A free, open-source platform, OpenStack was created with the ambitious target of giving infrastructure-as-a-service to consumers in a rapid, self-serve manner. It is now one of the most popular open-source cloud projects with the likes of eBay and Walmart relying on its framework.
Speed and simplicity were essential throughout OpenStack’s development, with users now easily able to manage it through a web-based dashboard, command-line tools, or through a RESTful API. Security, however, took a backseat until recent incidents such as the VENOM breakout and Heartbleed SSL-related flaw gave rise to no small discussion around its ability to keep data safe as a cloud platform. Safety had apparently been sacrificed for speed and efficiency at the development stage.In OpenStack, safety had apparently been sacrificed for speed and efficiency at the development stageClick To Tweet
That said, when assessing the relative security of OpenStack it is important to remember that the inevitable complexity of public computing, which introduces many layers of interacting technology, is part of the reason security issues are evolving so quickly and tend to introduce many difficult cloud issues.
OpenStack is relatively new code. Therefore is likely to contain numerous software vulnerabilities and implementation issues, which continue to be uncovered by the OpenStack community. However with specific portals and projects devised to tackle emerging security issues head on, it the OpenStack community appears to be taking security concerns quite seriously.
the OpenStack community appears to be taking security concerns quite seriously
At the highest-level, general implementation-based vulnerabilities do exist such as clear text RPC communications and the use of plaintext passwords in some of the authentication files. In addition to this, the reliance of OpenStack on other components can pose an issue. For example, if your team were to use an old version of OpenSSL that suffers from Heartbleed, your organisation’s OpenStack implementation may be affected as well.
Staying aware of the latest vulnerabilities and advice on what to do can be found on the community’s security portal, security.openstack.com. This page will make sure users know of the latest security patches. You can even track the open software flaws, based on Common Vulnerabilities and Exposure (CVE).
The OpenStack Security Project attempts to tackle security directly, and allows the community to share and report vulnerabilities so they get fixed. The security guide is also a great tool for users as it acknowledges some of the security issues around implementing OpenStack and helps to deploy the platform in the most secure manner.
Despite the fact that OpenStack is a “cloud” computing platform, it still helps in managing real servers that physically exist somewhere, sending traffic on real networks. Therefore, all the normal, relevant security controls should be considered; (firewalls, IPS, anti-malware, WAD etc.). In certain cases, OpenStack even offers APIs that can help you apply traditional security controls (such as network IPS via the Networking API) using this new cloud model. As with anything, CTO/CIO’s will also need to make sure the OpenStack software is properly marinated and updated regularly.
Auditing your system regularly on a set schedule is an absolute necessity to stand any chance of finding vulnerabilities before they are exploited. Make sure you prioritise any potential exploits based on severity and real-world impact; there may well be cases where a vulnerability could be devastating but simply isn’t accessible in your company’s implementation.
One other tip here is to make sure you track the time it takes your team to close or mitigate the threat. They should be closing high priority or severe vulnerabilities quicker over time.
All in all, OpenStack is an amazing platform with tons of potential in the enterprise realm. As with all new technology platforms, however, data breaches are happening at a staggering rate and the first question that every CTO/CIO should ask themselves before implementing is how secure can I make this network?
every CTO/CIO should ask themselves before implementing, how secure can I make this network?