From Detection to Decision, Polestar SIEM's AI SOC

From Detection to Judgment: The Next Step of AI SOC Envisioned by Polestar SIEM

The most difficult problem in security monitoring is neither collecting logs nor creating detection rules. In the end, it is determining "Is this a real threat?" among numerous alerts. Polestar SIEM is preparing for the next step beyond the traditional detection-centered structure: an AI SOC that evaluates multiple security contexts to judge true/false positives and prioritize responses.

The Bottleneck of Security Monitoring Lies After 'Detection'

Traditional SIEMs collect and normalize logs, then detect anomalies through rules and correlation analysis. This structure remains crucial. However, the tighter the detection conditions are set, the larger another problem becomes in actual operations: False Positives and Alert Fatigue.

Lowering thresholds helps find more potential attack candidates but also increases false positives. Raising them reduces the operational burden but increases the risk of missed detections. Ultimately, the quality of security monitoring is determined more by "which of the detected signals should be investigated first?" rather than "how many detections were made?"

From Detection-Centered SIEM to Judgment-Centered AI SOC

<Figure 1> Detection → Context → Decision → Response

Recently, SIEM technology has also been moving away from analyzing a single event in isolation. It groups multiple detection results by user, host, asset, and time axis, and evaluates risks by considering asset importance, Threat Intelligence, user behavior, and past detection history together.

Splunk's Risk-Based Alerting (RBA) also takes an approach of accumulating individual detections as risk events and linking multiple signals by Entity to find events highly worthy of investigation. At the ISEC 2025 presentation, combining simple rules and actively utilizing context such as assets, accounts, and TI was introduced as a key method to reduce false positives.

Polestar SIEM Already Has the Ingredients for Judgment

Polestar SIEM currently handles not only Rule, Sigma, and CEP-based detection, but also UEBA, CTI, MITRE ATT&CK, asset importance, false positive history per rule, Incidents, and SOAR within a single platform. The fact that each function already exists is of great significance. Instead of forcing a new AI to infer everything from scratch, verified security signals can be normalized into a single judgment context.

Selene: Context-Aware SOC Decision Engine

<Figure 2> Selene Risk Engine and Decision Engine

The core of Selene as we envision it is separating the 'Risk Engine' and the 'Decision Engine'. The Risk Engine normalizes Rule, UEBA, CTI, Asset, MITRE, and past history into Risk Evidence, and builds contexts by Entity (such as user, host, asset) and time-window units. The Decision Engine takes this context as input and returns structured results regarding actual threat probability, false positive probability, risk level, necessity for incident escalation, and response requirement.

What is important here is not just a single Risk Score. Confidence must be provided with each judgment. For example, even within the same classification, 'Malicious 97%' and 'Malicious 58%' must have different operational policies. While high-confidence results can be prioritized, uncertain results should safely be sent to security analysts for additional review.

What Matters More Than a Single Alert is 'Connected Evidence'

<Figure 3> Changing Judgments When Multiple Weak Signals Connect

For example, it is difficult to conclude an attack based solely on PowerShell execution. This is because it can commonly appear in normal management scripts or development tasks. However, if a login from an unusual location, PowerShell initiated from Word, Credential Access behavior, and connection to an external IP registered in CTI occur in a short sequence, the judgment changes.

Instead of viewing each event solely as a separate alert, Selene aims to connect related Risk Evidence by Entity and time axis to construct a single context. This structure is easier to manage than simply making rules complex, and has the advantage of allowing the interpretation of complex situations at a higher judgment layer while keeping the rules themselves clean.

Generative AI and Judgment AI Have Different Roles

When thinking of an AI SOC, people often picture passing logs to an LLM and asking it to 'analyze this attack'. The structure Polestar SIEM aims for separates judgment from explanation.

Repetitive core judgments, such as true/false positives and risk levels, are handled by a small, dedicated Decision Model, while the sLLM explains the results and reasoning in sentences that are easy for security analysts to understand. By separating roles in this way, there is no need to call a large generative model for every alert, making it easier to standardize judgment results and connect them to policies and automation.

Furthermore, in environments where internet connectivity is restricted, such as financial and public institutions, relying on external AI APIs is difficult. Therefore, the core Decision function of Selene must be able to operate offline in a single-server on-premise environment, and a security sLLM is best configured optionally depending on the environment.

AI Does Not Respond Directly: Separation of Decision and Policy

Even if the Decision Model returns a high threat probability, it must not immediately isolate endpoints or block accounts. An explicit Policy Engine is required between AI's judgment and the actual response. For instance, you can configure the system to automatically generate an incident only when the malicious confidence is extremely high, it involves a critical asset, and there is sufficient CTI reliability.

SOAR follows the same principle. Selene 'recommends' responses, while the actual automatic execution is decided by legacy approval/protection policies and the customer's operational policies. This way, the benefits of AI can be utilized while maintaining control over high-risk automation.

The Competitiveness of AI SOC Ultimately Comes from Data

<Figure 4> Structure Where Analyst Feedback Leads to the SOC Judgment Dataset

Adopting a good model alone does not create good security monitoring. There must be a continuous accumulation of data regarding which alerts were judged as true positives, which were false positives, whether they led to actual incidents, and which responses were effective.

Polestar SIEM already possesses alert FALSE_POSITIVE processing, FP statistics per rule, justification results, and execution history of Incidents and SOAR. Selene aims to accumulate this data as a SOC Judgment Dataset rather than letting it end as mere operational history.

However, immediately applying feedback generated in customer environments to Online Training can be risky. This is because analyst misjudgments or data biases could be trained directly into the model. Therefore, a direction where operational data is first accumulated and verified, and models that have gone through Offline Training and evaluation are distributed as signed packages, is more suitable for closed-network operations.

Better Decisions, Not More Alerts

For a long time, SIEM has developed in a direction of collecting more logs and detecting more attacks. However, now that data and detection rules have become sufficiently abundant, we believe the next competitive edge lies in how accurately we can judge which of the numerous detected signals should be investigated first.

The direction of the AI SOC prepared by Polestar SIEM is simple. Detection is performed by the existing engine, Selene makes judgments by connecting multiple security contexts, and when necessary, the Security sLLM explains and SOAR responds.

Rules detect, and Selene judges. This is the direction in which Polestar SIEM aims to evolve from a 'detection-centered SIEM' to a 'judgment-centered AI SOC'.

References

• Splunk Enterprise Security - Risk-Based Alerting Concept and Operational Methods

• Polestar SIEM Internal Implementation: Rule/CEP, UEBA, CTI, MITRE ATT&CK, Rule Effectiveness, Incident, SOAR

Author: YW Jung | Information Security Team