editione1.0.0
Updated October 9, 2023If you’ve been notified that a tool or technology you use has a security vulnerability, there are actions you can take and mitigations you can put in place.
Before we act, it’s crucial that we understand the risk this vulnerability poses to our organization. This starts with asking the following questions:
When was it found?
What are the details?
What is the severity of the issue?
What is the impact of the vulnerability if it is exploited?
Are there any proof-of-concept tools?
Have there been reports of compromises using this vulnerability?
Using the news, online communities, and our own research powers, we can answer these questions to understand the scope of the problem. We are not trying to decide if we will take action. We are trying to decide when we take action.
Now that we understand what the impact would be if this vulnerability was exploited, we’re going to try and map out how this technology interacts with and affects our processes, systems, and customers.
Map the internal impact and exposure. We’re going to map out our business and where this technology touches. This can be a tricky and manual process. Don’t underestimate the complexity needed to get this working.
Map the external impact and exposure. Finally, we’ll review this technology’s impact on our external elements such as customers, third-party tool providers, and suppliers. Does it interact with our systems or products? Does it relate to our customers or processes related to them?
At this stage, we start to understand our options. These questions will allow us to decide the next steps to take:
Is there a patch available?
Has it been tested?
What else would the patch change?
Do we have the access and resources to act?
confusion Remember, security is often a footnote in a patch. Companies are not obliged to disclose software vulnerabilities in their products. So please pay close attention. We’re not joking when we say the presence of new emoji in a patch is more likely to get front page news than the security vulnerability that’s hiding three lines below it.
The next mitigation we need to discuss is patching and updating. In simple terms, this means applying a patch (a change to the code that makes a technology work) using a process to update the version of the technology we are using.
As soon as the patch is available, we’ll update our software. This is the best-case scenario, as sometimes it’s not possible to update your software.
There are a few common reasons for not being able to update a technology. In this section we’re going to be pragmatic. We know that you don’t live in a perfect world and you’re making some tough decisions.
You can’t make the change. It could be that the technology or the vulnerability is in a legacy project, one that’s no longer supported. Or in the worst-case scenario, if you don’t even have the code for that system anymore (it was lost in that disc failure in 2003), it belongs to a third-party contractor or an outsourced company.
It’s a breaking change. The security change might be small, but it’s included in a large batch of updates that takes you up to a major version of a library. In this case, the amount of work to implement the patch is likely to be significant.