Defcon에서 "Most Epic Fail"로 PwnieAwards를 수상한 CrowdStrike

[GN⁺]

Hacker News 의견들

• 이 재앙에서 유머를 찾는 건 이해하지만, 책임 소재는 어떻게 되는지 궁금함
  이 사건으로 수십억 달러 손실이 났다는 이야기는 HN에서 몇 번 봤지만, 소송 이야기는 아직 많지 않음
  라이선스가 그렇게 철벽이라 고객이 구제받을 길이 없는 건지, 개인 PC가 몇 시간/며칠 멈춘 소비자라면 이해할 수 있어도 산업계가 이런 수준의 위험 노출을 받아들이는 건 말이 안 된다고 봄
  토목공학이 진지한 분야로 여겨지는 큰 이유도 여기에 있음. 다리가 무너지면 금전 책임뿐 아니라 형사책임 가능성도 있고, 토목공학 학생들은 비윤리적으로 행동하거나 엔지니어로서 받아들일 수 없는 위험을 감수하면 감옥에 갈 수 있다는 걸 반복해서 배움
  소프트웨어 엔지니어도 이런 수준의 책임성과 실무 규범에 도달할 길이 있을까?

  • 토목공학은 물리적 제품을 설계한다는 점이 다름. 어떤 것도 한계치에 딱 맞춰 설계하지 않고, 모든 것에 충분한 안전 여유를 둠
    허리케인 중에 지진까지 나는 상황에서 화물차가 빽빽하게 지나는 다리를 계산한 뒤 20%를 더 얹는 식임. 보가 버틸지 확신이 안 들면 더 크게 만들면 되고, 계산이 0.5% 틀려도 큰 문제가 안 됨
    설계 문서에 오타가 있어 15.0피트 틈에 150피트 보를 넣으려 하면 시공자가 확인을 요청할 것임. 그래서 다리 붕괴는 거의 확실히 중대한 과실의 결과가 됨
    반면 프로그래밍에서는 < 하나가 <= 대신 들어간 것만으로도 멀쩡한 상태와 수십억 달러 피해가 갈릴 수 있음. 지구상 어떤 프로그래머도 사소하지 않은 복잡도의 애플리케이션을 100% 무결점으로 작성할 수 없음
    형식적 정확성 증명을 내세우는 seL4 마이크로커널에도 버그가 있음. 컴파일러와 증명 검사기는 기술적으로 가능하지만 명백히 잘못된 일을 시켜도 불평하지 않음
    가장 작은 실수에도 사실상 무제한 책임을 지겠다는 건 정상적인 사람이 받아들일 수 없음
    소프트웨어 엔지니어에게 책임을 묻고 싶다면, 먼저 일상적인 선의의 실수와 중대한 과실을 구분할 방법을 찾아야 하는데, 이를 형식화하기는 매우 어려울 것임
  • Delta가 5억 달러 손실에 대해 소송을 예고하자 CrowdStrike는 공개적으로 계약상 CrowdStrike의 책임 한도가 한 자릿수 백만 달러라고 답함
    이어서 소송이 시작되면 백업 계획, 장애조치 계획, 테스트 일정과 결과, 마지막 백업 복구 훈련 시점 등을 증거개시에서 요구하겠다고 목록을 보냄
    사실상 “소송하면 당신들의 IT 관행을 우리보다 더 창피해질 만큼 깊게 파헤치고, 잘못이 당신들에게 있었다는 걸 보이겠다”는 뜻임
  • 구제 수단은 있지만, 말한 대로 일반 사람을 위한 건 아님. 기업들은 CrowdStrike를 상대로 소송을 제기하고 있고 앞으로도 계속할 것이며, CrowdStrike가 공개한 문서를 보면 피해 기업들이 이길 가능성이 매우 높아 보임
    CrowdStrike가 중대한 과실을 저질렀고, 기업들에 직접 손실과 간접적인 평판 손상을 명백히 초래했다는 점을 판사·배심·중재인에게 설득할 가능성이 커 보임
    솔직히 CrowdStrike가 끝까지 다툴지도 모르겠음. 대부분은 법정 밖에서 합의될 것 같고, 앞으로 몇 년 동안 CrowdStrike가 무너지는 모습을 보게 될 수도 있음
  • 많은 회사는 수입원이 끊기는 사건에 대비한 보험을 갖고 있음. 농부의 작물 보험이나 대형 소매점의 재난 피해 보험처럼, 인프라 붕괴로 매출이 일정 기간 0이 되는 상황에도 뭔가 있을 것이라고 봄
    영향을 받은 모두가 ClownStrike에 손실 100%를 청구해도 ClownStrike의 매출로 그 손실을 감당할 수 없음. 회사를 문 닫게 만들고 싶어도 실제 손실에 가까운 금액을 회수할 수는 없음
    그래서 실제로 무엇을 제안할 건지 궁금함. 버그 없는 코드는 거의 불가능하고, 일부 위험은 사용자가 받아들이는 것임
    소프트웨어가 사용되기 전에 반드시 100% 버그가 없어야 한다고 정말 생각하는가? 그걸 어떻게 증명할 것인가? 그렇다면 본인 코드가 얼마나 깨끗하길래 그게 가능하다고 보는지도 이어지는 질문임
  • 가능하긴 한데, 답은 시간임. 토목공학은 수천 년의 역사를 가졌고, 소프트웨어 공학은 훨씬 젊으며 이 분야의 기초도 아직 변하고 있음
    적어도 내 나라에서는 1970년대 후반부터 시스템 분석가, 전자 컴퓨터 프로그래머, 데이터 처리 기계 조작자, 타이피스트(!) 면허제 입법안이 있었음
    이런 법들이 통과됐다면 우리나라 소프트웨어 개발 발전은 수십 년 뒤처졌을 것임. 예를 들어 한 법안은 “단말기(디지털 또는 시각 장치)를 포함한 전자 처리 장치나 기계의 조작 및 운용”을 “데이터 처리 기계 조작자” 면허 보유자에게만 허용하려 했음

• 이 문제는 CrowdStrike를 넘어, 규제기관과 보험사를 만족시키려고 기성 보안 제품을 사면서 실제로 그것이 무엇을 하고 어떻게 작동하는지는 신경 쓰지 않는 보안 접근 전반을 보여줌
  기술을 규제하면 안 된다는 뜻은 아니지만, 현재의 “이걸 사서 책임을 덜어내자” 모델은 작동하지 않음
  더 나쁜 건 이 일을 예상한 사람들, 즉 IT 부서가 아마 아무것도 할 수 없었다는 점임. 회사 상층부에서 “사이버 보험” 요건이나 다른 규정 때문에 의무화했을 가능성이 높음. 미친 일임

  • 그렇게 느끼는 훌륭한 IT 담당자들을 많이 봤지만, 내 경험상 대부분의 IT 부서는 계약서가 필요한 항목을 충족하면 실제 문제를 해결하는지에는 별로 관심이 없었음
    예전 직장에서 CrowdStrike와 비슷한 소프트웨어가 주말 사이 내 워크스테이션에 설치됐고, 돌아와 보니 컴파일 시간이 20% 느려짐
    당시 그걸 측정하고 있어서 수십 개의 측정값이 있었고, ETL 추적으로 그 소프트웨어가 원인임을 보였지만 IT는 인정하지 않았음. 공급사 계약서에 우리 작업부하에서는 성능 영향이 없을 것으로 되어 있었기 때문임
  • 대부분의 IT 부서가 이걸 예견하지는 못했을 것이고, 전체 보안 전략을 그 가능성에 맞춰 세우지 않은 것도 당연함. 이런 서사가 어디서 나오는지 모르겠음
    Falcon은 고객에게 실제적이고 진짜 보안 이점을 제공했고 지금도 제공함. 그렇다고 모든 위험을 없애는 것도 아니고, 자체적인 위험을 만들지 않는다는 뜻도 아님
    모든 공학 문제처럼 말 그대로 상충관계의 게임. 여기 있는 사람들에게 낯설 일도 아님
    갑자기 HN이 사후확신과 최신 사건 편향에 찬 보안 전문가들로 가득 차서, 기업들이 이 총알을 어떻게 피할 수 있었는지 설명하지만 애초에 Falcon을 사용함으로써 피하고 있던 실제 총알들은 고려하지 않음

• 이건 법정 증거 영상이나 소송에 쓰일 수도 있는 일이고, 웃긴 일이 아님
  원래는 보안 괴짜들끼리 이야기하는 닫힌 순간이었을 텐데, 이제 큰 피해를 입은 일반 대중이 마음껏 조롱할 수 있게 공개되어 버림

  • CrowdStrike 임원이 상황을 가볍게 여겼다고는 전혀 보지 않았음. 오히려 그 연설은 상황을 진지하게 받아들이고, 엄청난 실수였음을 인정하며, 그 트로피를 수치의 표식이자 미래 CrowdStrike 직원들을 위한 경고담으로 받아들이겠다고 한 것으로 보였음
    그 임원이 이 상을 받아들인 건 정말 품격 있는 행동이었다고 생각함. 물론 그렇게 말한다고 해서 CrowdStrike가 사건에 대한 책임이나 배상책임에서 면제된다는 뜻은 전혀 아님
  • 티셔츠로 만들면 웃길 수는 있음
    When I use
    REGEXP
    I use it in my
    KERNEL CODE
    비극과 희극은 같은 동전의 양면임

