Insider Threat Detection에 대한 고찰 - 탐지 메트릭스와 커버리지

소개

안녕하세요. TeamH4C의 D4C 그룹 faper입니다.

오늘 제가 공유드릴 인사이트는 바로 내부자 위협 탐지 방법론인데요. 주제를 선정하게 된 이유는 한국에서 이런 내부자 위협 탐지/대응에 대한 고민이나 정형화된 방식에 대해 이야기하는 기술 블로그가 딱히 없는 것 같아서 제 경험에 기반한 러닝 쉐어를 하고 싶었습니다. 저는 침해사고분석 및 대응 업무로 첫 커리어를 시작해 여러 도메인을 거쳤고, 현재는 Detection Engineering 및 보안 이벤트 분석 업무를 담당하고 있습니다. 미리 밝혀두자면 본문의 모든 시나리오와 수치, 예시는 특정 조직의 실제 구현과 무관하게 일반화한 내용입니다.

이런 내부자 위협에 대한 탐지 시나리오가 공개되지 않는 이유는 간단합니다. 내부자 위협을 어떻게 탐지하는지 구체적인 시나리오를 공개하는 것 자체가 리스크이며, 기본적으로 폐쇄적인 환경이라면 솔루션단에서 원천 차단되는 구조기 때문입니다. 마치 카카오톡이나 텔레그램 등을 회사 컴퓨터에서 못 깔게 하는 것처럼, cyber hygiene을 엄격하게 강화하는 방식이 대부분입니다.

하지만 시대가 변했습니다. AI를 업무 환경에 도입하고 싶어하는 수준을 넘어서, 쓰지 않으면 생산성을 따라가지 못하는 단계까지 왔습니다. 더 이상 단순하게 "이 프로그램은 위험하니까 못 쓰게 막는다" 수준으로 커버할 수는 없습니다. 무엇이 위험하고, 무엇을 통제해야 하는지, 그리고 그 수준과 범위를 정하기 위한 커버리지를 어떻게 탐지 매트릭스로 구성할 것인지에 대한 저의 생각을 공유드리면서, 내부자 위협 탐지를 설계하는 전국의 보안팀들에게 좋은 러닝쉐어가 되었으면 합니다.

1. 세대별 DLP 프레임

세대	핵심 질문	탐지 기준	통제 지점	대표 기술	한계
1세대 (Pattern)	"이 파일에 민감한 패턴이 있는가?"	정규식, 키워드, 주민번호/카드번호 포맷	네트워크 경계, 메일 게이트웨이	패턴 매칭, 프록시	오탐 폭발, 암호화/압축/캡처 우회에 무력
2세대 (Content)	"이 파일이 우리 회사 데이터인가?"	핑거프린팅, 분류 라벨, 문서 지문	엔드포인트 에이전트, USB/프린터	EDM/IDM, 파일 태깅	라벨은 사람이 붙임 → 라벨 없는 데이터는 투명인간
3세대 (Context)	"누가, 어디로, 왜 보내는가?"	사용자 행위 기준선, 채널 위험도	SaaS/클라우드(CASB), 협업툴	UEBA, CASB, 리스크 스코어링	행위는 보이지만 그 데이터가 어디서 왔는지는 모름 → "이상하긴 한데 뭐가 나갔는지" 답을 못 함
4세대 (Lineage)	"이 데이터는 어디서 태어나 어떤 변형을 거쳐 여기까지 왔는가?"	원천 추적(data lineage) + 변환 이력 + 행위 컨텍스트	데이터가 생성/조회되는 지점(DB 쿼리 게이트웨이, 데이터 웨어하우스, Git/Wiki/드라이브 API, 사내 서비스 백엔드). 경계(네트워크)나 단말(엔드포인트)이 아니라 원천 자체에 계측을 심음	원천 태깅(쿼리 결과, 문서에 출처 식별자 부여), 파생 추적(복사, 압축, 캡처 후에도 태그 상속), 콘텐츠 지문의 부분 매칭(프롬프트, 채팅 페이로드 안에서 원천 조각 식별), LLM 프록시/AI 게이트웨이, 그래프 기반 전파 경로 분석(원천 → 사용자 → 채널)	계측 비용이 큼(모든 원천에 태깅 파이프라인 필요), 태그가 상속되지 않는 채널(개인 폰 촬영, 구두 전달)은 여전히 사각

