[Incident Response] 침해사고 대응(Incident Response)
(1) Incident(사고) vs Event(사건)
1-1. Event(사건)
-
시스템이나 네트워크에서 관찰 가능한 모든 행위들
-
악의적 Event , 정상적 Event, 의심스러운 Event 등 매우 다양
-
예시)
-
공유 폴더(Shared Folder)에 연결하는 사용자
-
웹 페이지 요청을 수신하는 서버
-
이메일을 보내는 사용자
-
1-2. Incident(사고)
-
사내 컴퓨터 보안 정책 위반
-
시스템 권한 불법적 사용
-
민감한 데이터 무단 접근
-
악성코드 실행 등과 같은 부정적 결과를 초래하는 유해한 모든 이벤트
-
예시)
-
봇넷에서 웹 서버에 많은 양의 연결 요청을 보내 서비스 거부를 유발하도록 명령
-
사내 이메일을 통해 수신된 악성 첨부파일 실행
-
조직의 민감한 데이터를 입수한 공격자가 금액을 지불하지 않으면 공개하겠다며 협박
-
내부자가 P2P 파일 공유 서비스를 통해 민감 정보를 제 3자에게 제공 / 노출
-
(2) Asset(자산), Threat(위협), Vulnerability(취약성), Risk(위험)의 개념
2-1) Asset(자산)
-
조직 내의 보호가 필요한 유형 / 무형의 모든 객체들
-
'자산'을 지키는 것을 '정보보안'으로 표현 가능
-
예시)
-
유형 : 조직원, 외주 직원, 고객, 서버, 기타 유형의 것들
-
무형 : 회사 평판, 주요한(민감한) 사내 데이터, 소스 코드, 기타 무형의 것들
-
2-2) Threat(위협)
-
취약점(vulnerability)을 악용하여 자산(asset)에 접근 / 손상 / 파괴하려는 모든 시도들
-
예시)
-
하루 평균 10000건 정도의 웹 서버에 대한 SQL Injection 공격 시도
-
사내 이메일을 통해 수신되는 모든 악성 메일
-
권한 없는 조직원이 사내 민감 정보에 접근하려는 시도들
-
인터넷에 공개된 제로-데이, 원-데이 취약점을 이용한 공격 시도
-
2-3. Vulnerability(취약성)
-
위협(threat)에 의해 권한 없이 무단으로 사용될 가능성이 있는 자산(asset)이 갖고 있는 기술적 / 정책적 / 관리적 약점(weakness)
-
예시)
-
회사 홍보 목적으로 사용하는 사내 웹 서버에 SQL 취약점 존재
-
조직원들의 보안 인식 부재로 사내 메일로 수신되는 악성 첨부파일 실행 가능성
-
사내 특정한 자산들에 해당되는 제로-데이 취약점 공개
-
2-4. Risk(위험)
-
사내 자산(asset)에 존재하는 취약성(vulnerability)에 대한 악용 위협(threat)으로 인한 자산 손실, 손상 또는 파괴 가능성
-
위험 관리 방법으로는 웹 방화벽 설정, 웹 서버에 대한 SQL Injection 제거 등이 있음
-
예시)
-
SQL Injection 취약점이 존재하는 웹 서버에 대한 공격 시도로 사내 정보 유출 및 위변조
-
보안 인식이 부족한 조직원이 사내 메일을 통해 수신된 악성 첨부파일 실행
-
권한 관리가 되어 있지 않은 주요 서버에 권한 없는 조직원이 접근하여 정보 열람
-
(3) A-V-T-R Model
3-1. A-V-T-R 모델?
-
자산(asset) 내에 존재하는 취약성(vulnerability)을 위협(threat)으로 발생하는 실질적 손해와 그 가능성을 위험(risk)이라고 함
-
즉, 자산(asset) + 취약점(vulnerability) + 위협(threat) = 위험(risk)
(4) Purpose : IR
4-1. 침해사고 대응 목적
-
침해 사고에 효율적 / 효과적으로 대응하기 위한 조직 실정에 맞는 실질적 대응 지침 수립
-
조직의 자산(asset)에 존재하는 취약성(vulnerability)에 대한 공격 위협(threat)으로 부터 컴퓨터 침해사고(incident) 발생 시 초래되는 위험(risk)을 완화(mitigation)하도록 지원
-
'침해사고를 막는다(block)'는 개념보다 '완화(mitigation)'하는 개념
4-2. 완화의 개념
-
식별(identification)
-
격리(containment)
-
제거(Eradication)
-
복구(Recovery)
-
사후-활동(Post-Incident Activity)
(5) 침해사고 대응 절차
5-1. 예방 단계
1) 준비(Preparation)
-
원활한 침해사고 대응을 위한 정책 / 계획 / 절차 / 지침 수립
-
원활한 침해사고 대응을 위한 탐지 센서 구축 / 설치
2) 탐지(Detection)
-
준비 단계에서 구축 / 설치한 탐지 센서들로부터 위협(threat) 모니터링
-
실제 공격 시도인지? (정탐 / 오탐 구분)
-
정탐이면 '분석 단계'로 진행하고, 오탐이면 '탐지 단계'로 리턴
5-2. 심사 단계
3) 분석(Analysis)
-
내부 자산(asset)에 대한 위협(threat)이 실제로 취약성(vulnerability)에 위험(risk)을 발생시켰는가?
-
실제 공격이 성공한 호스트에서는 어떠한 일이 발생했는가? (영향도 분석)
-
공격이 실제로 성공하지 않았으면 '탐지 단계'로 리턴하고, 공격이 실제로 성공했으면 '식별 단계'로 진행
-
얼마나 심각한 공격이 성공했는가? (심각도 분석)
-
너무 많이 '분석 단계'에서 머물러 있지 않되, 다음 단계들을 진행하면서 같이 병행하며 추가적 정보를 지속적으로 획득하는 것이 중요
4) 식별(Identification)
-
공격자가 내부 시스템에 얼마나 많은 발판(foothold)을 설치했는지 식별하는 단계
-
공격이 성공적으로 실행된 경우, 내부 전파(측면 이동)가 공격자의 일반적인 첫 단계이므로 사고 범위를 빠르게 결정하는 것이 매우 중요
-
해당 시스템만 영향을 받는가? (사고 범위 분석)
5-3. 완화 단계
5) 격리(Containment)
-
다른 시스템이 추가 점령 / 감염 / 전파되는 것을 막기 위한 단계
-
식별 단계를 통해 파악된 사고의 범위를 통해 격리 범위 판단 가능
-
현실적으로 완벽히 / 신속히 수행되기 매우 어려운 단계
예시 1) 사고 범위가 해당 서버 1대인 경우
-
확인된 공격자의 C2 서버 IP 차단
-
서버 랜선 절췌
-
서버 셧다운
예시 2) 사고 범위가 특정 네트워크 대역대인 경우
-
확인된 공격자의 C2 서버 IP 차단
-
방화벽을 통한 해당 네트워크 대역대 인 / 아웃바운드 접근 제어
-
이후 점진적인 서버 랜선 절췌 / 셧다운
6) 제거(Eradication)
-
공격자가 내부 시스템에 설치한 발판(foothold)들을 제거하는 단계
-
일부 케이스에서는 '제거 / 복구 단계'를 병행하여 같이 수행
-
예시)
-
안티 바이러스 솔루션을 통한 치료
-
악성 파일 및 프로세스 삭제 / 종료
-
침해된 사용자 계정 비활성화 / 삭제
-
악용된 취약점 / 서비스 제거
-
7) 복구(Recovery)
-
공격자에 의해 영향 받은 시스템에 대해 이전과 같은 정상 상태로 복구하기 위한 단계
-
예시)
-
백업 서버를 통한 서버 재설치 / 교체
-
손상되거나 위변조된 내부 데이터베이스 복원
-
재감염 여부 모니터링 수행
-
8. 사후 활동(Post-Incident Activity)
-
사고 원인을 다시 추적 / 분석하며, 이전 단계에서 놓친 부분이 없는지 재확인하고 보고하는 단계
8-1. 조사(Investigation) - optional
-
이번 침해사고에 대한 전체적인 타임라이닝(timelining) 및 추가적 세부사항 작성
-
이번 침해사고에 대한 가시성 확보, 원인을 파악함으로써 내부 보안성 강화 기회 제공
-
많은 시간 소모, 높은 수준의 기술력 요구
-
조사가 필요한 수준의 사고였는지 판단 필요
8-2. 강화(Hardening)
-
이전 단계들을 수행하며 보안성을 향상할 필요가 있었던 부분에 대한 강화 진행
예시)
-
이메일이 벡터인 경우 > 이메일 필터링 강화 / APT 솔루션 도입 혹은 내부 직원에 대한 스피어피싱 교육 실시
-
웹 서버가 벡터인 경우 > 웹 서버 보안 점검 프로세스 혹은 시큐어 코딩 의무화 실시
# Reference