AlgoBuzz Blog

Everything you ever wanted to know about security policy management, and much more.

Generic filters
Exact matches only
Search in title
Search in content
Search in excerpt
Filter by Custom Post Type

Resolving the cloud security blame game


One in three IT professionals believe that cloud security is the sole responsibility of their chosen cloud provider. Is that really the case?

Like many things in life, network security is a continuous cycle. Just when you’ve completed the security model for your organization’s current network environment, the network will evolve and change – which will in turn demand changes to the security model. And perhaps the biggest change that organizations’ security teams need to get to grips with is the cloud.

This was highlighted by a recent survey, which showed that one in three IT professionals believed that cloud security is the sole responsibility of their chosen cloud provider. This rather worrying finding was offset by the other 66% of respondents being at least somewhat familiar with the ‘shared responsibility’ cloud security model, in which the cloud provider updates, patches and secures their infrastructure, and the customer is responsible for protecting what they run in it. 

But what exactly does ‘shared responsibility’ mean? 

In reality, the responsibility for security in the cloud is only shared in the same way that an auto manufacturer installs locks and alarms in its cars. The security features are certainly there:  but they offer no protection at all unless the vehicle owner actually uses them.  

In other words, responsibility for security in the public cloud isn’t really ‘shared’.  Ensuring that applications and data are protected rests entirely on you, the customer.  Here’s a simple example:  I’ve blogged previously about how several high-profile companies unwittingly exposed large volumes of data in AWS S3 buckets.  These issues were not caused by problems in Amazon:  they were the result of users misconfiguring the Amazon S3 services they were using, and not using proper controls when uploading sensitive data to the services.  The data was placed in the buckets protected by only weak passwords (and in some cases, no password at all).

Cloud exposure

It’s important to remember that cloud servers and resources are much more exposed than physical, on-premise servers.  For example, if you make a mistake when configuring the security for an on-premise server that stores sensitive data, it is still likely to be protected by other security measures by default.  It will probably sit behind the main corporate gateway, or other firewalls used to segment the network internally. Its databases will be accessible only from well-defined network segments. User logging into it will have their accounts controlled by the centralized passwords management system. And so on.

In contrast, when you provision a server in the public cloud, it may easily be exposed to and accessible from any computer, anywhere in the world.  Apart from a password, it might not have any other default protections in place. Therefore, it’s up to you to deploy the controls to protect the public cloud servers you use, and the applications and data they process.  If you neglect this task – and a breach occurs – the fault will be yours, not the cloud provider’s!

This means that it is the responsibility of your company’s security team to establish perimeters, define security policies and implement controls to manage connectivity to those cloud servers. They need to set up controls to manage the connection between the organization’s public cloud and on-premise networks, for example using a VPN, and consider whether encryption is needed for data in the cloud. These measures will also require a logging infrastructure to record actions for management and audits, to get a record of what changes were made and who made them.

Of course, all these requirements across both on-premise and cloud environments add significant complexity to security management, demanding that IT and security teams use multiple different tools to make network changes and enforce security.  However, using a security policy management solution will greatly simplify these processes, enabling security teams to have visibility of their entire estate and enforce policies consistently across public clouds and the on-premise network from a single console.

The solution’s network simulation capabilities can be used to easily answer questions such as: ‘is my application server secure?’, or ‘is the traffic between these workloads protected by a security gateway?’ It can also quickly identify issues that could block an application’s connectivity (such as misconfigured or missing security rules, or incorrect routes) and then plan how to correct the connectivity issue across the relevant security controls. What’s more, the solution keeps an audit trail of every change for compliance reporting.

In conclusion, in the public cloud, there’s almost no such thing as ‘shared responsibility.’  Security is primarily your responsibility – and the cloud provider will assist you.  But with the right approach to security management, that responsibility is easy to maintain, without having to play the blame game.

Subscribe to Blog

Receive notifications of new posts by email.