Day 4 - 인시던트 대응 프레임워크: NIST 단계, 런북, 자동화 vs 사람 판단의 경계

지금까지(Day 1~3) 자동 대응 파이프라인, 침해 인스턴스 격리, 자격증명 회수라는 구체적 기술을 다뤘다. 오늘은 그것들을 묶는 프레임워크를 본다. 도구가 아무리 정교해도 언제 무엇을 누가 판단하는가의 체계가 없으면 사고 대응은 혼란에 빠진다. 인시던트 대응(IR, Incident Response)의 본질은 압박과 불확실성 속에서도 일관된 의사결정을 가능하게 하는 구조다. 시험은 NIST IR 단계의 정의, 각 단계에서 AWS 서비스의 역할, 그리고 무엇을 자동화하고 무엇을 사람에게 남길지의 경계 판단을 묻는다.

AWS는 자체 AWS Security Incident Response Guide에서 NIST SP 800-61의 IR 생명주기를 클라우드에 맞춰 채택한다. 이를 정확히 아는 것이 이 영역 시험의 토대다.

NIST IR 생명주기 4단계

[1. 준비] ──► [2. 탐지 및 분석] ──► [3. 봉쇄·근절·복구] ──► [4. 사후 활동]
   Preparation    Detection &           Containment,           Post-Incident
                  Analysis              Eradication,           Activity
                                        Recovery
        ▲                                                              │
        └──────────────── 교훈을 준비 단계로 환류 ──────────────────────┘

생명주기는 순환한다. 사후 활동의 교훈이 준비를 강화한다.

1. 준비 (Preparation)

사고가 나기 전에 대응 능력을 구축. 클라우드에서의 준비:

• 로깅·가시성 기반: CloudTrail(모든 계정·리전), VPC Flow Logs, GuardDuty/Security Hub/Config 활성화. 사고 후엔 늦다 — 로그가 없으면 분석 자체가 불가능.
• 격리·포렌식 인프라: 격리 보안 그룹·서브넷, 포렌식 계정·AMI, Object Lock 증거 버킷을 미리 준비.
• 권한·접근: IR 담당자의 break-glass 역할, 자동화 실행 역할(최소 권한).
• 런북·연락망: 시나리오별 런북, 에스컬레이션 경로, 권한 위임 정의.
• 훈련: game day / tabletop 연습.

2. 탐지 및 분석 (Detection & Analysis)

신호를 사고로 식별하고 범위·심각도를 판단:

• GuardDuty(위협), Security Hub(집계·정규화 ASFF), Config(구성 일탈), Macie(데이터 민감도), CloudTrail/Athena(조사).
• 결과를 분류(triage): true/false positive, 심각도, 영향 범위, 사고 등급(severity classification).

3. 봉쇄·근절·복구 (Containment, Eradication, Recovery)

• 봉쇄(Containment): 피해 확산 차단. 인스턴스 격리(Day 2), 자격증명 폐기(Day 3), 보안 그룹·NACL·SCP. 단기 봉쇄(즉시) vs 장기 봉쇄(임시 복구) 구분.
• 근절(Eradication): 위협 제거. 멀웨어·백도어 제거, 취약점 패치, 침해 리소스 폐기.
• 복구(Recovery): 정상 운영 복원. 패치된 골든 AMI 재배포, 백업 복원, 모니터링 강화하며 단계적 서비스 복귀.

4. 사후 활동 (Post-Incident Activity)

• 근본 원인 분석(root cause), 타임라인 재구성(CloudTrail), lessons learned 회의, 런북·통제 개선, 지표(MTTD/MTTR) 갱신.

💡 관련 이론: NIST가 근절(eradication)을 복구(recovery)와 분리한 이유는 깊다. 위협을 완전히 제거하지 않은 채 복구하면(예: 백도어를 남긴 채 인스턴스만 재시작) 재침해가 즉시 일어난다. 반대로 봉쇄 전에 근절을 시도하면 공격자가 탐지를 눈치채고 증거를 파괴하거나 더 깊이 숨는다. 순서(봉쇄→근절→복구)는 공격자의 행동 가능성을 최소화하는 게임이론적 설계다. SANS의 6단계 모델(Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned)도 본질적으로 동일한 논리다.

준비 단계를 구체적 산출물로 환산하면

"준비를 잘 하라"는 말은 시험에도 실무에도 쓸모가 없다. 준비 단계는 사고가 났을 때 존재하지 않으면 대응이 불가능한 것들의 목록이다. 아래 표의 오른쪽 열(없으면 무슨 일이 일어나는가)이 각 항목의 존재 이유다.

이 표에서 빠지기 쉬운 항목이 break-glass 역할이다. 페더레이션(IdP)으로만 접근하는 조직에서 IdP 자체가 침해되거나 장애가 나면, 정작 대응해야 할 사람이 계정에 들어갈 수 없다. 그래서 IdP와 독립적인 비상 경로를 하나 남기되, 그 경로를 쓰는 순간이 곧 알람이 되도록 만든다.

// break-glass 역할의 신뢰 정책: MFA와 소스 제한을 동시에 건다
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "900" },
      "IpAddress": { "aws:SourceIp": ["203.0.113.0/24"] }
    }
  }]
}

// break-glass 사용을 즉시 이벤트로 만든다 — 사용 자체가 알람이어야 한다
{
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["sts.amazonaws.com"],
    "eventName": ["AssumeRole"],
    "requestParameters": { "roleArn": ["arn:aws:iam::111122223333:role/BreakGlass-IR"] }
  }
}

사고 등급 분류: 무엇을 기준으로 나누는가

탐지·분석 단계의 실질은 등급 결정이다. 등급이 정해져야 누구를 부르고 어떤 런북을 돌릴지가 정해진다. 등급 기준을 조직이 미리 합의해 두지 않으면 매 사고마다 "이거 심각한 건가요"를 논의하느라 시간이 흐른다.

등급을 가르는 축은 "심각도 점수"가 아니라 세 가지 사실 질문이다. ① 데이터가 나갔는가(또는 나갔을 가능성이 있는가). ② 공격자가 지속성을 확보했는가. ③ 통제 평면(IAM·조직·로깅)이 건드려졌는가. 셋 중 하나라도 "예"면 등급은 올라간다. GuardDuty 심각도 5짜리 결과라도 그것이 CloudTrailLoggingDisabled 계열이라면 SEV-2 이상이다 — 점수는 낮지만 통제 평면이 흔들린 사건이기 때문이다.

봉쇄의 두 층: 단기 봉쇄와 장기 봉쇄

NIST가 봉쇄를 하나로 두지 않고 단기(short-term)와 장기(long-term)로 나누는 것도 시험 포인트다.

• 단기 봉쇄: 지금 이 순간의 출혈을 멈춘다. 격리 SG 교체, 키 비활성화, 세션 폐기. 서비스 영향을 감수하고서라도 확산을 막는다.
• 장기 봉쇄: 근절이 끝날 때까지 운영을 유지하면서 위협을 묶어 둔다. 침해 인스턴스를 격리한 채 정상 인스턴스로 트래픽을 옮기고, 임시 WAF 규칙으로 공격 패턴을 차단하고, 취약한 경로를 우회하는 임시 구성을 적용한다.

둘을 구분하지 않으면 "봉쇄했으니 이제 천천히 고치자"는 위험한 정체가 생기거나, 반대로 "서비스가 멈추니 봉쇄를 풀자"는 더 위험한 후퇴가 생긴다. 장기 봉쇄는 근절이 끝날 때까지 시간을 사는 구조물이고, 그 사이에 사람은 근본 원인을 찾는다.

런북(Runbook)과 플레이북(Playbook)

• 런북(Runbook): 특정 작업의 단계별 절차(예: "EC2 격리 런북" — 스냅샷→격리 SG→태깅). 자동화하기 좋음(SSM Automation Document).
• 플레이북(Playbook): 시나리오 전반의 의사결정 흐름(예: "랜섬웨어 대응 플레이북" — 어떤 조건에서 어떤 런북을 호출하고 누가 승인하는가).

좋은 런북의 속성:

• 결정론적: 같은 입력 → 같은 절차. 압박 속 판단 부담 감소.
• 멱등적: 중복 실행해도 안전.
• 감사 가능: 모든 단계가 기록.
• 테스트됨: game day로 검증.

# 사고 등급별 플레이북 골격 (의사 결정 흐름)
사고 탐지 (GuardDuty/Security Hub)
  ├─ 심각도 LOW  → 자동 티켓 생성, 영업시간 내 검토 (사람)
  ├─ 심각도 MED  → 자동 알림 + 영향 분석 (사람) → 필요 시 런북 수동 실행
  └─ 심각도 HIGH → 자동 봉쇄 런북 즉시 실행 (자동)
                   + 동시에 IR팀 호출 (사람)
                   + 고영향 조치(prod 종료 등)는 aws:approve 게이트 (사람 승인)

플레이북의 의사결정을 런북 안으로 끌어들이는 표준 수단이 aws:branch다. 같은 결과라도 대상의 태그에 따라 다른 경로로 가게 하면, "프로덕션은 승인 후 격리"라는 정책이 문서가 아니라 실행 가능한 구조가 된다.

schemaVersion: '0.3'
description: "환경 태그에 따라 자동 격리와 승인 게이트를 분기한다"
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  InstanceId:  { type: String }
  Environment: { type: String, default: "unknown" }
mainSteps:
  - name: preserveEvidence            # 어느 경로든 증거는 먼저
    action: aws:executeAwsApi
    onFailure: Continue
    inputs:
      Service: ec2
      Api: CreateSnapshots
      InstanceSpecification: { InstanceId: "{{ InstanceId }}" }
 
  - name: routeByEnvironment
    action: aws:branch
    inputs:
      Choices:
        - NextStep: requireApproval
          Variable: "{{ Environment }}"
          StringEquals: "prod"
      Default: isolateNow             # 비프로덕션은 즉시 격리
 
  - name: requireApproval             # 프로덕션 경로: 사람이 한 번 본다
    action: aws:approve
    timeoutSeconds: 3600
    onFailure: Abort
    inputs:
      Approvers: ["arn:aws:iam::111122223333:role/IR-Lead"]
      MinRequiredApprovals: 1
      Message: "프로덕션 인스턴스 {{ InstanceId }} 격리 승인 요청 (증거 스냅샷 완료)"
    nextStep: isolateNow
 
  - name: isolateNow
    action: aws:executeAwsApi
    onFailure: Abort
    inputs:
      Service: ec2
      Api: ModifyInstanceAttribute
      InstanceId: "{{ InstanceId }}"
      Groups: ["{{ IsolationSgId }}"]

여기서 설계 판단 하나가 중요하다. 증거 보존 단계는 분기 앞에 둔다. 승인 대기 중에 공격자가 디스크를 지우거나 인스턴스가 다른 이유로 종료될 수 있기 때문이다. 승인 게이트는 비가역 조치 앞에 두는 것이지, 가역적이고 무해한 조치 앞에 두는 것이 아니다. 스냅샷 생성은 되돌릴 필요조차 없는 순수 추가 행위이므로 승인 대상이 아니다.

승인이 여러 팀에 걸치거나 대기가 길어지면 SSM 런북 대신 Step Functions로 올린다.

[ Step Functions 기반 승인 워크플로우 ]

 결과 수신
    ▼
 [증거 보존]  ── 자동, 즉시
    ▼
 [단기 봉쇄]  ── 자동, 가역적(격리 SG · 세션 폐기)
    ▼
 [승인 대기]  ── Task(.waitForTaskToken)
    │  ├─ Slack/이메일로 토큰 포함 승인 링크 발송
    │  ├─ 승인 → SendTaskSuccess  → 다음 단계
    │  ├─ 거부 → SendTaskFailure  → 사람 경로로 전환
    │  └─ 타임아웃 → 에스컬레이션(상위 승인자 호출)
    ▼
 [비가역 조치] ── 종료·삭제·재배포
    ▼
 [사후 기록]  ── Security Hub Workflow.Status 갱신, 티켓 코멘트, 타임라인 적재

