코드형 탐지 원칙

코드형 탐지는 소프트웨어 공학의 원칙을 보안 탐지에 적용합니다. 분석가가 SIEM 콘솔 안에서 규칙을 직접 수정하는 대신, 탐지 규칙은 버전 관리의 텍스트 파일로 저장되고 파이프라인을 통해 배포됩니다.

구체적인 이점은 다음과 같습니다:

• 풀 리퀘스트를 통한 검토 가능한 변경 사항
• 환경 전반에서 재현 가능한 배포
• 운영 환경에 도달하기 전에 테스트 가능한 논리
• 누가 무엇을, 왜 변경했는지 확인할 수 있는 감사 가능한 이력

탐지 규칙은 다른 코드처럼 차이를 비교하고 되돌리며 동작을 추론할 수 있는 산출물이 됩니다.

각 탐지 규칙은 일반적으로 YAML 또는 공급업체 쿼리 언어로 작성된 독립적인 파일로 저장되어 Git 저장소에 커밋됩니다. 저장소 구조는 적용 범위를 구성하는 방식과 일치합니다.

플랫폼과 전술별로 규칙을 나누는 일반적인 구조는 다음과 같습니다:

새 탐지 규칙이나 수정된 탐지 규칙은 모두 병합 요청을 거칩니다. 두 번째 엔지니어가 병합하기 전에 논리, 오탐 위험 및 ATT&CK 매핑을 검토합니다.

검토자는 다음을 질문합니다:

• 논리가 설명된 위협과 일치합니까?
• 어떤 정상 활동이 이를 발생시킬 수 있습니까?
• 심각도와 ATT&CK 참조가 올바릅니까?
• 참양성과 오탐을 다루는 테스트가 있습니까?

이 과정을 통해 새벽 2시에 분석가 혼자 SIEM을 수정했다면 놓쳤을 실수를 발견할 수 있습니다.

지속적 통합 파이프라인은 푸시할 때마다 자동으로 실행됩니다. 규칙을 병합하기 전에 품질 기준을 적용합니다.

시그마 기반 저장소의 일반적인 지속적 통합 단계는 다음과 같습니다:

병합되면 배포 작업이 이식 가능한 규칙을 대상 쿼리 언어로 변환하고 응용 프로그램 인터페이스를 통해 SIEM 또는 EDR로 전송합니다.

시그마에서는 일반적으로 플랫폼에 맞는 백엔드를 사용하여 sigma convert와 같은 변환기를 실행합니다(스플렁크, 일래스틱, 마이크로소프트 센티널). 그런 다음 파이프라인이 생성된 저장 검색 또는 분석 규칙을 업로드합니다.

사람이 콘솔에 쿼리를 붙여 넣지 않습니다. 배포된 상태는 항상 main에 있는 내용과 일치합니다.

테스트가 없는 탐지 규칙은 추측에 불과합니다. 코드형 탐지는 각 규칙에 테스트 데이터를 연결합니다. 규칙이 탐지해야 하는 로그 샘플(참양성)과 탐지하지 않아야 하는 정상 로그 샘플(오탐)입니다.

테스트는 지속적 통합에서 실행되므로, 적용 범위를 깨뜨리거나 잡음을 재도입하는 변경으로 인해 병합 전에 빌드가 실패합니다. 이는 규칙을 대규모로 리팩터링할 때 신뢰를 주는 가장 큰 요소입니다.

메타데이터를 핵심 요소로 취급하십시오. 각 탐지 규칙은 수명 주기를 거치며 상태를 기록합니다:

• experimental — 새로 작성되었으며 면밀히 모니터링함
• test — 실행 중이지만 아직 경고에 신뢰할 수 없음
• stable — 검증되었으며 오탐률이 낮음
• deprecated — 다른 규칙으로 대체되었거나 폐기됨

파일에서 상태를 추적하면 오래된 논리가 운영 환경에 남아 있게 두지 않고 규칙을 의도적으로 승격, 강등 및 폐기할 수 있습니다.

