Respond to security incidents in the cloud, they say. Should be easy, they say. But they didn’t tell you everything involved in ‘cloud’ and that incident response to it is in no way ‘easy’. When you think of responding to security incidents, where does your mind go? Is it to third party SaaS applications like your HR platform? Is it to your hosted environment in AWS or Azure? Is it other applications that interface with other applications via Application Programming Interface (API)? The answer is yes, it’s all of the above…and now your Security Operations Center needs to be able to respond to any and all events that happen there.
Let’s break down just one of these areas to further illustrate just how navigation of this complex environment can be. In recent years, there have been several high-profile security incidents that have involved misconfigured or poorly configured API interfaces. While they are convenient and efficient, when you expose applications intending to be functional, sometime security comes in as the last priority.
Security Operations teams are a simple example of this. In order to get automation amongst the disparate tools they use to respond to incidents, we often interface with APIs So, when an event is detected in the SIEM, the SIEM may then interface with a SOAR tool, which then interfaces with other tools like open source intelligence to look up IP addresses, ticketing tools to open requests for other teams to help lock accounts or block malicious IP addresses or sending requests to your Endpoint Detection and Response (EDR) tools to quarantine an endpoint.
The scope of this example spans both internal and external tools, which is typical to an application ecosystem in today’s world, and likely also takes advantage of cloud services. API gateways have been a popular wave to try and wrangle this vast highway of data going back and forth amongst applications, but how do you know that you’ve caught everything? How do you find all those interfaces? You may have better luck in finding them by not relying on a tool, believe it or not. And this same methodology may work to better understand the entire cloud ecosystem that expands beyond just the API interfaces.
The strategy here goes back to teamwork and communication. When the disparate teams that establish and leverage cloud services talk to each other and share common business objectives, they will also understand how to better secure these services and want to implement the protections needed. We have relied heavily in the past on architectural patterns that are lobbed over the wall to other teams, where they are not enforced or used and we end up very much in a space where we play whack-a-mole when something breaks either by malicious attacker or unknowing insider. In order to tackle the cloud security response space, we need to work together.
Another benefit of working with other teams is skill and knowledge transfer. Finding employees who are fully skilled in your specific cloud services will be difficult. But if you can pair them with knowledgeable internal team members who can not only educate on specific internal services but also on how the services tick, while the knowledgeable security employee can in turn educate that person on what they know and how it may apply.
Let’s go back to our API security example from earlier. Some recommendations for securing APIs come down to basic security hygiene:
- Limit access to only services that need the access
- Ensure that services that do connect use strong authentication
- Monitor access to your APIs and understand the difference between valid and non-valid interactions
- Validate data that may be pushed to APIs
- Test your API interface specifically for security use cases*
*Refer to the OWASP API Security project for more information.
This same approach can be applied to any and all cloud services across the organization. A couple other key incident response steps to take ahead of an incident:
- Gather a full inventory of cloud services (note: this also requires talking to people because it may not just be one source for information here. Shadow IT anyone?)
- Understand who owns what service internally
- Get the contact information for each service, including who to reach out to in the case of a security incident, and other pertinent support information may be need to get assistance
- Understand what the service is providing (is it hosting? Is it SaaS?)
In the end, Cloud Incident Response can be much improved by a lot of effort in the preparation phase. The effort may be a bit of a slog depending on your organization, but it will be worth it when your team is attempting to quickly respond to an event.
