It still surprises me that much of the tone of vulnerability management is about patch/bug fix vs. detecting broader configuration and architectural problems. I’ve always found it more 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 - especially cloud), 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 vulnerability management - 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 configuration. In cloud (IaaS, PaaS, and SaaS) this is where cloud security posture management plays well - but really is mostly cloud configuration assurance, where the security aspect is a number of pre-canned templates.
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 of 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 patching is not enough. Each layer becomes progressively more powerful for risk mitigation. There are probably yet more layers to build on top of this.
Comments