Foundational Elements of Cloud Incidence and Response in 2021 

By: Jake King

Infrastructure Detection and Response (IDR) remains one of the more interesting topics I am asked to cover at Cmd, often in the context of modern cloud workloads and environments. Recently, I had the privilege of speaking at the ISACA North America conference, and covered a few of these topics in a little detail, you can check out a recording of the talk here.


Why is Infrastructure Detection and Response needed?

Given that this is a relatively broad topic, writing a post on a few key takeaways from the presentation felt pertinent for those entering the field of more mature incident response mechanisms in cloud and looking for resources to dive deep on the subject.


Often this search begins with a question, What makes detection in the cloud so difficult? Well, there’s a few key factors at play:


  1. Fast-paced: Systems launch and shut down in minutes, containers even faster.
  2. Heterogeneous in nature: Deployed and maintained by developers.
  3. Often highly automated and flexible: Allows for fast deployment and rapid failure.
  4. Almost always shared: IaaS, PaaS, SaaS? Ownership is difficult to pin down.


The majority of these factors, which differ from traditional data center environment response methodologies, are primarily due to the sprawling nature of the systems at play, bringing us to our first key point of the shared responsibility model:

Source: RedHat


The Shared Responsibility Model

The Shared Responsibility Model provides somewhat of an overview of capabilities and their owners, broken down into common terms leveraged by vendors. A vendor such as Google can provide IaaS, PaaS, and SaaS services within Google Cloud Platform, so it is important to understand the characteristics of each service.


The Shared Responsibility Model outlines the line of delineation between where you must respond to a particular incident or issue and where a cloud provider may need to intervene. This becomes immensely critical when considering scenarios where you may need to trust the vendor’s response times and SLAs.


Determining this trust boundary also allows you to ensure configuration of these services is performed in an effective manner, but doing so requires tooling and skills. Thankfully the industry has responded with incredibly intricate tools in theCloud Security Posture Management  (CSPM), and as such becomes increasingly important to implement to your organization’s Infrastructure Detection and Response (IDR) strategy.


These platforms are designed to detect changes and misconfigurations within your scope of control, allowing for comprehensive benchmarking on common misconfigurations. OpenCSPM and CloudSploit remain excellent open source tools for determining risks within your configured services (and assisting in common hardening & best practices) alongside many paid (vendor supported) platforms. 


Who’s log is this anyway?

Once CSPM has assisted you in configuring console and service permissions with best practices, it is critical to ensure the delivery of mechanisms for responding to an incident, starting with logging. Logging of services, API requests, IAM permissions, and extending into system and host monitoring are items that should be considered where possible. 


While many console default services provide capabilities that can give you insights into the operations of your services, it becomes incredibly critical that you configure not only the kind of logging enabled but also the retention periods, storage locations while ensuring you’re following your governance requirements, and local regulations. It’s especially important to consider gaps in this logging, including network monitoring, runtime monitoring, and application logging.


Logging and tools are in: now for the strategy 

Once you have the foundation in place, ensuring that a sound strategy is developed to respond when something is identified within your tooling and logging systems rounds out the picture. A fantastic reference for those interested in diving into a templated strategy for cloud response is created and maintained by the CIS Cloud Incident Response guide. Migrating your existing strategy will provide some guidance, but a revisit is probably worthwhile if you’re undergoing a cloud transformation.


Consider these and other resources from Cmd to ensure a successful cloud or digital transformation journey!

Get Started

Gain true visibility
in minutes_

Ramp up your Linux defense strategies
and see what you've been missing.



Share via
Copy link