Amazon Web Services Provides the Tools, But it Won’t Secure Your Data for You

February 22, 2018 |

In what’s become a frighteningly frequent occurrence, another unsecured Amazon Web Services (AWS) S3 bucket has jeopardized hundreds of millions of customers’ personal data.

Companies share security responsibilities with their Cloud service providers. While AWS and other CSPs must provide identity and access management tools, among others, they can’t control how clients use those tools. They can’t stop organizations using their Cloud platforms from spilling users’ sensitive information across the web.

Often, breaches occur because Cloud clients fail to properly configure or upkeep their Cloud environments. That isn’t to say that Cloud service providers never make mistakes, but the great majority of breaches could be prevented with the following best practices.

Basic Security Protocols

  1. Strengthen Root Account Setup

Using root access might seem easier, but the risks aren’t worth it. Don’t generate an access key for your root account. You probably won’t need one, but if you do, lock away root user access keys and never use that account to access AWS. Any regular access should go through unique user accounts, which are protected by identity and access management protocols.

     2. Implement Role-based Access Control

Any Cloud security program should limit access according to the user’s role. Assign permission to groups, not individual user accounts. Generally speaking, users should only have access to the data they need to do their job.

Try a tool like Access Advisor, which can show user activity over time, highlighting which permissions are used by which accounts. Overlooking RBAC in the beginning is easy, but as the company grows, cleaning up RBAC becomes more difficult — and the consequences of a breach become more severe.

     3. Use Multifactor Authentication.

One organization recently suffered a breach on Azure, an AWS equivalent, that could have been avoided with proper MFA implementation. In fact, eight in 10 hacking breaches happen because of weak or stolen passwords.

MFA is easy to set up and keeps AWS system resources safer than single passwords. With MFA, a would-be hacker needs to acquire an accompanying phone or token device in addition to the password in order to access the account.

Make MFA an across-the-board rule for anyone accessing AWS. You can choose in AWS’ settings to enforce MFA sign-in through a managed policy rather than make it optional. Beware of using SMS-based MFA, however, which the National Institute of Standards and Technology has declared insecure.

Maintenance and Housekeeping

     4. Rotate Access Keys

Most users rarely, if ever, log in to the AWS console. Access usually goes through programmatic requests or API services. Over time, tracking access keys becomes more difficult, so rotate keys at least annually (or even better, quarterly) for both human accounts and automated services.

Some companies fail to rotate keys because they don’t appreciate the dangers overused keys pose. AWS makes it easy to trade keys, but like any security measure, it’s easier to start rotating early than to implement rotation later.

     5. Harden and Patch Infrastructure

AWS won’t set up a bastion host for you, disable root API and secret keys, or password protect .pem files that authenticate powerful accounts. You are in charge of these security steps.

Don’t assume, that a standard Linux or other third-party server image will meet your individual security requirements. The Center for Internet Security offers excellent resources on standard hardening of different infrastructures. In particular, don’t forget to regularly check for and install new infrastructure patches, which plug known holes that hackers could take advantage of.

Preventative and Detective Measures

     6. Log Resources, Especially S3

S3 storage interfaces are choice attack points. Although S3 makes it easy to connect, store, and retrieve data, those same functions make it appealing to hackers.

AWS offers tools to safeguard S3, but again, it’s up to you to use them. Implement alarms for S3 bucket changes, which could minimize accidental bucket exposures.

     7. Forbid services from Directly Accessing the Internet, Particularly Secure Shell.

SSH is often used to facilitate remote login, which can give hackers their “in.” Fortunately, AWS makes it easy to establish groups and virtual private networks within your infrastructure. Use these tools to disallow ingress network traffic from using stateful security groups.

If you must allow online traffic, allow it only from whitelisted visitor IPs and ensure transport security from a secure sockets layer. For added security, arrange for an internal virtual private network with a company-provided client certificate. Remember to add a MFA mechanism, a mobile app. Then, only allow the source IPs of the VPN server to connect to internal applications.

When used well, AWS is a highly secure platform. It’s up to you, however, to make use of the security tools it provides. Compromising millions of users’ personal data — not to mention all the fallout that follows — is an awfully high price to pay for lax Cloud controls.

Original article published on Dataversity

Let's Talk