NIST SP 800-61
더 많은 작업
NIST SP 800-61(Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile)은 미국 국립표준기술연구소(NIST, National Institute of Standards and Technology)가 발행하는 사이버보안 사고 대응 지침으로, 조직이 침해사고의 탐지·분석·대응·복구 활동을 사이버보안 위험 관리체계에 통합하기 위한 권고사항과 고려사항을 제시하는 NIST SP 800 시리즈의 특별간행물이다.
NIST SP 800-61은 침해사고(Cybersecurity Incident)에 대한 조직의 대응 역량을 확보하고, 사고로 인한 피해를 최소화하기 위한 지침이다.
사고 대응(Incident Response)은 침해사고를 탐지하고 분석하여 피해 확산을 방지하며, 원인을 제거하고 정상적인 업무 운영을 복구하는 활동을 포함한다.
NIST SP 800-61은 사고 대응을 독립적인 기술적 절차가 아니라 조직 전체의 사이버보안 위험 관리(Cybersecurity Risk Management)에 포함되는 활동으로 다룬다.[1]
2025년 4월 발행된 Revision 3부터는 NIST 사이버보안 프레임워크(CSF) 2.0의 여섯 가지 기능을 중심으로 사고 대응 활동을 구성한다.
주요 목적은 다음과 같다.
- 사고 대응 활동을 조직 전체의 사이버보안 위험 관리에 통합.
- 침해사고의 발생 가능성과 피해 규모 감소.
- 사고 탐지·대응·복구 활동의 효율성과 효과성 향상.
- 조직 내부 및 외부 관계자의 사고 대응 역할과 책임 명확화.
- 사고 대응 과정에서 발견된 문제를 지속적으로 개선.
- 사고 대응 활동과 위험 관리 활동에 공통적인 용어와 분류체계 제공.
| 항목 | 내용 |
|---|---|
| 문서 번호 | NIST SP 800-61 |
| 현행 문서명 | Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile |
| 이전 문서명 | Computer Security Incident Handling Guide |
| 발행기관 | 미국 국립표준기술연구소(NIST) |
| 최초 발행 | 2004년 |
| 현행 개정판 | Revision 3 |
| 현행판 발행일 | 2025년 4월 3일 |
| 주요 분야 | 침해사고 대응, 사이버보안 위험 관리, 사고 탐지·분석·복구 |
| 기반 프레임워크 | NIST Cybersecurity Framework 2.0 |
| 핵심 구성 | 사고 대응 준비, 탐지, 대응, 복구 및 지속적 개선 |
| 공식 문서 | NIST SP 800-61 Rev. 3 |
2026년 10월 23일 기준 NIST 공식 간행물 페이지에서 확인되는 현행 최종 발행본은 Revision 3이다. Revision 3은 2012년 발행된 Revision 2를 대체한다.[2]
NIST SP 800-61은 2004년 Computer Security Incident Handling Guide라는 제목으로 처음 발행되었다.
초기 문서는 컴퓨터 보안 사고를 처리하는 조직과 담당자가 사고 대응 역량을 구축하고, 실제 사고에 체계적으로 대응할 수 있도록 하는 데 초점을 맞추었다.
사고 대응팀의 구성, 사고 처리 절차, 기술적 분석, 피해 제한 및 복구 등 실무적인 내용을 다루었다.
2012년 8월 6일 Revision 2가 발행되었다.
Revision 2는 사고 대응을 다음 네 단계의 생애주기로 구성했다.[3]
- 준비(Preparation)
- 탐지 및 분석(Detection and Analysis)
- 봉쇄·근절·복구(Containment, Eradication, and Recovery)
- 사후 활동(Post-Incident Activity)
이 모델은 사고가 발생하기 전에 대응 역량을 준비하고, 사고를 탐지·분석한 뒤 피해를 제한하고 시스템을 복구하며, 사후 분석을 통해 다음 사고에 대비하는 순환 구조이다.
Revision 2는 사고 대응 조직의 운영과 기술적 사고 처리 절차를 상세하게 설명했다.
특히 다음과 같은 실무 분야를 다루었다.
- 사고 대응팀의 구성과 운영 방식.
- 사고 대응 정책과 계획 수립.
- 보안 이벤트의 분석과 사고 여부 판단.
- 사고의 우선순위 결정.
- 사고의 봉쇄 전략.
- 악성코드 및 침입 원인의 제거.
- 시스템 복구.
- 디지털 증거 수집과 보존.
- 사고 보고 및 사후 분석.
- 외부 기관과의 정보 공유.
이 네 단계 모델은 사고 대응 교육과 보안 실무에서 널리 활용되었으나, 현행 Revision 3의 기본 구성과는 구분해야 한다.
2024년 4월 3일 Revision 3의 공개 초안이 발표되었고, 2025년 4월 3일 최종본이 발행되었다.
Revision 3의 문서명은 Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile로 변경되었다.
NIST는 현대의 사이버보안 사고가 빈번하고 복잡하며, 사고 복구에 수주 또는 수개월이 걸릴 수 있다는 점을 개정 배경으로 설명했다.
또한 사고 대응 활동이 특정 대응팀에 국한되지 않고 조직 전체의 업무 및 위험 관리 활동과 긴밀하게 연계되어야 한다고 보았다.[4]
주요 변경사항은 다음과 같다.
- 기존의 4단계 사고 대응 생애주기를 CSF 2.0의 6개 기능에 기반한 모델로 재구성.
- 사고 대응을 조직 전체의 사이버보안 위험 관리 활동에 통합.
- 사고 발생 이전의 준비 활동과 실제 사고 대응 활동을 구분.
- 사고 대응 과정 전반에서 지속적 개선을 수행하도록 강조.
- 경영진, 기술 담당자, 법무 담당자, 외부 서비스 제공업체 등 다양한 이해관계자의 역할 반영.
- 사고 대응 정책과 절차의 조직적 관리 강조.
- CSF 2.0 커뮤니티 프로파일을 이용한 권고사항과 고려사항 제공.
- 기술별 세부 구현 지침은 별도의 온라인 자료를 통해 제공하도록 구성.
Revision 3은 기존의 사고 대응 절차를 단순히 6단계로 늘린 문서가 아니다.
사고 대응을 조직의 위험 관리체계에 통합하고, 이를 CSF 2.0의 기능·범주·하위범주와 연결하는 방식으로 접근법을 변경한 것이다.
NIST SP 800-61 Revision 3은 이벤트(Event)와 사이버보안 사고(Cybersecurity Incident)를 구분한다.
이벤트(Event)는 물리적·가상 시스템, 네트워크, 서비스, 클라우드 환경 등 컴퓨팅 자산과 관련하여 관찰할 수 있는 모든 발생 사항을 의미한다.
대표적인 이벤트는 다음과 같다.
- 사용자 로그인 시도.
- 소프트웨어 업데이트 설치.
- 애플리케이션의 요청 처리.
- 네트워크 연결.
- 시스템 설정 변경.
이벤트가 발생했다는 사실만으로 보안 사고가 발생한 것은 아니다.
부정적 이벤트(Adverse Event)는 부정적인 결과와 관련된 사건을 의미한다.
NIST SP 800-61은 그중 사이버보안에 부정적인 영향을 미칠 수 있는 이벤트를 주요 분석 대상으로 한다.
사이버보안 사고(Cybersecurity Incident)는 정보나 정보시스템의 기밀성·무결성·가용성을 실제로 또는 임박하게 위협하거나, 법률·보안 정책·보안 절차·허용 가능한 사용 정책을 위반하거나 위반할 위험이 있는 사건을 의미한다.[1]
| 구분 | 의미 | 예시 |
|---|---|---|
| 이벤트 | 컴퓨팅 자산과 관련하여 관찰되는 발생 사항 | 정상 로그인, 소프트웨어 업데이트 |
| 부정적 사이버보안 이벤트 | 사이버보안에 부정적인 영향을 미칠 가능성이 있는 이벤트 | 의심스러운 인증 시도, 비정상적인 네트워크 활동 |
| 사이버보안 사고 | 보안 목표를 침해하거나 관련 정책 등을 위반하는 실제 또는 임박한 사건 | 계정 탈취, 랜섬웨어 감염, 무단 접근 |
부정적 이벤트가 탐지되면 추가 분석을 통해 실제 사이버보안 사고가 발생했는지 판단해야 한다.
NIST SP 800-61 Revision 3에서 제시하는 사고 사례는 다음과 같다.
- 봇넷을 이용한 대량 접속 요청으로 인터넷 서비스의 가용성을 저해하는 공격.
- 서비스형 소프트웨어(SaaS) 제공업체의 관리자 인증정보 탈취.
- 기업 네트워크 침입 후 산업제어시스템을 조작하여 중요 설비의 운영을 방해하는 공격.
- 랜섬웨어를 이용한 시스템 사용 방해 및 정보 유출.
- 피싱을 통한 사용자 계정 탈취와 금융사기.
- 네트워크 관리 장비의 취약점을 악용한 무단 접근.
- 공급업체의 소프트웨어를 변조하여 고객에게 배포하는 공급망 공격.
사고 유형에 따라 탐지 방법과 대응 전략, 복구 절차가 달라질 수 있다.
따라서 조직은 모든 사고에 동일한 세부 절차를 적용하기보다 사고 유형과 위험 수준에 맞는 대응 방법을 마련해야 한다.
Revision 2의 사고 대응 생애주기는 다음과 같다.
| 단계 | 영문 | 주요 활동 |
|---|---|---|
| 준비 | Preparation | 대응 조직 구성, 정책 수립, 도구와 절차 준비 |
| 탐지 및 분석 | Detection and Analysis | 이상징후 탐지, 사고 여부 확인, 피해 범위와 원인 분석 |
| 봉쇄·근절·복구 | Containment, Eradication, and Recovery | 피해 확산 차단, 공격 원인 제거, 시스템 복구 |
| 사후 활동 | Post-Incident Activity | 사고 기록, 대응 결과 분석, 재발 방지 및 절차 개선 |
이 모델은 사고 대응의 시간적 흐름을 이해하는 데 유용하다.
다만 실제 사고에서는 여러 단계가 동시에 수행되거나 반복될 수 있다.
예를 들어 사고 분석이 완료되기 전에 긴급한 봉쇄 조치가 필요할 수 있으며, 복구 중 새로운 침해 흔적이 발견되어 추가 분석과 봉쇄가 이루어질 수도 있다.
Revision 3은 NIST 사이버보안 프레임워크 2.0의 여섯 가지 기능을 이용하여 사고 대응 활동을 구성한다.
| 기능 | 약어 | 주요 내용 | 사고 대응과의 관계 |
|---|---|---|---|
| Govern | GV | 사이버보안 위험 관리 전략·정책·거버넌스 | 대응 정책과 책임 및 의사결정 체계 수립 |
| Identify | ID | 자산과 사이버보안 위험의 식별 및 이해 | 사고 대응에 필요한 자산·위험 정보 확보와 개선 |
| Protect | PR | 사이버보안 위험을 관리하기 위한 보호조치 | 사고 예방 및 피해 규모 감소 |
| Detect | DE | 사이버 공격과 침해 가능성 탐지 및 분석 | 사고 탐지와 초기 분석 |
| Respond | RS | 탐지된 사이버보안 사고에 대한 조치 | 사고 관리, 분석, 봉쇄, 근절 및 보고 |
| Recover | RC | 사고로 영향을 받은 자산과 업무 복구 | 시스템 및 서비스 복구와 정상 운영 확인 |
NIST는 여섯 가지 기능을 다음과 같이 구분한다.[1]
- 사고 대응 준비: Govern, Identify, Protect.
- 실제 사고 대응: Detect, Respond, Recover.
- 지속적 개선: Identify 기능의 Improvement 범주(ID.IM).
Govern·Identify·Protect는 사고 대응에 필요한 기반을 제공하지만, 그 자체가 모두 실제 사고 대응 활동에 해당하는 것은 아니다.
반면 Detect·Respond·Recover는 사고를 발견하고 처리하며 정상적인 운영을 회복하는 직접적인 대응 활동이다.
ID.IM은 사고 대응 과정뿐 아니라 모든 사이버보안 위험 관리 활동에서 얻은 교훈을 지속적으로 반영하도록 한다.
Revision 3은 기존 4단계 생애주기와 CSF 2.0 기능의 대응 관계를 제시한다.
| Revision 2의 단계 | Revision 3의 관련 CSF 기능 |
|---|---|
| 준비 | Govern, Identify, Protect |
| 탐지 및 분석 | Detect, Identify의 Improvement 범주 |
| 봉쇄·근절·복구 | Respond, Recover, Identify의 Improvement 범주 |
| 사후 활동 | Identify의 Improvement 범주 |
두 모델은 완전히 동일한 절차를 서로 다른 이름으로 표현한 것은 아니다.
Revision 3은 사고 대응을 조직 전체의 위험 관리에 연결하고, 개선 활동을 사고 종료 후에만 수행하는 것이 아니라 사고 대응 과정 전반에 걸쳐 수행하도록 한다.
또한 NIST는 모든 조직이 반드시 CSF 2.0 기반의 생애주기 모델을 사용해야 한다고 요구하지 않는다.
조직은 업무 환경과 위험 수준에 적합한 사고 대응 모델을 선택할 수 있다.
Revision 3에서 사고 대응 준비는 Govern·Identify·Protect 기능을 중심으로 이루어진다.
Govern(GV)은 조직의 사이버보안 위험 관리 전략과 정책, 책임 및 감독체계를 수립하는 기능이다.
사고 대응 관점에서 주요 활동은 다음과 같다.
- 사고 대응 정책과 계획 수립.
- 사고 대응 책임자와 담당 조직 지정.
- 사고 대응에 필요한 예산과 자원 확보.
- 사고 발생 시 의사결정 권한 정의.
- 사고 심각도와 우선순위 판단 기준 수립.
- 법령·규제·계약상 사고 통지 및 신고 의무 식별.
- 외부 서비스 제공업체와의 책임 분담.
- 사고 대응 성과의 감독 및 평가.
특히 중요 시스템의 중단이나 재구축과 같은 조치는 업무 운영에 중대한 영향을 줄 수 있으므로 의사결정 권한을 사전에 정의할 필요가 있다.
Identify(ID)는 조직의 자산과 위험을 이해하는 기능이다.
사고 대응에 필요한 주요 정보는 다음과 같다.
- 하드웨어 및 소프트웨어 자산 목록.
- 네트워크와 시스템 간 연결관계.
- 중요 업무와 핵심 서비스.
- 외부 서비스 및 공급업체 의존관계.
- 취약점과 위협 정보.
- 업무별 위험 수준.
- 복구 우선순위에 영향을 미치는 자산 중요도.
사고 발생 시 영향을 받은 시스템과 업무를 신속하게 파악하려면 정확한 자산 목록과 의존관계 정보가 필요하다.
예를 들어 침해된 서버가 어떤 업무시스템과 연결되어 있는지 확인할 수 없다면 사고의 영향 범위를 판단하기 어려울 수 있다.
Protect(PR)은 사이버보안 위험을 관리하기 위한 보호조치를 적용하는 기능이다.
사고 대응 준비에 도움이 되는 활동은 다음과 같다.
- 사용자 및 관리자 접근통제.
- 인증정보 보호.
- 보안 교육과 훈련.
- 데이터 보호.
- 시스템 보안 설정.
- 소프트웨어 보안 관리.
- 시스템과 기반시설의 복원력 확보.
이러한 보호조치는 사고 발생 가능성을 낮추거나 사고가 발생했을 때 피해 규모를 제한하는 데 기여한다.
다만 Protect 기능은 사고 대응만을 위한 기능이 아니며 조직의 전반적인 사이버보안 위험 관리를 지원한다.
Detect(DE)는 사이버 공격과 침해 가능성을 탐지하고 분석하는 기능이다.
Revision 3은 탐지 활동을 크게 두 범주로 구분한다.
- DE.CM: Continuous Monitoring.
- DE.AE: Adverse Event Analysis.
지속적 모니터링(Continuous Monitoring)은 시스템과 네트워크 및 운영 환경에서 발생하는 이벤트를 지속적으로 관찰하는 활동이다.
대표적인 모니터링 대상은 다음과 같다.
- 네트워크 트래픽.
- 운영체제 및 애플리케이션 로그.
- 사용자 인증 및 접근 기록.
- 보안장비의 탐지 결과.
- 클라우드 서비스의 활동 기록.
- 중요 시스템의 구성 변경.
- 외부 서비스 제공업체의 관련 활동.
SIEM과 SOAR 등의 기술을 이용하여 이벤트를 수집하고 분석할 수 있다.
다만 자동화된 탐지 기술만으로 모든 공격을 발견할 수 있는 것은 아니므로 필요에 따라 수동 분석과 다른 탐지 방법을 병행해야 한다.
부정적 이벤트 분석(Adverse Event Analysis)은 탐지된 이벤트가 실제 사고를 의미하는지 판단하는 활동이다.
NIST는 다음과 같은 분석을 권고한다.
- 여러 로그와 이벤트 출처의 정보 상관분석.
- 의심스러운 활동의 맥락 파악.
- 위협 인텔리전스와 침해지표 활용.
- 이벤트의 영향 범위 추정.
- 사고 대응 담당자에게 분석 결과 전달.
- 사전에 정의한 기준에 따라 사고 발생 여부 판단.
특히 DE.AE-08은 부정적 이벤트가 조직이 정의한 사고 기준을 충족하는 경우 사고로 선언하도록 한다.
사고 선언에는 알려진 오탐 가능성과 이벤트의 특성을 함께 고려해야 한다.
단순한 보안 경보와 실제 사고를 구분하는 것은 대응 자원의 효율적인 배분을 위해 중요하다.[1]
Respond(RS)는 탐지된 사이버보안 사고에 대해 실제 대응 조치를 수행하는 기능이다.
Revision 3의 Respond 기능은 다음 네 범주로 구성된다.
| 식별자 | 범주 | 주요 내용 |
|---|---|---|
| RS.MA | Incident Management | 사고 관리 |
| RS.AN | Incident Analysis | 사고 분석 |
| RS.CO | Incident Response Reporting and Communication | 사고 대응 보고 및 의사소통 |
| RS.MI | Incident Mitigation | 사고 완화 |
사고 관리(Incident Management)는 사고 대응 활동을 총괄하고 우선순위와 자원을 조정하는 활동이다.
주요 활동은 다음과 같다.
- 사고 보고의 접수 및 검증.
- 사고 유형 분류.
- 사고의 심각도와 긴급성 판단.
- 대응 우선순위 결정.
- 사고 대응 계획 실행.
- 필요한 경우 외부 대응기관과 협력.
- 대응 진행 상황 추적.
- 사고 복구 개시 기준 적용.
RS.MA-02는 사고 보고를 접수하여 실제 사고 발생 여부를 검증하고 심각도와 긴급성을 추정하도록 한다.
RS.MA-03은 사고를 유형별로 분류하고 우선순위를 결정하도록 한다.
사고 유형의 예시는 다음과 같다.
- 정보 유출.
- 랜섬웨어.
- 계정 탈취.
- 서비스 거부 공격.
대응 우선순위를 결정할 때는 사고의 범위, 예상 영향, 시간적 긴급성 및 대응 자원의 가용성을 고려한다.
또한 신속한 복구와 추가적인 공격자 관찰 또는 상세 조사 사이에서 적절한 대응 전략을 선택해야 할 수 있다.
RS.MA-04는 필요한 경우 사고 대응의 자원을 확대하거나 상위 관리자의 의사결정을 요청하도록 한다.
사고 분석(Incident Analysis)은 사고가 어떻게 발생했고 어떤 영향을 미쳤는지 조사하는 활동이다.
주요 분석 대상은 다음과 같다.
- 최초 침입 시점.
- 공격자의 침입 경로.
- 악용된 취약점.
- 공격에 사용된 계정과 권한.
- 공격자의 활동 순서.
- 침해된 시스템과 자산.
- 정보 접근 및 유출 여부.
- 악성코드와 지속성 확보 수단.
- 사고의 근본 원인.
RS.AN-03은 사고 과정에서 발생한 사건과 근본 원인을 파악하도록 한다.
사고 분석에서는 단순히 공격에 사용된 기술적 취약점만 확인하는 것이 아니라, 해당 취약점이 악용될 수 있었던 구조적·관리적 원인도 검토할 수 있다.
RS.AN-06은 사고 조사 과정에서 수행한 조치를 기록하고 기록의 무결성과 출처를 보존하도록 한다.
RS.AN-07은 사고 관련 데이터와 메타데이터를 수집하고 무결성과 출처를 보존하도록 한다.
사고 조사 과정에서 확보한 로그, 파일, 메모리 및 네트워크 기록은 디지털 포렌식에 활용할 수 있다.
수사나 법적 절차에 활용될 가능성이 있는 경우에는 증거의 보관 및 인계 기록(Chain of Custody)도 고려해야 한다.
사고 대응 보고 및 의사소통(Incident Response Reporting and Communication)은 사고 대응 활동을 내부 및 외부 관계자와 조정하고 필요한 정보를 전달하는 활동이다.
주요 대상은 다음과 같다.
- 경영진.
- 사고 대응팀.
- 시스템 및 업무 책임자.
- 법무 및 개인정보 보호 담당자.
- 외부 서비스 제공업체.
- 규제기관.
- 수사기관.
- 영향을 받은 고객과 협력업체.
RS.CO-02는 사고와 관련된 내부 및 외부 이해관계자에게 필요한 통지를 수행하도록 한다.
통지와 보고는 조직에 적용되는 법령·규제·계약 및 내부 정책에 따라 이루어져야 한다.
NIST SP 800-61은 특정 국가의 모든 사고 신고 기한을 통일하여 규정하지 않는다.
실제 신고 대상과 기한은 해당 조직에 적용되는 법령과 규제에 따라 별도로 판단해야 한다.
사고 완화(Incident Mitigation)는 사고의 확산을 방지하고 영향을 줄이는 활동이다.
주요 활동은 봉쇄(Containment)와 근절(Eradication)이다.
봉쇄는 공격의 확산과 추가 피해를 제한하는 활동이다.
대표적인 조치는 다음과 같다.
- 침해 시스템의 네트워크 격리.
- 공격자의 접근 차단.
- 탈취된 계정의 비활성화.
- 악성 도메인 또는 IP 주소 차단.
- 침해된 서비스의 일시 중단.
- 외부 통신 경로 제한.
근절은 공격자의 지속적인 접근과 사고의 원인을 제거하는 활동이다.
대표적인 조치는 다음과 같다.
- 악성코드 제거.
- 백도어와 비인가 계정 제거.
- 취약점 보안 패치.
- 탈취된 인증정보 변경.
- 악용된 설정 오류 수정.
- 필요시 침해 시스템의 재구축.
NIST는 자동화된 봉쇄 기능과 함께 담당자가 직접 봉쇄 조치를 선택하고 수행할 수 있는 수단도 고려하도록 한다.
특히 자동화된 조치가 업무 중단을 초래할 수 있는 환경에서는 사고의 심각성과 업무 영향을 고려하여 조치를 결정해야 한다.
Recover(RC)는 침해사고로 영향을 받은 시스템과 업무를 정상적인 운영 상태로 복구하는 기능이다.
Revision 3의 Recover 기능은 다음 두 범주로 구성된다.
- RC.RP: Incident Recovery Plan Execution.
- RC.CO: Incident Recovery Communication.
복구 계획 실행(Incident Recovery Plan Execution)은 사고 대응 계획에 따라 복구 작업을 선정하고 수행하는 활동이다.
대표적인 복구 조치는 다음과 같다.
- 신뢰할 수 있는 백업에서 시스템 복원.
- 침해된 시스템 재설치 또는 재구축.
- 변조된 파일 교체.
- 보안 패치 적용.
- 인증정보 변경.
- 보안 설정 강화.
- 정상적인 업무 서비스 재개.
RC.RP-03은 복구에 사용하기 전에 백업과 기타 복구 자산의 무결성을 확인하도록 한다.
백업에 악성코드가 포함되어 있거나 파일이 손상된 경우 복구 과정에서 문제가 재발할 수 있기 때문이다.
RC.RP-05는 복구된 자산의 무결성을 검증하고 시스템과 서비스가 정상적으로 작동하는지 확인하도록 한다.
NIST는 시스템을 실제 운영 환경에 다시 투입하기 전에 사고의 근본 원인을 조치하고 복구 작업의 적절성을 확인하도록 권고한다.
모든 시스템을 동시에 복구할 수 없는 경우에는 업무 중요도와 가용 자원을 고려하여 복구 우선순위를 결정해야 한다.
주요 고려사항은 다음과 같다.
- 핵심 업무에 미치는 영향.
- 서비스 중단에 따른 피해.
- 시스템 간 의존관계.
- 복구에 필요한 시간과 자원.
- 복구 작업의 신뢰성.
- 복구 과정에서 발생할 수 있는 추가 위험.
NIST는 복구 작업의 신속성뿐 아니라 정확성과 신뢰성도 함께 고려하도록 한다.
복구 과정에서 새로운 위험이 발견되거나 조직의 요구사항이 변경되면 복구 계획을 조정할 수 있다.
RC.RP-06은 사전에 정의한 기준에 따라 사고 복구의 종료를 선언하고 관련 문서를 완성하도록 한다.
복구 완료를 판단할 때는 다음과 같은 사항을 확인할 수 있다.
- 중요 서비스가 정상적으로 작동하는가.
- 복구된 시스템의 무결성이 확인되었는가.
- 침해 원인이 적절하게 조치되었는가.
- 업무 책임자가 복구 결과를 확인했는가.
- 복구 이후 필요한 모니터링이 수행되고 있는가.
- 사고 대응과 복구 과정이 문서화되었는가.
사고 대응이 종료되더라도 위험 관리와 지속적 모니터링은 계속 수행된다.
Revision 3은 사고 대응 과정에서 발견된 문제를 지속적으로 개선하는 것을 강조한다.
이는 CSF 2.0의 Identify 기능에 포함된 ID.IM(Improvement) 범주와 연결된다.
주요 하위범주는 다음과 같다.[1]
| 식별자 | 주요 내용 |
|---|---|
| ID.IM-01 | 평가 결과를 바탕으로 개선사항 식별 |
| ID.IM-02 | 보안 시험과 훈련 결과를 바탕으로 개선사항 식별 |
| ID.IM-03 | 실제 운영 절차와 활동 수행 결과를 바탕으로 개선사항 식별 |
| ID.IM-04 | 사고 대응 계획과 관련 사이버보안 계획의 수립·유지·개선 |
기존 사고 대응 모델에서는 사후 활동을 사고 처리의 마지막 단계로 표현했다.
Revision 3에서는 개선사항을 사고 대응과 복구가 완전히 종료된 이후에만 식별하는 것이 아니라, 관련 사실이 확인되는 시점부터 분석하고 공유하도록 한다.
예를 들어 사고 조사 중 새로운 공격 기법이 확인되었다면 복구 완료를 기다리지 않고 탐지 규칙과 보호조치를 개선할 수 있다.
사고 대응 훈련은 조직의 대응 계획과 절차가 실제로 작동하는지 확인하기 위한 활동이다.
대표적인 훈련 방식은 다음과 같다.
- 모의 상황을 바탕으로 대응 절차를 논의하는 테이블탑 훈련.
- 기술적 사고 대응 절차의 기능 시험.
- 여러 부서가 참여하는 통합 사고 대응 훈련.
- 외부 서비스 제공업체와의 공동 대응 훈련.
- 복구 절차 및 백업 복원 시험.
훈련 결과는 사고 대응 계획과 조직의 위험 관리체계를 개선하는 데 활용한다.
NIST는 사고 대응 훈련과 시험에 관한 추가 자료로 NIST SP 800-84를 참고하도록 안내한다.
Revision 3은 사고 대응의 성공이 전문 대응팀뿐 아니라 조직 내부와 외부의 다양한 이해관계자에게 달려 있다고 설명한다.
주요 역할은 다음과 같다.[1]
| 역할 | 주요 책임 |
|---|---|
| 경영진 | 사고 대응 감독, 자원 배분, 중요 대응 조치에 관한 의사결정 |
| 사고 대응 담당자 | 사고 확인, 증거 수집·분석, 우선순위 결정, 피해 제한 및 복구 지원 |
| 기술 담당자 | 시스템·네트워크·클라우드·소프트웨어의 분석 및 복구 |
| 법무 담당자 | 법적 의무 검토, 계약 검토, 소송 및 수사 관련 자문 |
| 대외협력 및 홍보 담당자 | 언론 대응, 대외 발표, 이해관계자와의 의사소통 |
| 인사 담당자 | 임직원 관련 사고와 내부자 문제에 관한 업무 지원 |
| 물리적 보안 담당자 | 시설 및 물리적 자산과 관련된 사고 대응 지원 |
| 업무 및 자산 책임자 | 업무 영향 분석, 복구 우선순위 결정 및 정상 운영 확인 |
| 외부 서비스 제공업체 | 계약에 따라 탐지·분석·대응·복구 등의 업무 수행 |
사고 대응팀은 일반적으로 침해사고 대응 조직(CSIRT, Computer Security Incident Response Team) 또는 CERT(Computer Emergency Response Team)로 구성할 수 있다.
조직은 다음과 같은 방식으로 대응 역량을 확보할 수 있다.
- 내부 전담 대응팀 운영.
- 외부 전문업체에 사고 대응 업무 위탁.
- 필요시 외부 전문가와 대응기관의 지원 활용.
- 내부 대응팀과 외부 전문조직을 결합한 혼합형 운영.
규모가 큰 조직은 여러 사고 대응팀을 운영할 수 있다.
이 경우 조직 전체에서 일관된 대응 절차와 교육 및 정보 공유가 이루어지도록 조정체계를 마련해야 한다.
클라우드 서비스 제공업체(CSP), 관리형 보안 서비스 제공업체(MSSP), 인터넷 서비스 제공업체(ISP) 등은 사고 대응에 참여할 수 있다.
외부업체가 사고 대응 업무의 일부를 수행하는 경우에는 다음 사항을 계약과 운영 절차에서 명확히 정의해야 한다.
- 사고 탐지 및 보고 책임.
- 사고 대응 시 정보 공유 범위.
- 시스템 접근 및 조치 권한.
- 서비스 중단이나 격리 조치의 승인 권한.
- 고객 및 관계기관에 대한 통지 책임.
- 사고 관련 정보의 기밀성 보호.
- 사고 대응 기록과 증거의 관리.
외부업체가 사고 대응을 수행하더라도 조직의 모든 위험과 책임이 자동으로 이전되는 것은 아니다.
또한 외부업체가 조직의 중요 시스템에 높은 권한으로 접근할 수 있다는 점에서 해당 업체의 내부자 위협과 침해 가능성도 고려해야 한다.
NIST SP 800-61 Revision 3은 조직이 사고 대응 정책(Policy), 계획(Plan), 프로세스(Process), 절차(Procedure)를 수립하도록 권고한다.
사고 대응 정책에는 일반적으로 다음 사항을 포함한다.
- 경영진의 사고 대응에 대한 의지.
- 정책의 목적과 목표.
- 적용 범위.
- 이벤트와 사고의 정의.
- 역할과 책임 및 권한.
- 사고 우선순위와 심각도 판단 기준.
- 복구 개시 기준.
- 업무 운영의 유지 및 복구에 관한 기준.
- 성과 측정 기준.
특히 시스템의 격리, 중단, 압수 또는 재구축과 같은 조치를 누가 승인할 수 있는지 명확히 정의해야 한다.
사고 대응 절차는 실제 사고가 발생했을 때 담당자가 수행해야 하는 작업을 구체적으로 설명한다.
조직은 발생 가능한 모든 사고 유형에 대해 상세한 절차를 마련하기 어렵기 때문에, 자주 발생하는 사고와 업무에 중대한 영향을 미치는 사고를 중심으로 절차를 마련할 수 있다.
주요 절차는 다음과 같다.
- 사고 신고 접수.
- 초기 분석 및 사고 선언.
- 사고 심각도 분류.
- 대응 담당자 지정.
- 피해 확산 방지.
- 사고 원인 조사.
- 증거 수집 및 보존.
- 외부기관 신고 및 통지.
- 시스템 복구.
- 사고 종료 및 사후 보고.
플레이북(Playbook)은 특정 사고 유형이나 상황에서 수행할 작업을 실행 가능한 순서와 형태로 정리한 문서이다.
예를 들어 랜섬웨어 사고 대응 플레이북에는 다음과 같은 작업이 포함될 수 있다.
- 의심 시스템 식별.
- 사고 대응팀 통보.
- 침해 시스템 격리.
- 관련 로그와 증거 확보.
- 침해 범위 분석.
- 악성코드 및 침입 경로 제거.
- 백업의 무결성 확인.
- 시스템 복구.
- 재침해 여부 모니터링.
- 사고 결과 보고 및 개선사항 반영.
이 절차는 플레이북의 구성 예시이며, NIST SP 800-61이 모든 랜섬웨어 사고에 동일한 순서를 강제하는 것은 아니다.
NIST는 플레이북 작성의 참고자료로 미국 사이버보안·인프라보안국(CISA)의 사고 및 취약점 대응 플레이북을 안내한다.[5]
Revision 3의 핵심 구성요소는 CSF 2.0 커뮤니티 프로파일(Community Profile)이다.
커뮤니티 프로파일은 특정 분야나 기술, 위협 또는 공동의 목표를 가진 조직들이 활용할 수 있도록 CSF의 사이버보안 성과를 선정하고 우선순위를 부여한 자료이다.
NIST SP 800-61은 사고 대응을 위한 커뮤니티 프로파일을 두 부분으로 구분한다.[1]
| 구분 | 내용 | 관련 기능 |
|---|---|---|
| Table 2 | Preparation and Lessons Learned | Govern, Identify, Protect 및 Identify의 Improvement 범주 |
| Table 3 | Incident Response | Detect, Respond, Recover |
각 표는 CSF의 기능(Function), 범주(Category), 하위범주(Subcategory)에 대응하는 권고사항과 고려사항을 제공한다.
커뮤니티 프로파일은 각 CSF 요소의 사고 대응 관련 우선순위를 세 단계로 구분한다.
| 우선순위 | 영문 | 의미 |
|---|---|---|
| 높음 | High | 대부분의 조직에서 핵심적인 사고 대응 활동에 해당 |
| 중간 | Medium | 대부분의 조직에서 사고 대응 활동을 직접 지원 |
| 낮음 | Low | 대부분의 조직에서 사고 대응 활동을 간접적으로 지원 |
이 우선순위는 사고 대응과의 관련성을 나타낸다.
Low로 분류된 항목이 조직 전체의 사이버보안 위험 관리에서 중요하지 않다는 의미는 아니다.
또한 조직은 업무 특성과 위험 수준에 따라 프로파일의 우선순위를 조정할 수 있다.
커뮤니티 프로파일은 각 항목에 다음 세 가지 유형의 정보를 제공한다.
| 식별자 | 영문 | 의미 |
|---|---|---|
| R | Recommendation | 조직이 수행하도록 권고하는 사항 |
| C | Consideration | 조직이 수행 여부를 고려할 사항 |
| N | Note | 추가 설명 및 참고 정보 |
각 항목은 CSF 식별자와 결합하여 고유하게 표시할 수 있다.
예를 들어 GV.OC-03.R1은 GV.OC-03 하위범주에 대한 첫 번째 권고사항을 의미한다.
이러한 식별 방식은 조직이 사고 대응 요구사항을 관리하거나 다른 보안 통제 및 지침과 연결하는 데 활용할 수 있다.
Revision 3의 커뮤니티 프로파일에는 사고 대응을 위한 다양한 권고사항이 포함되어 있다.
대표적인 항목은 다음과 같다.[1]
| CSF 식별자 | 주요 내용 | 사고 대응 관점 |
|---|---|---|
| DE.AE-02 | 부정적 이벤트 분석 | 로그 분석 도구와 위협 인텔리전스를 활용한 의심 활동 분석 |
| DE.AE-03 | 여러 출처의 정보 상관분석 | 다양한 로그와 이벤트 정보의 연계 분석 |
| DE.AE-06 | 부정적 이벤트 정보 전달 | 사고 대응 담당자와 관련 도구에 경보 및 분석 결과 전달 |
| DE.AE-08 | 사고 선언 | 정의된 기준에 따라 실제 사고 발생 여부 판단 |
| RS.MA-01 | 사고 대응 계획 실행 | 사고 선언 이후 관련 조직과 협력하여 대응 계획 수행 |
| RS.MA-02 | 사고 보고 검증 | 사고 여부와 심각도 및 긴급성 판단 |
| RS.MA-03 | 사고 분류 및 우선순위 결정 | 사고 유형과 예상 피해에 따른 대응 전략 선정 |
| RS.AN-03 | 사고 및 근본 원인 분석 | 사고 발생 경위와 구조적 원인 파악 |
| RS.AN-07 | 사고 데이터와 메타데이터 수집 | 사고 증거의 무결성과 출처 보존 |
| RS.CO-02 | 사고 통지 | 내부 및 외부 이해관계자에게 필요한 사고 통지 수행 |
| RS.MI-01 | 사고 봉쇄 | 사고의 확산과 추가 피해 제한 |
| RS.MI-02 | 사고 근절 | 공격자의 접근 경로와 사고 원인 제거 |
| RC.RP-03 | 복구 자산의 무결성 확인 | 백업과 복구 자산을 사용하기 전 검증 |
| RC.RP-05 | 복구된 자산의 무결성 확인 | 정상 운영 재개 전 복구 결과 검증 |
| RC.RP-06 | 복구 종료 및 문서화 | 복구 완료 기준 적용과 사후 보고서 작성 |
각 항목의 상세한 권고사항과 고려사항은 공식 문서 제3장의 커뮤니티 프로파일에서 확인할 수 있다.
Revision 3은 사고 탐지와 분석 및 대응 과정에서 자동화 도구를 활용할 수 있음을 설명한다.
대표적인 활용 영역은 다음과 같다.
- 로그와 보안 이벤트의 자동 수집.
- 여러 출처의 이벤트 상관분석.
- 위협 인텔리전스와 침해지표의 연계.
- 사고 경보 생성.
- 사고 대응 티켓 자동 생성.
- 사고 대응 담당자에게 작업 자동 배정.
- 특정 유형의 사고에 대한 자동 봉쇄.
- 대응 진행 상황 추적.
특히 DE.AE-02와 DE.AE-03은 SIEM과 SOAR 등의 기술을 이용한 로그 분석 및 상관분석을 언급한다.
DE.AE-06은 특정 경보 발생 시 사고 대응 티켓을 자동으로 생성하고 배정하는 방안을 고려하도록 한다.
다만 자동화된 대응은 업무 운영에 영향을 줄 수 있으므로 조직의 위험 수준과 대응 정책에 따라 적용해야 한다.
자동화된 탐지나 봉쇄가 모든 상황에서 적절한 것은 아니며, 필요에 따라 사람이 분석과 의사결정에 참여해야 한다.
NIST SP 800-61은 사고 대응을 중심으로 하지만, 위험 평가·보안 통제·로그 관리·복구 등 다양한 NIST 지침과 연계된다.
| 문서 | 주요 내용 | SP 800-61과의 관계 |
|---|---|---|
| NIST SP 800-30 | 위험 평가 | 사고의 위험 수준과 예상 영향을 판단하는 방법 제공 |
| NIST SP 800-37 | 위험 관리 프레임워크 | 사고 대응 결과를 조직과 시스템의 위험 관리에 반영 |
| NIST SP 800-53 | 보안 및 개인정보 보호 통제 | 사고 대응에 필요한 보안 통제와 관련 요구사항 제공 |
| NIST SP 800-84 | 시험·교육·훈련 프로그램 | 사고 대응 계획과 역량을 검증하는 훈련 방법 제공 |
| NIST SP 800-86 | 디지털 포렌식 기술 | 사고 조사와 증거 수집 및 분석 지원 |
| NIST SP 800-92 | 로그 관리 | 사고 탐지와 분석에 필요한 로그 관리 지원 |
| NIST SP 800-150 | 사이버 위협 정보 공유 | 사고 관련 위협 정보와 침해지표의 공유 지원 |
| NIST SP 800-184 | 사이버보안 사고 복구 | 사고 이후 시스템과 서비스의 복구 활동 지원 |
| NIST SP 800-218 | 안전한 소프트웨어 개발 | 소프트웨어 취약점과 관련된 사고 예방 및 대응 지원 |
NIST SP 800-53은 조직과 정보시스템에 적용할 수 있는 보안 및 개인정보 보호 통제를 제공한다.
이 가운데 IR(Incident Response) 통제 계열은 사고 대응 정책, 계획, 훈련, 시험, 처리 및 보고 등에 관한 통제를 포함한다.
SP 800-53이 통제 요구사항을 제시하는 문서라면, SP 800-61은 사고 대응 활동을 사이버보안 위험 관리에 통합하기 위한 권고사항과 고려사항을 제공한다.
두 문서는 상호 보완적으로 활용할 수 있다.
NIST SP 800-86은 디지털 포렌식 기술을 사고 대응에 통합하는 방법을 다룬다.
로그, 파일시스템, 운영체제 및 네트워크 데이터 등의 수집과 분석에 초점을 맞춘다.
반면 SP 800-61은 사고 대응 조직과 정책, 탐지, 대응, 복구 및 지속적 개선을 포괄하는 상위 지침이다.
따라서 디지털 포렌식은 사고 대응을 지원하는 전문적인 분석 활동으로 구분할 수 있다.
NIST SP 800-184는 사이버보안 사고 이후의 복구를 다루는 지침이다.
사고 복구 계획, 복구 활동 및 관련 위험 관리에 관한 내용을 제공한다.
SP 800-61이 사고 대응 전반을 다룬다면, SP 800-184는 그중 복구 활동을 보다 구체적으로 지원한다.
NIST SP 800-61 Revision 3은 본문 3개 장과 3개 부록으로 구성된다.[1]
| 구분 | 제목 | 주요 내용 |
|---|---|---|
| 제1장 | Introduction | 목적, 적용 범위, 사고의 정의 및 문서 구성 |
| 제2장 | Incident Response as Part of Cybersecurity Risk Management | 사고 대응 생애주기, 역할과 책임, 정책 및 절차 |
| 제3장 | CSF 2.0 Community Profile for Cyber Incident Risk Management | 사고 대응을 위한 CSF 2.0 커뮤니티 프로파일 |
| 참고문헌 | References | 관련 표준과 지침 |
| 부록 A | List of Symbols, Abbreviations, and Acronyms | 기호 및 약어 목록 |
| 부록 B | Glossary | 주요 용어 정의 |
| 부록 C | Change Log | 이전 개정판과의 주요 변경사항 |
제3장은 다음 두 부분으로 구분된다.
- 3.1 Preparation and Lessons Learned: 사고 대응 준비와 교훈 및 개선.
- 3.2 Incident Response: 사고 탐지·대응·복구.
문서에는 다음 세 개의 주요 표가 포함되어 있다.
- Table 1: 기존 사고 대응 생애주기와 CSF 2.0 기능의 대응 관계.
- Table 2: 준비 및 교훈에 관한 CSF 2.0 커뮤니티 프로파일.
- Table 3: 실제 사고 대응에 관한 CSF 2.0 커뮤니티 프로파일.
Revision 3은 이전 개정판보다 기술별 세부 사고 처리 절차의 비중을 줄이고, 조직 차원의 위험 관리와 CSF 기반 권고사항에 초점을 맞추었다.
NIST는 사고 대응에 필요한 기술과 운영 절차가 지속적으로 변화한다는 점을 고려하여, Revision 3의 세부 구현 자료를 온라인에서 제공한다.
주요 자료는 다음과 같다.
| 자료 | 주요 내용 |
|---|---|
| NIST Incident Response Project | 사고 대응 관련 지침과 추가 참고자료 |
| SP 800-61 Rev. 3 공식 페이지 | 현행 간행물과 문서 이력 |
| Cybersecurity and Privacy Reference Tool | CSF 요소와 관련 지침 및 통제의 연결 정보 |
| NIST Cybersecurity Framework 2.0 | 사고 대응 프로파일의 기반이 되는 사이버보안 프레임워크 |
NIST의 사고 대응 프로젝트 페이지와 CPRT는 지속적으로 갱신될 수 있는 온라인 자료이다.[6]
실제 사고 대응체계를 수립하거나 개정할 때는 SP 800-61 Revision 3의 본문과 함께 관련 온라인 자료의 최신 내용을 확인할 필요가 있다.
NIST SP 800-61은 미국 연방정부의 정보보안 지침으로 개발되었지만 민간기업과 다른 기관에서도 자발적으로 활용할 수 있다.
Revision 3은 특정 산업이나 조직 규모에 한정되지 않는 사고 대응 권고사항을 제공한다.
다만 다음과 같은 사항을 고려해야 한다.
- 위험 관리 중심: Revision 3은 사고 대응을 사이버보안 위험 관리에 통합하는 데 초점을 맞추며, 모든 기술 환경의 상세한 사고 처리 절차를 제공하지 않는다.
- 조직별 조정: 조직의 규모, 업무 특성, 위험 수준 및 기술 환경에 따라 사고 대응 절차를 조정해야 한다.
- 기술적 구현의 다양성: 클라우드, 산업제어시스템, 모바일 및 일반 업무시스템 등은 서로 다른 대응 방법이 필요할 수 있다.
- 법적 요구사항의 구분: 사고 신고와 개인정보 유출 통지 등의 의무는 해당 국가와 산업에 적용되는 법령 및 규제를 별도로 확인해야 한다.
- 외부업체와의 책임 분담: 사고 대응 업무를 위탁하더라도 책임과 권한 및 정보 공유 범위를 명확히 정의해야 한다.
- 지속적 개선: 사고 대응체계는 일회성 계획 수립으로 완성되지 않으며 훈련과 실제 사고 대응 결과를 바탕으로 지속적으로 개선해야 한다.
- 기존 개정판과의 구분: Revision 2의 4단계 모델은 여전히 사고 처리 절차를 이해하는 데 활용할 수 있지만, 현행 Revision 3의 공식 구성은 CSF 2.0 기반 모델이다.
NIST SP 800-61 Revision 3의 핵심은 사고가 발생했을 때 기술적으로 대응하는 절차를 마련하는 것뿐 아니라, 사고 대응에 필요한 조직의 거버넌스·위험 관리·기술적 보호·탐지·복구·지속적 개선을 하나의 체계로 연결하는 데 있다.
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 Alexander Nelson, Sanjay Rekhi, Murugiah Souppaya, Karen Scarfone, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, NIST Special Publication 800-61 Revision 3, National Institute of Standards and Technology, 2025-04-03.
- ↑ SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, NIST Computer Security Resource Center, 확인: 2026-10-23.
- ↑ Paul Cichonski, Tom Millar, Tim Grance, Karen Scarfone, Computer Security Incident Handling Guide, NIST Special Publication 800-61 Revision 2, National Institute of Standards and Technology, 2012-08-06.
- ↑ NIST Revises SP 800-61: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, NIST Computer Security Resource Center, 2025-04-03.
- ↑ Cybersecurity and Infrastructure Security Agency, Cybersecurity Incident & Vulnerability Response Playbooks, 2021-11.
- ↑ Incident Response Project, NIST Computer Security Resource Center, 확인: 2026-10-23.