침해 사고 대응 계획

보안 사고는 준비되지 않은 시각에 터집니다. 금요일 밤에 고객사에서 "우리 직원 계정으로 이상한 로그인이 찍혔다" 는 연락이 오고, 확인해 보니 관리자 화면에 낯선 접속 기록이 남아 있는 식입니다. 이때 계획이 없는 회사에서 가장 먼저 일어나는 일은 조사가 아니라 연락 돌리기입니다.

실제 장면은 이렇습니다. 처음 본 사람이 팀장에게 알리고, 팀장이 대표에게 묻고, 대표가 "일단 서비스를 내려야 하나" 를 되묻습니다. 서비스를 멈출 권한이 누구에게 있는지 정해 둔 적이 없으니 그 질문에 답할 사람이 없습니다. 한쪽에서는 고객에게 알려야 한다고 하고, 다른 쪽에서는 원인을 다 파악한 뒤에 알리자고 합니다. 그렇게 세 시간이 지나는 동안 공격자는 여전히 안에 있고, 법이 정한 통지 기한은 계속 줄어듭니다. 개인정보가 새어 나간 경우 며칠이 아니라 시간 단위로 기한이 걸리는 나라가 많습니다.

침해 사고 대응 계획은 이 논의를 사고 전으로 옮겨 놓은 문서입니다. 누가 결정하고 누가 알리고 언제까지 끝내는지를 평온한 날에 미리 적어 두면, 사고 당일에는 그 문서를 펴서 순서대로 실행하기만 하면 됩니다. 결정을 그때 하지 않는 것이 이 문서가 시간을 버는 방식입니다.

문서에는 최소한 여섯 가지가 들어갑니다. 어느 항목이든 사람 이름이나 숫자로 적히고, "신속히" 나 "관련 부서" 같은 말로 남지 않습니다.

1. 사고 판정 기준 — 무엇을 침해 사고로 볼지 정합니다. 직원 계정 하나가 뚫린 것과 고객 데이터베이스가 통째로 조회된 것은 다른 등급이고, 등급이 다음 항목 전부를 결정합니다.
2. 역할과 이름 — 상황을 지휘할 사람, 서비스를 멈출 권한을 가진 사람, 고객과 감독 기관에 알릴 사람, 언론 문의를 받을 사람을 이름으로 적습니다. 직책만 적으면 그 자리가 비어 있는 날에 문서가 멈춥니다. 자리마다 대리인을 한 명씩 더 적어 둡니다.
3. 대응 절차 — 탐지, 차단, 증거 보전, 복구, 재발 방지의 순서로 단계를 나누고 단계마다 할 일을 적습니다. 증거 보전이 차단과 복구 사이에 들어가는 이유는 서버를 급히 지우고 새로 올리면 무엇이 어떻게 뚫렸는지 알 방법이 함께 사라지기 때문입니다.
4. 통지 대상과 시한 — 고객, 감독 기관, 계약상 알려야 하는 기업 고객을 나누고 각각 몇 시간 안에 알릴지를 숫자로 적습니다. 보낼 문구의 초안도 함께 둡니다. 사고 당일에 처음부터 쓰면 검토에만 반나절이 걸립니다.
5. 연락망 — 담당자 연락처와 외부 보안 업체, 법률 자문의 번호를 한 곳에 모읍니다. 사내 시스템이 잠긴 상황을 가정해 종이나 별도 장소에도 둡니다.
6. 훈련과 갱신 — 몇 달에 한 번 모의로 돌려 보는지, 조직이 바뀌면 누가 문서를 고치는지를 적습니다.

앞 단계는 자산 목록에 기대어 돌아갑니다. 지켜야 할 시스템과 데이터가 한 표에 정리돼 있어야 사고 당일에 무엇이 영향을 받았는지 셀 수 있습니다. 목록에 없는 시스템은 조사 대상에서도 빠집니다.

쓰는 사람은 보안을 맡은 담당자입니다. 구성원이 수십 명인 회사에서는 전담자가 없어 개발 조직의 책임자가 겸하는 일이 흔합니다. 혼자 쓰지는 않습니다. 통지 기한과 문구는 법률 자문을 받아 정하고, 서비스를 멈출 권한처럼 사업에 영향을 주는 항목은 대표가 승인합니다. 보안 정책이 평소에 지킬 규칙을 적는다면 이 문서는 그 규칙이 뚫린 날을 맡습니다.

읽는 사람은 넷으로 나뉩니다. 첫째는 사고 당일의 대응자입니다. 새벽에 연락을 받은 사람이 한 화면 안에서 다음 행동을 찾을 수 있어야 하므로, 앞쪽에 연락망과 첫 30분에 할 일을 둡니다. 둘째는 경영진입니다. 서비스 중단과 고객 통지처럼 되돌리기 어려운 결정이 여기 적혀 있어서 사고 전에 읽고 동의해 둬야 합니다. 셋째는 고객사입니다. 기업 고객은 계약 전에 보안 검토를 하면서 이 문서를 요구하는 일이 잦습니다. 넷째는 보안 인증 심사원입니다. 문서가 있는지만이 아니라 최근에 갱신됐는지와 훈련 기록이 남아 있는지를 함께 봅니다.

"대응 계획에 통지 시한이 24시간으로 적혀 있는데 지금 열여덟 시간 지났습니다."

남은 여섯 시간 안에 통지 여부를 결정해야 한다는 신호입니다.

"이번 분기에 대응 계획 한 번 돌려 봅시다. 연락망부터 확인하고요."

문서를 실제 상황처럼 실행해 보고 낡은 부분을 찾자는 제안입니다.

"고객사 보안 검토에서 대응 계획 제출을 요구했어요."

계약을 따려면 이 문서가 있어야 하고 내용도 검토받는다는 뜻입니다.

페이지덱에서는 수아가 기업 고객과 계약을 앞두고 이 문서를 처음 요구받았습니다. 그때까지 페이지덱에는 대응 계획이 없었고, 규원과 태오가 이틀에 걸쳐 초안을 썼습니다. 쓰면서 막힌 곳은 대부분 권한이었습니다. 서비스를 멈출 결정을 누가 내리는지, 고객에게 먼저 알릴지 원인 파악을 먼저 할지가 정해져 있지 않았습니다.

반년 뒤 외주 개발자의 저장소 접근 권한이 남아 있던 것이 접근 권한 점검에서 드러났을 때, 실제 유출은 없었지만 문서를 그대로 한 번 돌려 봤습니다. 연락망의 번호 두 개가 이미 바뀌어 있었습니다.

문서를 만들어 두면 대응이 된다고 여기는 경우가 가장 많습니다. 심사에서도 문서 제출을 요구하니 만드는 일 자체가 목표처럼 보이기 때문입니다. 하지만 사고 당일에 펴 보는 문서는 연락처가 맞고 권한이 실제 조직과 일치할 때만 쓸모가 있습니다. 한 번 쓰고 2년 두면 적힌 사람의 절반이 퇴사해 있습니다. 피싱 모의 훈련처럼 주기적으로 돌려 보는 것을 함께 정해 두는 이유가 여기 있습니다.

보안팀만의 문서로 여기는 것도 흔합니다. 제목에 보안이 들어가니 자연스러운 오해입니다. 그런데 이 문서에서 가장 먼저 필요한 결정은 기술 판단이 아니라 서비스를 멈출지와 고객에게 언제 알릴지입니다. 둘 다 사업 결정이고, 승인 없이 적어 두면 사고 당일에 그 줄이 지켜지지 않습니다.