Vulnerability Management Risk Based Approach: Keepin’ it Real

If you are reading this, my catchy photo and title caught your eye. Hunt no further for answers regarding vulnerability management and risk treatment. Vulnerability management is not just scanning and reporting – it’s a critical ingredient to the risk management and compliance program mix. Think of it as the icing on the cake – wrong analogy… maybe the cherry, in any regard, an important part of the overarching success (or failure) of a security program. However, security practitioners are at a crossroad. There are some very exciting technologies that will help enhance your program. We (security practitioners) are also getting smarter and better at vulnerability management. On the down-side, there are regulatory and contractual requirements that are impacting our ability to base our programs on a risk based approach. Some regulations and even contracts are too prescriptive and enforce outdated approaches. Following the simple rating and prioritization of vulnerabilities according to the scan vendor’s recommendation is sooo 2010! Below I share my recommendations on vulnerability management that I’ve learned from the trenches.

As stated previously, standards and policies are built to align with regulatory requirements and best practices. The regulatory requirements trickle into customer requirements in our contractual agreements. If the company you work for offers services or products, chances are you have contractual requirements that align with regulations or industry requirements. Have you ever reviewed a contract (usually already signed) that has your company agreed with requirements that you can’t meet? It happens, don’t freak out – consider it leverage for getting some things done – this is the ultimate business requirement. See below, an example of a poor approach to vulnerability management. This is the traditional time-based approach assigning priority to remediation. This approach leads to chasing vulnerabilities and remediation timelines with no regard to risk reduction.

We need more contractual language around organization’s vendor programs asking for the risk based approach. Vulnerability management teams should review contractual requirements and ensure the vulnerability related requirements leave room for deviating from the old boring (and more risky) scan, assign due date, lather, rinse, repeat. The Payment Card Industry Data Security Standard (PCI DSS) is already changing the vulnerability approach and showing some promise in the wording of the requirements, however, there are still references that blur lines between patch and vulnerability management… more on this later.

The blurred lines I’m referring to is the mixing of requirements around patch management and vulnerability management. They are not the same. Patch management processes should take a pro-active approach. Mature patch management programs have methods to either monitor or get updates for patches to be deployed. This is a process that should be managed outside the vulnerability management program – with its own policy/standard. The vulnerability management program, in nature, audits the patch management program. I’ve experienced programs where patches and vulnerability remediation is discussed as though it is the same thing. It isn’t. Of course there may be a good business reason to merge them together – if there is, I’d love to hear about it.

In the table posted above I showed a bad example of a remediation timeline. Can you see the issue with the approach? It is missing critical criteria needed to properly assess risk. In addition, scanning technologies do a great job of taking in the CVSS (Common Vulnerability Scoring System) data and assigning severity to the vulnerability. The critical data that we need in addition to vulnerability severity is:

• Area of the network (Internal, DMZ or other sensitive segment)
• Data sensitivity
• Exploitability

This additional context rounds out the risk based approach and assists in assignment and treatment of risk. Some companies, such as Kenna Security, factor in other important things such as real time threat intelligence and have the capability to “weigh” assets with vulnerabilities to add another dimension to your vulnerability management risk treatment process. Kenna Security takes the manual weighting and scoring out of a risk based vulnerability management approach. One quick way to weighting systems is to leverage your company’s Disaster Recovery (DR) program to help you identify critical systems in your enterprise. DR programs send extensive checklists to business owners to understand where investments must be made to ensure there is limited interruption in services in the event of a disaster. These programs usually rate systems by recovery times, lower recovery times means more investment. The more investment in keeping recovery times low – equals the more critical systems are to the business. Viola! Weighting systems made easy. No DR program? Then you probably have less systems and you can quickly identify your most critical assets.

Don’t Forget Critical Exposures: Just like thieves looking for a house to break into, the house with the lights off indicates no one is home and is the one that becomes the target. So keep the lights on and keep your cyber footprint low. Scanning tools that are cloud based can identify ports protocols and services and identify critical exposures. One cloud based tool that offers a unique approach to scanning for external (internet facing) exposures is Qadium. Qadium scrapes the internet and can find systems with a reference to your domain and provide historical data about your assets and exposed ports and protocols. Remember to leverage this data to close ports that aren’t needed. In addition, Qadium can give you information about certificate health. This helps keep reputation based stats high and ensure secure communications are secure.

Yep yep… keep your cyber footprint low, treat risk appropriately and tip your wait staff… rules to live by.