5. 결과 보고¶
"기록이 없으면 한 일이 아니고, 보고서가 없으면 작전도 없었다."
보고서는 작전의 유일한 증거이자 최종 산출물. 조직이 레드팀의 행동과 결과를 그대로 재현할 수 있어야 하고, 다음 작전을 설계하는 지도가 된다.
'발견 항목'이 아니라 '관찰'로 쓴다¶
- 취약점 점검·침투 테스트 보고서: 개별 발견 항목 + 수정 권고 목록
- 레드팀 보고서: 목표 달성 과정을 시간 순서로 서술한 관찰(observation) 중심의 이야기
기술적 결함 하나하나는 중요하지만 전체 흐름의 일부일 뿐이다. 예: 오래된 시스템 침투 → 원격 제어 확보 → 상황 파악 → 네트워크 이동 → 데이터 유출 — 이 연쇄 자체가 "공격자가 자유롭게 돌아다닐 수 있다"는 하나의 관찰이 된다.
공격 흐름 그림¶
복잡한 행동 연쇄는 그림 한 장이 가장 효과적이다. 행동·성공·실패를 한 장의 그림으로 표현 — 저자들은 긴 문서 대신 그림 하나로 브리핑을 하기도 한다.
위험도 평가 방식¶
기존 방식의 한계¶
영향도×발생가능성 3×3 또는 5×5 표는 개별 취약점 평가에는 맞지만, 이야기 형태의 관찰에는 안 맞는다 — "데이터를 얼마나 어떻게 빼냈는가"를 점 하나로 찍을 수 없다. 게다가 작성자 주관이 개입된다.
대안: 3단계 분류 (Chris Crowley)¶
위험도가 아니라 고치기 쉬운가를 기준으로 분류 — 바로 실행 가능한 개선 계획으로 이어진다.
| 단계 | 의미 | 시사점 |
|---|---|---|
| 1단계 | 고칠 수단이 이미 환경 안에 있는데 적용이 안 됨 | 가장 심각 — 노력 부족을 의미 |
| 2단계 | 수단은 있으나 정책·절차·정치·계약·교육 문제로 적용이 막힘 | 가장 흔함 — 정책 변경과 교육의 근거 |
| 3단계 | 업계 어디에도 바로 쓸 수 있는 해결책이 없음 | 추가 연구·검토 필요 |
조합해서 사용
관찰에는 3단계 분류를, 기술적 발견 항목에는 5×5 표를 부록에 쓸 수 있다. 분류는 레드팀과 조직이 함께 검토해야 한다 — 외부 팀은 그 조직의 사정을 모른다.
고통의 피라미드 (Pyramid of Pain)¶
권고사항이 공격자에게 끼치는 '고통'의 수준으로 효과를 표현한다. 해시·IP 같은 단순 지표 차단은 쉽게 우회되지만, 공격 기법 자체를 못 쓰게 만드는 통제는 공격자에게 가장 큰 고통을 준다 — 알려진 공격뿐 아니라 아직 모르는 제로데이 공격에도 먹힌다.
방어 권고 예시¶
공격자의 활동 능력을 직접 줄이는 통제들:
- 클라이언트 PC 간 통신 차단 (측면 이동 제한)
- 서버→클라이언트 방향 통신 차단
- 서버의 외부 통신 차단
- 메모리에 남는 관리자 자격 증명 정리
- KRBTGT 계정 짧은 간격으로 2회 초기화 + 관리자 비밀번호 전체 변경
- 민감 정보(비밀번호, 설정 파일, 지적재산) 정기 검색
- 불필요한 포트·프로토콜·서비스 비활성화
- 계정 분리 (일상 업무에는 상승 권한 불필요)
- Microsoft LAPS 도입 (로컬 관리자 비밀번호 개별화)
- 다중 인증(MFA)
- 애플리케이션 허용 목록(화이트리스팅) — 위 항목들이 먼저
공격 이야기 (Attack Narrative)¶
보고서의 본체. 작전의 실행 흐름을 시간 순서로 서술 — 공격 흐름 그림의 글 버전.
기록해야 할 관찰 유형¶
- 최초 침입부터 최종 목표까지 이어진 핵심 행동
- 각 단계에서 접근을 얻은 방법 (최초 침입, 측면 이동, 권한 상승)
- C2 설계 상세 — IP, 도메인, 포트, 프로토콜, 설치된 파일·지속성 수단
- 정찰·상황 파악에 쓴 기법과 얻은 정보
- 기술 외 관찰 — 사람·프로세스 관련 사항
- 작전과 직접 관련 없지만 우려되는 발견
개별 관찰의 구성¶
제목 → 상황 설명(이야기) → 기술 상세(출발지/대상 IP, 도구·기법, 결과·영향) → 스크린샷
블루팀 활용
보고서의 흔적(IOC) 목록은 작전 종료 후 블루팀의 사후 분석·위협 사냥의 출발점이 된다 — 탐지된 것과 탐지되지 않은 것을 비교해 사각지대를 찾고 탐지 도구를 개선한다.