Incident Response in AWS

The AWS Security Specialization exam is divided into five domains:

  • Domain 1: Incident Response
  • Domain 2: Logging and Monitoring
  • Domain 3: Infrastructure Security
  • Domain 4: Identity and Access Management
  • Domain 5: Data Protection

In this post we will introduce the first domain, incident response (IR). It is critical that the entire IT staff be trained and have the opportunity to develop their IR skillsets. The reason is that bad security will negate even the best architected cloud environment. Regardless of whether a person is in a technical IT role or not, every member of our organization must know their role when an incident occurs.

An exploit is a program or piece of code designed to find and take advantage of security flaws. Anyone who has ever experienced one has seen firsthand that these are able to cripple business processes and productivity.

NIST SP 800-53 defines a security incident as “an occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system process, stores, or transmits that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable us policies”.

An incident in a cloud environment will involve any event that outside of a systems tolerances. This is slightly different from the NIST definition and we need to understand that all incidents will be events but not all events will be an incident. Personnel must be trained to determine which events should be identified as an incident.

Event management is key to our incident response process. It is the process that identifies an event that will need to be analyzed. Some of these events will be qualified as an incident.

The definition of an incident in the cloud can be expanded beyond that used traditional security incidents to include unplanned interruptions or reduction in quality of service. With the heavy reliance on automation we can also say that the failure of a configuration item that has not yet affected service could also be defined as an incident.

Incident response will often look much more complicated than it actually is. It is complex but it is not rocket science. A cloud implementation will add some benefits that not found in traditional implementations.

If you have worked for any length of time with cloud services then you probably have heard of the Shared Responsibility Model:

https://www.slideshare.net/AmazonWebServices/the-aws-shared-security-responsibility-model-in-practice

We are not going to detail in this post about the model. It states that AWS is responsible for Security of the Cloud and we are responsible for Security in the Cloud. For incident response this creates four scenarios:

  • Our incident response in the cloud
  • AWS’ incident response for the cloud infrastructure and provided services
  • Coordinated incident response between our organization and AWS
  • Coordinated incident response between our organization and other cloud providers if we are utilizing multiple could providers

Our incident response will be governed by compliance regulations like PCI, SOX, FEDRAMP, or NIST. Each of these may have standards that must be adhered to. Everyone involved in incident response operations will need to be familiar with them.

This post is meant to serve as an introduction to incident response. We will continue our discussion in the next post with an examination of Incident Response Frameworks for a cloud deployment.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.