Enterprise cloud security best practices for locking down your cloud
A comprehensive collection of articles, videos and more, hand-picked by our editors
Security and IT managers often ask about the security of open source cloud infrastructure: whether it's possible to secure them and, if so, how to specifically go about it. It's not difficult to see why they're asking this question. The popularity of open source cloud services (particularly Infrastructure as a Service, or IaaS) built using open source technologies is on the rise; with its increased usage comes an increased interest in keeping those technologies secured.
There are some areas where open source options can be better than proprietary counterparts when it comes to cloud security, despite fears in the industry to the contrary.
According to Zenoss' "State of Open Source Cloud" survey released in October 2012, approximately 18% of enterprises are already using open source cloud, and about 41% of respondents indicated expectations of doing so in the next two years. Why aren't there more adopters, more quickly? Security was one of the top reasons, as nearly three of every 10 respondents cited security as a factor for delaying deployment.
Based on these survey results, it should be clear that security matters for open source cloud. But asking "How do you secure open source cloud" is a bit like asking "How do I secure FreeBSD, Apache and OpenOffice?" While it's true that these technologies are open source, the differences are apples and oranges. They're different products that do different things (these particular three don't even have licenses in common) and as you'd expect, there are significant differences in how you'd secure them.
The same is true when it comes to securing open source cloud. The specifics of securing any particular environment will vary depending on a number of factors: what technology is used, how it's used, as well as a number of enterprise-specific factors such as regulatory context, risk tolerance, proposed use case, user population and internal vs. external facing deployment (to name just a few.) That said, there are some general steps that can be taken to "bake in" security to an open source cloud deployment. In fact, depending on the approach, open source cloud platforms can even offer advantages from a security standpoint.
Open source alternatives
As mentioned, there isn't just one open source cloud -- just like there isn't only one open source OS. There are a number of different initiatives all aimed at solving a different (though sometimes overlapping) subset of cloud computing needs. In the IaaS space, leading initiatives include OpenStack and CloudStack; these technologies allow organizations to integrate existing virtualization technologies into a more comprehensive, better-managed whole -- with all the cloud features of an industrial-strength platform (self-service provisioning, scalable storage, flexible networking and so on). They can be the foundation for an internal private cloud deployment, or used to build a service offering at a cloud services provider.
Eucalyptus is also centered on IaaS, but its focus is different: In its case, the primary intent is to bring AWS compatibility to private and hybrid clouds. Cloud Foundry is similarly focused on bringing openness, but instead of focusing on IaaS it's focus is on Platform as a Service (PaaS) -- attempting to decrease "vendor lock-in" that can occur when code is written to a proprietary vendor PaaS application programming interface (API). Obviously, given the breadth of these various efforts, the specific technical-level controls each organization will employ to secure them varies based on their particular technology selection.
Understanding advantages and disadvantages
There are some areas where open source options can be better than proprietary counterparts when it comes to cloud security -- despite fears in the industry to the contrary. Notably, the underlying code base for open source options is transparent. Transparent doesn't necessarily equal secure, but just like availability of source code can help foster better-audited code in other open source contexts (like, for example, in OS and Web server efforts), it can do so here as well. Also, the software is designed to be open, which prevents vendor lock-in. Being locked into a particular vendor can sometimes inhibit the security of an environment; for example, vendor-initiated changes to the service offering (such as changes in security controls) can decrease leverage in negotiations about security measures and controls -- not to mention availability considerations should the vendor become oversold.
There can also be some potential disadvantages in an open source solution. The perception in the industry of security issues in open source cloud can work against some efforts. For example, an auditor (or customer) may perceive the underlying software to be insecure simply because it is open source, which can have a chilling effect on adoption (at least in situations where this sort of bias exists). Additionally, there can be some supportability challenges. Those organizations that leverage, for example, the expertise of internal personnel to keep a private cloud deployment humming need to be aware that attrition of those personnel can have an effect on the existing environment; meaning, if there are a few engineers who know the environment really well and the organization lacks proper documentation or knowledge management, be prepared for a firestorm if those experts decide to leave.
Some things never change
Advantages and disadvantages aside, there are critical steps that must be undertaken to secure any cloud environment. These things don't change just because the underlying software is open source. Whether an enterprise is using open source to build an internal private cloud deployment, or moving to a service provider that has an offering built on open source, technical risks still need to be managed. It's vital to understand the risk profile of what is deployed into an environment, and select the controls that offset and manage those risks. Note that this is true no matter whether you use open source or whether you use a commercial product.
Security managers will also need to define responsibilities for who does what, from a security control operations and management standpoint. If it's a deployment at a cloud services provider, decide what areas of responsibility the service provider has from a security control standpoint vs. what the manager's team does. If it's an internal deployment, decide which internal group does what. Again, this would need to be done anyway for any cloud deployment, but for open source it is particularly important. There are some specific tasks that should be on a security manager's responsibility assignment list, such as monitoring for security issues in the product chosen, keeping the software up-to-date, and more.
About the author
Ed Moyle is a founding partner with New Hampshire-based information security and compliance consulting firm SecurityCurve. Moyle previously worked as a senior manager with CTG's global security practice, and prior to that served as vice president and information security officer to Merrill Lynch Investment Managers. In addition to his numerous contributions to Information Security magazine and SearchSecurity.com, Moyle is co-author of the book Cryptographic Libraries for Developersand is a frequent contributor to the information security industry as an author, expert speaker and analyst.