코드형 탐지의 핵심 이점은 공급업체 중립 형식으로 탐지 논리를 한 번 작성한 다음 여러 백엔드로 컴파일할 수 있다는 것입니다. 시그마는 로그 기반 탐지의 사실상 표준입니다.

시그마 규칙 파일 하나로 파이프라인별 필드 매핑을 통해 스플렁크 SPL, 일래스틱 루씬/EQL, 마이크로소프트 센티널 KQL 등 여러 대상을 지정할 수 있습니다. 같은 아이디어를 다섯 번 다시 작성할 필요가 없고 특정 공급업체에 종속되지도 않습니다.

로그 소스마다 같은 데이터의 이름이 다릅니다. 시스몬 프로세스 생성 이벤트는 Image를 사용하지만 Windows 보안 로그는 NewProcessName을 사용할 수 있습니다. 처리 파이프라인이 이러한 차이를 연결합니다.

파이프라인은 일반적인 시그마 필드 이름을 데이터가 사용하는 정확한 필드로 변환하므로, 하나의 논리적 규칙을 SIEM이 수집하는 어떤 스키마에도 깔끔하게 매핑할 수 있습니다. 파이프라인을 중앙에서 관리하면 스키마 변경을 규칙별이 아니라 한 번만 수정하면 됩니다.

애플리케이션 코드와 마찬가지로 탐지 규칙은 운영 환경에 도달하기 전에 여러 환경을 거칩니다. 일반적인 흐름은 개발에서 스테이징을 거쳐 운영으로 이어집니다.

• 개발 — 규칙을 작성하고 지속적 통합에서 단위 테스트를 실행합니다.
• 스테이징 — 실제 원격 측정 데이터의 복사본을 대상으로 감사 모드에서 배포합니다.
• 운영 — 오탐률이 허용 가능한 수준이면 승격합니다.

승격은 병합 과정에서 우연히 이루어지는 것이 아니라, 의도적으로 검토하며 규칙의 수명 주기 상태에 연결하는 단계입니다. 이러한 단계별 출시는 인라인 탐지에 사용하는 경고 후 차단 원칙과 동일합니다.

탐지가 코드이므로, 탐지 범위를 프로그래밍 방식으로 측정할 수 있습니다. 각 규칙을 MITRE ATT&CK 기법에 연결하고, 어떤 항목을 다루고 어떤 항목을 다루지 않는지 히트맵으로 생성할 수 있습니다.

시간에 따라 추적할 유용한 지표:

• 위협 모델의 전체 기법 대비 적용된 기법
• 규칙별 오탐률
• 규칙 아이디어가 운영 환경에 적용되기까지의 평균 시간
• 각 수명 주기 상태의 규칙 수

이 수치들을 통해 탐지 엔지니어링은 경험담이 아니라 체계적으로 관리되는 프로그램이 됩니다.

코드 기반 탐지의 기본 원리에 대한 이해도를 확인합니다.

코드 기반 탐지는 소프트웨어 엔지니어링의 엄격한 원칙을 탐지에 적용합니다:

• 규칙은 Git의 버전 관리되는 파일로 존재합니다
• 변경 사항은 병합 요청 검토를 거칩니다
• 지속적 통합이 린트 검사, 유효성 검사, 테스트 실행을 자동으로 수행합니다
• 병합된 규칙은 배포 흐름을 통해 배포되어 운영 환경을 주 브랜치와 동기화합니다
• 테스트가 오탐과 회귀를 방지합니다
• 이식성(Sigma + 처리 흐름)을 통해 하나의 규칙으로 여러 백엔드를 대상으로 할 수 있습니다
• 메타데이터, 수명 주기, 지표를 통해 탐지를 체계적으로 관리되는 프로그램으로 만들 수 있습니다

다음으로 Sigma를 사용하여 이식 가능한 규칙 자체를 작성합니다.