오탐도 정탐도 아닌 것: Benign Activity와 RBA 이야기

오늘은 benign activity와 RBA 개념에 대해서 이야기하려고 합니다.

오탐/정탐 이분법의 문제

보통 SOC팀이나 블루팀이 로그를 판단하는 기준은 오탐, 정탐 딱 두 개입니다. 그러다 보니 종종 애매한 경우가 생깁니다.

간단한 예를 들어보죠. 로그인 실패를 5번 이상 잡는 룰이 있다고 합시다. 실제 해커의 공격을 잡으면 정탐, 정상 사용자의 실수를 잡으면 오탐으로 판정하는 게 일반적입니다. 하지만 이건 어디까지나 탐지 결과 기반의 판정이고, 룰셋 자체를 놓고 보면 이야기가 달라집니다.

Usecase를 작성하고 운영에 들어가면, 분기나 반기마다 각 룰의 정오탐률을 계산해서 최적화 작업을 하게 됩니다. 그런데 방금 케이스는 어떨까요? 정상 사용자의 실수를 오탐으로 집계했으니 수치상으로는 "개선이 필요한 룰"이 됩니다. 하지만 룰 자체만 보면, 비정상 로그인 시도를 잡는다는 로직이 틀린 게 하나도 없어요. 룰은 시키는 대로 정확히 동작했는데 오탐률만 올라가는 겁니다. 이런 경우 손대야 할 건 룰 규칙이 아니라 화이트리스트, UEBA, 머신러닝 같은 다른 보완 장치죠.

그러면 이 판정 체계 자체를 어떻게 바로잡아야 할까요? 해외에서 쓰이기 시작한 개념이 TP-benign activity, 즉 양성 행위입니다. 정탐이긴 하나 유해하지 않은 것. 룰 규칙의 관점에서 판단하는 겁니다. 우리 룰이 잘 잡았고(TP), 다만 이게 정상 사용자의 양성 행위였다는 거죠.

이렇게 세 갈래(TP / TP-benign / FP)로 집계하면 나중에 정오탐 점수를 계산할 때 "룰 로직의 문제"와 "컨텍스트 보완의 문제"가 분리돼서, 최적화 방향을 훨씬 정확하게 잡을 수 있습니다.

RBA (Risk-Based Alerting)

benign activity 상황을 놓고 보면, 룰 메인 로직 자체는 오류가 없지만 추가 컨텍스트로 보완할 여지가 많이 남아 있습니다. 화이트리스트로 해결해도 되지만, 공격자나 APT 그룹의 본질적인 목적 기반으로 접근하자면 RBA(Risk-Based Alerting)를 언급할 수 있겠습니다.

RBA는 쉽게 말해 리스크 점수 기반 알림입니다. 알림을 이벤트 단위로 바로 쏘는 게 아니라, 모든 엔티티(유저, 호스트 등)에 리스크 점수를 누적시키는 방식이에요. 예를 들어 홍길동이라는 유저가 있습니다. 홍길동이 패스워드를 5번 틀릴 때마다 홍길동에게 30점을 부여합니다. 그리고 누적 점수가 100점을 넘을 때만 notable, 즉 알림을 생성합니다.

여기서 이런 질문이 나올 수 있습니다. "한 번에 30점이면 총 4번, 즉 20번은 틀려야 알림이 가는 거 아냐? 해커가 20번 미만으로만 시도하면 영원히 안 잡히는 거 아냐?" 여기까지 생각하셨다면 아주 훌륭하신 겁니다. 다만 그건 Usecase가 하나뿐일 때 이야기입니다.

실제로 RBA를 적용한다면 킬체인이나 MITRE ATT&CK 기반으로 여러 개의 Usecase를 만들 테고, 각 Usecase가 가리키는 risk object가 전부 같은 유저라면 이야기가 달라집니다. 해커가 홍길동 계정을 탈취하려 한다고 가정해 보죠. 패스워드 실패로 30점, 이어서 다른 수상 행위를 잡는 Usecase들이 각각 추가 점수를 얹습니다. 공격자는 계정 탈취라는 목적을 향해 후속 행동을 이어갈 수밖에 없으니, 시나리오 기반으로 Usecase를 짜고 점수를 잘 배분해 두면 단일 이벤트로는 조용해 보여도 누적으로는 반드시 드러나게 됩니다.

