Continuous Vulnerability Management: Security as a Baseline

Ask 100 security ‘professionals’ what vulnerability management is and at least half of them will begin with patching, another 25% will focus on vulnerability scanning and penetration testing, and the majority of the rest will start quoting the gamut of Risk Assessment to Business Continuity. I’m not saying they are wrong, but most will not be right enough.

If you accept this description as standard; “Vulnerability Management is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities, especially in software and firmware. Vulnerability Management is integral to computer security and network security.“, it’s no wonder that actually performing appropriate vulnerability management is a concept rife with misinterpretation and bad decisions.

The old adage; “You can’t manage what you can’t measure.”, while often incorrectly interpreted from the original work of W. Edwards Deming, is actually completely relevant in information security. Security is series of baselines / whitelists /  known-goods, and is only ever effective if it’s simple and repeatable. In other words, if you don’t have a point to measure security from, how can you possibly know if it’s enough, or too much?

Like every process in security, vulnerability management  is only as good as the context in which you place it, and ANY security process out of context from the underlying business goals is doomed to failure. Rightfully so. The vulnerability management controls you put in place relevant to your environment therefore go through the exact same process as every other control, from firewalls to outsourcing.

Step 1: Determine your business goals – in order to conduct an appropriate Risk Assessment (RA) and Business Impact Analysis (BIA)

Step 2: Conduct a gap analysis – to determine the shortfalls or over-extensions between current security capability and desired capability

Step 3: Fill the gaps – to the capability level determined by the BIA (accept residual risk)

Step 4: Determine appropriate baselines – for the management, maintenance and monitoring of the ‘new’ infrastructure/processes

Step 5: Place appropriate ISMS-esque controls – around the ongoing management, maintenance and monitoring of the new infrastructure/processes

Step 6: Develop appropriate mechanism for the decision making process – from responsibility / function, to scoring / rating, to mitigation, everything must be in-line with Step 1 in order to be effective and sustainable

Step 7: Determine all control inputs to the process – including – and certainly not limited to – patching, vulnerability scanning, penetration testing, code review (if applicable), logging, FIM, and so on…

Step 8: Determine all appropriate internal and external sources of threat intelligence  – from relevant vendors to paid-for services.

Step 9: Bring everything together into a Management capability – one with a specific charter and report structure.

Step 10: Re-examine every step for continued relevant and effectiveness – on a regular basis

If this sounds complicated, it’s likely that you don’t understand one or several of the steps. All aspects of security are simple, they have to be, and while is can be difficult to implement, that’s almost always because you are not asking the right questions. In any endeavour outside of your business’s core competencies, the trick is not to ask for what you think you need, it’s to ask for help from someone who KNOWS what you need.

You don’t tell your doctor you have a brain tumour, you tell them you have a headache a leave the diagnosis up to the expert.

[Ed. Written in collaboration with Voodoo Technology, Ltd.]

PCI – Going Beyond the Standard: Part 11, Vulnerability Management

For those of you errr… fortunate enough to be have been performing PCI assessments as long as I have, you will have noticed the ‘progress’ the DSS has made in terms of turning ‘just patching’ into more of a risk based approach to threats. Yes, it’s about time, and no, it has not gone far enough to be truly effective, but it should go to show just how important this subject is.

v1.1 of the DSS didn’t contain the phrase ‘risk-based’ at all, v1.2 and v2.0 say that organisations “MAY consider applying a risk-based approach to prioritise their patch installations.”, then finally in v3.0 says; “6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

This only took 8 years.

Unfortunately, it’ll be 3 more years before they can make any additional improvements, and when you consider how far they are already behind, and the rapidly worsening threat landscape, you simply cannot afford to do the PCI minimums here.

Vulnerability Management is the overarching process whereby a significant number of other processes are combined into a method for the never-ending examination and remediation of threats to your business. Everything from risk assessment, to asset management, to configuration standards, to change control, to patching, to vulnerability scanning to penetration testing, to monitoring and incident response, all combine into a life cycle of knowing your business goals, and enabling both IT and the business side to get there safely.

REAL Governance in other words.

I have already explained [hopefully] why Risk Assessment s and Asset Management are the starting points for a proper vulnerability management program. The rest of my list below will get their own post in due course, but here’s why they are included here:

  1. Configuration Standards – No point trying to manage risk on something that is fundamentally flawed. Don’t get these right and all the vulnerability scanning and penetration testing in the world isn’t going to help. Not to mention your logging and monitoring would be so inundated with false positives as to be rendered ineffective;
    o
  2. Change Control – Without VERY robust change control even the best initial set-ups can become rapidly insecure. Why make things easier for the bad guys?;
    o
  3. Patching – For the longest time the PCI DSS focused on the patching of systems, and insisted that all relevant, critical security patches be installed within 30 days. This completely missed the point, and while patching is an important aspect of vulnerability management, relying on reactive security measures is like taking aspirin for a broken leg;
    o
  4. Vulnerability Scanning & Penetration Testing – I lump these two together not because they are so similar (they aren’t), but because they are complimentary and fall within the same category; Testing. The cycle of constant improvement cannot be maintained if you aren’t testing your security controls and processes in some way. Test, fix, test again, repeat forever;
    o
  5. Monitoring – For every second of the day, your systems are providing information relevant to their health and security. Ignore these events, or fail to properly interpret these events and you have negated any ability you have to prevent a minor incident from becoming a worse. Unless you are able to baseline a ‘known-good’ environment, you have no idea what ‘bad’ is;
    o
  6. Incident Response (and Disaster Recovery) – In theory, you should never need Disaster Recovery if your Incident Response is as good as it should be. Without all of the above in place, you don’t have the ability to perform either well.

One of the most common complaints I get from clients is that previous QSAs have insisted that relevant, critical security patches are installed within 30 days. Yes, that’s what the PCI DSS says, but the only reason I can see that this should be a problem is if your Vulnerability Management process is so poor that you cannot show your QSA how installation within one month is actually MORE risky than to not.

There can be many reasons for this, but the inability to test patches and/or get them rolled-out in time are not excuses I would accept.

I have yet to see Vulnerability Management done well, in ANY organisation I have assessed. The pro-active life cycle approach to security, while very difficult to set-up, is nevertheless very simple and far cheaper in the long run that a reactive one. My analogy for this is that it will take me a year before I’m fit enough to ever run a marathon again, but if I had just MAINTAINED my fitness from the last one, it would be a hundred times easier.

The only things in security that stay the same are the basic good practices, vulnerability management is one of those basics.

[If you liked this article, please share! Want more like it, subscribe!]