공개하지 않고도 검증 가능한 보안 사고 타임라인 구축하기

보안 팀은 사고를 준비가 되기 전에 공개하지 않고도 증명 가능한 사고 타임라인을 구축할 수 있습니다. 증거를 수집하는 동안 각 중요한 산출물을 해시하고, 그 다이제스트를 Label 309에 따라 Cardano에 게시합니다. 이후 원하는 누구든지 그 정확한 바이트가 공개 블록 타임 시점 또는 그 이전에 존재했다는 것을 확인할 수 있습니다 — 여러분의 서버나 도메인, 또는 여러분의 말을 신뢰할 필요 없이 말입니다. 민감한 자료는 봉인할 수 있어, 커밋먼트만 공개되고 평문은 암호화된 상태로 유지됩니다.

실제로는 사고가 전개되는 동안 보고서, 로그, 포렌식 내보내기, 스크린샷, 고객 통지문, 규제 기관 초안, 증거 매니페스트를 해시합니다. 각 게시는 공개 시각에 대한 커밋먼트를 고정합니다. 평문은 지정된 수신자를 대상으로 봉인할 수 있으므로, 체인은 무엇을 공개하지 않고도 언제를 증명합니다.

이것은 증거 계층이지, 사고 대응이나 법률 자문, 공개 결정, 규제 보고를 대체하는 것이 아닙니다. 이는 그러한 결정의 배경이 되는 타임라인에 외부적이고 변조가 드러나는 앵커를 제공합니다.

사고 중에 타임라인은 왜 증거가 됩니까?

사고 중에는 시간 그 자체가 증거입니다.

사고 이후 팀은 종종 다음과 같은 질문에 답해야 합니다:

의심스러운 활동이 처음 관측된 시점;
사고가 에스컬레이션된 시점;
법률 자문이 통보된 시점;
봉쇄가 시작된 시점;
시스템이 재구축되기 전에 어떤 로그가 존재했는지;
각 단계에서 어떤 고객 레코드가 영향을 받았다고 판단되었는지;
어떤 버전의 보고서가 이사회에 올라갔는지;
어떤 규제 기관 통지가 작성되거나 제출되었는지;
최초 평가와 최종 보고서 사이에 무엇이 바뀌었는지.

문제는 사고 증거가 빠르게 변한다는 것입니다. 로그는 순환됩니다. 티켓은 편집됩니다. 보고서는 수정됩니다. 스크린샷은 슬라이드에 붙여 넣어집니다. 내보내기는 다시 실행됩니다. 첫날에는 명백해 보였던 사건의 순서가 6개월 뒤에는 증명하기 어려울 수 있습니다.

타임스탬프가 찍힌 커밋먼트는 모든 중요한 산출물에, 여러분을 포함해 그 누구도 날짜를 소급할 수 없는 외부 앵커를 부여합니다.

보안 팀은 무엇에 타임스탬프를 찍어야 합니까?

타임라인이 언젠가 다투어질 경우 중요해질 산출물에 타임스탬프를 찍으십시오.

보안 사고의 경우, 여기에는 흔히 다음이 포함됩니다:

초기 탐지 메모;
경보 내보내기;
SIEM(보안 정보 및 이벤트 관리) 도구에서의 검색;
EDR(엔드포인트 탐지 및 대응) 도구에서의 내보내기;
방화벽 및 접근 로그;
신원 공급자 로그;
클라우드 감사 로그;
악성코드 샘플 또는 샘플 해시;
포렌식 디스크 또는 메모리 이미지 매니페스트;
영향받은 계정 목록;
영향받은 고객 추정치;
봉쇄 및 제거 메모;
사고 티켓;
내부 상태 보고서;
이사회 업데이트;
규제 기관 초안;
고객 통지 초안;
최종 사고 보고서.

비밀을 평문으로 게시하지 마십시오. 해시, Merkle 루트, 또는 봉인된 암호문은 거의 언제나 공개 텍스트보다 안전하면서도 — 똑같이 증명 가능합니다.

Label 309는 사고 대응에 어떻게 들어맞습니까?

이미 운영 중인 도구 옆에 증명 계층으로 사용하십시오.

사고 대응 팀은 SIEM이나 사건 관리 도구, 티켓 시스템, 포렌식 플랫폼, 문서 저장소를 대체할 필요가 없습니다. 중요한 산출물을 내보내거나 스냅샷으로 만들고, 해시를 계산하며, 대응의 정해진 시점에 레코드를 게시합니다.

일반적인 흐름은 다음과 같습니다:

탐지 팀이 최초 경보 번들을 내보냅니다.
사고 책임자가 파일들의 매니페스트를 만듭니다.
매니페스트를 해시합니다.
Label 309 레코드가 해시, 또는 번들에 대한 Merkle 루트를 고정합니다.
민감한 파일들은 법률 자문과 보안 리더십을 대상으로 봉인됩니다.
트랜잭션 참조가 사고 사건에 첨부됩니다.

이후 그 트랜잭션 참조를 가진 누구든지, 주어진 파일이나 매니페스트가 공개 타임스탬프 시점에 커밋된 바이트와 일치하는지 확인할 수 있습니다 — 검증기, 오픈 소스 명령줄 도구, 또는 그 표준의 모든 제3자 구현을 사용해서 말입니다. 게시 및 검증 코드는 github.com/cardanowall에서 오픈 소스로 공개되어 있습니다.

바이트를 게시하는 대신 사고 레코드를 봉인하는 이유는 무엇입니까?

사고 세부 내용은 게시하기에 위험한 경우가 많습니다.

여기에는 패치되지 않은 취약점, 자격 증명, IP 주소, 고객 데이터, 직원 데이터, 위협 행위자 정보, 법 집행상 민감한 사실, 또는 상업적으로 민감한 개선 계획이 담겨 있을 수 있습니다.

봉인된 레코드를 사용하면 파일을 암호화된 상태로 두면서도 커밋먼트를 게시할 수 있습니다. 온체인 레코드는 평문 해시 — 타이밍의 증명 — 와 함께 선택된 수신자만 열 수 있는 래핑된 키를 담습니다. 암호문은 체인이 아니라 콘텐츠 주소 지정 스토리지 URI에 저장되며, 수신자 공개 키 또한 체인에 절대 나타나지 않습니다. 관찰자는 봉인된 레코드가 존재한다는 것, 그 블록 타임, 그리고 몇 명의 수신자에게 봉인되었는지만 알 수 있을 뿐 — 그들이 누구인지, 무엇이 봉인되었는지는 결코 알 수 없습니다.

따라서 증명 레코드 자체를 통해 사고를 공개하지 않으면서도 원본 증거를 보존할 수 있습니다. 내용을 노출하지 않고 특정 사람들에게 파일을 봉인하는 방법에 대한 더 자세한 내용은 공개 파일 없이 기밀 공개하기를 참고하십시오.

이것은 규제 기관 타임라인에 어떻게 도움이 됩니까?

많은 사고 규제 체계는 타이밍에 좌우되며, 무엇을 언제 알았는지에 대한 변조가 드러나는 레코드는 그러한 판단을 뒷받침할 수 있습니다.

미국에서 SEC 규정은 국내 등록자가 중대한 사이버보안 사고에 대해 Item 1.05에 따라 Form 8-K를 사고가 중대하다고 판단한 날로부터 영업일 4일 이내에 제출하도록 요구합니다 — 기한은 발견 시점이 아니라 중대성 판단 시점부터 시작됩니다. SEC는 또한 중대성 판단을 부당한 지체 없이 내려야 한다는 점을 강조해 왔습니다.
유럽연합에서 NIS2 지침은 중대 사고에 대해 3단계 기한을 설정합니다: 사고를 인지한 시점으로부터 24시간 이내의 조기 경보, 72시간 이내의 사고 신고, 그리고 1개월 이내의 최종 보고서입니다.
EU 금융 기관의 경우, 디지털 운영 복원력법(DORA)은 2025년 1월 17일부터 적용되기 시작한 통일된 ICT 사고 관리 및 주요 사고 보고 의무를 도입했습니다.

정확한 의무는 회사, 부문, 관할권, 사고에 따라 다르며 시간이 지나면서 바뀝니다 — 이것은 일반적인 배경 설명이지 법률 자문이 아닙니다. 증명은 보고가 필요한지를 결정하지 않으며, 마감을 지켰다는 것을 증명하지도 않습니다. 증명이 할 수 있는 것은 그러한 결정의 배경이 되는 산출물과 평가에 대한 변조가 드러나는 레코드를 보존하여, 여러분이 의존한 타임라인을 나중에 보여줄 수 있게 하는 것입니다. 이를 주장을 뒷받침할 수 있는 증거로 다루십시오; 이것이 법률 자문을 대체하지는 않습니다.

실무적인 증명 워크플로는 어떤 모습입니까?

필요해지기 전에 미리 소수의 증명 시점을 정의하십시오.

회사는 다음과 같이 사고 증명 체크포인트를 정의할 수 있습니다:

T0: 처음 탐지된 신호 또는 경보 번들;
T1: 사고 선언;
T2: 초기 범위 평가;
T3: 봉쇄 조치 시작;
T4: 중대성 또는 보고 의무 평가 초안;
T5: 이사회 또는 경영진 업데이트;
T6: 규제 기관 또는 고객 통지 초안;
T7: 최종 사고 보고서;
T8: 사후 검토 및 개선 계획.

