In the first post we established that vulnerability management is a difficult task, regardless of what industry or organization you are in. We learned that every organization will have unique hurtles to overcome and that management buy in is crucial to the success of the program.
In this post we will be reviewing the second step in building a vulnerability management program: creating (or vetting an existing) asset inventory.
Inventory of Assets
What gets scanned during a vulnerability scan? Is it ALL assets? Is all assets except X, Y & Z? Is it only production assets and nothing else?
Before we can answer that question we need to have a complete and validated list of assets on the network in your organization. Don’t have one yet? GOOD. Lets build it with paid tools or open source tools. While most vuln scanners will do a “discovery” scan which is usually a ICMP echo request couple with a SYN connect scan on common service ports what if you have yet to get a vulnerability scanner? If you can install Nmap on a system with complete access to the networks to be scanned you can run the following to quickly gather a list of hosts:
nmap -sn -T5 –min-parallelism 100 –max-parallelism 256 -oN ./results.txt
Explanation: This nmap one-liner uses the -sn switch with the -T5 switch. -sn enabled “ping” only scanning while -T5 is a speed template, which tells Nmap to scan at its highest speed. The “–minparallelism 100” and “–max-parallelsim 256” defines a range of how many simultaneous scans can occur. Finally we specify that we want the results of this scan sent to a text file with the “-oN” switch.
Already have asset inventory? Do you trust it? Is it vetted? If your organization already has a CMDB or some other method of inventorying your servers, workstations, network devices, firewalls, applications, etc…start there but don’t assume its accurate. Either use the tools described above or some combination of other methods to verify the list.
Once you have built a trusted inventory you can then work with your senior manager to define the scope for the vulnerability management program. They will probably want to give you some input at this stage of development. If they don’t? I suggest scanning everything, always, every time.
One last note on building and vetting your asset list. This is the point in time you may discover your internal architecture doesn’t support scanning. Specifically, you might find out those firewalls between networks are not going to allow complete scanning and will hinder both your discovery and vulnerability scans. The solution to this is (simple but not) easy. Wherever your scanning from, this subnet needs to be able to freely communicate to the rest of the network (the firewalls should allow it to all destinations/all ports inside of your network). This means you will need to apply appropriate mitigating controls to this network and the scanning host(s) since it will have elevated levels of access to your environment. If your organization is dynamic enough, disabling these rules after every scan is a great mitigating control!