.waitForTaskToken의 가치는 타임아웃 경로가 명시적으로 존재한다는 데 있다. 승인자가 잠들어 있으면 어떻게 되는가 — 이 질문에 답이 없는 승인 게이트는 사고 때 대응을 멈춰 세우는 장치가 된다. 승인은 항상 상위 승인자 자동 호출 또는 기본 동작(보수적으로 봉쇄 유지)과 짝지어야 한다.

AWS는 이 조율 자체를 서비스로도 제공한다. Systems Manager Incident Manager는 대응 계획(response plan), 온콜 일정, 자동 호출(engagement), 사고 타임라인 기록, 런북 자동 실행을 묶어 준다. 시험에서 "결과 발생 시 온콜 담당자를 자동 호출하고 사고 타임라인을 기록하며 런북을 실행"이라는 문장이 나오면 이 서비스가 답이 된다 — EventBridge가 신호를 라우팅한다면, Incident Manager는 사람과 절차를 조율한다.

자동화 vs 사람 판단의 경계 (핵심)

이 단원의 정수는 무엇을 기계에, 무엇을 사람에게 맡기는가다. 잘못된 경계 설정은 두 방향으로 실패한다: 너무 자동화하면 false positive로 정상 서비스를 파괴하고, 너무 수동이면 대응이 느려 피해가 커진다.

graduated automation(단계적 자동화): 신뢰가 쌓일수록 사람→자동으로 이동.

1. 처음엔 알림만(human-in-the-loop) — 자동화 로직 검증.
2. 신뢰 쌓이면 가역적·저영향 조치 자동화(키 비활성화, 격리).
3. 고영향 조치는 승인 게이트(SSM aws:approve) — 자동 실행하되 사람이 한 번 승인.

# SSM Automation에 사람 승인 게이트 삽입
mainSteps:
  - name: snapshotAndIsolate     # 자동: 가역적 봉쇄
    action: aws:executeAutomation
    inputs: { DocumentName: IsolateInstance }
  - name: approveTermination     # 사람: 비가역 조치 전 승인
    action: aws:approve
    inputs:
      Approvers: ["arn:aws:iam::111122223333:role/IR-Lead"]
      Message: "프로덕션 인스턴스 i-xxx 종료 승인 요청"
  - name: terminate              # 자동: 승인 후 실행
    action: aws:executeAwsApi
    inputs: { Service: ec2, Api: TerminateInstances }

이것은 항공·원자력 등 고위험 산업의 automation paradox(자동화의 역설)다. 자동화가 늘수록 사람은 상황 인식(situational awareness)을 잃어, 정작 자동화가 실패하는 드문 순간에 개입할 능력이 떨어진다. 그래서 모범은 자동화가 무엇을 했는지 사람이 항상 볼 수 있게(SNS 알림, 대시보드) 하고, 고영향·비가역 결정에는 사람을 루프에 유지하는 것이다. 완전 자동화가 목표가 아니라, 사람의 판단을 가장 가치 있는 곳에 집중시키는 것이 목표다.

AWS 서비스의 IR 단계 매핑

Amazon Detective는 특히 분석·사후 단계에서 GuardDuty 결과의 맥락과 연관 관계(어떤 엔티티가 무엇과 통신했는가, 행동 기준선 대비 이상)를 그래프로 보여줘 근본 원인 분석을 돕는다.

IR 성숙도는 지표로 측정·개선된다. MTTD(평균 탐지 시간)·MTTR(평균 대응 시간)·dwell time(공격자 잠복 기간). 자동 대응(Day 1)은 MTTR을 극적으로 줄이고, 탐지 통제(GuardDuty/Security Hub)는 MTTD를 줄인다. 사후 단계에서 이 지표를 추적해 어느 단계가 병목인지 찾고 거기에 자동화·통제를 투자한다. 또한 IR은 법적·규제적 차원이 있다 — 증거 무결성(chain of custody, Day 2), 침해 통지 의무(GDPR 72시간 등), 규제 보고. 그래서 IR 계획에는 보안팀뿐 아니라 법무·홍보·경영진의 역할과 연락망이 포함된다. 기술적 봉쇄와 조직적 대응은 분리되지 않는다.

