Introducing Twilio's SOCless: Automated Security Runbooks

October 18, 2019
Written by
Twilion

Decorative header image

How can an organization’s security team defend its customers against threats at scale?

When the Twilio Security Operations team (SecOps) was founded, this challenge weighed heavily on our minds. We knew that automating all our threat investigation and response procedures would be key to safeguarding our customers, but we had no clue where to begin. We also knew that many of our peers were in the same boat.

That’s why today, we’re proud to open-source SOCless: a serverless framework to help organizations easily automate their security workflows and respond to threats quickly and at scale.

To get started with SOCless, visit the documentation at https://twilio-labs.github.io/socless/

Building automated security runbooks

When performing investigations and responding to threats, security professionals follow well-documented, pre-planned, step by step procedures. We call these procedures runbooks.

A typical runbook may require a security professional to use multiple security products, custom scripts, and decision trees to address a threat quickly and effectively.

However, when multiple threats exist simultaneously, it becomes virtually impossible to execute all necessary runbooks both quickly and effectively. If a security professional gets lucky, they’ll end up with a long, hard day. If they’re unlucky, that long, hard day becomes a terrible one for their customers as well.

SOCless supercharges security professionals with the tools to execute their runbooks at scale. With SOCless, security teams focus on designing their runbooks, while SOCless executes them both quickly and effectively in response to threats.

In our last three years developing SOCless, the Twilio SecOps team has successfully used the framework to automate runbooks that:

  • Warn employees of phishing emails within seconds of receipt
  • Investigate anomalous activity in our cloud environment
  • Audit compliance with our customer data access policies
  • Support Twilio’s Git Guard service by detecting when valid Twilio credentials are accidentally pushed to GitHub by customers
  • Interact with individuals via a Slack bot for investigations

And so much more.

Knowing how much SOCless has helped our team meet the security challenges of a business built to scale, we wanted to make SOCless available to other security doers as well.

Designing SOCless

When we set out to build a framework for automating our runbooks, we knew that the best solution for us would:

  1. Allow our team to focus on the things we do best. (Managing servers isn’t one of them.)
  2. Encourage like-minded security developers to amplify their efforts through collaboration.
  3. Grow and adapt to match an ever-changing environment and threat landscape.

That’s why we designed SOCless to be serverless, modular and extensible.

SOCless Is Serverless

SOCless is one hundred percent serverless. Every part is built on AWS’ auto-scaling serverless platform.

SOCless uses AWS Lambda functions written in Python to perform actions in a runbook. SOCless developers use these Lambda functions to integrate with their security products or implement scripts that are relevant to their runbooks. Then, SOCless coordinates these Lambda functions into the desired step-by-step workflow using AWS Step Functions, AWS’ fully managed workflow engine.

Runbook executions are triggered by events received via AWS API Gateway Endpoints or AWS Cloudwatch Events, and findings generated during runbook executions are persisted to AWS DynamoDB tables.

SOCless ships with a Python library called socless_python that abstracts away the complexities of its architecture from SOCless developers, allowing you to focus on implementing your use-cases.

SOCless Is Modular

Out of the box, SOCless’ core architecture and functionality address the basic challenges of automating security runbooks. SOCless helps you handle challenges such as processing and routing alerts to their appropriate response plans, coordinating response steps, persisting investigation findings, and other common issues.

Once SOCless’ core is deployed, you plug in any modules you need to satisfy your specific use-cases. Modules are either custom built or sourced from a community of other SOCless developers. This modular design makes SOCless easier to manage and allows you benefit from existing solutions created by fellow security doers.

For just one example, to get other security teams started on integrating Slack chat bot functionality into their runbooks, we’ve also open-sourced our SOCless Slack Lambda Functions.

SOCless is Extensible

To top it all off, SOCless can easily be extended to support use-cases that are unique to your environment and needs. We’ve taken great effort to ensure that SOCless’s core architecture and functionality can be augmented with additional infrastructure without losing sync with the open-source repository. We’ve accomplished this by organizing the infrastructure components into distinct apps using the Serverless Framework. And since SOCless is native to AWS, the full power of all AWS services are at your disposal to meet your automation needs.

We can’t wait to see what you build

We’re really excited to share SOCless, a serverless framework for automating security runbooks, with you all today.

For us, open-sourcing SOCless is a big first step in fostering a community of fellow security doers who are dedicated to safeguarding the trust their customers place in them. We hope the framework will help your team scale to meet its security challenges, as it has for ours.

We really can’t wait to see what you build with SOCless. Visit the documentation at https://twilio-labs.github.io/socless/ to get started.

Ubani Balogun is a Senior Security Engineer at Twilio focused on scaling security incident investigations and response through automation. He can be reached at ubalogun [at] twilio.com or on LinkedIn at linkedin.com/in/ubaniabalogun.