Incident Response In The AWS Cloud
The Amazon Web Services (AWS) cloud works under a shared responsibility model, just like all major cloud vendors. This means AWS secures the underlying infrastructure and cloud customers are required to protect their cloud resources and data, including accounts and permissions, network and data, and application code deployed in the cloud.
There are several indicators that can signal a potential threat, including abnormal cloud resource utilization or billing activity. To ensure timely incident response, cloud customers need to continuously monitor their cloud environment.
This could mean storing event log data, leveraging AWS security features, and adding third-party monitoring solutions if necessary. You should also create an incident response plan designed especially to respond to security events occurring within the AWS cloud.
AWS Security Incident Domains
Three domains exist within the organization’s responsibility, where incidents relating to security could take place. The distinction between the domains relates to the tools used to respond.
The three domains are:
Service Domain - incidents in the service domain impact a customer’s IAM permissions, AWS account, billing, resource metadata and more. A service domain event is an event that you react to with just AWS API mechanisms, or where there are root causes connected to your resource permissions or configuration and may have associated service-oriented logging.
Infrastructure Domain - incidents within the infrastructure domain are activity connected to the network or data. This includes data and processes on the Amazon EC2 instances, the traffic to the Amazon EC2 instances in the VPC, and components for example containers or various future services. Responses to these events tend to involve restoration, acquisition, or retrieval of incident-related data for forensic purposes. This typically involves correspondence with the operating systems of an instance, and for certain cases, could include AWS API mechanisms.
Application Domain - incidents in this domain take place in the software deployed or the application code to the infrastructure or services. This domain must be an element of your cloud threat response and detection runbooks, and could incorporate responses like those within the infrastructure domain. With considered and appropriate application architecture, you are able to oversee this domain through cloud tools, making use of automated recovery, forensics and deployment.
For each of these domains, you should think about the cybercriminals who could act against your resources, data or account. Whether external or internal, make use of a risk framework to ascertain what the particular risks are to the organisation and prepare with these risks in mind.
Within a service domain, you strive to attain your objectives solely with AWS APIs. Within the infrastructure domain, you may employ both digital forensics/incident response (DFIR) software and AWS APIs for the operating system of the workstation. For example, an Amazon EC2 instance which you have developed for IR purposes.
Infrastructure domain incidents could include disk blocks on an Amazon Elastic Block Store (Amazon EBS) volume, studying network packet captures, and/or volatile memory gained via an instance. Ransomware is a rising threat, making it important to pursue a careful AWS backup strategy.
Indicators of AWS Security Events
Several security events exist that you may not regard as incidents, however, it could still be worthwhile investigating them. To identify security-related events in the AWS Cloud environment, you could employ these mechanisms.
Though not a complete list, consider these examples of potential indicators:
Logs and Monitors - review AWS logs (including Amazon S3 access logs, Amazon CloudTrail, and VPC Flow Logs) as well as security monitoring services (including Amazon Detective, Amazon GuardDuty, Amazon Macie, or AWS Security Hub). Make use of monitors for example Amazon CloudWatch alarms and Amazon Route 53 health checks. Use Linux syslog logs, Windows Events and different application-specific logs which you could create in the applications, following this log to Amazon CloudWatch via a CloudWatch agent.
Billing Activity - an unexpected variation in billing activity could point to a security event.
Threat Intelligence - if you sign up to a 3rd party intelligence feed, you could use that information together with other monitoring and/or logging tools to find possible indicators of events.
One-time Contract - it could be the developers, customers, or other staff members who identify something unusual, so you have to have a well-publicised and well-known way for them to contact the security team. Some methods include contact email addresses, web forms and ticketing systems. If your organization deals with the public, you could also require a public-facing security contract tool.
AWS Security Hub is a tool which AWS provides for detection and automation. Security Hub offers you a detailed view of the compliance status and high-priority security alerts over AWS accounts in a centralized place, providing more visibility to such indicators.
AWS Security Hub does not equal Security Information and Event Management (SIEM) software, and thus doesn’t retain log data. Rather, it organizes, aggregates and prioritizes security alerts, or discoveries, from several AWS services.
This provides Security Operations teams with deeper insights when an event takes place. Security Hub monitors the environment on an ongoing basis using automated compliance checks according to the AWS industry standard and best practices followed by your organization.
AWS Security Incident Response Plan
All AWS users in an organization must have an appreciation of the security incident response procedures, and the security staff should know how to react to security issues. While preparation and education are essential, it is recommended that customers practice these skills via simulations to improve and iterate their processes.
A successful incident response plan in the cloud should achieve the following:
- Educate the security incident and operations response staff with respect to cloud technologies and how the organization plans on using them.
- Prepare the incident response team to react to and detect incidents in the cloud by permitting detective competencies and providing the right access level to the required tools and cloud services. Prepare the required runbooks, both automated and manual, to ensure consistent and reliable responses. Work together with different teams to create expected foundational operations and employ that knowledge to notice deviations from regular operations.
- Simulate both unexpected and expected security events in the cloud to demonstrate how well you have prepared.
- Iterate on the outcome of the simulations to reduce delays, increase the scale of the response posture, and further minimise risk.
Conclusion
In this article, I covered the basics of incident response within the AWS cloud:
- Understanding the shared security model and the three domains cloud customers are responsible to secure.
- Monitoring for indicators of AWS security events, and establishing logging, monitoring, and threat intelligence processes as needed.
- Developing and implementing an AWS security incident response plan designed to cover the unique security challenges posed by cloud environments.
I hope this will be of help as you gain a better understanding of developing, implementing, and maintaining incident response practices and processes within the AWS cloud
__________________
Gilad David Mayaan is a strategic Consutant, technology writer and CEO of Agile SEO, a digital marketing agency focused on technology.
__________________
You Might Also Read:
Six Reasons To Move Your SIEM To The Cloud:
