Re: Hopefully not too OT

[<jimmy () chickenhollow net>]

Gentlemen (and Ladies Lurking),

  I certainly do appreciate all of the good responses to this.  Phishing is indeed a worry I have to address as best I 
can, but our organization is 
a prime target for large scale type identity theft, and the type which would likely make the papers if a breach 
occurred. So this is my big worry 
at the moment.

  I completely agree that there needs to be an HR component to my plan (and it is already in place), and I agree that 
we (as IT practitioners)
have been taken off track in the last decade with the 'liberation' of the data from the central (and more easily 
securable) systems, and are 
now hurling at a rapid pace into ever new and uncharted areas of connectivity.

  But I feel that IT security will ultimately be held responsible (rightly or wrongly) for any identity theft which may 
occur(especially if it is 
through unathorized access to our system), so unfortunately *I* am where 'the rubber meets the road'.

  I am initially looking to eliminate any low-hanging-fruit from our system as best I can (double-checking that backup 
tapes are both securely 
stored AND encrypted!) And given that there was recently a massive theft due to a rogue wireless AP, that is what I am 
using to elevate 
general awareness and spur further interest from the powers that be in the organization.

  I am going to have to take a multifaceted approach to this I believe, we have a very aggressive security posture 
here, we mistrust our 
internal users just as much as external users, and have a very tight filtering system, at the wire and application 
level, but I am paranoid, so I 
will keep going further.

  If anyone has any experience with scanners (preferrably open source) which are good at ferreting out rogue APs I 
would be gratefull for 
pointers. 

  Again,  many thanks to all!

Jimmy

On Tue, 03 May 2005 10:47 , Kevin Sheldrake <kev () electriccat co uk> sent:

> > > From: "Paul Melson" psmelson () comcast net>
> > > To: jimmy () chickenhollow net>, firewall-wizards () honor icsalabs com>
> > > Subject: RE: [fw-wiz] Hopefully not too OT
> > > Date: Mon, 2 May 2005 17:12:59 -0400
> > >
> > > I fear that a jammer would give you a false sense of security.  For one,
> > > they're not totally effective, especially against ad-hoc networks in  
> > > close
> > > proximity to each other.  Sure, they kill performance, but they don't  
> > > shut
> > > it down.  Secondly, they can actually assist those airsnort-ing your  
> > > space
> > > in collecting unique IV's should your rogue users be well-intentioned  
> > > enough
> > > to use WEP.  Thirdly, many jammers only operate in the 2.4GHz band - in  
> > > the
> > > US alone you can buy WiFi products that operate at 915MHz and 5.8GHz,  
> > > to say
> > > nothing of FHSS vs. DSSS.  And, perhaps more importantly, jammers are  
> > > not at
> > > all neighborly if your offices share space or proximity to businesses  
> > > that
> > > do choose to use WiFi.
> > >
> > > Not to say that I have a better technical solution, but if you don't  
> > > want
> > > *people* in or with your organization to use wireless, then you have a
> > > *people* problem that requires a people solution.
> > >
> > > PaulM
> >
> > Jimmy:
> >
> > Actually, Paul Robertson, Ben, and Paul Melson hit the nail on the head.
> >
> > You need a written policy saying, in effect, "no wireless access to the
> > company network", get the employees to sign off on it AFTER the
> > layer-8/9 people approve the policy.  If anyone breaks the rules after
> > that, then you have an HR problem.
>
> While I agree that failure to adhere to the security policy is certainly  
> an HR problem, we shouldn't forget that all internal security issues  
> involving staff or contractors are HR problems, but it doesn't stop us  
> doing something about them.
>
> I'm sure you understand that in order to recognise the HR problem, we need  
> suitable accounting and audit systems (however the sensors are  
> implemented).  We also might be concerned about the exposure to risk in  
> the period between detection and repair, and we might wish to do something  
> to lower it ahead of the breach.
>
> As I said, I don't think I'm stating anything new, I just thought it was  
> worth stating that technical controls should be developed hand-in-hand  
> with personnel and procedural controls; changing the policy alone might  
> not have the desired effect and, with insufficient accounting and audit,  
> we may never know.
>
> Kev
>
> -- 
> Kevin Sheldrake MEng MIEE CEng CISSP
> Electric Cat (Cheltenham) Ltd




_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards