So you have just installed the latest antivirus and turned on your shiny new firewall. Now your organisation is fully secure, right?
The reality is that all the security products in the world will never be able to fully protect your data centre or your business from security threats. Because of the asymmetry between attackers and enterprises, cybersecurity is a problem that can never be solved and is never going away. The key is to realise that the journey towards a healthy infrastructure is one that has a beginning but not an end.
So what does a good cybersecurity strategy look like? While Canonical is not a cybersecurity vendor, we make sure countless organisations around the world are safe from potential attackers. As the first link in the software supply chain, we play a critical role here.
In this article, we want to explain how different security considerations help shape the way we design our products and what you should consider when developing your cybersecurity strategy to ensure open source security.
Prevention is the best cure…
As the Dutch philosopher Desiderius Erasmus theorised in 1500, focusing on prevention is a lot cheaper and more effective than focusing on the cure. The COVID-19 pandemic taught us that. This principle applies to cybersecurity too.
Security operations teams are often understaffed and under-resourced, therefore it is crucial that they focus their attention on putting off the big fires, rather than look at smoke signals to understand where the fire is.
The best way to enable that is building healthy, resilient systems that are vulnerability free. In reality however, implementing a consistent hardening and security patching strategy is one of the most difficult things for IT teams to get right, especially smaller ones.
At Canonical, we believe that security patching and hardening should not be limited to sophisticated, well-funded IT teams. That’s why we released Ubuntu Pro to democratise access to security support. Ubuntu Pro offers 10 years of security updates for all packages in the Ubuntu Universe repository, live kernel patching and hardening automation tools.
The focus on prevention goes far beyond the operating system: Canonical Kubernetes and Microk8s implement the Center For Internet Security (CIS) hardening profile by default. We are also working on ROCKs, which are minimal, hardened container images with the lowest possible surface attack area.
Ultimately we know that tall walls and deep moats have never kept a castle safe forever. However, in a world where most companies are keeping their gates open and walls unguarded, a consistent hardening and security patching strategy will go a long way in deterring ordinary, unsophisticated threat actors from easily breaking into your systems.
…But detection, response and recovery matter too!
What happens when attackers get in? We know even the most sophisticated controls will eventually fail, therefore when that happens it is important to make sure threats are contained and operations restored as quickly as possible.
We try to help you deal with the detection and response challenges by establishing partnerships with leading security vendors and with the recovery challenge by building software operators to automate common actions across the most popular open-source applications.
From vulnerability management platforms like Tenable Nessus to malware detection systems like Microsoft Defender, to infrastructure security tools like Aqua Security, Canonical has a long history of collaborating with leading cybersecurity vendors to make sure they understand the inner workings of our systems (and hence are good at distinguishing normal from unexpected behaviour) and they are aware of all the available patches and vulnerabilities.
Rebuilding infrastructure is often the biggest challenge after a breach. Operational knowledge is often concentrated in a handful of key individuals and the large number of manual steps involved also means that the process is lengthy and leads to inconsistent results.
With Juju and charmed operators administrators can take back control of their environments. Charms make it easy not only to redeploy complex systems, but also to manage all the day 2 operations like backups, scaling and recovery. Encoding operational knowledge in software also means that less administrators need to have access to the environments, effectively reducing the attack surface area and increasing security.
And remember that Security fails at the integration
In maths 1 + 1 always equals 2, however when it comes down to cybersecurity that’s not always the case. Combining 2 products that are individually secure does not guarantee that the resulting system will be secure too. Likewise, if a product has a vulnerability it does not automatically mean that the combined system can be compromised.
Organisations and cyber security practitioners are often guilty of talking about the security features of their products as if they existed in isolation or as if they were deployed in clean, greenfield environments. The reality, however, looks very different: all new infrastructure needs to coexist and integrate with a lot of other systems, including legacy, outdated ones. The only viable approach is defence in depth.
At Canonical this need is on top of mind: we have a vertically integrated offering that covers everything from the OS you deploy on bare metal to container images and application automation with Juju. When testing for open source security and reliability we make sure that our products not only perform well on their own, but they work even better when deployed alongside each other.
We also realise that it is unrealistic for any company to run all their infrastructure entirely on Canonical products. This is why we think of the infrastructure stack as a big Jenga tower. If you remove a block from the top, a few others might fall. However if you try to remove one from the bottom the chances of the entire tower toppling over are exponentially higher.
Everything is connected and that’s why we invest heavily in confinement at the infrastructure, containers and OS layer to limit the likelihood of issues spreading to several layers of the stack.