Vulnerability Management Part 3: Mastering Vulnerabilities the Right Way

How do you ever “master” an area which constantly evolves? You do so by understanding that mastering simply means having control or ownership of something. It doesn’t mean you’re going to stop something, because you’re right, there is no way of actually stopping vulnerabilities. You can, however, have control in knowing your environment, defining the processes and motivating progress (delegating as you see fit).

Step 1: Knowing Your Environment

The right way is knowing (or someone knowing) what exactly is running on the network and how. Is it an application? What version? What patch level? How does it authenticate? What communication ports does it use? What type of data is stored/transmitted? What services are running or being used? What's the typical memory usage? How much is the throughput traffic size? Does it require Java or have any other dependencies?

The reason for these types of questions and information is that you are trying to establish a baseline or normalized profile of your environment. This is your understanding of what a system/application/database looks like in a “normal” day to day situation. And what abilities they have in relation to the whole network. This information will also help in cutting down the scanning by having “focused scans” instead of “spam scans” (scan everything).

This must be treated as living; meaning that you have to care and feed it. This is the backbone of your program, without it you’re a jellyfish floating in the www ocean.

Step 2: Choosing Your Vulnerability Management Tools/Service 

The right way to choose a tool or service to help identify vulnerabilities is not to rely on just one tool or a service that uses one tool. You could go with an enterprise edition VM scanning tool and have an open source VM scanner in your back pocket.

Sometimes, even the best of us have bad days, and we might miss something. It is a good idea to have a second person check from time to time to make sure we are seeing things correctly. In the military we call it the “Two Man Integrity Check.” While I wouldn’t go rescanning everything, I would take a small sample size. If what you have can cost millions in damages, then it's worth going the extra mile.

Managing those vulnerabilities in a consistent manner with a manageable workflow is another matter entirely. For that, you really do want a single, unified tool that can integrate all vulnerabilities from all sources.

Step 3: Embracing the VM Scanning Life

The right way to embrace the VM scanning life is to incorporate/integrate the process early. I recommend breaking up the environment into segments/sections and start there. The overall process is relatively simple: scan, remediate, scan, verify. Ensure you have a strong tracking method of this process. This is very important. Anything that cannot be remediated needs to be flagged and have some type of control in place as an alternate solution, until a proper patch is developed. This is where solid workflow in a unified vulnerability management tool is indispensable.

Instituting a change freeze while you begin your scanning program is often underlooked. It presents lots of problems later on while trying to conduct vulnerability trends. This is why you get the best results if you start with the baseline and work from there. Go through your developed processes on identifying, tracking, remediating and verifying vulnerabilities. Ask for input and shore up the areas that might need it. The more the program is “team developed” the better.

You should expect to have a lot of questions. My best advice is for you to rely on the experts to tell you more about where you are. They will, most likely, be the same experts who will have a workaround solution for those “just in case” moments.

After you formalize the program, you can then implement more frequent scans. These scans can be more focused on the applications they are scanning, which will save you time and bandwidth. For any new systems coming online, you should add them through the same process, starting with putting the baseline/profile through a scan. Then put it through a 90 day probation period, where it may become scanned. After its probation period, I would then add it into the regular scanning pool environment.

Those are the three steps it takes to mastering or controlling vulnerabilities the right way. It takes a complete group and team effort to make an intrusive program such as this work. If you do it successfully and continue forward, it can help you in other areas such as assessing risk or determining incident response measures.

I know this blog has been one of my longer ones, so thanks for riding along. This was a fun blog for me. I recalled the lessons I learned while serving as an Information Assurance Manager in Bosnia. With team effort, we made our VM program successful.