The public cloud has undoubtedly been a great enabler for business, but it has also created a number of blind spots and brought with it serious security challenges. The collection of cloud services and applications has – and continues to – increase exponentially, making access logic, permission sets, resources, capabilities and risks much more difficult to manage.
Authorization is no longer a nice-to-have feature, it is an imperative. Permissions and access rights for user identities must be well defined and carefully verified, and over-provisioned users identified and their permissions right-sized. Otherwise, the results can be disastrous and often irreversible.
The public cloud allows a business to expand its computing power easily while cutting expenses on physical infrastructure and maintenance. An IT department can create servers with a single click, keep an almost infinite amount of storage on demand, and always have the newest software and hardware.
However this comes at a price; you need to rely on these services to manage access for your users and developers. This introduces blind spots, where attackers can attack each service separately from the web, trying to compromise credentials and hide their trails. The goal of keeping data secure over different platforms, as well as on many personal computers, becomes an elusive challenge.
In this new and extremely dynamic environment it is very easy to leave an information leak unnoticed. Your information is distributed across services such as Dropbox, Gmail, AWS, GitHub and Slack, each with its own set of permissions and credentials APIs. Where you once needed only an IT professional for Windows domains, you now need a team of experts in each of these services to define the same groups and permissions, over and over again, and to monitor the activity and behavior of each entity in each service.
Often different configurations need to be set up for each type of platform, and you must ensure you provide each user or service with the correct access keys for each service. This exposes you to the risk that your users can now be compromised in any one of many platforms that your company uses, opening the door to a completely new world of risks.
Authorization used to be controlled on-premises by a single authorization server. Now, even with IDaaS solutions such as OneLogin and Okta, permissions are enforced individually by each service. A compromise or breach in one service can lead to unwanted privileged access in another. Preventing this requires an understanding of how your IDaaS and other cloud applications work, so you don’t mistakenly give the wrong keys to the wrong people.
It also requires continuous monitoring and authorization of user actions, to look for anomalous access to devices, time of access, and user accessing these resources. Not to mention, this often has to be done across multiple cloud services. To make this possible, ‘normal’ access and behavior must be very well defined and carefully verified. Resources should be separated by use and sensitivity.
We can see, from common recent use cases, how authorization in the cloud requires a new approach. Use case 1 - SSRF to Credential Theft: A Server-Side-Request-Forgery (SSRF) attack is an attack on a web application or virtual server where the attacker forges an http request and causes the web application to send it. Many cloud server providers, such as Amazon EC2, use link-local addresses to provide the applications running on a virtual machine access to their cloud APIs.
An attacker can use an SSRF attack to request temporary credentials to the role of the EC2 virtual machine which runs the vulnerable application. Then, using these credentials, the attacker will go on to search for any sensitive data or administrative users they can access. If these roles are monitored for suspicious activity, this sort of attack may be identified.
Usually these intrusive actions will not be the normal behavior of a machine’s role. Additionally, using a principle-of-least-privilege model, and a web application firewall, may help mitigate breaches of this sort.
Use case 2 - MITC: A Man-In-The-Cloud (MITC) attack is an attack on personal data stored on a storage service. This happens when an attacker intervenes and negotiates with the cloud service on behalf of the user and provides the user with a fake access token. In this way, the attacker steals a token with access to the service, to download the user’s data, sometimes containing plaintext passwords and other personally identifiable information.
Client endpoints should be monitored as well as cloud services. It is easier to detect this type of attack if you monitor across multiple cloud services. Check that the IP address that is accessing your data is the same IP that accesses other cloud services, for example, your anti-virus software or Gmail account.
The public cloud has enabled companies to expand their storage space and provide better service cost-effectively, but with the expanding number of cloud services, controlling authorization has become a key challenge. Identities are managed by each service separately, each with its own API and set of capabilities, and these all need to be continuously monitored. It becomes more difficult to identify malicious activity and its source.
This being said, it is possible to reduce these risks by defining a strong set of permissions, of who can access what, and why, and adopting a principle-of-least-privileged model. This will make it possible to define each user’s ‘normal’ behavior and access patterns. Then you can start to search for suspicious actions across your cloud services, and provide better protection for your company’s sensitive resources.