In the security world, we're tasked with assessing many alerts daily: We have to decide which alerts need a response, then gather additional data and filter out false positives, often with little upfront context. We wanted to address this problem by building a specialized tool: an in-house, Zapier-specific context engine named Hobi. After a year and a half of work leading the design and engineering of our new context engine, it is complete. I would love to share what it's about.
The problem with security alerts: They often lack context.
The role of Security Detection and Response is to understand and follow up when something deviates from expected business operations. This helps keep our business running smoothly and our customers' data safe. We have many specific alerts designed to watch out for anything that looks like unusual activity.
Sometimes, it's easy to determine whether an event is a legitimate concern or not by how much information our SIEM (Security Information and Event Management) has been able to gather from a log source. But often, we have the manual task of looking at other data sources to gather additional context around an alert.
When an alert triggers, we generally need supplementary contextual data to understand the big picture fully. This includes locations, IPs, activity and event information from other platforms, and the usual activity done by the actor or service in the alert. The investigator gathers this information from many different tools and takes up a large percentage of alert triage time.
Hobi collects data automatically to create context
Hobi, our context engine, is designed to perform most of the data gathering needed for effective alert triage. It's a modular tool with libraries for gathering data from log aggregators, identity providers, cloud environments, and more. It can check IP WHOIS information, do geolocation lookups, pull historical user IP addresses, and much more. It's a fancy way of saying that we now automatically gather information from various log sources around the company to build a better picture of what the activity in question actually means before any human has ever laid eyes on it. Hobi collects this information in real-time as alerts are generated and can also be invoked as part of the investigation process if more information is needed.
Our context engine allows us to use this newly available data within the alert logic, helping to decide whether an activity is expected, if the alert is a false positive, or whether the severity should be modified. Hobi also has a built-in Slack module that allows us to gather information about resources or employee feedback that might be part of the alert's context. This new pre- and post-alert contextualization automates away what was previously done manually.
How does Hobi differ from a SOAR?
For context, SOAR stands for Security Orchestration, Automation, and Response. It's a group of security technologies that allows organizations to respond to incidents automatically.
Hobi focuses on aggregating and consolidating information from various services and tooling to provide additional context for an alert. It is part of the entire alert pipeline from logic to follow-up. A SOAR focuses on automating the handling and responding to security events operations once an alert or condition has been triggered.
The critical difference is that Hobi can programmatically query data sources for point-in-time context (cloud resource tags, Okta metadata, etc.) that can be used in alert processing and response. It helps eliminate the need for things like lookup tables (and all of their problems) by reaching out to an authoritative data source and allowing for employee feedback on alerts related to them.
Hobi doesn't replace a SOAR but rather complements it by providing additional actionable data.
How Hobi creates context
Hobi is split into two primary services:
An API that returns the context about a given alert.
A SlackBot for interactive use or gathering user feedback regarding an alert.
How the Hobi API endpoints are used
Hobi can be reached via API endpoints, accessible as a regular web request. This means it can be called manually, as a part of a script, or embedded within any code. Adding and accessing a new data source or type is fairly straightforward:
We write a small Python module to interface with a service's native API. The module specifies the types of supported indicators (IP, email, URL, domain, etc.) and contains the processing logic for returning helpful context.
We add a new Hobi API endpoint to call that specific module, enabling targeted context collection (for example, /okta/user) from a single tool.
More API endpoints that reference particular modules that return specific data for desired use cases (for example, IP-searching endpoints, user-searching endpoints, tool-specific endpoints, etc.) can be created.
Users and services can get an access key and begin querying data about indicators and resources.
This exact workflow is how we leverage Hobi in our SIEM detections.
How the Hobi SlackBot works
The general flow goes as follows:
Our SlackBot reads the basic details of a new alert that pops into Slack from our SIEM
It then spiders out to all the log sources we have connected and finds relevant information on the alert and any matching previous activity.
Hobi reports any new contextual information and uses historical data to decide whether the alert is likely a false positive or not.
Hobi then pings either the user/team or our team Detection and Response in Slack with the decision and action.
The flow completes the feedback loop and reduces manual work, as Hobi can self-resolve alerts or reach out to parties when needed.
We're always improving Hobi
Hobi collates all the alert determinations and provides a report to our SIEM. This report will help us identify which alerts need improvements based on the true/false positive ratio.
We will continue developing new modules for Hobi and expand the sources and types of data it can gather. Hobi is still young, and we're excited to see where it will be a year from now!
And as for the name? The team named our new context engine Hobi as a nod to one of my interests, K-Pop. Hobi is the nickname for an artist I admire. I lived in Korea for a while, so naturally, this fell into place.
