Change Your Mindset To Successfully Defend The Cloud

Opinionated Security
Feb 2 · 4 min read

There is a bit of comfort for cyber security blue teams in defending traditional physical infrastructure. We’ve known how to defend legacy infrastructure for decades.

That level of comfort brought by a legacy mindset might be so subtle that you might not even know how much your legacy minded IT security team relies on it.

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

Dwell time is very simply the time between an attack penetrating a network’s defenses and being 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 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.

While dwell time might be a horribly revealing statistic about the state of cyber programs and their ability to identify and respond to malware, it’s also may be a source of comfort in some ways.

Dwell time tells us that the blue team in almost all legacy infrastructures has some measure of time on its side.

  • A cyber 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.
  • Ten days means that, while automation would be nice, there is little real business pressure to move away from manual processes
  • The attacker has also time on their side, There is little pressure to go fast because going fast creates noise which might be detected by the defending organization.

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

Cyber 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 example of a similar IAM risk are poor passwords. Just like with your legacy infrastructure, an attacker that can guess, phish, break, or otherwise steal a valid username and password combination without a requirement to multifactor now has become an insider. Yikes.

That said, we can’t bring the same legacy thinking to all cloud risks and be successful. Each control must be considered from a cloud specific perspective and within the limitations of the particular cloud provider.

We’ll especially need to consider unique defensive scenarios that differentiate the cloud from legacy infrastructure.

For instance, most AWS security tools are bound by AWS geography. If my organization’s security tools are focused on US East and US West and there are no controls limiting account access to those regions with security controls, an attacker that has gained credentials may be able to spin up instances in other regions and operate with impunity.

Cloud forensics also takes on an entirely different mindset. Spin down that instance and all forensics artifacts disappear. One creative cloud forensics approch might be using automation to spin off a potentially compromised AWS instance into a different namespace and dynamically change to a cloud template without privileges. A new instance could be spun up. The suspected attacker wouldn’t be able to do more damage and the forensic artifacts could be retained for further investigation.

Automation is normally a key part of the bad actor’s tactics in the cloud.

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.

So, the cloud isn’t “just another data center”. You’ll need to develop a different mindset around new 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.

CISO & Cyber Leaders

Opinionated Security

Written by

Tony Grey * leads a cyber program for an insurance company * led large software dev/test/PM teams at Microsoft * blogs about cyber leadership & managing change.

CISO & Cyber Leaders

A community for cyber security leaders

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade