RISKS LURKING IN THE CLOUD

Cloud computing offers lots of advantages for application services, including time to market, increased availability and scalability, and ease of management. When it comes to security, however, the cloud introduces new complexities. As use of public cloud infrastructure increases, how can organizations ensure their information is safeguarded?

If you rewound to a few years ago you would hear a lot of naysaying about running critical applications in the public cloud. Data privacy and security were huge concerns with some security regulations forbidding certain applications from running in these environments. As cloud computing has matured, both infrastructure and native security services are more readily available. Migration to the public cloud has become more a matter of “when” than “if.” In fact, in this year’s survey 44% of respondents said their organizations have deployed production of customer-facing applications on public cloud infrastructure. What’s more, 25% are running mission-critical applications in public clouds.

Traditional security practices build on the assumption that every network has a perimeter. Thus, if you implement the right controls in the right places, you need only wait for events to detect and prevent. Not so in the cloud. Today’s information networks are amorphous and highly distributed. Just as the new “perimeter” has become dynamic and adaptive, so must the security that protects it.

In most cloud deployments, users have limited visibility to the underlying infrastructure—rendering them dependent on their provider for security. Indeed, 51% of organizations rely on the cloud provider’s security controls whether using their defaults (32%) or tailoring the configuration (19%). Even so, several aspects of any application, including configuration and access management, are user responsibilities. This model of shared responsibility raises several key questions:

Where is the liability border? For many organizations this question can be difficult to answer. Distributed cloud architectures and combinations of virtual network elements and native, cloud-owned services make the lines blurry at best. At worst, lack of clarity can lead to insufficient focus on certain areas and, ultimately, costly errors.

How does the security management and monitoring model need to change? Many organizations are unsure whether the systems they use for company-owned data centers are the best choice for generating visibility, detecting breaches and monitoring security in public clouds. Answers to that question have security, operational and budgetary implications.

Does a cloud deployment shrink or expand the attack surface for our business applications?

The general notion is that attack surfaces become smaller when using more mature cloud providers. Each enterprise’s response to this question will depend not only on the provider but also on how well the organization adapts its policies and tools to the new scenario.

Hackers Take a Walk in the Cloud

The fictitious organization’s environment is an application running several instances within a public cloud’s virtual private cloud (VPC). The application interacts with databases, cloud services and application servers (see Figure 59). At the same time, developers are continuously updating and integrating new capabilities into the environment. Consequently, they have special access to certain areas of the environment to enable their work.

This security scenario starts with a spear phishing attack targeting a developer within the organization. The developer takes the bait, thereby allowing the hackers to obtain credentials to the developer’s Amazon Web Services (AWS) account. Such a breach can have several variations—all ending in the attackers gaining access either to account credentials or to API keys. Subsequently, attackers can access the AWS API environment directly and fully circumvent the organization’s corporate network.

The hackers now seek to understand what exactly they won—enumerating permissions associated with the account by attempting several API calls toward the AWS API. Unfortunately, the hackers discover that the account does not provide the ability to perform many operations or changes within the environment. However, the hackers find a couple of interesting actions that are permitted, such as describing instances and creating instances of a certain type. The hackers begin to describe instances and, with the network structure at hand, continue to the next step of their nefarious plan.

The first command worked well so the hackers try another, creating an instance within the VPC that they can control. The hackers can tell that this instance has a higher-privilege role than previous credentials. The new instance provides access to map even more parts of the network as they scan through and discover additional instances and entities.

That’s when the hackers hit pay dirt—an instance running Apache Tomcat with a vulnerable version of Struts. Because this server is not accessible from the outside world it has not yet been patched. The hackers exploit the vulnerability to deploy a backdoor on the server. With control of the web server they try to access the database storing personal data about application users. The database is now accessible using the server context and opens the doors for the hackers to find and read plenty of interesting information. These hackers are patient and methodical. The hackers upload the data to their location of choice so slowly that the changes in communication patterns are too slight to be noticed.

This “walk in the cloud” is not a far-fetched scenario. On the contrary, it is a fictitious yet realistic scenario that reveals how a series of issues, including several configuration errors in the network, enable hackers to breach an environment. What’s interesting about this illustration is that each of the problems occurs in a different part of the environment—in the AWS API, the internal network, the application itself and, finally, its data store.