사이버 사고 대응 가이드: 모범 사례, 도구 & 전략

사고 대응(IR)이란 무엇인가요?

사고 대응은 사이버 공격이 발생했을 때 기업이 전략적이고 체계적으로 수행하는 대응입니다. 사용자와 자산을 보호하고 피해와 취약점을 줄이며 향후 침해를 방지하기 위해 수행합니다. 보안 전문가는 사고 대응을 통해 보안 사고를 관리하고 새로운 위협에 신속하게 대응합니다. 침해가 발생했을 때 조직이 최대한 빨리 대처하도록 하는 것이 목표입니다.

사고 대응의 목표

사고 대응의 목표는 사이버 공격의 영향을 신속하게 줄이고 보안 침해를 방지하는 것입니다. 사고에서 얻은 인사이트와 위협 정보를 활용해 향후 사이버 보안 조치를 개선합니다. 그 밖에도 비즈니스 연속성을 유지하고, 진행 중인 위협을 탐지하고 격리하며, 사고 후 활동의 일환으로 검토를 수행합니다.

사고 대응과 사고 관리의 차이

사고 대응과 사고 관리의 주요 차이점은 다음과 같습니다:사고 대응 계획는 기업이 중대한 사건으로부터 복구하는 데 걸리는 시간을 획기적으로 단축할 수 있습니다. 사이버 위협은 그 어느 때보다 커지고 있으며, 우리는 복잡하게 얽힌 기술과 보안 위험을 다루고 있습니다. 효과적인 사고 대응 계획의 중요성을 강조하는 몇 가지 핵심 요소는 다음과 같습니다.

위험 관리
• 사고 대응은 사고를 식별하고 SIEM 같은 도구로 경보를 생성하고 전달하는 데 집중합니다. 직원과 SOC 팀에 상황을 알리고 위협에 적시에 대응합니다.
• 사고 관리는 제3자에게 지원을 요청하고 지원 인력을 투입할 수 있습니다. 사고 해결 결과를 확인하고 향후 사고 관리 전략을 평가하는 일도 포함합니다.
• 사고 대응은 네트워크에서 감염을 제거하는 조치를 시작합니다. 백업에서 데이터를 복원하고 비즈니스 연속성도 유지합니다.

오늘날 사고 대응이 중요한 이유는 무엇인가요?

사고 대응을 통해 조직은 잠재적인 사이버 위협의 영향을 신속하게 평가하고 필요한 시정 조치를 취할 수 있습니다. 사고의 근본 원인을 파악해 향후 유사한 사고를 방지할 수 있습니다.

사고 대응은 사용자의 보안 인식을 높이고 데이터 오용과 손실을 방지합니다. 조직의 규정 준수와 사이버 보안 태세를 강화하고 비즈니스 연속성 유지에도 기여합니다. 또한 조직을 신뢰할 수 있고 고객 데이터가 안전하게 보호된다는 점을 고객에게 보여줍니다.

사고 대응은 팀 전체가 따를 수 있는 지침과 절차도 마련합니다. 이를 통해 사이버 보안 사고의 영향을 줄이고 대응하며, 위협에 신속하게 대처하고, 침해 발생 시 빠르게 복구해 정상적인 보안 운영으로 돌아갈 수 있습니다.

공격은 해마다 더욱 정교해지고 있습니다. 조직은 지능형 지속 위협(APT), 제로데이 취약점, 서비스형 랜섬웨어(RaaS), 기존 보안 도구를 우회하는 AI 기반 공격에 직면합니다. 공격자는 이제 공급업체와 제3자를 노려 조직의 네트워크에 침입합니다. 체계적인 사고 대응 계획은 위협을 모니터링하고 공격 패턴을 추적하며 대응 계획을 갱신해, 새로운 공격이 큰 피해를 일으키기 전에 차단합니다.

200일 이내에 식별하고 격리한 침해 사고는 해결에 더 오래 걸린 사고보다 비용이 23% 적습니다. 2025년 데이터 침해 사고의 평균 비용은 444만 달러입니다. IBM 연구에 따르면 침해 사고가 해결되지 않은 채 한 시간 지속될 때마다 조직에는 약 $800의 비용이 발생하며, 심각도가 높은 사고에서는 이 비용이 크게 늘어납니다. 선제적 탐지 역량을 갖춘 조직은 평균 탐지 시간(MTTD)을 평균 44% 단축할 수 있습니다.

업계 표준 탐지 시간이 30분 이상인 데 비해, 조직의 선도적인 IR 팀은 5분 이내에 탐지할 수 있습니다. 또한 중대 사고당 평균 대응 시간(MTTR)을 단 5.5시간만 줄여도 일반적인 사고를 기준으로 연간 침해 비용 $352,000을 방지할 수 있습니다.

GDPR, HIPAA, SOC 2 같은 규정도 조직에 사고의 신속한 탐지, 문서화, 영향받은 당사자에 대한 통지를 요구합니다. 규정 준수를 넘어 고객과 이해관계자 역시 사고 발생 시 투명한 소통을 요구합니다. 체계적인 사고 대응 계획은 평판을 보호하고 고객 신뢰를 쌓으며, 규제 기관에 조직의 보안 의지를 보여줍니다. 부실한 대응이나 규정 위반은 막대한 벌금, 법적 문제, 장기적인 평판 손상으로 이어질 수 있습니다.

NIST 사고 대응 수명 주기

NIST 사고 대응 수명 주기의 주요 단계는 다음과 같습니다:

준비

이 단계에서는 먼저 사고 관리 계획을 수립합니다. 이 계획을 활용해 조직 환경에서 발생하는 사고를 탐지합니다. 준비 단계에서는 다양한 사이버 공격 유형을 파악하고 그 영향을 판단합니다. 또한 보안 사고에 대응하고 확산을 막으며, 처음부터 발생하지 않도록 방지하는 데 필요한 도구를 갖춥니다.

탐지 & 분석

다음은 탐지 및 분석 단계입니다. 데이터를 수집하고 분석해 단서를 찾고 새로운 공격 출처를 식별합니다. 공격의 성격과 시스템에 미치는 영향을 파악합니다. 보안 전문가와 협력하고 도구를 사용해 침해 지표(IOC)를 찾으며, 영향을 받은 시스템도 추적합니다.

격리

탐지 및 분석 — 사고 대응 라이프사이클의 이 단계에서 조직은 보안 사고를 정확히 탐지하고 평가하는 데 집중합니다.

격리, 제거 및 복구 — 기업은 보안 사고의 영향을 최소화하려 합니다. 피해 범위를 가능한 한 좁게 유지하고 서비스 중단을 완화하려 합니다.

사후 활동 — 이는 사고 대응 라이프사이클의 단계 중 하나로, 사고에서 교훈을 얻고 이후 개선하는 것이 목표입니다. 유사 사건 발생 가능성을 제한하고 향후 사고 대응 활동을 강화할 방법을 식별합니다.

격리 단계에서는 다양한 전술을 사용해 맬웨어와 바이러스의 확산을 막고 랜섬웨어를 차단합니다. 시스템의 네트워크 연결을 끊고, 기기를 격리하며, 의심스러운 트래픽과 악성 IP 주소를 차단할 수 있습니다.

제거

이 단계에서는 위협의 근본 원인을 찾습니다. 악성코드를 격리하고 감염된 기기를 분리한 뒤, 조직 환경에서 위협을 제거하기 시작합니다. 최신 백신 소프트웨어와 수동 위협 제거 기법을 사용할 수 있습니다. 향후 보안 사고를 방지하기 위해 소프트웨어를 최신 상태로 유지하고 패치를 적용합니다..

복구

비즈니스 운영을 신속하게 재개합니다. 복구 단계에서는 시스템을 운영 환경으로 되돌립니다. 신뢰할 수 있는 백업에서 이전 상태로 복원합니다. 이후 백업을 테스트하고 시스템 보안을 강화합니다.

교훈

세부 사항과 유연성—사고 대응 계획에는 확장 가능하고 유연하며 세부적인 구성 요소가 포함되어야 합니다. 계획은 지나치게 경직되지 않은 지침을 제공하여 예상치 못한 상황에도 대응할 수 있어야 합니다. 사고 대응 계획은 최소 6개월마다 검토해야 합니다.

소통 및 이해관계자 관리—사고 대응 계획은 경영진, 타 부서, 언론, 고객과의 소통 방식을 안내해야 합니다. 조직 내 모든 구성원이 동일한 인식 하에 있음을 알리는 것이 중요합니다. 또한 계획은 투명성과 책임성을 강화하여 구성원들이 주도적으로 참여하고 개선에 기여하도록 장려해야 합니다.

사고 대응 플레이북—사고 대응 플레이북은 사고 대응 라이프사이클의 각 단계에서 수행해야 할 작업을 단계별로 안내합니다. 시스템 전문가가 부재한 상황을 포함한 다양한 시나리오를 포함합니다. 문제 해결 팁을 얻고 다양한 작업을 수행하는 데 필요한 단계를 파악할 수 있습니다.

교훈을 도출하는 단계에서는 과거 또는 현재의 데이터 침해와 관련된 모든 문서를 분석합니다. 허점을 찾고 실제 사고와 모의 사고에서 얻은 교훈을 검토합니다. 이를 바탕으로 사이버 방어를 강화해 향후 공격을 막습니다.

IR 역할, 책임 & 팀 구조

사고 대응 팀은 사이버 공격에서 신속하고 효과적으로 회복하도록 지원하는 전문 조직입니다. 다운타임을 줄이고 운영 중단을 방지하며, 근본 원인을 해결해 향후 문제를 예방합니다.

IR 팀의 일반적인 역할과 책임을 살펴보겠습니다. 이상적인 IR 팀 구조도 함께 알아보겠습니다:

Incident Response Manager (IR Manager)

IR 팀을 이끄는 책임자입니다. 탐지부터 해결까지 모든 과정을 관리하고 감독합니다. 또한 경영진과 사고 대응 팀 사이의 연락 창구 역할을 합니다.

Security Analyst

IR 팀의 보안 분석가는 보안 사고를 탐지하고 분석하며 대응합니다. 취약점과 위협을 모니터링하고, 경보를 분류해 사고의 심각도와 영향을 평가합니다. 사고 관련 문서를 작성하고 갱신하는 일도 담당합니다.

Forensic Analyst

보안 사고 식별 – 이 단계에서는 고급 AI 위협 탐지 도구, 네트워크 모니터링 및 로그 분석을 조합하여 사용합니다. 조직은 자동화를 통해 워크플로우를 가속화하고 부정적 영향을 최소화하기 위해 확장할 수 있습니다.

사고 격리 전략 수립 – 침해 사고 발생 시 어떻게 대응할 것인가? 다음 논리적 단계는 위협을 격리하고 차단하는 것입니다. 이는 영향을 받은 시스템을 격리하고, 악성 IP 주소를 차단하며, 침해된 사용자 계정을 비활성화하는 절차입니다.

자동화된 위협 대응 – 조직은 다양한 보안 도구를 활용해 위협을 제거합니다. 악성코드를 제거하고 최신 취약점에 패치를 적용하며, 위협 인텔리전스까지 활용합니다. 주요 발견 사항을 바탕으로 현재 사고 대응 계획에 적용된 모든 업데이트가 반영됩니다.

사고 대응 평가 – 해당 기업은 취약점 스캔, 침투 테스트, 침해 및 공격 시뮬레이션을 수행할 것입니다. 또한 정책 검토를 실시하고 잠재적 취약점이 악용되기 전에 찾아내 수정할 것입니다. 시스템의 지속적인 평가와 보안 통제 검토를 위해 스트레스 테스트가 수행될 것입니다.

포렌식 분석가는 법원에 제출할 디지털 증거를 수집하고 보존하며 제시합니다. 조사 과정에서 법률 및 규정 준수 요건을 지원합니다. 상세한 포렌식 보고서를 작성하고 증거 관리 연속성을 유지하며, 법적 절차에서 수사 기관과 법무팀을 지원합니다.

Threat Hunter

위협 헌터는 기존 보안 도구를 피하는 숨겨진 위협과 지능형 지속 위협(APT)을 선제적으로 찾습니다. 위협 인텔리전스, 행동 분석, 가설 기반 조사를 활용해 피해가 발생하기 전에 악성 활동을 식별합니다. 네트워크 트래픽, 시스템 로그, 엔드포인트 데이터를 지속적으로 분석해 침해 지표와 새로운 공격 패턴을 찾아냅니다.

Communications Officer 사고 대응 서비스

커뮤니케이션 담당자는 보안 사고 발생 중과 발생 후의 내부 및 외부 소통을 관리합니다. 투명성을 유지하고 민감한 정보를 보호하면서 이해관계자, 경영진, 고객, 규제 기관에 명확하고 정확한 메시지를 전달합니다. PR 팀, 법률 자문, 경영진과 협력해 사고 공개와 평판 관리의 일관성을 유지합니다.

Legal Advisor

