Azure Sentinel 탐지 엔지니어링

제가 운영하는 실시간 Microsoft Sentinel 및 Defender XDR 환경에서의 탐지 엔지니어링입니다. 9개의 맞춤형 분석 규칙이 세 가지 플레인에 걸쳐 있으며, 각각 MITRE ATT&CK에 매핑되어 엔드투엔드로 검증되었습니다: 통제된 작업이 규칙을 트리거하고, 규칙이 인시던트를 생성하며, 인시던트가 조사·문서화됩니다. 7개는 Azure 컨트롤 플레인(AzureActivity)을 모니터링하며, 다단계 상관관계 규칙과 ARG 기반 콘텐츠 규칙을 포함합니다. 1개는 엔드포인트(Defender for Endpoint)를 모니터링하며 Defender Vulnerability Management가 헌팅 라이브러리에 데이터를 공급합니다. 1개는 ID(Entra ID SigninLogs)를 모니터링합니다. 모두 동일한 PR 게이트 파이프라인으로 배포됩니다.

제가 엔드투엔드로 운영하는 실시간 단일 테넌트 환경입니다. 모든 스크린샷에서 테넌트 및 구독 식별자와 모든 PII(개인 식별 정보)는 편집 처리되었습니다.

수치는 추적 가능합니다: 적용 범위는 ATT&CK 레이어, 검증은 RESULTS.md를 참조하세요. 의도적으로 오탐률 배지가 없습니다: 단일 테넌트 환경에서는 의미 있는 FP 비율을 산출할 수 없으므로, 이 저장소는 조작된 백분율 대신 실제 정상 배치에 대한 측정된 오탐 발생 건수를 보고합니다 (metrics.yaml에 전체 내용이 명시되어 있습니다).

빠른 시작

포크에서 탐지 단위 테스트를 실행하세요. Azure가 필요 없습니다. 각 규칙의 실제 KQL은 로컬 Kusto 에뮬레이터의 합성 픽스처에 대해 실행되므로 제 테넌트 없이도 탐지 로직을 검증할 수 있습니다:

git clone https://github.com/ibondarenko1/azure-sentinel-detection-engineering
cd azure-sentinel-detection-engineering
docker run -d --rm -p 8080:8080 -e ACCEPT_EULA=Y mcr.microsoft.com/azuredataexplorer/kustainer-linux:latest
pip install pyyaml
python tests/run-detection-tests.py

이것은 CI가 모든 풀 리퀘스트에서 실행하는 바로 그 검사입니다 (detection-tests): 각 규칙이 악성 픽스처에서는 탐지되고 정상 픽스처에서는 침묵을 유지하는지 검증합니다. validation/의 라이브 하네스는 더 나아가 테넌트에서 실제 정상 및 공격 배치를 구동하여 탐지 성공(TP)과 오탐 발생을 측정하지만, 여기에는 자체 Azure 구독과 az login이 필요하므로 (validation/README 참조) "로컬"이 아닙니다. 배포 파이프라인: docs/03. 규칙 기여: CONTRIBUTING.

존재 이유

탐지는 실제로 작동하는 모습을 보여줄 수 있을 때만 신뢰할 수 있습니다. 이 저장소는 Azure 컨트롤 플레인, 엔드포인트, ID라는 세 가지 플레인에서 그 루프를 완성합니다: 규칙 로직, 통제된 트리거, 생성된 인시던트, 조사, MITRE 매핑까지. 단일 이벤트 규칙을 넘어 다단계 상관관계(권한 부여 후 배포)와 Azure Resource Graph 포스처를 변경 이벤트에 결합하는 콘텐츠 인지 규칙을 제공합니다. 합성 샘플이 아닌 실제 텔레메트리를 대상으로 하는 Sentinel 분석 규칙, KQL, 인시던트 대응입니다.

Detection-as-Code

규칙은 포털에서 클릭으로 생성되는 방식이 아닙니다. 이 규칙들은 PR 게이트 파이프라인으로 배포되는 버전 관리된 YAML입니다. 탐지 규칙을 편집한다는 것은 풀 리퀘스트를 연다는 뜻입니다. CI가 검증하고, 리뷰어가 승인하며, main으로의 병합이 OIDC(저장된 비밀 없음) 를 통해 Sentinel에 규칙 GUID별로 멱등하게 배포합니다 (API 2025-09-01).

