6 Common Threats to Securing AWS Management Configurations

There’s a common misconception that cloud providers handle security, a relic leftover from hosting providers of previous decades. The truth is, cloud providers use a shared responsibility model, leaving a lot of security up to the customer. Stories of AWS compromise are widespread, with attackers often costing organizations many thousands of dollars in damages.

Luckily, The Center for Internet Security has created the CIS Amazon Web Services Foundations benchmark policy, which provides guidance on best practice security configuration options within the AWS management console.

Let’s look at some common threats to cloud infrastructure and how the CIS policy combined with general security practices help to mitigate them.

1. Phishing

Research shows that 30 percent of phishing emails are opened and that 91 percent of breaches begin with a phishing attack. CIS recommends the common best practice advice of enabling multi-factor authentication (MFA) in section 1.2.

In particular, the AWS root account is especially important to protect with MFA, as it holds access to anything and everything. CIS also recommends enabling alarms to detect when the root account is used (section 1.1) and having separation of roles, which involves setting up different accounts for different tasks (section 1.18).

Generally, phishing training should be offered to all users to limit the possibility of falling for this type of attack. Your organization should create an AWS root account that belongs to an internal user group and not a specific user account. Never use a standard personal Amazon.com shopping account as the AWS root account, and don’t use the root account for everyday work. Consider using a multiple AWS account strategy, so that the compromise of one doesn’t put all assets in danger.

2. Password Management

Breaches of third-party websites are another common method of AWS credential exposure. One report shows that 55 percent of users use the same password on most if not all websites. As mentioned above, reusing the credentials of an Amazon.com shopping account on another website could be exposing your entire cloud infrastructure.

Along with breaches, bad or guessable passwords are a risk factor.

CIS policy sections 1.4-1.10 recommend password policy options that can help mitigate password risk by ensuring password complexity requirements are met, such as password length and combinations that contain uppercase letters, lowercase letters, symbols and numbers. It also recommends preventing password re-use.

Generally, practice good password security. Use unique passwords on all sites and use a password manager. Have training with your users on the importance of having strong passwords and not reusing passwords on multiple websites.

3. Credential Leaks

Another source of reported AWS compromises is credentials being leaked via public source code or documentation. Amazon uses what it calls “access keys,” which function in exactly the same way as credentials. Users may not have been trained to treat API keys or access keys with as much care as usernames and passwords.

CIS advises us to again enable multi-factor authentication but to also ensure that access keys (section 1.4) and passwords (1.11) are rotated every 90 days or less.

It’s important to treat your AWS Access Keys as securely as passwords. Never hardcode them into source code or documentation. Never email them or let them escape outside of the organization.

4. Network Security

The cloud environment is no different from your on-premises environment in network regards.

CIS recommends limiting exposure to brute force attacks in section 4.1 and 4.2 by ensuring the AWS Network Security Groups do not allow access to port 22 and port 3389 from the open internet. They also advise ensuring that network flow logs are being created (section 4.3)

Of course, basic network security cannot be overlooked, and all standard best network security practices apply in AWS.

• Enable your operating system firewall along with the AWS Network Security Group ingress rules. Defense in depth is worth the extra firewall rule maintenance.
• Develop strong allow or block listing rules to apply to your firewalls to limit service access and exposure.
• Run anti-virus and monitoring products on your virtual machines.
• Perform vulnerability scans to find possibly exploitable vulnerabilities before the attackers do. These must be approved by Amazon in advance.
• It is also a good idea to run an intrusion prevention product to detect and stop attackers. You can even run the newly created Amazon Web Application Firewall, in order to target some attacks, such as protecting against the OWASP Top 10.

5. Insider Threat

The CIS policy contains sections on logging and monitoring. Section 2 ensures that logging is enabled for real-time monitoring and also that logs are archived on encrypted storage.

Section 3 ensures a wide variety of monitoring alerts are enabled, so that you are notified of various behaviors. These can help with insider threats and escalation of privileges via alerting on unauthorized API calls (Section 3.1) and IAM policy changes (Section 3.4). There are also numerous other behavioral alerts to keep you abreast of the goings on within your AWS setup.

6. Security Incident Recovery Planning

Lastly, not being prepared for incident eventuality is another risk, and you should ensure proper planning is implemented.

CIS advises us to ensure a security contact is established (section 1.20) and to ensure security questions are registered (section 1.15). This allows for secure communication when security incidents take place.

DoS attacks can be mitigated using the AWS Shield managed denial of service protection. This should be investigated, so that you are prepared to react in the case of an expensive denial of service attack.

Your backup strategy should also be reviewed, specifically regarding offline backups. An attacker who gains access to your control panel can remove your backup data storage just as easily as your primary.

Lastly, one benefit to virtualized infrastructure is the ability to easily roll out patched and updated capacity when you detect a compromise. Ensure your DevOps chain is capable of instantly deploying your required servers.

Combining security practices honed for your on-premises environment with recommendations from the Center for Internet Security’s AWS Foundations Benchmark Policy can drastically reduce your cloud risk.

Tripwire has developed Tripwire Configuration Manager  which helps you determine the security state of your AWS deployment, by collecting and analyzing configuration data based on the CIS AWS Foundations Benchmark.

Tripwire Configuration Manager can be used to automatically assess and monitor the security posture of your cloud accounts, as well as perform automatic remediation and enforcement of many common risks and settings.

To learn more about Tripwire Configuration Manager, click here.

To learn more about how to protect your AWS deployment from common threats, click here.