Vulnerability Scanning: Creating Scan Groups

At most sites in my experience, vulnerability scanning begins by doing a discovery scan, creating groups, assigning policy, and then proceeding on with scanning. These scans eventually will become reports that will go out to some entity, but there are some up and down sides to this approach.

First, let's look at doing a discovery scan. How do you do it?


To start, you will need to know all of the networks you are supposed to be auditing. For some sites it may be sufficient to refer to network diagrams. For sites that want to be the most diligent, you would capture all of the known routes from your routing devices. Then you would want to launch a discovery scan against the networks identified. If you are using a simple ping, icmp may be blocked between subnets and this may not give you a good footprint of what nodes exist on the network. So first, using a connection-oriented protocol along with connectionless protocols will be the most comprehensive method for conducting a vulnerability scan. To be even more comprehensive, it may be best to not only define discovery scanning to hit normal common ports (20, 21, 22, 23, 25, 53, 80, 443, and so on). This will give you a pretty good idea of what is out there, but what about other ports that were not being searched for? Notice that several well known ports are overlooked such as 123, 110, 389, 636, 1433, 1521, and many others. This leaves the potential for undiscovered assets. Now it may not be worthwhile for the sake of performance to not scan all common or well known ports (0-1023), but it may be worthwhile to investigate what your organization may have in order to better define what to look for.

Now let's say that a discovery scan is ready to be conducted. If your organization had the foresight to design each office, section, or floor by subnet you may be able to group like assets together and audit systems by a net block or ip range and this may be feasible in your environment. But what if your office suite wasn't planned out with such great detail?

There may be another place to look for obtaining these like assets. Active Directory (or like directory services) likely has an OU structure that is conducive to grouping by specific offices, sites, or types of systems. Obviously Active Directory doesn't house your Linux, Unix, printers, VOIP phones, appliances, and routers/switches. which is why you also are doing a discovery scan. You could develop a hybrid approach by using your discovery scans, comparing that against a dsquery, and then separating assets based on their OU structure. This would require the use of spreadsheets or some scripting ability, which makes it a little tougher to do.

If your organization does centralized patching, it may make more sense to focus scan groups into centrally patched systems and non-centrally patched systems. This may mean separating workgrouped servers from member servers patched by some centrally managed tool like SMS, SCCM, or BMC. It may mean separating out those that are patched by WSUS vs. either of the previously mentioned solutions. It may also mean separating out *nix systems with Yum update against those that do not.

Finally, you can always do it the old fashioned way. That's right, making manual entries and surveying your audience to see what groups would work best for them.

I believe that the reason many security programs are not effective comes down to largely two things - training and acceptance. It is important that vulnerability scan groups place like assets together because these systems will eventually become reports. If you mix assets within scan groups they will also be mixed in reports. Once you do auditing scans, tracking vulnerabilities to closure will become a more daunting task and you risk losing the faith of your audience, which is an even bigger fallout. This happens because the report audience will become disgruntled with seeing mixed assets that they may or may not be able to address.

However you do it, a well thought out and well designed plan mixed with a little customer satisfaction will get you a long way. There are so many benefits to doing this correctly that it really is worth taking a second look at how your organization does this, and how it could improve to achieve better results. A few notable benefits are obtaining a better baseline of assets within the organization, increasing the morale of those doing vulnerability assessment, reassuring those receiving the reports that these items are more usable, and betterment of the current security posture and program which will better align with organizational objectives.