사고 사후보고서는 탈취액과 원인 한 줄보다 공격 타임라인, 최초 침해 권한, 영향 자산·사용자, 중단·복구 조치, 남은 위험과 재발 방지 담당·기한을 연결해 읽어야 한다. 발표자의 주장과 온체인·로그 증거도 구분한다.
타임라인이 원인보다 먼저다
공격 시작, 최초 악성 거래, 탐지, 서비스 중단, 공개 공지, 패치, 재개를 UTC로 정렬한다. 발견 시각이 공격 시각보다 늦다면 그 사이 추가 피해와 로그 손실 가능성을 확인한다. 사후보고서 버전이 갱신되면 처음 공지의 추정과 최종 결론을 덮어쓰지 말고 변화 이유를 기록한다.
공격 경로를 재현하는 기술 분석은 실제 배포 블록과 동일한 상태에서 성공해야 설득력이 높다. 포크 환경 PoC가 있다면 사용한 블록 높이, 계약 주소, 입력값과 예상 결과를 확인한다. 재현 코드가 공개되지 않았더라도 로그·트레이스·권한 변경 증거가 결론과 맞는지 본다.
좋은 사후보고서는 범인을 지목하는 문서보다 같은 실패를 다시 막을 검증 가능한 작업 목록에 가깝다.
JOBCOIN 해설
직접 원인과 근본 원인을 나눈다
키 탈취는 직접 원인일 수 있지만 왜 한 키가 자금 이동에 충분했는지, 비밀이 어떻게 노출됐는지, 이상 출금이 왜 탐지되지 않았는지가 근본 원인이다. 개인 실수로 끝내지 말고 권한 분리, 변경 승인, 모니터링, 비상 중지 설계를 본다.
보고서가 known unknowns를 밝히는지도 품질 기준이다. 삭제된 로그, 접근할 수 없는 제3자 시스템, 아직 회수하지 못한 장비가 있다면 원인 확신도에 한계가 있다. 조사 중과 확정 표현을 나누고, 새 증거가 나올 때 수정 이력을 공개하는 편이 신뢰에 도움이 된다.
Dusk 브리지 사례의 증거
Dusk 사후보고서는 서명 지갑 키 침해를 직접 원인으로 밝히고 서명·이벤트 처리·네트워크 연결이 단일 경로에 있던 구조적 한계를 설명했다. 이후 서명과 이벤트 처리를 분리하고 상태 머신을 도입했다고 밝혔다. 원인과 개선이 대응되는 구체적 서술의 사례다.
| 항목 | 필요 증거 | 확인 질문 |
|---|---|---|
| 영향 | 주소·TXID·로그 | 누가 무엇을 잃었나 |
| 원인 | 포렌식·권한 구조 | 어떤 통제가 실패했나 |
| 개선 | 배포·테스트 기록 | 실제로 적용됐나 |
피해액과 영향 사용자를 계산한다
원자산 수량, 평가 시각의 달러 환산, 동결·회수액, 프로젝트 보전액, 사용자 미지급액을 나눈다. 계약이 공격받았어도 모든 예치자가 같은 손실률을 부담하지 않을 수 있다. 스냅샷 블록과 보상 자격, 클레임 기한을 확인한다.
보상 계획은 총예산과 지급 순서, 기준 스냅샷, 손실 산정 통화, 이의 신청 절차를 포함해야 한다. 프로젝트 토큰으로 보상하면 지급 시점 가격과 유동성 위험이 이용자에게 이전될 수 있다. vesting이나 양도 제한이 있으면 명목 금액과 즉시 회수 가능액을 구분한다.
복구 발표에서 남은 위험 찾기
서비스 재개 전 공격자 세션·키를 폐기했는지, 새 계약으로 이전했는지, 구계약 권한이 남았는지 본다. 독립 검토와 회귀 테스트, 새 모니터링 알림의 임계값이 공개됐는지도 확인한다. 감사 완료 문구는 조사 범위와 대상 커밋을 읽는다.
재발 방지 조치가 멀티시그 추가뿐이면 같은 공급망·운영팀이 모든 서명자를 통제하는지 살핀다. 키 회전, 최소권한, 속도 제한, 이상 거래 지연, 독립 모니터링과 비상 중지가 서로 다른 방어층을 이루는지 본다. 한 통제의 실패가 전체 자금 이동으로 이어지지 않아야 한다.
CISA식 사후활동을 적용하기
CISA 가이드는 공식 회고에서 타임라인을 보완하고 사람·절차·기술 전반의 개선점을 찾으며 정책과 절차를 갱신하라고 권한다. 암호화폐 프로젝트도 수정 담당자, 기한, 검증 기준을 공개해야 독자가 완료 여부를 추적할 수 있다.
후속 감사의 no critical findings 표현도 범위 안 결과다. 공격받은 구성요소, 새 구현, 배포 설정과 운영 절차가 모두 대상인지 확인한다. 수정 코드만 감사하고 키 관리·인프라가 빠졌다면 원래의 운영 침해 위험이 남을 수 있다.
공개 범위를 줄여야 하는 보안상 이유가 있더라도 이용자에게 필요한 최소 정보는 남아야 한다. 영향 계약·체인·시간대, 위험한 승인 취소 방법, 안전한 새 주소와 보상 절차를 명확히 제공해야 한다. 반대로 미확정 공격 기법을 상세히 공개해 모방 위험을 키우지 않는 균형도 필요하다. 독자는 비공개 세부가 있다는 사실과 확인된 운영 조치를 구분해 평가한다.
사후보고서 공개 뒤 버그바운티 규칙이 바뀌었다면 사고 당시와 이후 정책을 구분한다. 공격자를 선의의 연구자로 인정했는지, 반환 협상이 있었는지와 형사 수사 상태를 한 표현으로 합치지 않는다.
- UTC 타임라인과 온체인 블록을 맞춘다
- 직접 원인·기여 요인·근본 원인을 분리한다
- 회수·보전·미지급액을 같은 기준일로 계산한다
- 개선 조치의 배포 거래와 후속 감사를 확인한다
자주 묻는 질문
키가 탈취됐다는 설명이면 충분한가요?
아니다. 키가 어디서 노출됐고 왜 단일 침해가 자금 이동으로 이어졌는지 통제 실패를 설명해야 한다.
서비스가 재개되면 안전한가요?
공격 지속성 제거, 패치 적용, 독립 검증과 보상 상태를 확인해야 한다. 재개 자체는 한 단계다.
버그바운티 지급이 피해 회수인가요?
아니다. 공격자 반환, 보험·재단 보전, 이용자 지급과 보안 연구자 보상은 별도 금액이다.
