The fifth pillar to well-architected AWS cloud security - IR (Incident Response)

This is the sixth in a series of seven on the five pillars for well-architected AWS security.  For the entire series, visit the Five pillars – AWS blog page here.  

For a number of organizations, Incident Response (IR) is the first symptom of a poorly-architected cloud security framework.  Often, incidents aren’t even identified until well after they have occurred, and damage has been done.  In those cases, response quickly escalates to remediation, and there are numerous cautionary tales of companies being irreparably harmed by large and undetected breaches and incidents.

Within a well-architected IR Framework, the notion of IR is more basic.  Incidents are typically security failures or non-compliances that can be easily identified and rectified.  Solutions that prevent incidents still may have the requirement to identify intentional malicious incidents, even if they were ultimately prevented for occurring. 

IR can take many forms, from simple identification and rectification, or prevention, to changes in policies and strategies that avoid future similar incidents.  Organizations that leverage well-architected cloud frameworks as a basis to enforce security and workflow best practices can utilize IR as a way to identify where best practices aren’t being followed and why.  In that way, IR becomes part of a continuous feedback loop to help keep a well-architected cloud framework secure. 

Within the AWS infrastructure, several practices can help facilitate effective incident response

• Detailed logging which contains content including file access and changes


• Automated processing of events through AWS APIs


• Leveraging AWS CloudFormation to create a “clean room” in which you can carry out forensics in an isolated environment


• Leveraging AWS Lambda to create rules that will trigger automated responses

To develop a well-architected IR pillar, customers must understand first how they will respond to an incident, including access to their InfoSec team and a means to automatically isolate instances.  Visit the AWS Well-Documented Labs documentation to read more about Incident Response.

In the final blog in this series, we’ll discuss ways to tie these pillars together into a continuous cycle of Well-Architected AWS Cloud Security.  To follow this series in its entirety, visit the Five Pillars – AWS blog page here.

 

Barracuda Cloud Security Guardian has been designed from the ground up to integrate with AWS and leverage built-in security and alerting features.  For a free scan, visit our website here.