깨끗한 트래픽에 대한 0.1%의 오탐률(false-positive rate)은 아무 의미가 없습니다. 이 테스트는 탐지기가 건강 확인용 ping이나 일반 JSON API 호출을 무시할 수 있다는 것을 입증했습니다. 아무도 그것에 대해 걱정하지 않았습니다. 실제 탐지기를 작동시키는 트래픽은 공격처럼 보이지만 실제로 공격이 아닌 것들인데, 만약 여러분의 정상 테스트 세트(benign test set)에 그런 것이 없다면, 여러분의 오탐률은 참여 상패 수준입니다.

저는 AI 에이전트의 외부 통신(egress)을 위한 탐지 규칙을 작성하기 때문에 이것을 자주 봅니다. 에이전트가 프롬프트 주입 문자열을 인용하는 보안 권고문을 읽습니다. SQL injection, XSS, SSRF를 나열한 도구 설명이 있는 스캐너를 호출합니다. 붙여넣은 튜토리얼에는 AWS 자체의 가짜 키인 AKIAIOSFODNN7EXAMPLE가 포함되어 있습니다. 요약한 로그는

이것들은 불안정한 탐지기(jumpy detector)를 드러내는 샘플들입니다. 나머지는 모두 채우기용(filler)일 뿐입니다. 만약 당신의 정상 데이터 세트(benign set)가 400개의 깨끗한 API 호출로만 구성되어 있고 유사 사례(lookalikes)가 하나도 없다면, 아무것도 매칭되지 않는 정규 표현식(regex)만으로도 오탐(false-positive) 측면에서 완벽한 성적을 거둘 수 있으며, 당신은 정확히 그만큼만을 증명한 셈이 됩니다.

에이전트 이그레스(Agent egress)가 상황을 악화시킨다

전형적인 네트워크 탐지는 의지할 수 있는 지루한 정상 트래픽이 훨씬 더 많았습니다. 하지만 에이전트 트래픽은 그 양이 더 적습니다.

에이전트의 전체 업무는 시스템 간에 텍스트를 이동시키는 것입니다. 문서를 읽고, 스캐너를 실행하며, 소스 코드를 열고, 그 혼란스러운 데이터들을 어딘가로 전달합니다. 따라서 정상적인 스트림(benign stream)은 공격은 아니지만 공격 형태를 띤 텍스트, 그리고 유출되는 것은 없지만 자격 증명(credential) 형태를 띤 텍스트로 가득 차게 됩니다. 단순한 DLP(데이터 유출 방지)나 인젝션(injection) 규칙이 주목하는 신호는 하루 종일 정상적인 트래픽 속에서 나타납니다. 이러한 트래픽에 대한 테스트를 건너뛴다면, 운영 환경(production)에서의 첫 일주일은 긴 오탐(false-positive) 사고의 연속이 될 것이며, 운영자들은 해당 규칙을 제거해 버릴 것입니다. 저는 이러한 실패 모드(failure mode)가 탐지 실패(misses)보다 더 많은 규칙을 사장시키는 것을 목격해 왔습니다.

게으른 탐지기를 무너뜨리는 예시들

다음은 하드 네거티브(hard-negative) 테이블의 형태입니다. 모든 행은 정상(benign)이지만, 모든 행은 정상처럼 보이지 않습니다.

이 중 어느 것도 드문 일이 아닙니다. 바로 이 지점에서 규칙이 제 역할을 다하거나, 혹은 삭제됩니다.

자신만의 데이터 세트를 구축하라

당신에게 중요한 네거티브(negatives) 샘플을 다운로드할 수는 없습니다. 당신의 규칙을 무너뜨리는 것들은 당신만의 혼란스러운 데이터들, 즉 문서, 런북(runbooks), CI 로그, 스캐너 출력, 지원 티켓, 예시 자격 증명, 인코딩된 픽스처(encoded fixtures), 도구 스키마(tool schemas)에서 나옵니다. 그것이 바로 당신의 에이전트가 생성하는 정상 트래픽의 원천이며, 따라서 유사 사례(lookalikes)가 존재하는 곳이기도 합니다.

