사고 대응

이미 터진 사고를 알아채고, 번지는 것을 막고, 서비스를 되돌리고, 배운 것을 남기는 일입니다. 사고가 있었다는 것이 전제입니다. 안 터지게 막아 두는 일과는 자리가 다릅니다.

상세

부엌에 불이 붙으면 왜 났는지부터 따지지 않습니다. 먼저 사람을 내보내고 불을 끕니다. 원인은 불이 꺼진 뒤에 봅니다.

미국 국립표준기술연구소(NIST)가 낸 SP 800-61 은 사고 대응을 보안 정책과 권고 관행의 위반을 교정하거나 완화하는 것이라고 적습니다. 같은 문서는 사고를 이렇게 적습니다. 적법한 권한 없이 정보나 정보 시스템의 무결성·기밀성·가용성을 실제로 또는 임박하게 위태롭게 하는 사건입니다. 법·보안 정책·보안 절차·허용 사용 정책의 위반이거나 위반의 임박한 위협인 사건도 여기 듭니다.

두 정의를 겹쳐 놓으면 이 표제어의 자리가 나옵니다. 사고 대응은 사고를 안 나게 하는 일이 아닙니다. 이미 난 사고를 놓고 하는 일입니다.

같은 문서는 사고 대응의 생애주기를 여섯 기능으로 그립니다. 통치(Govern)·식별(Identify)· 보호(Protect)·탐지(Detect)·대응(Respond)·복구(Recover)입니다. 여섯 기능 전부가 사고 대응에서 몫을 가집니다. 다만 앞의 셋이 하는 준비 활동은 사고 대응 자체의 일부가 아니라고 못 박습니다. 그 셋은 사고 대응을 떠받치는 더 넓은 보안 위험 관리 활동입니다. 사고 대응은 뒤의 셋입니다.

flowchart TD
    subgraph 준비["준비 — 사고 대응 자체는 아니다"]
        G[통치] --> I[식별] --> P[보호]
    end
    subgraph 대응["사고 대응"]
        D[탐지] --> R[대응] --> C[복구]
    end
    P --> D

같은 문서는 구판이 쓰던 네 단계 이름도 이 여섯 기능에 짝지어 함께 싣습니다. 준비, 탐지 및 분석, 봉쇄·근절 및 복구, 사후 활동입니다. 각 구간에서 실제로 무엇을 하는지는 그 이름을 단 항목들이 받습니다.

배경

사고는 안 나게만 할 수 없습니다. NIST 는 공격이 개인과 업무 데이터를 침해하는 일이 잦다고 적습니다. 보안 침해가 일어났을 때 곧바로 효과적으로 대응하는 것이 매우 중요하다고도 적습니다. 그래서 터진 뒤에 할 일을 미리 갖춰 두는 역량이 따로 필요해졌습니다. 같은 문서는 그 역량이 주는 것을 넷으로 적습니다.

• 일관된 사고 처리 방법론을 따라 체계적으로 대응하게 해 줍니다. 적절한 조치가 취해지도록 뒷받침한다는 뜻입니다.
• 사고가 일으킨 정보의 손실·도난과 서비스 중단을 줄이는 데 도움이 됩니다.
• 사고를 처리하며 얻은 정보를 다음 사고를 준비하는 데 씁니다. 시스템과 데이터를 더 단단히 지키는 데도 씁니다.
• 사고 중에 생길 수 있는 법적 문제를 제대로 다루는 데 도움이 됩니다.

이름은 한 사건 뒤에 붙었습니다. 카네기멜런대학 소프트웨어공학연구소가 낸 침해사고대응팀 핸드북은 1988년 인터넷 웜 사건으로 당시 네트워크에 붙어 있던 시스템의 상당수가 침해되고 일시적으로 서비스에서 내려갔다고 적습니다. 사건 직후 열린 회의는 인터넷 보안 문제의 단일 연락 창구를 세우자고 권고했습니다. 그 권고에 따라 CERT 조정센터(CERT Coordination Center)가 만들어졌습니다. 원래 이름은 컴퓨터 긴급 대응팀(Computer Emergency Response Team)이었습니다. 핸드북은 이것이 침해사고대응팀(CSIRT, computer security incident response team) 유형의 첫 조직 가운데 하나였다고 적습니다. 그 뒤로 전 세계에 수백 개의 침해사고대응팀이 생겼습니다.

말도 한 번 옮겨 갔습니다. 같은 핸드북은 초판을 낼 때만 해도 incident response 가 침해사고대응팀의 핵심 서비스를 가리키는 말이었다고 적습니다. 이런 팀에 대한 이해가 무르익으면서 사고 대응은 사건에 대한 대응만이 아닌 훨씬 넓은 incident handling 서비스의 한 구성 요소가 되었다고 적습니다.

