editione1.0.0
Updated October 9, 2023There 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.
There’s no patch available. If the vulnerability is an open-source library or framework, it could well be that the community doesn’t have the expertise, resources, knowledge, or even time to get to that vulnerability and patch it. There are still major software systems that have known vulnerabilities in their stacks and have done for some time. Being a big company doesn’t mean you’ll instantly patch in a well-behaved manner.
So, if we can’t patch the vulnerability, what are our options?
It’s a risky plan, but for completeness, we should mention what to do if you choose to do nothing.
We don’t think you’re going to take this approach to your software security practice, but it feels like doing nothing when we choose to ignore a vulnerability.
This approach tends to apply to legacy and unsupported applications. Many organizations have applications or tools in their environments that are no longer supported, or for whom support is a complex subject.
Sometimes these applications have exceeded their lifetime and are no longer supported efficiently. Your organization may choose not to patch and to try to encourage people to use a new version of a product.
You can see this behavior and action if you follow the release cycles of Microsoft Windows and other operating system products. At some point, they choose to stop providing support and security updates, because otherwise nobody would ever upgrade. If nobody upgrades, they will be stuck supporting old and less innovative products forever.
If you choose to not update the technologies in your environment or the technologies used to build your product, you need to think clearly about the impact this choice will have on the overall vulnerability of your company and its systems, people, and customers.
In most jurisdictions, when company directors choose to intentionally ignore vulnerabilities that could harm the business or its customers, they open themselves up to liability if this vulnerability is later exploited. Check with a lawyer in your country or operating region to understand your directors’ responsibilities when it comes to protecting your organization from cybersecurity threats.
We’ve discovered a vulnerability in a library we’re using, for example, the library that’s providing our database connectivity.
What are the advantages of changing it entirely for something new? Maybe it will provide new, updated functionality as well as improved security practices. It could be an opportunity to modernize our technologies and, in limited cases, it might save you money or complexity. However, this comes at a high cost.
None of the advantages are guaranteed. All technologies have the chance of security vulnerabilities and the more modern the stack, or the technology, the less support and community may be available. There may be fewer people with the skills to understand and work with the technology, both internally and within the wider community. You may, as a result, struggle to hire people to fill roles for this bleeding-edge technology.
danger When choosing a new technology, supportability matters. A common risk associated with rapid, unplanned adoption of new technologies or dependencies is around support.
New technologies often don’t have the number of skilled engineers to support them to the same level. This impacts recruiting, retention, and support related to stress in our teams.
Definition Simply put, if you don’t have enough engineers with the right skills, the engineers you have will become burnt out and you may have a very hard time recruiting replacements. We call this problem key person risk. This is the risk from overreliance on a single person or a small group of people to complete critical activities or maintain key systems.
Have a think about your world.
Are you the only person that supports a tool, process, or system?
Is there a part of your world that would struggle to function if you took a day off, or won the lotto and decided to move to an exotic island?
If you answered yes to this, then you are a key person risk. Part of securing your organization is to identify all the key person risk in your company and reduce it, enabling everyone on your team to take that dream holiday should the chance arise.
The lesson is to not avoid emerging technologies, but to consciously embrace them, knowing the challenges they may bring.
When defending our applications, the part that is exposed to the world is what we call the attack surface.
Figure: Layers of protection.
Deep inside your organizations and your applications lie your data, the precious things in the center of your system. Every time we add software or hardware around our data, we create another layer, a separation from the internal space.
A common approach in security is to layer more controls around our system to protect the inner, more precious workings. This is the digital equivalent of building a very strong wall around the edge of the castle, with a hope of keeping out invaders.
Now there are many reasons that this approach is only part of the picture. But for now, when we’re talking about layering defenses, I’m going to talk about putting something between you and the outside world to stop malicious attacks.
In security, we assume that every step we take to protect something has a chance of failure. By layering our security measures, we hope that when this happens, other controls will prevent the compromise from progressing.
Layers also allow us to introduce different types of control, each providing a different set of options for our defense. In our previous diagram, adding another layer on the outside is another challenge for an attacker to get through before they get to our most valuable items in the center.
Definition The first type is preventative controls, which are items that stop attacks from happening.
Definition A good example of a preventative control is a firewall, which is a device that sits between your internal network and the wider internet. It monitors and responds to requests entering and leaving your network to ensure that potentially malicious activity is stopped and only those expected and permitted connections are allowed through.
Definition Detective controls try to spot incidents or malicious activity. They won’t necessarily take action, but they may alert you that a bad thing is happening and you should do something about it.
Definition Finally, responsive controls (or corrective controls) assume that a bad thing has happened and allow us to respond quickly and efficiently to minimize the impact and to maximize our return to operations.
As you develop the security of your organization and its systems, you will gradually introduce each of these types of controls as layers to your defense, creating a comprehensive set of protections suited to your environment and the data you are trying to protect.