Security OU – Security Tooling account

We would love to hear from you. Please provide feedback on the AWS PRA by taking a short survey.

The Security Tooling account is dedicated to operating security and privacy foundational services, monitoring AWS accounts, and automating security and privacy alerting and response. For more information about this account, see the AWS Security Reference Architecture (AWS SRA). The following diagram illustrates the AWS security and privacy services that are configured in the Security Tooling account.

This section provides more detailed information about the following in this account:

• AWS CloudTrail

• AWS Config

• Amazon GuardDuty

• IAM Access Analyzer

• Amazon Macie

AWS CloudTrail

AWS CloudTrail helps you audit the overall API activity in your AWS account. Enabling CloudTrail in all AWS accounts and AWS Regions that store, process, or transmit personal data can help you track the use and disclosure of this data. The AWS Security Reference Architecture recommends enabling an organization trail, which is a single trail that logs all events for all accounts in the organization. However, enabling this organization trail aggregates the multi-Region log data into a single Amazon Simple Storage Service (Amazon S3) bucket in the Log Archive account. For accounts that handle personal data, this can bring some additional design considerations. Log records might contain some references to personal data. To meet your data residency and data transfer requirements, you might need to reconsider aggregating cross-Region log data into a single Region where the S3 bucket is located. Your organization might consider which regional workloads should be included or excluded from the organization trail. For workloads that you decide to exclude from the organization trail, you could consider configuring a Region-specific trail that masks personal data. For more information about masking personal data, see the Amazon Data Firehose section of this guide. Ultimately, your organization might have a combination of organization trail and regional trails that aggregate into the centralized Log Archive account.

For more information about configuring a single-Region trail, see the instructions for using the AWS Command Line Interface (AWS CLI) or the console. When you create the organization trail, you can use an opt-in setting in AWS Control Tower, or you can create the trail directly in the CloudTrail console.

For more information on the overall approach and how to manage centralization of logs and data transfer requirements, see the Centralized log storage section in this guide. Whatever configuration you choose, you might want to separate trail management in the Security Tooling account from log storage in the Log Archive account, according to the AWS SRA. This design helps you create least-privilege access policies for those who need to manage logs and those who need to use the log data.

AWS Config

AWS Config provides a detailed view of the resources in your AWS account and how they’re configured. It helps you identify how resources relate to one another and how their configurations have changed over time. For more information about how this service is used in a security context, see the AWS Security Reference Architecture.

In AWS Config, you can deploy conformance packs, which are sets of AWS Config rules and remediation actions. Conformance packs provide a general-purpose framework that is designed to enable privacy, security, operational, and cost-optimization governance checks by using managed or custom AWS Config rules. You can use this tool as a part of a larger set of automation tools to track whether your AWS resource configurations comply with your own control framework requirements.

The Operational Best Practices for NIST Privacy Framework v1.0 conformance pack is aligned to a number of privacy-related controls in the NIST Privacy Framework. Each AWS Config rule applies to a specific AWS resource type, and it relates to one or more NIST Privacy Framework controls. You can use this conformance pack to track privacy-related continuous compliance across resources in your accounts. The following are some of the rules included in this conformance pack:

• no-unrestricted-route-to-igw – This rule helps prevent data exfiltration on the data plane by continually monitoring VPC route tables for default 0.0.0.0/0 or ::/0 egress routes to an internet gateway. This helps you restrict where internet-bound traffic can be sent, especially if there are CIDR ranges that are known to be malicious.

• encrypted-volumes – This rule checks whether Amazon Elastic Block Store (Amazon EBS) volumes that are attached to Amazon Elastic Compute Cloud (Amazon EC2) instances are encrypted. If your organization has specific control requirements that pertain to the usage of AWS Key Management Service (AWS KMS) keys for protection of personal data, you can specify specific key IDs as a part of the rule to check that the volumes are encrypted with a specific AWS KMS key.

• restricted-common-ports – This rule checks whether Amazon EC2 security groups allow unrestricted TCP traffic to specified ports. Security groups can help you manage network access by providing stateful filtering of ingress and egress network traffic to AWS resources. Blocking ingress traffic from 0.0.0.0/0 to common ports, such as TCP 3389 and TCP 21, on your resources helps you restrict remote access.

