화이트보드 트리아지 세션: 로그 보기 전에 복잡한 인시던트를 침착하게 풀어내는 방법

인시던트는 깔끔한 퍼즐처럼 오지 않는다. Slack 알림, 어설픈 경보, 불안해하는 이해관계자, 어딘가 빠져 있는 정보 뭉치로 찾아온다. 이런 혼란 속에서 많은 팀이 가장 자연스러운—하지만 항상 가장 효과적인 것은 아닌—행동을 취한다. 모든 도구를 열고, 모든 로그를 tail 하고, 여기저기 마우스를 클릭하기 시작하는 것이다.

더 나은 첫 움직임이 있다. 모든 도구에서 한 발 떨어져 화이트보드 트리아지 세션부터 시작하는 것이다.

화이트보드 트리아지 세션은, 상세 로그 분석에 들어가기 전에 인시던트를 높은 수준에서 다시 구성(reconstruct) 하는 짧고 집중적인 협업 미팅이다. 리스크 기준으로 우선순위를 정하고, 시스템과 타임라인을 그리며, 가설을 정의하고, 누가 무엇을 할지 결정한다. 그 모든 걸, 본격적인 로그 분석에 들어가기 전에 마친다.

이 접근 방식은 단지 마음을 차분하게 해 줄 뿐 아니라, 더 안전하고 빠르게 대응할 수 있게 해 준다.

왜 로그보다 화이트보드가 먼저인가?

바로 로그로 파고드는 것은 겉보기엔 생산적으로 느껴지지만, 다음과 같은 단점이 있다.

• 영향이 거의 없는 노이즈를 쫓느라, 실제로는 고위험 인시던트가 계속 진행되도록 내버려둘 수 있다.
• 역할과 담당 구역이 불명확해 여러 사람이 같은 일을 중복해서 한다.
• 증상만 고치고 시스템적인 원인이나 숨어 있는 공격자를 놓칠 수 있다.

화이트보드 우선 트리아지는 목표를 “버그 찾기”에서 **“시스템 상태 이해하기”**로 바꾼다. 임베디드 시스템을 디버깅하는 것과 비슷하다. 하나의 명확한 루트 원인이 있다고 가정하는 대신, 이렇게 묻는다:

• 어떤 시스템들이 관련되어 있는가?
• 그 시스템들은 지금 어떤 상태일 가능성이 높은가?
• 서로 어떻게 상호작용하는가?
• 지금 이 순간, 가장 안 좋은 상황이 벌어지고 있다면 그건 무엇인가?

이런 정신 모델이 있으면 우선순위를 제대로 정하고, 리스크를 더 빨리 차단하며, 이후의 심층 분석이 훨씬 더 의미 있게 된다.

1단계: 처음부터 리스크 기반 우선순위를 적용하라

모든 인시던트가 동일한 중대성을 가지는 것은 아니다. 트리아지에는 구조화된 리스크 기반 우선순위 체계가 필요하다. 가장 위험하거나 시간에 민감한 이벤트를 먼저 처리하도록 만드는 장치다.

예를 들어, 다음과 같이 단순하고 명시적인 티어를 정의할 수 있다.

• Critical (P0) – 데이터 유출(Exfiltration) 진행 중, 다수 사용자에게 영향을 주는 프로덕션 장애, 안전·법적 리스크 노출 등
• High (P1) – Lateral Movement(횡적 이동) 의심, 권한 상승, 민감 시스템 성능 저하 등
• Medium (P2) – 이미 격리된 호스트 침해, 국지적 오류, 잠재적 오구성(Misconfiguration) 등
• Low (P3) – 노이즈, 무해한 설정 오류, 명백한 오탐(False Positive) 등

화이트보드 세션에서는 인시던트를 빠르게 분류한다.

1. Impact(영향도): 무엇이 영향을 받고 있는가? 데이터? 가용성(Uptime)? 안전? 매출?
2. Exposure(노출 범위): 공격자가 Lateral Movement를 하거나 권한을 더 올릴 수 있는가?
3. Time sensitivity(시간 민감도): 피해가 지금도 진행 중이거나 임박했는가?

