런북에 아무도 넣지 않는 복원 단계

우리가 읽어 본 모든 복구 계획은 데이터가 얼마나 빨리 돌아오는지로 측정된다. 복구 시간 목표, 복구 시점 목표, 다운타임 시간, 시간당 손실되는 매출. 이 수치들은 경영진 슬라이드에 올라가는 숫자이며, 복구가 해야 할 대부분의 일에 대해서는 올바른 숫자다.

그리고 바로 그 이유 때문에 이 지역의 거의 모든 런북에서 한 단계가 빠져 있다.

두 날짜

타임라인부터 시작하자. 타임라인이 바로 전체 메커니즘이기 때문이다.

어느 날 침해된다. 나중에 다른 날에 이를 알게 된다. 그것이 바로 체류 시간이다. 즉, 침입자가 들어온 시점과 누군가가 알아차린 시점 사이의 간격이다. 분이나 시간이 아니라 일 또는 주 단위로 측정하라. 정확한 수치는 사고마다 다르며, 그 형태가 훨씬 더 중요하다.

이제 복구 팀이 어떤 백업을 선택하는지 물어보자. 그들은 깨끗하다고 믿어지는 가장 최근의 복원 지점을 선택한다. 실제로는 사고가 탐지되기 전에 생성된 가장 최근의 복원 지점을 의미하는데, 탐지는 모두가 동의하는 타임스탬프가 있는 유일한 사건이기 때문이다.

그 둘은 서로 다른 날짜다. 그 사이의 간격에서 생성, 수신 또는 수정된 모든 것은 백업 안에 들어 있으며, 사고를 시작한 악성 문서는 거의 확실히 아무도 무언가를 알아차리기 전에 생성되었다. 백업은 충실한 복사본이다. 페이로드에 대해서도 충실하다.

단계를 삭제하는 지표

여기서 덜 주목받는 부분이 나오는데, 이것은 전혀 기술 문제가 아니다.

복구는 경과 시간으로 평가된다. 자산이 중단된 매 시간은 계산되며, 종종 매출 수치를 지켜보는 사람들이 이를 집계한다. 복원된 모든 문서를 검사하거나 재처리하면 복구 책임자가 평가받는 바로 그 수치에 몇 시간이 더해지고, 사고 종료를 선언해야 한다는 압박이 가장 큰 최악의 순간에 그 시간이 더해진다.

아무도 런북에 "파일 위생을 건너뛰었다"고 적지 않는다. 그렇게 일어나지 않기 때문이다. 그 단계는 애초에 런북에 없었고, 어떤 지표도 그것을 요구하지 않았으며, 복구는 일정대로 완료되었다. 유인이 조용히 일을 해낸 것이다.

그래서 패턴은 반복된다. 서버는 깨끗한 이미지로 다시 구축되고, 자격 증명은 교체되며, 엔드포인트는 다시 이미지화되고, 이번에는 네트워크가 제대로 분리된다. 그런 다음 파일 공유, 사서함, 문서 저장소가 정확히 이전과 같은 상태로 돌아온다. 손대지 않은 채로. 아무도 다시 구성하지 않는 유일한 계층은 그 안에 문제를 실어 나른 계층이다.

재검사가 잘못된 도구인 이유

가장 분명한 답은 복원하기 전에 백업을 검사하는 것이며, 왜 그것이 들리는 것보다 약한지 정확히 짚어볼 가치가 있다.

귀하의 탐지 스택은 이 파일을 이미 한 번, 도착한 날에 식별하는 데 실패했습니다. 복원 시점에는 동일한 종류의 엔진을 동일한 파일에 대고, 알려진 악성 항목의 동일한 목록을 찾고 있습니다. 캠페인이 시끄럽고 널리 보고되었다면 시그니처가 따라잡았을 수도 있습니다. 그렇지 않았거나, 문서가 귀하를 위해 특별히 만들어진 것이라면, 그렇지 않았을 것입니다.

샌드박스에도 관련된 한계가 있습니다. 설계된 만큼만 좋다는 점입니다. 사용자 상호작용, 특정 로케일, 또는 아직 도래하지 않은 날짜를 기다리는 페이로드는 폭발 시에도 완벽하게 동작하고, 필요한 정확한 시간 동안만 완벽하게 동작합니다.

더 조용한 실패도 있습니다. 재스캔은 판정을 만들어 내지만, 판정은 증거가 아닙니다. "아무것도 발견되지 않음"은 파일에 대한 것이 아니라, 귀하의 탐지 범위에 대한 진술입니다.

복원-위생 단계는 어떤 모습인가

실제로 쓸 수 있는 방식은 백업에서 나온 파일을 낯선 사람에게서 도착한 파일처럼 다룹니다. 복구 중에는 그것이 정확히 그 출처이기 때문입니다.