간단한 이야기부터 시작해 보겠습니다. 내부 데이터를 외부로 반출하는 걸 막고 싶습니다. 내부 데이터란 무엇이고 외부는 어디까지고, 반출의 정의는 무엇인가요? 그리고 막는다고 하셨는데 어떻게 Block할 수 있을까요?

1세대 DLP는 "패턴" 기반입니다. 우리 GW에서 나가는 모든 트래픽을 복호화하고, 거기서 주민등록번호, 카드번호, 계좌번호 정규식을 돌립니다. 매칭되면 차단하거나 알림을 발생시킵니다. 직관적이고, 컴플라이언스 감사 대응 관점에서는 지금도 유효한 접근입니다. 문제는 세 가지입니다. 첫째, 오탐이 폭발합니다. 13자리 숫자는 세상에 널려 있고, 테스트 데이터와 실제 고객 데이터를 정규식은 구분하지 못합니다. 둘째, 우회가 너무 쉽습니다. 암호화 압축 한 번이면 패턴 매칭은 무력화되고, 화면을 캡처하면 텍스트 자체가 사라집니다. 셋째, 패턴이 없는 민감 데이터가 있습니다. 소스코드, M&A 검토 문서, 신사업 전략 자료에는 정규식으로 잡을 "포맷"이 존재하지 않습니다.

그래서 나온 것이 2세대, "내용" 기반입니다. 질문이 "패턴이 있는가"에서 "이것이 우리 회사 데이터인가"로 바뀝니다. 민감 문서의 지문(EDM/IDM)을 떠서 유사도를 비교하고, 문서에 기밀 등급 라벨을 붙여 라벨 기준으로 통제합니다. 진보한 방식이지만 치명적인 전제가 있습니다. 라벨은 사람이 붙인다는 것입니다. 라벨링되지 않은 데이터는 시스템 입장에서 투명인간이고, 현실의 조직에서 모든 문서에 라벨이 정확히 붙어 있는 경우는 없습니다. 또한 원본에서 표 하나를 복사해 새 문서를 만들면 지문이 깨지고, 파생본은 통제 밖으로 빠져나갑니다.

3세대는 관점을 데이터에서 사람으로 옮깁니다. UEBA가 대표적입니다. 개인 및 동료그룹 기준선을 만들고 "평소와 다른 행동"을 잡습니다. 새벽 3시에 평소의 50배 데이터를 개인 클라우드에 올리는 행위는 내용을 몰라도 이상합니다. 실제로 3세대에 와서 탐지 커버리지는 크게 넓어졌습니다. 하지만 반대편에 구멍이 생깁니다. 행위는 보이는데 그 데이터가 무엇인지, 어디서 왔는지 모릅니다. 인시던트가 터지면 경영진의 첫 질문은 늘 같습니다. "그래서 뭐가 나간 겁니까?" 3세대 스택으로는 "대량 업로드가 있었던 것은 확실한데, 내용물은 특정할 수 없습니다"라고 답해야 하는 순간이 옵니다. 유출 규모 산정, 법적 신고 의무 판단, 피해 고객 통지까지 전부 "무엇이 나갔는가"에 달려 있는데 말이죠.

그래서 제가 이 글에서 제안하는 프레임이 4세대, "계보(Lineage)" 기반입니다. 핵심 아이디어는 통제 지점을 경계(네트워크)나 단말(엔드포인트)에서 데이터가 태어나는 원천으로 옮기는 것입니다. DB 쿼리 결과, Git 레포, 사내 위키 문서가 조회되는 순간 출처 식별자를 부여하고, 그 데이터가 복사, 압축, 변환되어도 태그가 상속되도록 계측합니다. 그러면 3세대가 답하지 못했던 "나간 것이 무엇인가"라는 질문에 원천 키로 답할 수 있게 됩니다.

