Detection Engineering Needs a Forge: 탐지공학 운영체계 점검 포인트

서론

탐지공학을 단순히 SIEM 쿼리나 EDR 룰을 작성하는 일로 보면 운영은 금방 한계에 부딪힌다. 위협은 클라우드, SaaS, ID, 엔드포인트, 이메일, CI/CD 환경을 넘나들고, SOC는 이미 많은 경보와 불완전한 맥락 사이에서 우선순위를 정해야 한다. 이 상황에서 룰 개수만 늘리면 탐지 공백이 줄어드는 것이 아니라 경보 피로와 유지보수 부채가 커질 수 있다.

필요한 것은 탐지 룰을 빚고, 검증하고, 배포하고, 측정하고, 폐기하는 반복 가능한 운영 공정이다. Detection Engineering의 "forge"는 특정 벤더 기능이나 단일 플랫폼을 뜻하지 않는다. 탐지 가설을 운영 데이터로 재현하고, 변경 이력을 남기고, 테스트를 통과한 탐지만 운영에 올리며, SOC 조사 결과를 다시 개선으로 돌리는 체계다.

SOC 리더와 탐지 엔지니어가 먼저 던져야 할 질문은 "우리에게 룰이 몇 개인가"가 아니다. "각 탐지가 어떤 공격 행위를 겨냥하는지, 필요한 데이터가 실제로 들어오는지, 정상 업무와 공격 행위를 모두 검증했는지, 경보가 조사자에게 충분한 근거를 주는지"를 확인해야 한다.

본론

탐지공학은 생명주기 관리다

탐지공학의 성숙도는 룰 수량보다 생명주기의 완성도로 판단해야 한다. 기본 흐름은 가설 수립, 데이터 확인, 룰 구현, 리뷰, 테스트, 배포, 운영 측정, 튜닝 또는 폐기다.

가설 수립 단계에서는 공격 행위, 대상 자산, 필요한 로그, 기대 신호, 우회 가능성을 명확히 정의한다. 예를 들어 "관리자 권한 탈취"를 탐지한다는 문장만으로는 부족하다. 어떤 계정 행위가 비정상인지, 어떤 로그 소스와 필드가 필요한지, 정상 운영 작업과 어떻게 구분할지까지 적어야 한다.

데이터 확인은 자주 생략되지만 가장 중요한 단계다. 룰은 존재하지만 필드가 누락되거나 파서가 바뀌거나 로그 수집이 늦으면 탐지는 문서상으로만 존재한다. 엔드포인트, ID, 이메일, 네트워크, 클라우드, SaaS, CI/CD, 컨테이너 로그가 주요 공격 시나리오를 재현할 만큼 수집되는지 확인해야 한다. user, host, process, command_line, source_ip, destination_ip, cloud_account, role, resource_id 같은 핵심 필드가 조직의 스키마 기준에 맞게 정규화되는지도 함께 봐야 한다.

테스트와 폐기도 생명주기의 일부다. 탐지 룰은 공격 시뮬레이션에서 한 번 울렸다는 이유만으로 충분하지 않다. 정상 관리자 스크립트, 백업, 배포, 보안 점검 도구 같은 업무 시나리오에서도 오탐을 확인해야 한다. 반대로 위협 기법이 변했거나 데이터 비용 대비 효과가 낮아진 룰은 폐기하거나 재작성해야 한다. 오래된 룰을 그대로 유지하는 것은 탐지 자산이 아니라 운영 부채가 될 수 있다.

조직 역할과 피드백 루프가 먼저다

탐지공학은 한 명의 룰 작성자가 책임지는 업무가 아니다. SOC 분석가, 위협 인텔리전스, 사고 대응, 클라우드 보안, IAM, 데이터 엔지니어링, 플랫폼 운영이 맞물리는 영역이다.

탐지 엔지니어는 탐지 가설을 룰과 테스트로 구현하고 배포 품질을 관리한다. SOC 분석가는 경보 조사 결과, 오탐 원인, 누락된 맥락을 피드백한다. 위협 인텔리전스 담당자는 실제 공격 기법과 캠페인을 탐지 백로그로 바꾼다. 사고 대응 담당자는 침해 조사에서 확인한 행위를 신규 탐지와 헌팅 쿼리로 되돌린다. 데이터와 플랫폼 담당자는 로그 수집, 파서, 스키마, 비용, 지연, 보존 기간을 관리한다. 보안 리더는 품질 지표와 리스크 기반 우선순위를 승인해야 한다.