구체적으로는, 복원과 서비스 복귀 사이에 하나의 단계를 삽입합니다:

1. 검사보다 재구성. 각 문서를 구성 요소로 분해하고, 각 요소를 해당 형식의 공개된 사양과 대조해 검증한 다음, 그 중간 표현에서 완전히 새로운 파일을 만듭니다: 원본 바이트가 아니라 레시피입니다. 이 차이는 들리는 것보다 훨씬 중요합니다. 엔진이 안전하다고 판단한 부분만 복사하는 것도 여전히 무엇이 안전해 보이는지에 대한 판단이며, 이는 다른 옷을 입은 탐지일 뿐이고, 원본 파일은 여전히 그대로 도착한 파일입니다. 재구성은 원본을 아예 통과시키지 않으므로, 인식되지 않은 채 살아남는 것은 아무것도 없습니다. 이것이 결정론적 Content Disarm and Reconstruction이 하는 일입니다. Glasswall은 테스트된 827만 개의 파일 중 악성 파일 100%를 무력화했다고 보고하며, 정부 연구 센터 사례 연구는 이런 방식으로 순차화된 복구를 설명합니다.
2. 파일별 기록 유지. 각 문서에 대해 무엇이 제거되었는지, 어떤 policy 아래에서, 언제였는지 기록합니다. 이것이 사고 보고서에 필요한 증적이고 평가자가 요구하는 증적이며, 나중에 재구성할 수 없습니다.
3. 알파벳순이 아니라 폭발 반경 기준으로 우선순위 지정. 공유 드라이브, 메일박스, 그리고 자동화 파이프라인이 소비하는 모든 것이 먼저입니다. 월간 매크로 기반 프로세스에 공급되는 재무 공유 폴더는 아무도 열지 않는 아카이브보다 더 높은 수준의 문제입니다.
4. 환경이 여전히 분리되어 있다고 가정. 복구 중간에는 파일을 보낼 네트워크가 없는 경우가 많습니다. 그래서 데스크톱 상주 처리가 정상 상태에서는 그렇지 않은 방식으로 여기서 중요합니다. Glasswall Meteor는 엔진을 로컬에서, 온라인, 오프라인 또는 air-gapped 상태로 실행합니다. 8.27

이 중 어느 것도 화려하지 않고, 새로운 엔지니어링도 아닙니다. 하나의 단계와 그 시간을 쓰기로 하는 결정일 뿐입니다.

증거 측면

이 단계를 추가해야 하는 두 번째 이유는 이 지역에서는 이미 의무가 문서화되어 있고, 그것이 통제 의무이기도 하지만 증거 의무이기도 하기 때문입니다.

싱가포르의 Cybersecurity Code of Practice for Critical Information Infrastructure는 6.1.4항에서 이를 명확히 규정합니다. 기록한 사건 이후 최소 12개월 동안 보관되는 로그, 무단 수정 및 삭제로부터 보호되는 로그, 그리고 "사이버보안 사고에 대한 조사를 용이하게 하기 위해 log retention policy에 따라 관리되는" 로그입니다. 명시된 목적이 아카이브가 아니라 조사인 보존입니다. 6.1.4

MAS 기술 위험 관리 가이드라인은 금융 기관에 대해 동일한 기대를 제시합니다. 즉, 메일, 업로드 포털 또는 제3자 교환을 통해 도착한 신뢰할 수 없는 파일은 탐지 판정만으로 허용되지 않고 경계에서 처리되어야 합니다.

사고 후 이 둘을 함께 읽으면 평가자가 들고 오는 질문은 "무엇을 차단했는가"가 아닙니다. "이 문서에 무슨 일이 있었는지 보여 달라"입니다. 예외만 기록하는 통제는 그 질문에 답할 수 없습니다. 허용된 파일은 파일별 기록을 전혀 생성하지 않았기 때문입니다. 재구성 단계는 건드리는 모든 파일에 대해 하나의 기록을 만들어 내며, 완전히 정상인 것으로 판명된 파일도 포함합니다. 그래서 그 기록은 경보 이력이라기보다 증거로서 유용합니다.

물어볼 가치가 있는 질문

복구 계획은 리허설합니다. restore-hygiene 단계는 두 번째 사고 이후에 추가되곤 하는데, 그것은 배우기에는 비용이 큰 시점입니다.

복구 승인서에 귀하의 서명이 들어간다면, 팀에 대한 질문은 데이터가 얼마나 빨리 돌아왔는지가 아닙니다. 무엇을 다시 넣었는지, 그리고 어떻게 아는지입니다.

싱가포르의 전체 의무 그림은 Cybersecurity (Amendment) Act 2024와 2026년 7월에 발표된 CCoP 업데이트를 포함하여, Singapore compliance page를 참조하십시오.