이번 주는 "사후에 진실을 재구성하는 능력" — 감사 추적(audit trail)을 다뤘다. 네 개의 기둥을 세웠다: CloudTrail(활동: 누가 무엇을 했나), AWS Config(구성: 리소스가 각 시점에 어떤 상태였나), VPC Flow Logs·Resolver 쿼리 로그(네트워크: 어떤 트래픽·DNS가 흘렀나), 그리고 무결성·보존·중앙화(이 증거를 신뢰할 수 있게 보관하는 법). 오늘은 이 조각들이 하나의 침해 조사에서 어떻게 맞물리는지를 시나리오로 엮는다.
📚 사례: 침해 대응 업계에서 오래 인용되는 통계적 사실이 하나 있다. 침해가 실제로 발생한 시점과 그것이 발견된 시점 사이의 간격 — 이른바 체류 시간(dwell time) — 이 여전히 수십 일 단위라는 것이다. 그리고 발견의 계기가 조직 내부의 탐지가 아니라 외부 통보(고객, 수사기관, 보안 연구자)인 경우가 상당한 비율을 차지한다. 이 두 사실을 겹쳐 놓으면 감사 로그의 진짜 요구사항이 나온다. 발견은 몇 달 뒤에 일어나고, 그때 우리가 가진 것은 그동안 쌓인 로그뿐이다. 그래서 이번 주의 모든 설계 결정 — 데이터 이벤트를 미리 켜는 것, 보존 기간을 길게 잡는 것, 별도 계정에 격리하는 것 — 은 "오늘 유용한가"가 아니라 "석 달 뒤 아무 준비 없이 조사를 시작해야 할 때 유용한가"를 기준으로 판단해야 한다.