Last month we explored the pros and cons of open-source OpenStack, a platform I admittedly love, but which is not meant for everyone (for reasons laid out in that post). Today the topic shifts to OpenStack security. Why security? Because security is not only a hot media topic, but also one that automatically forces the CIO/CTO to analyze his or her own security situation within the organization. Is your open-source OpenStack network secure?
OpenStack is a framework that had a lofty goal of providing infrastructure resources to consumers (developers, end users, business units) in a rapid, self-service manner. This singular, self-serve aspect is what has made the platform so popular. The need for security with OpenStack, however, wasn’t addressed until much later, after it had become a clear problem internally. It was a classic technology afterthought — sacrificing safety for speed and efficiency.
Though I’m deeply versed in security, I’m not a day-to-day expert on the matter. That’s why I have decided to bring in some assistance with this post in the form of security industry influencer and subject matter expert Corey Nachreiner, the CTO at Watchguard. So without further ado here is my Q&A about OpenStack security with Nachreiner:
What vulnerabilities currently exist in open source OpenStack? In short, OpenStack is relatively new code. It surely contains many software vulnerabilities and implementation issues that the community will continue to uncover over time. The good news is the OpenStack community seems to be taking security seriously, with specific portals and projects designed to tackle security issues head on. Plus as an open-source product, anyone can track the open software flaws here, based on Common Vulnerabilities and Exposure (CVE).
At the highest-level, though, various general and implementation-based vulnerabilities can and do exist. For instance, the use of plaintext passwords in some of the authentication files, or clear text RPC communications. One can also introduce vulnerabilities based on the organization’s configuration of OpenStack. Furthermore, OpenStack relies on other components as well. So, for example, if your team uses an old version of OpenSSL that suffers from Heartbleed, or another similar SSL vulnerability, your organization’s OpenStack implementation may be affected as well.
Does the OpenStack Security Project properly address threats and prepare its community of users? I believe it does. At the very least, this group is tackling security head on, and sharing a procedural way for the community to report vulnerabilities so they get fixed. I also think the security guide is a great tool that acknowledges some of the security issues around implementing OpenStack, and helps its users try deploy in the most secure manner.
How should OpenStack users stay abreast of emerging threats? Security.openstack.com, the community’s security portal, is probably the best place to stay aware of the latest vulnerability notes, or advisories. This page will make sure users know of the latest security patches. Those developer types that really want to stay ahead of the curve can actually follow some of the CVE-related bugs on Launchpad, or simply join the OpenStack mailing list.
Is cycle time for future OpenStack platform improvements moving fast enough to keep up with new security concerns? That’s hard to say, as it’s a relatively new project. However, based on OpenStack’s security project and detailed vulnerability-handling procedure, and even its security guide, I do think OpenStack is making a best effort to secure the platform as quickly as it can. That said, the complexity of public and hybrid cloud computing, which introduces many layers of interacting technology, is part of the reason security issues are evolving so quickly. These complex technologies, which often bridge the separation between trust domains, introduce many hard-to-solve security issues.
Defense in depth: How deep (layers, tools, techniques) should a CTO/CIO consider going? Even though OpenStack is a “cloud” computing platform, it still helps organizations manage real servers that physically exist somewhere, and sends traffic on real networks. In short, a technology executive should still consider full defense in depth, using all the normal relevant security controls (firewalls, IPS, anti-malware, WAD). In some cases, OpenStack even offers APIs that can help you apply traditional security controls (like network IPS via the Networking API) using this new cloud model. Your images and physical servers still need protections — now users also need to make sure the OpenStack software is updated and properly maintained. In my opinion, OpenStack doesn’t remove any attack surface (the physical and virtual machines still have their own flaws); it just introduces the potential of new attack surfaces.
Are four domains — OpenStack cloud: public, guest, management and data networks — enough? These four domains are OpenStack’s way of discussing how its own modules interact, and sometimes bridge domains, but a CTO/CIO can’t forget there are many other systems interacting with the OpenStack platform as well — the physical machines, the virtual images, the hypervisor, the software running on individual machines, etc. The Cloud Security Alliance (CSA) has something called the Cloud Controls Matrix, which offers 16 domains that cloud providers need to consider to create a secure environment. Whether or not users are implementing OpenStack securely, they need to consider all these domains, and their full environment.
What considerations should be adopted for vulnerability metrics and tracking? In short, users need to audit the system regularly, on a set schedule, in order to find vulnerabilities. Make sure to prioritize them based on severity, but also real-world impact. For instance, there are cases where a vulnerability could have a severe impact, but in your company’s implementation it’s not easily exploitable. Those instances may not hold as high a priority to your team. Finally, track the time to close or mitigate the vulnerability. Your team should be closing high priority or severe vulnerabilities quicker over time.
And there you have it. Open-source OpenStack is, in my opinion, an amazing platform with tons of potential in the enterprise realm. As with all new technology platforms, however, the first question that every CTO/CIO should ask themselves before implementing is, ‘How secure can I make this network?’ Data breaches are happening at a staggering rate. Protecting that data should be every technology executive’s top priority, but then not all CTO/CIO types are security experts. Thanks to people like Nachreiner, they don’t need to be.
This article is published as part of the IDG Contributor Network. Want to Join?