목표는 완벽한 분류가 아니다. 무엇을 가장 먼저 해야 하는지 결정하는 것이다.

• 지금 네트워크 연결을 끊어야 하는가?
• 지금 바로 토큰을 모두 무효화해야 하는가?
• 리더십·법무팀을 지금 단계에서 참여시켜야 하는가?

이 리스크 렌즈 덕분에, 공격자가 핵심 시스템으로 조용히 이동하고 있는 동안 당신은 로그를 예쁘게 분류하는 데 한 시간을 쓰는 일을 막을 수 있다.

2단계: 인시던트를 높은 수준에서 재구성하라

대략적인 우선순위를 매겼다면, 지금 당장 대시보드로 Alt-Tab 하고 싶은 충동을 억제하라. 그 대신 모두의 시선을 실제 또는 가상의 화이트보드로 옮긴다.

기본이 되는 네 가지 축을 그린다.

1. Systems(시스템) – 어떤 컴포넌트가 관련되어 있는가?
   • 호스트, 서비스, 컨테이너
   • 데이터베이스, 외부 API, IdP(Identity Provider) 등
2. Timeline(타임라인) – 무엇이 일어났고, 우리는 그걸 언제 처음 인지했는가?
   • 알림 발생 시각, 사용자 신고 시점, 이상 징후 발생 시각 등
3. Actors(주체) – 누가 또는 무엇이 관련되어 있는가?
   • 사용자, 서비스 계정, 서드파티 벤더, 의심되는 공격자 등
4. Impact(영향) – 지금 이 순간, 실제로 무엇이 잘못되고 있는가?
   • 성능 저하, 수상한 로그인, 파일 암호화, 데이터 접근 등

여기에는 현재 알고 있는 것만 적는다. 그리고 각 내용을 다음 중 하나로 표시한다.

• Assumed(가정) – “아마 이럴 것이다” 수준으로 추측하지만, 아직 검증되지 않은 것
• Confirmed(확인됨) – 구체적 증거로 뒷받침되는 사실
• Unknown(미확인) – 중요해 보이지만 아직 답을 모르는 것

이 빠르고 시각적인 모델이 바로 지금의 작업 지도로 기능한다. 이것이 데이터를 마구 끌어오기 전에 어디를 봐야 할지, 어떤 질문이 중요한지를 정의해 준다.

3단계: 임베디드 시스템 디버거처럼 생각하라

임베디드 시스템을 디버깅할 때는, 하나의 명백한 버그가 있다고 가정하지 않는다. 대신 시스템 상태와 상호작용을 살핀다.

• 컴포넌트 A가 실패했을 때, A는 어떤 상태였는가?
• C가 타임아웃되거나 재부팅되면 어떤 일이 벌어지는가?
• 특정 조건에서 시스템 전체가 어떻게 동작하는가?

이 사고방식을 인시던트 트리아지에도 그대로 적용한다.

• **상태 전이(state transition)**를 그려본다:
  • “사용자 로그인” → “토큰 발급” → “서비스 접근” → “데이터 쓰기”
  • 이 과정 중 어디에서 문제가 발생할 수 있었는가?
• **인터페이스와 경계(boundary)**를 식별한다:
  • IdP, 방화벽, API 게이트웨이, 메시지 큐 등은 자연스러운 차단 지점이자 조사 타깃이다.
• 최근에 무엇이 바뀌었는지 묻는다:
  • 배포, 설정 변경, 신규 연동, 정책 업데이트 등

지저분한 로그 한 줄을 찾아 헤매는 대신, 시스템 전체가 어떻게 동작했는지, 인시던트가 어떻게 하나의 이야기로 설명될 수 있는지 이해하는 데 집중하는 것이다.

4단계: 안티 디버깅·회피(Evasion)까지 감안하라

공격자는 방어자가 어떻게 조사하는지 잘 알고 있다. 그래서 다음과 같은 행동을 자주 한다.

• 로그를 적극적으로 삭제하거나 빠르게 로테이션한다.
• 보안 에이전트나 EDR을 비활성화한다.
• Living-off-the-land(기존 시스템 도구 악용) 기법으로 정상 활동처럼 위장한다.
• 여러 개의 계정·아이덴티티로 활동을 분산시킨다.

