Vulnz: Being up to date is not the goal

Yup! I said it.

Being up to date is not the goal, for security. Being up to date is a side effect, a bonus if you will.

What on earth am I on about today? Glad you asked. Every security team is at some point tasked with a “vulnerability management” project/goal/initiative/whatever. Either of their own volition, or from the looming threat of compliance.

Compliance I’ll ignore, as you’re not paying me to write this, but for security what are you trying to get from vulnerability management?

“Everything secure and up to date! Surely”

Sure, what do mean by secure?

“Secure! Has no vulns in it”

Do you mean no known vulns?

“Yes! thank you, no know vulnerabilities”

you know there are heaps of vulnerabilities that are known but don’t have fixes, not even the dreaded 0-day, just a patch hasn’t been made"

“Oh, no. Okay so all the vulnerabilities that are known, and there are patches for, that are available”

So, this is patch management, not vulnerability management?

it will be okay, please just stop crying.

Patching agility is more important than patching recency

I posit that the speed and ease at which things can be patched is a better skill than just having everything patched.

Having everything on the latest version of whatever you can find/has all the fixes from their RedHat Satellite Server) is great, at exactly that point in time (say for an audit, sorry, no compliance talk here). This is a bunch of work and often a drive effort by a security team, that delicately (or less so) tries to do this with or in spite of the rest of the engineering org. And it lasts exactly one cycle of effort, at best. Is manual and toilsome, and features lots of dashboards and some Excel spreadsheets (okay, maybe Google Docs if you’re one of those cutting edge Cloud Native companies).

versus

Having everything able to easily be upgraded to a new version and deployed safely. When a new system is deployed it gets the latest version of it’s AMI base/built container/bit-torrented copy of Windows (I don’t know how Windows deployments work in clouds, I assume you define mouse movement and clicks in Terraform to drive a GUI?). If something is deployed and fails to build/test/run on a new version of something THEN there’s an alert, rather than an alert telling you you need to go and do something manual to an already existing thing. This becomes then not something teams have to do, or opt in to, it becomes how teams expect the platform to be. Developers expectations change from being hassled when their code is working (which, you know, should be most the time), to when it stops being able to work (but importantly is still working, it just hasn’t taken this new change too well).

Vulnerability management vs. Patch management?

One view, which my regular harsh opinion co-conspirator Kelly Shortridge has, is the dreaded

How does the infosec organism self-perpetuate via SecObs? Here are some examples (which perhaps can be called “Indicators of Obstructionism” or IoOs): Vulnerability management that creates long lists of things to triage (and outside of dev workflows)

Kelly Shortridge - The Security Obstructionism (SecObs) Market

Developers shouldn’t have to care about CVEs, bug classes sure, secure methods and styles of coding definitely, CVEs? not especially. As an industry we’ve tried throwing CVEs at people for coming on 25 years so that’s clearly effective! I’m not saying CVEs are useless (I’d love to, but one article at a time 😇), I’m sure there’s a perfectly good reason the not-for-profit organisation, who gets $2B from the US government likes to catalogue all the vulnerabilities in computer software for the public good, the US government well known for their doing the right thing, publicly charitable nature.

Sorry, where was I.

And then, once you have this magical ability to keep systems up to date, and only have to concentrate on the things that have issues, as opposed to having to ssh in and run apt-get dist-upgrade on all your containers (I kid, hopefully), you will get up to date systems, perhaps even passing compliance if that’s your kink, as a free side effect of this, and for more than one week too!

Not everything is in season in the state of Denmark

Obviously this isn’t a perfect system as it involves computers. I’m not suggesting you run the freshly copied from github HEAD version of software like the rubbists remember the 2000s, rubbygems has it’s Pessimistic version constraint for things like “install the latest version of this patch level” which many who’ve used bundler will have scars from.

There’s also a lot of implications of things like SemVer or other useful versioning standards being followed. Many linux distros prefer to backport fixes rather than upgrade a version, which I’m sure a lot of operations people are very grateful for, and anyone running Nessus will lament (but if you’re running Nessus in 2022 then you have a lot more problems than anything in this post).

All my dearly loved SREs and operations types are already screaming at me about when patches/updates break things and have written this off as “idiotic youth speak”. I did try and emphasise the testing part (I even wrote about it a lot last week too “Infrastructure in this Post-DevOps World?"), and will happily admit this won’t work in many environments. If you’re not already at a point of having agility in your environment for your code or infrastructure, then this isn’t fixing those more fundamental problems, sorry. Might I recommend “we’re hiring dot com”?