CIOs are increasingly concerned about cloud security. And they should be. With the recent outbreak of visible breaches at high-profile organizations like Target, Anthem, and others, and the subsequent damage they cause, corporations are scrambling to make sure their cloud applications, whether on private, public, or hybrid clouds, are safe.

But cloud security is complex. With ephemeral applications and services springing up around multiple data centers, with dozens or hundreds of independent microservices each with their own access mechanisms, with the widespread adoption of virtualization and the recent rampant frenzy over containerization, keeping on top of cloud-specific security vulnerabilities is a huge effort.

Here we'll look at a handful of high-level cloud security concerns that keep security folks up at night.

1. Transparency is crucial.
Transparency is highly valued: customers are beginning to demand complete transparency from cloud providers. For example, an IaaS/PaaS provider must be able to immediately expose fine-grained security specs and details for the entire stack including software versions, patch levels, firewall rules, tracking server snapshots, and user access rights. Many organizations have a long way to go in this area. It's often almost impossible to simply get a "count" of the number of systems in use, let alone their specific configurations, location, user profiles, etc.

2. Regulations can't keep up.
Regulations, processes, standards, practices, and mindsets from thirty years ago are still driving the industries, yet the landscape is nothing like the static, vertical, stationary non-distributed world of thirty years ago. Now apps and services are distributed, highly dynamic, coming and going across data centers, and technology is moving way too fast. Meanwhile, regulations by nature move and adapt at a glacial pace, and are just not able to keep up. As a result, the regulators find it almost impossible to keep up. This gets more challenging with cross-industry apps and services, such as a database service that stores both financial and medical data. It gets much more complex and challenging when dealing with global markets where regulations for each country/region can differ.

3. You need continuous real-time security audits.
Many corporations invest in very thorough, one-time "snapshot" security audits. This is the completely wrong approach. A security audit should be considered as a long-term, ongoing, real-time, continuous process. Instead of performing a security audit every six months, it should be performed every minute. This requires continuous monitoring and continuous assurance. And the audit procedure needs to adapt with the evolution of the overall system.

4. The academic world is innovating but out of touch.
Tons of security innovation is happening in the academic world and they are devising all sorts of ultra-secure protocols, tools, patterns, practices (e.g., self-healing networks, self-defending networks, advanced cryptography, etc.). But the academic world is detached from the corporate world, and the corporate world is unable to take advantage of the academic innovations due to legacy processes, existing requirements, hardware, customers, regulations, and other limitations. A very basic example of this is that academic research rarely pays attention to security audits, which are a crucial piece of overall security strategies.

5. Not looking at the big picture.
Many organizations expend effort securing individual systems, VMs, devices, or apps but fail to look at the big picture and the interrelations between their entire fleet of endpoints, services, processes, apps, devices, etc. The whole is much more complex than the parts, but often this is overlooked.

6. Mobile/BYOD brings additional challenges.
Mobile and BYOD ("bring your own device") are introducing considerable complexity and security vulnerabilities. For example, someone using a phone/tablet is both a personal consumer and a corporate user. Should these be distinct? For example if I bring my phone to work, am I restricted to accessing only work email, and not personal email, Facebook, etc.? There are efforts underway to enable "dual-personality" devices that switch between "corporate" and "personal" modes, which have completely different data-access requirements. One way to solve this is using a hypervisor/container that runs in a smart phone which can be booted up when an employee arrives to work. The end result is a completely new OS running on a device when in the work environment, with no overlap between personal and work environments.

7. Bare-metal security features are not available in virtual world.
Security apps benefit from using hardware acceleration and other bare-metal features for encryption, entropy, and performance, not to mention actual physical isolation. Yet most modern cloud apps are virtualized and thus unable to make use of these hardware capabilities. Because of this and other reasons, some organizations are moving away from virtualization and running critical services and applications on bare-metal instead.

8. Difficult to harvest entropy in virtual environments.
Proper encryption systems rely on entropy. Virtualization takes away much of this entropy and this can introduce vulnerabilities if keys and seeds can be predicted. There are efforts to make "real" entropy available to underlying VMs, but this is a difficult problem.

9. Accidental key sharing in appliances.
In products that are delivered as VM appliances it's not uncommon to find VM templates that include a given key that ends up on every appliance instance. The challenge is to build a turn-key appliance with minimal or no configuration, but one that doesn't embed and expose sensitive information such as security keys and passwords. For example, Telefonica de Espana recently duplicated the same OS image across all their network devices, resulting in hundreds of thousands of devices sharing the same keys.

