Message-ID: <04F92BA33955D51195B700508B4AB6E91737EBFD@dslak12.dnznet.co.nz>
From: StuartF at datacom.co.nz (Stuart Fox (DSL AK))
Subject: Top 15 Reasons Why Admins Use Security Scan
	ners

 
And some more things for you to think about
> 
> Just some things to think about...
> 
> > Top 15 Reasons Why Admins Use Security Scanners
> 
> Question: Should admins be using security scanners?

Someone should be.  Admins should be to confirm that their environment is in
the state that they believe it to be.

> 
> > This list has been compiled by emailing various Security/Admin 
> > lists...
> > Anyone care to offer their input - add to the list?
> > 
> > -Am I sure that I have found all vulnerabilities in my network?
> > -Have I configured my network properly?
> 
> What's your policy say?  If you're relying on a security 
> scanner to define proper network configuration, maybe you're 
> in the wrong line of work.

How do you know your policy has been implemented properly?  A security scan
is a useful tool to help you determine this.  How do you know that your
policy is still relevant - are their new security best practices that are
relevant that a security scan could help you find?

> 
> > -Am I finding and closing security holes fast enough?
> 
> With proper policies and procedures in place, it's not a 
> matter of finding and closing holes fast enough. 
> Some Microsoft guys (Dave LeBlanc included) set up an IIS 4.0 
> web server on NT a full year before Code Red came out, and 
> from the time it went live, it was immune to Code Red.  Why?  
> The ida/idq script mappings were unnecessary functionality 
> and therefore disabled.

Again, have new types of vulnerabilities been discovered, are there new best
practices.  The reason Code Red hit so hard was because people didn't know
about removing script mappings - it wasn't a common best practice.  It
became one pretty quickly after Code Red.

> 
> > -How do I know which machines have a missing patch?
> 
> What is your patch management process?

Is my patch management process working?  A security scan may well be part of
your patch management process, but you need to confirm that what your
process says and what is actually happening are the same.

> 
> > -Are we resistant enough to network-savvy viruses that spread via 
> > known exploits?
> 
> What is "resistant enough"?  You can roll out Norton on your 
> email server (and other servers) as well as on your desktops, 
> and manage them all from a central location, pushing out 
> updates as they become available?  Do you?  A security 
> scanner won't tell you if you do or not.

How do you confirm that updates are actually being rolled out, as opposed to
trusting that they are?
> 
> > -Are we in compliance with HIPAA, Sarbanes-Oxley and other 
> > regulations?
> 
> The only way a security scanner will tell you this is if it's 
> compliant, as well.
> 
> > -What have I missed in locking down a server or environment?
> 
> What do your policies and procedures say?

Have my policies and procedures been implemented properly?  How do I know -
by running a security scan?

> 
> > -Do I have my network perimeter and interior sufficiently protected?
> > -Have I identified and protected my network resources from external 
> > threats?
> > -Do I know which systems are now well protected?
> > -How vulnerable are we from the inside?
> 
> From what threat?  Are you refering to users, or to admins?

Probably both.  They're a different class of threat obviously, but both need
to be considered.

> 
> > -How will I ever pass my IT Security Audits?
> 
> Don't worry about it...most audits don't seem to have an IT 
> background, and even when they do, they don't take the time 
> to understand your business processes or your network infrastructure.
> 
> > -How do I locate computers on my network, that are not within 
> > compliance?
> > -How do I report to Management that we have done all we 
> could to lock 
> > down?
> 
> Very carefully.  IT guys and management don't speak the same language.
> 
> > -How do I detect unknown and/or rogue
> > devices/connections?
> 
> By understanding your infrastructure.  If you know what IP 
> address ranges are assigned and to where, then you'll know 
> that whatever device is on 10.2.1.52 shouldn't be responding 
> to ICMP...

And how did you detect that it **was** responding to ICMP - it wasn't by
running a security scan was it?

You've offered a lot of thoughts that seem to involve a degree of faith in
policies and procedures.  Policies and procedures can only do so much, but
you have to confirm that they are actually implemented correctly.  A
security scan is one way to develop improvements to your policies and
procedures, or to spot ways where their implementation could be improved.

Powered by blists - more mailing lists