Incident detection and response with alert-as-code

Infoservices LLC
May 1 · 5 min read

Perform Incident detection and response by scanning terabytes of log data and define alerts as code for a well managed cloud infrastructure.



is a serverless, real-time data analysis framework which enables cloud ops and security team to scan terabytes of log data from any environment, using data sources and alerting logic you define for incident detection and response.

Incoming log data will be classified and processed by the rules engine. Alerts are then sent to one or more outputs.


  • Serverless & Scalable
  • Alert as code (rules are written in Python)
  • Infrastructure as code (Terraform)
  • Secure (TLS, KMS)
  • Real-time alerting (when Kinesis Stream is used)
  • Merge alerts to reduce noise
  • Extensive data format support (JSON, CSV, KV pairs)
  • Built-in support for dozens of log types and schemas

Serverless Architecture:


SteamAlert supports both near real-time alert and historical alert search

  • Near real-time alert is processed with Kinesis Streams as log source and goes thru Parsing and Rule Analysis as specified in the middle section of the above architecture.
  • The classifier Lambda function is also capable of sending the logs consumed from the Kinesis Streams to Kinesis Firehose and later transformed with Lambda so Athena can query them efficiently

Four parts:

StreamAlert at a high level contains 4 parts:

  • Schemas to define the structure of logs (eg: attributes and data type)
  • Clusters dedicated to specific log data processing (eg: cloudwatch, cloudtrail)
  • Rules to create complex logic on when to trigger (eg: Root login)
  • Outputs to send the alert to different destinations (eg: slack, PD, SNS)


Log schemas are required to detect the correct log type of an incoming record

  • Defined in conf/schemas/<log-type>.json and used by rules in Python to determine which records are analyzed
  • They can be defined in one single file or multiple files for each log type
  • They represent the structure of a given log in <K,V> pairs
  • Keys in a schema refers to name of a field referenced by rules
  • Values in a schema refers to the data type of the field
  • Clusters dedicated to specific log data processing (eg: cloudwatch, cloudtrail)

Let’s understand this schema file:

  • This schema is based on cloudwatch:events
  • Contains few attributes such as account (string), detail (array), etc
  • Uses json as parser to parse the literal and complex type attributes. Eg: event_name attribute is extracted from from detail array as ["detail", “eventName"]


A StreamAlert set up can have multiple clusters to process different types of inbound data (cloudtrail, cloudwatch) or one for each environment or only one cluster to process all inbound data. Adding additional clusters can improve performance.

  • Defined by its own JSON file in the conf/clusters directory. To add a new cluster, a similar JSON with different configuration should suffice
  • A cluster definition typically contains cluster configuration and set of data sources specifying type of inbound data supported
  • Each definition of data source with associated inbound source should be mapped to an existing Schema
  • An optional Module section can be used to enable monitoring with CloudTrail

Let’s understand this cluster file:

  • This cluster config contains configuration, data sources and modules
  • A cluster’s classifier function knows what types of data it should parse based on defined data_sources within each cluster configuration file
  • Each data source (kinesis, s3)contains a mapping of specific resource names (Kinesis stream names, S3 bucket names, etc) along with a list of log types that should be expected from that source
  • Log schemas are defined in one or more files in the conf/schemas directory
  • A Kinesis Stream “abc_corporate_streamalert” produces cloudwatch logs defined by cloudwatch Schema
  • A S3 bucket “abc.ct.logs” produces cloudtrail and vpcflow logs defined by their respective Schema
  • Finally, in-built modules section creates a new CloudTrail and an S3 bucket for the resulting logs generated by StreamAlert


Rules are the interesting part of StreamAlert as it enables to write complex logic in Python to trigger alerts

  • Rules are written in Python that contain data analysis and alerting logic
  • A Rule can be run against multiple log sources or isolated into different environments via cluster configuration
  • Rule alerts can be sent to one or more outputs like SNS, S3, PD, Slack, etc

Let’s understand this Rule python code:

  • There is set of annotations specified on top of the function cloudtrail_root_account_usage
  • The annotation refers to logs cloudtrail & cloudwatch defined by their respective Schema object
  • These two logs merged by useragentkey that is common to both the log data
  • The python function validates whether any Root user login attempted every 5 minutes and sends alert out to two outputs: PagerDuty & Slack
  • The python function can implement complex logic before raising an alert


StreamAlert supports wide range of alerting framework and destinations that includes CloudWatch Logs, Kinesis Firehose, Lambda, S3, SNS, SES, SQS, GitHub, Jira, PagerDuty, Slack, MS Team, etc. Moreover, a new output can be created by inheriting StreamOutputBase class

Enrich with Lookup Tables:

Lookup Tables enable StreamAlert to hydrate & enrich alerting data as well as customize rule logic by pulling down data from external storage. StreamAlert supports S3 & DynamoDB for external data to be augmented

Let’s understand this configuration file:

  • enabled is a boolean to specify whether the lookup table is enabled or not
  • It defined two lookup tables one each with S3 and DynamoDB that contains the lookup table
  • LookupTables makes these storage solutions available to StreamAlert’s Lambda functions. It is available on all classifiers, the rules engine, the alert merger, and the alert processor.
  • Usage:
from streamalert.shared.lookup_tables.core import LookupTables

value = LookupTables.get('my-table-1', 'my-key', 'default-value')

Alert as code architecture:

We have adopted StreamAlert and implemented for centralized logging architecture that does near real-time alerting to various output destinations

Info Services StreamAlert Solution

What Next?

Watch out for our next installment of X-as-code and how Info Services have implemented them in our client solutions

Reach out to Info Services if you need any assistance with cloud workloads


Cloud & AI made easy —

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store