There are many unique challenges involved with securing cloud services. First, data and applications in the cloud are distributed across many services and platforms; each with its own unique set of capabilities, logs and users. Monitoring access is generally per service or cloud provider, this quickly becomes a mess when your company grows and adopts new cloud services. Even with an IDaaS solution, where connections to cloud applications are monitored in one place, activities are still stored in separate locations and formats.

Secondly, the effect of an access configuration mistake is usually much wider in the cloud. While an access misconfiguration on-premises will probably result in information reaching the wrong hands of someone inside the company, making the same mistake in the cloud will result in this data becoming public to a sub-contractor or external vendor, or even the whole world. In the cloud, access configuration should be treated ever more seriously than on-premises.

Additionally, while in the on-premises world there were multiple security layers separating your data from the internet (Firewall, VPN, NAC, IDS\IPS, A.V, etc.), in the cloud environment we mostly rely on authentication as the first and last line of defense. Once a role with sufficient privileges is compromised, it can leak personal information or maybe even create a new administrative account you haven’t thought of monitoring. Once a token is stolen from Git or Dropbox, your entire codebase or data set may be compromised.

Finally, the sense of tranquility in the cloud is elusive. The cloud lets companies worry much less about infrastructure, hardware and switching technologies. Unfortunately, while cloud providers make sure to protect their own environments, it is the cloud consumers’ duty to define who should have access to what within their organization. The cloud cannot choose by itself what information should or should accessed or publicly exposed. A false sense of security can lead to many misconfigurations in the areas that need the most focus: authorization.

What’s Changed Regarding the Perimeter?

Your company’s data is no longer confined to servers behind a network gateway, so a misconfiguration can immediately expose your data to the internet. In 2014, for example, a misconfiguration in Box caused data that was shared by link with only specific people became available through Google’s search engine.

Sharing your cloud infrastructure with a separate service, although reducing management costs and misconfigurations, can also prove a security threat. In 2017, for example, OneLogin’s own AWS infrastructure was hacked, providing hackers with access to many of the company’s clients in the U.S. The attack surface available to hackers today is much wider than in an on-premise environment, and consists of each cloud service whether it be an IDaaS, storage, or virtual machine, the on-premise equivalents of the DC, storage servers and website. Additionally, communication in the cloud is always encrypted providing more privacy, but also introducing more blindspots where malware and malicious actions can only be detected once they reach either logs or physical computers.

Are Companies Navigating the Shift to Cloud Appropriately?

There has been a lot of buzz about the cloud, and companies have shifted very quickly, but securing cloud services is still very basic. Companies are making their best effort to secure the cloud environment, but their team’s lack of experience combined with insufficient tools is making it difficult to manage the new set of risks associated with the cloud.

In addition to the technological challenge, there’s also an organizational culture transformation happening. Business owners often make decisions regarding permissions, identities and resources in a way that directly affects the security posture of the organization, not just inbound but outbound. Security teams need to evaluate in a non business-intrusive way when is the right time to step in, where to inspect and how to intervene when they feel there’s a potential security threat. Finding this balance in involvement presents an enormous challenge for security teams as they need to continue and add expertise to their teams in every service in order to understand a) what privileges are considered risky? b) what is a risky action? And c) how to assess identities’ permissions?

What Happened With the Capital One Breach, and What Could Have Been Prevented?

Around April 21st, a former-AWS employee posted credit application data she leaked most likely by using an SSRF attack and a misconfigured role. Capital One announced that one of their roles, which probably belonged to a web application firewall, was compromised by this former AWS employee. The role used the ListBuckets action and downloaded the contents of a bucket that contained substantial credit card application data. Capital One adds that this role did not usually use the ListBuckets action, nor does it access private customer information.

A web application firewall is meant to protect web services from different attacks such as SQL-injection and Cross-Site-Scripting. So the question becomes, “why does a role with this purpose have the permission to download personal information?” My advice is to deploy a principle-of-least-privilege model where every role has a specific purpose and is given only the permissions required.

Another scenario that may justify allowing the WAF role to access this bucket is when the bucket contains its own information and the object policies were not configured properly. The cloud offers an unlimited amount of buckets and storage space, so if the data had been separated by use and sensitivity into several buckets rather than just one, this breach may have been spared.

What Can IT and Security Teams Do to Truly Secure Their Cloud Environments?

When planning your cloud infrastructure, be sure to define the different entities and services in your organization. Note what access controls are offered by your cloud providers, and review their security guidelines carefully, then apply a principle-of-least-privilege model and define permissions for each entity in your infrastructure based on this principle. Identify how any attacker, whether from outside or inside your organization, could reach sensitive information in any of your cloud services and monitor those areas. Then choose how you will use the security tools offered by your cloud provider to manage and enforce your security guidelines, and to monitor changes in permissions and behavior.

To secure your cloud environment you must know your infrastructure, define and identify strong permissions and risky actions, find a way to manage all of your entities across each cloud service, and stay up to date with the latest security guidelines and tools offered by your cloud providers.

What Special Focus or Areas of Expertise Should IT Departments Be Working On?

Once you have established a strategy to manage the security guidelines created for your cloud environment, you can shift your focus to updating access and permission definitions as your organization grows and protecting them from abuse and misuse. This should happen every time a new position or cloud app is introduced into your organization, the cloud security best-practices are changed, or your cloud provider publishes a new security tool. IT departments should focus on adapting inside the dynamic world of the public cloud by fixing configuration mistakes, revoking stale permissions and monitoring changes in permissions and behavior.

What Has Authorization Done to Secure Cloud Services? Is It Enough?

Single Sign-On solutions such as OKTA, OneLogin, etc. have made great progress in helping organizations securely manage the initial authentication process. But that’s just one piece of the puzzle. After a user gains access, companies are unable to manage permissions, and monitor activity and behavior post-login to prevent misuse of company assets.

In order to manage users in the cloud from a single interface, it is common to use an external authorization service. You give it credentials to an account that can create temporary roles or manage your accounts on each other cloud service you use. By taking this approach, users and identities can be defined on a single platform, but the identity provider needs to be trusted not to perform malicious actions. When it does, it may be harder to track down the origin of these actions.

These authorization mechanisms still require you to monitor the activity of the users and roles on each cloud application separately. They leave blind spots where a single role is used by multiple users making it difficult to identify where a breach started. Each employee must know what keys to provide to whom. A shared link can suddenly make confidential information public, and exposing the token provided to any IDaaS can potentially compromise your entire infrastructure.

What Investments Should Businesses Be Making Here?

To be secure in a cloud environment it is important to employ the latest security tools provided by each cloud service, as well as to hire experts in the bigger services used by your organization. Another important investment is in platforms that will help manage and monitor your cloud permissions and entities more efficiently and, if possible, across most or all of your cloud services.