AI 시대에 이 전환은 선택이 아니라 필수에 가깝다고 생각합니다. LLM 프롬프트에 들어가는 데이터는 "파일"이 아니라 조각이기 때문입니다. 고객 테이블에서 조회한 결과 20행을 복사해 프롬프트에 붙여넣는 행위는, 파일 단위로 세상을 보는 1~2세대 DLP에는 아예 보이지 않고, 3세대에는 "브라우저에 뭔가 입력했다" 수준으로만 보이게 됩니다. 원천 조각의 부분 매칭(프롬프트 페이로드 안에서 원천 지문 조각을 식별)이 가능해야 비로소 이 채널이 탐지 범위에 들어옵니다.

2. 내부자 위협 탐지 매트릭스 (4세대 DLP 기준)

2-1. 축 정의

행은 위협 시나리오, 열은 데이터의 생애주기 4단계 + 행위자 컨텍스트입니다. 각 셀은 "어떤 신호를, 어떤 로그에서, 얼마나 신뢰할 수 있게" 잡을 수 있는지를 적습니다.

축	정의	주요 데이터 소스
Origin (원천)	데이터가 처음 접근/생성된 지점	DB 감사로그, Git/Wiki/드라이브 접근 로그, API 게이트웨이, DW 쿼리 이력
Transform (변환)	원본의 형태를 바꾸는 행위	엔드포인트 텔레메트리(파일 생성/이름변경/압축/암호화), 클립보드 이벤트, 스크린샷 API 호출, 인쇄 스풀
Movement (이동)	데이터가 통제 경계를 넘는 경로	프록시/SWG, 메일 게이트웨이, 협업툴 공유 이벤트, USB/블루투스, 개인 클라우드 업로드, LLM 프록시
Destination (목적지)	최종 도착지의 성격	외부 도메인 평판, 개인 계정 판별, 경쟁사/미승인 SaaS 목록, 공개 저장소
Actor (행위자)	사람 자체의 리스크 컨텍스트	HR 이벤트(퇴직 통보, 평가, 조직개편), 권한 변경 이력, 근무시간/위치 기준선

2-2. 매트릭스 본체

