The contents of this library are provided for informational purposes only. It represents the current product offerings and practices from Amazon Web Services (AWS) as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS products or services, each of which is provided “as is” without warranty of any kind, whether express or implied. This document does not create any warranties, representations, contractual commitments, conditions, or assurances from AWS, its affiliates, suppliers, or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.
© 2021 Amazon Web Services, Inc. or its affiliates. All Rights Reserved. This work is licensed under a Creative Commons Attribution 4.0 International License.
This AWS Content is provided subject to the terms of the AWS Customer Agreement available at http://aws.amazon.com/agreement or other written agreement between the Customer and either Amazon Web Services, Inc. or Amazon Web Services EMEA SARL or both.
This collections of files is provided as an example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services.
Before we get into the details: We want your help. No, really.
There may be a little voice inside your head that is telling you that you're not ready to contribute to playbooks; that your skills aren't nearly good enough to contribute. What could you possibly offer a project like this one? We assure you -- the little voice in your head is wrong. If you can write code at all or have experience with incident response, then we need your contributions! Writing perfect playbooks isn't the measure of a good responder (that would disqualify all of us!); it's trying to create something, making mistakes, and learning from those mistakes. That's how we all improve.
We've provided a clear playbook creation guide. This outlines the process that you'll need to follow to get a playbook developed and approved for use with Ziplines. By making expectations and process explicit, we hope it will make it easier for you to contribute. And you don't just have to write code. You can help out by writing documentation, tests, or even by giving feedback about this work. (And yes, that includes giving feedback about everything in this README)
- Compromised IAM Credential(s)
- Denial of Service / Distributed Denial of Service
- Inappropriate Public Resources: S3)
- Inappropriate Public Resources: RDS)
- Unauthorized Network Changes
- Bitcoin and Cryptojacking
- Responding to Ransom in AWS
- AWS Cloud Adoption Framework
- AWS Incident Response Blogs
- AWS Security Incident Response Guide Wiki
- AWS Security Incident Response Guide Downloadable
- AWS Security Reference Architecture (AWS SRA)
- AWS Shared Responsibility Model
- AWS Well Architected Resources
See CONTRIBUTING for more information.
The documentation is made available under the Creative Commons Attribution-ShareAlike 4.0 International License. See the LICENSE file.
The sample code within this documentation is made available under the MIT-0 license. See the LICENSE-SAMPLECODE file.