Most shops are small. Small shops as a rule (there are exceptions!) do not dedicate resources to security, and that represents risks to big shops that depend on those small shops. Big shops don’t like risk, so we have compliance baselines. Big shops usually have lots of dedicated security people who might even think compliance is stupid, but at the end of the day big shops are why compliance exists because small shops are a lot more comfortable accepting risk. Compliance means those shops have to use some kind of ongoing vulnerability assessment process and tool. It’s certainly annoying to deal with false findings that aren’t relevant to one’s situation, but I’d argue that everyone in the industry benefits from compliance driven vulnerability scanning. Anyone must be this tall to accept credit cards or sell to the Feds.
Those standards still leave room for nuance and interpretation, so the forces of “let’s not risk disruption” can prevail a lot of the time. So there’s a backlog of findings, mixing actual problems with inaccuracies. Note that identifying the inaccuracies usually requires contextual knowledge: it’s not that you’re running a patched and safe version of Postgres, because you’re not, you’re pinned on a version that’s got a dozens of CVEs. Rather it’s that you mitigated the issue elsewhere (ephemeral instance bound to localhost behind a stack of firewalls and holding a lucky shamrock). In other words, automating awareness of finding accuracy is closely related to that other nasty problem, automating awareness of your service relationship graph.
Anyway, now you have lots of findings, some of which are invalid, and you have to, or get to, make some choices about what to do about the oncoming SLAs attached to them. There are two obvious fail points at the ends of the activity bell curve:
Do nothing! Probably safe, just fix the worst things when some auditor says you have to. If you implement a Change Approval Board (CAB) or Change Review Committee (CRC) so everyone has an opportunity to stop the patch train, you might not ever have to roll out patches again.
“Fix everything now!” Your time in this organization will be a brief blaze of glory, like a moth in a bug zapper, but you’ll fix a lot of stuff. Unfortunately you’ll also break a few things, so that’s that.
Okay, so those are bad. More realistically, one evaluates findings, corrects some of them, and marks the others as invalid or deferred (accepted risk). Pick some stuff to fix in maintenance windows with some theoretical rollback options to appease the CAB/CRC people. Nice and safe, but how to pick? I Ching? CVSS? Vulnerability scanner vendor’s recommendation? Monte Carlo simulations of attack probability versus damage estimate? How about an LLM? They all sound like fun, but none of them will stand up perfectly to either scrutiny (“is that really a vulnerability in our environment, or was it mitigated by environmental context”) or prioritization (“That’s nice, but we’re not willing to risk self-inflicted downtime and our team’s mission outranks your SLA, kthnxbai”).
The key to understanding this approach is that there are three pressures aligned against each other: the risk of inducing downtime, the risk of failing a compliance audit, and the risk of being breached. Each of these pressures is more important to a different stakeholder, and their opinions of importance change over time. To successfully manage the job of correcting vulnerabilities, these pressures need to be recognized and balanced. Prioritization means deciding what you won’t do, otherwise it’s just making a list. Doing it successfully means answering why some stakeholders aren’t getting exactly what they want when they want it.
Monkeynoodle.Org 