Threat Detection

2 posts

kakao4 min readCurated summary

Finding Real Threats Among Hundreds of Millions of Security Signals — Transforming the Security Monitoring Paradigm with AI

Kakao argues that monitoring hundreds of millions of daily security events cannot scale through human analysts and increasingly complex rules alone. Its solution is a hybrid AI pipeline that filters noise early, analyzes only high-value events with multiple models, and continuously improves through verified feedback. The goal is not to generate more alerts, but to understand context and identify threats worth investigating. ## The Scale Problem: Finding Threats in a Haystack - Endpoint activity such as process execution, network connections, file changes, and privilege escalation produces hundreds of millions of events. - The volume grows rapidly as services expand, while the proportion of genuine attacks remains very small. - Increasing the number of analysts alongside event volume is economically and operationally unsustainable. - AI is needed to correlate events, interpret behavior statistically and contextually, and dynamically distinguish normal activity from anomalies. ## Limitations of Rule-Based Monitoring - Rules can identify what happened, but not why, who initiated it, or whether it fits the environment. - Legitimate deployment commands can resemble backdoor installation, causing high false-positive rates. - Analysis quality varies by analyst experience, shift, and time of day. - Analysts must manually assemble host information, network sessions, process histories, and related logs into an incident narrative. - Expanding detection categories—behavior sequences, statistical anomalies, multi-source correlations, and rare events—makes manual rule maintenance impractical. - SIEM correlation improves on single-event rules but remains limited to predefined scenarios and struggles with unknown attack patterns. - As rule sets and event volumes grow, both maintenance costs and matching performance become problematic. ## A Funnel-Based Hybrid Architecture - Kakao filters events through multiple stages before using AI: - Rule-based filters remove obvious noise. - Learned normal patterns are automatically excluded. - AI performs detailed analysis only on the small remainder requiring judgment. - Rules handle clear, deterministic patterns quickly, while AI evaluates complex contextual situations. - The framework is designed to accommodate new threat types and detection categories without creating a separate system for each scenario. ## Multi-Model Verification and Operational Resilience - Multiple AI models independently analyze the same event and cross-check one another. - Disagreement is treated as an uncertainty signal that can trigger deeper analyst review. - Model diversity helps reduce bias, false positives, and missed detections. - It also provides resilience against model failures, API outages, and quality changes after model updates. - The design balances cost, processing speed, and accuracy rather than optimizing only for detection precision. ## Teaching AI the Environment’s Context - Generic LLMs initially misclassified legitimate activity because they lacked knowledge of Kakao’s infrastructure. - The system supplies structured context, including: - Host roles - Services running on each host - Accounts used for automation - Normal communication and operational patterns - This context allows the model to act more like an analyst familiar with the organization than a generic security classifier. ## Analyzing Complete Behavior Flows - Individual commands such as `curl`, `chmod`, and script execution can occur in both normal deployments and attacks. - Kakao therefore reconstructs activity at the host level, linking: - Process execution history - Network sessions - File changes - Temporal ordering - The same command can have different meanings depending on when, where, and in what sequence it occurred. - AI evaluates the complete sequence to distinguish routine operations from intrusion behavior. ## Translating Events into AI-Usable Data - Sending raw events directly to an LLM wastes tokens on irrelevant information and reduces accuracy. - Different detection tasks require different signals; statistical anomaly detection and sequence analysis cannot rely on one fixed format. - Kakao introduced: - A standardized event schema - Dynamic feature construction tailored to each detection type - This reduces token usage while improving the relevance and precision of AI analysis. ## WALT: A Self-Learning Detection Loop - Initially, analysts had to manually convert AI conclusions into new detection policies. - Kakao developed WALT, or **Whitelist-Assisted Learning and Tuning**, to automate this feedback process. - Repeatedly verified normal patterns are converted into exception policies. - Those policies filter future matching events before they reach the AI engine. - Thousands of detection policies are reportedly being generated and operated this way, allowing accuracy to improve over time. ## Cost and Performance Constraints - Sending every event to an AI model caused unsustainable costs and processing delays. - The funnel architecture addresses this by reserving expensive AI analysis for events that survive earlier filtering. - The overall system must continuously balance economic cost, response speed, detection accuracy, and reliability. Kakao’s practical recommendation is to treat AI as part of a carefully designed security pipeline—not as a replacement for rules or analysts. Effective large-scale monitoring combines deterministic filtering, contextual multi-model analysis, structured data, and a controlled feedback loop that learns from verified outcomes.

Read original(opens in new tab)
slack3 min readCurated summary

Building Slack’s Anomaly Event Response

Slack’s Anomaly Event Response (AER) is designed to close the gap between detecting suspicious activity and stopping it. By combining real-time monitoring, adaptive analytics, and automated session termination, AER can disrupt high-confidence attacks within minutes rather than hours or days. Slack presents it as a built-in security capability for Enterprise Grid customers that works without additional tools or security staff. ## Shared Responsibility for Securing Slack - Slack processes billions of daily interactions from tens of millions of weekly users. - Enterprise customers receive audit logs covering hundreds of platform actions. - Specialized anomaly logs flag activity such as: - Irregular logins - Malware uploads - Unexpected data transfers - Audit logs provide early warning but traditionally require security personnel or third-party systems to interpret and act on them. - AER provides automated response for customers that lack the resources or infrastructure to build those integrations. - Advanced customers can still combine AER with customized security controls. ## Configurable Threat Detection AER focuses on common indicators of account compromise, data exfiltration, and automated abuse: - Access from Tor exit nodes - Excessive downloading - Data scraping through non-native automation tools - Session fingerprint mismatches - Unexpected API-call volumes or patterns - Unusual user agents, including virtual or non-standard clients Organizations can choose which anomaly types should terminate sessions and which should only be logged. Notification settings are also configurable, with alerts available for organization owners and security administrators through email or Slack. ## Detection Engine - The detection engine analyzes billions of Slack events each day. - It combines rule-based heuristics with dynamic thresholds. - Thresholds are calibrated to each enterprise’s historical usage patterns. - This prevents normal high-volume activity in one organization from being treated as anomalous in another. - Adaptive thresholds help reduce false positives while allowing Slack to refine detection sensitivity over time. ## AER Architecture AER consists of three main components: - **Detection engine:** Identifies suspicious activity and creates anomaly audit payloads. - **Decision framework:** Validates detected behavior and determines whether it qualifies for automated response. - **Response orchestrator:** Carries out the configured response, including terminating user sessions. The overall flow is: 1. Suspicious user activity is analyzed. 2. An anomaly is detected. 3. The AER controller determines whether it is a supported anomaly and whether the organization’s settings require action. 4. Associated user sessions may be terminated. 5. The event is always recorded in audit logs. 6. Customer notifications are sent according to configured preferences. AER’s practical value is that it turns anomaly detection into immediate containment, helping organizations interrupt attack chains before attackers can complete data theft or compromise.

Read original(opens in new tab)