위협 시나리오	Origin	Transform	Movement	Destination	Actor	원천 추적 연결 키
S1. 퇴사 예정자 대량 반출	평소 접근하지 않던 폴더/저장소 열람, 30일 기준선 대비 조회량 급증	대량 압축(zip/7z), 암호화 압축, 파일명 일괄 변경	개인 클라우드/웹메일 업로드, USB 마운트	개인 계정 도메인, 미승인 저장소	퇴직 통보 D-30 ~ D+7 윈도우, 평가 결과 통보 직후	파일 해시 + 원천 경로 태그 → 압축본 내부 해시 매칭
S2. 개발자 소스코드 유출	담당 외 레포 clone, 전체 org clone, 태그/브랜치 일괄 fetch	.git 삭제 후 재패키징, 코드를 텍스트로 복사	개인 GitHub push, Gist, 페이스트빈, 메신저 파일 전송	공개 저장소, 개인 계정	프로젝트 이관 직후, 담당 업무 변경 시점	레포 식별자 + 커밋 해시 → 외부 저장소 코드 지문
S3. AI 도구 입력 유출	고객 데이터/소스코드 조회 직후 LLM 세션 시작	클립보드 복사 → 브라우저/IDE 붙여넣기, 파일 첨부	미승인 LLM 도메인, 승인 LLM이지만 개인 계정, 로컬 모델 서빙 포트	외부 LLM 제공자, 학습 옵트아웃 미설정 계정	업무 효율 압박, 신규 입사자(정책 미숙지)	원천 쿼리 결과 지문 → 프롬프트 페이로드 부분 매칭
S4. 권한 오남용/과잉 조회	업무 무관 고객 조회(유명인, 지인), 시간당 조회 건수 이상, 전체 테이블 SELECT	조회 결과 화면 캡처, 엑셀 내보내기	반출 없음(열람 자체가 사건) 또는 개인 메신저 캡처 전송	개인 메신저	상담/운영 직군, 최근 권한 확장	조회 대상 식별자 + 조회자 → 반복성/패턴
S5. 협업툴 외부 공유	민감 라벨 문서 또는 원천이 DB/레포인 문서	링크 권한 "링크가 있는 모든 사용자"로 변경, 외부 게스트 초대	공유 이벤트 자체가 이동	외부 도메인 게스트, 개인 이메일	협력사 협업 중인 사용자	문서 ID → 원천 데이터 태그 상속 여부
S6. 화면/물리 채널	민감 화면 체류 시간 이상, 페이지네이션 빠른 순회	스크린샷 API, 화면 녹화, 인쇄	인쇄물 반출, 개인 폰 촬영(탐지 불가 영역)	물리	재택/외부 근무 중	화면에 렌더된 원천 식별자 워터마크
S7. 느린 유출 (Low & Slow)	매일 소량, 기준선 이하로 유지되는 조회	소량 파일 반복 생성	매일 소량 메일 첨부, 채팅 파일	동일 외부 수신자 반복	장기 근속, 권한 넓음	원천 태그의 누적 합계(일별 → 주별 → 분기별 롤업)
S8. 공모/대리 반출	본인 권한 없는 데이터를 동료가 대신 조회	동료 → 본인 내부 전송 후 반출	내부 메신저/드라이브 경유 후 외부	외부	두 행위자의 관계(같은 팀 아님, 최근 소통 급증)	원천 태그가 사용자 경계를 넘어 전파되는 경로 그래프

여기 있는 위협 시나리오는 모두 흔하게 생각 할 수 있는 반출 시나리오입니다. 어떤가요? 조직에서 가능한 모든 유출 시나리오가 여기에 매핑될 수 있을까요?

2-3. 리스크 스코어링 (셀을 합치는 법)

매트릭스의 힘은 셀 하나가 아니라 원천 키로 셀들이 이어질 때 나옵니다. 제안하는 식은 다음과 같습니다.

Risk = Origin_Sensitivity × Transform_Suspicion × Channel_Risk × Actor_Context

요소	0.5	1.0	2.0	3.0
Origin_Sensitivity	공개 자료	내부 일반	고객 PII / 소스코드	규제 데이터(금융거래, 인증정보)
Transform_Suspicion	변환 없음	단순 복사	압축/이름 변경	암호화 압축, 캡처, 형식 변환
Channel_Risk	승인 채널 + 회사 계정	승인 채널 + 개인 계정	미승인 채널	탐지 회피 채널(개인 핫스팟, 로컬 LLM 등)
Actor_Context	기준선 내	소폭 이탈	HR 이벤트 윈도우	HR 이벤트 + 권한 이상

점수	대응
< 2	로그만 축적 (원천 태그 유지)
2 ~ 8	분석가 큐, 24시간 내 트리아지
8 ~ 27	즉시 알림, 사용자 확인 절차
> 27	세션 차단 + 계정 격리 + 법무/HR 연계

곱셈을 쓰는 이유는 의도적입니다. 덧셈 모델에서는 "민감하지 않은 데이터를 이상한 채널로 보내는" 케이스와 "민감한 데이터를 정상 채널로 보내는" 케이스가 비슷한 점수를 받습니다. 곱셈 모델에서는 어느 한 축이 0.5(정상)면 전체 점수가 눌리고, 여러 축이 동시에 높을 때만 점수가 튑니다. 내부자 위협의 본질이 바로 이것, 단일 이벤트가 아니라 축들의 동시 이탈입니다. 위 표의 가중치와 점수 구간은 이해를 돕기 위한 예시 값이며, 실제 값은 조직의 데이터 등급 체계와 대응 역량에 맞춰 다시 설계해야 합니다.

3. 매트릭스에서 탐지 룰까지

매트릭스는 지도이지 탐지 룰이 아닙니다. 이 장에서는 지도를 실제 SIEM 룰로 옮길 때의 순서와 구현 포인트를 다룹니다.

3-1. 데이터 소스 현실 점검

매트릭스의 모든 셀을 채우려면 조직의 거의 모든 로그가 필요합니다. 현실적으로 불가능하니, 획득 난이도 대비 커버리지로 우선순위를 정해야 합니다.

데이터 소스	획득 난이도	커버하는 축	커버하는 시나리오	비고
프록시/SWG	낮음 (대부분 이미 있음)	Movement, Destination	S1, S3, S7	지금 당장 시작 가능한 지점
메일 GW / 협업툴 감사로그	낮음	Movement, Destination	S1, S5, S7	SaaS API로 수집, 스키마 정규화 필요
엔드포인트 텔레메트리	중간	Transform	S1, S2, S6	EDR 이벤트 재활용 가능. 클립보드는 별도 계측
Git/Wiki/드라이브 접근 로그	중간	Origin	S2, S5	audit log는 있는데 아무도 안 보는 경우가 많음
DB 감사로그	높음	Origin	S3, S4, S8	성능 이슈로 운영팀 협의 필수. 쿼리 게이트웨이 경유 구조면 난이도 급감
HR 이벤트 피드	높음	Actor	S1 외 전체 가중치	법무와 HR과의 데이터 제공 협약이 선행
LLM 프록시	높음	Movement	S3	AI 게이트웨이 도입과 묶어서 추진하는 것이 현실적

주목할 점은, HR 이벤트 피드가 기술적으로 가장 쉬운데 조직적으로 가장 어렵다는 것입니다. 퇴직 통보 데이터를 보안팀이 받는다는 것 자체가 민감한 사안이라, 기술 설계보다 먼저 데이터 최소화 원칙(퇴직 여부와 D-day만, 사유는 받지 않음)과 접근통제를 문서화해서 협의해야 합니다.

3-2. 원천 태깅의 구현

4세대의 핵심인 원천 태깅은 세 가지 요소로 구성됩니다.

(1) 태그 부여: 데이터가 조회되는 관문에서 결과에 출처 식별자를 붙입니다. DB라면 쿼리 게이트웨이에서 {source: <원천 식별자>, query_id, user, ts} 형태의 태그를 발급하고, 결과셋의 지문을 함께 저장합니다. Git이라면 레포 식별자 + 커밋 해시가 이미 자연 태그입니다.

(2) 지문 저장: 파일 전체 해시는 한 글자만 바뀌어도 깨지므로, 부분 매칭이 가능한 방식이 필요합니다. 결과셋을 일정 크기 조각으로 나눠 롤링 해시를 뜨는 shingling 방식이 기본이고, 텍스트 정규화(공백/인코딩 통일)를 지문 생성 전에 반드시 거쳐야 합니다. 저장소는 조회량이 많은 조직일수록 빠르게 커지므로, 민감 등급이 높은 원천부터 선별 적용하고 보존 주기를 정합니다.

(3) 파생 상속: 엔드포인트에서 "태그된 파일을 읽은 프로세스가 새 파일을 쓰면" 태그를 상속시킵니다. EDR의 파일 계보(file lineage) 이벤트를 활용하면 압축과 이름변경까지는 따라갈 수 있습니다. 클립보드 경유는 상속이 끊기는 지점이므로, 여기서부터는 (2)의 지문 부분 매칭이 이어받습니다.

3-3. 예시: S3 (AI 도구 입력 유출) 룰

S3를 예로 들어 상관 로직을 SPL 스타일 의사코드로 표현하면 이렇습니다. 실제 운영 룰이 아니라 구조를 보여드리기 위한 예시이며, 민감 등급 기준 S, 시간 윈도우 T, 알림 임계값 R은 조직마다 정책으로 정하는 값입니다.

spl

# Origin: 민감 원천 조회
| tstats ... from datamodel=DB_Audit
    where DB_Audit.sensitivity >= S
    by DB_Audit.user, DB_Audit.query_id, _time

# Transform: 클립보드 복사 후 브라우저/IDE 붙여넣기
| join type=inner user
    [ search index=endpoint sourcetype=clipboard_event
      | where match(dest_process, "browser|ide") ]

# Movement: LLM 도메인 세션 (채널 위험도는 정책 lookup으로 관리)
| join type=inner user
    [ search index=proxy category=llm_provider
      | lookup llm_channel_policy domain OUTPUT channel_risk ]

# 시간 윈도우: 원천 조회 후 T 이내에 LLM 세션 발생
| where llm_session_time - query_time < T

# Actor 가중치 결합 및 스코어링
| lookup hr_events user OUTPUT actor_context
| eval risk = origin_sensitivity * transform_suspicion
              * channel_risk * actor_context
| where risk >= R

구조에서 봐야 할 포인트는 세 가지입니다. 첫째, 조인 키는 사람(user)이고 판정 키는 시간 윈도우입니다. "민감 조회"와 "LLM 세션"이 각각은 정상 업무여도, 짧은 윈도우 안에서 연결되면 이야기가 달라집니다. 둘째, 여기에 3-2의 지문 부분 매칭이 붙으면 확신도가 점프합니다. LLM 프록시가 프롬프트 페이로드를 볼 수 있는 구조라면, 페이로드 지문과 원천 지문의 조각 매칭으로 "그 데이터가 실제로 들어갔는지"까지 판정할 수 있습니다. 이것이 시간 상관(추정)과 계보 추적(증거)의 차이입니다. 셋째, 스코어링 요소를 룰 안에 하드코딩하지 말고 lookup으로 분리해야 합니다. 민감도 등급표, 승인 LLM 목록, HR 윈도우는 계속 바뀌는 값이고, 룰 코드와 정책 데이터를 분리해야 정책 변경 때마다 룰을 재배포하지 않아도 됩니다.

3-4. 룰을 코드로 관리하기

내부자 위협 룰은 일반 위협 탐지 룰보다 관리 요건이 까다롭습니다. 오탐 하나가 "회사가 나를 의심했다"는 경험이 되기 때문에 변경 이력과 근거가 남아야 하고, 룰 자체가 민감 정보(무엇을 어떻게 탐지하는지)이기 때문입니다. 그래서 Detection-as-Code 방식, 즉 룰을 Git으로 버전 관리하고, 리뷰를 거쳐 CI/CD로 배포하며, 테스트 이벤트로 회귀 검증하는 구조가 필요합니다. 룰 저장소의 접근통제는 탐지 대상 데이터만큼 엄격해야 합니다. 4장에서 다시 이야기하겠지만, 탐지 로직이 새는 순간 그 로직은 우회 매뉴얼이 됩니다.

4. 운영에서 만나는 세 개의 벽

룰을 만드는 것보다 어려운 것이 운영입니다. 일반적으로 알려진 운영 난점을 기준으로, 반드시 부딪히는 벽 세 가지를 공유합니다.

4-1. 오탐: 예외 처리가 아니라 기준선 설계로

내부자 위협 탐지의 오탐은 대부분 "정상 업무가 위협 패턴과 겹치는" 케이스입니다. 협력사와 협업 중인 PM의 외부 공유(S5), 데이터 분석 직군의 대량 조회(S1/S4의 Origin 신호), 조직개편 시즌의 접근 패턴 변화(Actor 축 오염). 이걸 알림이 뜰 때마다 예외 목록에 추가하는 방식으로 대응하면 예외 목록이 룰 본체보다 커집니다.

