# Respond (사고 대응 단계)

## 개요

**Respond**(응답)는 정보 보안 사고 대응(Incident Response) 프로세스의 핵심 단계 중 하나로, 이미 탐지된 보안 사고에 대해 조직이 체계적으로 대처하고 통제하는 과정을 의미합니다. 일반적으로 NIST(미국 국립표준기술원)나 SANS 연구소와 같은 주요 보안 기관들이 제시하는 사고 대응 프레임워크에서, 'Preparation'(준비), 'Detection & Analysis'(탐지 및 분석)에 이어지는 단계로, 'Containment'(봉쇄), 'Eradication'(근절), 'Recovery'(복구)의 활동이 주로 이 단계에서 이루어집니다.

Respond 단계의 주요 목표는 사고의 확산을 막고, 비즈니스 연속성을 최대한 유지하며, 사고로 인한 피해를 최소화하는 것입니다. 단순히 기술적인 조치뿐만 아니라 법적, 커뮤니케이션적 측면에서의 대응도 포함됩니다.

## Respond 단계의 주요 활동

Respond 단계는 다음과 같은 세 가지 핵심 하위 활동으로 구성됩니다.

### 1. 봉쇄 (Containment)

봉쇄는 공격자가 시스템에 더 이상 접근하지 못하도록 하거나, 악성 코드의 확산을 차단하는 과정입니다. 이는 장기적인 봉쇄(Long-term Containment)와 단기적인 봉쇄(Short-term Containment)로 나뉩니다.

*   **단기적 봉쇄**: 즉각적인 위험을 제거하기 위한 조치입니다. 예를 들어, 감염된 서버의 네트워크 연결을 물리적으로 차단하거나, 방화벽 규칙을 변경하여 특정 포트의 접근을 차단하는 것이 포함됩니다.
*   **장기적 봉쇄**: 시스템의 가용성을 유지하면서 공격 경로를 차단하는 조치입니다. 백업 서버로의 전환, 임시 패치 적용, 또는 격리된 환경에서의 운영 등이 해당됩니다.

> **주의**: 봉쇄 과정에서 증거가 파괴되지 않도록 주의해야 합니다. 메모리 덤프(Memory Dump) 등 디지털 포렌식 증거 확보가 선행되어야 할 수 있습니다.

### 2. 근절 (Eradication)

봉쇄된 환경에서 사고의 근본 원인(Root Cause)을 제거하는 단계입니다. 단순히 감염된 파일만 삭제하는 것을 넘어, 공격자가 사용한 백도어(Backdoor), 취약점, 또는 악성 소프트웨어의 모든 흔적을 찾아 제거해야 합니다.

*   **악성 코드 제거**: 백신 소프트웨어를 통한 스캔 및 수동 제거.
*   **취약점 패치**: 공격에 이용된 시스템 취약점에 대한 패치 적용.
*   **계정 관리**: 유출된 비밀번호의 변경 및 불필요한 계정 삭제.
*   **시스템 재설치**: 감염 정도가 심각하여 정밀한 복구가 불가능한 경우, OS 및 애플리케이션을 깨끗한 상태로 재설치.

### 3. 복구 (Recovery)

근절이 완료된 후, 시스템을 정상적인 운영 상태로 되돌리는 단계입니다. 이 단계에서는 시스템의 안정성을 확인하고, 비즈니스 운영을 재개합니다.

*   **데이터 복구**: 백업된 데이터를 사용하여 손실된 데이터를 복원합니다. 이때 백업 데이터의 무결성을 반드시 검증해야 합니다.
*   **시스템 모니터링**: 복귀 후 시스템이 다시 공격받지 않도록 강화된 모니터링을 실시합니다.
*   **점진적 서비스 재개**: 전체 시스템을 동시에 가동하기보다, 중요도가 낮은 서비스부터 순차적으로 재개하여 잠재적 문제를 확인합니다.
*   **운영 환경으로의 이전**: 격리된 환경에서 운영되던 시스템을 본래의 프로덕션 환경으로 이전합니다.

## Respond 단계의 중요성과 고려사항

### 증거 보존 (Evidence Preservation)
사고 대응 과정에서 수집된 모든 로그, 메모리 덤프, 파일 등은 향후 법적 소송이나 내부 조사에서 중요한 증거가 됩니다. 따라서 Respond 단계에서는 증거의 무결성을 보장하기 위해 해시값(HASH)을 생성하고, 원본 데이터를 변경하지 않는 절차(Write-blocker 사용 등)를 준수해야 합니다.

### 커뮤니케이션 관리
내부 이해관계자(경영진, 법무팀, IT 부서)와 외부 이해관계자(고객, 규제 기관, 언론)에게 적절한 시기에 정확한 정보를 전달하는 것이 중요합니다.过早한 공개는 불필요한 공포를 야기할 수 있으며, 지연된 공개는 신뢰도를 떨어뜨릴 수 있습니다. 따라서 사전에 정의된 커뮤니케이션 플랜에 따라 대응해야 합니다.

### 문서화 (Documentation)
Respond 단계에서 수행된 모든 조치, 결정 사항, 시간대, 담당자 등은 상세히 기록되어야 합니다. 이 기록은 이후 'Lessons Learned'(교훈 도출) 단계에서 사고 대응 프로세스를 개선하는 데 필수적인 자료가 됩니다.

## 관련 단계와의 연계

Respond 단계는 사고 대응의 전후 단계와 밀접하게 연관되어 있습니다.

1.  **Detection & Analysis와의 연계**: 정확한 탐지와 분석이 이루어져야 효과적인 봉쇄 전략을 수립할 수 있습니다. 분석 결과에 따라 봉쇄 범위가 결정됩니다.
2.  **Lessons Learned와의 연계**: Respond 단계가 완료된 후, 'Lessons Learned' 회의에서 Respond 과정의 문제점을 분석하여 향후 'Preparation' 단계의 준비 사항을 개선합니다.

## 결론

Respond 단계는 보안 사고 발생 시 조직의 회복 탄력성(Resilience)을 결정짓는 가장 중요한 단계입니다. 사전에 수립된 사고 대응 계획(IRP, Incident Response Plan)에 따라 신속하고 체계적으로 대응함으로써, 조직은 막대한 금전적 손실과 평판 훼손을 방지할 수 있습니다. 따라서 정기적인 훈련과 시뮬레이션을 통해 Respond 단계의 효율성을 지속적으로 향상시켜야 합니다.

## 참고 자료

*   NIST Special Publication 800-61 Rev. 2: Computer Security Incident Handling Guide
*   SANS Institute: Incident Response and Management
*   ISO/IEC 27035: Information security incident management