RBA의 장점을 정리하면 이렇습니다. 단일 이벤트 알림이 확 줄어드니 분석가의 알림 피로가 내려가고, benign activity는 점수만 쌓고 알림까지는 안 가니 자연스럽게 걸러지고, 반대로 저강도로 오래 움직이는 공격자는 누적 점수로 잡힙니다.

일반 Splunk에서 구현해보기

Splunk Enterprise Security에는 RBA 모듈이 내장돼 있지만 워낙 비싸다 보니, 일반 Splunk나 타 플랫폼(Sentinel, ELK 등)에서도 같은 개념을 적용할 수 있는 예시를 들겠습니다. 핵심 구조는 두 층입니다. Usecase 룰은 알림을 쏘지 않고 리스크 이벤트만 쌓고, 별도의 집계 룰이 누적 점수를 보고 알림 여부를 판단합니다.

[Usecase 탐지룰] — 로그인 실패 5회 이상을 잡되, 알림 대신 리스크 인덱스에 점수를 적재합니다.

index=wineventlog EventCode=4625
| bin _time span=10m
| stats count as fail_count values(src) as src by _time, user
| where fail_count >= 5
| eval risk_object=user,
       risk_object_type="user",
       risk_score=30,
       risk_rule="AUTH-001_excessive_login_failure",
       risk_message="10분 내 로그인 실패 ".fail_count."회 (src: ".mvjoin(src,", ").")",
       mitre_technique="T1110"
| fields _time, risk_object, risk_object_type, risk_score, risk_rule, risk_message, mitre_technique
| collect index=risk_index

포인트는 마지막 collect입니다. 이 룰은 스케줄만 돌 뿐 누구한테도 알림을 보내지 않고, risk_index에 리스크 이벤트를 남기는 것으로 끝납니다. 다른 Usecase들(수상한 프로세스 실행, 비정상 시간대 접속, 신규 국가 로그인 등)도 전부 같은 포맷으로 이 인덱스에 쌓으면 됩니다. risk_rule에 룰 ID를, mitre_technique에 ATT&CK 번호를 박아두면 나중에 집계할 때 공격 흐름이 그대로 보입니다.

[RBA 집계룰] — 24시간 누적 점수가 임계치를 넘는 엔티티만 알림으로 올립니다.

index=risk_index earliest=-24h
| stats sum(risk_score) as total_score,
        dc(risk_rule) as distinct_rules,
        values(risk_rule) as triggered_rules,
        values(mitre_technique) as techniques,
        values(risk_message) as messages,
        latest(_time) as last_seen
        by risk_object, risk_object_type
| where total_score >= 100 OR distinct_rules >= 3
| eval last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| sort - total_score

조건을 total_score >= 100 OR distinct_rules >= 3으로 건 게 핵심입니다. 점수 총합뿐 아니라 서로 다른 룰 몇 개에 걸렸는지도 봅니다. 저강도라도 여러 단계에 걸쳐 움직이는 공격자는 distinct_rules 쪽에 걸리게 되는 거죠. 이 집계룰만 스케줄 알림으로 걸어두면, 분석가는 개별 이벤트가 아니라 "지금 점수가 쌓이고 있는 엔티티" 목록을 보게 됩니다.

Sentinel(KQL)에서는

Sentinel에는 UEBA 기반 엔티티 스코어링이 내장돼 있지만, 여기서는 같은 2층 구조를 KQL로 직접 짜는 예시를 보겠습니다. Sentinel엔 Splunk의 collect 같은 게 없으니, 각 Usecase를 저장 함수(saved function)로 만들어 두고 집계 쿼리에서 union으로 모으는 패턴이 간단합니다.

[Usecase 탐지룰] — 함수 AUTH001_LoginFailures로 저장:

SecurityEvent
| where EventID == 4625
| summarize fail_count = count(), srcs = make_set(IpAddress, 10)
    by bin(TimeGenerated, 10m), TargetUserName
