Heartbleed woke everyone up to the risks that open source software can pose if the management, development and design of the software isn’t up to par. Earlier this month OpenSSL released a roadmap the was very self-critical of the current state of the project and how they intend to get it back on track.
Realistically, who can blame the project? With just one full time employee and a mere $2,000 in donations per year compared to millions of OpenSSL deployments. But if you were a CISO purchasing software from a company with similar resources, it might be viewed as a risky move to say the least. The good news is some of the major tech companies are stepping in to provide better funding for the project through the Core Infrastructure Initiative and will greatly help OpenSSL and OpenSSH projects respectively.
Despite this, Google has decided to create a fork of the OpenSSL project named BoringSSL. Apparently managing over 70 patches - and a lot more expected in the future - made it difficult to maintain consistency across multiple code bases and is becoming a security issue. Google isn’t trying to upend open source it just simply needs a solution that works more efficiently and securely with its Android and Chrome products.
Like for Google, Heartbleed has been the trigger for many companies to reevaluate how they use and manage open source technologies – both in their products and within their organization. My pitch here isn’t that open source is bad – it can be very good and I use it all the time. Rather it’s a call to action for CISO’s asking them to take another look at the critical but often forgotten infrastructure that their business is riding on, especially when it is something as ubiquitous and critical as encryption technologies like SSL/TLS, SSH, etc.
Here are some key questions to ask:
- Does either a vendor or internal resources properly support my open source software or am I relying solely on someone’s good will?
- Are my enterprise open source technologies properly managed?
- Can I rapidly respond to vulnerabilities by rotating keys or updating to new versions?
- Do I know who is using what?
- Do I know who has access to what?
- Can I tell if someone has done something malicious?
For enterprises that use Secure Shell – which is pretty much everyone – here is a good place to start.