운영 점검은 다음 질문에서 시작할 수 있다.

• 탐지 룰별 owner, reviewer, 승인자, 운영 담당자가 지정되어 있는가.
• 룰 변경이 콘솔 직접 수정으로 끝나지 않고 변경 이력과 리뷰 기록을 남기는가.
• SOC 조사 결과가 탐지 엔지니어에게 티켓, 회의, 대시보드 형태로 주기적으로 돌아오는가.
• 탐지 백로그가 CVE, ATT&CK, 위협 인텔리전스, 내부 사고, 감사 요구사항을 구분해 관리되는가.
• 탐지공학 KPI가 룰 개수가 아니라 조사 효율, 오탐 감소, 미탐 보완, 대응 연결률로 정의되어 있는가.

잘못된 지표는 탐지 품질을 망친다. ATT&CK 매핑 개수나 일일 경보량만 보면 조직은 더 많은 노이즈를 생산하는 방향으로 움직일 수 있다. 룰별 true positive rate, false positive rate, human escalation rate, closed benign rate, 공격 시뮬레이션별 탐지 성공률, 탐지 가설 작성부터 배포까지 걸린 시간, 예외 만료 준수율, 고위험 탐지의 평균 조사 시간처럼 운영 성과와 연결되는 지표가 필요하다.

Detection-as-Code는 저장소보다 운영 방식이다

Detection-as-Code는 탐지 룰을 코드처럼 다루는 접근이다. 그러나 핵심은 Git 저장소를 하나 만드는 것이 아니다. 변경 이력, 코드 리뷰, 테스트, 릴리스, 롤백이 가능한 운영 방식을 만드는 데 있다.

탐지 저장소나 레지스트리에는 최소한 rule_id, title, description, severity, confidence, data_sources, required_fields, ATT&CK mapping, owner, test_cases, response_playbook이 포함되어야 한다. severity와 confidence도 분리하는 편이 좋다. 심각도는 영향도와 대응 우선순위를, 신뢰도는 탐지 정확도와 근거 강도를 설명해야 한다.

PR 리뷰에서는 탐지 조건만 보지 말아야 한다. 필요한 필드가 실제로 수집되는지, 쿼리 비용이 과도하지 않은지, 예상 오탐이 문서화되어 있는지, 대응 playbook이 연결되어 있는지, 경보 출력이 조사자에게 충분한 맥락을 주는지까지 확인해야 한다. 배포 파이프라인은 문법 오류, 필드 누락, 중복 룰, 과도한 스캔 비용, 누락된 메타데이터를 자동으로 잡아야 한다.

아직 Detection-as-Code를 도입하지 못한 조직도 시작점은 있다. 전체 룰 목록, 변경 이력, owner, 마지막 검증일, 마지막 발화일, 데이터 소스, 예외 목록부터 별도 레지스트리로 관리하면 된다. 운영 콘솔에서 긴급 수정이 필요했다면 나중에 반드시 저장소나 레지스트리로 역반영하는 절차도 필요하다.

로그 품질과 예외 관리가 탐지 품질을 결정한다

탐지는 데이터 품질을 넘을 수 없다. 로그 수집 지연, 파서 오류, 필드 누락, 자산 맥락 부재는 모두 탐지 정확도를 떨어뜨린다. 조직이 OCSF, ECS, ASIM 같은 스키마 중 하나를 선택했다면 선택 자체보다 변환 품질을 지속적으로 테스트하는지가 더 중요하다.

탐지 단계에서 enrichment도 필요하다. 사용자 권한, 자산 중요도, 부서, 위치, 취약점 상태, 인터넷 노출 여부가 경보에 반영되면 조사 우선순위가 달라진다. 같은 명령 실행이라도 일반 사용자의 노트북, 도메인 관리자 계정, 인터넷 노출 서버에서 발생한 경우의 의미는 다르다.

예외 처리는 별도 관리 대상이어야 한다. 서비스 계정, 배포 서버, 보안 스캐너, 관리자 스크립트를 룰 내부에 계속 하드코딩하면 시간이 지날수록 룰이 부패한다. 예외는 룰 코드와 분리된 레지스트리에서 승인자, 사유, 범위, 만료일, 재검토 결과를 가져야 한다. 예외 추가는 오탐 감소 효과뿐 아니라 미탐 위험 증가까지 평가해야 하며, 적용 후에는 공격 시뮬레이션이나 회귀 테스트를 다시 수행하는 것이 바람직하다.

