소프트웨어 업데이트 배포 무결성
2024년 7월 19일, 단 하나의 구성 파일이 90분도 안 되어 850만 대의 Windows 시스템을 다운시켰습니다. 멀웨어가 아니었습니다. 제로데이도 아니었습니다. 신뢰받던 공급업체의 일상적인 업데이트가 스테이징을 건너뛰고, 카나리를 건너뛰고, 한 번의 물결로 모든 엔드포인트에 도달한 것입니다.
CrowdStrike 사태 이후 이미 업데이트 리스크를 검토하셨다면, 문제는 그 검토가 일회성 작업이었는지 아니면 영구적인 역량이었는지입니다. 아직 검토하지 않으셨다면, 법적·규제 환경은 2024년 7월 이후 여러분 발밑에서 이미 바뀌었습니다. 어느 쪽이든 격차는 동일합니다. 공급업체의 업데이트 파이프라인과 여러분의 프로덕션 엔드포인트 사이에 독립적인 계층이 존재하지 않는다는 것입니다.
$10B+
CrowdStrike 사태로 인한 전 세계 피해액
Fortune/Parametrix, 2024
$2M/시간
심각한 IT 다운타임의 중앙값 비용
New Relic, 2025년 9월
8-12
일반적인 엔터프라이즈 엔드포인트의 커널 수준 에이전트
업계 설문조사 데이터
CrowdStrike의 Falcon 센서는 전체 바이너리 업데이트 없이 탐지 로직 업데이트를 푸시하기 위해 "Rapid Response Content" 메커니즘을 사용합니다. 7월 19일, 프로세스 간 통신 탐지를 위한 두 개의 새로운 Template Instance가 배포되었습니다. 이 인스턴스들은 21번째 입력 매개변수를 참조했습니다. 클라우드 기반 Content Validator는 새로운 21필드 스키마에 대해 업데이트를 검사하고 이를 승인했습니다. 그러나 Windows 커널에서 실행 중이던 Content Interpreter는 여전히 20개 필드만 예상하고 있었습니다.
| 구성 요소 | 위치 | 예상 필드 | 발생한 일 |
|---|---|---|---|
| Content Validator | 클라우드 | 21개 필드 | 업데이트 승인 (새 스키마와 일치) |
| Content Interpreter | 엔드포인트 커널 (Ring 0) | 20개 필드 | 범위 밖 메모리 읽기, 즉각적인 BSOD |
출처: CrowdStrike External Root Cause Analysis, 2024년 8월 6일
충돌은 부팅 시퀀스의 매우 초기 단계에서 발생하여 Falcon 관리 에이전트가 결코 초기화되지 못했습니다. 이로 인해 "죽은 에이전트" 루프가 발생했습니다. 충돌의 원인이 바로 그 명령을 수신해야 할 소프트웨어였기 때문에, 엔드포인트는 CrowdStrike로부터 롤백 명령을 받을 수 없었던 것입니다. IT 팀은 각 시스템을 안전 모드로 부팅하여 다음 경로로 이동해야 했습니다 C:\Windows\System32\drivers\CrowdStrike\, 그리고 결함이 있는 C-00000291-*.sys 파일을 수동으로 삭제해야 했습니다. Delta Air Lines는 이 작업을 4만 대의 서버에 걸쳐 수행했습니다. 복구에는 5일이 걸렸습니다.
CrowdStrike는 하나의 사례 연구이지만, 그 패턴은 권한 있는 업데이트를 푸시하는 모든 공급업체에 적용됩니다. 여러분의 플릿은 EDR 에이전트, DLP 에이전트, 암호화 에이전트, 패치 에이전트, VPN 클라이언트, 그리고 디바이스 관리 에이전트를 실행합니다. 각각은 커널 수준에서 또는 상승된 시스템 권한으로 작동합니다. 각각은 자체 업데이트 채널을 가지고 있습니다. 각각은 자체 일정에 따라 업데이트를 푸시합니다. 여러분의 변경 자문 위원회는 내부 배포를 검토하지만 "우리는 공급업체를 신뢰한다"는 이유로 공급업체 업데이트는 그냥 통과시킵니다.
아무도 논의하지 않는 두 번째 실패 모드는 에이전트 충돌 연쇄입니다. 두 공급업체가 같은 날 커널 인터페이스를 업데이트하면, 드라이버 호환성 문제가 단일 공급업체 실패와 동일한 블루스크린 결과를 초래할 수 있습니다. 그러나 근본 원인 분석은 몇 시간이 아니라 몇 주가 걸립니다. 서로 상대방의 업데이트를 탓하는 두 공급업체 지원 팀을 두고 삼각측량을 해야 하기 때문입니다.
"우리는 공급업체를 신뢰한다"의 비용
중대형 기업의 41%가 시간당 다운타임 비용을 100만~500만 달러로 추산합니다. 금융 및 의료 기관은 시간당 500만 달러 이상을 보고합니다. 여러분의 CAB이 결코 검토하지 않은 공급업체 업데이트로 인한 4시간 다운타임은 여러분의 연간 보안 도구 지출 전체보다 더 큰 비용이 듭니다. (ITIC / New Relic, 2025)
CrowdStrike 사태는 기술적 복구 이상의 결과를 낳았습니다. 그것은 소프트웨어 공급업체 책임을 둘러싼 법적 프레임워크를 바꿨습니다. 세 가지 변화가 여러분의 다음 공급업체 계약 갱신에 중요합니다.
2025년 5월 | Fulton County Superior Court
Ellerbe 판사는 중과실, 컴퓨터 침해, 그리고 부작위에 의한 사기 에 대한 청구를 CrowdStrike의 계약상 책임 상한에도 불구하고 진행하도록 허용했습니다. Delta는 자동 업데이트를 거부했지만, 채널 파일이 커널 수준에서 그 설정을 우회했습니다.
여러분의 노출: 공급업체가 여러분의 설정으로 제어할 수 없는 채널을 통해 Ring 0 콘텐츠를 푸시할 수 있다면, 여러분 계약의 업데이트 설정은 집행 불가능할 수 있습니다. 여러분의 계약이 전체 센서 업데이트와 rapid response content를 구분하는지 검토하십시오.
보고 의무 시작: 2026년 9월 11일
ENISA에 대한 의무적 24시간 취약점 보고. 소프트웨어 공급업체는 문서화된 검증 및 롤백 역량을 포함하여 업데이트 프로세스에서 보안 내재 설계를 입증해야 합니다.
여러분의 노출: 공급업체 업데이트가 여러분의 EU 사업에 다운타임을 초래하면, 공급업체와는 별개로 24시간 이내에 보고 의무가 발생할 수 있습니다. 그 시계는 공급업체가 통지할 때가 아니라 여러분이 인지하는 순간 시작됩니다.
2024년 개정, 2026년 발효
이제 소프트웨어는 엄격 책임 하에서 "제품"으로 명시적으로 분류됩니다. 기업은 소프트웨어 및 사이버보안 결함에 대해 계약으로 책임을 배제할 수 없습니다 . 이는 독립형 소프트웨어와 제품에 내장된 소프트웨어 모두에 적용됩니다.
여러분의 노출: 여러분의 구독 계약에 있는 공급업체 책임 상한은 EU 관할권에서 유효하지 않을 수 있습니다. EU 시장에서 운영한다면, 여러분의 계약은 이 변화를 반영해야 합니다.
SEC 공시 요건
이제 상장 기업은 중대한 사이버보안 사고를 4영업일 이내에 공시하고, 10-K 위험 요인 신고서에서 소프트웨어 공급망 위험 노출을 기술해야 합니다. 4시간 이상 동안 시간당 200만 달러의 비용이 드는 공급업체 유발 다운타임은 중요성 기준을 넘을 가능성이 높습니다. 여러분의 IR 팀에는 침해 대응 플레이북뿐만 아니라 공급업체 다운타임 플레이북이 필요합니다. (SEC 최종 규칙, 2024년 발효)
이 분야의 모든 플레이어는 문제의 한 조각을 해결합니다. 어느 누구도 전체를 해결하지 못합니다. 격차는 공급업체가 자체 업데이트 프로세스에 대해 하는 일과 여러분이 독립적으로 검증할 수 있는 일 사이에 있습니다.
| 플레이어 | 그들이 제공하는 것 | 격차 |
|---|---|---|
| CrowdStrike (사고 이후) | 자체 복구 모드, 콘텐츠 고정, 고객 배포 제어, Digital Operations Center. 2025년 3분기 유지율: 97%+ | 공급업체의 자기 감시. 그들의 검증 개선은 의미가 있지만, 여러분은 동일한 조직이 자체 업데이트를 검증하리라고 신뢰하는 것입니다. 독립적인 검증 계층이 없습니다. |
| Microsoft (Windows Resiliency Initiative) | Quick Machine Recovery (Win 11 24H2에서 GA). 보안 제품을 커널에서 사용자 모드로 옮기는 Endpoint Security Platform. 2026-2027년 마이그레이션 일정. | 플랫폼 수준이지 감사 수준이 아님. 부팅 복구를 해결하고 커널 표면적을 줄이지만, 다른 공급업체가 여러분의 플릿에 업데이트를 어떻게 배포하는지는 검증하지 않습니다. |
| SentinelOne / Palo Alto (Cortex XDR) | 자체 업데이트 파이프라인을 갖춘 자율 엔드포인트 보호. CrowdStrike의 경쟁 대안. | 동일한 구조적 위험. 그들은 자체 채널을 통해 커널 수준 업데이트를 푸시합니다. 다른 공급업체, 동일한 "감시자는 누가 감시하는가?" 문제입니다. |
| Datadog / Dynatrace / Splunk | AI 기반 옵저버빌리티, 이상 탐지, 실시간 알림. 엔터프라이즈 규모의 성숙한 데이터 수집. | 예방적이 아니라 사후 대응적. 그들은 업데이트가 프로덕션에 도달한 후에 이상을 탐지합니다. Datadog이 알림을 보낼 즈음이면, BSoD는 이미 연쇄적으로 퍼진 상태입니다. |
| SBOM / SCA 도구 (Snyk, Sonatype) | 오픈소스 의존성 스캐닝, 소프트웨어 구성 분석, 취약점 추적. | 완전히 잘못된 계층. 그들은 여러분 코드의 오픈소스 라이브러리를 감사합니다. CrowdStrike의 채널 파일은 오픈소스 의존성이 아니라 독점적인 공급업체 구성이었습니다. 이 도구들은 그것을 결코 보지 못합니다. |
| ITSM 플랫폼 (ServiceNow, Jira) | 변경 관리 워크플로우, CAB 검토, 내부 배포에 대한 감사 추적. | 공급업체 업데이트는 CAB을 우회함. 여러분의 ITSM은 여러분 팀이 만드는 변경을 추적합니다. 커널 에이전트에 대한 공급업체 푸시 업데이트는 워크플로우를 완전히 우회합니다. 티켓도, 검토도, 감사 추적도 없습니다. |
| Big 4 / 대형 SI | IT 위험 평가, 컴플라이언스 감사, 거버넌스 프레임워크 설계. Deloitte, Accenture, KPMG 모두 사이버보안 사업부를 보유하고 있습니다. | 프레임워크 중심이지 기술적이지 않음. 그들은 사전 배포 샌드박스가 아니라 거버넌스 성숙도 모델을 제공합니다. 6개월짜리 평가는 보고서를 내놓습니다. 여러분에게 필요한 것은 실시간으로 업데이트를 가로채는 자동화된 시스템입니다. 또한: 전사적 평가의 경우 50만 달러 이상의 계약 최소 금액이 듭니다. |
솔직한 단서: 이 목록의 일부 격차는 어떤 외부 컨설팅으로도 해결할 수 없습니다. 조직 변경 관리(여러분의 CAB이 실제로 공급업체 업데이트를 검토하도록 만들기), 공급업체 관계 정치(CrowdStrike에게 그들의 업데이트 프로세스를 신뢰하지 않는다고 말하기), 그리고 레거시 엔드포인트 다양성(샌드박스에서 가상화할 수 없는 Windows Server 2012를 실행하는 시스템)은 내부 주체가 책임져야 합니다. 우리는 기술적 인프라를 구축합니다. 그것을 사용하는 것은 여러분의 팀입니다.
다섯 가지 역량으로, 각각 위 환경의 특정 격차를 해결합니다. 모든 계약은 맞춤형이지만, 아키텍처는 5,000개 이상의 엔드포인트와 6개 이상의 커널 수준 에이전트를 가진 환경을 위해 우리가 설계한 패턴을 따릅니다.
우리는 여러분의 플릿에서 실행 중인 모든 커널 수준 및 권한 있는 에이전트를 매핑합니다. 각 에이전트에 대해, 업데이트 채널 메커니즘, 롤백 역량, 스테이징 제어(또는 그 부재), 그리고 에이전트 자체가 충돌의 원인이 될 때 무슨 일이 일어나는지를 문서화합니다.
산출물: 어느 공급업체가 CAB 검토 없이 Ring 0에 업데이트를 푸시할 수 있는지, 어느 에이전트가 부팅 시퀀스를 충돌시킬 경우 죽은 에이전트 루프를 만드는지, 그리고 어느 공급업체 계약에 단계적 출시 보장이 없는지를 보여주는 위험 순위가 매겨진 에이전트 인벤토리입니다. 대부분의 기업은 커널 수준에서 실행되고 있는지 몰랐던 에이전트를 발견합니다.
우리는 여러분의 실제 엔드포인트 다양성을 그대로 반영하는 가상 환경을 구축합니다. OS 버전, 패치 수준, 하드웨어 프로파일, 그리고 여러분이 프로덕션에서 실행하는 전체 에이전트 스택을 포함합니다. CrowdStrike의 충돌은 특정 Windows 빌드와 드라이버 구성에서만 발현되었습니다. 단일하고 깨끗한 VM 하나로는 그것을 놓쳤을 것입니다.
중요한 공급업체가 업데이트를 푸시하면, 샌드박스가 먼저 이를 수신하여 대표적인 구성들에 걸쳐 5회의 재부팅 사이클을 실행하고 스키마 호환성을 검증합니다. 우리는 여러분의 특정 에이전트 스택 조합을 모델링합니다. 에이전트 간 충돌(예: EDR과 암호화가 같은 날 동일한 커널 콜백 테이블을 업데이트하는 경우)이야말로 아무도 테스트하지 않는 실패 모드이기 때문입니다.
Delta 대 CrowdStrike 이후, 모든 공급업체 구독 계약은 검토가 필요합니다. 우리는 여러분의 계약을 책임 상한, 강제 업데이트 조항, "컴퓨터 침해" 노출, 통지 의무, SLA 격차에 대해 분석합니다. 우리는 EU CRA, 제조물 책임 지침, SEC 공시 요건과 교차 참조하여 수정 사항이 관할권 전반에서 유효하도록 합니다.
산출물: 여러분의 법무팀이 다음 갱신에서 사용할 수 있는 구체적인 계약 수정 문구입니다. 우리는 어느 공급업체가 계약에서 전체 바이너리 업데이트와 rapid response content를 구분하는지, 어느 계약에 커널 수준 액세스에 대한 예외 조항이 있는지, 그리고 어느 책임 상한이 Delta 판례 하에서 위험에 처하는지를 표시합니다.
우리는 공급업체 업데이트가 프로덕션 엔드포인트에 도달하기 전에 이를 가로채는 자동화된 워크플로우를 구축합니다. 이 시스템은 여러분의 ITSM(ServiceNow, Jira Service Management)과 통합되어, CAB이 현재 공급업체 푸시 업데이트에 대해 결여하고 있는 감사 추적을 생성하고, 공급업체가 기본적으로 지원하지 않을 수 있는 단계적 출시 정책을 집행합니다.
이 시스템은 구성 수준 업데이트의 스키마 변경, 공급업체가 문서화한 것보다 더 큰 변경을 나타내는 바이너리 diff 이상, 그리고 배포 속도 급증(CrowdStrike 실패 패턴과 일치하는, 한 번의 물결로 모든 엔드포인트에 적용)을 감시합니다. 알림은 몇 분 안에 보류/진행 결정을 내릴 수 있을 만큼 충분한 맥락과 함께 여러분의 보안 운영 팀으로 라우팅됩니다.
이사회 이사 중 단 29%만이 CISO의 사이버보안 보고를 "매우 효과적"이라고 평가합니다(IANS Research, 2026). 우리는 여러분의 소프트웨어 업데이트 배포 위험을 이사회가 이해하는 용어로 정량화하는 보고 프레임워크를 구축합니다. 여러분의 실제 비즈니스 운영에 기반한 다운타임 시간당 재무적 노출, 특정 법령(EU CRA, SEC 공시 시한)에 매핑된 규제 책임, 그리고 어느 단일 공급업체 실패가 가장 광범위한 다운타임을 초래할지를 보여주는 공급업체 집중 위험입니다.
이것은 대시보드가 아니라 분기별 산출물입니다. 각 보고서에는 업데이트된 위험 점수, 지난 분기 이후의 변경 사항(새로운 공급업체 업데이트, 계약 갱신, 규제 동향), 그리고 수정 비용 대 감소된 노출로 순위가 매겨진 구체적인 권장 사항이 포함됩니다. 여러분의 CISO는 서술이 아니라 숫자를 들고 감사위원회에 들어갑니다.
네 단계입니다. 처음 두 단계는 병렬로 진행되며 일반적으로 4-6주 만에 완료됩니다. 구현은 엔드포인트 플릿 규모와 공급업체 수에 따라 6-10주가 걸립니다. 지속적인 지원은 분기별로 이루어집니다.
1-3주차
2-5주차 (1단계와 병렬)
6-14주차
분기별
단서: 지속적인 지원은 선택 사항입니다. 우리가 3단계에서 구축하는 시스템은 여러분의 내부 팀과 함께 운영되도록 설계되었습니다. 우리는 갱신이나 규제 변화 중에 협상 테이블에서 공급업체 중립적인 전문성을 원하실 때 관여를 유지합니다.
여러분의 현재 업데이트 거버넌스에 관한 열 가지 질문입니다. 결과는 우리와 함께 일하는지 여부와 관계없이 여러분이 실행할 수 있는 우선순위가 매겨진 실행 목록을 제공합니다. 약 3분이 소요됩니다.
여러분의 플릿에서 실행 중인 모든 커널 수준 및 권한 있는 에이전트를 매핑하는 것부터 시작하십시오. 대부분의 기업은 8-12개의 에이전트(EDR, DLP, 암호화, VPN, MDM, 패치)를 실행하고 있으며, 어느 공급업체가 변경 자문 위원회 검토를 거치지 않고 Ring 0에 업데이트를 푸시할 수 있는지에 대한 중앙화된 기록이 없다는 것을 발견합니다.
각 에이전트에 대해 세 가지를 문서화하십시오. 업데이트 채널 메커니즘(CrowdStrike의 채널 파일처럼 rapid response content를 푸시하는가, 아니면 전체 센서 빌드만 푸시하는가?), 롤백 역량(에이전트가 부팅 시퀀스를 충돌시키면 스스로 복구할 수 있는가, 아니면 CrowdStrike의 Falcon이 그랬던 것처럼 죽은 에이전트 루프를 만드는가?), 그리고 여러분의 계약이 실제로 부여하는 스테이징 제어(공급업체의 마케팅이 말하는 것이 아니라, 구독 계약이 여러분에게 지연하거나 유예하도록 허용하는 것)입니다.
그런 다음 여러분의 실제 엔드포인트 다양성을 반영하는 사전 배포 샌드박스를 구축하십시오. CrowdStrike의 7월 19일 업데이트는 특정 드라이버 구성을 가진 특정 Windows 빌드를 충돌시켰습니다. 단일하고 깨끗한 VM 하나를 실행하는 샌드박스로는 그것을 놓쳤을 것입니다. 여러분에게는 대표적인 하드웨어 프로파일, OS 패치 수준, 그리고 에이전트 조합이 필요합니다. 모든 중요한 공급업체 업데이트를 프로덕션에 도달하기 전에 이러한 구성들에 걸쳐 5회의 재부팅 사이클을 통해 실행하십시오.
마지막으로, 여러분의 공급업체 계약을 검토하십시오. Delta 대 CrowdStrike 이후, 강제 업데이트 조항과 책임 상한은 소송 표적입니다. 여러분의 계약에 여전히 한 자릿수 백만 달러의 책임 상한이 있고 단계적 출시 보장이 없다면, 기술적 격차와 일치하는 계약상 격차가 있는 것입니다.
공급업체 업데이트 감사는 대부분의 기업이 결여하고 있는 세 개의 계층에 대한 가시성을 요구합니다. 계층 1: 업데이트 채널 아키텍처. 각 공급업체에게 그들의 업데이트가 개발 단계에서 여러분의 엔드포인트까지 어떻게 이동하는지에 대한 기술 문서를 요청하십시오. 구체적으로, 구성 수준 업데이트(CrowdStrike의 채널 파일과 같은)가 전체 바이너리 업데이트와 동일한 검증 파이프라인을 따르는지, 아니면 지름길을 택하는지 물어보십시오. CrowdStrike의 Content Validator와 Content Interpreter는 서로 다른 스키마 기대치를 가지고 있었습니다. 그 불일치가 근본 원인이었습니다.
계층 2: 배포 속도 및 폭발 반경 제어. 각 공급업체에게 그들의 단계적 출시 주기를 문서화하도록 요청하십시오. 그들은 몇 개의 내부 링을 사용하는가? 외부 고객 중 몇 퍼센트가 첫 번째 물결에서 업데이트를 받는가? CrowdStrike는 850만 개의 모든 엔드포인트에 한 번의 물결로 푸시했습니다. 여러분의 계약은 배포 단계당 최대 폭발 반경을 명시해야 합니다.
계층 3: 롤백 및 복구 역량. 각 공급업체에 대해, 그들의 에이전트가 부팅 실패를 일으킬 때 무슨 일이 일어나는지 테스트하십시오. 에이전트 자체가 충돌의 원인일 때 에이전트의 관리 프로세스가 롤백 명령을 받을 수 있는가? CrowdStrike의 관리 에이전트는 충돌이 부팅 시퀀스의 너무 초기 단계에서 발생했기 때문에 결코 초기화되지 못했고, 이로 인해 각 시스템에서 수동 안전 모드 개입이 필요한 고아 엔드포인트가 생겼습니다.
우리는 이 세 개의 계층을 지속적으로 검증하고, 문서화된 관행으로부터의 편차를 표시하며, 여러분의 보안 팀이 분기별로 검토할 수 있는 공급업체 스코어카드를 생성하는 자동화된 감사 프레임워크를 구축합니다.
엔드포인트 보안을 위한 카나리 배포는 웹 서비스를 위한 카나리 배포와 운영상 다릅니다. 트래픽의 1%를 새 버전으로 라우팅할 수 없습니다. 여러분의 실제 플릿 구성과 일치하는 하드웨어 다양성 링이 필요합니다.
Ring 0은 여러분의 사전 배포 샌드박스입니다. 여러분의 OS 매트릭스(Windows Server 2019, 2022, Windows 10 22H2, 11 23H2 등), 패치 수준, 그리고 여러분이 프로덕션에서 실행하는 전체 에이전트 스택을 포괄하는 가상화된 환경입니다. 이 링은 실제 엔드포인트가 노출되기 전에 스키마 불일치와 드라이버 충돌을 잡아냅니다. Ring 1은 여러분 IT 부서 자체의 시스템으로, 일반적으로 50-200개의 엔드포인트입니다. 이들은 이상을 상세히 보고할 수 있고 무언가 실패하면 재구축을 감내할 수 있는 사람들이 담당합니다.
Ring 2는 편의가 아니라 하드웨어 다양성을 기준으로 선정된 프로덕션 엔드포인트의 대표 샘플입니다. 여러분의 플릿에 씬 클라이언트, 키오스크 시스템, 도메인 컨트롤러가 포함되어 있다면, Ring 2에는 세 가지 모두가 포함되어야 합니다. 단순히 표준 데스크톱 500대를 고르지 마십시오. Ring 3은 더 넓은 물결로, 일반적으로 프로덕션의 10-20%이며, 단계 사이에 24시간 감시 창을 둡니다. Ring 4는 나머지입니다.
각 링에는 정의된 감시 창(Ring 1은 최소 4시간, Ring 2 이상은 24시간), 자동화된 상태 점검(부팅 성공, 에이전트 하트비트, 커널 충돌 보고), 그리고 실패율이 공급업체가 아니라 여러분이 설정한 임계값을 초과하면 배포를 중단시키는 롤백 트리거가 필요합니다. 핵심은 여러분의 링이 공급업체의 배포 제어에 위임되는 것이 아니라 여러분 쪽에서 집행되어야 한다는 것입니다. 우리는 여러분의 플릿과 모든 공급업체의 업데이트 채널 사이에 위치하는 시스템으로서 링 인프라, 자동화된 상태 모니터링, 롤백 트리거를 구축합니다.
Fulton County Superior Court의 2025년 5월 판결은 제3자 보안 소프트웨어를 실행하는 모든 기업의 위험 계산을 바꿨습니다. Kelly Lee Ellerbe 판사는 구독 서비스 계약이 책임을 계약 가액으로 제한한다는 CrowdStrike의 주장에도 불구하고, Delta의 중과실, 컴퓨터 침해, 부작위에 의한 사기 청구를 진행하도록 허용했습니다.
세 가지 함의가 여러분의 공급업체 계약에 중요합니다. 첫째, 강제 업데이트 조항은 이제 소송 표적입니다. Delta는 설정에서 자동 업데이트를 거부했지만, CrowdStrike의 커널 수준 채널 파일 메커니즘이 그 설정을 우회했습니다. 공급업체가 여러분의 설정으로 제어할 수 없는 채널을 통해 Ring 0 콘텐츠를 푸시할 수 있다면, 여러분 계약의 업데이트 설정은 집행 불가능할 수 있습니다. 여러분의 계약이 전체 센서 업데이트와 rapid response content를 구분하는지 검토하십시오.
둘째, 책임 상한은 불법행위 청구 하에서 유효하지 않을 수 있습니다. 법원은 컴퓨터 침해에 관한 법령상 의무가 구독 계약과 독립적으로 존재한다고 판결했습니다. 공급업체의 업데이트가 여러분 시스템에 대한 무단 접근에 해당한다면, 계약상 상한은 무관합니다. 여러분의 법무팀은 커널 수준 액세스에 대한 명시적 예외 조항과 의무적 단계적 출시 의무를 협상해야 합니다.
셋째, EU 제조물 책임 지침은 이제 소프트웨어를 엄격 책임 하의 제품으로 분류합니다. 기업은 2026년부터 소프트웨어 결함에 대해 계약으로 책임을 배제할 수 없습니다. EU 관할권에서 운영한다면, 여러분의 공급업체 계약은 이를 반영해야 합니다. 우리는 이 세 가지 차원에 대해 공급업체 계약을 감사하고 여러분의 다음 갱신 주기를 위한 구체적인 수정 문구를 작성합니다.
EU 사이버 회복탄력성법의 취약점 보고 의무는 2026년 9월 11일에 시작됩니다. 디지털 요소가 있는 소프트웨어를 EU 시장에 제조, 유통, 또는 수입한다면, 적극적으로 악용되는 취약점을 24시간 이내에 ENISA에 보고하고, 72시간 이내에 상세 통지를 제공하며, 14일 이내에 최종 보고서를 발행해야 합니다.
제3자 소프트웨어(엔드포인트 보안 에이전트 포함)를 소비하는 기업의 경우, CRA는 세 가지 컴플라이언스 의무를 만듭니다. 첫째, 공급업체에 대한 실사. 여러분은 소프트웨어 공급업체가 업데이트 프로세스에서의 보안 내재 설계, 문서화된 취약점 처리, 업데이트 무결성 보장을 포함한 CRA 요건을 충족하는지 검증해야 합니다. 여러분의 공급업체가 단계적 출시 없이 CrowdStrike 스타일의 업데이트를 푸시했다면, 그것은 CRA의 보안 내재 설계 표준을 충족하지 못할 수 있습니다.
둘째, 여러분 자신의 업데이트 프로세스. EU 시장에 배포되는 소프트웨어를 구축하거나 통합한다면, 여러분의 CI/CD 파이프라인은 보안 검증, 업데이트 무결성 확인, 문서화된 롤백 역량을 입증해야 합니다.
셋째, 사고 보고 체계. 공급업체 업데이트가 여러분의 EU 사업에 다운타임을 초래하면, 공급업체 자체 의무와는 별개로 24시간 이내에 ENISA에 보고할 의무가 발생할 수 있습니다. 보고 시계는 공급업체가 통지할 때가 아니라 여러분이 인지하는 순간 시작됩니다. CRA를 넘어, 개정된 EU 제조물 책임 지침은 소프트웨어를 엄격 책임 하의 제품으로 분류하며, 제조업체는 보안 결함에 대해 계약으로 책임을 배제할 수 없습니다. 우리는 CRA 대비 업데이트 거버넌스 프레임워크를 구축합니다. CRA 요건에 부합하는 공급업체 평가 설문지, 내부 파이프라인 검증 도구, 그리고 24/72시간 시한을 충족하는 사고 보고 워크플로우입니다.
CrowdStrike 사태 이후 발표된 Microsoft의 Windows Resiliency Initiative에는 근본적인 변화가 포함됩니다. 제3자 엔드포인트 보안 제품을 커널 모드(Ring 0)에서 사용자 모드로 옮기는 것입니다. Quick Machine Recovery 기능은 이미 Windows 11 24H2에서 GA되어, 시스템이 정상적으로 부팅할 수 없을 때에도 원격 복구를 가능하게 합니다. 더 큰 변화인 Windows Endpoint Security Platform은 보안 공급업체가 탐지 역량을 유지하면서 커널 밖에서 작동하도록 하는 구조화된 마이그레이션 경로입니다.
이 마이그레이션은 2026-2027년에 걸쳐 전개될 것이며 기업에게 세 가지 실질적인 도전을 만듭니다. 첫째, 여러분의 보안 공급업체는 어떤 채널 파일보다도 더 중대한 아키텍처 업데이트를 출시할 것입니다. 커널 모드에서 사용자 모드로의 전환은 에이전트가 시스템 호출을 가로채고, 파일 작업을 모니터링하고, 네트워크 트래픽을 검사하는 방식의 근본적인 재작성입니다. 이러한 전환을 공격적으로 테스트하십시오. 아키텍처 변경 자체가 CrowdStrike 사고와 동일한 폭발 반경 위험을 수반합니다.
둘째, 전환 기간 동안 여러분은 혼합 플릿을 운영하게 됩니다. 일부 엔드포인트는 커널 모드 에이전트에, 일부는 사용자 모드 에이전트에, 일부는 둘 다에 걸쳐 있는 버전에 있게 됩니다. 여러분의 보안 정책 집행, 탐지 규칙, 사고 대응 플레이북은 이러한 불일치를 고려해야 합니다.
셋째, 모든 공급업체가 같은 속도로 마이그레이션하지는 않을 것입니다. CrowdStrike, SentinelOne, Palo Alto는 각각 다른 일정을 가지고 있습니다. 여러 보안 에이전트를 실행한다면, 그들의 마이그레이션 일정이 서로 다르게 겹쳐 새로운 호환성 위험을 만들 것입니다. 우리는 여러분의 현재 에이전트 아키텍처를 매핑하고, 겹침 위험을 최소화하기 위해 공급업체 전환의 순서를 정하는 단계적 마이그레이션 계획을 구축하며, 커널-사용자 모드 마이그레이션의 각 단계에 대한 검증 게이트를 수립합니다.
전체 CrowdStrike 기술 분석과 회복탄력적 시스템 아키텍처를 포함한, 이 솔루션 페이지의 배경이 되는 연구입니다.
CrowdStrike 사태의 기술적 사후 분석, Delta 대 CrowdStrike 소송의 법적 분석, 그리고 AI 기반 업데이트 검증 및 자가 치유 시스템을 위한 아키텍처 프레임워크입니다.
그것을 예방하는 평가는 다운타임 한 시간보다 적은 비용이 듭니다.
우리는 여러분의 공급업체와 프로덕션 엔드포인트 사이에 위치하는 독립적인 업데이트 거버넌스 시스템을 구축합니다. 플랫폼 편향 없음. 정직한 평가와 충돌하는 공급업체 제휴 없음.