Another day, another re:Invent session! This time I listened to Stephen Schmidt’s session, “AWS Security: Where we’ve been, where we’re going.” Amongst covering the highlights of AWS security during 2020, a number of newly added AWS features/services were discussed, including: AWS Audit Manager, Cloud Audit Academy and AWS Network Firewall. Stephen also highlighted the 10 places your security group should focus its resources.
In this post, I want to talk about the tactical areas (points 1-7 of the above screenshot taken from Stephen’s session) in a little more detail and the resources where you can learn more about them.
1. Use AWS Organizations
As organizations begin to expand with multiple accounts, it will become increasingly difficult to manage them as separate entities. The more accounts you have, the more distributed your environment becomes, and the associated security risks and exposures increase and multiply.
However, AWS Organizations can provide a means of centrally managing and categorizing multiple AWS accounts that you own, bringing them together into a single organization, which helps to maintain your AWS environment from a security, compliance, and account management perspective.
The primary benefit of AWS Organizations is its ability to centrally manage multiple Accounts from a single AWS account, known as the master account. You can start by inviting your existing accounts to an Organization and then create new accounts directly from the Master Account.
Using service control policies (SCPs), you can secure your AWS Organization. SCPs are different from both identity-based and resource-based policies, which grant permissions to users, groups, and roles. However, SCPs do not actually grant permission themselves. Restrictions made within an SCP set a boundary of permissions for AWS accounts.
For example, let’s say a user within an AWS account had full access to S3, RDS, and EC2 via an identity-based policy. If the SCP associated with that AWS account denied access to the S3 service, then that user would only be able to access RDS and EC2, despite having full access to S3. The SCP would serve to prevent that service from being used within the AWS account and so have the overriding precedence and determine the maximum level of permissions allowed.
So to be clear, an SCP does not grant access. It adds a guardrail to define what is allowed. You will still need to configure your identity-based or resource-based policies to identities, granting permission to carry out actions within your accounts.
Cloud Academy resources:
Course – Securing AWS Organizations with Service Control Policies (SCPs)
AWS resources:
https://aws.amazon.com/organizations/
2. Understand your usage
Here I want to touch on a couple of the services that Stephen highlighted, these being AWS Config and AWS Security Hub.
AWS Config
One of the biggest headaches in any organization when it comes to resource management of IT infrastructure is finding the answers to some of these questions:
- What resources do we have?
- What devices are out there within our infrastructure performing functions?
- Do we have resources that are no longer needed, and therefore, can we be saving money by switching them off?
- What is the status of their configuration?
- Are there any security vulnerabilities we need to worry about?
- How are our resources linked within the environment?
- What relationships are there, and are there any dependencies?
- If we make a change to one resource, will this affect another?
- What changes have occurred on the resources, and by whom?
- Do we have a history of changes for this resource that shows us how the resource changed over time?
- Is the infrastructure compliant with specific governance controls, and how can we check to ensure that this configuration is meeting specific internal and external requirements?
- Do we have accurate auditing information that can be passed to external auditors for compliance checks?
Depending on the size of your deployment with AWS, trying to answer some of these questions can be very time consuming and laborious. AWS is aware that due to the very nature of the cloud, the resources within an AWS environment are likely to fluctuate frequently, along with the configurations of the resources. The cloud, by its very nature, is designed to do so, and so trying to keep up with the resource management can be a struggle. AWS Config fixes this problem.
AWS Config has been designed to record and capture resource changes within your environment, allowing you to perform a number of actions against the data that help to find answers to the questions that we highlighted previously.
AWS Config can:
- Capture resource changes, so any change to a resource supported by Config can be recorded within a configuration item (CI).
- Act as resource inventory, discovering supported resources running within your environment, allowing you to see data about that resource type.
- Store configuration history for individual resources.
- Provide a snapshot in time of current resource configurations.
- Using SNS, it can notify you of any changes.
- Integrate with AWS CloudTrail to help you identify who made the change and when, and with which API.
- Enforce rules that check the compliance of your resource against specific controls.
- Perform security analyses within your AWS environment.
- Identify relationships between resources.
This makes AWS Config very useful when it comes to carrying out security analysis and understanding your resource usage and the changes that have been made.
Cloud Academy resources:
Course – AWS Config: An Introduction
Lab – Compliance check using AWS Config Rules (Managed and Custom)
AWS resources:
https://aws.amazon.com/config/
AWS Security Hub
AWS Security Hub can be used to help you detect and remediate security incidents within your environment. It is designed to help you centralize security findings, alerts, and compliance reports, and is fully integrated with:
- AWS Identity & Access Management
- Amazon Macie
- Amazon GuardDuty
- Amazon Inspector
- AWS Firewall Manager
The findings gathered from these services are presented via a series of interactive graphs, tables, and statistics. In addition to these native AWS services, it can also be incorporated into third-party partner solutions, such as Sumo Logic, Splunk and many more, which you might already be using within your own organization. This enables you to use Security Hub to receive and present data from not only the AWS security services mentioned, but also the security data gathered by tools and services offered by AWS partners that you may already be using as a part of your infrastructure.
AWS Security Hub can be deployed across multiple accounts to centralize your findings. When findings are generated and found, Security Hub will prioritize each one allowing you to focus on the key security threats and weaknesses detected across your multi-account configuration.
The service itself is continually running and provides automatic assessment of compliance and security best practice checks based on the information being ingested from the different feeds. Based on the results of these automatic checks, Security Hub is able to define and present which AWS accounts and resources are most affected by potential security issues, allowing you to rectify and remediate them as soon as possible.
From the Security Hub console, you are able to carry out a number of immediate actions on the findings, such as being able to send the details of the findings to your engineers via email, chat, or even to a ticketing system. As the service is supported by Amazon CloudWatch, you can also configure automated responses based on metric information.
It also integrates with Amazon Detective, and this helps to simplify the effort in analyzing and investigating the root cause of security incidents and suspicious activity, through machine learning and log data received by multiple AWS services.
In summary, AWS Security Hub saves you time by centralizing security findings from multiple accounts, from multiple security services and partner tools, enabling you to quickly identify and spot security threats, weaknesses, and trends. This allows you to provide a more efficient way of maintaining a safe, secure, and protected environment.
AWS resources:
https://aws.amazon.com/security-hub/
3. Use Cryptography Services
In this section, I want to focus on both the AWS Key Management Service and AWS CloudHSM.
AWS Key Management Service
Basically, the Key Management Service is used to store and generate encryption keys that can be used by other integrated AWS services and applications to encrypt your data at rest. So it’s a fundamental security service offered by AWS to help you manage your cryptographic operations.
There are different types of keys used within KMS which perform different roles and functions, such as the CMK, the Customer Master Key, and Data Encryption Keys.
The CMK is the main key type within KMS, and contains the key material that is used to encrypt your data. There are three different types of CMK:
- Customer Managed: These keys offer the greatest level of flexibility and control of the three types. You are able to create, disable or delete the key, configure the key policies associated with your key, configure Grants, and also alter and adjust the key rotation periods and view full usage history of the key.
- AWS Managed: As the name suggests, AWS Managed Keys are managed by AWS. However, you are still able to view these keys within the Management Console, and also audit and track their usage and view their key policies. Because they are managed by AWS, you are not able to modify them (for example, it’s not possible to edit the key policy or control their rotation frequency). They can only be used by the service that creates them and can be identified by their alias (for example, aws/s3 is an AWS managed key used for S3 encryption).
- AWS Owned: These are not visible within the KMS console or anywhere within your account; neither do you have the ability to audit and track their usage. They are essentially abstracted from your AWS account. But of course, some services use this key type to encrypt your data within your account (for example, the S3 Master key used for SSE-S3 encryption).
The CMK NEVER leaves KMS. It is created within KMS and remains within KMS at all times, but it can generate Data Encryption Keys and bucket keys, and these keys can leave KMS and are used by other AWS services to implement encryption, such as S3.
Next we have Data Encryption Keys:
Data keys are created by CMKs; however, they are used outside of KMS to perform encryption against your data, either in your own applications or by other AWS services.
When a request to generate a data key is received by KMS, the associated CMK in the request will create two identical data encryption keys — one will be a plaintext key, and the other will be an encrypted key.
During the encryption process, it’s the plaintext data key that will be used to perform the encryption of your data using an encryption algorithm. Once the encryption has taken place, this plaintext data key will then be deleted and the encrypted data key will be stored and associated with the newly encrypted data.
Cloud Academy resources:
Course – How to use KMS key encryption to protect your data
Lab – Using Amazon Key Management Service to encrypt S3 and EBS data
Lab – Encrypting objects using SSE-KMS
AWS resources:
AWS CloudHSM
Firstly, what does the HSM stand for? Well HSM stands for Hardware Security Module, but what is a hardware security module? It’s a physical tamper-resistant hardware appliance that is used to protect and safeguard cryptographic material and encryption keys.
The AWS CloudHSM service provides HSMs that are validated to Federal Information Processing Standards (FIPS) 140-2 Level 3, which is often required if you are going to be using your CloudHSM for document signing or if you intend to operate a public certificate authority for SSL certificates.
As I mentioned, CloudHSM is a physical device, and it’s important to note that this device is not shared with any other customer, so it’s NOT a multi-tenant device. It is a dedicated single-tenant appliance exclusively made available to you, for your own workloads. The fact that the HSM is based upon single tenancy should not be surprising bearing in mind how sensitive the information is that it contains.
CloudHSM is an enterprise-class service used for secure encryption key management and storage which can be used as a root of trust for an enterprise when it comes to data protection, allowing you to deploy secure and compliant workloads within AWS.
There are a number of different operations that CloudHSM can help you provide. These include:
- The creation, storage, and management of cryptographic keys, allowing you to import and export both asymmetric and symmetric keys
- The ability to use cryptographic hash functions to enable you to compute message digests and hash-based message authentication codes, otherwise known as HMACs
- Cryptographic data signing and signature verification
- Using both asymmetric and symmetric encryption algorithms
- Ability to generate cryptographically secure random data
Cloud Academy resources:
Course – Getting started with CloudHSM
AWS resources:
https://aws.amazon.com/cloudhsm/
4. Federation for human access
Sometimes it’s not feasible, or even possible due to limitations, to create IAM accounts for everyone who needs to access your AWS resources, as you might have hundreds or even thousands of users needing different access. As a result, you could implement Federated access to help you simplify access management for your users within a big organization. In this section, I want to highlight AWS federated access, which will allow you to create a single sign-on (SSO) approach, and Amazon Cognito, a service enabling you to configure and grant access through Mobile devices.
Federated access is a great method of centralizing account management to use your AWS resources without having a requirement of using IAM user credentials. Instead, access credentials are federated by an identity provider (IdP). This could be your own enterprise federation by using your MS Active Directory account, or alternatively, you could use a social identity provider, such as Amazon, Google, or Facebook, which are all well-known social IdPs.
Using your own enterprise MS-AD account, you could create an SSO approach using SAML, Security Assertion Markup Language, allowing users to gain access to your AWS Management Console. SAML provides an effective and secure way to exchange authentication between an IdP, such as MS-AD, and a SAML consumer, your AWS account, specifically IAM roles, with the help of the Security Token Service (STS). This would then enable authenticated MS-AD users to assume IAM roles, providing temporary access and permissions to access the AWS Management Console.
Using a social IdP (Amazon, Facebook, Google, etc.) allows you to authenticate users without your own corporate MS-AD. Perhaps you don’t know which users will need access. You might have a mobile game that requires access to your resources to log high scores and team data, but you need the users to authenticate first. In this scenario, social federation can help.
Social federation enables you to create your applications, allowing them to request temporary credentials. These temporary credentials are associated with an IAM role which provides the relevant permissions to access any resources required.
Cloud Academy resources:
Course – AWS Identity Federation
Course – AWS: Overview of Identity & Access Management (IAM)
AWS resources:
https://aws.amazon.com/identity/federation/
Amazon Cognito
This service allows users to log in directly with their user credentials that are maintained in Amazon Cognito on behalf of your web and mobile applications. It also allows sign-in through third-party social networking applications such as Facebook, Amazon, Google, or Apple, and other Identity providers.
Amazon Cognito provides important features to achieve different use cases in user management and authentication in web applications and mobile applications.
Let us have a quick look at Amazon Cognito features:
- Managing user directory – Amazon user pools function as user directories to store user’s personal data such as login ID, password, etc. This information will be used during sign-in for validation. As this is a cloud service from AWS, we need not worry about managing infrastructure, setup, and scaling the service. We could store even millions of user details if required.
- Integrate with social network logins and federated identity providers – Amazon Cognito accepts and allows sign-in for users who have an account in social networking sites such as Facebook, Google, or PayPal without the need to create a new account in Amazon Cognito. This feature is also available if a user signs in through an external identity provider (IdP) that is compatible with OpenID Connect and SAML 2.0.
- Standards-based authentication – OpenID Connect, OAuth 2.0, and SAML 2.0.
- Security for your apps and users – HIPAA eligible and PCI DSS, SOC, and ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, and ISO 9001 compliant.
- Simple integration with your app – Amazon Cognito provides a software development kit (SDK) for Android, iOS, and Javascript to call APIs that implement user sign-up and sign-in functionality. In addition to providing simple APIs, Amazon Cognito also comes with a default and customizable UI page for user sign-up and sign-in.
- Role-based access control for AWS resources – An AWS IAM role has specific permissions to access AWS resources. You could use identity pools to map users to specific roles and authorize their access to AWS resources.
Cloud Academy resources:
Blog – What is Cognito in AWS?
Lab – Manage Authentication with Amazon Cognito
AWS resources:
https://aws.amazon.com/cognito/
5. Block public access on accounts
One of the biggest pitfalls that I have seen by some organizations has been the lack of basic security controls, and specifically those that are placed around Amazon S3 buckets.
Over the years, we have all seen news articles of instances where organizations have left themselves exposed by leaving customer and confidential information within unprotected AWS buckets allowing access to the general public. This has resulted in huge security breaches and has left those organizations answering difficult questions in addition to financial penalties.
As a response to the mistakes made by these organizations and the resulting repercussions, AWS has continually worked to improve the security around Amazon S3 to prevent instances such as these from happening again.
When creating a new bucket in S3, there is an option that’s dedicated to helping you protect your bucket from public access, and by default there is a checkbox that’s ticked which blocks ALL public access.
If you do need some public access to this bucket, then you can turn off this setting and it allows you to select four additional options that can be used to filter public access.
So you can:
- Block public access to buckets and objects granted through NEW access control lists
- Block public access to buckets and objects granted through ANY access control lists
- Block public access to buckets and objects granted through NEW public bucket or access point policies
- Block public and cross-account access to buckets and objects through any public bucket or access point policies
This allows you to allow some public access based on certain security controls and block others. You don’t have to select any, or you can have a combination of any of the four selected.
Because ALL public access to this bucket is blocked, you will not be allowed to configure any kind of public or cross-account access via the Bucket policy or ACL.
Cloud Academy resources:
Course – Increasing your security posture when using Amazon S3 (Coming Jan 2021)
Course – Introduction to Amazon S3
Course – Using Amazon S3 bucket properties and management features to maintain your data
AWS resources:
6. Edge protection on external resources
Amazon CloudFront
Amazon CloudFront is AWS’s fault-tolerant and globally scalable content delivery network service. It provides seamless integration with other AWS services to provide an easy way to distribute content.
Amazon CloudFront speeds up distribution of your static and dynamic content through its worldwide network of edge locations. Normally when a user requests content that you’re hosting without a CDN, the request is routed back to the source web server, which could reside in a different continent than the user initiating the request. However, if you’re using CloudFront, the request is instead routed to the closest edge to the user’s location which provides the lowest latency to deliver the best performance through cached data.
So Amazon CloudFront provides a means of distributing the source data of your web traffic closer to the end user requesting the content via AWS edge locations as cached data.
AWS edge locations are sites deployed in major cities and highly populated areas across the globe. While edge locations are not used to deploy your main infrastructure, such as EC2 instances or EBS storage, they are used by AWS services such as AWS CloudFront to cache data and reduce latency for end user access. For example, you may have your website hosted on EC2 instances or S3 within the Ohio region, with an associated CloudFront distribution. When a user accesses your website from Europe, they would then be redirected to their closest edge location in Europe, where cached data could be read off your website. This significantly reduces latency.
CloudFront uses distributions to control which source data it needs to redistribute and to where. When configuring your distributions, you will be required to enter your origin information. This is essentially where the distribution is going to get the data to distribute across edge locations.
You can also select a host of different caching behavior options, defining how you want the data at the edge location to be cached via various methods and policies, and which edge locations you want your data to be distributed to.
You can also define if you want your distribution to be associated with a web application firewall (WAF) access control list for additional security and web application protection.
Cloud Academy resources:
Course – Introduction to DNS and Content Delivery on AWS
Lab – Serve your files using the CloudFront CDN
Lab – Configuring a Static Website with S3 and CloudFront
AWS resources:
https://aws.amazon.com/cloudfront/
AWS Web Application Firewall (WAF)
The AWS Web Application Firewall is a service that helps to prevent websites and web applications from being maliciously attacked by common web attack patterns such as SQL injection and cross-site scripting. It also integrates with Amazon CloudFront distributions, the Application Load Balancer, and the API Gateway to analyse requests over HTTP or HTTPS. The services work together to filter both HTTP and HTTPS by distinguishing between legitimate and harmful inbound requests that will then either be allowed or blocked.
AWS WAF is comprised of a number of different components, including:
- Web Access Control Lists (Web ACLs): This is the element within WAF that is used to help you protect your resources. Each ACL contains another component: rules, which inspect the incoming requests.
- Rules: Each rule contains specific statements that are used to filter any incoming requests, and these rules are added to a Web ACL. Upon inspecting the traffic and determining if it matches the rule If a match is found, the rule will indicate if the traffic should be “Allowed” or “Blocked.”
- Rule Groups: These allow you to group your rules together to form a defined set of security standards or best practices allowing you to quickly and easily assign them to different Web ACLs
Cloud Academy resources:
Course – Protecting Web Apps with AWS WAF, Shield and Firewall Manager
AWS resources:
7. Patch and Measure
AWS Systems Manager is a great service, providing a method of easily performing operational actions against your instances without having to remotely connect to them first – and this can be achieved at scale. Providing a single dashboard helps your operational teams gain insight into your EC2 resources, widening the visibility of your fleet. This helps to view configurations, patching levels of your instances, in addition to specific software installed on the instance. Using Patch baselines, Systems Manager can scan your instances to ensure they remain compliant.
The Patch Manager within Systems Manager provides a method of automating and managing any patch updates that are required across your whole fleet of EC2 instances within your environment. As a result, it enables you to quickly deploy newly released patches that could protect your resources from any new vulnerabilities that have been detected. Maintaining the best level of patch protection is so important, and to help you stay on top of this, Patch Manager has the ability to scan your instances to see which key patches are missing that could be exposing your resources unnecessarily. If instances are discovered to have missing patches, Patch Manager can be configured to automatically update any missing patches for you.
Patch Manager follows a four-stage process:
- Use default patch baselines, or create your own
- Organize instances into patch groups (optional)
- Automate the patching schedule by using maintenance windows
- Monitor patch status to ensure compliance
AWS resources:
https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html
Summary
Ultimately, when working with AWS, security still remains a priority, and with the huge range of AWS services that are available today, there is no reason to overlook security at any stage throughout your deployment. There are services to help you protect your environment at every step of your cloud journey, and it’s critical that you take time to learn about these services and how they can help architect your environment, allowing you to implement and build a robust security posture.
For more information on AWS security services, see our existing learning paths:
