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.]