비용과 성능도 탐지공학의 일부다. 룰별 실행 주기, 스캔 데이터량, 평균 실행 시간, 실패율을 측정하지 않으면 탐지 비용이 조용히 커진다. 같은 공격 행위를 여러 룰이 중복 경보로 만드는지도 확인해야 한다. 고비용 룰은 pre-filter, summary table, streaming detection, EDR local rule 등으로 옮길 수 있는지 검토해야 한다.

AI SOC 시대에는 경보 메타데이터가 더 중요해진다

AI SOC, MDR, SOAR가 경보를 소비하는 환경에서는 탐지 출력이 단순 제목과 심각도만 가져서는 부족하다. 조사 계층이 바로 사용할 수 있는 근거와 맥락이 있어야 한다.

권장되는 경보 메타데이터는 다음과 같다.

• 공격 전술과 기법: ATT&CK tactic, technique, sub-technique
• 신뢰도: IOC 기반인지, 행위 휴리스틱인지, 임계치 기반인지 구분
• 엔티티 맥락: 사용자 권한, 자산 중요도, 신규 행위 여부, 평소 행위와의 차이
• 근거 이벤트: 원본 이벤트 링크, 핵심 필드, 쿼리 매치 이유
• 예상 오탐: 정상 관리 작업, 배포 작업, 보안 점검 도구, 서비스 계정
• 대응 힌트: 격리, 세션 회수, 토큰 폐기, 메일 격리, 추가 헌팅 쿼리
• 데이터 품질: 필요한 필드 누락 여부, 파서 버전, 수집 지연

AI가 탐지 엔지니어를 대체한다는 뜻이 아니다. 오히려 AI나 자동화 계층이 경보를 소비할수록 탐지 출력의 품질 기준은 높아진다. 같은 룰이 반복적으로 정상으로 닫힌다면 로직이 틀렸거나, 환경 맥락이 부족하거나, 경보 메타데이터가 조사에 충분하지 않은 것이다.

대응 우선순위와 실무 체크리스트

탐지공학 운영체계를 한 번에 완성하려고 하면 기존 SOC 운영과 충돌하기 쉽다. 우선순위는 현재 룰의 상태를 보이게 만들고, 고위험 탐지부터 품질 기준을 붙인 뒤, 예외와 폐기 기준까지 운영 루프로 연결하는 순서가 현실적이다.

우선순위 1: 룰 인벤토리를 먼저 만든다

가장 먼저 전체 탐지 룰 목록을 확보해야 한다. 룰별 owner, 플랫폼, 데이터 소스, ATT&CK 매핑, 마지막 수정일, 마지막 검증일, 마지막 발화일, 예외 목록을 채운다. 최근 90일 기준으로 가장 많이 울린 룰, 에스컬레이션이 많았던 룰, 한 번도 울리지 않은 고위험 룰을 나눠 본다.

체크리스트:

• 운영 콘솔에만 존재하는 룰이 있는가.
• owner와 reviewer가 없는 룰이 있는가.
• 마지막 검증일을 알 수 없는 룰이 있는가.
• 최근 90일 동안 반복 오탐을 만든 룰이 있는가.
• 고위험 룰인데 장기간 한 번도 발화하지 않은 룰이 있는가.

우선순위 2: 메타데이터와 리뷰 기준을 표준화한다

탐지 룰의 필수 메타데이터를 정해야 한다. 제목, 설명, 심각도, 신뢰도, 데이터 소스, 필요 필드, ATT&CK 매핑, 예상 오탐, 테스트 케이스, 대응 playbook, owner를 최소 기준으로 둔다.

체크리스트:

• severity와 confidence가 분리되어 있는가.
• 탐지 가설과 필요한 로그가 문서화되어 있는가.
• PR 또는 변경 리뷰에서 데이터 비용과 예외까지 확인하는가.
• 대응 playbook이나 조사 절차가 경보와 연결되어 있는가.
• 경보 출력이 SOC, MDR, SOAR, AI 조사 계층에서 그대로 사용할 수 있는가.

우선순위 3: 상위 탐지부터 테스트 체계를 붙인다

모든 룰을 한 번에 정비하려고 하면 오래 걸린다. 우선순위가 높은 탐지 10개부터 샘플 로그, 정상 케이스, 공격 시뮬레이션, 회귀 테스트를 붙이는 방식이 현실적이다.

체크리스트:

• 샘플 악성 이벤트와 정상 이벤트가 모두 있는가.
• Atomic Red Team, Caldera, Prelude, 수동 purple team 등으로 실제 로그를 생성해 본 적이 있는가.
• 경보 생성 후 티켓, SOAR, MDR, 알림 채널까지 맥락이 유지되는가.
• 테스트 실패 시 룰을 자동 배포하지 못하게 막는 절차가 있는가.
• 룰 수정 후 기존 탐지가 깨지지 않았는지 회귀 테스트하는가.

우선순위 4: 예외와 폐기 기준을 운영한다

오탐을 줄이기 위해 예외를 계속 추가하는 방식은 단기 처방일 뿐이다. 예외 레지스트리를 만들고 만료일을 강제해야 한다. 동시에 낡은 룰의 폐기 기준도 운영해야 한다.

체크리스트:

• 예외가 룰 코드와 분리되어 있는가.
• 예외마다 승인자, 사유, 범위, 만료일이 있는가.
• 만료일 없는 예외가 얼마나 되는가.
• 예외 추가 후 미탐 위험을 다시 평가하는가.
• 룰별 비용, 발화 품질, 위협 유효성을 기준으로 폐기 후보를 정하는가.

우선순위 5: 월간 Detection Review를 운영한다

탐지공학은 한 번 정리하고 끝나는 프로젝트가 아니다. 월간 리뷰에서 SOC, 위협 인텔리전스, 사고 대응, 클라우드/IAM, 데이터 플랫폼 담당자가 함께 탐지 품질을 봐야 한다.

체크리스트:

• 오탐 상위 룰을 예외 문제가 아니라 가설, 데이터, 임계치, 메타데이터 문제로 분류하는가.
• 신규 위협 공개 후 탐지 가설 작성까지 걸린 시간을 측정하는가.
• 공격 시뮬레이션 결과를 coverage뿐 아니라 조사 정확도와 대응 시간까지 평가하는가.
• 탐지 백로그가 리스크 기반으로 우선순위화되어 있는가.
• 개선 결과가 다음 배포와 지표에 반영되는가.

결론

탐지공학은 더 많은 룰을 쓰는 경쟁이 아니다. 신뢰할 수 있는 경보를 반복적으로 생산하고, 운영 결과로 계속 개선하는 체계를 만드는 일이다. SOC가 탐지 룰을 제품처럼 다루지 않으면 룰은 빠르게 부패하고, 예외는 늘어나며, 조사자는 맥락 없는 경보 속에서 시간을 잃는다.

반대로 탐지 가설, 데이터 품질, 코드 리뷰, 테스트, 배포, 예외 관리, 운영 지표가 연결되면 탐지는 조직의 대응 역량을 실제로 높인다. AI SOC와 자동화가 확산될수록 이 기준은 더 중요해진다. 자동화 계층은 좋은 탐지를 증폭하지만, 부실한 탐지의 노이즈도 그대로 증폭하기 때문이다.

따라서 첫 실행 단위는 작아야 한다. 전체 룰 인벤토리를 만들고, 상위 오탐 룰과 미발화 고위험 룰을 검토하며, 핵심 탐지 10개에 테스트와 메타데이터를 붙이는 것부터 시작할 수 있다. 이후 예외 레지스트리와 월간 Detection Review까지 연결하면 우선순위 점검이 일회성 정리가 아니라 지속적인 개선 루프가 된다. 그 공정이 반복 가능해질 때 탐지공학은 개인 역량이 아니라 조직의 운영체계가 된다.

참고자료

1. SOC Prime, What Is Detection Engineering?
   https://socprime.com/blog/what-is-detection-engineering/

2. Splunk, What Is Detection Engineering? A Complete Guide to Modern Threat Detection
   https://www.splunk.com/en_us/blog/learn/detection-engineering.html

3. Prophet Security, Detection Engineering in an AI-Driven SOC
   https://www.prophetsecurity.ai/blog/detection-engineering-in-an-ai-driven-soc-what-actually-needs-to-change

4. Exaforce, Detection engineering: A complete guide for security teams
   https://www.exaforce.com/learning-center/detection-engineering

5. Cymulate, Detection Engineering: A Complete Guide
   https://cymulate.com/cybersecurity-glossary/detection-engineering/

6. MITRE ATT&CK
   https://attack.mitre.org/

7. OCSF, Open Cybersecurity Schema Framework
   https://schema.ocsf.io/

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