접근을 바꿔야 합니다. 직군과 역할별로 기준선을 다르게 설계하는 것입니다. 데이터 분석가의 "대량 조회"는 동료그룹(peer group) 대비 이탈로만 판정하고, 협력사 협업 사용자는 외부 공유의 목적지 도메인을 화이트리스트가 아니라 "협업 상대 도메인 목록"으로 관리합니다. 예외는 사람 단위가 아니라 컨텍스트 단위로 정의될 때만 유지보수가 가능합니다. 그리고 조직개편이나 평가 시즌 같은 전사 이벤트 캘린더를 룰의 억제(suppression) 조건에 반영해 두면, 분기마다 반복되는 오탐 파도를 미리 눌러둘 수 있습니다.

4-2. 개인정보와 노동법: 감시가 아니라 데이터 보호

이 영역은 기술보다 법이 먼저입니다. 한국 기준으로 최소한 세 가지를 정리하고 시작해야 합니다.

고지와 동의 체계: 임직원 모니터링의 범위와 목적을 취업규칙/정보보호 서약/사내 공지로 명확히 고지해야 합니다. 특히 클립보드나 화면 계측처럼 침습성이 높은 텔레메트리는 도입 전 법무 검토가 선행되어야 하고, 사업장 내 노사협의 대상이 될 수 있습니다.

목적 제한과 데이터 최소화: 탐지 시스템이 수집하는 로그는 그 자체로 개인정보처리시스템입니다. "데이터 유출 탐지"라는 목적으로 수집한 로그를 근태 평가나 인사 조치의 근거로 전용하는 순간 목적 외 이용이 됩니다. HR 이벤트 피드는 앞서 말했듯 필요 최소 필드만 받고, 접근 가능 인원을 명시적으로 제한합니다.

조사 절차의 정당성: 고위험 알림이 떠서 특정인을 조사하게 될 때의 절차(누가 승인하고, 어디까지 열람하고, 어떻게 기록하는지)를 사전에 문서화해야 합니다. 절차 없는 조사는 나중에 법적 다툼에서 증거 능력을 잃을 수 있고, 조직 신뢰를 무너뜨립니다.

관점 자체를 "직원 감시"가 아니라 "데이터의 이동을 보호한다"로 좁혀야 합니다. 4세대 프레임이 여기서 오히려 유리합니다. 사람의 모든 행동을 보는 것(3세대 UEBA의 확장)이 아니라, 민감 데이터에 태그를 붙이고 그 태그의 이동만 추적하는 구조는 수집 범위를 데이터 중심으로 한정할 수 있기 때문입니다.

4-3. 탐지 시스템 자체의 보안

내부자 위협 탐지의 역설은, 탐지 대상이 탐지 시스템에 접근 가능한 내부자일 수 있다는 점입니다. 태깅이 어느 원천에 적용되는지, 어떤 임계값에서 알림이 뜨는지를 아는 사람은 그 아래로 기어갈 수 있습니다(S7이 정확히 이 패턴입니다). 그래서 다음이 필요합니다.

룰, 임계값, 태깅 대상 목록에 대한 접근을 탐지팀 내에서도 최소화
탐지 인프라(SIEM, 태그 저장소, LLM 프록시)의 관리자 행위 자체를 별도 감사
임계값 기반 룰과 함께, 임계값이 없는 누적 롤업 룰(S7의 원천 태그 일별 → 분기별 합산)을 병행. 임계값을 아는 사람도 누적 합계는 피할 수 없습니다

이 블로그에서 매트릭스의 구조와 원리만 공유하고 실제 임계값이나 운영 룰을 공유하지 않는 이유도 같습니다. 방법론은 공유재가 될 수 있지만, 파라미터는 각 조직의 비밀이어야 합니다.

마지막으로, 탐지 불가 영역을 인정해야 합니다. 개인 폰으로 화면을 촬영하거나 구두로 전달하는 채널은 어떤 계측으로도 잡히지 않습니다. 이 영역은 기술이 아니라 억지력의 영역입니다. 화면 워터마크(누가 언제 조회한 화면인지 사후 추적 가능하다는 사실 자체가 억지력), 보안 서약과 법적 책임의 명시, 그리고 보안 문화. 매트릭스에 S6을 굳이 넣은 이유는 "여기는 탐지로 못 막는다"를 팀과 경영진이 공유하기 위해서입니다.