AWS Config can be used for both proactive and reactive compliance checks of your AWS resources. In addition to considering the rules found in the conformance packs, you can incorporate these rules in both detective and proactive evaluation modes. This helps implement privacy checks earlier in your software development lifecycle because the application developers can start incorporating predeployment checks. For example, they can include hooks in their AWS CloudFormation templates that check the declared resource in the template against all privacy-related AWS Config rules that have proactive mode enabled. For more information, see AWS Config Rules Now Support Proactive Compliance (AWS blog post).

Amazon GuardDuty

AWS offers multiple services that might be used to store or process personal data, such as Amazon S3, Amazon Relational Database Service (Amazon RDS), or Amazon EC2 with Kubernetes. Amazon GuardDuty combines intelligent visibility with continuous monitoring to detect indicators that might be related to unintended disclosure of personal data. For more information about how this service is used in a security context, see the AWS Security Reference Architecture.

With GuardDuty, you can identify potentially malicious, privacy-related activity throughout an attack lifecycle. For example, GuardDuty can alert you about connections to blacklisted sites, unusual network port traffic or traffic volumes, DNS exfiltration, unexpected EC2 instance launches, and unusual ISP callers. You can also configure GuardDuty to stop alerts for trusted IP addresses from your own trusted IP lists and alert on known malicious IP addresses from your own threat lists.

As recommended in the AWS SRA, you can enable GuardDuty for all AWS accounts in your organization and configure the Security Tooling account as the GuardDuty delegated administrator. GuardDuty aggregates findings from across the organization into this single account. For more information, see Managing GuardDuty accounts with AWS Organizations. You can also consider identifying all privacy-related stakeholders in the incident response process, from detection and analysis to containment and eradication, and involving them in any incidents that might involve data exfiltration.

IAM Access Analyzer

Many customers want continual assurance that personal data is being shared appropriately with preapproved and intended third-party processors and no other entities. A data perimeter is a set of preventive guardrails designed to allow only trusted identities from expected networks to access trusted resources in your AWS environment. As you define controls for unintended and intended disclosure of personal data, you can define trusted identities, trusted resources, and expected networks.

With AWS Identity and Access Management Access Analyzer (IAM Access Analyzer), organizations can define an AWS account zone of trust and configure alerting for violations to that zone of trust. IAM Access Analyzer analyzes IAM policies to help identify and resolve unintended public or cross-account access to potentially sensitive resources. IAM Access Analyzer uses mathematical logic and inference to generate comprehensive findings for resources that can be accessed from outside an AWS account. Finally, for responding to and remediating overly-permissive IAM policies, you can use IAM Access Analyzer to validate existing policies against IAM best practices and provide suggestions. IAM Access Analyzer can generate a least-privilege IAM policy that is based on an IAM principal's prior access activity. It analyzes CloudTrail logs and generates a policy that grants only the permissions required to continue performing those tasks.

For more information about how IAM Access Analyzer is used in a security context, see the AWS Security Reference Architecture.

Amazon Macie

Amazon Macie is a service that uses machine learning and pattern matching to discover sensitive data, provides visibility into data security risks, and helps you automate protections against those risks. Macie generates findings when it detects potential policy violations or issues with the security or privacy of your Amazon S3 buckets. Macie is another tool that organizations can use to implement automation in order to support compliance efforts. For more information about how this service is used in a security context, see the AWS Security Reference Architecture.

Macie can detect a large and growing list of sensitive data types, including personally identifiable information (PII), such as names, addresses, and other identifiable attributes. You can even create custom data identifiers in order to define detection criteria that reflects your organization's definition of personal data.

As your organization defines preventative controls for your Amazon S3 buckets that contain personal data, you can use Macie as a validation mechanism to provide continual reassurance of where your personal data lives and how it's protected. To start, enable Macie and configure automated sensitive data discovery. Macie continually analyzes objects in all of your S3 buckets, across accounts and AWS Regions. Macie generates and maintains an interactive heat map that depicts where personal data resides. The automated sensitive data discovery feature is designed to reduce costs and minimize the need to manually configure discovery jobs. You can build on top of the automated sensitive data discovery feature and use Macie to automatically detect new buckets or new data in existing buckets and then validate the data against the assigned data classification tags. Configure this architecture to notify the appropriate development and privacy teams about misclassified or unclassified buckets in a timely manner.

You can enable Macie for every account in your organization by using AWS Organizations. For more information, see Integrating and configuring an organization in Amazon Macie.