각 체크포인트는 매니페스트를 산출합니다. 매니페스트는 직접 해시하거나, 더 넓은 사고 루트에 Merkle 리프로 포함할 수 있습니다.

그 결과는 나중에 설명하기 쉬운 타임라인입니다: 여기 체크포인트가 있고, 여기 산출물이 있으며, 여기 공개 타임스탬프가 있고, 여기 파일이 일치하는지 검증하는 방법이 있습니다.

파일당 레코드 하나 대신 Merkle 루트를 커밋해야 하는 경우는 언제입니까?

증거 집합이 클 때 Merkle 루트를 사용하십시오.

심각한 사고는 수천 또는 수백만 건의 로그 행, 경보, 패킷, 파일 해시, 엔드포인트 이벤트, 티켓 업데이트를 수반할 수 있습니다. 산출물당 레코드 하나를 게시하는 것은 비용이 많이 들고 관리하기 어렵습니다.

대신, 결정적 매니페스트를 만들고, 각 항목을 리프로 해시하며, Merkle 트리를 구축하고, 체크포인트에 대해 32바이트 루트 하나를 게시하십시오. 이후 특정 로그 내보내기, 이벤트, 또는 파일 해시가 그 체크포인트에 포함되어 있었음을 — 간결한 포함 증명으로 — 나머지 증거 집합을 드러내지 않고 증명할 수 있습니다.

이는 다음에 자연스럽게 들어맞습니다:

일별 사고 증거 배치;
대용량 클라우드 로그;
고객 영향 목록;
엔드포인트 산출물 인벤토리;
포렌식 수집 매니페스트;
취약점 스캔 스냅샷;
패치 및 개선 증거.

한 가지 주의 사항: 루트는 매니페스트, 순서가 정해진 리프 목록, 포함 증명을 보존할 때에만 유용합니다. 체인은 루트를 저장하고; 여러분은 어떤 리프가 그 아래에 있음을 증명하는 데 필요한 모든 것을 저장합니다. 거대한 집합을 레코드 하나가 대신하는 동일한 패턴은 수천 개 파일을 위한 레코드 하나에서 다룹니다.

사실이 바뀌었을 때 정정은 어떻게 이루어집니까?

사실이 개선되면서 사고 보고서는 바뀌며, 이 표준은 그것을 가시화할 수 있게 합니다.

초기 추정치는 종종 틀립니다. 팀은 처음에는 200개의 계정이 영향을 받았다고 믿었다가, 이후 2,000개를 발견하고, 그다음 150개의 오탐을 제외할 수 있습니다. 그러한 변화는 숨겨져서는 안 됩니다 — 설명 가능해야 합니다.

레코드는 대체(supersedence) 포인터, 즉 자신이 대체하는 이전 레코드의 32바이트 트랜잭션 해시를 담을 수 있습니다. 이전 레코드는 체인에 남아 독립적으로 검증 가능한 상태를 유지하며; 체인은 추가 전용이므로 대체한다고 해서 어떤 것도 제거하거나 무효화하지 않습니다. 포인터는 사실상 이것이 더 나중 버전이다라고 말할 뿐입니다. 포인터에는 사유 필드가 없습니다 — 사람이 읽을 수 있는 의미는 포인터가 아니라 새 콘텐츠에 담겨야 합니다.

그 구분은 중요합니다: 이는 정직한 수정과 조용한 재작성 사이의 차이를 보존합니다. 이력은 순서대로, 가시적이며, 증명 가능합니다.

봉인된 사고 레코드는 누가 받아야 합니까?

수신자 목록을 작고 신중하게 유지하십시오. 수신자가 한 명 추가될 때마다 평문을 복호화할 수 있고 — 복호화한 뒤 — 유출할 수 있는 또 다른 당사자가 생깁니다.

일반적인 수신자에는 다음이 포함됩니다:

외부 법률 자문;
내부 법무;
사고 지휘자;
CISO 또는 보안 리더십;
포렌식 파트너;
적절한 경우 규제 기관 담당자;
사이버 보험 자문 또는 패널 벤더;
이사회 보안 위원회;
회사가 관리하는 신뢰할 수 있는 아카이브 신원.

각 수신자는 여러분이 별도 경로로 실제로 확인한 수신 주소를 제공해야 합니다 — 그 키가 그들을 사칭하는 누군가가 아니라 정말로 그 사람의 것임을 확인하는 것입니다. 잘못된 키에 봉인하면 잘못된 독자에게 봉인되며, 체인은 그 실수를 대신 잡아 주지 않습니다; 파일을 봉인하기 전에 수신자를 확인하기가 그 방법을 단계별로 안내합니다. 오래 보관되는 민감한 증거의 경우, 워크플로가 지원하는 곳에서는 선택적 하이브리드 포스트 양자 수신 주소를 선호하십시오. 이는 공격자가 오늘 암호문을 저장해 두고 미래의 양자 컴퓨터가 그것을 깨뜨리기를 기다리는 "지금 수집하고 나중에 복호화하기" 공격에 저항하도록 설계되었습니다.

