Organizations address problems; simple or complex, by creating solutions, leveraging systems and technology, primarily to establish a business process, and/or to simplify the means of achieving a business goal. Systems and solutions are built to cater to the needs; throughput, efficiency and resilience are seldom a consideration while creating a solution. It’s a known fact that none of the business or IT systems are 100 % foolproof, and the irony is ‘They still achieve their intended goals’. The Benefits are continuously derived, regardless, because ‘Why Fix It? When It didn’t Break’. It's just a matter of Time; One fine day, one school of thought provokes "How good are our systems?" - Let’s Check. Here they come, with scanners; scan inside out and outside in and the list contains 100,000 things to fix. Chief calls for a meeting asking, "What did we do to end up in this state?" or rather should the question be "What did we NOT-DO to end up in this state?". This is precisely where Vulnerability Management lives; quite often it is the reaction to the extent of exposure when realized at a point in time. Resources are only then committed to repair things one way or the other to fix the 100K weaknesses aka vulnerabilities throughout the organization. Sooner or later all these vulnerabilities will be addressed by deploying different types of controls and countermeasures. Bear in mind solutions are continuously evolved alongside technology dragging along the vulnerabilities. There needs to be a Fore-Thought, Look-Ahead with a Proactive approach, only then the long-term business goals are achieved consistently. Hence the start of Vulnerability Management.

For example, when creating a Business Application; requirements are gathered both high level and low level; user stories and test cases; development and testing approach; release, deployment, and then production. A good SDLC would include an Application Maintenance Plan, a downtime proposition; alignment with the configuration management database; more than anything else a set of dependency checks every time a certain version of the business application changes. All of which can be achieved with the help of a simple “Risk Assessment”. A candidate to suit the above example is a java-based application; every version change leaves the application exposed to a good set of vulnerabilities.

The best option to explore in SDLC is to attach a mandatory preventive maintenance plan with every system which is rolled into production, and one way to develop a preventive maintenance plan is by a thorough Risk Assessment. Put all the above together to evolve a “Risk-Based Vulnerability Management (RBVM)”.

So, how to start a Risk-Based Vulnerability Management (RBVM)?

By answering the following:

1. What is the value of the information the Business System is processing?
2. Identify failure modes of the application or business system as a whole.
3. What is the impact to the business for each of the failure instances?
4. What is the likelihood of occurrence of the failure mode?
5. What is the mitigation strategy for each instance? Ex: Accept, Mitigate or Eliminate.
6. What are the controls offered by the existing infrastructure?
7. What Administrative or Process controls can be explored as checkpoints?
8. Finally, Who Owns the Risk aka The Vulnerabilities in that System?

By exploring the answers to the above set of questions concerning any Business System and context associated with it; a Risk Based Vulnerability Management Solutions can be derived which if coupled with Administrative guidance can definitely lower the overall vulnerability footprint, not only for the information system but also for the business as a whole. One most important aspect of the RBVM – associate an owner to the vulnerabilities of a given system; It’s not an IT or InfoSec Team but it should be a business owner who has the overall accountability; Period.