대응이 이뤄지는 계정 구조

IR 프레임워크는 조직도이자 계정 구조다. "누가 판단하는가"는 결국 "어느 계정의 어떤 역할이 그 API를 호출할 수 있는가"로 환원된다.

                     ┌──────────────────────────────┐
                     │  관리 계정 (Management)       │
                     │  · Organizations / SCP        │
                     │  · 조직 CloudTrail 생성        │
                     │  · 워크로드를 두지 않는다       │
                     └──────────────┬───────────────┘
                                    │ 위임
        ┌───────────────────────────┼───────────────────────────┐
        ▼                           ▼                           ▼
┌─────────────────┐      ┌────────────────────┐      ┌────────────────────┐
│ 로그 아카이브 계정 │      │ 보안(Security) 계정 │      │ 포렌식 계정          │
│ · CloudTrail 목적지│      │ · Security Hub 위임 │      │ · 증거 스냅샷 수신   │
│ · Object Lock    │◀─────│ · GuardDuty 위임    │─────▶│ · 격리 VPC·분석 EC2  │
│ · 쓰기 전용 접근   │ 조회 │ · EventBridge 허브  │ 공유 │ · 외부 공유 SCP 금지 │
└─────────────────┘      │ · IR 오케스트레이터  │      └────────────────────┘
                         └─────────┬──────────┘
                                   │ sts:AssumeRole (IR-RemediationRole)
        ┌──────────────────────────┼──────────────────────────┐
        ▼                          ▼                          ▼
   워크로드 계정 A            워크로드 계정 B             워크로드 계정 C
   (격리·스냅샷·세션 폐기가 실행되는 곳 — 권한은 최소, 비가역 조치는 Deny)

핵심: 증거(로그·스냅샷)는 침해될 수 있는 계정 밖에 있고,
      대응 권한은 침해될 수 있는 계정 안에 미리 심어 두되 최소로 좁힌다.

이 구조가 답하는 질문은 하나다 — 워크로드 계정이 완전히 장악당했을 때도 조사와 대응이 가능한가. 로그가 그 계정 안에만 있으면 답은 "아니오"다. 대응 역할이 사고 후에 만들어져야 한다면 답은 "아니오"다. 준비 단계의 항목들이 전부 이 한 질문에서 파생된다.

2017년 Equifax 침해는 NIST 4단계 중 준비와 탐지가 동시에 무너지면 무슨 일이 일어나는지 보여 주는 표준 사례다. 최초 진입은 널리 알려진 웹 프레임워크 취약점(Apache Struts)에 대한 패치 누락이었다. 여기까지는 흔한 이야기지만, 이 사건을 교재로 만든 것은 그다음이다 — 조직은 암호화된 네트워크 트래픽을 복호화해 검사하는 장비를 운영하고 있었는데, 그 장비의 인증서가 만료된 상태로 오랜 기간 방치돼 있었다. 그동안 나가는 트래픽은 검사되지 않았고, 공격자는 장기간 데이터를 반출했다. 인증서를 갱신하자 그제야 비정상 트래픽이 드러났다. 여기서 뽑을 교훈은 세 가지다. ① 탐지 통제는 "설치했다"가 아니라 "지금 이 순간 작동하고 있다"가 확인돼야 한다 — 만료·권한 부족·구성 오류로 조용히 죽은 통제는 통제가 없는 것보다 위험하다. 스스로 안전하다고 믿게 만들기 때문이다. ② 그래서 준비 단계에는 통제의 존재뿐 아니라 생존 확인(로그가 실제로 도착하는지, 규칙이 실제로 매칭되는지)이 포함돼야 한다. Day 1에서 FailedInvocations 알람과 샘플 결과 검증을 강조한 이유가 이것이다. ③ 자산 인벤토리와 패치 관리가 곧 IR의 일부다 — 무엇이 어디서 도는지 모르면 취약점 공지가 와도 어디를 고쳐야 할지 알 수 없다.

