요약

  • RFC 2350은 CSIRT에게 누구를 지원하는지, 어떻게 보고하는지, 어떤 권한을 갖는지, 어떤 서비스를 제공하는지를 기술하도록 요구한다. 이러한 선언은 기대치를 정의할 뿐, 특정 사건의 상태를 정의하지 않는다.
  • 접수, 인시던트 확인, 공격자 귀속, 제거, 복구, 당사자 간 조율은 별개의 명제이다. 각각에는 그에 맞는 케이스별 기록이 필요하다.

어떤 보고자가 CSIRT 설명서에 인쇄된 주소로 암호화된 메시지를 보냈다고 상상해 보자. 문서는 최신 상태이고, 공개 키는 유효하며, 제출 시점은 운영 시간 안에 있다. 이 사실들은 보고자가 선언된 조건 아래 선언된 경로를 사용했음을 입증한다. 그러나 메시지가 실제 작업 대기열에 도달했는지, 사람이나 시스템이 이를 접수했는지, 누군가 내용을 분류했는지는 입증하지 않는다.

1998년 6월의RFC 2350, BCP 21의 핵심에 있는 유용한 한계가 바로 이것이다. 이 메모는 커뮤니티가 컴퓨터 보안 인시던트 대응 팀(CSIRT)에게 무엇을 기대할 수 있는지에 대한 오해에 대응한 것이다. 그 해답은 정보 아키텍처였다. 팀의 신원과 연락처, 헌장, 지원 대상(컨스티튜언시), 후원, 권한, 정책, 서비스, 보고 양식, 면책 조항을 공개하라는 것이다. 그 결과 지원 대상자는 어디에 보고해야 하는지, 어떤 지원이 제공되는지, 팀이 무엇을 기대하는지 알 수 있게 되었다.

따라서 이 문서는 인시던트 이전의 책임성을 개선했다. 인시던트 이후의 접수 증명을 만들어 낸 것은 아니다.

연락 창구에는 여러 개의 시계가 있다

RFC 2350은 팀에게 시간대, 운영 시간, 휴일 일정, 24시간 핫라인 유무를 공개하도록 요구한다. 이는 단순히 이메일 주소를 나열하는 것보다 정밀하다. 보고자는 즉각적인 처리가 합리적인 기대인지 판단할 수 있다.

그러나 운영 시간은 서비스 조건이지 관찰된 응답 시간이 아니다. 네 개의 타임스탬프는 서로 구분된다. 보고자의 제출, 공지된 시스템으로의 전달, 팀의 접수 확인, 그리고 분류(triage) 결정이 그것이다. 공개 서술은 첫 경로와 의도된 가용성을 정의할 수 있다. 이후 단계들은 메시지 전송 기록, 티켓 생성, 접수 확인 또는 이에 상응하는 케이스 기록만이 확립할 수 있다.

이 구분이 중요한 이유는 “연중무휴 운영”이 쉽게 “이 보고는 실시간으로 처리되었다”로 변환되기 때문이다. RFC 2350은 그런 변환을 하지 않는다. 오히려 지원은 업무량과 제공된 정보의 완전도에 따라 달라질 수 있다고 명시한다. 유용한 평가는 서비스 페이지에서 추론하는 대신 대기열 상태, 우선순위, 추가 정보 요청, 실제 인계 시각을 그대로 보존해야 한다.

보고된 사안은 아직 확인된 인시던트가 아니다

RFC 2350은 분류(triage)를 수신 보고를 해석하고 우선순위를 매기며, 진행 중인 인시던트 및 추세와 연관시키고, 인시던트가 실제로 발생했는지와 그 범위를 판단하도록 돕는 것으로 정의한다. 순서가 결정적이다. 검증은 보고 다음에 온다.

이후의FIRST CSIRT Services Framework 2.1은 이 분기점을 더욱 명확히 한다. 초기 정보는 실제 인시던트일 수도 있고, 추가 데이터가 필요할 수도 있으며, 설정 오류나 하드웨어 결함일 수도 있고, 오보로 처리되거나 다른 책임 그룹으로 전달될 수도 있다. 보고 접수, 인시던트 분석, 포렌식 분석은 별개의 결과를 가진 별개의 서비스이다.

따라서 주소나 티켓 번호는 보고자가 서술한 사건 자체를 증명하지 못한다. 티켓은 주장이 절차에 들어갔다는 것만 증명할 수 있다. 확인을 위해서는 케이스를 접수 단계에서 벗어나게 만든 증거와 분석이 필요하다.

컨스티튜언시, 권한, 통제권이 하나의 경계로 합쳐지지는 않는다

RFC 2350은 CSIRT에게 컨스티튜언시, 즉 서비스를 제공하는 사용자, 사이트, 네트워크 또는 조직을 정의하도록 요구한다. 그리고 별도로 팀에게 자신의 권한을 공개하도록 요구한다. 커뮤니티 팀은 자문 역할일 수 있고, 조직 소속 팀이라도 컨스티튜언시 경계 안의 모든 시스템에 개입할 권한이 있는 것은 아니다.

이 분리는 흔한 과잉 해석을 막는다. 팀은 컨스티튜언시에 관한 보고를 접수하고, 다른 당사자와 조율하고, 기술 조언을 제공할 수 있다. 그러면서도 호스트 격리, 기기 보존, 벤더 강제, 서비스 패치, 프로덕션 복구를 실행할 권한이 없을 수 있다. 후원 조직은 권한이 어디에서 오는지 밝힐 뿐, 모든 운영 주체가 모든 조치를 위임했다는 것을 증명하지 않는다.

