Operations | Monitoring | ITSM | DevOps | Cloud

In this Black Hat talk, Nicole Beckwith introduces APEX (Adversarial Pattern Extraction and Correlation), a detection framework—not a Cribl product—that clusters TTP-based signals around entities to support behavioral detection. It is intended for security practitioners, SOC and detection teams, and threat hunters who want to learn how to use raw telemetry or OCSF data, TTP chaining, time windows, criticality, and cross-correlation to detect behavior beyond static indicators and rule-count coverage.

Watch the full episode: MCP vs CLI: Does it even make a difference? Live Laugh Logs ep. 3.

AURA runs as a standalone service and knows nothing about Slack. A separate bridge streams events off its API, which is what makes the chat tool swappable. This is the implementation behind the automated PagerDuty investigation demo. Jeff Vogt walks the whole path an incident takes: a Grafana alert fires PagerDuty, PagerDuty opens a Slack channel and sends a webhook, and a service called AURA Bridge picks it up and calls AURA's API with an investigation prompt.

Two engineers can hold the same approve button and still not be allowed to make the same change. The key riding with the approval settles it. AURA's human in the loop config gates the create_pipeline tool on the Mezmo MCP server and sends each request to a webhook for review. A mock UI stands in for the approval system here, and Mike walks through the payload schema so you can point it at your own.

Nobody wants an API key sitting in an agent's config file on a shared server. Mike shows how AURA takes the credential off the request instead. AURA can hold your keys in its config file, but it does not have to. Mike Shearer, one of AURA's creators, walks through the alternative: AURA reads named headers off the incoming request and forwards them to the MCP servers it calls, so the credential never has to sit on disk.

Ingestion stops, and you start reading system tables by hand to find out why. This run checks disk, merges, and replication across every replica first.

3 a.m., the pager fires, and the runbook describes a service that shipped three versions ago. Ask the agent what the cluster actually has instead. Runbooks go stale because clusters change faster than documentation does. Every deploy, every new service, every renamed alert widens the gap between what is running and what is written down.