🎯 시나리오: 토요일 새벽, Security Hub에 CRITICAL 결과가 올라온다. 워크로드 계정 한 곳에서 조직 CloudTrail의 로깅이 중지됐고, 거의 같은 시각 새 IAM 사용자와 액세스 키가 생성됐으며, 평소 쓰지 않는 리전에서 대형 인스턴스가 기동됐다. 온콜 분석가가 처음 30분 동안 무엇을 어떤 순서로 하는가. → 먼저 등급을 정한다. 앞의 세 가지 사실 질문 중 ②(지속성 확보)와 ③(통제 평면 훼손)이 모두 "예"이므로 이 사고는 즉시 SEV-1이다. 심각도 점수를 다시 계산하며 시간을 쓰지 않는다. 그다음 순서는 이렇다. ① 로깅 복구가 최우선이다 — 로깅이 꺼진 동안의 행위는 영원히 알 수 없으므로, 지금 이후만이라도 기록되게 만든다. 동시에 로그 아카이브 계정에 이미 도착한 로그가 온전한지 확인한다(그래서 아카이브가 별도 계정이어야 한다). ② 자격증명 무력화: 새로 생성된 사용자·키를 비활성화하고, 그것을 만든 주체의 자격증명도 함께 무력화한다. 순서가 중요하다 — 만든 쪽을 먼저 끄지 않으면 공격자가 즉시 다른 사용자를 또 만든다. ③ 컴퓨트 격리: 미사용 리전의 인스턴스는 종료하지 말고 스냅샷 후 격리한다. ④ 에스컬레이션: SEV-1이므로 이 시점에 이미 보안 리더·법무 경로가 열려 있어야 한다. 데이터 접근 정황이 확인되면 통지 의무 시계가 돌기 시작하고, 그 판단은 분석가 혼자 할 수 있는 것이 아니다. ⑤ 조직 차원 차단: 관리 계정에서 SCP로 해당 OU의 로깅 중지·리전 확장을 봉쇄한다. 요점은 로깅 복구 → 자격증명 무력화(만든 쪽부터) → 컴퓨트 격리 → 조직 차단이며, 흔한 실수는 눈에 띄는 대형 인스턴스부터 종료해 증거와 단서를 동시에 없애는 것이다.

⚠️ 함정: IR 프레임워크에서 반복되는 세 가지 착각. ① "봉쇄했으니 사고는 끝났다" — 봉쇄는 출혈 정지일 뿐이고, 근절 없이 복구하면 재침해된다. NIST가 단계를 나눈 이유가 이 착각을 막기 위해서다. ② "자동화를 늘리면 대응이 좋아진다" — 자동화는 반복되는 판단을 대신할 뿐 새로운 판단을 대신하지 못한다. 오히려 자동화가 늘수록 사람의 상황 인식이 떨어져, 정작 자동화가 실패한 순간의 대응 능력이 낮아진다(자동화의 역설). 그래서 자동 조치는 반드시 사람에게 통보되어야 한다. ③ "런북을 문서로 써 뒀으니 준비됐다" — 실행해 본 적 없는 런북은 사고 때 반드시 실패한다. 참조하는 SG가 없거나, 역할 권한이 모자라거나, 파라미터 이름이 바뀌어 있다. 런북은 코드이며, 테스트되지 않은 코드는 동작하지 않는다. game day의 목적은 사람을 훈련시키는 것이 절반, 런북이 실제로 도는지 확인하는 것이 나머지 절반이다.

IR을 조직 차원에서 볼 때 반드시 짚어야 할 축이 책임 공유 모델이다. 인프라 계층(하이퍼바이저·물리 보안·관리형 서비스 내부)의 사고는 AWS가 대응하고, 고객 데이터·IAM 구성·게스트 OS·애플리케이션의 사고는 고객이 대응한다. 이 경계가 실제 사고에서 문제가 되는 지점은 "AWS에 연락해야 하는 상황"의 판단이다 — 계정 통제권을 완전히 잃었거나(루트 침해에 복구 채널까지 탈취), 우리 계정이 다른 곳을 공격하는 발신지가 되었거나(Abuse 신고 수신), AWS 측 조사 협조가 필요한 경우다. AWS에는 고객 사고를 지원하는 전담 조직(Customer Incident Response Team)이 있고, 사고 대응 준비·탐지·복구를 묶은 관리형 서비스도 제공된다. 실무적 결론은 연락 경로와 지원 플랜을 사고 전에 확인해 두라는 것이다 — 지원 플랜 등급에 따라 응답 시간이 달라지는데, 이것을 SEV-1 한복판에서 처음 알게 되는 조직이 놀랄 만큼 많다. 그리고 법적 축이 하나 더 있다. 침해 통지 의무는 관할·규제마다 기한이 다르고, 기한의 기산점은 대개 "인지 시점"이다. 즉 탐지가 빨라질수록 통지 시계도 빨리 돌기 시작한다 — 그래서 사고 등급 판정과 법무 통보 경로가 기술 대응과 같은 플레이북 안에 들어 있어야 한다.

