Continuous monitoring & maintenance of security baseline posture of infrastructure and environment is one of the key components of an enterprise’s cybersecurity defense-in-depth framework. Different federal organizations like NIST, CISA, DISA and industry consortiums like PCI and non-profit organizations like CIS, have created recommendations & guide that help create security baseline for an enterprise’s infrastructure configuration. Cloud security posture management (CSPM) products have been helping to track the security controls/guardrails adopted based on these recommended best practices as well as policy & standard defined by an organization's InfoSec team.
Conformance packs in AWS SecurityHub, help track AWS environment security posture and hence SecurityHub can be used as CPSM. However, in a multi-account AWS environment, one could face following challenges while using & operating CSPM capability of AWS SecurityHub:
- Difficulty in establishing traceability between organization defined process & standards with the guardrails & exception implementation
- Findings for certain guardrails have to have exception process e.g., few S3 buckets have to made public for business reasons. So non-compliance findings related to S3 bucket being public has to tracked depending on whether the resource is in the allow/exception list
- There are many security guardrails in the CIS AWS benchmark that are detective controls e.g., monitoring usage of root user or setting up metric filter for high risk AWS CloudTrail events. As these guardrails are to be implemented as detective rules in SIEM, there is no need to have them & track as part of the SecurityHub compliance dashboard
- Enterprise cloud security teams would typically monitor the findings in CSPM product & use Jira like ticketing system to collaborate with respective AWS account owners/DevOps/developers to remediate finding related to a non-compliance event e.g., securing security group that allows traffic on port 22
In order to address afore mentioned challenges & making sure equal participation of different stakeholders in securing AWS environment (i.e., security & risk governance team, DevOps/SRE, development), following can be one of the approaches to scale and effectively use AWS SecurityHub as CSPM platform.
Step 1: Create a traceability matrix between organization’s cloud security standard and CIS AWS benchmark and AWS foundational best practices. Store the result in an Excel spreadsheet.
- This spreadsheet would contain customized list of controls/guardrails resulting based on organization process & standards and operating environment e.g., instead of hardware MFA, software MFA could be used; instead of VPC flow logs, firewall logs could be ingested to SIEM etc
- Make sure this spreadsheet is stored in source code repository system like GitHub so that all the stakeholders can access this information and can review/update by using gitflow workflow
- For the GitHub repo that stores the controls spreadsheet, enable GitHub Action for the repo. When GitHub action is triggered, deploy a script that would read the controls defined in the spreadsheet and enable/disable controls in individual AWS accounts.
Step 2: Setup a process to create exception/allow list for the AWS resources that would be shown as non-compliant in SecurityHub dashboard e.g., S3 buckets that are to be public for business reason. Use ARN base method to manage this exception list and this list is updated once the approval for the exception is received from risk team (SNOW based workflow is one of the ways for implementing this exception process). With resource/guardrail in exception list, when there is a finding related to non-compliance of that resource/guardrail, update non-compliance finding
Step 3: Set expectation with stakeholders and operationalize CSPM workflow finalized in step 1 & 2. Since the controls and findings are customized for the enterprise environment, AWS account owners/stakeholders are excepted to maintain 100% compliance and is tracked on a weekly basis.
- Non-conformance findings can be imported to vulnerability orchestration tool and then be pushed to ticketing systems like Jira. This will help in the scenarios where different DevOps teams have their own Jira boards & Epics and also need an independent system to validate remediation of the non-conformance findings OR use native bidirectional Jira integration reference implementation as documented here - https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/bidirectionally-integrate-aws-security-hub-with-jira-software.html. However, additional considerations needed to handle events related to ephemeral resources & tracking Jira issues in different team's Jira boards
- If the SecurityHub is setup with hub-and-spoke pattern, the the hub SecurityHub dashboard gives the overall compliance score (including cross-AWS regions) and also highlight guardrails that are failing compliance test. Hub dashboard can be used for weekly report to execs as it helps track overall AWS infrastructure security posture
- SecurityHub dashboard for a given AWS account can be used by the AWS account owner/DevOps team to track non-compliance and take action
- Since custom conformance pack can be deployed in SecurityHub, SecurityHub can be used to monitor AWS resource compliance checks that are missing in other vendor CSPM products
- If an enterprise adopts hierarchical approach to manage security posture & cloud governance guardrails, then other vendor CSPM can be used at enterprise level and AWS SecurityHub at the individual business unit level. Reason being, SecurityHub based CSPM implementation helps OUs DevOps team to add additional cloud governance guardrails and build specific remediation automation in the AWS accounts residing that that OU. This gives add-on flexibility for the DevOps team to maintain AWS environment governance while keeping the environment compliant to organization's InfoSec policies
Caveats to consider while using AWS SecurityHub as CSPM
- SecurityHub doesn't support setting up multiple admins e.g., creating (delegated) admin at OU (organization unit) level and also at organization root level
- Missing AWS account alias/short name in the dashboard - hard to identify account owner in a multi-account AWS environment
- Slack notifications for non-compliant events, require custom Lambda implementation and is not convenient for security analyst who is triaging the findings
- Cannot disable guardrail through SecurityHub dashboard, but can be done through custom Lambda function code; yet to support fine-grain access control for different SecurityHub dashboard actions e.g., create IAM policy to allow/deny actions related to suppressing finding related to certain AWS resource types
- In order to view Config history/Config snapshot and CloudTrail events related to AWS resources, need to navigate to different service dashboard and setup specific queries
If SecurityHub based CSPM is being implemented in an AWS environment that already has prod/non-prod workloads, lead time needs to be considered to address already non-compliant guardrails & AWS resources before operationalizing the CSPM. There can be a specific time bound project for dev/DevOps teams to remediate non-compliant AWS resources and to educate stakeholders on the security guardrails being implemented.