예시

사고 지휘 체계를 빌려 온 자리

SRE(Site Reliability Engineering) 책은 Google 의 사고 관리 체계가 사고 지휘 체계(Incident Command System)를 바탕으로 한다고 적습니다. 그 체계가 명료함과 확장성으로 알려져 있다는 말이 함께 붙어 있습니다.

역할 몇 가지를 특정 개인에게 나눠 맡깁니다.

• 사고 지휘(Incident Command) — 사고의 상위 상태를 쥡니다. 대응 조직을 짜고 필요와 우선순위에 따라 책임을 배정합니다. 위임하지 않은 자리는 사실상 전부 지휘자가 쥡니다.
• 운영 작업(Operational Work) — 지휘자와 함께 운영 도구를 써서 손을 댑니다. SRE 책은 사고 중에 시스템을 고치는 것은 운영 팀 하나여야 한다고 적습니다.
• 소통(Communication) — 대응 조직의 대외 창구입니다. 대응 팀과 이해관계자에게 주기적으로 상황을 알리는 일이 몫이고, 대개 이메일로 합니다. 사고 문서를 정확하고 최신으로 유지하는 데까지 일이 넓어질 수도 있습니다.

우선순위도 한 줄로 적혀 있습니다. Prioritize. Stop the bleeding, restore service, and preserve the evidence for root-causing. 피를 멈추고, 서비스를 되돌리고, 원인 규명에 쓸 증거를 남기라는 순서입니다.

한 사고의 시각별 기록

SRE 워크북은 사고 하나를 시각과 함께 적어 두었습니다.

워크북은 두 번째 단계 뒤에 일반 완화책을 썼다면 여기서 매우 쓸모가 있었을 것이라고 적습니다. 대응한 사람들이 문제의 대략적인 위치를 알아낸 시점에 모든 이미지를 정상으로 알려진 상태로 되돌렸다면 사고가 오전 10시에 완화됐을 것이라고 적습니다.

경계

보안 침해를 다루는 것과 서비스 장애를 다루는 것은 서로 다른 일인가. 아닙니다. 어느 쪽에서나 알아채고, 번지는 것을 막고, 되돌리고, 배운 것을 남깁니다. 갈리는 것은 무엇을 먼저 지키느냐입니다. NIST 는 조직이 공격자를 샌드박스로 돌려 활동을 지켜보는 일이 있다고 적습니다. 대개 증거를 더 모으려는 목적입니다. 그러면서 이것이 봉쇄와 근절을 늦춘다고 적습니다. 의도한 지연은 위험할 수 있다고도 적습니다. 공격자가 권한 없는 접근을 키우거나 다른 시스템을 침해할 수 있기 때문입니다. 반대쪽 순서는 앞의 예시에 나온 한 줄입니다. 피를 멈추고 서비스를 되돌린 다음에 증거를 남깁니다. 같은 두 가지를 놓고 순서가 갈릴 뿐, 하는 일의 뜻이 갈리지는 않습니다.

터지기 전에 세워 두는 정책과 보호 장치도 사고 대응인가. 아닙니다. NIST 는 통치·식별·보호의 준비 활동이 사고 대응 자체의 일부가 아니라고 적습니다.

사고 관리는 같은 말인가. 아닙니다. 대응을 굴리는 체계 쪽에 붙은 이름입니다. 앞의 예시에서 본 Google 의 사고 관리 체계가 그 자리입니다. 그 체계를 어떻게 굴리는지는 그 이름을 단 항목이 받습니다.

사후 분석은 사고 대응 안에 드나. 듭니다. 대응의 마지막 구간입니다. 그 관행 자체를 어떻게 굴리는지는 그 이름을 단 항목의 몫입니다.

재해 복구도 같은 말인가. 아닙니다. 사고 대응이 다루는 범위 전체가 아니라 크게 잃은 뒤 되살리는 쪽에 목표를 걸어 둔 이름입니다. 무엇을 목표로 재는지는 그 이름을 단 항목이 받습니다.

관련 항목

사고를 알아채는 수단

탐지 · 모니터링 · 알림 · 온콜

사고 대응을 굴리는 체계

사고 관리 · 사고 지휘 체계 · 사고 지휘관 · 상황 전파 · 침해사고대응팀

되돌리는 수단

봉쇄 · 근절 · 복구 · 롤백 · 완화 · 재해 복구

사고 뒤에 남기는 기록

사후 분석 · 뿌리 원인 · 증거 보존

사고 대응을 재는 지표

복구 목표 시간 · 복구 시점 목표 · 평균 복구 시간 · 가용성