EBOOK
AWS Security
Checklist
Identity, Data, Workload and Platform Security
for the Well-Architected Framework
Table of Contents
Introduction
03 AWS Shares Responsibility Model
Amazon Web Services (AWS), the top public cloud service provider, offers
a broad set of global compute, storage, database, analytics, application, 04 AWS Shares Responsibility Table
and deployment services that help enterprises move faster, lower IT costs,
05 Top AWS Cloud Security Challenges
and scale applications. While this is great for development, AWS remains
one of the biggest cloud security threats in 2022, as companies face more 07 AWS Cloud Security Checklist
sophisticated threats.
09 About Sonrai
Environments are frequently at risk from cybercrime. At the same time,
companies are facing rising internal security issues due to misconfigurations
and mismanagement. In one recent high-profile example, a misconfigured
AWS S3 bucket created a vulnerability in software developed by Turkish
airline Pegasus exposing 6.5 terabytes of data.
Research from ID Watchdog shows that insiders are present in 60% of cyber
breaches — and 44% of root causes can be attributed to negligence.
AWS can be incredibly complicated, and when you are developing
fast in the platform, it’s easy to make small mistakes that can lead to
catastrophic consequences.
This document guides AWS customers by recommending best practices for
the highest protection level for their AWS infrastructure and the sensitive
data stored in AWS.
2
AWS Shared Responsibility Model
Like most cloud providers, AWS operates under a shared Customer Responsibility
responsibility model. AWS takes care of the security ‘of’ the cloud AWS customers are responsible for the secure usage of AWS
while AWS customers are responsible for security ‘in’ the cloud. services that are considered unmanaged. For example, while AWS
has built several layers of security features to prevent unauthorized
AWS has made platform security a priority to protect customers’
access to AWS, including multi-factor authentication, it is the
critical information and applications taking responsibility for its
customer’s responsibility to make sure multifactor authentication is
infrastructure’s security. AWS detects fraud and abuse and responds
turned on for users, particularly for those with the most extensive
to incidents by notifying customers. However, the customer is
IAM permissions in AWS.
responsible for ensuring their AWS environment is configured
securely and data is not shared with someone it shouldn’t be shared Furthermore, the default security settings of AWS services are often
with inside or outside the company, identifying when an identity the least secure. Correcting misconfigured AWS security settings,
person or piece of compute misuses AWS, and enforcing compliance therefore, is a low hanging fruit that organizations should prioritize to
and governance policies. fulfill their end of AWS security responsibility.
AWS Responsibility As enterprises continue to migrate to or build their custom
AWS is focused on the security of AWS infrastructure, including applications in AWS, the threats they face are no longer isolated like
protecting its computing, storage, networking, and database services the old world of on-premises applications as identities are the new
against intrusions because it can’t fully control how its customers perimeter. Preventing many of these threats falls on the shoulders
use AWS. AWS is responsible for the security of the software, of the AWS customer. So how are you securing your data? Your
hardware, and the physical facilities that host AWS services. Also, security boundaries. As enterprises continue to migrate to or build
AWS takes responsibility for the security configuration of its their custom applications in Azure, the threats they face are no
managed services such as AWS DynamoDB, RDS, Redshift, Elastic longer isolated like the old world of on-premises applications. Under
MapReduce, WorkSpaces, and others. this new paradigm, preventing many of these threats falls on the
shoulders of the Azure customer. So how are you securing your data?
3
AWS Responsibility Reminder Table
Below are areas of responsibility to help you govern and secure your AWS:
Customer AWS
Preventing or detecting when an AWS account has been compromised
Preventing or detecting a privileged or regular AWS user behaving in an insecure manner
Business continuity management (availability, incident response)
Protecting against AWS zero-day exploits and other vulnerabilities
Providing environmental security assurance against things like mass power outages, earthquakes,
floods, and other natural disasters
Providing physical access control to hardware/software
Configuring Azure Managed Services in a secure manner
Database Patching
Ensuring network security (DoS, man-in-the-middle (MITM), port scanning)
Ensuring AWS & custom applications are being used in a manner compliant with internal and external policies
Updating guest operating systems and applying security patches
Restricting access to AWS services or custom applications to only those users who require it
Configuring AWS services (except AWS Managed Services) in a secure manner
Preventing sensitive data from being uploaded to or shared from applications in an inappropriate manner
4
Top AWS Cloud Security Challenges
Risks to applications running on AWS and the data stored within it can take many forms:
Compromise of AWS Software Development Lacks
AWS has made significant investments in security to Security Input
protect its platform from intrusion. However, the slight Unfortunately IT security isn’t always involved in the
possibilty remains that an attacker could compromise development or security of custom applications.
an element of the AWS platform and either gain access When it comes to their development, IT security is
to data, take an application running on the platform often circumvented, making the task of securing these
offline, or permanently destroy data. applications more difficult.
Third Party Account Compromise Shadow IT
According to the Verizon Data Breach Investigations Shadow IT uses information technology systems,
report, 1% of data breaches are caused by third- devices, software, applications, and services
parties. However, these breaches are very noteable without explicit IT department approval. It has
when they happen, like the third party data breach
grown exponentially in recent years with the
with Volkswagen Group of America, Inc. affecting 3.3
adoption of cloud-based applications and
million customers.
services. Compute departments other than
Sensitive Data Uploaded Against Policy the central IT department, to work around the
& Regulation shortcomings of the central information systems
create a hidden risk.
Many organizations have industry-specific,
regional regulations, or internal policies that Manually Managing Access Rights
prohibit certain data types from being uploaded
Keeping track of which users can access an
to the cloud. In some cases, data can be
application manually creates risk. You can’t
safely stored in the cloud, but only in specific
detect common privilege escalation attacks
geographic locations (for example, a data center
across your infrastructure manually. Also, you can
in Ireland but not in the United States).
create risk by giving too many admin rights to
virtual machines and containers.
5
Ephemeral Compute Pours Over Your Data Insider Threats & Privileged Identity Threats
With container orchestration, the typical lifetime of a The average enterprise experiences 10.9 insider
container is 12 hours. Serverless functions - already threats each month and 3.3 privileged user
adopted by 22% of corporations - come and go in threats each month. These incidents can include
seconds. Data is the digital era’s oil, but the oil rigs are malicious and negligent behavior— ranging from
ephemeral and countless in this era. EC2 instances,
taking actions that unintentionally expose data to
spot instances, containers, serverless functions,
the internet to employees stealing data.
admins, and agile development teams are the
countless fleeting rigs that drill into your data. Increase in Supply Chain
Unsecured Storage Containers A lack of understanding in the chain of custody
in your most-often-used projects can create a
The news is filled regularly with attacks on
risk. Developers have lengthened their software
misconfigured cloud servers and the leaked data that
criminals obtain from them. This happens because of supply chains by using more open-source tools.
human error. Setting a cloud server with loose or no This means you must understand the trust
credentials and then forgetting to tighten them when relationship and protect the complete path that
the server is placed into production is a software takes through your entire development
common mistake. process and lifecycle. Lack of visibility in these
trust relationships leads to unnecessary risk.
Cloud Data Sprawl
Gone are the days of a limited selection of Root Account Access
manageable data stores. Innovations in agile cloud Frequently, organizations still use an active
development have led to an explosion of new data root account and allow access via access keys.
store options, with teams utilizing Amazon MongoDB, The root is the account that has access to
Elasticsearch, Dynamo DB, HashiCorp Vault, and many all files and commands across the operating
more. Adding these to object stores makes it self-
environment. Using a root access account is
evident that new corporate infrastructures do not
extremely dangerous.
have a physical or logical concept of a ‘data center.’
This innovation can create cloud sprawl, where an
organization has an uncontrolled proliferation of its
cloud instances, services, or identities.
6
AWS Cloud Security Checklist
Amazon has built a set of security controls for its customers to use across AWS services, and it is
up to the customer to make the most of these built-in capabilities. Here are some best practices
security experts recommend you follow:
Enable CloudTrail logging across all of Enable IAM users for multi-mode access. Control inbound and outbound traffic
AWS. to your EC2 with structured security
Attach IAM policies to groups or roles.
groups that don’t have large ranges of
Turn on CloudTrail log file validation.
Rotate IAM access keys regularly, and ports open.
Enable CloudTrail multi-region logging. standardize on the selected number of Configure EC2 security groups to
days.
Integrate CloudTrail with CloudWatch. restrict inbound access to EC2.
Set up a strict password policy.
Enable access logging for CloudTrail Protect EC2 Key Pairs.
S3 buckets. Set the password expiration period to Avoid using root user accounts.
90 days and prevent reuseCustomer
Enable access logging for Elastic Load Visualforce pages with standard headers. Lock root user accounts and prevent
Balancer (ELB).
anyone in the organization from
Don’t use expired SSL/TLS certificates.
Enable Redshift audit logging. accessing them.
User HTTPS for CloudFront distributions.
Activate Virtual Private Cloud (VPC) Use secure SSL ciphers when
flow logging. Restrict access to CloudTrail buckets. connecting between the client and
ELB.
Require multi-factor authentication Encrypt CloudTrail log files at rest.
(MFA) to delete CloudTrail buckets. Use secure SSL versions when
Encrypt Elastic Block Store (EBS)
connecting between client and ELB.
Turn on multi-factor authentication for database.
the “root” account.
Provision access to resources using IAM Use a standard naming (tagging)
Turn on multi-factor authentication for roles. convention for EC2.
IAM users.
7
AWS Cloud Security Checklist, cont.
Encrypt AWS’ Relational Database Disable access for inactive or unused IAM Involve IT security throughout the
Service (RDS). users. development process.
Ensure access keys are not being Remove unused IAM access keys. Grant the fewest privileges as possible
used with root accounts. for application users.
Delete unused SSH Public Keys.
Use secure CloudFront SSL versions. Enforce a single set of data loss
Restrict access to Amazon Machine
prevention policies across custom
Enable the require_ssl parameter in Images (AMIs).
applications and all other cloud
all Redshift clusters.
Restrict access to EC2 security groups. services.
Rotate SSH keys periodically.
Restrict access to RDS instances. Encrypt highly sensitive data such as
Minimize the number of discrete protected health information (PHI) or
Restrict access to Redshift clusters. personally identifiable information
security groups.
(PII).
Restrict access to outbound access.
Reduce the number of IAM groups.
Control access to S3 buckets.
Disallow unrestricted ingress access on
Terminate unused access keys.
uncommon ports. Don’t create any public access S3
Rotate your keys regularly. This will buckets.
Restrict access to well-known ports such
reduce the risk of a compromised
as CIFS, FTP, ICMP, SMTP, SSH, Remote Activate S3 access logging.
key. Do this even if someone has a
desktop.
“read-only” API key.
Inventory and categorize all existing
Remove access keys that haven’t
custom applications by the types of data
been used in the last 90 days. (You
stored, compliance requirements, and
can always create a new one.)
possible threats they face.
8
About Sonrai Security
Sonrai Security delivers an enterprise identity and data governance
platform for AWS, Azure, Google Cloud, and Kubernetes. The Sonrai Dig
platform is built on a sophisticated graph that identifies and monitors
every possible relationship between identities and data that exists inside
an organization’s public cloud. Dig’s Governance Automation Engine
automates workflow, remediation, and prevention capabilities across cloud
and security teams to ensure end-to-end security. The company has
offices in New York and New Brunswick, Canada, backed by ISTARI, Menlo
Ventures, Polaris Partners, and Ten Eleven Ventures.
GET STARTED
Ready to Secure your Azure Environment?
Feeling lost or overwhelmed? Don’t worry. New and mature organizations are facing
these concerns alike - and we’re here for you. Our cloud security experts are
standing by and ready to help. Contact Sonrai Security to start your conversation.
Contact Sonrai Security
sonraísecurity.com | info@sonraísecurity.com | 646.389.2262 9
Legal Notice
This document is provided for informational purposes only. It represents Sonrai Security
practices as of the date of issue of this document, subject to change without notice.
Customers are responsible for making their own independent assessment of the information
in this document and any use of Microsoft's products or services, each of which is provided
"as is" without warranty of any kind, whether express or implied. This document does not
create any warranties, representations, contractual commitments, conditions, or assurances
from Sonrai Security, its affiliates, suppliers, or licensors. The responsibilities and liabilities
of Microsoft to its customers are controlled by Microsoft agreements, Sonrai Security
agreements, and this document is not part or, nor does it modify, any agreement between
Microsoft, Microsoft Azure, Sonrai Security, and its customers.
10
© 2022 Sonrai Security. All rights reserved. Sonrai cloud security platform, products and services are covered
by U.S. Patent Nos. 10,728,307 and 11,134,085, together with other domestic and international patents pending.
All rights reserved. re:0622KS