| where fail_count >= 5
| project TimeGenerated,
          risk_object = TargetUserName,
          risk_object_type = "user",
          risk_score = 30,
          risk_rule = "AUTH-001_excessive_login_failure",
          mitre_technique = "T1110"

[RBA 집계룰] — 분석 룰(Analytics rule)로 스케줄:

union
    AUTH001_LoginFailures(),
    PROC002_SuspiciousProcess(),
    GEO003_NewCountryLogin()
| where TimeGenerated > ago(24h)
| summarize total_score = sum(risk_score),
            distinct_rules = dcount(risk_rule),
            triggered_rules = make_set(risk_rule),
            techniques = make_set(mitre_technique)
    by risk_object, risk_object_type
| where total_score >= 100 or distinct_rules >= 3
| order by total_score desc

집계 쿼리 하나만 Analytics rule로 등록해서 인시던트를 만들게 하면, Usecase 함수들은 조용히 점수 공급만 하는 구조가 됩니다. 리스크 이벤트를 실제 테이블로 적재하고 싶다면 Logic App이나 DCR 기반 커스텀 테이블로 빼는 방법도 있는데, 소규모라면 union 패턴으로 충분합니다.

ELK에서는

Elastic도 8.x부터 Entity Risk Scoring이 내장되기 시작했지만, 개념 이해용으로 같은 구조를 ES|QL로 짜보면 이렇습니다. Usecase 룰은 탐지 룰의 인덱스 액션(또는 transform)으로 risk-events 인덱스에 결과를 적재한다고 가정합니다.

[Usecase 탐지룰]

FROM logs-windows*
| WHERE event.code == "4625"
| STATS fail_count = COUNT(*), srcs = VALUES(source.ip)
    BY user.name, bucket = BUCKET(@timestamp, 10 minutes)
| WHERE fail_count >= 5
| EVAL risk_object = user.name,
       risk_object_type = "user",
       risk_score = 30,
       risk_rule = "AUTH-001_excessive_login_failure",
       mitre_technique = "T1110"

[RBA 집계룰]

FROM risk-events
| WHERE @timestamp > NOW() - 24 hours
| STATS total_score = SUM(risk_score),
        distinct_rules = COUNT_DISTINCT(risk_rule),
        triggered_rules = VALUES(risk_rule),
        techniques = VALUES(mitre_technique)
    BY risk_object, risk_object_type
| WHERE total_score >= 100 OR distinct_rules >= 3
| SORT total_score DESC

플랫폼이 달라도 뼈대는 똑같다는 게 보이실 겁니다. 점수를 쌓는 층과 판단하는 층을 분리한다, 이거 하나예요.

운영 팁

운영하면서 조정할 부분은 세 가지 정도입니다. Usecase별 점수 배분(치명적인 행위일수록 높게), 집계 윈도우(24시간이 기본이지만 저속 공격 대비로 7일 윈도우를 하나 더 두는 것도 방법), 그리고 임계치입니다. 처음부터 완벽하게 잡으려 하기보다 일단 굴리면서 notable 수를 보고 맞추는 게 현실적입니다.

마무리

정리하면 이렇습니다. 오탐/정탐 이분법에 TP-benign을 추가하면 룰 로직의 문제와 컨텍스트의 문제를 분리해서 볼 수 있고, RBA를 얹으면 benign activity는 조용히 점수만 쌓다 사라지고 진짜 공격 흐름은 누적으로 드러납니다.

사실 오늘 다룬 건 맛보기에 가깝습니다. 점수 설계를 어떻게 하는지, 킬체인 단계별로 Usecase를 어떻게 배치하는지, 점수 감쇠(decay)나 화이트리스트와의 조합은 어떻게 가져가는지 등 실전에서 부딪히는 이야기가 훨씬 많거든요. 다음에는 Threat Detection Panorama와 RBA, 그리고 RBA의 핵심인 Finding-Based Detection을 제대로 파는 상세 포스트로 찾아오겠습니다. 오늘은 여기까지 하겠습니다.