법률 자문은 규정 준수, 데이터 침해 통지 요건, 보안 사고의 법적 영향에 관한 지침을 제공합니다. 조사와 복구 과정에서 IR 팀이 GDPR, HIPAA 또는 산업별 규정 등 관련 법규를 준수하도록 합니다. 또한 책임 위험을 평가하고 수사 기관과 협력하며 사고 대응과 관련된 계약상 의무에 관해 조언합니다.

사고 대응 계획(IRP): 반드시 포함해야 할 사항

모든 사고 대응 계획에는 빠뜨려서는 안 될 기본 요소가 있습니다. IR 계획에 포함해야 할 내용은 다음과 같습니다:

목표와 사명

타겟(2013): 4,100만 고객에게 영향을 미친 타겟의 결제 카드 시스템 침해 사건으로 인해, 회사는 강화된 모니터링 시스템 도입, 네트워크 분할, 위협에 더 신속히 대응하기 위한 사이버 퓨전 센터 설립을 추진했습니다.

NotPetya 공격 (Maersk): 해운사는 10일 만에 4,000대의 서버와 45,000대의 PC를 재구축하고 임시 수동 절차를 통해 부분적인 운영을 유지하는 대응을 펼쳤습니다.SolarWinds: 대응팀은 맞춤형 탐지 도구를 개발하는 과정에서 공급망 공격을 발견하자마자 침해된 네트워크를 격리하고 사고 분류 체계를 수립했습니다.

사고 대응 계획에는 사명과 구체적인 목표를 명확히 밝혀야 합니다. 이는 모든 사고 대응 전략의 핵심입니다. 또한 민감한 데이터 보호, 피해 최소화, 운영 복구 등 사고 대응 계획의 목적도 설명해야 합니다. 계획에 명시된 모든 목표는 이해관계자와 팀원의 합의를 거쳐야 하며 정기적으로 재검토해야 합니다.

역할과 책임

사고 대응 팀원은 자신의 역할과 책임을 명확히 알아야 합니다. 특히 역할을 정하고 담당자를 지정할 때 혼선이 없어야 합니다. 외부 사이버 보안 업체나 제3자 담당자를 활용한다면, 이들의 지정된 책임도 함께 명시해야 합니다.

사이버 위협 대비

사고 대응 계획의 이 부분에서는 잠재적인 사이버 위협에 대한 조직의 대비 수준을 평가해야 합니다. 사이버 보안 인식 교육, 침입 탐지, 랜섬웨어와 악성코드, 사회공학 및 기타 위협에 대응하기 위한 정책 수립 등 IRP 구성 요소를 포함해야 합니다. 테스트 계획에는 모의 훈련을 포함하고, 새로운 위협에 앞서 대응할 수 있도록 지속적으로 업데이트해야 합니다.Vigilance MDR(24시간 모니터링을 제공하는 관리형 탐지 및 대응 서비스); Singularity XDR는 다중 공격 표면에 걸친 확장된 탐지 및 대응 기능을 제공하며, Singularity Threat Intelligence는 AI와 머신 러닝 기반의 실시간 위협 인사이트를 제공합니다.

피해 완화 및 확산 방지 전략

사고가 탐지되면 가장 먼저 환경 전반으로 위협이 확산되는 것을 막아야 합니다. 영향을 받은 시스템을 신속하게 격리하고 공격자가 네트워크의 다른 영역으로 측면 이동하지 못하도록 하는 명확한 절차가 필요합니다. 여기에는 침해된 사용자 계정 비활성화, 악성코드 제거, 무단 액세스 지점 차단이 포함됩니다. 팀이 지체 없이 실행할 수 있도록 격리 단계와 확산 방지 절차를 미리 정해 두어야 합니다.

커뮤니케이션 및 에스컬레이션 대응 절차

인시던트 대응 계획에는 각 단계에서 누구에게 어떤 채널로 알릴지 명시해야 합니다. 경영진, IT 팀, 관련 부서가 언제 어떻게 소통해야 하는지 정확히 알 수 있도록 내부 보고 체계를 정의하세요. 법률상 필요한 경우 고객, 규제 기관, 수사 기관에 알리기 위한 외부 커뮤니케이션 절차도 마련해야 합니다. 미리 작성한 템플릿과 승인된 메시지는 일관되고 정확하며 규정을 준수하는 통지에 기여합니다. 인시던트가 진행되는 동안 팀의 소통 주기를 명시하고, 민감한 정보를 보호할 수 있는 보안 채널을 사용하세요.SentinelOne를 사용해 보세요.

사고 분류 및 우선순위 지정

모든 사고가 같은 것은 아닙니다. 계획에는 심각도와 영향에 따라 사고를 분류하는 명확한 체계를 마련해야 합니다. 영향을 받은 시스템, 위험에 노출된 데이터의 양, 비즈니스 운영 차질의 정도에 따라 사고를 심각, 높음, 보통, 낮음으로 분류할 수 있습니다. 각 분류 등급별로 대응 기한과 구체적인 에스컬레이션 절차를 정해야 합니다.

신속한 복구 계획 및 사고 사후 검토

위협의 확산을 막았다면 다음 단계는 비즈니스 운영을 최대한 신속하게 복구하는 것입니다. 상세한 복구 단계와 영향을 받은 시스템을 다시 온라인으로 전환하는 방법을 명확히 제시해야 합니다. 시스템을 테스트해 지속적인 작동과 데이터 무결성을 확인하고, 손실된 데이터도 복원해야 합니다. 향후 사고를 예방할 수 있도록 지속적으로 개선해야 합니다.

아울러 공식적인 사고 사후 검토 절차를 마련하세요. 팀은 사고 경위를 기록하고 대응 절차의 미비점을 파악하며, 얻은 교훈을 조직 전체에 공유해야 합니다. 이러한 정기적인 검토를 통해 사고 대응 역량을 지속적으로 강화할 수 있습니다.

제3자 공급업체 관리

많은 조직이 운영에 필수적인 외부 공급업체와 서비스 제공업체에 의존합니다. 사고 대응 계획에는 대응에 참여해야 하는 공급업체와 각 업체의 구체적인 책임을 명확히 밝혀야 합니다. 에스컬레이션 절차를 문서화하고 커뮤니케이션 프로토콜을 수립하며, 공급업체 계약에 통지 요건을 명시해야 합니다.

공급업체 시스템이나 데이터 액세스와 관련된 사고의 조사 절차를 포함하세요. 핵심 공급업체를 정기적으로 보안 평가하면 적절한 보안 기준을 유지하고 사고 대응 활동을 효과적으로 지원할 수 있는지 확인할 수 있습니다.

법률 및 규정 준수 고려 사항