10. Leave security implementations to the experts.
Security is really hard and requires expert knowledge to properly safeguard systems, yet way too many developers with minimal security expertise/experience are building "secure" products with vulnerabilities due to lack of deep understanding. Bottom line: security implementations should be left to security experts then made available to general app developers in the form of libraries, tools, services, apps, frameworks, practices, and underlying architecture features.

11. Data partitioning for hybrid clouds.
In hybrid cloud scenarios data must be partitioned so that highly sensitive data is treated differently from "somewhat sensitive" data and "not sensitive" data. Non-critical data can live in the public cloud while highly protected/regulated data must remain behind the firewall.

12. Do consumers care?
Many consumers don't care about (read: are not willing to pay for) security features, instead relying on consumer protection processes (e.g., dispute credit card transactions) or luck (why pay more for security if the odds are so low that I will be attacked). This puts the burden of the cost on the providers, and therefore if the consumer is not demanding it, there is less motivation to secure products.

13. Products can end up being used in industries they aren't designed for.
Products and companies that work with Big Data (analytics, etc.) can suddenly find themselves in regulated industries with no experience or understanding of how to interpret or comply with the regulations. For example, an analytics product designed for entertainment (few regulations) might find itself being used for healthcare data (many regulations).

14. Security guarantees are impossible to "prove."
It's basically an intractable problem to provide proof that a system, app, process, tool, or service is "secure." It's equally challenging to provide security assurances to end users who have no clue about security concepts and assurances that rely on understanding technical concepts that are completely out of reach to most users. For example, Public Key Infrastructure (PKI) is a relatively simple concept but very difficult to describe to a layperson.

15. Containers and portable VM snapshots are too portable.
VM images/snapshots are easy to create and transport around the world. Often this happens automatically. But a VM image that is compliant with U.S. regulations could violate European regulations if it was spun up in Norway. This obviously applies to backups and Docker images too.

16. Encryption efforts are vulnerable if physical access to a machine is available.
Physical access to hardware can circumvent many encryption efforts. For example, with additional hardware, memory can be analyzed on the fly to extract keys and plain text. Some companies, like PrivateCore, are working on decreasing the "security perimeter" to include only the CPU so that all encryption/decryption (including key management and ephemeral key generation) happens on the CPU. Clear-text never shows up in memory, on disk, or on the network, but is only decrypted by in the CPU itself.

17. Controlling physical access to the data center is not enough.
Systems can be made vulnerable in the supply chain. For example, at an overseas manufacturing plant, additional hardware might be surreptitiously added to a server, providing a back door that is almost undetectable after the server is deployed to a data center.

18. Privacy and security are at odds.
Privacy, trust, anonymity, right to be forgotten: these are highly elusive and can conflict with security goals. For example, I am confident that my data on Google is quite secure, given that Google has a world-class security team dedicated to ensure their data is not compromised. But is my data private? And what if I want to remove it entirely. Not an easy task. Today the "right to be forgotten" is akin to the right to "getting your virginity back." This is just the tip of the iceberg. I have barely mentioned the security issues brought to the table by containerization mechanisms like Docker, nor the complexities inherent in hybrid cloud and microservices.

The Good News
Fortunately there is good news, in the form of PaaS. A secure platform goes a long way to enabling secure applications. As stated above in point #11, it makes sense to leave security implementations to the experts. PaaS providers are experts when it comes to securing their platform, and leaving some of the security effort to the PaaS allows the product team to focus on the product, not get mired into the subtleties of security protection.

Stackato, ActiveState's enterprise hardened Cloud Foundry PaaS, takes several measures to bulletproof the cloud, securing both hosted applications as well as the underlying computing environment. Full multi-tenancy support, SSL everywhere, integration with external authentication providers like LDAP, and role-based access control ensure that your cloud apps, and the cloud are locked down.

Additionally, Stackato employs Linux containers, via Docker, to segregate applications and PaaS components, providing all the operational integrity inherent in LXC such as process, memory, disk, user, and network isolation. And our App Armor layer, on top of Docker, provides additional protection against compromises. See our Security White Paper for more information.

Summary
Security in the cloud has its challenges for sure, but the cloud is the direction that promises greater efficiency for Enterprise IT. PaaS may not be the magic bullet, but it does go a long way toward improving application security by leaving many security concerns to the experts.

The post Locking Down the Cloud: 18 Security Issues Faced by Enterprise IT appeared first on ActiveState.