여러분 쪽에서 아무도 검토하지 않은 파일 하나로 850만 대의 컴퓨터가 멈췄다
중견 항공사의 보안을 책임지는 한 친구가 2024년 7월 19일 아침 식사 자리에서 저에게 사진 한 장을 문자로 보냈습니다. 그것은 출발 안내판이었는데, 모든 패널이 똑같은 색조의 파란색이었고, 똑같은 흰색 오류 문구가 터미널 전역에 걸쳐 패널마다 반복되고 있었습니다. 그는 사진과 함께 아무 말도 쓰지 않았습니다. 그럴 필요가 없었습니다.
제가 커피를 다 마셨을 무렵, 그 수는 850만 대의 Windows 기계였고, 90분도 안 되어 다운되었습니다. 악성코드가 아니었습니다. 제로데이도 아니었습니다. 바로 그 기업들이 자신을 안전하게 지켜 달라며 특별히 비용을 지불한 벤더인 CrowdStrike의 일상적인 콘텐츠 업데이트였습니다. 엔드포인트를 보호하던 바로 그것이 엔드포인트를 벽돌로 만들어 버린 것입니다.
그 이후로 저는 그 벤더들과 그 기계들 사이에 있어야 했던 계층을 구축하는 데 시간을 써 왔습니다 — 우리가 지금 이렇게 부르는 것, 소프트웨어 업데이트 배포 무결성, 즉 벤더의 업데이트 파이프라인과 여러분의 프로덕션 플릿 사이의 독립적인 체크포인트입니다. 이 글은 왜 그 계층이 존재하지 않았는지, 왜 그것을 구축하는 뻔한 방법이 잘못되었는지, 그리고 그 파란 화면이 켜진 순간 커널 수준 에이전트를 운영하는 모든 기업에서 무엇이 바뀌었는지에 관한 것입니다.
21번째 필드
저는 CrowdStrike의 외부 근본 원인 분석(External Root Cause Analysis)을 2024년 8월 공개된 그날 밤에 읽었는데, 원인이 너무나 사소해서 거의 모욕적으로 느껴질 정도였습니다.
CrowdStrike의 센서인 Falcon은 Rapid Response Content라고 부르는 메커니즘을 통해 탐지 로직을 배포합니다 — 완전히 새로운 바이너리를 밀어내지 않고도 새로운 위협에 대응하게 해 주는 작은 구성 업데이트입니다. 7월 19일, Falcon은 프로세스 간 통신(inter-process-communication) 탐지를 위한 두 개의 새로운 Template Instance를 배포했습니다. 그 인스턴스들은 21번째 입력 매개변수를 참조했습니다. CrowdStrike의 클라우드 기반 Content Validator는 그 업데이트를 새로운 21개 필드 스키마에 대조해 검사하고, 유효하다고 판단하여, 승인했습니다.
문제는 Windows 커널 내부, 즉 운영 체제에서 가장 권한이 높은 계층인 Ring 0에서 실행되던 Content Interpreter였습니다. 그것은 여전히 20개 필드를 기대하고 있었습니다. 21번째 필드에 손을 뻗었을 때, 존재하지 않는 메모리를 읽었고, 기계는 즉시 블루스크린을 띄웠습니다.
클라우드 검증기는 새로운 규칙에 따라 업데이트를 승인했습니다. 그것을 받은 커널은 여전히 옛 규칙에 따라 살고 있었습니다. 그 둘이 일치하는지 아무도 확인하지 않았습니다.
엔지니어로서 저를 여전히 가장 괴롭히는 부분이 여기 있습니다. 그 충돌은 부팅 시퀀스 아주 초기에 일어나서 Falcon 자체의 관리 에이전트가 아예 올라오지 못했습니다. 그래서 엔드포인트들은 CrowdStrike가 내보낸 롤백 명령을 받을 수 없었습니다. 그 명령을 받기로 되어 있던 소프트웨어가 바로 기계를 충돌시키고 있던 그 소프트웨어였기 때문입니다. 업계는 이것을 부르는 암울한 이름을 가지고 있습니다 — 죽은 에이전트 루프(dead-agent loop)입니다. 복구는 버튼이 아니었습니다. 그것은 각 기계마다 사람이 직접, 안전 모드로 부팅해 C:\Windows\System32\drivers\CrowdStrike\로 이동한 뒤, 결함이 있는 C-00000291-*.sys 파일을 손으로 삭제하는 일이었습니다. Delta는 40,000대의 서버에서 이 작업을 했습니다. 복구에는 5일이 걸렸습니다.
결코 한 벤더의 문제가 아니었다
쉬운 이야기는 CrowdStrike가 부주의했다는 것입니다. 그것은 또한 잘못된 교훈이며, 그것을 쫓았다면 저는 잘못된 제품을 만들게 되었을 것입니다.
그 패턴은 CrowdStrike만의 것이 아니기 때문입니다. 아무 대기업의 엔드포인트 목록을 열어 보면 커널 수준에서 또는 상승된 권한으로 실행되는 8개에서 12개의 에이전트를 발견하게 됩니다 — EDR 에이전트, 데이터 유출 방지 에이전트, 암호화 에이전트, 패치 에이전트, VPN 클라이언트, 기기 관리 에이전트. 스프레드시트의 여덟 개 행, 그리고 여덟 개의 개별 업데이트 채널이 있고, 각각 자기만의 일정에 따라 밀어내며, 각각 무사통과됩니다.
그해 여름 저는 CISO들에게 같은 질문을 계속 던졌습니다. 이 벤더 업데이트들을 프로덕션에 도달하기 전에 누가 검토하는가? 대답은 매번 이런 식이었습니다. 우리에겐 변경 자문 위원회(change advisory board)가 있습니다. 그리고 잠시 후, 솔직한 부분이 나옵니다. 변경 자문 위원회는 내부 배포는 한 줄 한 줄 검토하지만, 벤더 업데이트는 티켓 큐를 건너뛰고, 스테이징을 건너뛰고, 곧바로 모든 엔드포인트로 갑니다 — "우리는 벤더를 신뢰하니까"요. 그 문구는 업계 전체를 떠받치고 있었지만, 그 뒤에는 아무런 메커니즘도 없었습니다.
거의 아무도 이야기하지 않는 두 번째 장애 유형이 있는데, 진단하기가 더 까다롭습니다. 두 벤더가 같은 날 커널 인터페이스를 업데이트하면, 그들의 드라이버가 충돌하여 단일 벤더 버그와 정확히 똑같은 블루스크린을 만들어 낼 수 있습니다. 다만 이제 근본 원인 분석은 몇 시간이 아니라 몇 주가 걸립니다. 각자 나름의 이유로 서로를 탓하는 두 벤더 지원 팀 사이에서 삼각 측량을 하고 있기 때문입니다.
우리가 처음 만든 버전, 그리고 그것이 실패한 이유
우리가 시작했을 때, 저는 답이 탐지라고 확신했습니다. 엔드포인트를 지켜보고, 정상이 어떤 모습인지 학습하고, 업데이트가 오작동하기 시작하는 순간 비명을 지르는 것 말입니다. 그것은 관측성(observability) 시장 전체가 우리에게 갖도록 훈련시킨 본능입니다 — Datadog, Dynatrace, Splunk 모두 방금 무슨 일이 일어났는지 알려 주는 데는 탁월합니다.
우리는 그것의 한 버전을 만들었습니다. 업데이트로 인한 장애들의 재현에 대해 그것을 돌려 봤습니다. 그리고 그것은 가능한 가장 쓸모없는 방식으로 작동했습니다. 문제를 아름답게 잡아냈습니다 — 뒤늦게, 첫 기계들이 이미 다운되고 난 다음에 말이죠.
이것이 와닿았던 통화를 기억합니다. 한 파일럿 고객사의 CISO는 모의 불량 롤아웃 몇 초 만에 우리 대시보드에 불이 들어오는 것을 지켜보더니, 대략 이런 말을 했습니다. 자신이 이미 불타고 있다는 사실을 더 빨리 알아내는 방법은 필요 없다고요. 그에게 필요한 것은 애초에 업데이트가 모든 엔드포인트에 한꺼번에 도달하지 않는 것이었습니다. 90분 만에 850만 대의 기계를 강타하는 장애에 대해 배포 이후의 탐지란, 집이 이미 사라진 뒤에야 울리는 화재경보기입니다.
관측성은 건물이 불타고 있다고 알려 줍니다. 그때쯤이면 남은 유일한 질문은 재건에 며칠이 걸리느냐입니다.
그달은 제가 조용히 잘못된 계층에 작업을 걸었던 달이었고, 그 대시보드가 그것을 증명하는 것을 지켜본 일이 우리에게 일어난 가장 유용한 일이었습니다. 문제는 결코 탐지 속도가 아니었습니다. 문제는 아무런 체크포인트도 없었다는 것이었습니다 — 사전에, 업데이트가 도착하기도 전에 말입니다.
그렇다면 왜 기존 도구들은 이것을 잡아내지 못하는가?
사람들은 소프트웨어 공급망 보안이 이미 이것을 다룬다고 가정합니다. 그렇지 않으며, 그 이유는 명확합니다.
SBOM과 소프트웨어 구성 분석(software-composition-analysis) 도구 — Snyk, Sonatype — 은 여러분의 오픈소스 의존성 트리를 감사합니다. 그것들은 세 단계 깊이의 어떤 npm 패키지에 알려진 취약점이 있다고 알려 주도록 만들어졌습니다. 하지만 벤더의 Rapid Response Content, 채널 파일, CrowdStrike나 그 어떤 동종 업체가 서명해 밀어낸 독점 구성 블롭 — 그것은 그들에게 보이지 않습니다. 그것은 여러분의 의존성 트리 안에 없습니다. 그것은 그 트리를 우회하여, 곧바로 커널로 밀어넣어집니다. 여러분의 소프트웨어 공급망을 지킨다는 도구들이 완전히 엉뚱한 계층을 감사하고 있는 것입니다.
ITIL과 여러분의 변경 자문 위원회요? 절차적입니다. 그것들은 여러분이 시작하는 변경을 위해 설계된 체크리스트이자 승인 절차이며, 벤더의 릴리스 주기에는 결코 연결된 적이 없습니다.
그리고 CrowdStrike 자체의 개선책 — 자가 복구 모드, 콘텐츠 고정(content pinning), 단계적 "고객 배포 제어", CISA에서 빌려온 Resilient-by-Design 프레임워크 — 은 진짜 노력이고, 저는 그것을 무시하지 않습니다. 하지만 그것이 실제로 무엇인지 읽어 보십시오. 그 제어들 하나하나가 모두 벤더의 자기 감시입니다. 21번째 필드를 내보낸 바로 그 회사가 이제 그것이 안전하다고 인증하는 회사입니다. 벤더의 푸시와 여러분의 엔드포인트 사이에 서 있는 독립적인 당사자는 여전히 없습니다. 이번 사태 이후 분기에 CrowdStrike의 총 유지율(gross retention)은 97%를 넘었는데, 이는 시장이 그들을 처벌하지 않았다는 것을 말해 줄 뿐, 근본적인 격차가 닫혔는지에 대해서는 아무것도 말해 주지 않습니다. 닫히지 않았습니다.
그 격차가 곧 제품 전체입니다. 서야 할 올바른 자리는 불을 지켜보는 엔드포인트 위도 아니고, 그들의 말을 믿는 벤더 안쪽도 아닙니다. 그것은 그 사이입니다. 즉 업데이트를 프로덕션에 도달하기 전에 받아, 여러분의 실제 플릿을 그대로 반영한 샌드박스에 통과시키고, 콘텐츠를 여러분의 커널이 실제로 기대하는 것과 대조하며, 잘못되었을 경우의 폭발 반경을 모델링하는 벤더 중립적 체크포인트입니다. 그것이 우리가 결국 구축한 계층이며, 그 형태는 우리 솔루션 페이지에서 확인할 수 있습니다. 21 대 20 필드 버그 같은 스키마 불일치는 바로 사전 배포 샌드박스가 한꺼번에 850만 대의 기계에 걸쳐서가 아니라 카나리 링에서 드러내는 종류의 문제입니다.
법적 지형이 바뀌었고, 대부분의 계약은 아직 따라잡지 못했다
한동안 저는 규제 측면을 배경 소음처럼 취급했습니다. 제가 틀렸고, 구매자들이 그 이유를 보여 주었습니다. 그들 서랍 속 계약서는 그들이 생각하는 방식으로 더 이상 그들을 보호해 주지 않습니다.
Delta 대 CrowdStrike 사건부터 시작해 봅시다. 2025년 5월, Fulton County Superior Court에서 Ellerbe 판사는 중과실, 컴퓨터 무단 침입, 부작위에 의한 사기 청구가 진행되도록 허용했습니다 — 그 너머로 CrowdStrike의 계약상 책임 한도까지 말입니다. 컴퓨터 무단 침입 부분은 모든 CISO를 긴장시켜야 할 대목입니다. Delta는 자동 업데이트를 해제해 두었는데도, 채널 파일이 어쨌든 커널에 도달했습니다. 벤더가 여러분의 설정이 통제하지 못하는 채널을 통해 Ring 0 콘텐츠를 밀어넣을 수 있다면, 여러분 계약서의 업데이트 기본 설정은 집행 불가능할 수 있습니다. 대부분의 엔터프라이즈 MSA는 전체 센서 업데이트와 래피드 리스폰스 콘텐츠를 구분조차 하지 않습니다. 구분해야 합니다.
그런 다음 EU가 움직였는데, 이것은 제가 참여하는 모든 계약 재협상에서 지금 제기하는 부분입니다. 개정된 제조물 책임 지침(Product Liability Directive)은 이제 소프트웨어를 엄격 책임 하의 "제품"으로 명시적으로 분류하며, 기업이 소프트웨어 및 사이버보안 결함에 대한 책임을 계약으로 배제할 수 없다고 규정합니다. 벤더가 계약서에 동그라미 친 수백만 달러대의 책임 한도는 EU 관할권에서는 아예 유효하지 않을 수 있습니다. 이와 함께, EU 사이버 회복력 법(Cyber Resilience Act)은 2026년 9월 11일부터 의무적인 취약점 보고를 시작합니다 — 결정적으로, 그 24시간 시계가 시작되는 시점은 여러분이 인지하는 순간이지, 벤더가 여러분에게 통지하는 순간이 아닙니다. 벤더의 장애가 순식간에 여러분의 보고 의무가 될 수 있습니다.
그리고 미국에서는, SEC가 이제 상장 기업들에게 중대한 사이버보안 사건을 4영업일 이내에 공시하고 소프트웨어 공급망 위험을 10-K 서류에 기술하도록 요구합니다. 비용 데이터로 계산을 해 보십시오. 2025년 9월 New Relic 연구는 심각한 IT 다운타임의 중간값 비용을 시간당 200만 달러로 추산했고, 중대형 기업의 41%는 자신들의 수치를 시간당 100만 달러에서 500만 달러 사이로 잡았습니다. 여러분의 변경 위원회가 한 번도 보지 못한 벤더 업데이트로 인한 4시간짜리 장애는 그 자체만으로 중대성 기준을 넘습니다. 여러분의 투자자 관계(IR) 팀에게는 침해 대응 플레이북뿐 아니라 벤더 장애 플레이북이 필요합니다.
여러분 쪽에서 아무도 검토하지 않은 업데이트로 인한 4시간짜리 장애는 중간값으로 대략 800만 달러에 이릅니다 — CISO의 책상이 아니라 CFO의 책상에 올라가는 종류의 숫자입니다.
"이런 일이 우리에게도 일어날 수 있을까?"
2024년 7월 이후, 세계의 모든 이사회가 자사의 CISO에게 똑같은 네 마디 질문을 던졌습니다. 그리고 제가 이야기를 나눈 CISO들은 대부분 체계적인 답을 가지고 있지 않았습니다 — 그들을 탓하려는 것은 아닙니다. 2026년 초 IANS Research 데이터에 따르면 이사회 이사 중 단 29%만이 자사 CISO의 보안 보고가 "매우 효과적"이라고 여기며, 업데이트 배포 위험은 바로 실재하고, 비용이 크며, 대부분의 팀이 가진 도구로는 숫자를 붙이기가 거의 불가능한 종류의 것입니다.
그것이 우리가 구축한 것의 더 조용한 절반입니다. 단지 기술적 체크포인트만이 아니라, "이런 일이 우리에게도 일어날 수 있을까"를 이사회에 내놓을 수 있는 답으로 바꾸어 주는 것입니다. 즉 모든 권한 있는 에이전트와 그 업데이트 채널의 목록, 벤더별로 정량화된 폭발 반경 모델, 어떤 업데이트가 샌드박스에서 검증되었고 거기서 무엇을 했는지에 대한 기록입니다. 그것은 예전에 "우리는 우리 벤더를 신뢰한다"라고 적혀 있던 슬라이드를, 그 작업을 보여 주는 슬라이드로 바꿉니다.
사람들은 이제 Microsoft가 보안 벤더들을 커널 밖으로 밀어내고 있으니 — Quick Machine Recovery를 갖춘 Windows Resiliency Initiative, 그리고 엔드포인트 보안을 커널 모드에서 사용자 모드로 점진적으로 옮기는 것 — 이것이 정말 필요한지 저에게 묻습니다. 그것은 진정으로 좋은 구조적 전환이며, 시간이 지나면서 최악의 폭발 반경을 줄여 줄 것입니다. 하지만 그 일정은 2026년과 2027년까지 이어지고, 여러분은 그 기간 내내 마이그레이션 도중의 혼합 플릿을 운영하게 될 것이며, "덜 파국적"이라는 것이 "검증되었다"는 뜻은 아닙니다. 잘못된 구성을 배포하는 사용자 모드 에이전트도 여전히 자신이 책임지는 것을 다운시킬 수 있습니다. 독립적인 검사의 필요성은 커널이 사라진다고 해서 사라지지 않습니다. 그저 한 계층 위로 올라갈 뿐입니다.
사람들이 말하는 또 다른 것은 체크포인트를 추가하면 모든 것이 느려진다는 것입니다 — 래피드 리스폰스 콘텐츠의 요점 전체가 실시간 위협에 맞선 속도라는 것이죠. 일리 있습니다. 하지만 그 선택은 결코 속도 대 안전이 아니었습니다. CrowdStrike의 클라우드 검증기는 빠르게 실행되었는데도 결함이 있는 업데이트를 승인했습니다. 파일을 새 스키마와 대조해 검사했을 뿐, 커널이 동의하는지는 결코 검사하지 않았기 때문입니다. 실패는 속도가 아니었습니다. 독립적인 검사의 부재가 실패였습니다. 30대의 기계에서 스키마 불일치를 잡아내는 카나리 링은 몇 분이면 됩니다. 그 대안은 Delta에게 5일과 5억 5천만 달러를 치르게 했습니다.
그 파란 안내판은 실제로 무엇을 의미했는가?
저는 계속 그 출발 안내판을 찍은 제 친구의 사진으로 돌아가게 됩니다. 어느 한 아침 동안, 모든 기업이 그 안에서 살아가는 추상적 관념 — 우리의 신뢰하는 벤더들이 우리를 안전하게 지켜 준다는 것 — 이 문자 그대로의 파란색으로, 패널에 패널이 이어지며, 발이 묶인 사람들로 가득한 건물 안에서 구현되었습니다.
벤더들이 실패한 것은 그들이 무모했기 때문이 아닙니다. 그들이 실패한 것은, 우리가 집단적으로, 단 하나의 공급업체가 보낸 단 하나의 구성 파일이 계산을 확인하는 독립적인 당사자 없이 모든 엔드포인트에 한꺼번에 도달할 수 있는 산업을 만들었기 때문입니다. CrowdStrike는 그저 번호가 뽑힌 쪽이었습니다. 그 일이 일어나게 한 구조는 지금 이 순간, 여러분이 이름을 댈 수 있는 거의 모든 회사의 엔드포인트 목록 안에 자리하고 있습니다 — 8개에서 12개의 권한 있는 에이전트, 8개에서 12개의 채널, 그리고 그 사이에는 아무도 없습니다.
우리가 구축한 체크포인트의 전체 아키텍처는 여기에서 읽어 보실 수 있습니다. 하지만 제가 CISO가 얻어 가길 바라는 부분은 어떤 제품보다도 단순합니다. 이런 종류의 다음 장애는 스스로를 보안 사건이라고 알리지 않을 것입니다. 그것은 서명되고, 신뢰받고, 승인된 채로 도착할 것입니다 — 바로 지난번과 똑같은 방식으로요. 결말을 바꾸는 유일한 것은, 850만 대 모두가 한꺼번에 알아차리기 전에 업데이트와 기계가 여전히 일치하는지를 확인하며, 푸시와 프로덕션 플릿 사이에 서 있는 누군가입니다.
