top of page
  • Phil Venables

Vulnerability Management

I don’t see much written on vulnerability management in more holistic terms vs. patch/bug fixing. This might be ok given a lot of vulnerability mgmt. should be contextualized into enterprise risk/control. I’ve always found it immensely useful to think of vulnerability management as four layers - building on each other and in turn becoming more powerful as a risk mitigation approach.

  1. Coverage completeness, criticality ranking and dependency mapping. Having a continuously defined, enumerated and verified inventory of all the objects in your domain (internal or external), understanding their relative criticality in the context of the organization's business processes as well as the dependencies between them. Identify dependency discrepancies e.g. something ranked as highly critical being intimately dependent on something ranked as not critical signals an error, or a need to understand why the dependency doesn’t propagate the criticality (which may in fact be a good design). You all know, this is hard to do, very hard. I don’t know any organization that does this as well as they’d truly like, or any tool that can currently help enterprises get this right in a practical way (although there are various new companies taking a good shot).

  2. Component flaw discovery and remediation. This is what most refer to as vuln. mgmt. - the discovery (by various techniques) of flaws in software/other objects that can be exploited. These are remediated by fixes/patches, layered mitigation or compensating controls.

  3. Configuration flaw discovery and remediation. A system that is free of component flaws (hypothetically, no ‘zero day’ vulnerabilities and is all patched and up-to-date) can, of course, still be riddled with exploitable vulnerabilities due to its configuration. This could be by design or accident (drift from expected configuration). Hence, it is important to adhere to standards or baselines (in CIS parlance) by continuous monitoring and/or continuous redeployment of assured/pristine builds & validating overall system-wide config.

  4. Architectural goal enumeration and enforcement. Defining and enforcing design patterns across an environment such that individual flaws or issues from layers 1, 2 or 3 have less potential effect or overall ‘blast radius’. This could be as simple as separation of services across security zones, service isolation, data desensitization, tokenization, immutable infrastructure patterns, and myriad others. There are two overall approaches to this : constraints and obligations.

  • 4a. Constraints. Developing rules for what potentially toxic arrangements of components should never exist. Scanning for these is as much a job for continuous vulnerability scanning as making sure unit components are patched and configured correctly.

  • 4b. Obligations. Developing default architectural/design patterns for the deployment of common services and then monitoring for adherence to those as well as enforcing them as “policy as code” in various parts of the development and deployment lifecycle.

Bottom line : vulnerability management should have multiple layers, standard component flaw discovery and patch is not enough. Each layer becomes progressively more powerful for risk mitigation. There are probably more layers to build on top of this.

194 views0 comments

Recent Posts

See All

Since the last post about leverage points in managing complex systems I thought it would be good to revisit and update a post from a few years ago looking at the seemingly accepted wisdom that complex

Security is an emergent property of the complex systems we inhabit. In other words, security isn’t a thing that you do, rather it's a property that emerges from a set of activities and sustained condi

Unless you’re doing continuous or quarterly budgeting, which some organizations do, then you’ll no doubt be getting ready for the long haul of the annual budget process to seek the resources you need

bottom of page