Skip to content

Instantly share code, notes, and snippets.

@ramimac

ramimac/Cloud Security Orienteering Checklist.md

Last active October 10, 2024 17:47
Show Gist options
  • Save ramimac/823e52befba373d71bc936d1742768f4 to your computer and use it in GitHub Desktop.
Save ramimac/823e52befba373d71bc936d1742768f4 to your computer and use it in GitHub Desktop.
Download ZIP
A Checklist of Cloud Security Orienteering
Raw
Cloud Security Orienteering Checklist.md

Cloud Security Orienteering: Checklist
by Rami McCarthy
via TL;DR sec

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 methodology.

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 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.
    • 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).
    • 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).


    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.
    • Run auditing tooling, which implicitly discovers resources: For AWS, my favorites include Steampipe, Prowler, and 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, or are used in publicly analyzed AWS Security Breaches.

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). 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, 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).
    3. Least Privilege and IAM security: see An AWS IAM Security Tooling Reference

      • Secure the root user (Summit Route's guide)

      • Use native tools

      • Use open source tools

        • Cloudsplaining: Provides a comprehensive and digestible risk-prioritized report of violations of least privilege in your AWS IAM.
        • PMappper: 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: A tool that greatly improves the user experience of IAM least privilege policy generation.
        • RepoKid: A tool that automatically reduces permissions down to least privilege based on usage patterns.
        • 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.
    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 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. If you can afford it, consider instead a third party tool like Qualys or Nessus, or using cloud native capabilities, like AWS 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.

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).
  • 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 (suggestion: AWS SSO integration to you Identity Provider).
  • 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, which is affiliated with the Cloud Security Alliance and IANS, and built in partnership with Securosis. Then also peek at Marco Lancini's (CloudSecList) Cloud Security Roadmap.

Other Resources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment