Ending the Cloud Security Blame Game

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, in which over 75% of respondents said the cloud service provider is entirely responsible for cloud security. This rather worrying finding was offset by some respondents stating that security is also the responsibility of the customer to protect their applications and data in the cloud service, which shows at least some familiarity with the ‘shared responsibility’ cloud security model. 

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 activates and 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 the customer of those services. Over recent years we’ve seen 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. Users 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 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 network 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.

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

About the author: Professor Avishai Wool is the CTO and Co-Founder of AlgoSec.

Copyright 2010 Respective Author at Infosec Island via Infosec Island Latest Articles "https://ift.tt/2Ck38n5"