“로그에 모든 것이 남아 있을 것이다”라는 전제 위에 모델을 세우면, 완전히 왜곡된 그림을 그리게 될 수 있다.

화이트보드 트리아지에서 다음을 명시적으로 질문하라.

• 이게 정말 무해한(benign) 이벤트라면, 우리는 무엇을 보게 될까?
• 이게 악의적인(malicious) 이벤트라면, 어떤 흔적이 있어야 하고, 그게 지금 보이지 않는가?
• 어떤 데이터 소스가 조작되었을 수 있는가? (엔드포인트 로그, 프로세스 리스트, 감사 로그 등)

이 질문들을 통해 다음과 같은 행동으로 이어질 수 있다.

• 독립적인 데이터 소스를 교차 검증한다. (예: 네트워크 텔레메트리 vs. 엔드포인트 로그)
• 갑작스러운 로그 공백을 단순 우연이 아니라 의미 있는 신호로 본다.
• 가능하다면 Out-of-band 검증(클라우드 제공자 로그, IdP 로그, 백업 등)을 활용한다.

애초에 시야가 부분적으로 가려져 있다고 가정하고 조사를 설계하면, 공격자의 안티 디버깅 트릭에 속을 가능성이 크게 줄어든다.

5단계: 차분하고 협력적인 커뮤니케이션을 운영하라

화이트보드 트리아지는 시스템만큼이나 사람에 관한 작업이다. 초기 15분 동안 어떤 톤을 세팅하느냐에 따라, 대응이 집중되고 효과적일지, 아니면 혼란스럽고 정치적이 될지가 결정된다.

다음과 같은 형태를 목표로 하라.

• 명확한 역할 정의

  • Incident Lead: 세션을 주도하고, 트레이드오프를 결정한다.
  • Scribe(기록 담당): 노트, 다이어그램, 의사결정을 기록한다.
  • Domain Experts: 시스템, 보안, 네트워크, 애플리케이션 담당 전문가.
  • Communications Owner: 이해관계자 커뮤니케이션을 책임진다.

• 공유된 어휘

  • “이건 가설입니다.”
  • “이건 X에 의해 확인된 사실입니다.”
  • “이건 Y를 검증할 때까지 가정입니다.”

• 심리적 안전감(Psychological Safety)

  • 트리아지 중에는 비난하지 않는다.
  • 누가 맥락을 공유할 때는 끼어들지 않는다.
  • 기초적인 질문이라도 언제든 환영한다.

이 방 안의 모든 사람이 다음을 알고 있는 상태를 만들어야 한다.

• 지금 무엇이 일어나고 있는지
• 앞으로 무엇이 일어날 수 있다고 우리가 생각하는지
• 앞으로 30–60분 동안 본인이 무엇을 책임지고 할 것인지

차분하고 명시적인 커뮤니케이션은 실수를 줄이고, 필요할 때 인시던트를 다른 팀에 넘기는 과정도 훨씬 수월하게 만든다.

6단계: 가정, 증거, 의사결정을 실시간으로 기록하라

화이트보드는 단순한 그림판이 아니라, 실시간 문서화 도구다.

세 가지 카테고리를 계속해서 기록하라.

1. Assumptions(가정)
   • “공격자의 최초 침투 경로는 피싱일 것으로 가정한다.”
   • “데이터베이스 백업은 침해되지 않았다고 가정한다.”
2. Evidence(증거)
   • “CloudTrail에서 10:14 UTC, 사용자 Y로 IP X에서 로그인한 기록이 보인다.”
   • “프로세스 리스트에서 10:09 UTC에 EDR 에이전트가 중지된 것이 확인된다.”
3. Decisions(의사결정)
   • “10:20 UTC: 사용자 Y 비활성화 및 테넌트 A 모든 API 키 롤테이션.”
   • “10:28 UTC: 방화벽에서 도메인 Z로의 아웃바운드 트래픽 차단.”

이게 왜 중요한가?

