AWS whitepapers documentation change
Summary
Removed entire content of the file which contained guidance on documenting architecture diagrams and security patterns for incident response.
Security assessment
The change deletes documentation about security incident response practices but provides no evidence of addressing a specific vulnerability or security incident. Removal appears to be content cleanup without security justification.
Diff
diff --git a/whitepapers/latest/aws-security-incident-response-guide/document-and-centralize-architecture-diagrams.md b/whitepapers/latest/aws-security-incident-response-guide/document-and-centralize-architecture-diagrams.md index 02c47c879..8b1378917 100644 --- a//whitepapers/latest/aws-security-incident-response-guide/document-and-centralize-architecture-diagrams.md +++ b//whitepapers/latest/aws-security-incident-response-guide/document-and-centralize-architecture-diagrams.md @@ -1 +0,0 @@ -[View a markdown version of this page](document-and-centralize-architecture-diagrams.md) @@ -3,110 +1,0 @@ -[](/pdfs/security-ir/latest/userguide/sir-ug.pdf#document-and-centralize-architecture-diagrams "Open PDF") - -[Documentation](/index.html)[Security Incident Response](/security-ir/index.html)[](what-is.html) - -# Document and centralize architecture diagrams - -To quickly and accurately respond to a security event, you need to understand how your systems and networks are architected. Understanding these internal patterns is not only important for incident response, but also for verifying consistency across applications that the patterns are architected with, according to best practices. You should also verify that this documentation is up to date and regularly updated in accordance with new architecture patterns. You should develop documentation and internal repositories that detail items such as: - - * **AWS account structure** \- You need to know: - - * How many AWS accounts do you have? - - * How are those AWS accounts organized? - - * Who are the business owners of the AWS accounts? - - * Do you use Service Control Policies (SCPs)? If so, what organizational guardrails are implemented by using SCPs? - - * Do you limit the Regions and services that can be used? - - * What differences are there between business units and environments (dev/test/prod)? - - * **AWS service patterns** - - * What AWS services do you use? - - * What are the most widely used AWS services? - - * **Architecture patterns** - - * What cloud architectures do you use? - - * **AWS authentication patterns** - - * How do your developers typically authenticate to AWS? - - * Do you use IAM roles or users (or both)? Is your authentication to AWS connected to an identity provider (IdP)? - - * How do you map an IAM role or user to an employee or system? - - * How does access get revoked when someone is no longer authorized? - - * **AWS authorization patterns** - - * What IAM policies do your developers use? - - * Do you use resource-based policies? - - * **Logging and monitoring** - - * What logging sources do you use and where are they stored? - - * Do you aggregate AWS CloudTrail logs? If so, where are they stored? - - * How do you query CloudTrail logs? - - * Do you have Amazon GuardDuty enabled? - - * How do you access GuardDuty findings (for example, console, ticketing system, SIEM)? - - * Are findings or events aggregated in a SIEM? - - * Are tickets automatically created? - - * What tooling is in place to analyze logs for an investigation? - - * **Network topology** - - * How are devices, endpoints, and connections on your network physically or logically arranged? - - * How does your network connect with AWS? - - * How is network traffic filtered between environments? - - * **External infrastructure** - - * How are externally-facing applications deployed? - - * What AWS resources are publicly accessible? - - * What AWS accounts contain infrastructure that is externally facing? - - * What DDoS or external filtering is there? - - - - -Documenting internal technical diagrams and processes eases the incident response analyst’s job, helping them quickly obtain the institutional knowledge to respond to a security event. Thorough documentation of internal technical processes not only simplifies security investigations, but also adjusts for rationalization and evaluation of the processes. - - **Javascript is disabled or is unavailable in your browser.** - -To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions. - -[Document Conventions](/general/latest/gr/docconventions.html) - -Develop and test an incident response plan - -Develop incident response playbooks - -Did this page help you? - Yes - -Thanks for letting us know we're doing a good job! - -If you've got a moment, please tell us what we did right so we can do more of it. - -Did this page help you? - No - -Thanks for letting us know this page needs work. We're sorry we let you down. - -If you've got a moment, please tell us how we can make the documentation better.