A big part of my “day job” over the past few years has been to act as the security advocate for a number of Dell EMC products. This includes a variety of activities, both proactive and reactive. One common activity is handling the life cycle of a security vulnerability through discovery, triage, remediation, and disclosure. Most (but not all) of the vulnerabilities I deal with are a result of embedded components which are updated periodically for security reasons.
There’s a common response I get when vulnerabilities, and their remediation, are disclosed. “Do I really need to worry about this one?”
When I put my corporate hat on, the answer of course is, “Yes. We advise you to <blah blah blah> immediately.”
But you know and I know that security vulnerabilities come in a wide variety of flavors.
So what’s the real answer?
The real answer is you can’t get me to tell you that, and you shouldn’t try. The real answer is that only you know your own threat model, and if you don’t, you should.
- What other security exists around the deployment of this application?
- Who are your likely attackers? Are you a small shop where everyone already is an admin, or do you have a large staff and multiple (possibly competing) tenants?
- What is the cost of the vulnerability being exploited: what data is on this system? What is it used for?
- Who consumes the output of the application — a single IT staffer? The VP of Engineering?
Let’s take a fictional vulnerability in the Linux kernel that allows a malicious attacker with user-level credentials the ability to reboot the system through use of specially crafted code. Let’s assume it’s challenging to patch the system for some reason (though it honestly shouldn’t be). Do you, as the IT owner of a Linux system, need to immediately patch?
Before you can answer, you need to know your own threat model.
- Who could exploit this? Are there any local user-level users on the machine?
- Is this a headless appliance with no interactive users, a single-user development sandbox, or a shared system with a hundred user accounts?
- How costly is a reboot? If a job is interrupted due to a reboot, what business impact does that have?
- How costly is the patching process?
These are just a few questions off the top of my head — and you should easily see how the answers to each could impact whether you should patch. Knowing the answers (to these and other questions), combined with your knowledge of the vulnerability (who can exploit it, what do they have to do, what is its impact) should tell you how critical it is to address this: can it wait until a scheduled maintenance window or should you be escalating for an immediate fix?
If you ask me, as the person documenting the patch, if you need to apply it, how can I possibly answer without knowing all the above? And even knowing it all, it’s not my job on the line if I’m wrong, it’s yours. You need to know your environment. It’s my job to tell you everything you need to know about the vulnerability to make the decision. It’s your job to decide.
All that said, everyone is still going to tell you to patch your system, and here’s why: the more issues like this you allow to accumulate, the more likely someone with specialized knowledge will chain them together and launch a legitimate attack. One issue like I’ve described may not sound like much, but you put a few of them together and suddenly you’ve got lab machines taking down your mail server with a DOS attack because someone clicked a link they shouldn’t have and ran some untrusted code and your defense in depth wasn’t up to par to stop the damage.
It’s almost always more expensive to recover from a breach than to prevent one.
There’s no shortcut here. You have to know your environment, understand the threat landscape, understand the vulnerability, and make sound business decisions. That’s why they (should) pay you the big bucks….