그러한 소스들로부터 데이터를 가져오십시오. 각 샘플을 당신이 집행하고자 하는 정책(policy)에 따라 레이블링(labeling)하십시오. 튜닝(tuning) 과정에서 탐지기(detector)가 절대 보지 못하는 별도의 프라이빗 홀드아웃(private holdout) 세트를 유지하십시오. 홀드아웃은 사람들이 흔히 건너뛰는 부분이지만, 당신이 자신의 테스트 세트에 과적합(overfitting)된 후 그것을 정밀도(precision)라고 부르는 상황을 막아주는 핵심적인 부분입니다.

정직하게 보고하십시오

단일 오탐률(false-positive rate)은 중요한 부분을 숨길 수 있게 만듭니다. 이를 분리하십시오. 쉬운 부정 사례(easy negatives)에 대한 비율과 어려운 부정 사례(hard negatives)에 대한 비율을 두 개의 숫자로 나누어 보고하십시오. 왜냐하면 그 차이가 바로 발견 사항(finding)이기 때문입니다. 깨끗한 트래픽(clean traffic)에서는 0%이지만 유사 사례(lookalikes)에서는 30%가 나오는 탐지기는, 정상 트래픽이 위험해 보이는 순간 패닉에 빠집니다. 이를 0.3%라고 부르는 것은 결과를 세탁하는 행위입니다.

그 김에 단위도 명시하십시오. 오탐률의 기준은 무엇입니까: 요청당(per request), 세션당(per session), URL당(per URL), 문서 청크당(per document chunk), 도구 호출당(per tool call), 알림당(per alert)? 분모가 없는 비율은 형편없는 수치이며, 벤더(vendor)들은 자신들을 돋보이게 하는 분모를 선택합니다.

그다음에는 놓친 사례(misses)들을 보여주십시오. 제가 직접 테스트를 수행할 때는 실패 사례들을 점수 바로 옆에 게시합니다. 만약 숫지 뒤에 숨겨진 실패 사례를 아무도 볼 수 없다면, 그것은 측정이 아니라 주장일 뿐입니다. 승리한 사례만 보고한다면 당신은 탐지 엔지니어링(detection engineering)을 하는 것이 아니라 마케팅을 하고 있는 것입니다.

성가신 주의사항

특정 어려운 부정 사례(hard negative)를 허용할지 차단할지는 보편적인 진리가 아니라 당신의 정책(policy)에 달려 있습니다. 많은 기업이 예시 값인지 여부와 상관없이 AWS 키 형태의 문자열이 보이면 즉시 차단하며, 이는 방어 가능한 결정입니다. 따라서 각 샘플을 당신의 정책에 따라 레이블링하고, 그것이 보편적으로 안전한 것처럼 가장하지 마십시오. 벤치마크는 반드시 그 정책을 명시적으로 밝혀야 합니다. 선언된 정책 경계가 없는 어려운 부정 사례(hard-negative) 세트는 여전히 깨끗한 트래픽보다는 성능이 좋겠지만, 이는 논란의 여지가 있는 주장일 뿐입니다.

핵심

탐지(detection)는 정상 트래픽이 공격처럼 보일 때 침착함을 유지함으로써 그 오탐률(false-positive rate)의 가치를 증명합니다. 만약 테스트 과정에서 위험해 보이는 정상 트래픽을 한 번도 만나보지 못했다면, 수치가 아무리 좋아 보여도 아직 아무것도 증명한 것이 아닙니다.

저는 이러한 유사 사례(lookalikes)들을 모은 공개 스타터 세트(starter set)를 agent-egress-bench에 보관하고 있습니다. 이는 특정 도구에 종속되지 않으므로(tool-neutral), 여러분이 사용하는 어떤 도구에 대해서도 실행해 볼 수 있습니다. 하지만 이를 씨앗(seed)으로만 취급하십시오. 여러분의 규칙을 깨뜨릴 부정 사례(negatives)들은 여러분 자신의 문서와 로그, 그리고 여러분 자신의 도구들로부터 나오는 것들이며, 그 누구도 여러분을 대신해 그것들을 만들어 줄 수 없습니다.