Skip to content

Instantly share code, notes, and snippets.

@Cybernewbies

Cybernewbies/Cloud Security Orienteering Checklist.md

Forked from ramimac/Cloud Security Orienteering Checklist.md
Created September 25, 2021 12:24
Show Gist options
  • Save Cybernewbies/a675ae38f4f58af80b16ba06022296c0 to your computer and use it in GitHub Desktop.
Save Cybernewbies/a675ae38f4f58af80b16ba06022296c0 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. @ramimac ramimac revised this gist Aug 18, 2021. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions Cloud Security Orienteering Checklist.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    Cloud Security Orienteering: Checklist
    by Rami McCarthy
    via [TL;DR sec](https://tldrsec.com)
    Cloud Security Orienteering: Checklist
    by Rami McCarthy
    via [TL;DR sec](https://tldrsec.com)

    How to orienteer in a cloud environment, dig in to identify the risks that matter, and put together actionable plans that address short, medium, and long term goals.

  2. @ramimac ramimac revised this gist Aug 18, 2021. 1 changed file with 41 additions and 39 deletions.
    80 changes: 41 additions & 39 deletions Cloud Security Orienteering Checklist.md
    View file
    Original file line number Diff line number Diff line change
    @@ -10,7 +10,7 @@ Based on the [Cloud Security Orienteering](https://tldrsec.com/blog/cloud-securi

    - [ ] **Gain access**: Ensure stable, secure Admin access to the known account(s). AWS Support may be necessary if access is not available.

    ### Enumerate the environment:
    ### Enumerate the environment

    First principles are: _Breadth, then depth_, _Anomaly detection_, and _Inside out and outside in_

    @@ -20,65 +20,67 @@ First principles are: _Breadth, then depth_, _Anomaly detection_, and _Inside ou
    - [ ] Review any configuration as code/infrastructure as code (C/IaC) (Terraform, CloudFormation, Pulumi, Chef, Ansible, Puppet)
    - [ ] Review any data classification and designation of scope for those classes of data
    - [ ] Review any standardized or ad-hoc resource tagging practices (consider [Yor](https://github.com/bridgecrewio/yor) going forward)
    - [ ] Review organizational documentation: Wikis, Documents, READMEs, etc.
    - [ ] Review organizational documentation: Wikis, Documents, `READMEs`, etc.
    - [ ] Identify any existing cloud security tools or vendors in use (CSPM, native security services, auditing tools, automation, etc.)

    Your end goal should be to discover or drive the organization to generate the following:
    1. Architecture diagrams or documentation of intended workloads
    2. Definition of "crown jewels", the unique set of data that is identified by the business as the most sensitive if compromised
    3. Intended authentication and identity approach
    1. Architecture diagrams or documentation of intended workloads.
    2. Definition of "crown jewels", the unique set of data that is identified by the business as the most sensitive if compromised.
    3. Intended authentication and identity approach.

    2. Get hands on and **discover the environment**:

    Start by targeting environments - the Cloud Service Provider's defined unit with a security boundary (AWS Accounts, Azure Subscriptions, GCP Projects).
    - [ ] For AWS, follow [Scott Piper's guide](https://summitroute.com/blog/2018/06/18/how_to_inventory_aws_accounts/)
    - [ ] Start to establish incentives for centralized management and visibility into all cloud environments
    - [ ] For AWS, follow [Scott Piper's guide](https://summitroute.com/blog/2018/06/18/how_to_inventory_aws_accounts/).
    - [ ] Start to establish incentives for centralized management and visibility into all cloud environments.

    Move on to find workloads:
    - [ ] Within discovered accounts, use billing as an indication of architectural patterns (h/t Corey Quinn's [Last Week in AWS post](https://www.lastweekinaws.com/blog/the-key-to-unlock-the-aws-billing-puzzle-is-architecture/))
    - [ ] Extract from the documentation discovered in Step 1
    - [ ] Extract from any C/IaC discovered in Step 1: This is particularly useful as C/IaC tends to be structured based on workload, unlike the cloud environment itself which is generally grouped by service and region
    - [ ] Work backwords from all discovered workloads to ensure complete coverage of any novel environments
    - [ ] Within discovered accounts, use billing as an indication of architectural patterns (h/t Corey Quinn's [Last Week in AWS post](https://www.lastweekinaws.com/blog/the-key-to-unlock-the-aws-billing-puzzle-is-architecture/)).
    - [ ] Extract from the documentation discovered in Step 1.
    - [ ] Extract from any IaC discovered in Step 1: This is particularly useful as IaC tends to be structured based on workload, unlike the cloud environment itself which is generally grouped by service and region.
    - [ ] Work backwords from all discovered workloads to ensure complete coverage of any novel environments.

    Document the **Collections of Environments**:
    - [ ] Create an inventory of environments and the collections to which they are linked (e.g AWS Organizations and which accounts are in each, which are orphaned currently)
    <br/>Document the **Collections of Environments**:
    - [ ] Create an inventory of environments and the collections to which they are linked (e.g AWS Organizations and which accounts are in each, which are orphaned currently).


    Leverage automation to index all the resources within the discovered estate:
    <br/>Leverage automation to **index all the resources** within the discovered estate:
    - [ ] Review existing company tooling identified in Step 1. Be cautious of any disabled rules or excluded resources, as well as the fact that this tooling likely does not cover all the accounts discovered through this process.
    - [ ] Run environment inventory tooling: For AWS my preference is NCC Group’s [aws-inventory](https://github.com/nccgroup/aws-inventory)
    - [ ] Run auditing tooling, which implicitly discovers resources: For AWS, my favorites include [Steampipe](https://steampipe.io/), [Prowler](https://github.com/toniblyx/prowler), and [ScoutSuite](https://github.com/nccgroup/ScoutSuite)
    - [ ] Run environment inventory tooling: For AWS my preference is NCC Group’s [aws-inventory](https://github.com/nccgroup/aws-inventory).
    - [ ] Run auditing tooling, which implicitly discovers resources: For AWS, my favorites include [Steampipe](https://steampipe.io/), [Prowler](https://github.com/toniblyx/prowler), and [ScoutSuite](https://github.com/nccgroup/ScoutSuite).

    ### Prioritize Remediation

    Target remediation at the most important risks first, as defined as threats with high impact that provide initial footholds within [Cloud Attack Killchains](https://disruptops.com/stop-todays-top-10-cloud-attack-killchains), or are used in publicly analyzed [AWS Security Breaches](https://speakerdeck.com/ramimac/learning-from-aws-customer-security-incidents). Reduced down, the three main focus areas should be the Identitiy Perimeter, the Network Perimeter, and Hosted Applications/Services. Until these risks are remediated, no investment should be made in defense in depth (See: [Defense in Depth is Over Hyped](https://tldrsec.com/blog/cloud-security-orienteering/#defense-in-depth-is-over-hyped)). Misconfigurations should be prioritized based on this framework.
    Target remediation at the most important risks first, as defined as threats with high impact that provide initial footholds within [Cloud Attack Killchains](https://disruptops.com/stop-todays-top-10-cloud-attack-killchains), or are used in publicly analyzed [AWS Security Breaches](https://speakerdeck.com/ramimac/learning-from-aws-customer-security-incidents).

    Reduced down, the three main focus areas should be the Identity Perimeter, the Network Perimeter, and Hosted Applications/Services.

    Until these risks are remediated, no investment should be made in defense in depth (See: [Defense in Depth is Over Hyped](https://tldrsec.com/blog/cloud-security-orienteering/#defense-in-depth-is-over-hyped)). Misconfigurations should be prioritized based on this framework.

    1. **Identity Perimeter**

    1. Management Plane Access model:
    - [ ] Identify the various means used to mediate management plan access.
    - [ ] Remove insecure mechanism such as Access Key/Secret Key, any use of IAM Users directly, unused users and roles, and ensure secure configurations are used for cross-account access for humans (MFA) and services (ExternalID).
    2. SSH/Server access model:
    - [ ] Ensure that no insecure mechanisms, specifically SSH with Password Authentication over the internet, are used to access services.
    - [ ] Ensure that no insecure mechanisms, specifically SSH with Password Authentication over the Internet, are used to access services.
    - [ ] In the short term, get compensating controls in place such as [fail2ban](https://www.fail2ban.org/), MFA, and bastion hosts.
    - [ ] In the long term, move to cloud-native patterns, either through services that have replaced SSH, or native offerings (Segment [has a great guide](https://segment.com/blog/infrastructure-access/))
    - [ ] In the long term, move to cloud-native patterns, either through services that have replaced SSH, or native offerings (Segment [has a great guide](https://segment.com/blog/infrastructure-access/)).
    3. Least Privilege and IAM security: see [An AWS IAM Security Tooling Reference](http://ramimac.me/cloudsec/security/aws-iam-tool-reference/)
    - [ ] Secure the root user ([Summit Route's guide](https://summitroute.com/blog/2018/06/20/managing_aws_root_passwords_and_mfa/))
    1. Use native tools
    - [ ] IAM Credential Report: Identify unused users and roles, and well as authentication patterns, such as MFA usage.
    - [ ] IAM Access Analyzer: Identify resources in your accounts shared with external entities.
    - [ ] Trusted Advisor (free): Multi-factor authentication on root account, AWS IAM use
    - [ ] AWS Config and/or Security Hub, if in use
    2. Use open source tools
    - **Use native tools**
    - [ ] [IAM Credential Report](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html): Identify unused users and roles, and well as authentication patterns, such as MFA usage.
    - [ ] [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html): Identify resources in your accounts shared with external entities.
    - [ ] [Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) (free): Multi-factor authentication on root account, AWS IAM use.
    - [ ] [AWS Config](https://aws.amazon.com/config/) and/or [Security Hub](https://aws.amazon.com/security-hub/), if in use.

    - **Use open source tools**
    - [ ] [Cloudsplaining](https://github.com/salesforce/cloudsplaining): Provides a comprehensive and digestible risk-prioritized report of violations of least privilege in your AWS IAM.
    - [ ] [PMappper](https://github.com/nccgroup/pmapper): A script (and library) that identifies privilege escalation risks and leverages a local IAM graph to allow querying of principals with access to a specific action or resource, including transitive access.
    - [ ] [PolicySentry](https://github.com/salesforce/policy_sentry): A tool that greatly improves the user experience of IAM least privilege policy generation
    - [ ] [PolicySentry](https://github.com/salesforce/policy_sentry): A tool that greatly improves the user experience of IAM least privilege policy generation.
    - [ ] [RepoKid](https://github.com/Netflix/repokid): A tool that automatically reduces permissions down to least privilege based on usage patterns.
    - [ ] [ConsoleMe](https://github.com/Netflix/consoleme): A Netflix-developed web service that "makes AWS IAM permissions and credential management easier for end-users and cloud administrators."




    2. **Network Perimeter**

    1. Public resources in managed services:
    @@ -91,24 +93,24 @@ Target remediation at the most important risks first, as defined as threats with
    3. **Hosted Applications/Services**

    - [ ] Run a vulnerability scan against all identified external attack surface. For a lightweight approach, you can use [`nmap` as a vulnerability scanner](https://isc.sans.edu/forums/diary/Using+Nmap+As+a+Lightweight+Vulnerability+Scanner/26098/). If you can afford it, consider instead a third party tool like Qualys or Nessus, or using cloud native capabilities, like [AWS Inspector](https://aws.amazon.com/inspector/).
    - [ ] Remediate out of date services, especially ones with known vulnerabilities
    - [ ] Assess all unauthenticated services, add authentication to any that are unintentionally exposed
    - [ ] Assess all exposed services, and remove all internal or sensitive services, such as CI/CD tools, from the internet
    - [ ] Remediate out of date services, especially ones with known vulnerabilities.
    - [ ] Assess all unauthenticated services, add authentication to any that are unintentionally exposed.
    - [ ] Assess all exposed services, and remove all internal or sensitive services, such as CI/CD tools, from the Internet.

    ### Create your Roadmap

    1. Apply universally applicable hardening:

    - [ ] Enable Guardduty in all accounts, and centralize alerts
    - [ ] Enable Cloudtrail in all accounts; turn on optional security features, including encryption at-rest and file validation; centralize and back up logs
    - [ ] Ensure security visibility and break-glass access to all accounts
    - [ ] Configure account-wide security defaults, including S3 block public access, EBS and all other default encryption
    - [ ] Enable GuardDuty in all accounts, and centralize alerts.
    - [ ] Enable Cloudtrail in all accounts; turn on optional security features, including encryption at-rest and file validation; centralize and back up logs.
    - [ ] Ensure security visibility and break-glass access to all accounts.
    - [ ] Configure account-wide security defaults, including S3 block public access, EBS and all other default encryption.

    2. Invest in Organizational Change
    - [ ] Take a relationship-drive approach to building out the cloud security program. (See: Todd Barnum's seven step methodology on [The Cybersecurity Manager's Guide](https://bookshop.org/books/the-cybersecurity-manager-s-guide-the-art-of-building-your-security-program/9781492076216))
    - [ ] Take a relationship-drive approach to building out the cloud security program (See: Todd Barnum's seven step methodology on [The Cybersecurity Manager's Guide](https://bookshop.org/books/the-cybersecurity-manager-s-guide-the-art-of-building-your-security-program/9781492076216)).
    - [ ] Use governance to continue to move the ball on remediation activities. Define a security baseline, document exceptions, and track and measure compliance of each business unit to the company’s security standards.
    - [ ] Determine and document the target end state. Focus on: Organization and Account model and management, business ownership and governance, continous auditing and posture management approach and tooling, and federated access model (sugestion: [AWS SSO integration to you Identity Provider](https://aws.amazon.com/identity/federation/))
    - [ ] Select and invest in a cloud security maturity model. I recommend spending time doing due dilligence here as you'll be making a strategic committment. Start by looking at the [Cloud Security Maturity Model](https://www.iansresearch.com/resources/cloud-security-maturity-model/what-is-the-csmm), which is affiliated with the Cloud Security Alliance and IANS, and built in partnership with Securosis. Then also peek at Marco Lancini's (behind cloudseclist.com) [Cloud Security Roadmap](https://roadmap.cloudsecdocs.com/).
    - [ ] Determine and document the target end state. Focus on: Organization and Account model and management, business ownership and governance, continous auditing and posture management approach and tooling, and federated access model (suggestion: [AWS SSO integration to you Identity Provider](https://aws.amazon.com/identity/federation/)).
    - [ ] Select and invest in a cloud security maturity model. I recommend spending time doing due dilligence here as you'll be making a strategic committment. Start by looking at the [Cloud Security Maturity Model](https://www.iansresearch.com/resources/cloud-security-maturity-model/what-is-the-csmm), which is affiliated with the Cloud Security Alliance and IANS, and built in partnership with Securosis. Then also peek at Marco Lancini's ([CloudSecList](https://cloudseclist.com/)) [Cloud Security Roadmap](https://roadmap.cloudsecdocs.com/).


    ### Other Resources
  3. @ramimac ramimac revised this gist Aug 16, 2021. 1 changed file with 0 additions and 3 deletions.
    3 changes: 0 additions & 3 deletions Cloud Security Orienteering Checklist.md
    View file
    Original file line number Diff line number Diff line change
    @@ -94,9 +94,6 @@ Target remediation at the most important risks first, as defined as threats with
    - [ ] Remediate out of date services, especially ones with known vulnerabilities
    - [ ] Assess all unauthenticated services, add authentication to any that are unintentionally exposed
    - [ ] Assess all exposed services, and remove all internal or sensitive services, such as CI/CD tools, from the internet
    - Sensitive or internal services that are needlessly public, such as CI/CD tools



    ### Create your Roadmap

  4. @ramimac ramimac revised this gist Aug 16, 2021. 1 changed file with 0 additions and 4 deletions.
    4 changes: 0 additions & 4 deletions Cloud Security Orienteering Checklist.md
    View file
    Original file line number Diff line number Diff line change
    @@ -6,10 +6,6 @@ How to orienteer in a cloud environment, dig in to identify the risks that matte

    Based on the [Cloud Security Orienteering](https://tldrsec.com/blog/cloud-security-orienteering) methodology.

    TKTK Github gist version
    {: .notice--info }


    ## Checklist

    - [ ] **Gain access**: Ensure stable, secure Admin access to the known account(s). AWS Support may be necessary if access is not available.
  5. @ramimac ramimac created this gist Aug 16, 2021.
    129 changes: 129 additions & 0 deletions Cloud Security Orienteering Checklist.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,129 @@
    Cloud Security Orienteering: Checklist
    by Rami McCarthy
    via [TL;DR sec](https://tldrsec.com)

    How to orienteer in a cloud environment, dig in to identify the risks that matter, and put together actionable plans that address short, medium, and long term goals.

    Based on the [Cloud Security Orienteering](https://tldrsec.com/blog/cloud-security-orienteering) methodology.

    TKTK Github gist version
    {: .notice--info }


    ## Checklist

    - [ ] **Gain access**: Ensure stable, secure Admin access to the known account(s). AWS Support may be necessary if access is not available.

    ### Enumerate the environment:

    First principles are: _Breadth, then depth_, _Anomaly detection_, and _Inside out and outside in_

    1. Kick off **corporate archeology**

    - [ ] Identify and review any existing asset inventor(y/ies)
    - [ ] Review any configuration as code/infrastructure as code (C/IaC) (Terraform, CloudFormation, Pulumi, Chef, Ansible, Puppet)
    - [ ] Review any data classification and designation of scope for those classes of data
    - [ ] Review any standardized or ad-hoc resource tagging practices (consider [Yor](https://github.com/bridgecrewio/yor) going forward)
    - [ ] Review organizational documentation: Wikis, Documents, READMEs, etc.
    - [ ] Identify any existing cloud security tools or vendors in use (CSPM, native security services, auditing tools, automation, etc.)

    Your end goal should be to discover or drive the organization to generate the following:
    1. Architecture diagrams or documentation of intended workloads
    2. Definition of "crown jewels", the unique set of data that is identified by the business as the most sensitive if compromised
    3. Intended authentication and identity approach

    2. Get hands on and **discover the environment**:

    Start by targeting environments - the Cloud Service Provider's defined unit with a security boundary (AWS Accounts, Azure Subscriptions, GCP Projects).
    - [ ] For AWS, follow [Scott Piper's guide](https://summitroute.com/blog/2018/06/18/how_to_inventory_aws_accounts/)
    - [ ] Start to establish incentives for centralized management and visibility into all cloud environments

    Move on to find workloads:
    - [ ] Within discovered accounts, use billing as an indication of architectural patterns (h/t Corey Quinn's [Last Week in AWS post](https://www.lastweekinaws.com/blog/the-key-to-unlock-the-aws-billing-puzzle-is-architecture/))
    - [ ] Extract from the documentation discovered in Step 1
    - [ ] Extract from any C/IaC discovered in Step 1: This is particularly useful as C/IaC tends to be structured based on workload, unlike the cloud environment itself which is generally grouped by service and region
    - [ ] Work backwords from all discovered workloads to ensure complete coverage of any novel environments

    Document the **Collections of Environments**:
    - [ ] Create an inventory of environments and the collections to which they are linked (e.g AWS Organizations and which accounts are in each, which are orphaned currently)


    Leverage automation to index all the resources within the discovered estate:
    - [ ] Review existing company tooling identified in Step 1. Be cautious of any disabled rules or excluded resources, as well as the fact that this tooling likely does not cover all the accounts discovered through this process.
    - [ ] Run environment inventory tooling: For AWS my preference is NCC Group’s [aws-inventory](https://github.com/nccgroup/aws-inventory)
    - [ ] Run auditing tooling, which implicitly discovers resources: For AWS, my favorites include [Steampipe](https://steampipe.io/), [Prowler](https://github.com/toniblyx/prowler), and [ScoutSuite](https://github.com/nccgroup/ScoutSuite)

    ### Prioritize Remediation

    Target remediation at the most important risks first, as defined as threats with high impact that provide initial footholds within [Cloud Attack Killchains](https://disruptops.com/stop-todays-top-10-cloud-attack-killchains), or are used in publicly analyzed [AWS Security Breaches](https://speakerdeck.com/ramimac/learning-from-aws-customer-security-incidents). Reduced down, the three main focus areas should be the Identitiy Perimeter, the Network Perimeter, and Hosted Applications/Services. Until these risks are remediated, no investment should be made in defense in depth (See: [Defense in Depth is Over Hyped](https://tldrsec.com/blog/cloud-security-orienteering/#defense-in-depth-is-over-hyped)). Misconfigurations should be prioritized based on this framework.

    1. **Identity Perimeter**

    1. Management Plane Access model:
    - [ ] Identify the various means used to mediate management plan access.
    - [ ] Remove insecure mechanism such as Access Key/Secret Key, any use of IAM Users directly, unused users and roles, and ensure secure configurations are used for cross-account access for humans (MFA) and services (ExternalID).
    2. SSH/Server access model:
    - [ ] Ensure that no insecure mechanisms, specifically SSH with Password Authentication over the internet, are used to access services.
    - [ ] In the short term, get compensating controls in place such as [fail2ban](https://www.fail2ban.org/), MFA, and bastion hosts.
    - [ ] In the long term, move to cloud-native patterns, either through services that have replaced SSH, or native offerings (Segment [has a great guide](https://segment.com/blog/infrastructure-access/))
    3. Least Privilege and IAM security: see [An AWS IAM Security Tooling Reference](http://ramimac.me/cloudsec/security/aws-iam-tool-reference/)
    - [ ] Secure the root user ([Summit Route's guide](https://summitroute.com/blog/2018/06/20/managing_aws_root_passwords_and_mfa/))
    1. Use native tools
    - [ ] IAM Credential Report: Identify unused users and roles, and well as authentication patterns, such as MFA usage.
    - [ ] IAM Access Analyzer: Identify resources in your accounts shared with external entities.
    - [ ] Trusted Advisor (free): Multi-factor authentication on root account, AWS IAM use
    - [ ] AWS Config and/or Security Hub, if in use
    2. Use open source tools
    - [ ] [Cloudsplaining](https://github.com/salesforce/cloudsplaining): Provides a comprehensive and digestible risk-prioritized report of violations of least privilege in your AWS IAM.
    - [ ] [PMappper](https://github.com/nccgroup/pmapper): A script (and library) that identifies privilege escalation risks and leverages a local IAM graph to allow querying of principals with access to a specific action or resource, including transitive access.
    - [ ] [PolicySentry](https://github.com/salesforce/policy_sentry): A tool that greatly improves the user experience of IAM least privilege policy generation
    - [ ] [RepoKid](https://github.com/Netflix/repokid): A tool that automatically reduces permissions down to least privilege based on usage patterns.
    - [ ] [ConsoleMe](https://github.com/Netflix/consoleme): A Netflix-developed web service that "makes AWS IAM permissions and credential management easier for end-users and cloud administrators."




    2. **Network Perimeter**

    1. Public resources in managed services:
    - [ ] Review and harden inappropriately exposed resources in managed services. For a list of exposable resources, see [AWS Exposable Resources](https://github.com/SummitRoute/aws_exposable_resources).
    2. Public network access to hosted services:
    - [ ] Review and harden inappropriately exposed services. Focus on network access via security groups with unrestricted access to sensitive services and ports.
    3. Default, insecure resources:
    - [ ] Review usage of default VPCs and security groups. Ensure they are replaced by restrictive configurations following least privilege. Review DisruptOps' [_The Power of the Minimum Viable Network_](https://disruptops.com/the-power-of-the-minimum-viable-network/) for a strategic approach.

    3. **Hosted Applications/Services**

    - [ ] Run a vulnerability scan against all identified external attack surface. For a lightweight approach, you can use [`nmap` as a vulnerability scanner](https://isc.sans.edu/forums/diary/Using+Nmap+As+a+Lightweight+Vulnerability+Scanner/26098/). If you can afford it, consider instead a third party tool like Qualys or Nessus, or using cloud native capabilities, like [AWS Inspector](https://aws.amazon.com/inspector/).
    - [ ] Remediate out of date services, especially ones with known vulnerabilities
    - [ ] Assess all unauthenticated services, add authentication to any that are unintentionally exposed
    - [ ] Assess all exposed services, and remove all internal or sensitive services, such as CI/CD tools, from the internet
    - Sensitive or internal services that are needlessly public, such as CI/CD tools



    ### Create your Roadmap

    1. Apply universally applicable hardening:

    - [ ] Enable Guardduty in all accounts, and centralize alerts
    - [ ] Enable Cloudtrail in all accounts; turn on optional security features, including encryption at-rest and file validation; centralize and back up logs
    - [ ] Ensure security visibility and break-glass access to all accounts
    - [ ] Configure account-wide security defaults, including S3 block public access, EBS and all other default encryption

    2. Invest in Organizational Change
    - [ ] Take a relationship-drive approach to building out the cloud security program. (See: Todd Barnum's seven step methodology on [The Cybersecurity Manager's Guide](https://bookshop.org/books/the-cybersecurity-manager-s-guide-the-art-of-building-your-security-program/9781492076216))
    - [ ] Use governance to continue to move the ball on remediation activities. Define a security baseline, document exceptions, and track and measure compliance of each business unit to the company’s security standards.
    - [ ] Determine and document the target end state. Focus on: Organization and Account model and management, business ownership and governance, continous auditing and posture management approach and tooling, and federated access model (sugestion: [AWS SSO integration to you Identity Provider](https://aws.amazon.com/identity/federation/))
    - [ ] Select and invest in a cloud security maturity model. I recommend spending time doing due dilligence here as you'll be making a strategic committment. Start by looking at the [Cloud Security Maturity Model](https://www.iansresearch.com/resources/cloud-security-maturity-model/what-is-the-csmm), which is affiliated with the Cloud Security Alliance and IANS, and built in partnership with Securosis. Then also peek at Marco Lancini's (behind cloudseclist.com) [Cloud Security Roadmap](https://roadmap.cloudsecdocs.com/).


    ### Other Resources

    - [The Extended AWS Security Ramp-Up Guide](https://research.nccgroup.com/2020/04/24/the-extended-aws-security-ramp-up-guide/)
    - [Marco Lancini, On Establishing a Cloud Security Program](https://www.marcolancini.it/2021/blog-cloud-security-roadmap/)
    - [Scott Piper (Summit Route), AWS Security Maturity Roadmap 2021](https://summitroute.com/downloads/aws_security_maturity_roadmap-Summit_Route.pdf)
    - [Matt Fuller, So You Inherited an AWS Account](https://medium.com/swlh/so-you-inherited-an-aws-account-e5fe6550607d)
    - [DisruptOps, AWS Cloud Security Checklist](https://disruptops.com/resources/aws-cloud-security-checklist/)
    - [CSA Top Threats, Cloud Penetration Testing Playbook](https://cloudsecurityalliance.org/artifacts/cloud-penetration-testing-playbook/)
    - [Dave Walker & Chris Astley, Security @ Scale on AWS](http://london-summit-slides-2017.s3.amazonaws.com/11.50%20-%20Security-at-Scale-with-AWS.pdf)