질문은 "뚫릴 것인가"가 아니라 "언제 뚫릴 것인가, 그리고 그때 얼마나 빨리 알아챌 것인가"입니다.
들어가며: 예방의 끝에서 시작하는 이야기
1부부터 4부까지, 우리는 예방에 집중했습니다. 공격면을 줄이고, 포트를 닫고, 인증을 강화하고, 통신을 암호화하고, 애플리케이션의 취약점을 막았습니다. 이 모든 예방은 필수적이고 강력합니다. 그러나 이 책의 두 번째 원칙은 처음부터 우리에게 불편한 진실을 말해 왔습니다. 침해를 가정하라.
왜 그래야 할까요? 2장에서 보았듯, 충분한 시간과 자금을 가진 공격자(APT) 앞에서 완벽한 예방은 존재하지 않기 때문입니다. 방어자는 모든 문을 지켜야 하지만 공격자는 하나의 열린 문만 찾으면 되는, 근본적으로 비대칭적인 싸움이기 때문입니다. 4장에서 보았듯 매주 새 취약점이 쏟아지고, 3장에서 보았듯 공격은 AI로 가속되며, 11장에서 보았듯 작은 실수 하나가 연쇄의 시작이 될 수 있기 때문입니다.
이것은 예방을 포기하라는 뜻이 결코 아닙니다. 예방은 침해의 확률과 빈도를 크게 낮춥니다. 침해를 가정하라는 것은, 예방을 다 한 뒤에도 "그럼에도 뚫렸다면"을 준비하라는 뜻입니다. 성숙한 보안은 예방과 대비를 함께 갖춥니다. 예방만 있고 대비가 없으면, 침해의 순간 속수무책이 됩니다. 그리고 침해는 일어나지 않을 일이 아니라, 언젠가 일어날 일입니다.
이 장에서는 침해를 가정한 방어를 다룹니다. 무엇을 기록하고 무엇을 감시할 것인가(로깅과 모니터링), 침해를 어떻게 빠르게 알아챌 것인가(탐지), 알아챘을 때 어떻게 할 것인가(대응), 그리고 최악의 경우에도 어떻게 회복할 것인가(백업과 복구)입니다. 특히 마지막 — 백업 — 은 랜섬웨어 시대에 가장 강력한 생존 전략이며, 이 장에서 비중 있게 다룹니다.
13.1 탐지의 중요성: 머무는 시간을 줄여라
침해를 가정할 때 가장 중요한 지표 하나가 있습니다. 공격자가 침입한 순간부터 발각되기까지의 시간 — 흔히 체류 시간(dwell time)이라 부르는 것입니다.
체류 시간이 뭔가요? 공격자가 시스템 안에 "발각되지 않고 머문" 기간입니다. 1일이면 가벼운 사고로 끝날 일이, 200일이면 데이터가 다 빠져나간 뒤일 수 있습니다. 침해의 피해 규모는 이 시간에 거의 비례합니다. 매년 침해 사고를 통계로 정리하는 Verizon 데이터 침해 조사 보고서(DBIR)가 해마다 보여 주는 것 중 하나가, 외부(고객·결제사·수사기관)가 먼저 알려 줘서 침해를 알게 되는 경우가 여전히 많다는 사실입니다 — 즉 스스로 탐지하지 못하고 있었다는 뜻입니다.
왜 체류 시간이 결정적인가
2장에서 APT가 "들키지 않고 오래 머무는 것"을 목표로 한다고 했습니다. 그 이유는 명확합니다. 공격자가 시스템 안에 머무는 시간이 길수록, 더 많은 데이터를 빼내고, 더 깊이 침투하고, 더 많은 피해를 입힐 수 있기 때문입니다. 반대로 침입을 빠르게 탐지하면, 공격자가 목표를 달성하기 전에 차단할 수 있습니다.
현실의 침해 사고에서 가장 뼈아픈 패턴 중 하나가, 침입이 수개월, 때로는 수년간 탐지되지 않은 채 진행되었다는 것입니다. 공격자가 오래전부터 내부에 있었는데 아무도 몰랐고, 피해가 다 일어난 뒤에야, 또는 외부에서 알려 주어서야 비로소 알게 되는 경우입니다. 이것은 예방의 실패라기보다 탐지의 실패입니다.
현장에서 사고를 분석해 보면, 침입의 입구는 대개 거창하지 않습니다. 4장에서 본 MOVEit Transfer(CVE-2023-34362)처럼 패치가 나와 있는 n-day로 조용히 들어와, 한참 뒤 데이터가 외부에 풀리고 나서야 발각된 경우가 적지 않습니다. 입구를 다 막지 못하더라도, 들어온 흔적을 빨리 보는 것 — 그것이 이 장 전체의 목표입니다.
그래서 침해를 가정하는 방어에서, 탐지 능력은 예방 능력만큼 중요합니다. 뚫리는 것을 완전히 막을 수 없다면, 적어도 뚫렸을 때 빨리 알아채야 합니다. 빠른 탐지가 피해를 결정합니다.
탐지의 전제: 보이지 않으면 탐지할 수 없다
탐지의 전제는 가시성(visibility)입니다. 시스템에서 무슨 일이 일어나고 있는지를 볼 수 없으면, 이상한 일이 일어나도 알 수 없습니다. 5장에서 "보이지 않는 것은 지킬 수 없다"고 했듯, 여기서는 "기록되지 않는 것은 탐지할 수 없다"가 됩니다. 그래서 탐지의 첫걸음은 적절한 로깅입니다.
13.2 로깅: 무엇을 기록할 것인가
로깅은 시스템에서 일어나는 일들을 기록으로 남기는 것입니다. 좋은 로깅은 탐지의 토대이자, 침해 후 무슨 일이 있었는지를 재구성하는 단서이며, 책임 추적의 근거입니다.
무엇을 기록해야 하는가
모든 것을 기록할 수도 없고 그럴 필요도 없습니다. 핵심은 보안상 의미 있는 사건을 기록하는 것입니다. 일반적으로 다음과 같은 것들이 중요합니다.
인증 관련 사건. 누가 언제 로그인했는지, 로그인 실패는 없었는지. 1장에서 본 SSH 무차별 대입의 흔적이 여기 남습니다(리눅스라면 보통 /var/log/auth.log 또는 journalctl -u ssh). 성공한 로그인뿐 아니라 실패한 시도, 특히 비정상적인 패턴의 실패가 중요합니다. 7장에서 다룬 fail2ban이 바로 이 인증 로그를 읽어 반복 실패 IP를 자동 차단하는데, 같은 로그를 사람이 가끔 들여다보는 것만으로도 "어제 새벽 낯선 나라에서 관리자 계정으로 수백 번 시도가 있었다"는 신호를 잡을 수 있습니다.
권한 관련 사건. 권한 상승, 관리 작업, 중요한 설정 변경 등. 11장에서 본 권한 상승의 흔적을 포착할 수 있습니다. 누가 언제 어떤 권한 작업을 했는지를 기록하면, 정상적이지 않은 권한 사용을 탐지할 수 있습니다.
접근 관련 사건. 중요한 자원에 대한 접근, 특히 민감한 데이터에 대한 접근. 12장에서 본 접근 제어와 연결되며, 비정상적인 데이터 접근 패턴을 포착할 수 있습니다.
애플리케이션 사건. 웹 애플리케이션의 중요한 동작, 오류, 비정상적 요청. 11장과 12장에서 본 공격 시도의 흔적이 여기 남습니다.
시스템 사건. 서비스의 시작과 종료, 시스템 수준의 중요한 변화. 공격자가 무언가를 설치하거나 변경한 흔적을 포착할 수 있습니다.
좋은 로그의 조건
기록하는 것만으로는 부족합니다. 로그가 유용하려면 몇 가지 조건을 갖춰야 합니다.
충분한 맥락. 각 로그 항목은 "언제, 누가/무엇이, 무엇을, 어디서" 했는지를 충분히 담아야 합니다. 맥락이 부족한 로그는 나중에 해석할 수 없습니다.
민감 정보의 보호. 역설적이지만, 로그 자체가 민감 정보를 담아 위험이 될 수 있습니다. 비밀번호, 키, 개인정보 등이 로그에 그대로 기록되면, 로그가 유출될 때 그것들도 함께 유출됩니다. 로그에 민감 정보가 들어가지 않도록 주의해야 합니다.
로그의 무결성. 11장에서 공격자가 "흔적을 정리한다"고 했습니다. 공격자는 자신의 침입 흔적이 담긴 로그를 지우거나 변조하려 합니다. 이것은 즉흥적인 행동이 아니라, 공격자 행동을 체계적으로 정리한 MITRE ATT&CK에 "흔적 제거(Indicator Removal)"라는 이름으로 분류돼 있을 만큼 정형화된 단계입니다. 그래서 로그는 공격자가 쉽게 손댈 수 없는 곳에 보관되어야 합니다. 로그를 생성하는 시스템과 분리된 곳, 또는 변조하기 어려운 형태로 보관하면, 공격자가 흔적을 지우기 어려워집니다. 이것은 침해 후 재구성에도 결정적입니다.
그래서 지금 뭘 하면 되나. 1인 운영이라도 한 가지만 먼저 하십시오 — 웹 서버·인증 로그를 운영 서버 바깥으로 한 벌 복사해 두는 것. 다른 호스팅의 저장소든, 권한이 분리된 객체 스토리지든, 운영 시스템을 장악한 공격자의 손이 그 사본에 닿지 않으면 됩니다. 침해를 알아챈 순간, 변조되지 않은 그 사본 한 벌이 "무슨 일이 있었는지"를 재구성하는 거의 유일한 단서가 됩니다.
보존 기간. 앞서 보았듯 침해가 오랫동안 탐지되지 않을 수 있으므로, 로그는 충분히 오래 보존되어야 합니다. 침해를 뒤늦게 알았을 때, 그 시작점까지 거슬러 올라갈 수 있어야 하기 때문입니다.
13.3 모니터링과 탐지: 로그를 살아 있게 만들기
로그를 남기는 것은 시작일 뿐입니다. 13.1에서 강조했듯, 그것을 읽고 이상을 알아채야 의미가 있습니다. 그런데 사람이 매일 수만, 수십만 줄의 로그를 일일이 읽을 수는 없습니다. 여기서 모니터링과 탐지가 필요합니다.
무엇을 감시할 것인가
모니터링의 핵심은, 수많은 로그 중에서 주의가 필요한 것을 골라내는 것입니다. 무엇이 "주의가 필요한 것"일까요?
알려진 공격 패턴. 이미 알려진 공격의 서명이나 패턴이 나타나는지를 감시합니다. 11장과 12장에서 본 공격 시도들이 여기에 해당합니다.
이상 징후. 평소와 다른 패턴이 나타나는지를 감시합니다. 비정상적인 시간대의 접근, 평소와 다른 위치에서의 로그인, 갑작스러운 대량 데이터 접근, 비정상적인 권한 사용 등입니다. "정상"이 무엇인지를 알아야 "비정상"을 알아챌 수 있으므로, 평소의 정상 패턴을 파악해 두는 것이 도움이 됩니다.
무결성 변화. 변하지 않아야 할 것이 변했는지를 감시합니다. 중요한 시스템 파일, 설정 파일, 웹 콘텐츠 등이 예상치 못하게 변경되면, 그것은 침해의 신호일 수 있습니다. 파일 무결성 모니터링은 공격자가 무언가를 설치하거나 변조한 것을 포착하는 강력한 방법입니다.
예상치 못한 변화. 5장에서 다룬 것과도 연결됩니다. 새로운 포트가 열리거나, 새로운 프로세스가 실행되거나, 새로운 사용자가 추가되는 등, 예상치 못한 변화는 그 자체로 점검할 신호입니다.
알림: 무엇을 사람에게 알릴 것인가
모니터링의 어려움 중 하나는 균형입니다. 너무 많은 것을 알리면, 알림이 홍수가 되어 사람이 둔감해지고 정작 중요한 것을 놓칩니다(경보 피로). 너무 적게 알리면, 중요한 것을 놓칩니다. 그래서 정말 주의가 필요한 것만 사람에게 알리고, 나머지는 기록만 하되 필요시 조회할 수 있게 하는 균형이 필요합니다.
좋은 접근은 심각도에 따라 차등을 두는 것입니다. 즉각적인 대응이 필요한 것은 즉시 알리고, 검토가 필요하지만 급하지 않은 것은 정기 요약으로 전달하며, 단순 기록은 조회 가능한 형태로 보관하는 것입니다.
자동화와 AI의 역할
부록 E의 영역 3에서 다뤘듯, 로그 분석과 이상 탐지는 자동화와 AI가 도울 수 있는 영역입니다. 대량의 로그에서 이상 패턴을 1차 분류하고, 사람이 검토해야 할 것을 추려 주는 데 활용할 수 있습니다. 다만 부록 E의 한계선을 기억하십시오. 로그에는 민감 정보가 포함될 수 있으므로 외부로 보낼 때 신중해야 하고, AI의 1차 분류는 사람의 판단을 보조하는 것이지 대체하는 것이 아닙니다. 자동화는 사람이 모든 로그를 읽는 불가능한 일을 가능하게 해 주지만, 최종 판단은 사람의 몫입니다.
13.4 침해 사고 대응: 알아챈 다음에 무엇을 하는가
탐지가 침해를 알아채는 것이라면, 사고 대응(incident response, IR)은 알아챈 다음에 하는 일입니다. 침해의 순간은 혼란스럽고 압박이 큽니다. 그 순간에 무엇을 해야 할지 미리 준비되어 있지 않으면, 당황 속에서 잘못된 결정을 내리기 쉽습니다.
IR 자료, 어디서 보나. "전담 보안팀이 없으면 IR은 불가능한 것 아닌가" 싶겠지만, 작은 조직이 따라 할 수 있는 무료 기본 절차가 공개돼 있습니다. 미국 CISA는 사고 대응의 단계별 가이드와 점검표를 무료로 제공합니다. 지금 사고가 난 게 아니어도, 한 번 훑어보고 우리 상황에 맞게 한 페이지짜리 "첫 대응 메모"로 줄여 두는 것만으로 충분합니다.
미리 준비하라
사고 대응의 가장 중요한 원칙은, 사고가 나기 전에 준비하는 것입니다. 불이 난 뒤에 소화기가 어디 있는지 찾으면 늦습니다. 침해가 일어난 뒤에 "이제 뭘 해야 하지?"를 고민하면 늦습니다.
미리 준비해야 할 것들은 다음과 같습니다. 침해가 의심될 때 누가 무엇을 하는지에 대한 기본 계획, 중요한 연락처와 의사결정 경로, 대응에 필요한 자원과 접근 권한, 그리고 무엇보다 13.5에서 다룰 검증된 백업입니다. 1인 운영이라도, 최소한 "침해를 발견하면 첫 단계로 무엇을 할 것인가"를 미리 생각해 두는 것이 도움이 됩니다.
대응의 기본 흐름
사고 대응은 대략 다음 흐름을 따릅니다. 이것은 구체적 절차라기보다 사고의 틀입니다.
확인과 분류. 먼저 정말 침해인지, 어느 정도 심각한지를 파악합니다. 거짓 경보일 수도 있고, 사소한 것일 수도, 심각한 것일 수도 있습니다. 성급한 판단도 위험하지만, 의심을 가볍게 넘기는 것도 위험합니다.
격리와 차단. 침해가 확인되면, 피해의 확산을 막는 것이 우선입니다. 11장에서 본 측면 이동과 13.1의 체류 시간을 떠올리십시오. 공격자가 더 퍼지거나 더 머무는 것을 차단해야 합니다. 영향받은 시스템을 격리하고, 공격자의 접근 경로를 차단합니다. 다만 이 과정에서 신중함이 필요합니다. 성급하게 모든 것을 끄면, 침해의 증거가 사라지거나 공격자가 눈치채고 더 파괴적으로 행동할 수 있습니다.
증거 보전. 무슨 일이 일어났는지를 이해하고, 필요시 법적 대응이나 신고를 위해, 증거를 보전하는 것이 중요합니다. 13.2에서 강조한 로그의 무결성이 여기서 빛을 발합니다. 침해의 흔적을 성급히 지우지 말고, 무슨 일이 있었는지 재구성할 수 있도록 보전하십시오.
제거와 복구. 공격자의 흔적과 침입 수단(백도어 등)을 제거하고, 시스템을 안전한 상태로 복구합니다. 여기서 13.5의 백업이 결정적 역할을 합니다. 다만 단순히 백업으로 되돌리는 것만으로는 부족할 수 있습니다. 애초에 침입을 허용한 취약점을 함께 고치지 않으면, 같은 방법으로 다시 뚫리기 때문입니다.
교훈과 개선. 사고가 수습된 뒤, 무엇이 왜 일어났는지, 어떻게 막을 수 있었는지, 무엇을 개선해야 하는지를 정리합니다. 이것은 원칙 5(과정으로서의 보안)의 적용입니다. 모든 사고는 고통스럽지만, 동시에 방어를 개선할 교훈을 줍니다.
신고와 법적 의무
침해, 특히 개인정보가 관련된 침해의 경우, 법적인 신고 의무가 있을 수 있습니다. 한국을 비롯한 많은 국가가 일정 규모 이상의 개인정보 유출 사고에 대해 당국과 정보 주체에게 신고하도록 규정하고 있습니다. 국내에서는 KISA 보호나라가 침해사고 신고 창구와 대응 안내를 운영하므로, 신고처와 절차를 여기서 미리 확인해 둘 수 있습니다. 자신에게 적용되는 법적 의무를 미리 파악해 두는 것이, 사고의 순간에 추가적인 법적 문제를 피하는 길입니다. 다만 구체적인 법적 의무는 상황과 관할에 따라 다르므로, 필요시 전문가의 조언을 구하십시오.
13.5 백업과 복구: 랜섬웨어 시대의 생존 전략
이제 이 장에서 가장 실용적이고, 어쩌면 가장 중요한 부분에 도달했습니다. 백업입니다. 2장에서 랜섬웨어를 다루며, 그것에 대한 가장 강력한 방어가 역설적으로 침입을 막는 것이 아니라 백업이라고 했습니다. 그 이유와 방법을 여기서 자세히 다룹니다.
왜 백업이 최강의 방어인가
2장에서 본 랜섬웨어를 떠올리십시오. 랜섬웨어는 데이터를 암호화하여 사용할 수 없게 만든 뒤 몸값을 요구합니다. 공격자의 협박이 효과를 갖는 것은, 피해자가 그 데이터를 잃을 수 없기 때문입니다. 그런데 만약 피해자가 깨끗한 백업을 가지고 있어서, 암호화된 데이터를 버리고 백업에서 복구할 수 있다면? 몸값을 지불할 이유가 사라집니다. 협박의 힘이 무너집니다.
이것이 백업이 랜섬웨어에 대한 최강의 방어인 이유입니다. 백업은 침입을 막지는 못하지만, 침입의 가장 큰 무기 — 데이터를 인질로 잡는 것 — 를 무력화합니다. 이것이 침해를 가정하는 원칙 2의 가장 구체적인 실천입니다. "뚫릴 수 있다. 하지만 뚫려도 데이터는 잃지 않는다."
백업은 랜섬웨어뿐 아니라 모든 종류의 데이터 손실 — 하드웨어 고장, 실수로 인한 삭제, 자연재해, 11장의 파괴적 공격 — 에 대한 보험입니다. 모든 방어 중에서, 백업만큼 적은 노력으로 큰 회복력을 주는 것은 드뭅니다.
3-2-1 규칙
백업의 고전적이고 검증된 원칙이 3-2-1 규칙입니다. 그 의미는 다음과 같습니다.
3 — 중요한 데이터는 최소 세 벌의 사본을 유지합니다. 원본 하나와 백업 둘입니다. 사본이 많을수록, 모든 사본이 동시에 손실될 확률이 낮아집니다.
2 — 백업을 최소 두 종류의 다른 매체나 장소에 보관합니다. 한 종류의 저장 방식에만 의존하면, 그 방식의 공통된 문제로 모두 잃을 수 있습니다.
1 — 최소 한 벌은 물리적으로 떨어진 곳(off-site) 에 보관합니다. 모든 백업이 한 장소에 있으면, 그 장소의 재해(화재, 침수, 그리고 랜섬웨어)로 모두 잃을 수 있습니다.
이 규칙의 정신은, 단일 실패점을 없애는 것입니다(원칙 3, 깊이 방어의 백업판). 어떤 하나의 사고로도 모든 사본을 잃지 않도록, 사본을 여러 개로, 여러 매체에, 여러 장소에 분산하는 것입니다.
랜섬웨어 시대의 추가 고려: 백업도 노려진다
여기서 현대적으로 매우 중요한 점을 강조합니다. 2장에서 보았듯, 정교한 랜섬웨어 공격은 데이터를 암호화하기 전에 먼저 백업을 찾아 파괴하려 합니다. 백업이 있으면 피해자가 몸값을 내지 않을 것을 알기 때문입니다. Verizon DBIR가 해마다 확인해 주듯 랜섬웨어는 2026년 현재에도 침해의 주된 동기로 남아 있고, 2장에서 본 MOVEit Transfer(CVE-2023-34362) 사건의 Cl0p처럼 조직화된 집단이 대량으로 같은 수법을 돌립니다. 그래서 단순히 백업을 갖는 것을 넘어, 백업 자체를 공격으로부터 보호해야 합니다.
핵심은, 백업이 침해된 시스템에서 쉽게 접근하거나 삭제할 수 없는 곳에 있어야 한다는 것입니다. 만약 백업이 운영 시스템과 같은 네트워크에, 같은 권한으로 접근 가능한 곳에 있다면, 운영 시스템을 장악한 공격자가 백업도 함께 파괴할 수 있습니다. 그래서 백업은 운영 환경과 분리되어야 하고, 가능하면 한 번 기록되면 변경하거나 삭제할 수 없는 형태(불변 백업), 또는 운영 시스템에서 끊어진(오프라인) 형태로 보관하는 것이 강력합니다. 이것이 3-2-1 규칙의 "off-site"가 단순한 물리적 거리를 넘어 "공격자의 손이 닿지 않는 분리"를 의미하는 현대적 이유입니다.
검증되지 않은 백업은 백업이 아니다
마지막으로, 백업에 관한 가장 흔하고 뼈아픈 실수를 강조합니다. 백업을 만들기만 하고, 그것이 실제로 복구되는지 확인하지 않는 것입니다.
백업이 존재한다는 사실과 그 백업으로 실제 복구가 가능하다는 사실은 다릅니다. 백업이 손상되어 있을 수도, 불완전할 수도, 복구 절차에 문제가 있을 수도 있습니다. 그리고 이것을 발견하는 최악의 순간은, 실제로 백업이 필요한 재난의 순간입니다. 그때 백업이 작동하지 않으면, 백업이 없는 것과 마찬가지입니다.
그래서 백업은 정기적으로 복구 테스트를 해야 합니다. 실제로 백업에서 데이터를 복구해 보고, 그것이 온전하고 사용 가능한지 확인하는 것입니다. 이것은 이 책의 네 번째 원칙, "검증 없는 보안은 희망일 뿐이다"의 백업판입니다. 검증되지 않은 백업은 백업이 아니라 희망일 뿐입니다. 복구 테스트를 정기 루틴에 포함하십시오(원칙 5).
현장에서 가장 자주 본 실패가 바로 이것입니다. 백업은 매일 도는데, 막상 복구해 보면 데이터베이스 덤프가 절반에서 잘려 있거나, 업로드된 파일은 백업 대상에서 통째로 빠져 있는 경우입니다. 나는 새 서버를 인수하면 "복구가 되는지"부터 한 번 돌려 봅니다 — 백업 화면의 초록색 체크가 아니라, 빈 환경에 실제로 되살려 서비스가 떠야 비로소 백업이 있다고 말할 수 있기 때문입니다.
그래서 지금 뭘 하면 되나. 이번 분기에 딱 한 번, 백업에서 빈 환경으로 실제 복원을 해 보십시오. 데이터베이스가 다 들어오는지, 사용자 업로드 파일과 설정까지 함께 살아나는지, 서비스가 정상으로 뜨는지를 눈으로 확인하면 됩니다. 이 한 번의 리허설이, 진짜 재난의 순간에 "백업이 있었는데 안 됐다"는 최악의 상황을 막아 줍니다.
13.6 이 장이 남기는 교훈
이 장에서 확인한 것을 압축합니다.
첫째, 예방을 다 한 뒤에도 침해를 가정해야 합니다. 완벽한 예방은 없습니다. 성숙한 보안은 예방과 대비를 함께 갖춥니다. 침해는 일어나지 않을 일이 아니라 언젠가 일어날 일입니다(원칙 2).
둘째, 체류 시간을 줄이는 것이 핵심입니다. 뚫리는 것을 완전히 막을 수 없다면, 적어도 빨리 알아채야 합니다. 빠른 탐지가 피해를 결정합니다. 그리고 탐지의 전제는 가시성, 즉 적절한 로깅입니다.
셋째, 의미 있는 사건을 기록하고, 로그를 보호하십시오. 인증·권한·접근·애플리케이션·시스템 사건을 충분한 맥락과 함께 기록하되, 민감 정보를 보호하고, 공격자가 지우기 어려운 곳에 충분히 오래 보관하십시오.
넷째, 로그를 살아 있게 만드십시오. 알려진 공격 패턴, 이상 징후, 무결성 변화를 감시하고, 정말 중요한 것만 알리되(경보 피로 방지), 자동화와 AI로 사람이 못 하는 규모를 처리하십시오(부록 E).
다섯째, 사고 대응을 미리 준비하십시오. 불이 난 뒤 소화기를 찾으면 늦습니다. 확인·격리·증거 보전·제거·복구·교훈의 흐름을 미리 생각하고, 법적 신고 의무를 파악해 두십시오.
여섯째, 백업은 랜섬웨어 시대의 최강 방어입니다. 3-2-1 규칙으로 단일 실패점을 없애되, 백업 자체를 공격으로부터 분리하고, 무엇보다 정기적으로 복구를 검증하십시오. 검증되지 않은 백업은 희망일 뿐입니다.
이 장에서 우리는 침해를 가정한 기술적 대비를 다뤘습니다. 그러나 침해의 경로는 기술에만 있지 않습니다. 2장에서 보았듯, 가장 약한 고리는 종종 사람입니다. 아무리 단단한 기술적 방어도, 한 명의 직원이 속거나, 한 명의 내부자가 배신하거나, 한 번의 물리적 침입이 일어나면 무너질 수 있습니다. 다음 장에서는 이 사람과 물리의 공격면을 다룹니다.
이 장의 실행 항목
- 의미 있는 보안 사건을 로깅하십시오. 인증, 권한, 접근, 애플리케이션, 시스템 사건을 충분한 맥락과 함께 기록하십시오. (13.2)
- 로그를 보호하고 충분히 보존하십시오. 민감 정보를 거르고, 공격자가 지우기 어려운 곳에, 충분히 오래 보관하십시오. (13.2)
- 모니터링과 탐지를 갖추십시오. 공격 패턴, 이상 징후, 파일 무결성 변화를 감시하고, 중요한 것만 알리십시오. (13.3)
- 로그 분석에 자동화·AI를 활용하되 검증하십시오. 사람이 못 하는 규모를 처리하되 최종 판단은 사람이. (13.3, 부록 E)
- 사고 대응을 미리 준비하십시오. 첫 단계로 무엇을 할지 생각해 두고, 법적 신고 의무를 파악하십시오. (13.4)
- 3-2-1 규칙으로 백업하십시오. 사본 셋, 매체 둘, 한 벌은 분리된 곳에. (13.5)
- 백업을 공격으로부터 분리하십시오. 침해된 시스템에서 백업을 파괴할 수 없게 하십시오. (13.5)
- 정기적으로 복구를 테스트하십시오. 검증되지 않은 백업은 백업이 아닙니다. (13.5)
다음 장: 14장 — 사람과 물리. 가장 약한 고리는 거의 항상 사람입니다. 기술 너머의 공격면.