Gartner: Cloud Breaches are Almost Certainly The Customer’s Fault
January 28, 2016 | DevOps |
As more enterprises embrace AWS, the industry analyst firm sounds a note of caution: security and compliance is still your responsibility no matter how well the cloud service provider does the job of securing their infrastructure.
In what is a pretty eye-opening and cautionary prognostication, the industry analyst firm Gartner has warned that through 2020, 95% of cloud security failures will be the customer’s fault. What does this mean in practical terms for the growing number of risk-conscious organizations making Amazon Web Services an integral component of their IT services delivery strategy?
For many large organizations that still have substantial misgivings about the risks posed by cloud services, this prediction would seem counter-intuitive. Gartner, of course, is not suggesting that customers should simply assume the best of their cloud service provider, and “that using a cloud means that whatever they do within that cloud will necessarily be secure”.
Instead, Gartner is restating the fundamental challenge of the cloud’s shared responsibility model. But, the firm is pointing out, rather emphatically, that while cloud service providers have done a good job of holding up their bargain, customers are still coming to terms with the challenge that “secure use of public clouds requires explicit effort on the part of the cloud customer.”
Effectively speaking, the service provider is responsible for securing the infrastructure. How the infrastructure is used, and who – and what – gets access and permissions remains the customer’s responsibility. Without adequate controls in place, it’s far more likely that a security incident, breach, or compliance failure will be the customer’s fault rather than that of the service provider.
So what are the practical implications and the logical conclusions from the prediction, especially for AWS customers? What value can tools like AWS Identity and Access Management (IAM), or even Security Monkey for AWS provide for ensuring security and compliance? Gartner sounds another note of caution:
”The characteristics of the parts of the cloud stack under customer control can make cloud computing a highly efficient way for naive users to leverage poor practices, which can easily result in widespread security or compliance failures.
In other words, cloud service providers can only provide the tools. The customers have to bring the policy.
For AWS customers, access and authorization policy is in large part a question of who or what gets access to the AWS Management Console and how AWS IAM roles and rules are maintained to ensure consistency. Just as in on-premise datacenters, who gets access to administrator accounts and their associated authorizations is a key security and compliance consideration.
For many Conjur customers, the first point of departure is ensuring that AWS IAM users, roles, and rules are based on existing policy logic and identity data stores (notably but not exclusively, Microsoft Active Directory). Synchronizing with existing data and policy stores ensures that AWS identities are not managed in a silo, and that when users leave or are de-provisioned, they don’t end up keeping their AWS credentials.
The next element is ensuring that access to the AWS Management Console and privileged systems running in AWS is via strong authentication and involves the use of private keys, including SSH keys. This type of deployment is commonly referred to as a SSH bastion host.
However, a set of new challenges present themselves when customers go to the next series of steps. Securing access to the AWS Management console is complicated by the need to enable developer access for moving code intro production, for example, which can easily result in violating principles of least privilege. In this sense, AWS usage illustrates the need how to strike a balance between operational flexibility and security and compliance needs.
A closely related authorization challenge to developer access is how machine identities are managed in AWS environments. Machine identities, such as applications, services, and APIs also need to be managed in terms of permissions. In order to scale effectively as well as secure ephemeral infrastructure, a new approach is needed.
Conjur is designed to effectively tackle these challenges – especially the management authorization for machine identities in highly dynamic environments.
The Conjur platform directly addresses those elements that customers need to avoid becoming one of Gartner’s statistics:
- Manage the complexity of IAM permissions and align cloud service provider tooling with internal policy and identity data sources
- Ensure consistent authorization policies are maintained for access to secrets based on role, with activity logged and audited
- Enable developer access to AWS admin console while still adhering to least privilege access
- Automate governance for ephemeral, short-lived machine identities Broker access and enforcing strong authentication for remote users to private instances and privileged systems running in AWS