법률과 규제 요건은 관할권마다 준수해야 할 법률이 달라 까다로울 수 있습니다. 하지만 민감한 데이터를 보호하고 고객의 신뢰를 유지하려면 HIPAA, CCPA, GDPR과 같은 주요 규정을 준수해야 합니다.

법적 처벌과 평판 손상을 피할 수 있도록 법적 위험에 대처하고, 적시에 보고하며, 변화하는 규제 요건을 준수하는 방법을 조직에 안내해야 합니다. 사고 보고 및 데이터 페이지와 관련된 법적 의무를 이행하기 위한 명확한 절차도 마련해야 합니다.

IR에 사용되는 도구 & 기술

현재 IR에 가장 흔히 사용되는 도구와 기술은 다음과 같습니다:

EDR/XDR

엔드포인트 탐지 및 대응(EDR) 도구는 네트워크의 개별 기기에서 일어나는 활동을 모니터링합니다. 공격자가 시스템에 침입하면 EDR은 공격자의 행동 데이터를 수집해 보안 팀이 공격자의 행위를 정확히 파악하도록 합니다. 확장 탐지 및 대응(XDR)은 엔드포인트, 네트워크, 클라우드 시스템의 데이터를 하나의 화면에 통합합니다. 이를 통해 보안 팀은 공격의 전체 범위를 파악하고 더 빠르게 대응하는 데 필요한 맥락을 확보합니다. EDR/XDR이 없다면 보안 팀은 이미 피해가 발생한 뒤에야 침해된 기기에서 무슨 일이 일어났는지 알 수 있습니다.

SIEM & SOAR

SIEM은 인프라 전반의 로그를 수집하고 의심스러운 패턴을 표시합니다. 팀은 위협이 심각한 문제로 번지기 전에 발견할 수 있도록 이러한 가시성을 확보해야 합니다. SOAR는 팀의 대응 워크플로를 자동화하므로 사고가 발생할 때마다 동일한 확산 방지 단계를 수동으로 실행할 필요가 없습니다. 위협이 탐지되면 SOAR는 사람의 조치를 기다리지 않고 즉시 시스템을 격리하거나 계정을 비활성화하고 포렌식 데이터를 수집할 수 있습니다.

위협 인텔리전스

누가 공격하고 어떻게 움직이는지 알면 보안 팀의 대응이 달라집니다. 위협 인텔리전스는 알려진 공격자와 그들의 전술, 공격 대상으로 삼는 취약점에 관한 정보를 제공합니다. 보안 팀은 사고를 조사할 때 공격자의 행동을 알려진 위협 행위자의 행동과 비교합니다. 이를 통해 무작위 공격인지, 해당 산업을 겨냥한 표적 공격 캠페인인지 판단합니다. 위협 인텔리전스는 다양한 출처를 분석해 보안 인사이트를 제공합니다. 무엇을 상대하는지 알아야 대응할 수 있습니다. 그렇기에 위협 인텔리전스가 중요합니다.

로그 관리 & 포렌식 도구

로그는 증거입니다. 사고가 발생하면 팀은 침해된 시스템에서 일어난 일을 상세히 기록한 자료에 접근해야 합니다. 로그 관리 도구는 조사에 필요할 때 사용할 수 있도록 이러한 기록을 안전하게 보관합니다. 포렌식 도구를 사용하면 침해된 기기에서 데이터를 추출하고 법적 검증에도 견딜 수 있는 방식으로 보존할 수 있습니다. 적절한 로그 보존 및 포렌식 역량이 없다면 팀은 분석할 자료도, 사고 경위를 입증할 증거도 확보할 수 없습니다.

자동화 & AI 기반 IR

새롭게 등장하고 변화하는 위협에 대응하려면 보안 자동화와 신속한 대응이 필요합니다. AI 기반 도구는 방대한 데이터를 분석하고 팀이 수동으로 찾는 데 몇 시간이 걸릴 패턴을 발견합니다. 자동화는 시스템 격리나 계정 비활성화 같은 반복 작업을 몇 분이 아닌 몇 초 만에 처리합니다.

머신러닝은 공격이 알려진 시그니처와 일치하지 않아 팀이 놓칠 수 있는 이상 징후를 탐지합니다. 수동 분석에만 의존하는 조직은 자동화와 AI를 사용하는 조직보다 대응이 늦을 수밖에 없습니다.

보안 사고 유형 & 필요한 대응

알아두어야 할 보안 사고 유형은 다음과 같습니다. 필요한 대응 방법도 간략히 정리했습니다. 하나씩 살펴보겠습니다:

악성코드 & 랜섬웨어

악성코드는 시스템에 몰래 설치되어 공격자에게 원격 액세스 권한을 줍니다. 랜섬웨어는 파일을 잠그고 잠금 해제의 대가로 금전을 요구합니다. 둘 다 패치되지 않은 취약점을 악용하고 공유 드라이브를 통해 측면 이동하며 네트워크 전반으로 확산됩니다.

대부분의 랜섬웨어 변종은 파일을 천천히 암호화하므로 주시하면 알아챌 수 있습니다. 성능 저하, 백그라운드에서 실행되는 비정상적인 프로세스, 대량의 파일 이름 변경이 눈에 띕니다. 공격자는 랜섬웨어를 배포하기 전 몇 주 동안 네트워크를 스캔하며 백업 시스템과 가치가 높은 표적을 찾는 경우가 많습니다. 일부 공격 조직은 데이터를 먼저 탈취한 뒤 암호화합니다—백업이 있어도 정보는 여전히 위험에 노출됩니다. 악성코드는 누군가 공격의 다음 단계를 촉발할 때까지 몇 달 동안 잠복하며 데이터나 자격 증명을 탈취할 수 있습니다.

대응 지침: 감염된 시스템을 즉시 네트워크에서 분리하세요. 감염이 시작된 시점과 변경된 파일을 확인하세요. 악성코드가 제거되었음을 확인한 후에만 안전한 백업에서 복원하세요.

피싱 & 비즈니스 이메일 침해(BEC)

피싱 이메일은 정상적인 이메일처럼 보이지만, 위험한 항목을 클릭하거나 다운로드하도록 유도합니다. 비즈니스 이메일 침해는 한 단계 더 나아갑니다—공격자가 CEO나 신뢰할 수 있는 공급업체를 사칭해 송금하거나 로그인 자격 증명을 공유하도록 속입니다.

