Vulnerability Scanning: Best Practices

This is the first of what will be a series of posts about vulnerability scanning.  This particular post will be fairly generalized, but the next two to three posts to follow will be more in depth.


Vulnerability scanning is something that every organization should do. It can drastically help improve an organizations security posture. There are many different ways that a vulnerability scanner can help your organization to build secure systems, validate maintenance and patching of existing systems, and in some cases ensure legal compliance.  In any case it is important to make sure that scans are being run with administrative privileges.


Vulnerability scanners can help an organization to build and produce secure systems by reviewing systems prior to them going into production.  This can be done many ways.  Some organizations may have a build subnet with a permanently affixed vulnerability scanner designed specifically for this purpose.  Others may have a build subnet that is completely isolated.  While even still others may have a laptop loaded with vulnerability scanning software that they connect via cat 5 and set the net mask so that the two can talk, essentially making a peer to peer network.  Once built, these systems can be shipped and delivered secure (assuming no one tampers with them in transit ;) ).


Patch and configuration management can be audited using vulnerability scanners.  Generally speaking, the most typical approach is to scan-patch-scan.  In other words, the first scan identifies what needs to be patched. Then fix actions are applied based on the report.  Finally after the fix has been put into place, a second scan is done to confirm that the fix was applied properly and/or resolves the finding.


Some vulnerability scanners can be used for checking legal compliance.  These will typically have a NIST policy looking for control compliance, PCI DSS compliance, HIPPA, and others.


Vulnerability scanners are often misused.  Their name says it all.  What do you think a vulnerability scanner does?  It scans for vulnerabilities.  This is such a simple concept that so many just do not get.  No where in the name do you see "malware scanner" and yet throughout my career I hear this silly requirement to run a vulnerability scan to make sure the system is free of malware.  A vulnerability scanner cannot identify if a system is clean or infected (unless of course you write your own policies and custom checks that are specifically looking for files created when the system is compromised by malware x).  It is important to remember that a "vulnerability" is only the potential for a system to be compromised.


In the upcoming posts I'll be diving a little deeper into this subject.  I intend to cover ideas for establishing policies, scan groups, reporting best practices, common scanning mistakes, properly identifying false positives, and reporting concepts.