DEEP DIVE REPORT

Google SecOps에서 AI 기반 UEBA를 설계할 때 확인할 다단계 분석과 탐지 품질

SecurityDesk
2026.08.31 조회 13

Google SecOps의 사용자 및 엔티티 이상 행위 분석(UEBA)은 단순 규칙 기반 이상치 탐지를 넘어, 여러 단계로 데이터를 가공하고 위험 점수를 알림이나 복합 탐지에 연결하는 방향으로 논의되고 있다. 이 글에서는 Building AI-driven UEBA for Google SecOps에서 설명한 멀티스테이지 검색, UDM stats search, Risk Metrics, 그리고 Calibrated Risk Index(CRI) 대응 점수를 중심으로, 설계할 때 실제로 점검해야 할 지점과 현재 자료로 판단하기 어려운 부분을 정리한다.

개요

개요 인포그래픽
자료에 따르면 SecOps UEBA는 지금까지 YARA-L 규칙 엔진에 직접 의존해 왔고, 이 구조가 잠재력을 제한하는 요인으로 지적된다. 여기에 멀티스테이지 검색이 추가되면서 한 단계에서 계산한 값을 다음 단계로 전달해 추가 분석을 수행할 수 있게 된다. UDM stats search는 세 단계와 마지막 root 단계까지 지원해 데이터를 네 번에 걸쳐 계산할 수 있고, 위험도 지표는 현재 검색 데이터를 내부 테이블에 저장된 30일 창과 비교하는 방식으로 작동한다. 계산된 위험 점수는 CRI에 대응하며, 이 값을 기반으로 알림을 생성하는 규칙이나 복합 탐지를 구성할 수 있다.

이 구조가 주는 의미는 단순 기능 추가가 아니라, 분석의 표현 범위와 탐지 품질을 검토하는 기준이 달라진다는 점이다. 다단계 계산, 단계별 값 전달, 30일 기준 비교, 점수 기반 알림이라는 단위가 실제로 어떻게 작동하는지에 따라 설계 판단이 달라진다. 다만 이 글은 단일 기고글에 근거한 것이며, AI 모델의 구체적 학습 방법이나 성능 지표는 포함되지 않는다. 따라서 아래에서는 확인된 구조를 전제로 조건부 판단을 제시하고, 자료로 확인되지 않는 영역은 한계로 명시한다.

배경·현황

기존 YARA-L 기반 방식은 규칙을 정의하고 적용하는 구조에서 출발했다. 자료는 이 방식이 SecOps UEBA의 잠재력을 제한했다며, 두 가지 핵심 문제가 있다고 언급하지만 그 내용이 자료에서 구체적으로 열거되지는 않는다. 이 때문에 구조적 한계를 특정 수치나 사례로 설명하는 것은 어렵다.

이 한계를 보완하기 위한 변화의 중심에는 멀티스테이지 검색이 있다. 데이터를 수집한 뒤 그 묶음을 다음 단계로 전달해 추가 분석을 수행할 수 있고, 한 단계에서 도출한 값을 두 번째 단계에 적용하는 방식이다. 이를 통해 단순 규칙으로는 표현하기 어려웠던 분석을 다단계 파이프라인으로 설계할 수 있는 여지가 생긴다.

UDM stats search에서는 세 단계와 그 뒤의 root 단계가 지원되며, 이는 데이터에 네 번의 계산 패스가 적용된다는 것을 의미한다. 자료는 수식 라이브러리가 풍부해지면 추가 단계를 줄일 수도 있다고 설명한다. 즉, 계산의 표현력이 넓어지면 단계 수를 늘리는 대신 단계 내 수식으로 처리할 수 있는 범위가 커질 수 있다는 것이다.

위험도 지표는 현재 검색 데이터를 30일 창과 비교하는 구조를 가진다. A 모드는 하루 데이터를 30일의 과거 관점과 비교하는 방식이며, 계산된 지표는 내부 테이블에서 rolling 1년간 유지된다. 30일 창 비교와 1년 유지가 결합된 구조가 주는 운영적 의미를 자료만으로는 단정할 수는 없다.

주요 사례·변화

멀티스테이지 검색과 UDM stats search의 조합은, UEBA 설계에서 “한 단계로 끝나는 규칙”과 “여러 단계로 이어지는 계산” 사이의 경계를 변화시킨다. 자료에 따르면 의미 있는 데이터를 얻기 위해 이벤트 스트림의 범위를 넓게 유지하고 match: 블록으로 엔티티를 묶어 범위를 정렬하는 방식이 중요하다고 설명된다. 이는 다단계 분석에서 어떤 엔티티에 대해 어떤 값을 계산하는지가 명확하지 않으면, 결과의 해석과 재사용이 어려워질 수 있음을 시사한다.