공개 메타데이터에 절대 들어가서는 안 되는 것은 무엇입니까?

사고 비밀은 공개 레코드에서 완전히 배제하십시오.

다음을 게시하지 마십시오:

평문 익스플로잇 세부 내용;
자격 증명;
개인 키;
고객 개인 데이터;
민감한 내부 호스트명 또는 IP 주소;
기밀로 유지되어야 하는 공격자 인프라 세부 정보;
특권적 법률 분석;
근거 없는 비난;
공개되어서는 안 되는 규제 기관 전용 정보.

공개 체인은 커밋먼트 — 해시, 루트, 봉인 봉투 — 를 담아야 하지, 사고 서사를 담아서는 안 됩니다. 서사는 여러분의 시스템에, 그리고 필요한 경우 봉인된 암호문 안에 남습니다.

증명은 회사가 사고를 잘 처리했음을 보여줍니까?

아닙니다. 그것은 의도적으로 그보다 좁습니다.

증명은 특정 파일이나 매니페스트가 공개 시각까지 존재했음을 보여줄 수 있습니다. 선택적 작성자 서명이 있을 때, 특정 서명 키가 레코드를 보증했음을 보여줄 수 있습니다. 나중의 산출물이 이전 커밋먼트와 일치함을 보여줄 수 있습니다.

증명은 조사가 완전했다거나, 회사가 옳은 판단을 내렸다거나, 법적 마감을 지켰다거나, 통제가 효과적이었다거나, 고객에게 올바르게 통지되었다는 것을 증명하지는 않습니다. 이것은 진실이나 판단, 컴플라이언스가 아니라 타이밍과 무결성에 관한 증거입니다. 이 경계의 일반적인 설명은 증명이 증명하지 않는 것을 참고하십시오.

무엇이 잘못될 수 있습니까?

가장 흔한 실패는 암호학적인 것이 아니라 운영상의 것입니다.

엉뚱한 파일에 타임스탬프를 찍을 수 있습니다. 원본 증거를 잃을 수 있습니다. 루트가 의존하는 Merkle 리프를 보존하지 못할 수 있습니다. 민감한 사실을 공개 필드에 넣을 수 있습니다. 아무도 확인하지 않은 수신 주소에 봉인할 수 있습니다. 너무 많은 사람이 복호화하도록 허용할 수 있습니다. 증명 계층을 그 배경의 증거 계층이 아니라 보고 시스템처럼 다루기 시작할 수 있습니다.

가장 좋은 방어책은 절차적입니다: 사고가 발생하기 전에 증명 체크포인트를 정의하고, 지루한 부분을 자동화하며, 법적 노출이 가능한 곳마다 법률 자문을 계속 참여시키십시오.

요약

보안 사고에는 압박을 견뎌 내는 타임라인이 필요합니다.

Label 309는 사고 산출물, 보고서, 매니페스트를 공개 시각에 고정합니다. 봉인된 레코드는 민감한 증거를 선택된 수신자를 대상으로 암호화된 상태로 유지합니다. Merkle 루트는 큰 증거 집합을 레코드 하나로 커밋합니다. 대체 포인터는 정정을 조용히가 아니라 가시적으로 만듭니다 — 어떤 단일 서버나 벤더도 신뢰하지 않고 말입니다.

무엇이 언제 존재했는지를 증명하는 데 사용하십시오. 사고 대응이나 법적 보고를 대체하는 데 사용하지 마십시오 — 그리고 타이밍과 무결성을 넘어서는 무언가를 증명하리라 기대하지 마십시오.

더 읽을거리

내부고발자 증거 — 발신자를 익명으로 유지하면서 민감한 드롭을 봉인하기.
법적 증거와 전자증거개시 — 분쟁에서 증명을 증거로 활용하기.
벤더 신뢰 없는 컴플라이언스 로그 — 아무도 날짜를 소급할 수 없는 감사 추적을 커밋하기.
SEC, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (소기업 컴플라이언스 가이드): https://www.sec.gov/resources-small-businesses/small-business-compliance-guides/cybersecurity-risk-management-strategy-governance-incident-disclosure
European Commission, NIS2 Directive FAQs: https://digital-strategy.ec.europa.eu/en/faqs/directive-measures-high-common-level-cybersecurity-across-union-nis2-directive-faqs
ESMA, Digital Operational Resilience Act (DORA): https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora