Last week I wrote the first part of this blog and I have already received some feedback. Many thanks for that. I pointed out that security increasingly became a question of risk management and I reviewed client security, the security aspects related with the network and the physical security of the datacenter. With every aspect, I tried looking at the actual risks associated with the information available at that level in the cloud chain. Now I’m going to look at the four remaining aspects— platform, application, data security as well as identity and access management. So, let’s get started.
A cloud platform includes the hardware and software required to provide any type of cloud service. It includes the resource management, the automation and orchestration, as well as the client interaction functions available in any cloud. These functions interact directly with the actual service functionality and with the user data. From that perspective these functions need to be secured because they provide access not simply to the information of a singular customer, but of all people using the cloud platform. So, a threat positioned at this level is many times more “profitable” to the hacker than capturing a block of information in the network.
So, what is required at this level? Actually many things are required. Let’s review the key ones. The provisioning of a service typically starts with the loading of a virtual machine image in memory. Where does that virtual machine image come from? It’s probably stored in an image repository, but some cloud providers allow users to upload their own virtual images. A couple years ago MIT and the University of California demonstrated that a virtual machine can launch an attack to ano... on the same physical server in Amazon for example. So, the virtual machine image needs to be scanned for viruses and other malware prior to be loaded in memory. Isolation of VM’s has to be hardened as much as possible etc. The behavior of VM’s should be checked and any strange behaviors should be stopped as soon as possible.
The operating system in the virtual machine may have security holes, so it must be checked for the latest patches. Have those been implemented, have all known holes been closed?
Once the VM is uploaded, automation may install applications and/or configure elements of the VM to deliver the service required. This is done through the use of workflows. There is a remote possibility of tempering the workflows to include malware or create backdoors for example. When and by whom has the workflow been updated? Is its repository secured etc.? All questions to ask.
The service will have access to data. Is that access secured? How is the data traveling between its repository and the application logic? This is often called data in-flight security. The service also interacts with the user. How secure is that connection? We discussed client security already, but let’s not forget that a client may be used as a platform to initiate a massive attack to a cloud platform. So isolating the tenants and ensuring they cannot hamper other tenants is critical to limit the damage of a possible attack. Intrusion detection is a critical element here. All this is the responsibility of the cloud platform security. Cloud platform security is complex and at the heart of the security provisions that need to be taken. Fortunately it’s an area where a lot of work has been done already and where we can build upon the experience of years of datacenter security.
Complementing platform security is application security; the actual security of the application logic underpinning the delivery of the service. Once configured in the virtual machine provisioned on the platform we just discussed, how do we ensure a malevolent user cannot reach the operating system and launch an attack from there?
Applications can also have security holes. It’s key to close as many of those as possible prior to taking the application in production. We do this by scanning source code to point out vulnerabilities that need to be addressed and simulating comprehensive attack scenarios to detect vulnerabilities in web applications and services. Performing these tasks helps you minimize the risk when taking the applications in production. Real-time analysis of the behavior of applications allows you to spot potential attacks quickly and act accordingly.
Obviously the objective is to minimize the risks of an attack, but things will happen. So it is also of the utmost importance to be able to react quickly.
Often data contains your most important assets. Data is also persistent, and is what hackers are after. , The ultimate objective is to get access to the data for industrial espionage or for criminal reasons. Such data can include credit card numbers, user passwords and personal information as well as companies’ private documents etc. Data has a lifecycle and we have to look at all stages in the lifecycle. Data is created, stored, used, moved, backed-up and finally deleted. Let’s leave deletion aside for a minute; data is usually “at rest” or “in flight”. Data can best be encrypted, and that makes it more difficult for unauthorized people to exploit the information. Access to data sources should be restricted through information rights management.
You want to make sure the data cannot be lost, storing multiple copies of the same data in different locations prevents loss. But it also makes data more vulnerable. Particularly when using public clouds, it’s important to understand where all the copies of your data are and who hosts them. You need to know what security precautions they have taken to ensure your data is safe.
Particular care should be taken when information from multiple tenants are co-located in the same database. The read and write mechanisms have to be hardened to ensure one tenant cannot get access to the data items from another tenant.
When you decide to remove the data—either by purging it or by ending the use of the service—you should make sure the data is properly removed from the systems; all copies of the data. This is called crypto-shredding. You do not want the next user to be able to recoup your data by scanning the surface of the disk space given to him.
Identity and Access Management
I kept identity and access management for the end, but this is where it all begins, isn’t it? How do I make sure the person logging into the system is authenticated. Again, nothing here is cloud specific, but the cloud makes it more complex. Particularly in a converged cloud environment where, using one set of credentials, I can get access to multiple cloud environments. It is absolutely key that, from the moment I am logged into the system, I can prove beyond reasonable doubt that I am who I say I am.
Federated identity facilitates the access to the services I consume, but at the same time concentrates my information in one place, that better be fully secured. But as a user I have the responsibility to ensure that my credentials are kept safe. The quality of my passwords and pins, and the physical security of my tokens are my responsibility. Often we forget that in many cases criminals get access to confidential information legally by using the identity of others. It is our responsibility to protect our information.
Cloud proponents actually point out cloud is more secure than traditional environments “if done right”. Moving to the cloud forces companies to rethink their security environment from the ground up to maintain compliance.
Actually it means Cloud Computing is only secure if the user practices vigilance, and uses the proper security measures such as encryption, monitoring and patching.
Security and Cloud
We started this discussion by asking ourselves whether we were missing the point when discussing security in cloud. We have a tendency to look at things individually, and then addressing each of the above aspects separately. That’s not the right way to look at things. We should take a comprehensive view and ask ourselves how a hacker can get maximum value with minimal investment. Where is the most vulnerable piece in the puzzle?
When using converged cloud we should start looking at the security-related information we have and where we lack transparency. Then we may want to weigh our options. Wharton University discusses the topic in its latest Knowledge@Wharton newsletter, confirming most hackers are criminals looking at where the money is. So the question you should ask yourself is—whether the information you put in the cloud has potential financial value to others, what that value is and how you can protect it? How much can you invest? What are the risks you are prepared to take?
In my next post, I’ll discuss some end-to-end scenarios showing how the aspects discussed have to be looked at jointly to get a reasonable risk profile of the service. Keep with me, and obviously don’t hesitate to comment on this blog or on the linkedIN discussion
Interested in more information, go to the HP security site