규칙 한 편을 여섯 번 고쳐 쓴다

목표

합성한 프로세스 실행 기록 24건을 놓고 Sigma 규칙을 여섯 편 씁니다. 매번 실제로
돌려 몇 건을 맞히고 몇 건을 놓쳤는지 숫자로 확인하면서 규칙을 좁혀 갑니다.

왜 중요한가

탐지 규칙이 현장에서 죽는 이유는 대개 문법이 아닙니다. 너무 넓어서 오탐이
쌓이면 사람들이 알림을 안 보게 되고, 너무 좁아서 주소 하나가 바뀌면 아무것도
못 잡습니다. 둘 사이를 찾는 유일한 방법은 자료에 돌려 보는 것입니다. 규칙을
쓰고 눈으로 읽어 "맞겠지" 하고 배포하는 습관이 탐지 공백의 가장 큰 원인입니다.

그래서 이 실습은 규칙을 쓸 때마다 사건 기록에 적용해 봅니다. 맞은 건과 잘못
잡은 건이 숫자로 나오면, "이 조건을 넣으면 무엇이 함께 들어오는가" 를 감이
아니라 관찰로 알게 됩니다. 이것이 탐지 엔지니어링이 보안 업무 중에서도 유난히
소프트웨어 공학을 닮은 이유입니다 — 규칙은 코드이고, 사건 기록은 시험 자료입니다.

단계

1. 사건 기록을 부모 프로세스별로 세어 /root/sigma/01-parents.txt 에 저장하세요.
2. cron 이 부모인 실행을 전부 잡는 최소 규칙을 /root/sigma/02-cron-any.yml 에 쓰세요.
3. 그중 명령줄에 curl 이나 wget 이 있는 것만 잡도록 좁혀 /root/sigma/03-outbound.yml 에 쓰세요. selection 은 하나만 씁니다.
4. 사내 저장소(repo.corp.internal)로 보내는 정상 백업을 필터로 덜어 내 /root/sigma/04-filtered.yml 에 쓰세요. condition 에 not 을 씁니다.
5. 주소를 쓰지 말고 행위로 잡는 규칙을 /root/sigma/05-behaviour.yml 에 쓰세요. 받아 온 것을 셸에 파이프로 넘기는 것과 셸을 붙여 바깥으로 연결하는 것, 두 가지입니다. |re 수식어를 반드시 씁니다.
6. 예약 작업의 외부 요청과 역방향 셸을 selection_ 으로 시작하는 두 선택으로 나누고 1 of selection_* 로 묶어 /root/sigma/06-combined.yml 에 쓰세요. 사내 저장소 필터는 공통으로 겁니다.
7. 6번 규칙에 배포용 메타데이터를 채워 /root/sigma/07-release.yml 에 쓰세요.
8. 3번과 7번 규칙의 판정 결과를 /root/sigma/08-review.md 에 숫자와 판단으로 적으세요.

참고

• 재료는 /opt/lab/fixtures/detection/proc_events.jsonl 이고 한 줄이 사건 하나입니다. jq -r '.ParentImage' <파일> 처럼 읽으세요.
• 규칙을 돌려 보는 도구가 함께 있습니다. python3 /opt/lab/fixtures/detection/sigma_eval.py --lint <규칙> 은 구조만 보고, --ids <규칙> <사건파일> 은 맞은 사건의 id 를 냅니다. --help 로 지원 범위를 확인하세요.
• 흔한 실수: |contains 로 짧은 낱말을 찾는 것. nc 는 rsync 안에도 들어 있습니다.
• 흔한 실수: selection 안에서 값을 리스트로 준 것을 AND 로 착각하는 것. 한 필드 안의 리스트는 OR 입니다.
• 6~7번의 진실 집합(실제 침해 4건)은 5번과 3번에서 본 것을 합치면 보입니다.

단계 8개

1. 자료부터 훑는다
2. 가장 작은 규칙
3. 바깥으로 나간 것만
4. 정상 하나를 덜어 낸다
5. 주소가 아니라 행위로
6. 두 갈래를 하나로
7. 배포할 수 있는 규칙으로
8. 숫자로 남긴다