Follow up: Cloud security

Since the publication of the last entry on cloud security, I received many emails from clients and colleagues who have an interest in this topic. Because of the sensitive nature of the topic, they chose to email me rather than leaving a comment here. I have synthesized and sanitized the feedback, and decided to publish the summary here:

a) Investigation support: A few responses stressed the importance of support for enterprise investigation. They  voiced frustration with the lack of timely response and technical support from some of the cloud vendors. One senior IT officer said: “For every investigation, I have to work with the vendor to get the data I want. They don’t have an option for me to be the administrator of my users’ data and logs. This goes against the self-service nature of cloud computing, and essentially takes away some of the benefits”.

b) Security and privacy are equally important for all layers of cloud, as customers may be buying a combination of  services (of different layers) from the same provider. The so-called “layers of cloud” include infrastructure-as-a-service(IAAS), platform-as-a-service (PAAS), and software-as-a-service (SAAS). Each layer may have its own unique challenge. 

c) Incident response and disclosure: Readers pointed out that you may want to know that a data breach has happened within the cloud environment even though your data may not be breached. This is a tough issue because from the users’ standpoint, you want to know the incidents so you can make an informed decision whether to stay with the cloud. But on the flip side, you may not want the provider to offer too much information to other clients if it were your data that were breached. There is no standard procedures today people follow for incident disclosures that impact other people’s data.

d) Compliance: Some compliance requirements demand that relevant data be encrypted both at rest and in transit. Many of the cloud providers do not support that and in some cases due to the way the application is configured, encryption by the customer of the cloud is also not an option. For instance, some cloud applications leave sensitive information in the database index, which is typically not encrypted even if the blocks are encrypted. In this case, having block-based encryption is clearly not sufficient.

About these ads

About Chenxi Wang

Dr. Chenxi Wang is a Principal Analyst with Forrester Research. She serves on the security and risk team, covering topics such as cloud security, application security, and content security. Previously Chenxi was Chief Scientist with KSR Inc. (now part of Neohapsis). Prior to that Chenxi was an Associate Professor at Carnegie Mellon University.
This entry was posted in Cloud security. Bookmark the permalink.

4 Responses to Follow up: Cloud security

  1. These look good, although application layer is not here. One of the black eyes for all the cloud standards docs being put together right now is the assumption that all applications can and are developed according to recommended standards. This just isn’t a reality today or in the near future. There are issues to contend with here that are worth exploring – what to do, how, without consuming resources and in a scalable manner. What’s the best use of hardware or software and at what layer should this be added? For example, what should we be recommending for companies using providers for overflow app support to make sure policy continues to the cloud hosting the overflow? I don’t think this issue is limited to public clouds either. Thoughts?

    • Chenxi Wang says:

      For the cloud security follow up note, you are right I didn’t list application security. However, application security is part of my original cloud security checklist, which I referenced in a previous post: “Cloud security front and center”. Application security is part of the cloud vulnerablity management: it doesn’t matter how many security controls they put in, if their infrastructure or applications are vulnerable, all bets are off. This issue is not limited to public clouds, you are absolutely correct. Application security is not even restricted to any particular cloud application either, because we’d always need good application security. As for the point of policy continuity for cloud-based overflow capacity, this goes to the provisioning process. How can one quickly establish and use capacity in the cloud for application overflow? Provisioning cloud capacity must include any necessary policy element including identity management, administrative policies, acceptable usage policies, etc. In some scenarios, the provisioning process can be as simple as integration with internal corporate directories, but it can be a whole lot more complex as well.

  2. Fi says:

    Hi
    All these items can be addressed in a separate Security SLA. BUT you have to install your own sensors and log parsers to be able to follow up that your provider really acts on security alerts/incidents

    • Chenxi Wang says:

      Here lies in the problem. Cloud providers will not allow you to install your own sensors and log parsers to ascertain that your provider truly acts on alerts/incidents. This is never going to be a standard practice. What we can get the cloud provider to agree on is perhaps an audit two or three times a year. Even that may be pushing it right now. But that’s why the community needs to band together and demand a certain level of visibility from the cloud vendors. A separate security SLA is a good idea but most customers of clouds do not know what to ask should a separate security SLA be on the table.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s