Exploring the Risks of Running in the Cloud

We’ve talked a bit about some of the factors that lead to security risks in the cloud environment. Now, we go into a little more detail about the specific kinds of risks you might face, beginning with the categories of security risks. According to the National Institute of Standards and Technology (NIST), a government standards body, computer systems are subject to many threats ranging from loss of data to loss of a whole computing facility because of fire or natural disaster. These losses can come from trusted employees or from hackers. NIST divides these risks into the following categories:

Errors and omissions including data errors or programming errors

Fraud and theft

Employee sabotage

Loss of physical infrastructure support

Malicious hackers

Malicious code

Threats to individual personal privacy

Many of the same security risks that companies face when dealing with their own computer systems are found in the cloud, but there are some important twists. The Cloud Security Alliance (CSA — http://cloudsecurity alliance.org), an organization dedicated to ensuring security best practices in the cloud, noted in its recent publication, “Security Guidance for Critical Areas of Focus in Cloud Computing,” that significant areas of operational security risk in the cloud include the following:

Traditional security: A hybrid cloud environment changes traditional security because you’re no longer totally in control. Some of the computing assets you’re using aren’t on your premises. Now, you must ensure that strong traditional security measures are being followed by your cloud provider. Traditional security includes

• Physical security covers security of IT equipment, network assets, and telecommunications infrastructure. CSA recommends both “active and passive” defenses for physical security (see the section, “Assess your cloud vendor,” which also includes equipment protection and location.

• Human resource security deals with the people side of the equation — ensuring background checks, confidentiality, and segregation of duties (that is, those who develop applications don’t operate them).

• Business continuity plans need to be part of any service level agreement (see Chapter 17 for more information on SLAs) to ensure that the provider meets its service level agreement for continuous operation with you.

• Disaster recovery plans must ensure that your assets (for example, data and applications) are protected.

Incident handling: A hybrid cloud environment changes incident handling in at least two ways. First, whereas you may have control over your own data center, if an incident occurs, you’ll need to work with your service provider, because the service provider controls at least part of the infrastructure. Second, the multi-tenant nature of the cloud often makes investigating an incident more complicated. For example, because information may be co-mingled, log analysis may be difficult, since your service provider is trying to maintain privacy. You need to find out how your service provider defines an incident and make sure you can negotiate how you’ll work with the provider to ensure that everyone is satisfied.

Application security: When an application is in the cloud, it’s exposed to every sort of security threat. The CSA divides application security into different areas, including securing the software development lifecycle in the cloud; authentication, authorization, and compliance; identity management, application authorization management (for updating application and the like), application monitoring, application penetration testing, and risk management.

Encryption and key management: Data encryption refers to a set of algorithms that can transform text into a form called cyphertext, which is an encrypted form of plain text that unauthorized parties can’t read. The recipient of an encrypted message uses a key that triggers the algorithm to decrypt the data and provide it in its original state to the authorized user. Therefore, you can encrypt data and ensure that only the intended recipient can decrypt it.

In the public cloud, some organizations may be tempted to encrypt all their information because they’re concerned about its movement to the cloud and how safe it is once it’s in the cloud. Recently, experts in the field have begun to consider other security measures besides encryption that can be used in the cloud. (We tackle a few of those security measures in the later section that deals with encryption options.)

Identity and access management: Identity management is a very broad topic that applies to many areas of the data center. The goal of identity management is to manage identity information so that access to computer resources, applications, data, and services is controlled properly. Identity management changes significantly in the cloud. In a traditional data center, you might use a directory service for authentication and then deploy the application in a firewall safe zone. The cloud often requires multiple forms of identity to ensure that access to resources is secure. (We also cover this topic in a bit more detail in the identity management section, later in this chapter.)

With the increasing use of cloud computing, wireless technology, and mobile devices, you no longer have well-defined boundaries regarding what is internal and what is external to your systems. On an ongoing basis, you must assess whether holes or vulnerabilities exist across servers, network, infrastructure components, and endpoints, and then continuously monitor them. In other words, you need to be able to trust your own infrastructure as well as a cloud provider’s.

Digging deeper into identity management

Identity management helps prevent security breaches and plays a significant role in helping a company meet IT security compliance regulations. In a cloud environment, where you don’t own the infrastructure and may not control the applications, you may need to think about identity management in a slightly different way. For example, the CSA notes that in the cloud, an identity isn’t just a person’s identity. Identities also exist for devices, code, and other resources that exist off-premises. The CSA notes, “It becomes necessary to identify all of the entities associated with a transaction.” A username and password simply aren’t enough. Perimeter security with a firewall isn’t enough.

In the cloud, identity and attributes (that is, facets of identity that link to the identity) can come from many systems. These facets may feed into an entitlement layer that contains the rules for authorization and access to the different layers at a provider’s site. These layers include the network layer, the system layer, the application layer, the data layer, and the process layer.

Think about the cloud. Machines can be decommissioned quickly and then brought up online again. New machines can be provisioned on the fly. Data can be moved to different machines when the need arises. Your company may want to communicate with different partners and cloud providers. All of this can affect security and identity management practices.

The Jericho Forum, part of the Open Group (www.opengroup.org ) that addresses the development of open, vendor-neutral IT standards and certifications, has recently published a set of principles called the Identity, Entitlement and Access Management (IdEA) Commandments. These best practices are meant to promote open and interoperable standards that can be used to help build strong identity management processes for systems, services, and data. Although not specifically developed for the cloud, they are meant to deal with systems that have become de-perimiterized (that is, where there is no hardened perimeter security because information is flowing between organizations). The cloud certainly falls into this category. There are 14 commandments, which include the following:

All core identities must be protected to ensure their secrecy and integrity.

Identifiers must be trustworthy.

The authoritative source of identity will be the unique identifier or credentials offered by the persona representing that entity.

An entity can have multiple separate personas (identities) and related unique identifiers.

A persona must, in specific use cases, be able to be seen as the same (that is, to substitute one persona for a currently interacting persona).

The attribute owner is responsible for the protection and appropriate disclosure of the attribute.

Connecting attributes to a persona must be easy and verifiable.

The source of the attribute should be as close to the authoritative source as possible.

A resource owner must define entitlement.

Access decisions must be relevant, valid, and bidirectional.

Users of an entity’s attributes are accountable for protecting the attributes.

Principals can delegate authority to another persona to act on behalf of a persona.

Authorized principals may acquire access to (seize) another entity’s persona.

A persona may represent, or be represented by, more than one entity.

For full descriptions of these Commandments, go to The Open Group website and enter Commandments in the Search box.

Understanding data protection options

Some experts believe that different kinds of data require different forms of protection and that, in some cases in a cloud environment, data encryption might, in fact, be overkill. You could encrypt everything. You could encrypt data, for example, when you write it to your own disk, when you send it to a cloud provider, and when you store it in a cloud provider’s database. You could encrypt at every layer.

Encrypting everything in a comprehensive way reduces your exposure; however, encryption poses a performance penalty. For example, many experts advise managing your own keys rather than letting a cloud provider do so, and that can become complicated. Keeping track of too many keys can be a nightmare. Additionally, encrypting everything can create other issues. For example, if you’re trying to encrypt data in a database, you will have to examine data as it’s moving (point-to-point encryption) and also while it’s being stored in the database. This procedure can be costly and complicated. Also, even when you think you’ve encrypted everything and you’re safe, that may not be the case.

One of the long-standing weaknesses with encryption strategies is that your data is at risk before and after it’s encrypted. For example, in a major data breach at Hannaford Supermarkets in 2008, the hackers hid in the network for months and were able to steal payment data when customers used their credit card at the point-of-sale. This breach took place before the data was encrypted.

Maintaining a large number of keys can be impractical, and managing the storing, archiving, and accessing of the keys is difficult. In order to alleviate this problem, generate and compute encryption keys as needed to reduce complexity and improve security.

Here are some other available data safeguarding techniques:

Anonymizing the data: When data is anonymized, all of the data that describes the data (called metadata) is removed. This might include someone’s name or Social Security number or address. Although this technique can protect some personal identification, hence privacy, you need to be really careful about the amount of information you strip out. If it’s not enough, hackers can still figure out who the data pertains to.

Tokenization: This technique protects sensitive data by replacing it with random tokens or alias values that mean nothing to someone who gains unauthorized access to this data. This technique decreases the chance that thieves could do anything with the data. Tokenization can protect credit card information, passwords, personal information, and the like. Some experts argue that it’s more secure than encryption.

Cloud database controls: In this technique, access controls are built into the database in order to protect the whole database so that each piece of data doesn’t need to be encrypted.