In 2014, a fundamental vulnerability in OpenSSL was made public in the worst way possible: by the creation of a vulnerability bug called Heartbleed. It’s an apt name, considering it is a “buffer over-read” vulnerability that specifically existed in the TLS implementation of heartbeat. This Heartbleed bug affected a majority of big tech players like Facebook, Google, Netflix, and Amazon’s AWS service.
Thankfully there hasn’t been any major breach using the bug, even though minor attacks have been seen in the wild. But companies around the world had to race to fix this issue, which often required going through a manual spreadsheet of their certificates to find affected servers.
Not only is that an incredibly intense process, but many companies still haven’t learned their lesson and refuse to move to an automated certificate management system. So, the question remains, what can we learn about certificate management in a post-Heartbleed world?
Actually use automation for certificates
It might seem obvious, but the first step of automating certificate management is actually automating the process. This means moving from the traditional approach of keeping licenses and certificates inside a spreadsheet. That practice was a major contributor to how effective Heartbleed was since it took a significant amount of time to find certificates and update them across servers and other devices. Unfortunately, according to this year’s PKI survey results, 36% of IT professionals are still using spreadsheets to manage their certificates – which is worrisome.
There are a variety of ways to automate certificate lifecycle management, including automating the certificate provisioning and enrollment process.
Support new and strong protocols
TLS support is essential for being able to avoid issues similar to those brought on by Heartbleed. Even more so, it’s important to move on from TLS 1.1 and TLS 1.2. Since TLS 1.3 came out there’s no real reason to maintain any of the older versions.
This is made more obvious by the fact that significant SSL/TLS certificate attacks often come and go, and that there is always a risk with the older version of protocols. So, deploy TLS 1.3 as soon as possible.
Take advantage of internal reviews
Since Heartbleed was based on an OpenSSL vulnerability, it’s important for organizations to conduct regular internal reviews of any open-source software they use. This can take a variety of forms, whether through dynamic or static analysis, but it should certainly include a large search of the web for little known-vulnerabilities. By staying ahead of the curve, companies can ensure that they don’t fall victim to overlooked vulnerabilities – after all, Heartbleed went overlooked for nearly two years.
Of course, not all companies have their own internal security teams, so you might consider hiring a freelancer or consulting agency to carry out the audit and to make your website and backend system secure. Organizations can expect to pay at least $60 an hour for an experienced developer, and it’s well worth the cost for peace of mind if you can find one with secure coding experience. Opening up an internal division is also an option, although a more costly one.
The importance of this step can’t be overstated, especially because of how most open-source libraries are built and the fact they aren’t cryptographically signed. There’s a reason why the global cybersecurity market is poised to reach nearly $420 billion by 2028, and it is partly due to these sorts of vulnerability oversights.
Imagine a company that develops its own software or service based on an open-source library that isn’t necessarily signed or is signed after being pushed to release. Vulnerabilities that potentially exist in open-source libraries are introduced into said company’s product, even if otherwise it’s cryptographically secure. The SolarWinds breach is a perfect example of how a vulnerability in one software spread out to other software that relied on it.
Support strong cryptographic ciphers and ephemeral key exchanges
Perfect Forward Secrecy, or PFS, is a cryptographic concept that revolves around long-term key security. Namely, it allows for legacy session keys to be secure even if certain key exchange sessions are compromised. Think of it as a self-sealing fuel tank – even though there is a breach, it doesn’t affect the overall integrity.
There’s actually a variety of protocols that use some form of PFS, such as IPsec and SSH, both of which are popular when it comes to messaging. You’ll also be happy to know that TLS 1.3 does not support ciphers without some form of forward secrecy, which is why it’s so important to deploy it as soon as possible.
Maintain a security-by-design culture
One major issue faced when it comes to any product development is the need to balance speed and security. Usually, this is the part where a lot of companies seem to cut corners on their CI/CD processes that maintain good cybersecurity. This is only going to get worse as cyberattacks become more advanced, so this is certainly not an issue that is going to go away by relying on others.
This is why having a strong culture that focuses on security as the fundamental building block is important. By building up your security well in advance, there won’t be a need to scramble to implement security measures in the middle of a crisis.
Organizations need to have a streamlined process for DevSecOps as well as good training and opportunity for skill growth in that niche. Similarly, a code-signing step should be integrated into the CI/CD process to help non-cybersecurity developers build their products with minimal interference or second-guessing.
Conclusion
Heartbleed redefined how we approach certificates and open-source libraries. That being said, many organizations have yet to move to a more modern system and approach development with a security focus. By adopting automated certificate management, organizations can respond much faster to these sorts of vulnerabilities and protect their systems and customer data.
Note: This blog article was written by a guest contributor for the purpose of offering a wider variety of content for our readers. The opinions expressed in this guest author article are solely those of the contributor and do not necessarily reflect those of GlobalSign.
