In part one of this series, we explored how to modernize SecOps processes for the cloud. In part two, we discussed the core capabilities required to accomplish this modernization.

Now that we’ve modernized our core SecOps capabilities, we can start adapting our processes. As a reminder, these changes will focus on the core principles for success in the cloud:

• We will operate in as close to real-time as possible, when needed. While not everything needs to be handled immediately, some things definitely can’t wait.
• Security will collaborate across teams, also with a real-time capability (when needed). Emailing spreadsheets is not the way.
• We will treat misconfigurations as potential adversarial activity until proven otherwise.
• Everything will focus on IAM first since this is the gateway to the management plane.

Adapt, Don’t Replace

One key point we mentioned briefly earlier is that our objective isn’t to build an entirely new program. Unlike many other areas of security, it can be highly valuable to keep cloud security operations aligned with existing security operations. Unless your organization is pure cloud, many issues and incidents will span both cloud and traditional infrastructure.

For example, if you detect a misconfiguration that is then tied to lost/stolen credentials, the investigation and response will expand to cover where those credentials originated from. This could be a developer’s laptop (time for that old-school malware/phishing investigation) or a server in the data center (back to network and server forensics).

If your team is big enough, you will likely want some dedicated cloud responders who will work shoulder-to-shoulder with the non-cloud team. This doesn’t mean you have to shoehorn everyone into exactly the same toolset; depending on what you already use, it may make sense to set up some parallel tooling if existing tools can’t meet the integration and speed requirements for the cloud.

For example, some SIEM solutions can’t send alerts faster than every 15 minutes or aren’t equipped to handle real-time feeds (they are file-based, not event-based). Those SIEM tools can still be incredibly valuable for analysis and hunting but may need to be supplemented with something like a cloud detection and response (CDR) tool that’s designed for real-time cloud threat detection. The CDR extends your existing capabilities.

Extending Process

The same holds true for processes. To the greatest degree possible, we want to adapt and extend, not replace. This is usually possible by integrating the principles we have been discussing. Let’s take the SecOps phases and review specific options for adapting them for the cloud:

Monitor

Expand the monitoring process beyond logs to include the cloud platform, service, and resource configurations (ideally with a real-time inventory). You will want to feed configuration changes into your detection and analysis since a misconfiguration or policy violation might be an indicator of attack. Monitoring should also expand to cover real-time events from your cloud platform; both activity and the events issued from the cloud provider’s security tooling (e.g. GuardDuty, Defender for Cloud, or the Security Command Center).

Detect and Analyze

Detection engineering will expand to include cloud-native threats associated with the management plane, both specific actions and outcomes (configurations). Detectors will need to be tuned for different environments (e.g., dev versus prod) to improve the signal-to-noise ratio. On the analysis side, cloud playbooks should always start with identity and the management plane before dropping into image forensics and network activity. Analysis should also emphasize the importance of identifying external exposures to the Internet or untrusted cloud accounts.

Communicate

Improving communications between the security and operational (and even development) teams is the single most impactful change for modernizing SecOps for the cloud. ChatOps has shown to be one of the most effective means of achieving this thanks to its support for person-to-person and automated messaging. Issues (filtered and prioritized) can be communicated to the responsible team for evaluation and to determine if it was intentional, accidental, or the action of an attacker. Then, SecOps can validate, create an exemption or trigger a more in-depth response. Lower-priority issues can simply feed into a ticketing system; not everything needs to be communicated immediately.

Respond and Remediate

Two key changes can dramatically improve the response process. ChatOps can be used to coordinate responses between SecOps and the team that owns the deployment. This expedites an effective response since the cloud team will know what their stack should look like and how to make changes while reducing impact, while the SecOps team handles the threat hunting, containment and eradication of the attacker. The second key is to ensure SecOps has emergency access to all cloud deployments in case a critical response is needed when the cloud team isn’t available. You don’t want the responders running around trying to wake someone up to trigger a change when the customer database is exposed to the Internet.

These principles can help guide your process modernization initiative. You can review your existing processes and identify opportunities to integrate these concepts. In our next post, we will show specific examples of how this looks in action.