AWS Security Maturity Roadmap

Sources

This page is a summary of the great paper published by SummitRoute:

Stage Description
Stage 1: Inventory
  • Identify all AWS accounts in the company and their points of contact (details)
  • Integrate AWS accounts into AWS Organizations
  • Secure root users
  • Have an AWS account for Security
  • Create budget alarms
Stage 2: Have Backups
Stage 3: Visibility and Initial Remediation
  • Turn on CloudTrail for all accounts to send their logs to the Security account
    • CloudTrail logs should be turned on via the Organization root via an organization trail (source)
    • By using the organization trail you not only have a centrally configured CloudTrail that is enabled by default for all newly created accounts in the Organization, but also these CloudTrail logs cannot be turned off by the child accounts
    • Create an S3 bucket in the Security account, and then from the Master account, enable the CloudTrail logs
    • Setup permissions on this bucket for your organization to send logs to it, and setup read-only privileges for the child accounts to be able to view their own logs
  • Turn on GuardDuty and IAM Access Analyzer for all accounts to send alerts to the Security account
    • Can be enabled in the Organization Master account via the Delegated Admin concept
    • It allows to specify another account, such as your dedicated Security account, to enable GuardDuty across your organization and for all new accounts in the org
  • Create an IAM role in every account that grants view access into the account from the Security account
  • Run a one-time scanning tool to identify tactical remediations (e.g., CloudMapper, Prowler, ScoutSuite)
  • Turn on S3 Public Block Access to disable buckets and their objects from being made public
  • Develop an account initialization script and new account creation process
    • What team should do that and for what needs?
    • Where should the root password and MFA be kept?
    • What email address pattern should be used for the account?
    • Who should be on the distribution list of that email address? What phone number and billing information do these accounts tie back into it?
    • CloudFormation StackSets with Organizations can be used in order to establish this baseline
Stage 4: Detection
  • Detect issues from logs and events and enable investigations of logs
    • With CloudTrail logs, GuardDuty and Access Analyzer events going to an S3 bucket in the Security account, you should integrate them into a SIEM for monitoring and alerting
    • Ensure you can at least do the following:
      • Receive a notification about a GuardDuty alert from any of your accounts and any region you enabled it in
      • Be able to alert on Access Denied errors from CloudTrail logs
      • Be able to search through CloudTrail logs to see all of the actions performed by a principal during a time period
    • If you do not give people access to your SIEM to analyze their own CloudTrail events, you should set up Athena tables for people to use to more easily query and analyze their events
  • Consider turning on more logging sources (full list of known log sources on AWS):
    • VPC DNS queries
    • VPC Flow Logs
    • CloudTrail S3 access and Lambda invokes
    • S3 access logs
    • Load balancers
    • CloudFront
  • Detect credential compromise (source)
  • Perform regular scanning of the accounts for security issues (e.g., CloudMapper, Config)
  • Document your security guidelines for your company
Stage 5: Secure IAM Access
  • Use SSO for access
    • You can either have a single "Identity" AWS account that users log into via SSO and then assume into roles from there to the different accounts, or you can have them SSO directly into the different AWS accounts they have access to
    • Your SSO solution should be enforcing strong password policies and MFA access, but if you do have any human IAM users, you should enforce these restrictions in your AWS account of having a strong password policy and apply the policy at Self-Manage an MFA Device to these users which enforces MFA even on access key usage
  • Remove all IAM users in favour of IAM roles (to avoid static Access Keys)
    • If you do have requirements to use IAM access keys, they should be using aws-vault
    • For all access keys, you should create a single "Identity" account that they will then assume roles from in order to access other accounts
    • This ensures you have only a single account with IAM access keys and allows you to setup alerts if the access keys are used without assuming roles into other accounts
  • Remove all unused IAM roles
  • Reduce the privileges of service roles to necessary services
    • Use Access Advisor to reduce the privileges of the IAM roles to only those services they use
  • Implement pre-commit hooks for secret detection (like detect-secrets)