5. 어디서부터 시작할까: 성숙도 로드맵

4세대를 하루아침에 구축할 수는 없습니다. 제가 권하는 순서는 다음과 같습니다.

단계	목표	하는 일	커버 시나리오
Phase 0. 인벤토리	지도 그리기	민감 원천 목록화(어떤 DB/레포/문서가 규제 대상, PII, 핵심자산인지), 보유 로그 소스와 매트릭스 셀 매핑, 빈 셀 식별	해당 없음
Phase 1. Movement 우선	있는 로그로 시작	프록시, 메일 GW, 협업툴 로그 기반 룰. 개인 클라우드 업로드, 외부 공유, LLM 도메인 목록화	S1(부분), S5, S7(부분)
Phase 2. Origin 계측	원천이 보이기 시작	Git/드라이브 감사로그 수집, DB 감사로그 또는 쿼리 게이트웨이 협의, HR 피드 협약	S2, S4, S1(완성)
Phase 3. Lineage 연결	4세대 본체	원천 태깅 + 지문 저장소, 파생 상속, LLM 프록시 페이로드 매칭, 사용자 간 전파 그래프	S3, S7(완성), S8

핵심은 Phase 1을 건너뛰지 않는 것입니다. 4세대 프레임에 매료되면 태깅 파이프라인부터 만들고 싶어지는데, Movement 계층의 기본 탐지 없이 원천 계측부터 시작하면 투자 대비 성과를 보여줄 수 없어 프로젝트가 중간에 좌초합니다. Phase 1에서 실제 탐지 성과(그리고 오탐 관리 경험)를 쌓고, 그 성과로 Phase 2~3의 조직 협의(DB팀, HR, 법무)를 끌어내는 것이 현실적인 경로입니다.

6. 마치며

긴 글을 정리하자면 다음과 같습니다.

DLP는 패턴 → 내용 → 컨텍스트 → 계보(Lineage)로 진화해 왔고, AI가 업무 도구가 된 지금은 "파일"이 아니라 "데이터 조각"의 이동을 추적하는 4세대 관점이 필요합니다.
탐지 설계는 시나리오 나열이 아니라 매트릭스여야 합니다. 데이터 생애주기(Origin → Transform → Movement → Destination)와 행위자 축 위에 시나리오를 올리면, 커버리지의 빈 셀이 보이고 셀들을 잇는 원천 키가 보입니다.
리스크는 덧셈이 아니라 곱셈입니다. 내부자 위협은 단일 이벤트가 아니라 여러 축의 동시 이탈이기 때문입니다.
룰보다 어려운 것이 운영입니다. 기준선 설계, 개인정보 및 노동법, 탐지 시스템 자체의 보안이라는 세 벽을 넘을 준비 없이 룰부터 만들면 안 됩니다.

완벽한 내부자 위협 탐지는 없습니다. S6처럼 원리적으로 탐지 불가능한 채널이 존재하고, 계측을 촘촘히 할수록 프라이버시와의 긴장은 커집니다. 그래서 이 매트릭스의 진짜 용도는 탐지 룰 생성기가 아니라 대화의 도구라고 생각합니다. 경영진에게는 "우리가 무엇을 볼 수 있고 무엇을 못 보는지"를, 법무와 HR에게는 "무엇을 왜 수집하려는지"를, 그리고 보안팀 내부에서는 "다음 분기에 어느 셀을 채울지"를 이야기할 수 있는 공통 언어 말이죠.

이 글이 내부자 위협 탐지를 설계하는 분들께 출발점이 되었으면 합니다. 각자의 환경에서 매트릭스를 변형해 쓰신 경험이나 다른 관점이 있다면 언제든 피드백 주세요. 긴 글 읽어주셔서 감사합니다.