BEC 공격은 치밀한 사전 조사를 거칩니다. 공격자는 회사의 조직 구조, 최근 거래, 이메일 소통 패턴을 분석합니다. 새 계좌로 긴급 송금을 요청하거나, 직원의 세금 신고 서류를 요구하거나, 가짜 포털에서 결제 정보를 "업데이트"하라고 지시하는 이메일을 받을 수 있습니다. 공격자의 이메일 주소는 실제 주소와 거의 똑같아 보입니다—글자 하나만 다를 수도 있습니다. 일부 BEC 공격에서는 먼저 실제 이메일 계정을 탈취한 뒤, 해당 계정에서 연락처에 있는 사람들에게 피싱 메시지를 보냅니다. 이러한 공격을 알아차리기 어려울수록 직원들이 속을 가능성이 커집니다.

대응 지침: 이메일 헤더에서 발신자 주소 위조와 인증 실패 여부를 확인하세요. 비정상적인 결제 요청이나 낯선 위치에서의 계정 액세스를 조사하세요. 침해된 사서함에서 전달 규칙과 보낸 편지함 항목을 확인하세요.

데이터 침해

데이터 침해란 누군가 데이터에 무단으로 접근해 이를 복사했을 가능성이 있는 상태를 뜻합니다. 고객 기록, 결제 정보, 영업 비밀 또는 직원 데이터가 대상일 수 있습니다. 데이터가 도난당하면 되찾을 수 없습니다—관련자에게 알리고 추가 피해를 제한할 수 있을 뿐입니다.

데이터 침해는 노출된 데이터베이스, 탈취된 자격 증명, 직원을 노린 피싱 공격, 웹 애플리케이션의 취약점을 통해 발생합니다. 공격자는 경보가 울리지 않도록 데이터에 조금씩 접근하며, 수개월 동안 시스템에 머물러도 발견되지 않을 수 있습니다. 일부는 탈취한 데이터를 다크웹에서 레코드당 몇 푼에 판매합니다. 다른 공격자는 사기, 신원 도용 또는 기업 스파이 활동에 이용합니다. 침해를 탐지하지 못하는 기간이 길어질수록 더 많은 데이터가 유출됩니다. 보안 연구원이 판매 중인 데이터를 발견하거나 수사 기관에서 연락을 받은 뒤에야 침해 사실을 알게 될 수도 있습니다.

대응 지침: 접근된 데이터의 종류와 영향을 받은 사람의 수를 파악하세요. 액세스 로그를 검토해 침해가 시작된 시점을 확인하세요. 해당 지역의 법률이 정한 기한 내에 고객과 규제 기관에 통지하세요.

내부자 위협

내부자 위협은 정당한 액세스 권한을 가진 사람이 이를 고의 또는 실수로 오용하는 것을 말합니다—직원이 경쟁사로 이직하기 전에 영업 비밀을 다운로드하거나, 계약업체 직원이 코드에 백도어를 남기거나, 누군가 사회공학 전화에 속아 데이터베이스 비밀번호를 넘기는 경우입니다.

내부자 위협은 이미 접근 권한을 가진 사람에게서 비롯되므로 알아차리기 어렵습니다. 불만을 품은 직원이 몇 주에 걸쳐 민감한 파일을 조금씩 복사할 수 있습니다. 부주의한 개발자가 자격 증명을 코드에 하드코딩한 채 GitHub에 올릴 수도 있습니다. 공격자는 직원 계정 하나를 탈취한 뒤, 그 계정으로 진짜 목표인 고객 데이터베이스나 소스 코드에 접근할 수 있습니다. 권한이 있는 사람의 행동이므로 내부에서는 정상으로 보입니다. 비정상적인 데이터 전송이나 삭제된 감사 로그를 발견했을 때는 이미 피해가 발생했을 수 있습니다. 일부 내부자는 로그를 지우고 흔적을 없애기 때문에 무슨 일이 있었는지 추적하기 어렵습니다.

대응 지침: 통상적인 업무 범위를 벗어난 과도한 파일 액세스를 주시하세요. USB 드라이브나 클라우드 스토리지로의 데이터 다운로드를 모니터링하세요. 직원 계정의 로그인 시간과 위치에 이상이 없는지 확인하세요.

클라우드 보안 사고

클라우드 사고에는 잘못 구성된 스토리지 버킷에서 발생하는 데이터 유출, 사용자 자격 증명 탈취, 취약한 접근 제어를 악용한 공격이 포함됩니다. 클라우드 리소스가 침해되어도 즉시 알아차리지 못할 수 있습니다. 클라우드 제공업체가 항상 알림을 보내지는 않기 때문입니다.

공격자는 공개된 S3 버킷, Azure Blob Storage, Google Cloud Storage에서 개방된 접근 권한을 찾습니다. 기본 비밀번호가 여전히 활성화된 데이터베이스도 찾아냅니다. 누군가의 클라우드 액세스 키가 GitHub에 유출되고 공격자는 사용자가 알아채기 전에 이를 악용합니다. 잘못 구성된 ID 및 액세스 정책 때문에 침해된 계정 하나로 환경의 모든 자원에 접근할 수 있습니다. 공격자는 이를 악용해 측면 이동하며, 가장 중요한 자산을 찾아 탈취합니다. 클라우드 보안 사고가 위험한 이유는 공격자가 조직의 인프라 안에서 활동하기 때문입니다—보안 도구가 공격자의 활동을 기록하더라도, 로그 역시 공격자가 삭제할 수 있는 클라우드에 저장됩니다.

대응 지침: 클라우드 스토리지 버킷의 권한을 확인하고 공개 액세스를 비활성화하세요. ID 및 접근 정책을 검토해 지나치게 광범위한 권한을 찾아내세요. 클라우드 로그에서 예상치 못한 API 호출과 데이터 내보내기 기록을 확인하세요.

클라우드 & SaaS 사고 대응

클라우드 및 SaaS 환경의 IR에 관해 알아야 할 사항은 다음과 같습니다:

클라우드 IR의 과제

클라우드 사고는 온프레미스 공격보다 빠르게 전개됩니다. 로그에서 비정상적인 활동을 발견했을 때는 공격자가 이미 데이터를 복사하고 증거를 삭제했을 수 있습니다. 보안 팀은 기본 인프라를 제어하지 못합니다—클라우드 제공업체가 제어합니다—따라서 제공업체의 로깅 시스템과 지원에 의존해야 합니다.

클라우드의 동적인 특성 때문에 근본 원인 분석도 어려워집니다. 인스턴스는 끊임없이 생성되고 종료됩니다. 공격을 인지했을 때는 침해된 인스턴스가 이미 사라져 증거가 남아 있지 않을 수 있습니다.

