And How Your Organization Can

Avoid Becoming One!

3AWS Cautionary Tales

2

Organizations face a number of challenges in securing their AWS infrastructure

n Detection of anomalous activity is challenging due to the volume of log data, lack of activity baselines, and lack of context.

n Manual monitoring of security configurations and activities is laborious and error-prone.

n Remediation requires subject matter expertise in AWS.

3

What happens when organizations CAN’T secure AWS?

Unfortunately, many organizations lack sufficient cloud security measures to adequately address their end of the Shared Responsibility Model. And when vulnerabilities exist, someone is sure to take advantage.

Take a look at some cautionary tales of compromised AWS instances, and read on for TIPS to make sure you’re protected!

4

CAUTIONARY TALE: Employee spun up unauthorized AWS instancesAn employee in a global organization, with the majority of their operations in the US, decided to leverage the company’s AWS environment for the purpose of Bitcoin Mining. Knowing that the organization operates exclusively within the US, the employee turned on AWS EC2 instances in Asia at the end of each business day, and then turned them off before the office opened each morning. No one had a reason to check if any AWS resources were being used outside the US, and hence, no one was the wiser. However, the organization was paying a significant amount of money for AWS instances that it wasn’t using, and was also opening itself up to potential legal action since some Asian countries have bans on Bitcoin.

Bitcoin transactions are recorded in a public ledger. Processing and recording these transactions require computing resources, and users who offer their resources are rewarded with transaction fees and Bitcoins.

5

How to mitigate the risk

Deploy a cloud security solution which automatically monitors your cloud security settings and alerts you to activities such as the launch of new AWS instances.

6

During a security assessment of an organization’s AWS environment, we found AWS keys that had not been rotated in over three years. We also found that only 10% of all keys were actually necessary and should have been active. Not only were 90% of the keys simply redundant, it represented a huge attack surface for hackers. And as new users were being created, none of the outdated ones were being deleted.

This practice is equivalent to an IT administrator not changing passwords to the company’s entire infrastructure for over three years.

Although not rotating keys for over three years is one of the most extreme cases we have encountered, not rotating keys for over a year is actually a very common scenario.

CAUTIONARY TALE: AWS User Keys were not rotated in three years

100 EC2 keys never rotated

80 EC2 keys never used (orphaned)

95 EC2 keys not rotated in over 90 days

195 IAM keys not rotated in over 90 days

20 IAM key pairs unused (orphaned)

7

How to mitigate the riskn Use unique EC2 key pairs for all compute resources.

n Establish EC2 key pair rotation as a required procedure after any administrator turnover/departure.

n Replace IAM users’ access keys quarterly to reduce the risk of user account theft.

n Review your applications and tools to make sure there are no hard-coded IAM access keys present.

n Develop a key naming convention that does not compromise operational security concerns.

8

During an analysis of an organization’s credential practices, we uncovered that someone within the organization had standardized on a password format that was weaker than the AWS default password. They had standardized on a minimum of six characters, one of which had to be upper case. The AWS default is much more complex.

Fortunately, it is NOT common practice to reduce the default password strength because that leaves an organization open to all types of security breaches. This organization was shocked with this finding and immediately reset back to the AWS default.

CAUTIONARY TALE: IT made passwords easier to crack

9

n Require a minimum password or passphrase length of 12-14 characters. Also consider leveraging passphrases or randomly generated passwords with a password manager as well as multi-factor authentication.

n Enable the checkbox for “obscure secret answer for password resets” in the AWS console.

n Follow best practices from NIST and SANS that suggest preventing reuse of the past 8-12 passwords or passphrases. For sensitive or high risk systems, consider a larger history and/or multi-factor authentication.

n Update the password expiration value. NIST and SANS suggest a minimum password expiry of every 90 days.

How to mitigate the risk

10

When you leverage AWS, you gain agility and cost savings that can help you gain significant competitive advantage. At the same time, you are putting your most precious data into the cloud. Without proper controls, your data is at risk, and your organization is too. Instead of cost savings, you can incur high costs for AWS instances that you didn’t know existed. And you can incur high costs in damage to your brand as well as legal expenses when your data is not secure.

A CASB can provide the following benefits…

VISIBILITY: Insights into AWS usage

THREAT DETECTION: Monitoring for anomalous activities

COMPLIANCE MANAGEMENT: Monitoring of configurations and activities leading to policy violations

INCIDENT RESPONSE: Logging and remediation

Protect your AWS Instance with a Cloud Access Security Broker (CASB)

11

Are you doing your share of the shared responsibility model? If not, your organization is at risk.

Find out today with our free risk assessment of usage, threats, and compliance violations in your AWS environment.

It costs nothing to find out. It could cost everything if you don’t. We would love to help you find out today if you are at risk.

Request Assessment

Are your AWS Instances at risk and costing you more than they should?