탐지에서 판단으로, Polestar SIEM의 AI SOC

탐지에서 판단으로 Polestar SIEM이 그리는 AI SOC의 다음 단계

보안관제에서 가장 어려운 문제는 로그를 수집하는 것도, 탐지 룰을 만드는 것도 아닙니다. 결국 수많은 경보 가운데 '이것이 실제 위협인가?'를 판단하는 일입니다. Polestar SIEM은 기존의 탐지 중심 구조에서 한 단계 더 나아가, 여러 보안 컨텍스트를 종합해 정·오탐과 대응 우선순위를 판단하는 AI SOC를 준비하고 있습니다.

보안관제의 병목은 '탐지' 이후에 있다

전통적인 SIEM은 로그를 수집하고 정규화한 뒤 룰과 상관분석을 통해 이상 징후를 탐지합니다. 이 구조는 여전히 중요합니다. 다만 탐지 조건을 촘촘하게 만들수록 운영 현장에서는 또 다른 문제가 커집니다. 바로 오탐(False Positive)과 경보 피로(Alert Fatigue)입니다.

임계치를 낮추면 더 많은 공격 후보를 찾을 수 있지만 오탐도 증가하고, 높이면 운영 부담은 줄어도 미탐 위험이 커집니다. 결국 관제 품질을 결정하는 것은 '얼마나 많이 탐지했는가'보다 '탐지된 신호 중 무엇을 먼저 조사해야 하는가'에 가깝습니다.

탐지 중심 SIEM에서 판단 중심 AI SOC로

<그림 1> Detection → Context → Decision → Response

최근 SIEM 기술도 하나의 이벤트를 단독으로 보는 방식에서 벗어나고 있습니다. 여러 탐지 결과를 사용자·호스트·자산과 시간축으로 묶고, 자산 중요도와 Threat Intelligence, 사용자 행위, 과거 탐지 이력 등을 함께 고려해 위험을 평가합니다.

Splunk의 Risk-Based Alerting(RBA) 역시 개별 탐지를 위험 이벤트로 축적하고, 여러 신호를 Entity 단위로 연결해 조사 가치가 높은 이벤트를 찾는 접근입니다. ISEC 2025 발표에서도 단순 룰을 조합하고 자산·계정·TI와 같은 Context를 적극 활용하는 것이 오탐을 줄이는 핵심 방법으로 소개됐습니다.

Polestar SIEM에는 이미 판단을 위한 재료가 있다

Polestar SIEM은 현재 Rule·Sigma·CEP 기반 탐지뿐 아니라 UEBA, CTI, MITRE ATT&CK, 자산 중요도, 룰별 오탐 이력, Incident와 SOAR를 하나의 플랫폼에서 다룹니다. 각 기능이 이미 존재한다는 것은 중요한 의미가 있습니다. 새로운 AI가 모든 것을 처음부터 추론하도록 만드는 대신, 검증된 보안 신호들을 하나의 판단 Context로 정규화할 수 있기 때문입니다.

Selene: Context-Aware SOC Decision Engine

<그림 2> Selene Risk Engine과 Decision Engine

우리가 구상하는 Selene의 핵심은 'Risk Engine'과 'Decision Engine'을 분리하는 것입니다. Risk Engine은 Rule·UEBA·CTI·Asset·MITRE·과거 이력을 Risk Evidence로 정규화하고, 사용자·호스트·자산 같은 Entity와 시간창 단위로 Context를 만듭니다. Decision Engine은 이 Context를 입력받아 실제 위협 가능성, 오탐 가능성, 위험도, Incident 승격 필요성, 대응 필요성을 구조화된 결과로 반환합니다.

여기서 중요한 것은 단순한 Risk Score 한 개가 아닙니다. 판단마다 Confidence를 함께 제공해야 합니다. 예를 들어 'Malicious 97%'와 'Malicious 58%'는 같은 분류라도 운영 정책이 달라야 합니다. 고신뢰도 결과는 우선순위를 높일 수 있지만, 불확실한 결과는 관제요원의 추가 검토로 보내는 것이 안전합니다.

하나의 경보보다 중요한 것은 '연결된 근거'

<그림 3> 여러 약한 신호가 연결될 때 달라지는 판단

예를 들어 PowerShell 실행만으로 공격을 단정하기는 어렵습니다. 정상 관리 스크립트나 개발 작업에서도 흔히 나타날 수 있기 때문입니다. 하지만 평소와 다른 위치에서의 로그인, Word에서 시작된 PowerShell, Credential Access 행위, 그리고 CTI에 등록된 외부 IP 접속이 짧은 시간 안에 이어진다면 판단은 달라집니다.

