Incident Response

Incident Response

침해사고대응에 대해 전체적인 개념에 대해 정리를 하기 위해 글을 썼다.

 

용어 정리

내용에 들어가기 앞서 사용하는 여러 용어에 대해 적어두었다.

Incident vs Event

  • Event(사건)
    • 시스템 또는 네트워크에서 관찰 가능한 모든 행위를 의미한다.
    • 예)
      • 공유 폴더에 연결하는 사용자
      • 웹 페이지 요청을 수신하는 서버
      • 이메일을 보내는 사용자
  • Incident(사고)
    • 사내 컴퓨터 보안 정책 위반, 시스템 권한의 불법적인 사용, 민감한 데이터에 대한 무단 접근, 악성코드 실행 등과 같은 부정적인 결과를 초래하는 유해한 모든 이벤트를 의미한다.
    • 예)
      • 봇넷에게 웹서버에 많은 양의 연결 요청을 보내 서비스 거부를 유발하도록 명령
      • 사내 이메일을 통해 수신된 악성 첨부파일 실행
      • 조직의 민감한 데이터를 입수한 공격자가 금액을 지불하지 않으면 공개하겠다고 협박
      • 내부자가 P2P 파일 공유 서비스를 통해 민감한 정보를 제 3자에게 제공하거나 노출

 

Asset, Threat, Vulnerability, Risk

  • Asset(자산)
    • 조직 내의 보호가 필요한 유/무형의 모든 객체들
    • 예)
      • 유형
        • 조직원
        • 외주 직원
        • 고객
        • 서버
        • 기타 유형의 것들
      • 무형
        • 회사 평판
        • 주요한/민감한 사내 데이터
        • 소스코드
        • 기타 무형의 것들
  • Vulnerability(취약성)
    • 위협에 의해 권한 없이 무단으로 사용될 가능성이 있는 자산이 갖고 있는 기술적/정채적/관리적인 약점
    • 예)
      • 회사 홍보 목적으로 사용하는 웹서버에 SQL Injection 취약점 존재
      • 조직원들의 보안인식 부재로 사내 메일로 수신되는 악성 첨부파일 실행 가능성
      • 사내 특정한 자산들에 해당되는 Zero-Day 취약점 공개
  • Threat(위협)
    • 취약점을 악용하여 자산에 접근/손상/파괴하려는 모든 시도들
    • 예)
      • 하루 평균 만 건 정도의 웹서버에 대한 SQL Injection 공격 시도
      • 사내 이메일을 통해 수신되는 모든 악성 메일들
      • 권한 없는 조직원이 사내 민감 정보에 접근하려는 시도
      • 인터넷에 공개된 Zero-Day, One-Day 취약점을 이용한 공격 시도
  • Risk(위험)
    • 사내 자산에 존재하는 취약성에 대한 악용 위협으로 인한 자산 손실, 손상 또는 파괴 가능성
    • 예)
      • SQL Injection 취약점이 존재하는 웹서버에 대한 공격 시도로 사내 정보 유출 및 위변조
      • 보안 인식이 부족한 조직원이 사내 메일을 통해 수신된 악성 첨부파일 실행
      • 권한 관리가 안되어 있는 주요 서버에 권한 없는 조직원이 접근하여 정보 열람

 

A-V-T-R

  • 자산 내에 존재하는 취약성을 악용한 위협으로 발생하는 실질적인 손해와 그 가능성을 위험이라고 함
  • 자산(Asset) + 취약점(Vulnerability) + 위협(Threat) = 위험(Risk)

 

Incident Response

침해사고대응 목적

  • 침해사고에 효율/효과적으로 대응하기 위한 조직 실정에 맞는 실질적인 대응지침 수립

  • 조직의 자산에 존재하는 취약성에 대한 공격 위협으로부터 컴퓨터 침해사고(incident) 발생 시 초래되는 위험을 완화하도록 지원

  • 침해사고를 막는다(block)는 개념보다 완화(mitigation)하는 개념에 집중한다.

    • 완화(mitigation)의 개념 내에는 다음이 포함된다.

      • 식별(Identification)

      • 격리(Containment)

      • 제거(Eradication)

      • 복구(Recovery)

      • 사후-활동(Post-Incident Activity)

        사후-활동 : 일련의 사고 대응 절차가 끝난 후 해당 사고를 대응하면서 잘한 점 및 부족한 점과 침해 이유 등에 대해 다시 생각해보는 것

 

침해사고대응 절차

  • 예방 단계
    1. 준비(Preparation)
    2. 탐지(Detection)
  • 심사 단계
    1. 분석(Analysis)
    2. 식별(Identification)
  • 완화 단계
    1. 격리(Containment)
    2. 제거(Eradication)
    3. 복구(Recovery)
    4. 사후활동(Post-Incident Activity)

 