따라서 인시던트 기록에는 제안된 조치와 그것을 수행할 권한을 가진 행위자가 모두 필요하다. 시스템 소유자에게 보낸 요청은 봉쇄(containment)가 아니다. 지속성(persistence) 제거 조언은 지속성이 실제로 제거되었다는 증거가 아니다.

서비스 카탈로그에는 서로 다른 동사들이 담겨 있다

RFC 2350은 인시던트 대응을 분류(triage), 조율(coordination), 해결(resolution)로 나눈다. 분류는 보고를 평가하고 발생 여부와 범위 확인을 돕는다. 조율은 정보를 공개 정책에 따라 범주화하고, 필요한 사람(need-to-know)에게만 관련 당사자를 통보한다. 해결 서비스는 통상 부가적이거나 선택적이라고 기술된다. 기술 지원, 악용된 취약점과 그 영향의 제거(eradication), 영향받은 시스템과 서비스의 복구 지원이 그것이다.

이 순서는 모든 케이스가 자동으로 최종 단계에 도달하는 컨베이어 벨트를 의미하지 않는다. 팀은 핵심 분류를 제공하면서 현지 복구는 제공하지 않을 수 있다. 상대방에게 통보하면서 확인을 받지 못할 수도 있다. 악성 지속성 제거를 조언하면서도 영향받은 시스템을 통제하지 못할 수 있다. RFC 2350의 Security Considerations는 이 메모가 인시던트에 대한 특정 대응과 반응이 아니라 CSIRT가 제공하는 대응의 적절한 기술을 다룬다고 명시한다.

FIRST 프레임워크는 보고 접수, 인시던트 분석, 아티팩트 및 포렌식 증거 분석, 완화와 복구, 조율, 위기 관리 지원을 별개의 잠재적 제공 항목으로 나열함으로써 이 입체성을 유지한다. 또한 특정 팀의 역량, 용량, 성숙도 또는 품질을 평가하지 않음을 명시적으로 밝힌다. 공유된 어휘는 성과 감사가 아니다.

공격자 귀속에는 조율 이상의 것이 필요하다

RFC 2350은 CSIRT 설명에 일반적인 귀속(attribution) 판정을 부여하지 않는다. 이 문서는 보안 통신, 공개, 협력, 정보 범주화, 다른 사이트와의 접촉을 다룬다. 그 어느 필드도 공격자를 식별하지 않는다.

귀속에는 기술 아티팩트, 타임라인, 인프라, 신원 증거, 인텔리전스, 경쟁하는 가설, 법적·조직적 기준이 관여할 수 있다.RFC 3227은 증거 수집과 보존을 독립된 학제로 다루며, 관련 시스템과 증거원 식별을 포함한다. FIRST 역시 확인된 인시던트 분석과 아티팩트·포렌식 증거 분석을 분리한다. 서비스 페이지는 그런 분석을 제공한다고 말할 수는 있다. 그러나 누락된 아티팩트를 채우거나 그것이 무엇을 증명하는지 판단할 수는 없다.

방어 가능한 서술은 더 좁다. “이 CSIRT는 보고를 접수하고 조율을 제공한다”는 인터페이스 서술이다. “이 CSIRT는 이 인시던트를 행위자 X에게 귀속했다”는 날짜가 명시된 결론, 방법, 범위, 신뢰도, 뒷받침 증거를 요구한다. 그 기록이 없다면 행위자는 확립되지 않은 채 남는다.

복구는 측정된 상태이지 서비스 레이블이 아니다

RFC 2350은 복구를 영향받은 시스템과 서비스를 인시던트 이전 상태로 되돌리는 데 대한 지원(aid)으로 정의한다. “지원”이라는 단어가 중요하다. 그것이 실행이나 최종 권한을 반드시 CSIRT에 두는 것은 아니다.

현재의NIST SP 800-61 Rev. 3는 복구 주장이 통상적으로 필요로 하는 운영 기록을 보여준다. 복구 조치가 선택되고 수행되며, 복원 자산이 점검되고, 필수 서비스와 정상 운영이 확인되고, 복원된 시스템이 모니터링되고, 자산 무결성이 검증되고, 기준에 따라 복구 종료가 선언되며, 문서화가 완료된다.

이것들은 케이스에 대한 관찰과 결정이다. 복구를 도우겠다는 공개된 약속은 그 어느 것도 증명하지 못한다. 마찬가지로 로그인 화면의 등장은 근본 원인이 제거되었는지, 숨겨진 지속성이 소멸되었는지, 데이터 무결성이 복원되었는지, 의존 서비스가 정합되었는지를 보여주지 않는다.

출처와 증거의 한계

  • RFC 2350— 1998년 BCP로서, CSIRT 설명 템플릿과 컨스티튜언시, 권한, 분류, 조율, 선택적 해결 간의 구분을 담고 있다.
  • FIRST CSIRT Services Framework 2.1— 이후의 잠재적 서비스와 결과에 대한 분류 체계. 팀의 역량, 용량, 성숙도, 품질을 평가하지 않는다.
  • NIST SP 800-61 Rev. 3— 2025년 4월의 대응 및 복구 지침으로, 케이스별 복구 증거를 식별하는 데 사용되었다.
  • RFC 3227— 증거 수집 및 보존에 관한 별도의 지침.

이 분석은 특정 CSIRT를 감사하거나 응답 지연을 측정하거나 나열된 서비스가 수행되지 않았다고 주장하지 않는다. 증거 경계를 밝힌다. 즉, 선언은 지원에 대한 합리적 기대를 만들 수 있지만, 실행과 결과는 케이스 기록을 필요로 한다.