Cloud Security, let’s take an end-to-end look
My Identity
Let’s start with identity and access management. So, I am using a mobile device and access a cloud service. This may happen through the browser or through an application running in the mobile device. To get access to the service, I need to identify myself. How secure is that process? How do I guarantee the service that I am who I say I am?
Let’s take an example. For the last several hours I have been using a cloud service from somewhere in the UK, and suddenly I identify myself from the area of Tokyo. Strange isn’t it? Well you could argue that I logged in originally using my home PC and forgot to log-out prior to start my journey to Tokyo. Sure, that might be the case, but don’t you believe it’s worth taking a close look at what I’m doing as it is suspicious. Credit and calling card services routinely check for such anomalies, maybe identity management systems should do the same.
What level of authentication do I use to prove my identity? Name and password, token, digital certificate and fingerprint are all possible technologies. But we need to look at what is used to identify within the mobile device and then what is used to identify the mobile device with the cloud service. In other words, how easy is it for me to access my mobile app? And once my app contacts the cloud service, how does the app transfers my identity to the service?
The latter can be very secure, but if the first is not, the end-to-end security is not guaranteed.
Shall we run a couple scenarios? Let's say I am using a mobile device using a digital badge to log into a cloud service. If my mobile device is stolen, can somebody pretend to be me? As soon as he can log into the device itself, he can use the digital badge stored there to enter the cloud service. Do I have a mechanism to protect unwanted access to the device, or to wipe out the content of the device as soon as it is stolen? You will argue that this has nothing to do with cloud security, and you are right. But it opens up a door for a hacker to get access to the cloud. This is why it is important to look at things end-to-end.
My Virtual Machine environment
Let me now go to the next step. As we mentioned previously on this blog, some cloud providers allow their users to generate and store their own VM images in the image store. They can then use those to create appropriate instances to consume the cloud services. What do those VM images contain? How and where are they generated? It may be that I embed my own software in those VM images. That software may be infected by a virus or it may have a security hole. It is not only the responsibility but also the benefit of the service provider to thoroughly check the VM image prior to loading it in memory.
My Data
In my previous blog post I already discuss this area in quite some details. Data should be secured “at rest” and “in motion”. Encryption is a good mechanism to do that, although it is important to use the right encryption level to ensure proper security. The more the data is concentrated, the higher the encryption level should be.
In the first blog post we discussed that it was probably cost effective to try to un-encrypt a single message exchanged between a mobile device and a cloud service. The return from obtaining a single credit card number for example is limited. However, attacking the credit card database from an online merchant is a completely different story. With similar effort I can get hundreds or thousands of credit card numbers. With this in mind, we should store this type of information in our “digital vaults” if such things exist. To continue with our example, we may want to have one encryption mechanism for the communication between the device and the cloud service, and another for the data that is stored within the perimeter of the cloud service.
In a cloud environment, “this makes the job of the attacker so much harder, which means the amateur hacker might be obsolete,” says Sidiroglou-Douskos, who is working on a US government-funded research project to develop “self-healing” clouds. But if a system is breached, the amount of information lost could be far greater than what is in a single computer or cluster. “You can have better defences” in the cloud, “but if an attack happens, it’s highly amplified,” says Sidiroglou-Douskos
The importance of correlation
We should do everything we can to prevent attacks, but we know we will be attacked and it will probably come from an angle we had not expected. So, identifying an attack early and reacting quickly are important to ensure the security of the service. Hackers are patient people. They will take their time to quietly set-up all required elements prior to launch the attack itself. So it’s important to continuously see what is happening and to be on the look-out for strange behaviors.
If I repeatedly log-on from strange locations, at strange hours in the day/night, with a device I never used earlier, there might be something going on. If I regularly go to a service that is outside my area of responsibility, if I use that service in a strange way, there might be something wrong. There might also be a completely rational explanation obviously, but it’s worth checking, don’t you think?
This is where correlation comes in. In IT everything is logged - typically in log files - but how often are those files actually used to identify what is happening? Correlating events that have been logged by different systems is a very powerful way to identify issues early.
Avoid, protect, identify and react
I would argue we should look at cloud security from four different angles. I call them avoid, protect, identify and react. Let me explain what I mean by that. First avoid - lets make sure we do not leave openings that criminals can exploit. Prior to starting up a service, we should walk through scenarios and see how we trap misbehaviors. I talked about scanning code for security holes and I discussed how to ensure the integrity of an identity. Both are examples of how we can avoid trouble by taking a hard look at what we are putting in place.
But we will never be able to plan for every possible scenario. So, we need to protect - the second step. Let’s divide the environment into compartments that are isolated from each other using intrusion detection mechanisms to stop inappropriate access. Let’s protect our key assets through encryption mechanisms etc.
I repeatedly pointed out that security is all about risk management. Despite all our precautions, things will happen and when they happen, we should limit the impact as much as possible. This can be achieved by spotting attacks early - and indentifying them, step 3. Correlation is one way of doing so. It allows us to spot potential issues early, and once spotted to react - the final step. Occasionally this can cause irritation as a perfectly genuine event may attract attention and require checking. That’s the price to pay for a safe service.
Not only should we look at the 7 aspects discussed previously, we should also analyze end-to-end scenarios across the different aspects. Now, when using third party services this becomes very interesting because we do not have all the elements under our own responsibility. We need to share responsibility. That’s worth a whole discussion in its own right, so stay tuned. 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