Selene은 각각의 이벤트를 별도의 Alert로만 보는 대신, 관련 Risk Evidence를 Entity와 시간축으로 연결해 하나의 Context로 구성하는 것을 목표로 합니다. 이 구조는 단순히 룰을 복잡하게 만드는 것보다 관리하기 쉽고, 룰 자체는 명확하게 유지하면서 상위 판단 계층에서 복합적인 상황을 해석할 수 있다는 장점이 있습니다.

생성형 AI와 판단 AI는 역할이 다르다

AI SOC라고 하면 흔히 LLM에게 로그를 전달하고 '이 공격을 분석해줘'라고 요청하는 모습을 떠올립니다. Polestar SIEM이 지향하는 구조는 판단과 설명을 분리하는 것입니다.

정·오탐과 위험도처럼 반복적으로 수행되는 핵심 판단은 작은 전용 Decision Model이 담당하고, sLLM은 그 결과와 근거를 관제요원이 이해하기 쉬운 문장으로 설명합니다. 이렇게 역할을 분리하면 대형 생성형 모델을 모든 Alert마다 호출할 필요가 없고, 판단 결과를 정형화해 정책과 자동화에 연결하기도 쉬워집니다.

또한 금융·공공기관처럼 인터넷 연결이 제한된 환경에서는 외부 AI API에 의존하기 어렵습니다. 따라서 Selene의 핵심 Decision 기능은 단일 서버 온프레미스 환경에서 오프라인으로 동작할 수 있어야 하며, Security sLLM은 환경에 따라 선택적으로 구성하는 방향이 적합합니다.

AI가 직접 대응하지 않는다: Decision과 Policy의 분리

Decision Model이 높은 위협 확률을 반환했다고 해서 곧바로 Endpoint를 격리하거나 계정을 차단해서는 안 됩니다. AI의 판단과 실제 대응 사이에는 명시적인 Policy Engine이 필요합니다. 예를 들어 Malicious confidence가 매우 높고, 중요 자산이며, CTI 신뢰도까지 충분한 경우에만 Incident를 자동 생성하도록 할 수 있습니다.

SOAR 역시 같은 원칙을 따릅니다. Selene은 대응을 '추천'하고, 실제 자동 실행 여부는 기존 승인·보호 정책과 고객사 운영 정책이 결정합니다. 이렇게 해야 AI의 장점을 활용하면서도 고위험 자동화의 통제 가능성을 유지할 수 있습니다

AI SOC의 경쟁력은 결국 데이터에서 나온다

<그림 4> Analyst Feedback이 SOC Judgment Dataset으로 이어지는 구조

좋은 모델을 도입하는 것만으로 좋은 관제가 만들어지지는 않습니다. 어떤 경보를 정탐으로 판단했는지, 어떤 경보가 오탐이었는지, 실제 Incident로 이어졌는지, 어떤 대응이 효과적이었는지가 지속적으로 축적돼야 합니다.

Polestar SIEM은 이미 Alert의 FALSE_POSITIVE 처리, 룰별 FP 통계, 소명 결과, Incident와 SOAR 실행 이력을 가지고 있습니다. Selene은 이 데이터를 단순 운영 이력으로 끝내지 않고 SOC Judgment Dataset으로 축적하는 것을 목표로 합니다.

다만 고객 환경에서 발생한 피드백을 즉시 Online Training에 반영하는 것은 위험할 수 있습니다. 관제요원의 오판이나 데이터 편향이 그대로 모델에 학습될 수 있기 때문입니다. 따라서 운영 데이터는 먼저 축적·검증하고, Offline Training과 평가를 거친 모델을 서명된 패키지 형태로 배포하는 방향이 폐쇄망 운영에도 더 적합합니다.

더 많은 Alert가 아니라, 더 나은 Decision

SIEM은 오랫동안 더 많은 로그를 수집하고 더 많은 공격을 탐지하는 방향으로 발전해 왔습니다. 하지만 데이터와 탐지 룰이 충분히 많아진 지금, 다음 경쟁력은 탐지된 수많은 신호 중 무엇을 먼저 조사해야 하는지 얼마나 정확하게 판단할 수 있는가에 있다고 생각합니다.

Polestar SIEM이 준비하는 AI SOC의 방향은 단순합니다. 탐지는 기존 엔진이 수행하고, 여러 보안 Context를 연결해 Selene이 판단하며, 필요한 경우 Security sLLM이 설명하고 SOAR가 대응합니다.

Rule이 탐지하고, Selene이 판단한다. 이것이 Polestar SIEM이 '탐지 중심 SIEM'에서 '판단 중심 AI SOC'로 진화하고자 하는 방향입니다.

참고

• Splunk Enterprise Security - Risk-Based Alerting 개념 및 운영 방식

• Polestar SIEM 내부 구현: Rule/CEP, UEBA, CTI, MITRE ATT&CK, Rule Effectiveness, Incident, SOAR

작성자 : YW Jung | 정보보안팀