멀티 클라우드 환경에서는 문제가 더 복잡해집니다. 공격자가 AWS를 침해했다고 해서 Azure 환경에 대한 접근 권한까지 자동으로 잃는 것은 아닙니다. 각 환경에서 별도로 공격자를 차단해야 합니다. 서로 다른 로깅 시스템, API, 사고 대응 절차를 사용하는 제공업체 전반에서 대응을 조율해야 합니다.

멀티 클라우드 & SaaS 환경의 IR

Cloud Security Posture Management(CSPM)는 멀티 클라우드 리소스 전반에 대한 가시성을 제공합니다. CSPM은 AWS, Azure, Google Cloud에서 잘못된 구성과 취약점을 지속적으로 검사한 다음, 상관관계 분석을 위해 탐지 결과를 SIEM으로 내보냅니다. 멀티 클라우드 및 SaaS 환경의 IR은 변화하는 동적 생태계를 다뤄야 하므로 기존 IR 전략과 다르게 운영되며, 이러한 도구가 유용할 수 있습니다.

공동 책임 모델이 IR에 미치는 영향

클라우드 제공업체가 하이퍼바이저 수준에서 비정상적인 활동을 탐지하더라도 즉시 알리지 않을 수 있습니다. 자체 보안 조치가 노출될 수 있기 때문입니다. 조사에 중요한 정보를 기다려야 하는 상황이 됩니다. 제공업체는 규정 준수 법률에 따라 반드시 공개해야 하는 정보는 공유하지만, 사고 대응 속도는 느려집니다.

SaaS 환경에서는 SaaS 공급업체가 애플리케이션, 데이터베이스, 기본 인프라를 제어합니다. 고객은 사용자 접근, 권한, 통합을 제어합니다. 공격자가 SaaS 취약점을 악용하면 수정 책임이 누구에게 있는지 파악하는 데 시간이 걸려 복구가 지연됩니다. 공급업체가 보안 업데이트를 놓쳤나요? 권한을 지나치게 광범위하게 설정했나요? 서드파티 통합이 문제인가요?

공동 책임 모델에서는 클라우드 제공업체가 모든 보안을 담당한다고 가정할 수 없습니다. 제공업체의 사고 대응 SLA와 사고 발생 시 제공하는 지원을 파악해야 합니다. 원본 로그를 제공하나요, 아니면 요약본만 제공하나요? 응답하는 데 얼마나 걸리나요? 어떤 데이터에 대신 접근할 수 있나요? 이러한 세부 사항이 조사에 걸리는 시간을 결정합니다.

공동 책임 모델을 이해하면 단독으로 처리할 수 없는 작업도 알 수 있습니다. 클라우드 제공업체의 인프라에 패치를 적용할 수 없습니다. 요청하지 않고는 제공업체의 원본 감사 로그에 접근할 수 없습니다. 하이퍼바이저의 보안도 제어할 수 없습니다. 사고 대응 계획에 이러한 제약을 반영하고 사고 발생 전에 클라우드 제공업체로 문제를 상위 보고할 경로를 마련해야 합니다.

클라우드의 로깅 & 증거 처리

클라우드 사고에서 로그는 유일한 증거 기록입니다. 로그가 없으면 무슨 일이 일어났는지, 누가 했는지, 어떻게 막을지 파악할 수 없습니다. 하지만 클라우드 로깅은 사고가 발생하기 전에 의도적으로 설정해야 합니다.

대부분의 클라우드 제공업체는 기본적으로 제한된 기간 동안만 로그를 보관합니다. AWS CloudTrail은 관리 이벤트를 90일간 보관합니다. 공격자가 3개월 동안 활동을 숨겼다면 이전 로그는 사라진 상태입니다. 로그를 변경 불가능한 스토리지에 보관하도록 장기 보존을 설정해야 합니다—AWS의 Object Lock이 적용된 S3, 변경 불가능한 정책이 적용된 Azure Blob Storage, 보존 정책이 적용된 Google Cloud Storage를 사용할 수 있습니다. 로그를 변경할 수 없게 만들면 공격자가 주 계정을 침해해도 삭제할 수 없습니다.

공격자가 포렌식 데이터를 찾아 삭제하기 전에 증거 수집과 보존을 자동화하는 데 집중해야 합니다.

사고를 탐지하면 IR 플레이북이 메모리 덤프, 디스크 스냅샷, 네트워크 흐름 데이터, 실행 중인 프로세스 목록을 자동으로 수집해야 합니다. 클라우드 환경에서는 시스템에 물리적으로 접근할 수 없으므로 이러한 증거 자료를 API로 수집해 1회 기록 스토리지에 저장해야 합니다. 자동화하면 빠뜨리는 항목 없이 증거를 즉시 보존할 수 있습니다.

증거를 처리할 때는 증거 관리 이력을 문서화해야 합니다. 클라우드 로그는 법정에서 증거로 인정받을 수 있도록 신중하게 수집하고 안전하게 보관해야 하는 디지털 자료입니다. 누가 언제 로그에 접근했는지, 로그로 무엇을 했는지, 어디에 보관했는지 기록하세요. 증거 관리 이력이 적절하지 않으면 공격을 입증하는 증거라도 법정에서 인정받지 못합니다. 또한 업계에 적용되는 로그 보존 관련 규정 준수 요건을 파악해야 합니다.

사고 대응에서 흔히 겪는 과제

오늘날 사고 대응에서 마주할 수 있는 다른 일반적인 과제는 다음과 같습니다:

데이터 가시성의 공백

첫 번째 문제는 가시성의 공백입니다. 많은 클라우드 서비스는 기본적으로 로깅이 활성화되어 있지 않습니다. 미리 활성화하지 않았다면 무슨 일이 일어났는지에 대한 기록이 없습니다. 공격자는 이를 알고 측면 이동 전에 로깅을 끕니다. 클라우드 제공업체가 기본 인프라를 제어하므로 제공업체가 공개하기로 한 정보에만 접근할 수 있습니다. 온프레미스에서는 몇 시간이면 끝날 대응도 클라우드 제공업체가 자체 영역을 조사해야 한다면 며칠이 걸립니다.

컨테이너는 자동으로 확장되며 로그를 거의 남기지 않는 임시 리소스를 수천 개 생성합니다. 인프라가 끊임없이 변하면 공격이 언제 시작됐는지 추적하기가 거의 불가능해집니다. 또한 다루는 데이터의 유형, 출처, 양을 명확히 파악해야 합니다. 너무 빠르게 확장하면 데이터 가시성에 공백이 생기고, 알아차리기도 전에 큰 문제로 번집니다.

전문 인력 부족

