Preparing Your Organization for Incident Response on AWS

By Orel Einy

AllCloud Blog: Cloud Insights and Innovation

Another day, another hack. Security incidents evolve fast, continue to happen and should be taken seriously within every organization. The question organizations should focus on is not if, but when.

If you think you won’t become a victim or that you will get a pass, I advise you to rethink your security posture. So that there are no surprises, be prepared for an attack as it is quite possible that it can happen to your organization.

These facts aren’t different on the cloud, and taking advantage of cloud-native capabilities to empower your security team and enhance your preparation is often challenging. The picture is vast and the options are limitless as each goal can be achieved in several ways with various complexities that arise en route. On top of that, the primary focus of DevOps teams is not typically security-driven.

This topic has been discussed endlessly, but have you analyzed the ROI of your company’s security against the consequences of a security incident? In case not, I advise you to take that as the first step to better understand the risks your organization faces, what’s most important to you, and how much effort would be required in order to fully mitigate these risks or at least minimize them to an acceptable level. In order to be fully aware of the security risks, ensure that you either have a dedicated security team in place, an external company, or a security consultant that you trust to assist you.

Another point to consider, which is somewhat embarrassing, relates to misconfigured repositories. We still face scenarios of publicly-configured repositories which sometimes lead to data leakage and compromised credentials. The consequences  of this may not be pleasant, but configuration to avoid that exists and should be enforced. Before starting your project take security into consideration, this will provide you 10x the benefit compared to the risk you may face in case of a breach.

I’ve seen many pitfalls regarding this subject, and in most cases Incident Response is established properly when the management and security teams share support, efforts and full cooperation. The senior management should be involved and support security teams by embracing them as an enabler, not a blocker, while security teams should provide transparency during ongoing incident management and risk mitigation. Needless to mention that this should be achieved in a timely manner, professionally and methodologically to minimize damage, exposure, and prevent reputation impact.

Protecting the Diamonds

It’s important to understand the threats and invest accordingly in people, technology, and processes to strengthen the security layers around your diamonds – Diamonds? Wait, which diamonds?

Adversaries’ goals are creative and sometimes unique, and you should keep in mind that these goals are not always driven by data or money. Some of them are, but others are eager for revenge and reputable impact and some just enjoy this as a challenge to gain recognition within their community.

Knowing your organization top to bottom from a risk-driven aspect (assets, backups, PHI, PII, compliance, regulations, legal, and more) is something that varies between one organization to another, and each organization has its own responsibility to define what their diamonds are and how to protect them, regardless of the environment.

Improving your security with threat intelligence platforms, feeds, services and frameworks to cover Indicators of Compromise (IOC’s) and Tactics, Techniques and Procedures (TTP’s) used by adversaries are not less important. For example, getting familiar with MITRE ATT&CK Matrix for AWS can benefit your organization with comprehensive detection capabilities, which can be applied in your detective and preventive controls to either detect or break the Kill Chain of an attack as well as improve the expertise of your security team.

I’ve been in countless discussions when organizations come up with the notion that they don’t possess anything valuable, no one has a reason to hack them, they aren’t important, aren’t successful enough, and the list goes on – don’t make that mistake, since the price may be high to bear.

Building the Arsenal on AWS 

Building security layers properly requires a solid foundation to lean on, therefore, the preparation is an important process that evolves over time. This requires the business to provide the resources and budget, while the security team selects the right set of tools (AWS IR, Margarita Shotgun, etc.), experienced and dedicated security personnel (deep knowledge with threats and security on AWS) adopting frameworks and guidelines (NIST, CIS, Cloud Security Alliance), industry principles (Defense-in-Depth, Least Privilege, etc.) and of course using automation recipes.

Implement detective and protective controls provided by AWS Security Services. These services are becoming more robust overtime with additional capabilities and features that extend the efficiency and protection around your AWS Accounts. I advise starting off with the following best practices:

I highly recommend leveraging the alignment between NIST CSF to the AWS Cloud. This can provide you a quite powerful advantage with a leading framework to handle Cybersecurity incidents. However, this requires the understanding, expertise, and practices both with NIST CSF practical hands-on on AWS. Be aware that aiming for perfect results tends to involve complexity and may drag your team to extended timelines or take you off the track, or other unknown pitfalls. I advise establishing each CSF Core Function as a baseline and then stack additional efforts for improvements. Divide your plan into 5 phases for each CSF Core Function and know-how to measure your success in order to continue. That being done, can serve your organization with a leading methodological framework for Incident Handling on AWS.

Orel Einy

Cloud Security Specialist

Read more posts by Orel Einy