5 key cloud security use cases

February 13, 2019 by

Frank Siemons

A use case typically describes a situation where and how a system, product or service can be used. This is usually a short list of steps an actor should take in order to reach a goal.

The concept of use cases is very broad. A use case could, for instance, cover the installation of a bumper bar on a car; in the security world, they usually cover an attack method or analysis. An example of a security use case covering an SQL attack is a step-by-step instruction of where an analyst can find data and which decisions to take: find the network logs at X, find the local application logs at Y, block the source at Z and escalate if needed.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

There are many well-documented security use cases available online, ranging from ransomware outbreaks to insider fraud and data exfiltration. When it comes to cloud services, there are also some good opportunities, which are often based on the unique aspects of the cloud environments themselves.

Use case 1: Privileged account access

By far the most important security control when it comes to cloud environments is account management. Not only do accounts need to be configured with the “least privileges” required to perform their duties, their usage also needs to be monitored at all times.

This is especially important for cloud platform administrative accounts. Imagine such an account being compromised: it would be trivial for an attacker to change firewall configurations or add services where needed.

Generic accounts such as “admin,” “administrator” or “root” should not be used, in order to enforce accountability. Unusual activity should be monitored and compared to scheduled changes.

Any access from regions outside the expected operational areas of an organization should be flagged and investigated. For instance, a login from Brazil to a cloud account of a regional Australian supermarket chain should raise an alert (or should be already blocked proactively). Be mindful, however, that the use of VPNs or compromised local systems can circumvent some of these measures.

This is by far the most important use case, but because of its broad scope, it can be broken down into several individual use cases as well.

Use case 2: Data exfiltration

A cloud environment usually contains a lot of valuable data for an attacker. After all, the value of the data and the need to have a highly available and accessible platform is a reason for organizations to migrate systems to the cloud.

Even if the amount of data within the cloud environment itself is limited, the system can be used as a way to exfiltrate local data out of the on-premises network, potentially circumventing firewall rules and traffic alerts. Any unexplained data leaving the cloud systems — which could be large in volume, use a suspicious network port or could contain certain strings or headers — should be at least monitored and, if possible, also blocked based on the confidence of detections.

Use case 3: Suspicious network connections

Other than monitoring for data being exfiltrated, network connections should be monitored for remote access tool (RAT) communications, SQL injection, remote and local file injections and a whole range of other activity. This is best done via an Intrusion Detection (or Prevention) system.

Most cloud communications, however, utilize encrypted traffic. Encryption is great, but in the case of an IDS system, it renders it virtually useless; the IDS will not be able to see the actual traffic, so no signature can successfully match.

SSL decryption is the answer here, but this will come with some privacy and compliance issues which will need to be carefully worked through. Platform-specific technical challenges connected to SSL decryption will likely need assistance from the relevant cloud provider as well.

Use case 4: Man-in-the-cloud attack

The Man-in-the-Cloud Attack is focused on an authentication token residing on a device such as a PC or mobile phone. This token can be used by a local application to automatically authenticate a user to a cloud platform. An attacker will aim to replace that token with another one (usually via a spearphishing campaign), directing the user and their data to the attacker’s cloud instance instead. The result can be a synchronization of the victim’s data straight to the attacker’s system.

The monitoring of connections to unknown cloud instances either via endpoint monitoring, SSL decryption in the network or a Cloud Access Security Broker (CASB) could detect and often prevent this activity.

Use case 5: Unsecured storage containers

Whether it is called a bucket or something else, when it comes to storing data within a cloud platform, access to the data repository needs to be carefully managed and monitored. Large, unexpected amounts of incoming and outgoing data involving a storage container need to be watched, and access from suspicious sources needs to be investigated.

There are many, often fully-automated scanners available that allow an attacker to easily find unsecured buckets, such as the S3 Scanner and AWSBucketdump. Where possible, API calls to the storage platform should be monitored for suspicious activity — but again, this will require SSL decryption to be in place in order to work, unless detailed cloud storage logs are available.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Conclusion

Cloud security comes with its own challenges and use cases. Some are more specific to the cloud than others, but it is important to consider the unique aspects of cloud environments.

To get started, it is important to set out the requirements for the use case first — for instance, lining up the required logs and infrastructure to support them. The next step is to make sure all these requirements are met. Too often, an organization ends up with “broken” use cases and unactionable alerts because some key information was structurally missing while the use case implementation simply went ahead.