AWS prescriptive-guidance documentation change
Summary
Updated navigation links, headings, and content for clarity; fixed markdown formatting; corrected service names and links; reorganized some content.
Security assessment
Changes are editorial improvements (e.g., updated links, corrected service names like 'Amazon Security Lake' instead of 'AWS Security Lake', typo fixes). No evidence of addressing a specific security vulnerability or incident. The content remains focused on general security best practices without new security features.
Diff
diff --git a/prescriptive-guidance/latest/security-reference-architecture/phases.md b/prescriptive-guidance/latest/security-reference-architecture/phases.md index b384c0c6f..38b735686 100644 --- a//prescriptive-guidance/latest/security-reference-architecture/phases.md +++ b//prescriptive-guidance/latest/security-reference-architecture/phases.md @@ -3 +3 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Security Reference Architecture](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Security Reference Architecture (AWS SRA) – core architecture](introduction.html) @@ -7 +7 @@ Phase 1: Build your OU and account structurePhase 2: Implement a strong identity -# Building your security architecture - A phased approach +# Building your security architecture – a phased approach @@ -12 +12 @@ Influence the future of the AWS Security Reference Architecture (AWS SRA) by tak -The multi-account security architecture recommended by the AWS SRA is a baseline architecture to help you inject security early into your design process. Each organization’s cloud journey is unique. To successfully evolve your cloud security architecture, you need to envision your desired target state, understand your current cloud readiness, and adopt an agile approach to close any gaps. The AWS SRA provides a reference target state for your security architecture. Transforming incrementally enables you to demonstrate value quickly while minimizing the need to make far-reaching predictions. +The multi-account security architecture recommended by the AWS SRA is a baseline architecture to help you inject security early into your design process. Each organization's cloud journey is unique. To successfully evolve your cloud security architecture, you need to envision your desired target state, understand your current cloud readiness, and adopt an agile approach to close any gaps. The AWS SRA provides a reference target state for your security architecture. Transforming incrementally enables you to demonstrate value quickly while minimizing the need to make far-reaching predictions. @@ -14 +14 @@ The multi-account security architecture recommended by the AWS SRA is a baseline -The [AWS Cloud Adoption Framework (AWS CAF)](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/) recommends four iterative and incremental cloud transformation phases: [Envision, Align, Launch, and Scale](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/your-cloud-transformation-journey.html). As you enter the Launch phase and focus on delivering pilot initiatives in production, you should focus on building a strong security architecture as a foundation for the Scale phase so that you have the technical ability to migrate and operate your most business-critical workloads with confidence. This phased approach is applicable if you are a startup, a small or medium company that wants to expand their business, or an enterprise that’s acquiring new business units or undergoing mergers and acquisitions. The AWS SRA helps you achieve that security baseline architecture so that you can apply security controls uniformly across your expanding organization in AWS Organizations. The baseline architecture consists of multiple AWS accounts and services. Planning and implementation should be a multi-phase process so that you can iterate over smaller milestones to reach the bigger goal of setting up your baseline security architecture. This section describes the typical phases of your cloud journey based on a structured approach. These phases align with the [AWS Well-Architected Framework security design principles](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-design.html). +The [AWS Cloud Adoption Framework](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/welcome.html) (AWS CAF) recommends four iterative and incremental cloud transformation phases: [envision, align, launch, and scale](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/your-cloud-transformation-journey.html). As you enter the launch phase and focus on delivering pilot initiatives in production, you should focus on building a strong security architecture as a foundation for the scale phase so that you have the technical ability to migrate and operate your most business-critical workloads with confidence. This phased approach is applicable if you are a startup, a small or medium company that wants to expand their business, or an enterprise that's acquiring new business units or undergoing mergers and acquisitions. The AWS SRA helps you achieve that security baseline architecture so that you can apply security controls uniformly across your expanding organization in AWS Organizations. The baseline architecture consists of multiple AWS accounts and services. Planning and implementation should be a multi-phase process so that you can iterate over smaller milestones to reach the bigger goal of setting up your baseline security architecture. This section describes the typical phases of your cloud journey based on a structured approach. These phases align with the [AWS Well-Architected Framework security design principles](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-design.html). @@ -18 +18 @@ The [AWS Cloud Adoption Framework (AWS CAF)](https://docs.aws.amazon.com/whitepa -A prerequisite to a strong security foundation is a well-designed AWS organization and account structure. As explained previously in the [SRA building blocks](./organizations.html) section of this guide, having multiple AWS accounts helps you isolate different business and security functions by design. This might seem like unnecessary work in the beginning, but it’s an investment to help you scale quickly and securely. That section also explains how you can use AWS Organizations to manage multiple AWS accounts, and how to use trusted access and delegated administrator features to centrally manage AWS services across these multiple accounts. +A prerequisite to a strong security foundation is a well-designed AWS organization and account structure. As explained previously in the [SRA building blocks](./organizations.html) section of this guide, having multiple AWS accounts helps you isolate different business and security functions by design. This might seem like unnecessary work in the beginning, but it's an investment to help you scale quickly and securely. That section also explains how you can use AWS Organizations to manage multiple AWS accounts, and how to use trusted access and delegated administrator features to centrally manage AWS services across these multiple accounts. @@ -20 +20 @@ A prerequisite to a strong security foundation is a well-designed AWS organizati -You can use [AWS Control Tower](./org-management.html#mgmt-tower) as outlined earlier in this guide to orchestrate your landing zone. If you are currently using a single AWS account, see the [Transitioning to multiple AWS accounts](https://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/) guide to migrate to multiple accounts as early as you can. For example, if your startup company is currently ideating and prototyping your product in a single AWS account, you should think about adopting a multi-account strategy before you launch your product in the market. Similarly, small, medium, and enterprise organizations should start to build their multi-account strategy as soon as they plan their initial production workloads. Start with your foundation OUs and AWS accounts, and then add your workload-related OUs and accounts. +You can use [AWS Control Tower](./org-management.html#mgmt-tower) as outlined earlier in this guide to orchestrate your landing zone. If you are currently using a single AWS account, see the [Transitioning to multiple AWS accounts](https://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/welcome.html) guide to migrate to multiple accounts as early as you can. For example, if your startup company is currently ideating and prototyping your product in a single AWS account, you should think about adopting a multi-account strategy before you launch your product in the market. Similarly, small, medium, and enterprise organizations should start to build their multi-account strategy as soon as they plan their initial production workloads. Start with your foundation OUs and AWS accounts, and then add your workload-related OUs and accounts. @@ -22 +22 @@ You can use [AWS Control Tower](./org-management.html#mgmt-tower) as outlined ea -For AWS account and OU structure recommendations beyond what’s provided in the AWS SRA, see the [Multi-account strategy for small and medium businesses](https://aws.amazon.com/blogs/mt/multi-account-strategy-for-small-and-medium-businesses/) blog post. As you’re finalizing your OU and account structure, consider the high-level, organization-wide security controls that you would want to enforce by using service control policies (SCPs), resource control policies (RCPs), and declarative policies. +For AWS account and OU structure recommendations beyond what's provided in the AWS SRA, see the [Multi-account strategy for small and medium businesses](https://aws.amazon.com/blogs/mt/multi-account-strategy-for-small-and-medium-businesses/) blog post. As you're finalizing your OU and account structure, consider the high-level, organization-wide security controls that you would want to enforce by using service control policies (SCPs), resource control policies (RCPs), and declarative policies. @@ -26,4 +26 @@ For AWS account and OU structure recommendations beyond what’s provided in the - * Do not replicate your company’s reporting structure when you design your OU and account structure. Your OUs should be based on workload functions and a common set of security controls that apply to the workloads. Don’t try to design your complete account structure from the beginning. Focus on the foundational OUs, and then add workload OUs as you need them. You can [move accounts between OUs](https://docs.aws.amazon.com/organizations/latest/userguide/move_account_to_ou.html) to experiment with alternative approaches during the early stages of your design. However, this might result in some overhead around managing logical permissions, depending on SCPs, RCPs, declarative policies, and IAM conditions that are based on OU and account paths. - - - +Do not replicate your company's reporting structure when you design your OU and account structure. Your OUs should be based on workload functions and a common set of security controls that apply to the workloads. Don't try to design your complete account structure from the beginning. Focus on the foundational OUs, and then add workload OUs as you need them. You can [move accounts between OUs](https://docs.aws.amazon.com/organizations/latest/userguide/move_account_to_ou.html) to experiment with alternative approaches during the early stages of your design. However, this might result in some overhead around managing logical permissions, depending on SCPs, RCPs, declarative policies, and IAM conditions that are based on OU and account paths. @@ -37 +34 @@ The [AWS SRA code library](https://github.com/aws-samples/aws-security-reference -As soon as you have created multiple AWS accounts, you should give your teams access to the AWS resources within those accounts. There are two general categories of identity management: [workforce identity and access management](https://aws.amazon.com/identity/workforce-identities/) and [customer identity and access management (CIAM)](https://aws.amazon.com/identity/customer-identities/). Workforce IAM is for organizations where employees and automated workloads need to log into AWS to do their jobs. CIAM is used when an organization needs a way to authenticate users to provide access to the organization’s applications. You need a workforce IAM strategy first, so your teams can build and migrate applications. You should always use IAM roles instead of IAM users to provide access to human or machine users. Follow the AWS SRA guidance on how to use AWS IAM Identity Center within the [Org Management](./org-management.html#mgmt-sso) and [Shared Services](./shared-services.html#shared-sso) accounts to centrally manage single sign-on (SSO) access to your AWS accounts. The guidance also provides design considerations for using IAM federation when you cannot use IAM Identity Center. +As soon as you have created multiple AWS accounts, you should give your teams access to the AWS resources within those accounts. There are two general categories of identity management: [workforce identity and access management](https://aws.amazon.com/identity/workforce-identities/) and [customer identity and access management](https://aws.amazon.com/identity/customer-identities/) (CIAM). Workforce IAM is for organizations where employees and automated workloads need to log into AWS to do their jobs. CIAM is used when an organization needs a way to authenticate users to provide access to the organization's applications. You need a workforce IAM strategy first, so your teams can build and migrate applications. You should always use IAM roles instead of IAM users to provide access to human or machine users. Follow the AWS SRA guidance on how to use AWS IAM Identity Center within the [Org Management](./org-management.html#mgmt-sso) and [Shared Services](./shared-services.html#shared-sso) accounts to centrally manage single sign-on (SSO) access to your AWS accounts. The guidance also provides design considerations for using IAM federation when you cannot use IAM Identity Center. @@ -39 +36 @@ As soon as you have created multiple AWS accounts, you should give your teams ac -As you work with IAM roles to provide user access to AWS resources, you should use AWS IAM Access Analyzer and IAM access advisor as outlined in the [Security Tooling](./security-tooling.html) and [Org Management](./org-management.html) sections of this guide. These services help you achieve least privilege, which is an important preventive control that helps you build a good security posture. +As you work with IAM roles to provide user access to AWS resources, you should use IAM Access Analyzer and IAM access advisor as outlined in the [Security Tooling](./security-tooling.html) and [Org Management](./org-management.html) sections of this guide. These services help you achieve least privilege, which is an important preventive control that helps you build a good security posture. @@ -43,4 +40 @@ As you work with IAM roles to provide user access to AWS resources, you should u - * To achieve least privilege, design processes to regularly review and understand the relationships between your identities and the permissions they require to function properly. As you learn, fine-tune those permissions and gradually trim them down to the least permissions possible. For scalability, this should be a shared responsibility between your central security and application teams. Use features such as [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html), [permission boundaries](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/), [attribute-based access controls](https://www.youtube.com/watch?v=Iq_hDc385t4&t=1318s), and [session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) to help application owners define fine-grained access control. - - - +To achieve least privilege, design processes to regularly review and understand the relationships between your identities and the permissions they require to function properly. As you learn, fine-tune those permissions and gradually trim them down to the least permissions possible. For scalability, this should be a shared responsibility between your central security and application teams. Use features such as [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html), [permission boundaries](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/), [attribute-based access controls](https://www.youtube.com/watch?v=Iq_hDc385t4&t=1318s), and [session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) to help application owners define fine-grained access control. @@ -61 +55 @@ The [AWS SRA code library](https://github.com/aws-samples/aws-security-reference -When your users have access to AWS and start building, you will want to know who is doing what, when, and from where. You will also want visibility into potential security misconfigurations, threats, or unexpected behaviors. A better understanding of security threats enables you to prioritize the appropriate security controls. To monitor AWS activity, follow the AWS SRA recommendations for setting up an organization trail by using [AWS CloudTrail](./security-tooling.html#tool-cloudtrail) and centralizing your logs within the [Log Archive account](./log-archive.html). For security event monitoring, use AWS Security Hub CSPM, Amazon GuardDuty, AWS Config, and AWS Security Lake as outlined in the [Security Tooling account](./security-tooling.html) section. +When your users have access to AWS and start building, you will want to know who is doing what, when, and from where. You will also want visibility into potential security misconfigurations, threats, or unexpected behaviors. A better understanding of security threats enables you to prioritize the appropriate security controls. To monitor AWS activity, follow the AWS SRA recommendations for setting up an organization trail by using [AWS CloudTrail](./security-tooling.html#tool-cloudtrail) and centralizing your logs within the [Log Archive](./log-archive.html) account. For security event monitoring, use AWS Security Hub CSPM, Amazon GuardDuty, AWS Config, and Amazon Security Lake as outlined in the [Security Tooling account](./security-tooling.html) section. @@ -65,4 +59 @@ When your users have access to AWS and start building, you will want to know who - * As you start using new AWS services, make sure to enable [service-specific logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) for the service and store them as part of your central log repository. - - - +As you start using new AWS services, make sure to enable [service-specific logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) for the service and store them as part of your central log repository. @@ -74 +65 @@ The [AWS SRA code library](https://github.com/aws-samples/aws-security-reference - * [Organization CloudTrail](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/cloudtrail/cloudtrail_org) creates an organization trail and sets defaults to configure data events (for example, in Amazon S3 and AWS Lambda) to reduce duplicating the CloudTrail that’s configured by AWS Control Tower. This solution provides options for configuring management events. + * [Organization CloudTrail](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/cloudtrail/cloudtrail_org) creates an organization trail and sets defaults to configure data events (for example, in Amazon S3 and AWS Lambda) to reduce duplicating the CloudTrail that's configured by AWS Control Tower. This solution provides options for configuring management events. @@ -82 +73 @@ The [AWS SRA code library](https://github.com/aws-samples/aws-security-reference - * [Security Hub Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/securityhub/securityhub_org) configures Security Hub CSPM within a delegated administrator account for the accounts and governed Regions within the organization. + * [Security Hub CSPM Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/securityhub/securityhub_org) configures Security Hub CSPM within a delegated administrator account for the accounts and governed Regions within the organization. @@ -97 +88 @@ At this point, you should have: - * The ability to log AWS activities by using AWS CloudTrail; to detect security events by using Security Hub CSPM, Amazon GuardDuty, and AWS Config; and to perform advanced analytics on a purpose-built data lake for security by using Amazon Security Lake. + * The ability to log AWS activities by using AWS CloudTrail; to detect security events by using AWS Security Hub CSPM, Amazon GuardDuty, and AWS Config; and to perform advanced analytics on a purpose-built data lake for security by using Amazon Security Lake. @@ -102 +93 @@ At this point, you should have: -In this phase, plan to apply security at other layers of your AWS organization, as described in the section, [Apply security services across your AWS organization](./security-services.html). You can build security controls for your networking layer by using services such as AWS WAF, AWS Shield, AWS Firewall Manager, AWS Network Firewall, AWS Certificate Manager (ACM), Amazon CloudFront, Amazon Route 53, and Amazon VPC, as outlined in the [Network account](./network.html) section. As you move down your technology stack, apply security controls that are specific to your workload or application stack. Use VPC endpoints, Amazon Inspector, Amazon Systems Manager, AWS Secrets Manager, and Amazon Cognito as outlined in the [Application account](./application.html) section. +In this phase, plan to apply security at other layers of your AWS organization, as described in the section, [Apply security services across your AWS organization](./security-services.html). You can build security controls for your networking layer by using services such as AWS WAF, AWS Shield, AWS Firewall Manager, AWS Network Firewall, AWS Certificate Manager (ACM), Amazon CloudFront, Amazon Route 53, and Amazon VPC, as outlined in the [Network account](./network.html) section. As you move down your technology stack, apply security controls that are specific to your workload or application stack. Use VPC endpoints, Amazon Inspector, AWS Systems Manager, AWS Secrets Manager, and Amazon Cognito as outlined in the [Application account](./application.html) section. @@ -106,4 +97 @@ In this phase, plan to apply security at other layers of your AWS organization, - * As you design your defense in depth (DiD) security controls, consider scaling factors. Your central security team won’t have the bandwidth or full understanding of how every application behaves in your environment. Empower your application teams to be responsible and accountable for identifying and designing the right security controls for their applications. The central security team should focus on providing the right tools and consultation to enable the application teams. To understand the scaling mechanisms that AWS uses to adopt a more shift-left approach to security, see the blog post [How AWS built the Security Guardians program, a mechanism to distribute security ownership](https://aws.amazon.com/blogs/security/how-aws-built-the-security-guardians-program-a-mechanism-to-distribute-security-ownership/). - - - +As you design your defense in depth (DiD) security controls, consider scaling factors. Your central security team won't have the bandwidth or full understanding of how every application behaves in your environment. Empower your application teams to be responsible and accountable for identifying and designing the right security controls for their applications. The central security team should focus on providing the right tools and consultation to enable the application teams. To understand the scaling mechanisms that AWS uses to adopt a more shift-left approach to security, see the blog post [How AWS built the Security Guardians program, a mechanism to distribute security ownership](https://aws.amazon.com/blogs/security/how-aws-built-the-security-guardians-program-a-mechanism-to-distribute-security-ownership/). @@ -115 +103 @@ The [AWS SRA code library](https://github.com/aws-samples/aws-security-reference - * [EC2 Default EBS Encryption](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/ec2/ec2_default_ebs_encryption) configures the default Amazon Elastic Block Store (Amazon EBS) encryption in Amazon EC2 to use the default AWS KMS key within the provided AWS Regions. + * [EC2 Default EBS Encryption](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/ec2/ec2_default_ebs_encryption) configures the default Amazon EBS encryption in Amazon EC2 to use the default AWS KMS key within the provided AWS Regions. @@ -128 +116 @@ The [AWS SRA code library](https://github.com/aws-samples/aws-security-reference -Your business and customer data are valuable assets that you need to protect. AWS provides various security services and features to protect data in motion and at rest. Use AWS CloudFront with AWS Certificate Manager, as outlined in the [Network account](./network.html#network-cf) section, to protect data in motion that’s collected over the internet. For data in motion within internal networks, use an Application Load Balancer with AWS Private Certificate Authority, as explained in the [Application account](./application.html) section. AWS KMS and AWS CloudHSM help you provide cryptographic key management to protect data at rest. +Your business and customer data are valuable assets that you need to protect. AWS provides various security services and features to protect data in motion and at rest. Use Amazon CloudFront with AWS Certificate Manager, as outlined in the [Network account](./network.html) section, to protect data in motion that's collected over the internet. For data in motion within internal networks, use an Application Load Balancer with AWS Private Certificate Authority, as explained in the [Application account](./application.html) section. AWS KMS and AWS CloudHSM help you provide cryptographic key management to protect data at rest. @@ -134,3 +122 @@ As you operate your IT environment you will encounter security events, which are -The AWS SRA, through the design of the [Security Tooling account](./security-tooling.html) and the [deployment of common security services within all AWS accounts](./security-tooling.html#tool-common), provides you with the ability to detect security events across your AWS organization. [AWS Detective](./security-tooling.html#tool-detective) within the Security Tooling account helps you triage a security event and identify the root cause. During a security investigation, you have to be able to review relevant logs to record and understand the full scope and timeline of the incident. Logs are also required for alert generation when specific actions of interest happen. - -The AWS SRA recommends a central [Log Archive account](./log-archive.html) for immutable storage of all security and operational logs. You can query logs by using [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) for data that’s stored in CloudWatch log groups, and [Amazon Athena](http://aws.amazon.com/athena/) and [Amazon OpenSearch Service](http://aws.amazon.com/opensearch-service/) for data that’s stored in Amazon S3. Use Amazon Security Lake to automatically centralize security data from the AWS environment, software as a service (SaaS) providers, on premises, and other cloud providers. [Set up subscribers](./security-tooling.html#tool-security-lake) in the Security Tooling account or any dedicated account, as outlined by the AWS SRA, to query those logs for investigation. +The AWS SRA, through the design of the [Security Tooling account](./security-tooling.html) and the [deployment of common security services within all AWS accounts,](./security-tooling.html#tool-common) provides you with the ability to detect security events across your AWS organization. [Amazon Detective](./security-tooling.html#tool-detective) within the Security Tooling account helps you triage a security event and identify the root cause. During a security investigation, you have to be able to review relevant logs to record and understand the full scope and timeline of the incident. Logs are also required for alert generation when specific actions of interest happen. The AWS SRA recommends a central [Log Archive account](./log-archive.html) for immutable storage of all security and operational logs. You can query logs by using [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) for data that's stored in CloudWatch log groups, and [Amazon Athena](https://aws.amazon.com/athena/) and [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) for data that's stored in Amazon S3. Use Amazon Security Lake to automatically centralize security data from the AWS environment, software as a service (SaaS) providers, on premises, and other cloud providers. [Set up subscribers](./security-tooling.html#tool-security-lake) in the Security Tooling account or any dedicated account, as outlined by the AWS SRA, to query those logs for investigation. @@ -138 +124 @@ The AWS SRA recommends a central [Log Archive account](./log-archive.html) for i -[AWS Security Incident Response](https://aws.amazon.com/security-incident-response/) helps you automate security incident response, investigation, and remediation. It provides pre-built playbooks and workflows to help you respond to security events quickly and consistently. When the proactive response feature is enabled, AWS Security Incident Response [integrates with Security Hub CSPM and Amazon GuardDuty](https://docs.aws.amazon.com/security-ir/latest/userguide/detect-and-analyze.html) to automatically trigger response workflows when security findings are detected. The service helps you standardize and automate your incident response processes across your AWS organization. If you need additional assistance, you can open a service-supported case to engage with the AWS Customer Incident Response Team (CIRT). +[AWS Security Incident Response](https://aws.amazon.com/security-incident-response/) helps you automate security incident response, investigation, and remediation. It provides pre-built playbooks and workflows to help you respond to security events quickly and consistently. When the proactive response feature is enabled, Security Incident Response [integrates with Security Hub CSPM and GuardDuty](https://docs.aws.amazon.com/security-ir/latest/userguide/detect-and-analyze.html) to automatically trigger response workflows when security findings are detected. The service helps you standardize and automate your incident response processes across your AWS organization. If you need additional assistance, you can open a service-supported case to engage with the AWS Customer Incident Response Team (CIRT). @@ -144 +130 @@ The AWS SRA recommends a central [Log Archive account](./log-archive.html) for i - * The phases for building your cloud security architecture, as discussed in this section, are sequential in nature. However, you don’t have to wait for the full completion of one phase before you start the next phase. We recommend that you adopt an iterative approach, where you start working on multiple phases in parallel and evolve each phase as you evolve your cloud security posture. As you go through the different phases, your design will evolve. Consider tailoring the suggested sequence shown in the following diagram to your particular needs. + * The phases for building your cloud security architecture, as discussed in this section, are sequential in nature. However, you don't have to wait for the full completion of one phase before you start the next phase. We recommend that you adopt an iterative approach, where you start working on multiple phases in parallel and evolve each phase as you evolve your cloud security posture. As you go through the different phases, your design will evolve. Consider tailoring the suggested sequence shown in the following diagram to your particular needs. @@ -149 +135 @@ The AWS SRA recommends a central [Log Archive account](./log-archive.html) for i - + @@ -153 +139 @@ The AWS SRA recommends a central [Log Archive account](./log-archive.html) for i -The [AWS SRA code library](https://github.com/aws-samples/aws-security-reference-architecture-examples) provides a sample implementation of [Detective Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/tree/main/aws_sra_examples/solutions/detective/detective_org), which automatically enables Detective by delegating administration to an account (for example, Audit or Security Tooling) and configures Detective for existing and future AWS Organizations accounts. +The [AWS SRA code library](https://github.com/aws-samples/aws-security-reference-architecture-examples) provides a sample implementation of**** a****[ Detective Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/tree/main/aws_sra_examples/solutions/detective/detective_org), which automatically enables Amazon Detective by delegating administration to an account (for example, Audit or Security Tooling) and configures Detective for existing and future AWS Organizations accounts. @@ -163 +149 @@ AI/ML for security -IAM resources +AWS SRA best practices checklist