Security incident on Public Cloud, are you ready?

Source

More and more companies are using the Public Cloud. But are you ready to face Cloud security incidents?

As a customer, you are responsible for the security IN the Cloud: define and manage the Identity Access, backup and encrypt your data, update your operating system (when you operate an IaaS model) or define the firewall rules to protect your assets. The Cloud Service Provider will be responsible for the security OF the Cloud: manage the regions / availability zones, manage the physical network, the hypervisors or the physical storage. This is called the Shared Responsibility Model (see AWS example).

You probably already organized Cyber-Security drills on your On-Premise infrastructure (if you still have one) but did you already perform one on the Public Cloud? On the Public Cloud, the attacks will not be the same as the skills required to operate a Cloud Provider, whatever the one you are using. Your instances will not be the only target of the attackers. You are consuming Cloud Provider APIs for your daily actions (create an instance, give an access to a bucket or create a firewall rules). All these APIs can only be consumed through the Internet and you have to define permissions to allow your users to perform those actions. Attackers are now looking for Cloud misconfigurations to lead an attack.

You have to adapt your security incident response to the Public Cloud! But how to organize a Cyber-Security drill?

Step 1: define the objectives

Maybe you already write a lot of great incident response playbooks, train your teams, implement security tools and define a crisis management organization. If it’s already the case, you will probably want to test all the great things you did and improve your procedures. If you are starting your Cloud journey, it can be a good way for all stakeholders of your company to understand the importance of this topic.

Organizing this kind of Cyber-Security drill will also be the opportunity to test your crisis communication and identify an improvement plan.

Step 2: define the right organization

You will have to start first by answering the questions: who do you want to be involved with? Only your technical teams? Your business users? The decision makers? The list will depend on the objectives defined during step one.

At Decathlon, we are convinced that the security team needs to work every day with the team who operates the Public Cloud, and not only to manage Cloud security incidents. Organizing such drills is a good opportunity to create connections between these two teams. I recommend to mix the teammates and create a Blue team and a Red team for the drill.

Step 3: define the scenario

Now you have your Red team, it’s time to define the scenario! You can choose to work with a 3rd-party company or to organize the drill with your teams. Whatever the choice is, your teams will need time to get ready!

My first advice is to avoid scenarios close to attacks on On-Premise datacenters (like an instance compromission). Use the advantages of the Public Cloud:

• An access key has been leaked;
• Resources have been created to mine Bitcoin;
• Data stored on a bucket has been leaked.

Cloud Service Providers deliver hundreds of services, don’t use all of them for your drill. Highlight the services you are using the most in your company.

It’s important to build your drill on a Cloud test organization. You will build vulnerabilities on your Cloud environment. You don’t want to be really under attack. And your Blue team will be tempted to search for some clues.

Finally, you will also have to decide to connect the drill environment to your security tools like your CSPM (Cloud Security Posture Management) tool for example. It will depend on the objectives of your scenario: do you want to test your tools? The reactivity of your teams? The response of your team? If you choose to connect the drill environment to your security tools, do it when you launch the drill (or your Blue team will have an idea of the scenario).

Step 4: the D-Day

Your teams are ready, you booked a nice and comfortable room, you ordered coffee, juice and french croissants.

Be sure the participants will not be disturbed by their daily job. This day has to be a training day for your teams. Remind everyone the objectives of the drill and give them the rules (how many times, participation of the Red team, etc.). Be sure to have some observers and someone dedicated to taking notes. Before the drill, your Red team will have written the list of elements to find (vulnerabilities and exploitation of them). This checklist will be used to stop the drill at the right time and to debrief it.

Your Blue team has done a great job and found everything (or almost). Before celebrating this moment with your teammates, take time to debrief the drill.

First of all, give time to your Red team and your Blue team to discuss the scenario: which vulnerabilities or their exploitation have been found? How does the Red team build the scenario?

Then, as for any real security incidents, write all together a Post-Mortem:

• The description of the attack;
• The drill timeline;
• The elements found and missed;
• What went well;
• What have been missed;
• Actions plan to be taken after the drill.

All these actions will help you to improve your security response to incidents. Someone has to be nominated to follow the action plan. Finally, share with all stakeholders the results of the drill, it will help to raise awareness.

Last but not least, celebrate this moment with all stakeholders. It will also contribute to building a team spirit between people who maybe don’t have the habits to work together.

Conclusion

To succeed in your Cloud security incident response, you have to be ready (beyond the drill):

• Train your team to the Public Cloud. They have to understand how the Public Cloud differs from the On-Premise world, understand the new threats and how to adapt their responses.
• Define the Roles and Responsibilities of everyone involved in the incident response. Finding their places must be something normal for all your teammates when an incident happens. They have to know exactly what they are supposed to do.
• Create incident response playbooks on the most common use cases we will have to deal with. I recommend creating at least one related to the instance compromission, one on the credentials leak and one on the leak / ransom of data hosted on a bucket or a managed database service. Your playbooks must also describe the recovering process. If you don’t know where to start to write a playbook, have a look at the samples shared by AWS on their public Github repository.
• Automate everything you can to avoid an incident like the leak of credentials on a public git repository. If you don’t know how to start, have a look at this post I wrote.
• Collect and secure your Cloud Provider logs: who did what and when? (Admin Events) Who has access to what and when? (Data Events) Who talks with who? (VPC Flow Logs). Some of these logs have a cost but you will be happy to have them to understand an attack. Be sure they are stored for a long period on a secured location: your SIEM tool (Security Information & Event Management) or on a secured and dedicated cloud account.
• Take the time for a post-mortem after each incident describing:

1. The information related to the incident: people involved, duration, resources impacted, detection, timeline, technical and business impacts, root cause and corrective actions.
2. What went well? What didn’t go so well? Where did we get lucky?
3. The action plan to prevent the incident from happening again.