"Cloud" Security Recommendations

Security In The Cloud Is Still Just Security

A recent paper published in the International Journal of Services and Standards titled "A 'cloud-free' security model for cloud computing", written by Manal M. Yunis, outlines six security considerations for cloud computing. Upon reading the six considerations, I can't help but think that they do not present new challenges but merely rehash old ones. Let’s take a look at each of the six common cloud computing security considerations in more detail:

1. Resource Sharing

"On shared services, there is the possibility that another user on the same system may gain access inadvertently or deliberately to one's data, with potential for identity theft, fraud, or industrial sabotage."

The real problem with resource sharing in the context of cloud computing is that software logically separates one system from the next, but not physically. You can think of it as a "virtual server rack"; whereas traditionally you would have a physically separate server from your neighbor, but in the "cloud”, software is used to separate systems. Unfortunately, software is prone to vulnerabilities that could be exploited and in this case lead to complete access to your server or system. A great example of this in action is the "Cloudburst" exploit from the researchers at Immunity, Inc. that allows an attacker in a guest operating system to break out and gain access to the host operating system.

The resource sharing via software problem is similar to VLANs on switches that are controlled by software, requiring you to carefully design a network and be certain your most critical assets are not on the same switch as something less critical. This is a risk-based decision, and must be constantly evaluated whether you are using a "cloud" provider or designing VLANs on a switch.

2. Data Ownership

"Second, because data is held offsite, data ownership might be compromised."

This is another issue that I have dealt with when I worked for an ISP/hosting provider. Being physically separate from your data means that you need to make even more risk-based decisions in a cloud computing environment. If the data you are hosting off-site is public in any way, then there is less to be concerned about. However, if the data is sensitive or confidential, you may want to take extra precautions to safeguard it at remote sites (encryption, physical security, etc.). For example, the recommendation from the Cloud Computing Security Alliance is that "Customers should perform onsite inspections of cloud provider facilities whenever possible.".

What I struggle with is how this is different than using a remote storage facility for your backup tapes. Encryption of your sensitive data is an important safeguard, whether the data lives on a backup tape or "somewhere in the cloud". Almost equally as important as data encryption is ensuring that access to manage your cloud services is protected. While your data may be public, you would not want an attacker to have the ability to change your web site or use it to collect credentials.

3. Reduced Encryption in Favor of Speed

"Third, the intrinsic latency of transferring data back and forth for processing in the cloud means that some users might lower encryption levels to cut send and receive delays, giving rise to additional security concerns."

To combat this threat you must have a policy that defines what level of encryption to use on different types of data. Of course, this means you must classify the types of data. Unless the data has been identified and classified, you have no idea of the significance of the data. Once the data has been classified, you can more easily determine what needs to be encrypted and what does not. Some typical classifications are as follows:

• Patient Health Information
• Credit Card Data
• Client Financial Data
• Intellectual Property
• Material Non-public
• Business Critical Data
• Public information

Having a policy that states something along the lines of, "use the highest encryption level where feasible, and do not use encryption and/or hash functions that have known attacks against them" is a really good start. You will have to take performance into consideration, but certainly cloud computing is not the first new technology to challenge your encryption policy as your VPN users have most likely yearned for better performance.

Using Nessus audit files to ensure your systems are configured to use the highest encryption mechanism mandated by your security policy is a great way to ensure that all of your systems, including those in the "cloud", are protected and in line with policy.

4. Refusal of Services

"Fourth, the issue of Service Line Agreements (SLAs) may lead to an organization being refused access to data and services if there are technical, security or commercial disagreements between them and the cloud service provider."

I have run into this issue in the past and it really boils down to having good backups. Never put anything in the hands of a service provider (whether it’s a "cloud" provider or a provider of any other service) without first having a backup. Storage has become very inexpensive, so it costs little to keep a backup (when your data size can be measured in a few terabytes or less).

5. Data Loss Due To Technical Failure

"Fifth, data might be lost or otherwise compromised because of a technical or other failure on the part of the provider."

This has less to do with security and more to do with backups and disaster recovery planning. If you are keeping backups, or even running "hot sites", make sure they are part of your regular patching and vulnerability assessment schedule. Since they house an exact copy of your data and systems, they need the same level of protection and vulnerability management as your production systems.

6. Attackers May Go After the Provider or the Implementation

"Keep in mind that centralization of data means the risk of insider abuse from within the cloud provider is a significant concern."

Not only through insider abuse, which is a problem without question, what about an outside attack on the implementation or management interface? For example, I use a "cloud" provider and they provide me with a nice interface to manage all of my systems. If someone were to find vulnerabilities in the management application (e.g., XSS, CSRF) they could affect change on my systems. Vulnerabilities need to be managed and fixed within the "cloud" providers themselves. Nessus patch audits are available for VMware ESX server, which contains many vulnerabilities that could lead to attackers accessing your data or even taking ownership of your guest operating system!

Conclusion

My advice to those seeking cloud computing security guidance is if you relate it to similar security and risk decisions in your organization, I believe you will find that you are well equipped to securing your organization, whether it’s cloudy or sunny.

Resources

• "New model assesses various risks associated with relocating an organization's data and services to remote computer servers in the clouds"
• Audit the Cloud with Passive Scanning

Contributions by Carol Fennelly