예방 단계

  • 준비(Preparation)
    • 원활한 침해사고대응을 위한 정책/계획/절차/지침을 수립하는 단계
    • 원활한 침해사고대응을 위한 탐지 센서 구축/설치하는 단계
  • 탐지(Detection)
    • 준비 단계에서 구축/설치한 탐지 센서들로부터 위협 모니터링하는 단계
    • 실제 공격 시도인지? (정오 탐 구분)
      • 정탐이면, '분석 단계'로 진행
      • 오탐이면, '탐지 단계'로 리턴

 

심사 단계

  • 분석(Analysis)
    • 내부 자산에 대한 위협이 실제로 취약성에 위험을 발생시켰는가?
    • 실제 공격이 성공한 호스트에서는 어떠한 일이 발생했는가? (영향도 분석)
      • 공격이 실제로 성공하지 않았으면, '탐지 단계'로 리턴
      • 공격이 실제로 성공했으면, '식별 단계'로 진행
    • 얼마나 심각한 공격이 성공했는가? (심각도 분석)
    • 너무 많이 '분석 단계'에서 머물러 있지 않되, 다음 단계들을 진행하면서 같이 병행하며 추가적인 정보를 지속적으로 획득하는 것이 중요
  • 식별(Identification)
    • 공격자가 내부 시스템에 얼마난 많은 발판(foothold)을 설치했는지 식별하는 단계
    • 공격이 성공적으로 실행된 경우, 내부 전파(측면 이동)가 공격자의 일반적인 첫 단계이므로 사고의 범위를 빠르게 결정하는 것이 중요
    • 해당 시스템만 영향을 받는가? (사고 범위 분석)

 

완화 단계

  • 격리(Containment)
    • 다른 시스템이 추가 점령/감염/전파되는 것을 막기 위한 단계
    • 식별 단계를 통해 파악된 사고의 범위를 통해 격리 범위 판단 가능
    • 현실적으로 완벽히/신속 수행되기 매우 어려운 단계
    • 사고 범위가 해당 서버 한대인 경우
      • 확인된 공격자의 C2 서버 IP 차단
      • 서버 랜선 절체/셧다운
    • 사고범위가 특정 네트워크 대역 대인 경우
      • 확인된 공격자의 C2 서버 IP 차단
      • 방화벽을 통한 해당 네트워크 대역대인 인/아웃바운드 접근제어
      • 이후 점진적인 서버 랜선 절체/셧다운
  • 제거(Eradication)
    • 공격자가 내부 시스템에 설치한 발판(foothold)들을 제거하는 단계
    • 일부 케이스에서는 '제거/복구 단계'를 병행하여 같이 수행
      • 안티-바이러스 솔루션을 통한 치료
      • 악성 파일 및 프로세스 삭제/종료
      • 침해된 사용자 계정 비활성화/삭제
      • 악용된 취약점/서비스 제거
  • 복구(Recovery)
    • 공격자에 의해 영향을 받은 시스템에 대해 이전과 같은 정상 상태로 복구하기 위한 단계
      • 백업 서버를 통한 서버 재설치/교체
      • 손상되거나 위변조 된 내부 데이터베이스 복원
      • 재감염 여부 모니터링 수행
  • 사후활동(Post-Incident Activity)
    • 사고 원인을 다시 추적/분석하며, 이전 단계에서 놓친 부분이 없는지 재확인하고 보고하는 단계
    • 조사(Investigation) - optional
      • 이번 침해사고에 대한 전체적인 타임 라이닝(timelining) 및 추가적인 세부사항 작성
      • 이번 침해사고에 대한 가시성을 확보하며, 원인을 파악함으로써 내부 보안성 강화 기회를 제공
      • 많은 시간이 소모되며, 높은 수준의 기술력 요구
      • 조사가 필요한 수준의 사고였는지 판단 필요
    • 강화(Hardening)
      • 이전 단계들을 수행하며 보안성을 향상할 필요가 있었던 부분에 대한 강화 진행
        • 이메일 벡터인 경우, 이메일 필터링 강화/APT 솔루션 도입 혹은 내부 직원에 대한 스피어 피싱 교육 실시
        • 웹서버가 벡터인 경우, 웹서버 보안점검 프로세스 강화 혹은 시큐어 코딩 의무화 실시

 

thanks to Choe

'Incident Response' 카테고리의 다른 글

Fodhelper를 이용한 UAC bypass  (0) 2020.06.08
Amcache 수집 및 분석  (0) 2020.05.01
Windows Artifacts  (0) 2020.04.06
ATT&CK Attack Framework  (2) 2020.04.02
Initial Access  (0) 2020.03.31