• xcancel 경유: https://xcancel.com/singe/status/1822324795645575263

• 컴퓨터 보안 문제는 베트남전 때 이미 나타났고, 미국은 실제로 효과적인 컴퓨터 보안 모델을 찾아내는 작업을 했음. 그런데 우리는 그걸 사실상 기억에서 지워버린 사회에 살고 있음
  왜 컴퓨터가 실행하려는 모든 것 위에서 스캐너가 24시간 365일 돌아가야 하는가?
  왜 운영체제는 주변 권한에 의존해야 하는가?
  CrowdStrike를 탓하는 건 Linux, MacOS, Windows 등 운영체제에서 우리가 매일 무시하는 근본적인 설계 실패로부터 시선을 돌릴 뿐임

• 아직도 Microsoft를 탓하고 있는데, 업데이트되는 코드를 커널 밖에서 실행하고 커널 모드 코드는 관찰과 행동에만 쓰며 논리에는 쓰지 않는 방식이 불가능한 것도 아님

• IT에서 일하고 있고, Clown Strike가 인프라 대부분을 날려버렸을 때 하필이면 온콜이던 불쌍한 사람이었음
  개인적으로 클라우드 기반 헛소리를 쓰지 않겠다고 버틴 덕분에 며칠이 아니라 몇 시간 만에 복구했을 가능성이 큼
  IT 디렉터 같은 사람들이 이걸 문제로 보지 않고, 이런 헛소리를 막기 위한 조치를 하나도 취하지 않는다는 사실 때문에 머지않아 또 다른 클라우드 기반 대형 장애를 상대하게 될까 봐 꽤 걱정됨
  “남의 컴퓨터에 의존하는 건 바보들뿐”이라고 지겹도록 반복하고 있고, 그 말에 100% 동의함

  • 내부 인프라에서 단일 장애점이 나쁜 이유는 이해하면서, 외부 공급사의 제품·서비스가 단일 장애점이 되는 건 괜찮다고 보는 관리자나 임원이 있다는 게 이상함
    계약을 맺고 돈을 내면, 내부 엔지니어와 달리 실수하지 않는 초인들이 만들고 유지보수하는 것처럼 여기는 듯함. 이런 잘못된 신뢰가 이해되지 않음
  • 100% 동의함. 게다가 Azure VD 같은 클라우드 서비스에 터무니없는 비용을 내는 모습을 보면 놀라움
    연간 클라우드 예산의 일부만으로도 회사가 직접 매우 안정적이고 오프라인에서도 가능한 인프라를 만들 수 있음
  • 말투가 굉장히 공격적으로 들림. 맞는 말을 하더라도 같이 일하고 싶지는 않을 것 같음
    그렇게 공격적으로 말하지 않으면 요지를 더 잘 전달할 수 있을지도 모름
  • 바보 같은 CTO들이 CTO 서밋, 자기 유인이 뒤틀린 컨설턴트, 그리고 온갖 무작위 콘퍼런스에서 조언을 받아들이면 할 수 있는 일이 많지 않음

• 비교용 이전 Pwnie Award 수상자 목록: https://en.wikipedia.org/wiki/Pwnie_Awards

  • 이전 “가장 장대한 실패” 수상 대부분은 자연스럽게 Microsoft가 지배함
    계속 망신을 돌릴 수는 있지만, 이런 프로덕션 장애가 나쁜 프로세스 때문이라고 믿는다면 Microsoft도 여기서 분명 큰 역할을 했음

• 이 난장판 이후에도 CEO와 CTO가 어떻게 자리를 유지하고 있는지 정말 궁금함

• 여러 도시에서 911이 작동하지 않고 병원 흐름이 멈출 정도로 느려졌는데, Defcon에 가서 농담할 시간은 있는 건가?

  • 아직 컴퓨터를 고치지 못한 병원이 있나? 물론 CS가 망쳤지만, 손해배상하고 프로세스를 바꾸는 것 말고 지금 할 수 있는 일이 또 뭔지는 모르겠음
    사람들이 같은 실수를 반복하지 않도록 경고하는 건 나쁜 시간 사용처럼 보이지 않음
  • 여기서 CS가 비난받아야 하는 건 맞지만, 911 같은 중요 시스템에 CS를 넣은 것 자체가 큰 실수라고 봄
    다만 그걸 한 사람은 책임을 피할 수 있다는 걸 알았을 가능성이 크니, 신경 쓸 이유도 없었겠지 싶음