Automating Cloud Security

You’ve reached an archived blog post that may be out of date. Please visit the blog homepage for the most current posts.

Verizon’s 2013 Data Breach Investigations Report trumpets the fact that security issues are still a major concern for all IT organizations. For many enterprises, the move to cloud computing raises new or additional security concerns, but when applications and infrastructure are architected with attention to security, cloud platforms can be just as secure as those on-premises.

Cloud applications are subject to the same security concerns as those that run on-premises. Poor application security can lead to injection attacks. Poor configuration can lead to the compromise of systems and applications. And of course poor behavior on the part of users can lead to compromised credentials.

According to the Verizon report, the impetus behind most attacks is personal or financial gain. Stolen user data remains the primary threat, and much of the hacking and malware seeks to exploit weak login credentials. Among the statistics cited:

  • 75 percent of victims were targets of opportunity rather than victims of organized criminal activity
  • 78 percent of attacks were of low difficulty
  • 66 percent of breaches took months or more to discover
  • 69 percent of incidents were discovered by external parties

How do you architect cloud applications to avoid common security pitfalls? First, you have to understand where the problems may lie.

Securing Data Where It Lives

Data is typically exposed in one of three states: in transit, at rest, or in process.

You can’t guarantee the path your in-transit data will take if it traverses the public Internet, so you must protect it to keep it private, especially if regulatory or contractual requirements require you to do so. Solutions such as application transport-layer security (using protocols such as SSL and TLS), virtual private networks (VPN), or custom application-level security can keep miscreants from sniffing your data, modifying it, or injecting new data in transit.

Data at rest is subject to the same threats as data in transit. In the cloud, hackers may try to break into the file systems of running instances, into unattached virtual-disk storage such as Amazon Web Services’ (AWS) Elastic Block Storage (EBS) and OpenStack’s Cinder, and into other storage options, such as AWS Simple Storage Service (S3) and Rackspace’s Cloud Files. To protect data at rest, change the default credentials of all of your systems, use the access control lists (ACL) provided by the operating system or cloud API, and implement encryption along with key management.

The final state, in process, includes data in the memory of an instance, which might be available to accounts with privileged access. To protect it, limit administrative privileges on user accounts. If you’re running a private cloud, protect the hypervisor running each instance.

For all cases, the Verizon report recommends eliminating unnecessary data and keeping tabs on what’s left. Ensure that essential controls are met and regularly check that they remain so. And work on better and faster detection.

Employing Security Automation

How do you keep your cloud instances secure? Security automation helps you code in the practices that make your data meet your organization’s security policy. It includes identifying vulnerabilities on running instances, as well as patching those vulnerabilities.

Security automation starts with application design. Consider the requirements for access to data in transit, at rest, and in process. For example, how will you handle the keys for SSL or TLS or other encryption for data in transit? And if your data at rest is in a database, can you use the database’s native security or must you provide for security in the application?

What services need to be exposed to either trusted or untrusted parties, and what services are used only internally? Any services exposed to untrusted parties will require vulnerability management and diligence in patching. Even with trusted parties, you need to verify the security of your data and connection.

Document everything so you know the specific operating systems and instances that all of your services and applications are running on. Diagram network and application flows, including ports, protocols, and directions. And map out the roles required to access all parts of the system.

Enhancing Cloud Security

RightScale can help enhance cloud security by making sure that system and application configuration does not expose data. With RightScale you can require data to be stored and transmitted securely.

In RightScale, the top of the configuration hierarchy is a ServerTemplate™, which defines a conceptual entity, such as an application server for Microsoft Internet Information Server (IIS) or a database manager for MySQL. ServerTemplates abstract the role and behavior of a server, making each server cloud-agnostic and portable between cloud providers.

ServerTemplates use RightScripts™ or Chef recipes to configure instances at boot time and perform operations during the lifetime of an instance, such as backing up databases on demand. They also depend on MultiCloud Images™ (MCI), which encapsulate machine images for multiple cloud platforms to give organizations a consistent experience across cloud vendors.

At the base level of the hierarchy are image objects that each represents one machine configuration in one cloud, such as an AWS Amazon Machine Image (AMI) or Windows Azure virtual hard disk (VHD). RightScale by default uses secure RightImages™ — machine images bundled with applications and a RightLink™ agent that provides communication between RightScale and cloud servers.

Securing Developers

You can restrict developers’ permissions to work on ServerTemplates according to their user roles. For instance:


  • Users with the “designer” role can modify ServerTemplates but can’t influence cloud resources, and therefore aren’t a threat to data at rest or in-process.
  • Users with “actor” can run servers and influence cloud resources but only within the bounds permitted by ServerTemplate designers, and therefore they are not a direct threat, provided that the ServerTemplates have been authored well.
  • Users with “server_login” can access instances and bypass controls established by designers or actors but lack superuser privileges. Designers can craft their ServerTemplates with this in mind to limit the risk.
  • Users with “server_superuser” can access instances as a superuser and bypass all controls.

For best security you should practice separation of privilege, minimizing the number of users who have more than one of these roles. To avoid hamstringing development or operations, you can use multiple RightScale accounts (and multiple cloud accounts) to partition resources between development and production environments. Be lax with privilege in the development account but strict with privilege in the production account. The granting of “server_superuser” should be strictly limited!

RightScale checks RightImages, MCIs, and ServerTemplates for security issues and stores them in a trusted, frozen repository, so you can be sure that any cloud instances you spin up under RightScale are built on a secure foundation. You can then use third-party tools on running instances for things like port and service scans, vulnerability scans, and application testing. Examples of such tools include those from CloudPassage for vulnerability management and security event monitoring and TrendMicro for securing data at rest.

The bottom line is that RightScale gives you all the tools to design your cloud application with security in mind. To keep your application secure once it’s running, validate the configuration and use tools to identify vulnerabilities and monitor the application, then patch any flaws you find. If you do that, you’ve taken important steps toward maintaining cloud security for your organization.