• 인수인계가 빨라진다: 새로 합류한 대응자는 화이트보드 로그만 읽어도 상황을 빠르게 파악할 수 있다.
• 사후 리뷰(Post-incident Review)가 좋아진다: 단순 행동 목록이 아니라, 그때그때의 사고 과정과 타임라인을 그대로 볼 수 있다.
• 편향이 눈에 보인다: 가정을 글로 적어두면, 그 가정이 잘못되었을 가능성도 더 쉽게 검증하고 도전해 볼 수 있다.

나중에는 이 내용을 기반으로 정식 인시던트 타임라인과 회고 문서를 만들 수 있다. 인시던트가 진행 중일 때는, 부담 없이 가볍게 그러나 끊임없이 업데이트하는 것이 중요하다.

7단계: 격리 후에는 루트 원인과 재발 방지에 파고들어라

피해 확산을 막고—공격이 차단되고 영향이 안정된 뒤—“이 정도면 됐다”라고 생각하며 넘어가고 싶어질 수 있다. 그렇게 하면 몇 달 후 똑같은 인시던트를 다시 겪게 된다.

루트 원인·재발 방지 중심의 리뷰를 반드시 일정으로 잡아라. 여기에는 다음이 포함되어야 한다.

1. 기술적 요인(Technical Factors)

• 실제로 무엇이 고장 났는가?
• 어떤 보안 통제가 인시던트를 탐지했거나, 탐지하지 못했는가?
• 우리가 이해하고 있던 시스템 모델과 실제 동작 사이에는 어떤 차이가 있었는가?

2. 절차적 요인(Procedural Factors)

• 기존 런북은 도움이 되었는가, 아니면 방해가 되었는가?
• 에스컬레이션 경로는 명확했는가?
• 적절한 사람과 도구를 충분히 빨리 모을 수 있었는가?

3. 인적 요인(Human Factors)

• 온콜(온콜러)들은 과부하 상태였거나, 충분히 트레이닝을 받지 못했는가?
• 커뮤니케이션이 끊어지거나 왜곡된 지점이 있었는가?
• 사람들에게 문제를 “조용히 패치”하고 넘어가도록 압박하는 인센티브는 없었는가?

이를 바탕으로 다음과 같은 구체적인 개선 사항을 정의하라.

• Identity·네트워크 세분화(Segmentation) 강화
• 로그 수집 범위와 무결성 강화
• 런북에 화이트보드 트리아지 플로우 추가
• Evasion·안티 디버깅 기법에 대한 교육 강화

비슷한 인시던트가 덜 발생하거나, 발생해도 피해가 훨씬 적어지도록 무언가가 실제로 바뀔 때까지, 인시던트는 끝난 것이 아니다.

종합: 모든 것을 하나로 엮기

잘 설계된 화이트보드 트리아지 세션은 보통 30–60분 안에 끝나며, 다음 패턴을 따른다.

1. 리스크 레벨을 지정하고, 즉각적인 안전 조치를 결정한다.
2. 시스템, 타임라인, 액터, 영향을 포함한 고수준 지도를 만든다.
3. 단일 버그가 아니라 시스템 상태와 상호작용 관점에서 인시던트를 바라본다.
4. **부분적 관측(Partial Observability)**을 전제로 하고, 공격자의 회피 기법을 감안한다.
5. 차분하고 명료한 커뮤니케이션과 명확한 역할을 유지한다.
6. 가정, 증거, 의사결정을 계속해서 기록한다.
7. 격리 이후에는 루트 원인·재발 방지 중심 리뷰를 진행하고, 실제 개선을 구현한다.

알람이 울리고 있을 때, 잠깐 멈추고 그림을 그리고 생각하는 이런 훈련은 처음에는 매우 반직관적으로 느껴질 수 있다. 그러나 시간이 지나면, 화이트보드 트리아지에 투자한 팀은 귀중한 것을 얻게 된다. 시스템에 대한 공유된 정신 모델, 더 차분한 인시던트 문화, 그리고 위기 상황에서 더 빠르고 신뢰할 수 있는 결과다.

다음에 인시던트가 터진다면, 로그 tail부터 시작하지 마라.

먼저 마커를 집어 들어라.