위험 점수의 활용 방식도 하나의 변화 지점이다. 계산된 위험 점수가 CRI에 대응되고, 이 값을 기반으로 알림을 생성하는 규칙을 만들거나, 점수를 탐지에 반영하는 복합 탐지를 구성할 수 있다는 설명이다. 이는 점수가 단순히 참고 지표에 그치는 것이 아니라, 실제 탐지·알림 체인의 입력값으로 설계될 수 있음을 의미한다. 다만 CRI가 실제로 얼마나 정교하게 보정되는지, 점수가 탐지 품질에 어떤 수준의 영향을 주는지는 자료에서 확인되지 않는다.

자료가 직접 다루는 “AI 기반” 부분은 구체적 모델 설계나 학습 방법까지 포함하지 않는다. 멀티스테이지 계산과 위험도 지표가 결합된 구조를 중심으로, 규칙 기반 분석의 표현 범위를 확장하는 방향이 제시된다고 이해하는 것이 안전하다.

산업·기술 영향

이 구조가 주는 영향은 주로 탐지 설계의 단위가 달라진다는 점에 있다. 기존에는 규칙 하나당 어떤 이상치를 계산하는지가 중심이 되지만, 다단계 검색과 위험도 지표를 결합하면 데이터 수집, 단계별 계산, 점수 매핑, 알림 생성이라는 여러 단위로 설계를 분해할 수 있다. 각 단계에서 어떤 값이 계산되고, 그 값이 다음 단계의 어떤 조건에 전달되는지를 기록해 두면, 탐지 로직 변경이나 이상 결과 해석 시 원인 추적에 도움이 될 수 있다.

알림과 탐지의 품질을 검토할 때에도 기준이 달라진다. 위험 점수가 CRI에 대응되고 알림 규칙이나 복합 탐지에 반영되는 구조라면, 단순히 점수가 문턱값을 넘었는지가 아니라 어떤 기준 점수, 어떤 복합 조건에서 알림이 생성되는지를 함께 기록하는 것이 원인 추적을 돕는다. 이 기록 방식은 탐지 품질을 점검할 때 점수의 출처와 적용 맥락을 추적할 수 있게 해준다.

운영 관점에서는 30일 비교 창이 하나의 기준선이 된다. A 모드로 하루 데이터를 30일 과거와 비교하는 방식이라면, 반복적으로 벗어나는 엔티티나 활동이 있는지를 주기적으로 살펴보는 것이 자연스러운 점검 항목이다. 다만 어떤 분석에서는 30일 창이 충분하고 어떤 분석에서는 부족할 수 있으며, 이 판단에 필요한 수치나 기준은 자료에서 제공되지 않는다.

전망·시사점

멀티스테이지 검색과 Risk Metrics, CRI 대응 점수가 결합된 구조를 활용할 때, 먼저 점검해야 할 것은 “기존 규칙이 다루지 못했던 분석을 실제로 처리할 수 있는가”이다. 다단계 계산이나 전 단계 값을 다음 단계로 전달해야 하는 분석을 설계할 때, 멀티스테이지 검색을 사용할 수 있는 범위인지 먼저 확인하는 것이 설계의 출발점이 된다.

위험도 지표를 도입할 경우에는 A 모드의 적용 대상과 비교 기준을 점검할 필요가 있다. 자료는 의미 있는 데이터를 얻기 위해 이벤트 스트림의 범위를 넓게 유지하고, match: 블록으로 엔티티를 묶어 범위를 정렬해야 한다고 설명한다. 어떤 엔티티와 활동 범위를 대상으로 비교를 설계할지는 적용 대상 설정에서 결정될 수밖에 없다. CRI로 대응되는 위험 점수를 단순히 알림 문턱값으로만 사용할 것이 아니라, 알림 규칙이나 복합 탐지에 반영하기 전에 관련 팀과 임팩트를 확인하는 것이 바람직하다.

장기적으로는 UEBA 분석을 데이터 수집, 단계별 계산, 위험 점수 매핑, 알림 생성 단위로 분리해 설계할 수 있는 템플릿을 구성하는 방향을 검토할 수 있다. 멀티스테이지 검색과 수식 라이브러리 확대를 조합해 계산 단계를 줄이거나 재배치하는 설계 원칙을 문서화하는 것도 이 구조가 주는 가능성을 활용하는 방식이다.

다만 이 전망은 단일 기고글에서 확인된 구조를 전제로 한 것이다. AI 모델의 학습 방법과 성능 지표, YARA-L 의존의 두 가지 핵심 문제의 구체적 내용, CRI의 보정 정교함, 멀티스테이지 검색의 성능 제약이나 비용, 1년 내부 테이블이 탐지 민감도에 미치는 영향은 자료에서 확인되지 않는다. 이 부분들은 추가 검증이 필요한 영역이며, 현재 자료만으로는 단정할 수 없다.

참고자료

함께 읽으면 좋은 글

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.

댓글 (0)

댓글을 작성하려면 로그인이 필요합니다.

로그인

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!

IT 도구 서랍

→ Unix: 2025-01-15T09:30:00
→ 날짜: 1736934600

→ ASCII: ABC
→ 문자: 65 66 67

ASCII 코드표 — 클릭하면 입력란에 추가

DecHex약어설명
DecHex문자
DecHex문자

→ 유니코드: 홍길동
→ 문자: \ud64d\uae38\ub3d9