Stage 6: Reduce Attack Surface
  • Apply SCPs (Service Control Policies) (see examples)
    • SCPs can be used to restrict actions an account can perform
    • The SCPs to apply should include:
      • Deny root user access
      • Allow only approved regions
      • Allow only approved services
      • Deny ability to create IAM access keys
      • Require the use of IMDSv2 (see metabadger: a tool to help prevent SSRF attacks on AWS EC2 via automated upgrades to the more secure Instance Metadata Service v2)
      • Deny ability to leave Organization
      • Deny ability to make a VPC accessible from the Internet that isn't already for specific accounts
      • Deny ability to disrupt GuardDuty, Access Analyzer, CloudTrail, S3 Public Block Access, and other security services
      • Deny ability to disrupt CloudWatch Event collection or other aspects of your monitoring and alerting pipeline
      • Deny ability to modify important IAM roles, such as one used for Stack Sets, incident response, or vendors performing monitoring
  • Have no publicly facing EC2s or S3 buckets
    • EC2s and S3 should not be publicly accessible, but instead should have an ELB or CloudFront in front them
    • This has a number of benefits including being able to make use of AWS Shield (DDoS protection), AWS WAF, and a more standardized means of logging access
    • If you do have ports open, such as SSH, this also ensures a level of abstraction between the public web service and the public SSH service to mitigate the likelihood of a targeted attack there
    • CloudMapper's report and public commands will show you what public resources you have
    • You should also look into using SSM Session Manager instead of SSH as it removes the need to manage SSH keys and provides better auditing
  • Enforce IMDSv2 on all EC2s
    • The way in which EC2s obtain their credentials for their IAM roles is through the Instance MetaData Service (IMDS)
    • If an attacker can get the EC2 to access this service and return the results (such as through SSRF or a proxy service), they can take-over the IAM role
    • Ensure your EC2s enforce the use of the newer IMDSv2
  • Restrict Security Groups
Stage 7: Reproducibility and Ownership
  • Use Infrastructure as code and perform static analysis
  • Control AMI and package sourcing
    • Not all of the public AMIs (Amazon Machine Images) used to create EC2s are vetted by AWS, and there is not an easy way to identify the trust-worthiness of the source account ID that an AMI comes from
    • You should identify what AMIs you want to be allowed to run in your environment, as well as for any lambda layers, container images, and other resources
    • One strategy you should consider is building all of your AMIs yourself. This would mean that every code release would be a pre-built AMI (like Netflix)
    • Alternatively, you can deploy code and updates using something like salt, ansible, puppet, chef, or another solution
  • Apply tagging strategy (deprecated)
    • When a problem is found with a resource, you want to be able to quickly identify who the owner is, without looking through the CloudTrail logs
    • You can audit accounts and resources for compliance with tagging guidelines at the Organization level with Tag Policies and also enforce the policies
Stage 8: Enhance detection and least privilege refinement
  • Implement real-time monitoring
    • CloudTrail logs take 15 minutes to appear in S3
    • You can use CloudWatch Events to monitor events in near real-time: requires setting up a CloudWatch Event Rule in every account/region and then aggregating these events
    • Note that CloudWatch Events do not record List, Describe, and Get calls so it is not a complete replacement for some rules you might have on the monitoring of the CloudTrail logs going to S3
  • Implement automated remediation
    • In cases where actions cannot be restricted by SCPs, you can setup automated remediations to correct issues
    • This can mean automatically:
      • removing inactive IAM Roles after some time period
      • removing unused privileges via something like RepoKid
      • making network resources private that have been made public that shouldn't be
  • Refine IAM policies
    • Policies should have specific Actions, Resources, and include Conditions
    • Stars ("*") should be avoided unless required by the Action
    • Avoid using AWS provided Managed IAM policies because they are not restricted enough
    • To help reduce the scope of policies to only specific actions, you can use Client Side Monitoring (CSM) as described in Record AWS API calls to improve IAM Policies
  • Deploy honey tokens
Stage 9: Secure network communications
  • Move all non-public network resources into private subnets and proxy outbound requests so you can filter and block them
    • SCPs can be used to ensure no new subnets, Internet Gateways, or other networking components can be created → can ensure that some accounts only have private subnets
    • If you have publicly facing ELBs in front of EC2s, you can move the EC2s to private subnets. You can then restrict the network communication they initialize, and can run that outbound traffic through proxies in order to better monitor and restrict it
  • Restrict egress network traffic
    • Use AWS PrivateLink to restrict access to resources to only those coming from certain VPCs, by setting their resource policies to only allow access from VPC endpoints
    • You may need to have a proxy to access third-party vendors, but you should be able to restrict egress network traffic so nothing calls out to the Internet, or does so only through a proxy
    • This is not only applicable to EC2s, but also Lambdas and containers
    • AWS Network Firewall can assist with monitoring and protecting networks
Stage 10: Incident Preparation
  • Limit the blast radius of incidents
  • Practice responding to incidents