flowchart LR
  D[Edit rule YAML] --> PR[Pull request] --> V[CI validate] -->|review| M[Merge main] --> CD[OIDC deploy] --> S[Sentinel sc200-ws]

• 소스 오브 트루스: detections/rules/*.yaml · 파이프라인: .github/workflows/deploy-detections.yml · 배포자/검증기: cicd/ · 상세: docs/03-cicd.md

실제 변경 사항이 이 파이프라인을 통과했습니다: PR #1은 DET-001 임계값을 조정했습니다(10 → 8). CI가 검증했고, 병합이 라이브 sc200-ws 규칙에 배포했습니다. 리뷰된 PR을 통해 규칙이 git에서 자동으로 배포되는 이 단계가 바로 탐지 엔지니어를 교육 과정을 수료한 애널리스트와 구분 짓는 요소입니다.

아키텍처

flowchart LR
  subgraph Sources
    A[Microsoft Defender XDR<br/>Email · Endpoint]
    B[Azure subscription<br/>Activity Log]
    C[Entra ID<br/>sign-ins]
  end
  A --> W[Log Analytics workspace<br/>sc200-ws]
  B --> W
  C --> W
  W --> R[9 scheduled<br/>analytics rules]
  R --> I[Incidents]
  I --> V[Investigation<br/>+ MITRE mapping]

탐지 카탈로그

결과

각 탐지 규칙은 통제된 관리 작업(수행 후 자동으로 원상 복구되는)으로 트리거되어 실제 인시던트를 생성했습니다:

워크스페이스의 현재 운영 상태: 분석 규칙 10개 활성화, 데이터 커넥터 4개 활성, 자동화 규칙 1개, 실시간 데이터 유입. 활성화된 10개 규칙은 이 카탈로그의 맞춤형 [DET] 예약 규칙 9개에 Microsoft 기본 제공 Fusion 규칙(고급 다단계 공격 탐지)을 더한 것입니다. Fusion 규칙은 기본적으로 활성화되어 있으며 여기서 작성된 것이 아닙니다. 이 README의 다른 곳에 언급된 9개 수치는 맞춤형 규칙만 집계한 것입니다.

5건의 인시던트가 전체 조사 보고서로 작성되었습니다:

• INV-01, 대량 리소스 삭제 (높음)
• INV-02, RBAC 권한 상승
• INV-03, LSASS 자격 증명 액세스 (높음), 엔드포인트, 인시던트 #65
• INV-04, Any에서 인바운드로 열린 NSG (높음), ARG 콘텐츠 상관관계 (DET-009)
• INV-05, 권한 부여 후 배포 (높음), 다단계 상관관계 (DET-007)

일회성 트리거를 넘어, 검증 하네스는 테넌트에서 실제 정상 + 공격 배치를 구동하고 각 규칙의 KQL을 그 배치에 대해 실행하므로 오탐은 가정이 아니라 측정됩니다. 최신 실행 (결과): 공격 시나리오 5/5 탐지 성공 (DET-002/003/004/007/009), 정상 스트림에서 오탐 0건 (허용 목록에 등록된 소유자 배포, 임계값 미만 삭제, 권한 부여 없는 배포). 프로덕션 볼륨을 가장하지 않습니다. "N=1에서 FP 0%"라는 것을 실제 정상 배치에서 측정된 "오탐 0건"으로 전환합니다.

ATT&CK 적용 범위

명시적인 공백이 있는 적용 범위 맵은 규칙 목록보다 더 정직합니다. ATT&CK Navigator 레이어 (로드 방법)는 둘 다 보여줍니다:

공백은 정적인 텍스트가 아닙니다. 각 공백은 라이브 detection-gap 이슈이므로, 로드맵은 클릭 가능한 백로그입니다.

왜 다른 규칙이 아니라 이 규칙들인가: docs/08, 탐지 전략 및 위협 모델은 카탈로그를 클라우드 킬 체인에 매핑하고 공백의 위험 순위를 매깁니다. 규칙은 어떻게 튜닝되는가: docs/09, 측정 기반 DET-005 튜닝 루프는 "모든 쓰기에 즉시 탐지되는" 규칙을 검증 하네스에서 측정된 오탐 0건으로 이끕니다.

자동 대응 (SOAR)

최고 심각도 탐지는 탐지에서 대응까지의 루프를 완성합니다. Sentinel 자동화 규칙은 모든 DET-004(대량 삭제) 인시던트에서 Logic App 플레이북을 실행합니다: 권장 격리 조치(호출자 비활성화, 리소스 그룹 잠금, 복원, 헌팅)와 함께 보강 댓글을 게시합니다. 플레이북은 자체 관리 ID로 ARM API에 직접 인증하며, 비밀 없음, 외부 커넥터 없음.

두 번째 플레이북은 루프를 탐지 → 대응 → AI 조사로 확장하며 Microsoft Security Copilot을 사용합니다: 프롬프트북 + Logic App은 동일한 DET-004 인시던트에서 Copilot 프롬프트북을 호출하고 AI 조사 요약을 댓글로 게시합니다. 컴퓨트 유닛 없이 빌드 및 배포됩니다. 라이브 AI 요약 캡처는 단일 비용 제한(~$4) 유료 창에서 실행되며, 캡처되기 전까지는 주장하지 않습니다. 비용 및 해체 런북: docs/06.

엔드포인트 및 취약점 관리

탐지 규칙은 Azure 컨트롤 플레인에서 시작합니다. 이 단계는 엔드포인트 플레인을 추가합니다. Windows 호스트의 Defender for Endpoint 센서가 동일한 워크스페이스에 데이터를 공급하므로, Detection-as-Code 파이프라인이 컨트롤 플레인 규칙 옆에 엔드포인트 규칙인 DET-006 LSASS 자격 증명 액세스를 배포합니다. DET-006은 다중 소스 기반이며 실제 관찰 사례가 있습니다: 센서에 대해 세 가지 자격 증명 덤프 기법이 실행되었고, 강화된 호스트(LSASS RunAsPPL, AMSI, 동작 보호)가 모두 차단했으며, 규칙은 결과로 생성된 Defender 경고에서 탐지하여 인시던트를 생성했습니다 (INV-03). Defender Vulnerability Management는 두 번째 입력을 추가합니다: 노출된 소프트웨어별 중요 CVE, 실패한 보안 구성 기준, 활성 경고가 있는 취약 자산을 표면화하는 헌팅 라이브러리. DeviceTvm* 테이블은 Defender 고급 헌팅에만 존재하므로 이러한 상관관계는 배포된 규칙이 아닌 헌트이며, 저장소는 각 쿼리가 실제로 실행되는 위치를 명시합니다. 아키텍처 및 데이터 흐름: docs/07.

포스처 수정

탐지 규칙은 공격을 감시합니다. 이 단계는 테넌트 자체의 포스처 점수를 읽고 지적된 문제를 수정한 다음, 수치가 변했음을 입증합니다. Defender for Cloud Secure Score 기준선은 collect-posture.ps1에 의해 기계 판독 가능 스냅샷으로 수집되므로, 전후 비교는 스크린샷 비교가 아닌 파일 diff입니다. 기준선 시점의 점수는 68.81% (21.33 / 31)이며, 제어 항목별 분석에 따르면 전체 9.67점 차이는 4개 제어 항목(저장 데이터 암호화, 액세스 및 권한, 네트워크 액세스, 감사)에 집중되어 있습니다. 수정 작업은 폭발 반경 순으로 정렬되며 추가적(additive) 수정을 먼저 수행하고, 각 항목은 해당 회귀를 탐지하는 카탈로그 규칙에 매핑됩니다(스토리지 노출 → DET-002 / DET-009, RBAC 확산 → DET-003 / DET-007, 로깅 손실 → 전체 카탈로그). 이번 패스에서 3가지 수정이 적용되었고 리소스 수준에서 검증되었습니다: 보안 연락처 및 경고 알림, 두 SOAR 플레이북 모두의 진단 로깅(+1 감사), 센서 VM의 호스트 암호화(+4 저장 데이터 암호화). Defender for Cloud는 이후 24~72시간에 걸쳐 점수를 재평가하고 다시 계산하므로, 수정 후 점수는 지금 단언하지 않고 후속 항목으로 문서화합니다. 전체 방법, 순서화된 계획, 탐지 연계 테이블: docs/10, 포스처 수정.

SOC 2 통제 매핑

이 작업은 인정된 통제 프레임워크를 지원하므로, 저장소는 해당 위치를 명시합니다. 카탈로그의 각 부분은 SOC 2 Trust Services 기준에 매핑됩니다: 9개 규칙 카탈로그와 인시던트는 모니터링 및 대응 시리즈(CC7.2~CC7.4), SOAR 플레이북은 인시던트 대응(CC7.4), PR 게이트 Detection-as-Code 파이프라인은 변경 관리(CC8.1), 검증 하네스와 포스처 전후 비교는 통제 운영 효과성(CC4.1)에 매핑됩니다. 이는 컴플라이언스 주장이 아닌 매핑으로 구성됩니다: 감사받은 조직이 아니라 제가 운영하는 단일 테넌트이므로, 이 문서는 기술 통제 활동을 매핑하며 실제 SOC 2 보고서에 필요하지만 탐지 저장소에는 없는 거버넌스 래퍼에 대해 명시적으로 설명합니다. 기준별 전체 테이블과 감사에서 어떻게 읽히는지에 대한 메모: docs/11, SOC 2 통제 매핑.

저장소 구조

detections/rules  rule source-of-truth (Sentinel YAML, deployed by CI)
detections/*.md   one card per rule: logic, MITRE, trigger, evidence
detections/metrics.yaml  per-detection metrics (volume, FP rate, TP, MTTD)
tests/            synthetic-log unit tests (Kusto emulator, fork-runnable)
validation/       live mixed-activity harness: benign + attack streams, measured TP/FP
cicd/ + .github   Detection-as-Code pipeline (deploy, validate, regression)
sigma/            vendor-neutral Sigma conversions (portable to any SIEM)
kql/              analytics-rule queries + hunting library
investigations/   end-to-end incident write-ups
simulations/      exact atomic-aligned trigger steps
navigator/        ATT&CK coverage layer (covered + gaps)
posture/          Secure Score baseline collector + JSON snapshots + remediation script
playbooks/        SOAR response (Logic App + automation rule)
docs/             architecture, methodology, cicd, validation, data-dictionary, endpoint+TVM, detection-strategy, tuning case study, posture remediation, SOC 2 control mapping
screenshots/      visual evidence

입증된 기술

KQL · Microsoft Sentinel 예약 분석 규칙 · 다단계 상관관계 규칙 · Entra ID 신원 탐지 (SigninLogs) · 허용 목록 워치리스트 (_GetWatchlist) · Azure Resource Graph 포스처-애즈-콘텐츠 (예약 Action) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · 고급 헌팅 (Device / DeviceTvm 테이블) · Microsoft Secure Score · Defender for Cloud 포스처 수정 (CSPM, MCSB) · SOC 2 Common Criteria 통제 매핑 · Detection-as-Code (GitHub Actions, OIDC) · SOAR (Logic Apps 자동화 규칙) · Sigma (벤더 중립) · Atomic Red Team 검증 · 인시던트 트라이지 및 조사 · MITRE ATT&CK 매핑 · Azure 컨트롤 플레인 (Activity Log) 모니터링.

기여

이것은 개인 포트폴리오이지만, 탐지 변경이 포털 클릭이 아닌 리뷰 가능한 풀 리퀘스트가 되도록 구조화되어 있습니다. 포크하거나 규칙을 제안하려면 CONTRIBUTING.md에서 워크플로우를 확인하세요: 규칙 YAML 편집, KQL 미러 재생성, 테스트 픽스처 확장, 로컬에서 단위 테스트 실행, 동일한 CI 게이트가 검사하는 PR 열기.

자격

Microsoft Certified: Security Operations Analyst Associate (SC-200).

고지사항

제가 운영하는 환경으로, 어떤 고용주나 제3자의 프로덕션 테넌트가 아닙니다. 탐지 규칙은 제 리소스를 대상으로 한 통제된, 수행 후 자동 원상 복구되는 관리 작업으로 검증되었습니다. 프로덕션 시스템이나 제3자는 관련되어 있지 않습니다. 모든 스크린샷에서 테넌트 및 구독 식별자와 PII는 편집 처리되었습니다.

라이선스

MIT