Good AWS Security Hygiene: Limit Risk With Security by Design

A misconfigured data bucket in AWS Simple Storage Service (S3) led to a Republican contractor’s database of nearly every voter being left exposed on the Internet for 12 days, according to CRN. This news presents an unfortunate reminder of why good AWS security hygiene is important to designing, building and managing AWS environments. In this spirit, we’d like to explore two basic AWS best practices that when built-in can help stave off extreme events like this.


To understand these tenets at a deeper level, however, let’s first quickly examine what is S3, what is an S3 bucket and how does configuration come into play? Put simply, S3 is storage for the Internet. S3 is an object storage with a simple web service interface that allows users to store and retrieve any amount of data from anywhere on the web. People like to use S3 for a variety of reasons — from storing cloud-native apps to a bulk repository. An S3 bucket is a container for storing data in S3. You can store as much or as little data in an S3 bucket as you like, and you can upload as many objects as you like into a bucket. (Each object can contain up to 5 TB of data.)

It is important to note here that S3 buckets have policies that can be configured to manage permissions; it is these permissions that grant or deny access to people who want to download data from the S3 bucket. You can also configure bucket policies to control access to your data using AWS IAM.

As you can see, AWS has gone to lengths to make S3 simple yet powerful and secure. Unfortunately, the power for granular control can also sometimes translate into misconfiguration.

This database was left exposed to the world because it was reportedly left open to the internet. Such wide open access to an S3 is only granted in two cases in our experience: (1) when an organization is intending to host a public website there, or (2) when an engineer is trying to test something and wants to avoid the hassle of using any authentication or passwords. The latter often leads to people forgetting that they left something open to the world, and such data eventually gets in the wrong hands.

Authentication & Passwords

Authentication at large and passwords are like flossing; not many people enjoy them, but they are both an important part of proactive health. Considered a frontline of security, authentication should be used consistently, should meet defined organizational standards and access should be revoked immediately when not required.

Security by Design

One of the approaches our AWS Consultants consistently take is Security by Design. By building security in from the beginning–rather than as an afterthought–security rules, processes and controls are inherent to the system. Authentication and passwords are an integral part of Security by Design. (While not all infrastructure is built with this approach, it can be remedied with an AWS security assessment where weaknesses are identified and addressed with an action plan.)

AWS IAM is part of a Flux7 standard build as it allows us to securely control access to AWS services and resources; IAM also allows us to create and manage AWS users and groups. With permissions, we can determine who has access (or is denied access) to given AWS resources. Additional security benefits of IAM include:

• IAM provides flexible credential management, giving you control to enforce stricter security standards like Multifactor Authentication (MFA) for users who access the AWS Management Console or use APIs. For example, for a financial services firm who had strict security parameters, we used AWS IAM to institute MFA at the firm, thereby further tightening security controls and ensuring it met its internal security and regulatory compliance requirements.
• IAM allows organizations to leverage an existing identity system, like Active Directory (AD), to streamline management and more easily grant employees access based on their role within the organization. We have done this work for many organizations now, linking AD or another service to assign permissions and easily update systems with new employee arrival — and ensure removal from the system when employees depart.

Ideal Design

With 1.1TB of data and details of 198 million Americans, we surmise that the intended consumer of this data store was not a person at all, but rather a data analytics engine. In that case, the best design would have been to configure the S3 bucket policy to control access via IAM roles, granting access only to the bucket owner and the computing system that needed the data for its job(s). This design also negates the need for passwords and ensures strict access controls.

Misconfiguration

The other issue at play in this case was misconfiguration. While in this event it was a S3 bucket that was misconfigured, this issue can affect any element in a technology stack. As such, configuration plays an important role in sound security hygiene and is one of the reasons that Flux7 consultants use our DevOps methodology to place a strong emphasis on automation as it reduces the potential for human error and can be more effective at flagging errors. Most organizations have corporate policies surrounding certain configuration rules and it’s important that these policies are followed — and enforced. (These policies can vary widely depending on the security, risk, and compliance mandates a company faces–from AWS PCI compliance to HIPAA, FISMA, ISO 27001 and more–and resources for these individual mandates should be sought out.)

Security by Design

To this end, it’s important to know when changes happen so that you can immediately correct issues related to governance, risk and compliance (GRC) and/or that leave systems vulnerable. Both of which can result in fines, bad PR, lost customer confidence and more. However, because there is so much detail to be reviewed, automation is necessary to monitor for and flag troublesome configuration changes.

As a result, the AWS DevOps consultants here at Flux7 use AWS Config Rules to monitor infrastructure once it is deployed. AWS Config Rules continuously monitor configurations in the infrastructure and will alert you via email to any change occurs that puts the infrastructure out of compliance. Conversely, knowing that your systems remain in compliance, that they haven’t changed from a known, good baseline, is critical. In addition, if you need to examine a specific element, the AWS Config Rules auditing feature allows you to to select a specific resource and get a view into the configuration changes made to it on a timeline.

While security can (and at times arguably should) get very sophisticated, according to the 2017 Verizon Data Breach Investigations Report, 81% of hacking-related breaches leveraged either stolen, weak or non-existent passwords. As such, it’s important that basic security hygiene, like that discussed here, be considered as your frontline against potentially damaging events. Traditional security methods do not always scale to the cloud. As a result, the Flux7 AWS experts recommend building security in from the beginning using AWS best practice cloud security principles . For additional examples on how to build security into your AWS environment:

• RentACenter Builds Innovation, Availability and Security-By-Design
• Flux7 Improves Security in AWS with Effective Secret Management
• TN Marketing Scales Performance, Elasticity and Security through AWS CloudFront, ELB and WAF expertise
• Digital Financial Services Provider Grows Robustness, Security, and Optimizes AWS Costs