숙련된 클라우드 보안 전문가를 채용하기는 쉽지 않습니다. 지원자를 평가하고 자격증을 확인해야 합니다. 숙련된 인재를 찾기 어렵다는 사실은 부인할 수 없습니다. 이러한 전문가에 대한 수요는 높지만 공급은 부족합니다.

알림 피로

여러 도구, 리소스, 자산, 워크플로, 클라우드 환경을 다루다 보면 수많은 알림에 압도되기 쉽습니다. 알림 피로는 실제 문제이며, 보안 전문가는 많은 오탐에 발이 묶입니다. 공격자는 주의를 돌리고 악성 코드를 작성해 시스템에 주입하는 등 관심을 분산시키려고 온갖 수단을 동원합니다. 그 사이 자신들이 실행하거나 배포한 실제 위협이 탐지를 피해 지나가도록 하기 위해서입니다.

분산된 하이브리드 환경

분산된 하이브리드 환경에서 보안을 관리하려면 온프레미스 데이터 센터, 프라이빗 클라우드, 퍼블릭 클라우드 플랫폼 전반의 정책과 모니터링을 동시에 조율해야 합니다. 환경마다 다른 접근 제어, 암호화 표준, 규정 준수 요건까지 고려하면 복잡성이 더욱 커집니다.

인프라가 여러 공급업체와 배포 모델에 걸쳐 있으면 보안 팀은 가시성을 유지하고 일관된 기준을 적용하는 데 어려움을 겪습니다. 이 과정에서 공격자가 악용할 수 있는 공백이 생깁니다.

IR 강화 모범 사례

IR을 강화하기 위해 실천할 수 있는 모범 사례는 다음과 같습니다:

IR 대비 훈련 & 테이블탑 연습

IR 대비 훈련과 테이블탑 연습에는 의사소통 흐름, 상위 보고 경로, 의사결정 과정의 점검과 같은 구체적인 목표가 포함됩니다. 여러 부서의 이해관계자를 참여시키고 사람과 프로세스 모두에 집중해야 합니다. 각 연습이 끝나면 공식적으로 결과를 검토하고, 다양하고 정기적인 훈련도 실시하세요.

제로 트러스트 + IR 연계

제로 트러스트 아키텍처를 구축할 때는 항상 침해를 전제로 생각해야 합니다. 엄격한 접근 제어를 적용하고, 최소 권한 원칙을 따르며, ID와 기기 검증을 우선시하세요.

반복적인 IR 단계 자동화

마이크로세그멘테이션 적용도 권장합니다. 지속적인 모니터링을 시행하고 가시성도 높여야 합니다. SOAR 플랫폼으로 반복적인 IR 단계를 자동화하세요. 데이터 수집, 분류, 로그 분석도 자동화하세요. 단계적으로  접근해 최적의 프로세스를 구현하고 자동화와 운영 규모를 점진적으로 발전시킬 수 있습니다.

위협 인텔리전스 & 플레이북 통합

위협 인텔리전스와 플레이북을 강화하려면 지역, 업종, 위험 특성에 가장 적합한 정보원을 선택하세요. 내부 데이터와 외부 피드를 결합해 자세한 맥락을 확보하세요. 데이터 형식을 표준화하고 위협 인텔리전스를 보안 도구와 통합할 수도 있습니다.  MI를 사용

IR 성과 측정을 위한 지표 & KPI

IR 성과를 효과적으로 측정하려면 다음과 같은 주요 사고 대응 지표와 KPI에 주목해야 합니다:

MTTD, MTTR, 격리 시간

평균 탐지 시간(MTTD)은 보안 사고가 시작된 후 팀이 이를 알아차리기까지 걸리는 시간입니다. 평균 대응 시간(MTTR)은 사고를 탐지한 시점부터 팀이 차단 조치를 취할 때까지 걸리는 시간을 측정합니다. 격리 시간은 사고를 완전히 분리하고 피해를 제한하는 데 걸리는 시간입니다.

이 세 가지 지표는 대응 속도를 보여주기 때문에 중요합니다. 위협을 빠르게 탐지하고 격리할수록 피해가 줄어듭니다. MTTD가 길다면 모니터링 도구를 개선해야 한다는 뜻일 수 있습니다. MTTR이 길다면 팀에 리소스나 교육이 부족하다는 신호일 수 있습니다. 격리 시간이 길다면 팀 간 소통이 원활하지 않은 경우가 많습니다.

오탐 감소

보안 도구는 끊임없이 경고를 생성합니다. 하지만 상당수는 실제 위협이 아닌 오탐입니다. 보안 팀이 오탐에 시간을 쏟으면 실제 사고를 놓치고 더 빨리 소진됩니다.

전체 경고 중 실제 위협으로 확인된 비율을 추적하세요. 팀의 대응 역량이 높아질수록 이 비율도 높아져야 합니다. 모니터링 도구를 정교하게 조정하고, 경고 규칙을 명확히 하며, 팀을 교육하면 오탐을 줄일 수 있습니다. 오탐에 쓰는 시간이 줄면 실제 사고에 더 빠르게 대응합니다.

SLA 준수율

서비스 수준 계약(SLAs)은 사고 유형별로 팀이 지켜야 할 대응 시간을 정합니다. 심각한 침해에는 15분 이내의 대응이 필요할 수 있습니다. 중간 위험도 사고에는 2시간, 낮은 위험도 문제에는 24시간이 주어질 수 있습니다.

팀이 이 목표를 얼마나 자주 달성하는지 추적하세요. 높은 SLA 준수율은 이해관계자에게 IR 프로그램의 신뢰성을 보여줍니다. SLAs를 자주 지키지 못한다면 인력을 늘리거나, 도구를 개선하거나, 우선순위를 명확히 해야 합니다.

자체 IR과 외부 위탁 IR: 선택 방법

자체 IR 팀을 구축하는 조직도 있고, 사고 대응을 외부 전문업체에 맡기는 조직도 있습니다. 두 방식을 병행하는 곳도 많습니다. 적합한 방식은 예산, 직면한 위협, 내부 역량에 따라 달라집니다.

외부 위탁을 고려해야 할 때

내부에 보안 전문 인력이 부족하거나 전담 IR 전문가 채용이 부담된다면 외부 위탁을 고려하세요. 관리형 보안 서비스 제공업체(MSSP)나 사고 대응 전문업체는 다양한 공격 유형에 대응해 온 경험을 갖추고 있습니다. 이미 구축하고 검증한 도구와 프로세스도 제공합니다.

사고가 가끔 발생해 상시 IR 인력이 필요하지 않다면 외부 위탁이 효과적입니다. 필요할 때만 비용을 지불하면 됩니다. 대부분의 시간을 대기 상태로 보낼 인력을 채용하는 것보다 비용을 절약할 수 있습니다.

