Change Your Mindset To Successfully Defend The Cloud

There is a bit of comfort for cyber security blue teams in defending traditional on-premises physical infrastructure. It’s familiar. There is plenty of thought leadership provided in social media posts, blogs, videos, tabletop exercises, and conference presentations. We’ve been building a base of ever increasing knowledge and honing our skills to defend legacy infrastructure for decades.

This level of comfort brought by a legacy mindset might be so subtle that you might not even know how much your legacy minded information security team relies on it. It’s shapes our infosec world view as well as the lens through which we view all cyber requirements.

This post will focus on some of the complexities of defending Infrastructure as a Service (IaaS) cloud providers. These would include AWS, Google Cloud, and Azure.

One idea shaped by a legacy mindset would be the concept of “attacker dwell time.”

Dwell time is very simply the measure of the time between an attack penetrating a network’s defenses and the time that attack has been discovered. There obviously is no authoritative average but most reputable studies have a widely varying average from months to years. For example, a 2019 study by the security company, Infocyte, calculated the average attack dwell time for persistent malware in small to medium businesses to be 798 days. That’s more than two years.

This dwell time metric is a horribly revealing statistic about the state of cyber programs and their ability to identify and respond to malware. That said, the metric may also be a strange source of comfort to defenders of the network in some ways.

Think about it. An average of over two years of dwell time tells us that the blue team in almost all legacy infrastructures has some measure of time on its side. Any defensive response or paltry level of security resourcing can be justified when viewed side-by-side with an average two year dwell time.

For instance:

• An infosec team has little pressure to move fast because, if they can find and respond to malware in a 10 to 30 day period, they look pretty good to Boards and executive teams compared to a 798 day average.
• Using the above 10 to 30 day response time means that, while automation would be nice, there is little real business pressure to move away from manual processes and invest in proper defensive automation.
• The blue team world view might morph into one in which attackers have little incentive or pressure to move quickly, They might self justify that view by assuming that attackers don’t want to move fast because going fast potentially creates noise which might be detected by the defending organization.

And then, one day, the organization moves to the cloud.

Wise infosec leaders already know that migrating to the cloud entails many of the same legacy security risks around identity, access, and networking that legacy infrastructure poses. One quick example of a similar IAM risk are poor passwords. Just like with your legacy infrastructure, an attacker in the cloud can guess, phish, break, or otherwise steal a valid username and password combination. No requirement to multifactor in the cloud poses the same threat as on physical infrastructure. The outside attacker with valid stolen credentials now has easily become an insider threat. Yikes.

That said, while some cyber risks are shared between the cloud and physical infrastructure, not all threats and risks overlap. The cloud doesn’t have a traditional “perimeter” to defend., Therefore, a blue team can’t bring the same legacy thinking to all cloud defense and be successful. Each control must be considered from a cloud specific perspective and within the limitations of the particular cloud provider.

Dwell time by attackers in IaaS infrastructures isn’t measured in years, it’s measured in minutes.

Why? It has to be.

They use automation to steal access tokens and access token generally are severely time-boxed. Since the tokens expire, the attacker only has a limited amount of time to perform their malicious activity. Automation is normally a key part of the bad actor’s tactics in the cloud.

As an example, until the most recent Capital One breach, we rarely heard about the vulnerabilities around AWS access tokens. An attacker may try gain an valid access token in AWS through various means that are outside the scope of this post. Suffice it to say that the server side request forgery vulnerability was part of the Blackhat training course curriculum in 2018 (long before the Capital One breach). It’s fair to assume that there may be other approaches either now or in the future.

Once a bad actor has a valid access token, the attacker then has full access to any AWS services allowed by the instance. Unlike traditional infrastructure, the access token is time limited by an expiration date before the credentials are rotated. The remaining time before expiration is usually measured in minutes.

The timed access token means that, unless attackers have gained the actual legitimate credentials, they will likely to use automation to maximize the time left on the access token. There is no waiting. Without an automated defense, the bad actor will be long gone before a blue using manual methods would begin to engage in a response.

Trying to manually defend an organization’s cloud infrastructure against an automated attacker is like bringing a spoon to a tank battle.

IaaS also can create unique defensive scenarios that differentiate the cloud from legacy infrastructure.

For instance, AWS security tools may be bound by AWS geography by default . Let’s say that an organization maintains infrastructure in US East and US West. Their AWS security tools are focused on those two AWS regions. Without a purposeful global configuration limiting account access to other global regions, there might not be corresponding security control coverage in those accessible other regions. In fact, there may be no coverage at all. In those other regions, an attacker that has gained valid credentials may be able to spin up AWS instances, perform malicious activity, and operate with impunity.

Cloud forensics also takes on an entirely different mindset. If a blue team discovers malicious activity and simply spins down a compromised IaaS instance, the attack may be thwarted and a clean instance might be spun up. That said, any useful forensics artifacts related to the attack would also disappear. Blue teams need to think creatively in these scenarios.

One creative cloud forensics approach might be leveraging the ability to use different namespaces within a given customer account in a region. The blue team can

• create a namespace specifically for maintaining compromised instances
• use automation to spin off all potentially compromised AWS instances into that different namespace without spinning the compromised instance(s)
• Limit the ability of the attacker to cause more harm by automating the dynamic application a cloud formation template that removes all privileges to all live instances that were moved to the new namespace
• automate spinning up a new clean instance for legitimate users in the production namespace
• Maintain the compromised instances and all forensic artifacts (without losing them by spinning down the instance(s)) until the completion of forensic investigations and their artifacts can be or further investigation.

So, the cloud isn’t “just another data center”. You’ll need to develop a different mindset around new IaaS specific scenarios while still protecting against many of the same legacy network and IAM risks. You’ll also need to prioritize automation investments. They’ll need to become part of the story that you tell about your overall cyber program.

Change your mindset early and the cloud is yours to own, rather than the other way around.

For more insights into how cyber leaders can best enable the business and build rock solid cyber programs, please follow me on Twitter at @opinionatedsec1