함정 정리

• 준비 단계를 건너뛰고 사고 후에 로깅·격리 인프라를 만들려 한다 — 과거는 복원되지 않는다.
• 로그를 침해될 수 있는 계정 안에만 둔다 — 계정과 함께 증거가 사라진다.
• IR 대응 역할을 사고 이후에 배포하려 한다 — 침해 계정에 들어갈 수단이 없을 수 있다.
• break-glass 경로가 없어 IdP 침해·장애 시 아무도 계정에 들어가지 못한다.
• 사고 등급 기준을 미리 합의하지 않아 매 사고마다 심각도 논쟁으로 시간을 쓴다.
• 심각도 점수만 보고 통제 평면 훼손(로깅 중지·정책 변경)을 저등급으로 분류한다.
• 단기 봉쇄와 장기 봉쇄를 구분하지 않아 "봉쇄 후 정체" 또는 "서비스 때문에 봉쇄 해제"로 흐른다.
• 근절 없이 복구해 백도어로 재침해된다.
• 승인 게이트를 가역적·무해한 조치(스냅샷) 앞에 둬서 증거 확보가 지연된다.
• 승인 게이트에 타임아웃·에스컬레이션 경로가 없어 승인자가 응답하지 않으면 대응이 멈춘다.
• 자동화가 한 일을 사람에게 통보하지 않아 상황 인식이 사라진다(자동화의 역설).
• 실행해 본 적 없는 런북을 준비됐다고 믿는다 — 런북은 코드이며 테스트가 필요하다.
• 기술 봉쇄만 하고 법무·홍보·규제 통지 경로를 플레이북에 넣지 않는다.
• AWS 지원 플랜과 연락 경로를 사고 한복판에서 처음 확인한다.
• 사후 활동을 생략해 같은 사고가 반복된다 — 생명주기는 환류될 때만 순환이다.

정리

• NIST 4단계(준비→탐지·분석→봉쇄·근절·복구→사후)와 순환 구조를 이해했는가
• 준비 산출물 각각에 대해 "없으면 무슨 일이 일어나는가"를 답할 수 있는가
• 로그·증거가 침해될 수 있는 계정 밖에 있는가
• IR 대응 역할과 break-glass 역할을 사고 전에 배포하고 사용을 알람으로 만들었는가
• 사고 등급 기준(데이터 유출·지속성·통제 평면)을 미리 합의했는가
• 단기 봉쇄와 장기 봉쇄를 구분해 운영 유지 방안을 함께 설계했는가
• 승인 게이트를 비가역 조치 앞에만 두고, 타임아웃·에스컬레이션을 붙였는가
• 런북을 game day로 실제 실행해 검증했는가
• 준비 단계에서 로깅·격리 인프라·런북·break-glass를 사고 전에 갖췄는가
• 봉쇄→근절→복구 순서의 논리(재침해 방지·증거 보호)를 아는가
• 런북(작업 절차)과 플레이북(시나리오 의사결정)을 구분하는가
• 자동화/사람 경계를 명확성·가역성·영향 범위·속도로 판단하는가
• graduated automation으로 가역·저영향은 자동, 고영향은 승인 게이트(aws:approve)를 두는가
• 각 IR 단계에 맞는 AWS 서비스를 매핑할 수 있는가
• 사후 단계에서 MTTD/MTTR로 개선하고 법적·규제 의무를 반영하는가