AWS infrastructure security

Security Ops Waiting Game

Remember in the olden days, when central IT ruled the land? If an application required fixes or new capabilities, the business put in a change order, and the IT folks got to it at some point? That seems like eons ago because in cloud-time it was. In today’s environment, business IT drives projects, and in a lot of cases they’ve staffed up a DevOps capability to build and operate those projects in the cloud.

So what does that leave Security to do? We believe that to remain relevant to the organization; Security must embrace a Center of Excellence model where the team advises the business IT teams about how to do security. That involves what I call the 3 G’s: Guidance, Governance, and Guardrails. Security educates the teams about what good security looks like (Guidance), and they spearhead the development of the policies and best practices that ensure data is protected in the cloud (Governance). They also need the ability to enforce a select few policies that fall into a category we call “things that should never happen here.” (Guardrails)

In this model, Security continuously monitors the entire (multi-) cloud infrastructure to assess security posture. When a policy violation or potential attack happens, Security generates alerts to notify the operational team of the issue.

Then the fun begins. An alert fires, and then what? Who is responsible for making the operational changes? In a DevOps context, it’s not likely to be the security team (except in the most egregious of attacks violating a Guardrail). So security sends the alert over to the operational team for the (quick) fix.

And then they wait. And wait. And wait. And wait. I’m not being judgmental or pointing the finger at Ops. They’ve got a lot of competing priorities and have no idea why they would fix the security issue over any other issue in their queue.

Security sees nothing has happened regarding their request, so they ask again. And then they wait some more. By this time, the Ops team starts to get pissed because the security wheel is squeaking again. Same as it ever was. And the relationship turns (or returns) adversarial. Unfortunately in a lot of environments DevSecOps remains aspirational due to this communications breakdown.

But no one likes the person that tells you how everything is screwed up. We’re here to bring solutions to the table. Firstly, the alert must get routed to the responsible party with sufficient context and the ability to collaborate a bit to dig deeper into the issue, hopefully using the tools they already use all day. Throwing a generic alert thrown over the transom and hope it gets to the right folks and then fixed no longer makes sense. We call this Intelligent Security Alerting, which makes sure the alert ends up in the hands of those responsible.

Once the alert ends up with the responsible party, they need context to know the importance of the issue, and what to do to fix it. Sufficient context includes the impacted account/application, the risk/urgency, and most importantly, how to fix it. DisruptOps issues have the raw JSON of the finding easily accessible, so the Ops folks can dig deep to gain a proper understanding regarding the issue.

The Ops team also should be able to *take action* without having to work in multiple consoles or otherwise disrupt the flow of their work. DisruptOps enables the operational teams to take actions (remediate, create Jira ticket, escalate, ignore, suppress, etc.) right within the tool where they get the alert (Slack, Microsoft Teams, etc.). So not only does the alert show up in the right place, but the Ops team can fix the issue without leaving Slack or Teams. Yup, you have to see it to believe it, so sign up for a demo.

To be clear, the security team will need to have a good and productive relationship with the Ops folks. DisruptOps makes the Security team heroes by tearing down the walls between Security and Ops, making everyone’s lives easier. Having the capability for security to intelligently alert with embedded context and the ability to take action right within the tools the Ops teams already use will go a long way towards eliminating the security waiting game.

Leave A Comment

20 − three =

About the Author: Mike Rothman

Mike is a 25-year security veteran, specializing in the sexy aspects of security, like protecting networks and endpoints, security management, compliance, and helping clients navigate a secure evolution to the cloud. In addition to his role at D-OPS, Mike is Analyst & President of Securosis.

Sign-up for Updates!

  • This field is for validation purposes and should be left unchanged.