침해 사고 발생 시 제3자의 신뢰성이 필요할 때도 외부 전문업체가 유용합니다. 독립적인 포렌식 팀은 법적 입지를 강화하고 전문적인 조사를 기대하는 규제 기관의 요구를 충족할 수 있습니다.

자체 IR과 외부 위탁 IR의 장단점을 아래에서 비교해 보세요:

SentinelOne이 사고 대응을 강화하는 방법

SentinelOne은 AI 기반 자율 보안 플랫폼인 Singularity™ Platform을 통해 엔드포인트, 클라우드 워크플로, ID 전반의 예방, 탐지, 대응을 통합합니다. 위협을 즉시 격리하고 악의적인 네트워크 활동을 차단합니다. 원클릭 롤백 기능으로 변경 사항을 복구하고 되돌릴 수도 있습니다.

시스템을 공격 이전의 안전한 상태로 복원하고 다운타임과 데이터 손실을 최소화할 수 있습니다. SentinelOne 플랫폼은 Storylines™ 기술을 사용해 여러 소스의 데이터와 알림을 연관 분석합니다. 보안 분석가는 공격의 전체 범위, 근본 원인, 진행 과정을 신속하게 파악합니다. 더 빠르게 의사결정을 내리고 복잡성을 줄이며, SentinelOne의 통합 콘솔에서 모든 보안 운영을 관리하고 모니터링합니다. SentinelOne의 Offensive Security Engine™은 Verified Exploit Paths™를 통해 공격을 사전에 예측하고 공격자의 관점에서 사고해, 다가오는 위협에 신속하게 대응하도록 지원합니다.

또한 Singularity™ Network Discovery를 사용하면 IP를 사용하는 모든 장치와 관리되지 않는 장치를 자동으로 식별하고 특성을 파악할 수 있습니다. 이를 통해 보안 공백을 메우고 공격 표면을 줄일 수 있습니다. Purple AI  세계에서 가장 진보한 사이버 보안 분석가로, 자연어 쿼리를 사용해 위협 헌팅과 사고 조사를 수행합니다.

SentinelOne Singularity™ RemoteOps Forensics를 사용하면 대규모 증거 수집을 간소화하고, 맞춤형 스크립트를 실행하며, 포렌식 프로세스를 가속할 수 있습니다. SentinelOne은 MITRE ATT&CK 프레임워크에 매핑되어 있어 최신 업계 표준을 바탕으로 공격자의 전술과 기법을 깊이 이해합니다.

위협 인텔리전스를 위한 Singularity™ Threat Intelligence는 Mandiant를 기반으로 합니다. 새로운 위협, 공격자의 동기, TTPs에 관한 신뢰도 높은 실시간 맥락 정보를 제공합니다. 맞춤형 플레이북과 사고 대응 자동화로 일반적인 위협에 대응할 수 있습니다. 악성 IP를 자동으로 차단하고, 기기를 격리하며, 침해 지표를 식별하고 차단할 수 있습니다.

SentinelOne은 강력한 API를 사용해 SOAR 플랫폼 같은 타사 보안 도구와 연동할 수 있습니다. SentinelOne의 AI-SIEM 플랫폼은 로그 분석과 경고에 사용할 수 있습니다. SentinelOne의 에이전트리스 CNAPP 플랫폼 또한 선도적인 전문가의 사고 대응 서비스와 CSPM, KSPM, CDR, EASM, 규정 준수 관리 등 다양한 보안 기능을 제공합니다. SentinelOne의 Prompt Security는 Google, OpenAI, Anthropic 등 주요 LLM 제공업체를 대상으로 모델에 구애받지 않는 보호를 제공합니다. 조직 내 섀도 AI 사용에 따른 위험을 방지하고, 에이전트형 AI의 무단 작업을 차단하며, LLM이 사용자에게 유해한 응답을 생성하지 못하도록 합니다. 프롬프트 인젝션 공격과 지갑 고갈 및 서비스 거부 공격을 방지하고, AI 도구와 서비스의 규정 준수 관리도 간소화합니다.

신뢰할 수 있는 MDR

SentinelOne의 Singularity MDR로 안정적인 엔드투엔드 커버리지를 확보하고 안심하고 사용할 수 있습니다.

연락하기

실제 IR 사례/사례 연구

실제 사고 대응 사례와 사례 연구를 살펴보겠습니다:

Target 데이터 유출 사고 (2013)

해커들은 공급업체 연결을 통해 Target의 시스템에 침투해 신용카드 번호 4,000만 건에 접근했습니다. 이 사고는 중대한 공백을 드러냈습니다: Target에는 탐지 도구가 있었지만 명확한 보고 및 대응 체계가 없었습니다. 대응 속도만큼 협력도 중요합니다. Target 팀은 대응에 나선 뒤 영향을 받은 시스템을 격리하고 고객에게 통지했습니다. 사고 대응 계획은 있었지만 실행상의 허점으로 인해 합의금 1,850만 달러를 지불해야 했습니다.

Equifax 침해 사고 (2017)

Equifax는 알려진 취약점을 수개월 동안 패치하지 않았습니다. 공격자들은 이 취약점을 악용해 1억 4,700만 명의 개인정보에 접근했습니다. 진짜 문제는 공격 자체가 아니라 대응 지연이었습니다—Equifax는 몇 주 동안 침해 사실을 발견하지 못했습니다. 대응에 나섰을 때는 이미 공격자들이 데이터를 복사한 뒤였습니다. 체계적인 IR 계획이 있었다면 정기적인 취약점 검사와 신속한 탐지 절차가 포함되었을 것입니다.

Microsoft Exchange Server 공격 (2021)

Microsoft Exchange에서 여러 제로데이 취약점이 발생하자 IR 절차가 없는 조직들은 대응에 혼란을 겪었습니다. 대응 계획, 담당 역할, 커뮤니케이션 체계를 문서화한 조직들은 몇 시간 안에 대응했습니다. 대응을 며칠씩 미룬 기업에서는 공격자들이 지속적인 백도어를 구축했습니다.

결론

사이버 보안 사고 대응 계획은 미래의 방어 체계를 위한 토대이며 모든 조직에 필수적입니다. 보안 리더는 유사한 사고가 다시는 발생하지 않을 것이라고 단정해서는 안 됩니다. 사고 대응 전략을 지속적으로 개선하고 복원력을 구축해야 합니다. SentinelOne과 같은 플랫폼은 이러한 노력에 큰 도움이 됩니다.