This post is going to be more applicable to companies than individuals as it is going over how to manage vulnerabilities across all your computer systems. At a super high-level, the concept of vulnerability management is pretty simple. It is all about managing your vulnerabilities. When you dive deeper, then questions start to surface. Questions such as:
- What exactly is a vulnerability?
- How do I know what my vulnerabilities are?
- Can I management something I do not know about?
Some think that vulnerability management is all about having vulnerability scanners such as Tenable Nessus or Qualys and periodically running scans with them. Others believe it involves periodic penetration testing. Not only is this extremely flawed thinking, but it is also potentially dangerous and increases your exposure instead of reducing it. Sure, those things can add value to an already mature vulnerability management program; at best, they are a small addition to an overall program.
The purpose of a good vulnerability management program is to reduce your exposure and make it easier for you to respond when an issue comes up. To answer the questions from above, you cannot manage something you do not know about. To define the word vulnerability, turn to any English dictionary; it will give a good definition applicable here. The third question will require some discussion.
Since you cannot manage, what you do not know about a good asset and configuration management is the foundation of a good vulnerability management program. If you can only do one thing, just get your hands around what you have. This, of course, starts with knowing what computers and systems you have where, what IP addresses they have, and who is responsible for them. Knowing how big the hard drive is, how much memory it has, and what sort of NIC it has is not critical to vulnerability management, but it is useful information for other programs. Knowing the MAC addresses could come in handy, though, for this discussion. Once you have the basics covered, it is time to dive deeper, this is often called configuration management, but it is just an extension of asset management. In this stage, you collect details about what is installed on each computer. Here you capture things like
- What Operating system is installed, what version, and when was it last patches?
- What applications are installed, what version, and when was it last patched?
- What frameworks are used by what application?
- Do any of the frameworks or applications rely on external components or modules?
- Is any of this managed by someone other than the system owner?
Notice a trend there? For good asset and configuration management, all this and more should be documented in excruciating detail. If done correctly, you should be able to pull up all the systems that have a specific version of dotNet Framework, or a particular version of python, etc. You should also be able to detail the exact specs, all installed applications, frameworks, etc., for a given IP address or hostname. Make sure you capture both, along with any aliases and domain names.
Once you have all this documented, it is time to turn to the process side.
- How will you stay informed with issues that come up in the industry?
- Who is going to watch announcements from US-CERT, NIST, NVD, etc.?
- How will you go about remediating issues as they are discovered? Who will have what role? How will information flow?
- Publish a statement on your website on how a security researcher can notify you of an issue they notice externally. Then have an internal process for handling these notices, who is responsible for what, etc. This is called the responsible disclosure process.
Now you can say you have a vulnerability management program. Notice how there is no tool involved so far. The only tool you might think about so far is a Configuration Management Database (CMDB). If you are small enough org, you can do all of this with nothing more than your standard Office suite that you likely already have. If you are a little larger, a proper database will make a world of difference.
Only after you got both a solid Configuration Management and a firm policy & procedure should you even think about bringing in a vulnerability scanner. At this point, you can start to look at products like Tenable, Qualys, Tripwire IP360, etc., and find a product that suits your needs. Feel free to reach out if you need advice in this space. Then amend your existing Vulnerability program with details around what should get scanned when and who is responsible for what. Make sure you specify who is responsible for making sure scanning happens, who is responsible for disseminating the scanning results, and who is responsible for remediation.
