AWS prescriptive-guidance documentation change
Summary
Updated centralized monitoring guidance to recommend CloudWatch Unified Data Experience for log aggregation, added details about OCSF normalization, cross-account access via CloudWatch OAM, S3 Object Lock for compliance, and clarified Security Lake as a secondary option.
Security assessment
The changes enhance documentation about security monitoring features (CloudWatch Unified Data Experience, S3 Object Lock) and security frameworks (OCSF), but don't address a specific vulnerability. They improve guidance on implementing security best practices for log centralization and compliance.
Diff
diff --git a/prescriptive-guidance/latest/security-reference-architecture/value.md b/prescriptive-guidance/latest/security-reference-architecture/value.md index 8f134377d..bb5873842 100644 --- a//prescriptive-guidance/latest/security-reference-architecture/value.md +++ b//prescriptive-guidance/latest/security-reference-architecture/value.md @@ -11,3 +10,0 @@ How to use the AWS SRAKey implementation guidelines of the AWS SRA -Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a [short survey](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua). ---- - @@ -25 +22 @@ AWS has a large (and growing) [set of security and security-related services](ht -We address each of these in the AWS SRA. The first priority in the list (where things go) is the focus of the main architecture diagram and the accompanying discussions in this document. We provide a recommended AWS Organizations architecture and an account-by-account description of which services go where. To get started with the second priority in the list (how to think about the full set of security services), read the section, [Apply security services across your AWS organization.](./security-services.html) This section describes a way to group security services according to the structure of the elements in your AWS organization. In addition, those same ideas are reflected in the discussion of the [Application account](./application.html), which highlights how security services can be operated to focus on certain layers of the account: Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Virtual Private Cloud (Amazon VPC) networks, and the broader account. Finally, the third priority (service integration) is reflected throughout the guidance―particularly in the discussion of individual services in the [deep dive guides in the AWS SRA library](./about-sra-library.html) and the code in the AWS SRA code repository. +We address each of these in the AWS SRA. The first priority in the list (where things go) is the focus of the main architecture diagram and the accompanying discussions in this document. We provide a recommended AWS Organizations architecture and an account-by-account description of which services go where. To get started with the second priority in the list (how to think about the full set of security services), read the section, [Apply security services across your AWS organization](./security-services.html). This section describes a way to group security services according to the structure of the elements in your AWS organization. In addition, those same ideas are reflected in the discussion of the [Application account](./application.html), which highlights how security services can be operated to focus on certain layers of the account: Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Virtual Private Cloud (Amazon VPC) networks, and the broader account. Finally, the third priority (service integration) is reflected throughout the guidance―particularly in the discussion of individual services in the [deep dive guides in the AWS SRA library](./about-sra-library.html) and the code in the AWS SRA code repository. @@ -33 +30 @@ There are different ways to use the AWS SRA depending on where you are in your c -Whether you are just starting your AWS Cloud journey―setting up your first set of accounts―or planning to enhance an established AWS environment, the AWS SRA is the place to start building your security architecture. Begin with a comprehensive foundation of account structure and security services, and then adjust based on your particular technology stack, skills, security objectives, and compliance requirements. If you know you will be building and launching more workloads, you can take your customized version of the AWS SRA and use it as the basis for your organization's security reference architecture. To find out how you can achieve the target state described by the AWS SRA, see the section [Building your security architecture – A phased approach](./phases.html). +Whether you are just starting your AWS Cloud journey―setting up your first set of accounts―or planning to enhance an established AWS environment, the AWS SRA is the place to start building your security architecture. Begin with a comprehensive foundation of account structure and security services, and then adjust based on your particular technology stack, skills, security objectives, and compliance requirements. If you know you will be building and launching more workloads, you can take your customized version of the AWS SRA and use it as the basis for your organization's security reference architecture. To find out how you can achieve the target state described by the AWS SRA, see the section [Building your security architecture ‒ A phased approach](./phases.html). @@ -45 +42 @@ The AWS SRA infrastructure as code (IaC) modules provide a fast, reliable way to -The guidance and discussions in the AWS SRA include important features as well as deployment and management considerations for individual AWS security and security-related services. One feature of the AWS SRA is that it provides a high-level introduction to the breadth of the AWS security services and how they work together in a multi-account environment. This complements the deep dive into the features and configuration for each service found in other sources. One example of this is the [discussion](./security-tooling.html#tool-security-hub) of how AWS Security Hub Cloud Security Posture Management (AWS Security Hub CSPM) ingests security findings from a variety of AWS services, AWS Partner products, and even your own applications. +The guidance and discussions in the AWS SRA include important features as well as deployment and management considerations for individual AWS security and security-related services. One feature of the AWS SRA is that it provides a high-level introduction to the breadth of the AWS security services and how they work together in a multi-account environment. This complements the deep dive into the features and configuration for each service found in other sources. One example of this is the [discussion](./security-tooling.html#tool-security-hub) of how AWS Security Hub Cloud Security Posture Management (CSPM) ingests security findings from a variety of AWS services, AWS Partner products, and even your own applications. @@ -68 +65,5 @@ Here are eight key takeaways from the AWS SRA to keep in mind as you design and - * Implement centralized monitoring, management, and governance across your AWS organizations. By using AWS services that support multi-account (and sometimes multi-Region) aggregation, along with delegated administration features, you empower your central security, network, and cloud engineering teams to have broad visibility and control over appropriate security configuration and data collection. Additionally, the data can be provided back to workload teams to empower them to make effective security decisions earlier in the software development lifecycle (SDLC). + * Implement centralized logging, monitoring, management, and governance across your AWS organizations by using [Amazon CloudWatch Unified Data Experience](https://aws.amazon.com/cloudwatch/features/unified-data-and-telemetry/) as the preferred primary method for log data collection, security analytics, and operational observability. CloudWatch Unified Data Experience provides unified data management and analytics capabilities that consolidate operational, security, and compliance data across your AWS environment and third-party sources into a single service. By using CloudWatch Pipelines with organization-wide centralization rules, your central security, network, and cloud engineering teams can automatically aggregate AWS vended logs (such as CloudTrail, Amazon VPC Flow Logs, AWS WAF, Amazon Route 53, and Amazon EKS audit logs) and third-party security telemetry into a dedicated account within the Security OU. This helps you establish a single pane of glass for real-time visibility, anomaly detection, and incident response. + + * CloudWatch Unified Data Experience natively normalizes ingested data to the Open Cybersecurity Schema Framework (OCSF) using built-in pipeline processors. This eliminates the need for custom ETL pipelines or separate normalization layers. Cross-account observability is enabled through CloudWatch Observability Access Manager (OAM), which provides linked source accounts with secure, read-only access to centralized telemetry without requiring direct access to the Monitoring account. For long-term immutable retention, CloudWatch routes log data to [Amazon S3 Tables](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables.html) (Apache Iceberg format) in the Log Archive account, where [Amazon S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) and lifecycle policies ensure compliance with regulatory retention requirements. + + * For organizations with existing Amazon Security Lake deployments or specific requirements for subscriber-based data access patterns and Parquet-based archival, Security Lake serves as a complementary secondary option. Additionally, the centralized data can be provided back to workload teams through CloudWatch cross-account dashboards, OAM links, and Logs Insights shared queries. This helps you make effective security decisions earlier in the software development lifecycle.