Defconで「Most Epic Fail」としてPwnie Awardsを受賞したCrowdStrike

[GN⁺]

Hacker News の意見

• この大惨事にユーモアを見いだすのは分かるが、責任の所在はどうなるのか気になる
  この件で数十億ドルの損失が出たという話は HN で何度か見たが、訴訟の話はまだあまり多くない
  ライセンスがそこまで鉄壁で顧客が救済を受ける道がないのか、個人 PC が数時間／数日止まった消費者なら理解できても、産業界がこのレベルのリスク曝露を受け入れているのは筋が通らないと思う
  土木工学が真剣な分野と見なされる大きな理由もここにある。橋が崩れれば金銭的責任だけでなく刑事責任の可能性もあり、土木工学の学生は、非倫理的に行動したりエンジニアとして受け入れられないリスクを取ったりすれば刑務所に行くこともある、と繰り返し学ぶ
  ソフトウェアエンジニアも、このレベルの責任性と実務規範に到達する道はあるのだろうか？

  • 土木工学は物理的な製品を設計する点が違う。どんなものも限界値ぴったりには設計せず、すべてに十分な安全余裕を持たせる
    ハリケーンの最中に地震まで起きる状況で、貨物車がぎっしり通る橋を計算したうえで 20% 上乗せするようなもの。梁が耐えられるか確信が持てなければ大きくすればよく、計算が 0.5% 間違っていても大きな問題にはならない
    設計書にタイプミスがあって 15.0 フィートの隙間に 150 フィートの梁を入れようとすれば、施工業者が確認を求めるはずだ。だから橋の崩落は、ほぼ確実に重大な過失の結果になる
    一方プログラミングでは、<= の代わりに < が 1 つ入っただけで、正常な状態と数十億ドル規模の被害が分かれ得る。地球上のどんなプログラマーも、些細とは言えない複雑さのアプリケーションを100% 無欠陥で書くことはできない
    形式的な正しさの証明を掲げる seL4 マイクロカーネルにもバグはある。コンパイラや証明検査器は技術的には可能だが、明らかに間違ったことをさせても文句は言わない
    最小のミスにも事実上無制限の責任を負うというのは、まともな人なら受け入れられない
    ソフトウェアエンジニアに責任を問いたいなら、まず日常的な善意のミスと重大な過失を区別する方法を見つける必要があるが、それを形式化するのは非常に難しいだろう
  • Delta が 5 億ドルの損失について訴訟を予告すると、CrowdStrike は公開の場で、契約上 CrowdStrike の責任上限は一桁台の百万ドルだと回答した
    続けて、訴訟が始まればバックアップ計画、フェイルオーバー計画、テスト日程と結果、最後にバックアップ復旧訓練を実施した時期などをディスカバリーで要求する、というリストを送った
    実質的には「訴訟を起こすなら、あなた方の IT 慣行を我々以上に恥ずかしくなるほど深く掘り下げ、過ちはあなた方にあったことを示す」という意味だ
  • 救済手段はあるが、言う通り一般人向けのものではない。企業は CrowdStrike を相手取って訴訟を起こしており、今後も続けるだろうし、CrowdStrike が公開した文書を見る限り、被害企業が勝つ可能性は非常に高そうだ
    CrowdStrike が重大な過失を犯し、企業に直接的な損失と間接的な評判被害を明確にもたらしたと、裁判官・陪審・仲裁人に納得させられる可能性は高いように見える
    正直、CrowdStrike が最後まで争うかどうかも分からない。大半は法廷外で和解するだろうし、今後数年で CrowdStrike が崩れていく様子を見ることになるかもしれない
  • 多くの会社は収入源が断たれる事態に備えた保険を持っている。農家の作物保険や大手小売店の災害損害保険のように、インフラ崩壊で一定期間売上がゼロになる状況にも何かしらあるはずだと思う
    影響を受けた全員が ClownStrike に損失の 100% を請求しても、ClownStrike の売上ではその損失を賄えない。会社を閉じさせたいとしても、実際の損失に近い金額を回収することはできない
    だから実際に何を提案するつもりなのか気になる。バグのないコードはほぼ不可能で、一部のリスクは利用者が受け入れるものだ
    ソフトウェアは使われる前に必ず 100% バグがない状態でなければならないと本当に考えているのか？ それをどう証明するのか？ そうだとすれば、自分のコードがどれほどクリーンならそれが可能だと思えるのか、という問いも続く
  • 可能ではあるが、答えは時間だ。土木工学には数千年の歴史があり、ソフトウェア工学ははるかに若く、この分野の基礎もまだ変化している
    少なくとも私の国では、1970 年代後半からシステムアナリスト、電子計算機プログラマー、データ処理機械オペレーター、タイピスト（！）の免許制に関する法案があった
    こうした法律が通っていたら、我が国のソフトウェア開発の発展は数十年遅れていただろう。たとえばある法案は、「端末（デジタルまたは視覚装置）を含む電子処理装置または機械の操作および運用」を「データ処理機械オペレーター」免許保持者にだけ認めようとしていた

• この問題は CrowdStrike を超えて、規制当局や保険会社を満足させるために既製のセキュリティ製品を買いながら、実際にそれが何をしてどう動くのかは気にしない、セキュリティへのアプローチ全般を示している
  技術を規制すべきではないという意味ではないが、現在の「これを買って責任を減らそう」モデルは機能していない
  さらに悪いのは、これを予想していた人々、つまり IT 部門がおそらく何もできなかったという点だ。会社上層部が「サイバー保険」の要件や別の規定のために義務化した可能性が高い。狂っている

  • そう感じている優秀な IT 担当者を多く見てきたが、私の経験では、ほとんどの IT 部門は契約書上の必要項目を満たしていれば、実際の問題を解決しているかにはあまり関心がなかった
    以前の職場で CrowdStrike に似たソフトウェアが週末の間に私のワークステーションにインストールされ、戻ってみるとコンパイル時間が 20% 遅くなっていた
    当時それを測定していたので数十個の測定値があり、ETL トレースでそのソフトウェアが原因だと示したが、IT は認めなかった。ベンダー契約書では、我々のワークロードでは性能への影響はないことになっていたからだ
  • ほとんどの IT 部門はこれを予見できなかっただろうし、セキュリティ戦略全体をその可能性に合わせて組み立てなかったのも当然だ。この物語がどこから出てくるのか分からない
    Falcon は顧客に現実の、本物のセキュリティ上の利点を提供していたし、今も提供している。だからといってすべてのリスクをなくすわけでも、自らリスクを生まないという意味でもない
    あらゆる工学問題と同じく、文字通りトレードオフのゲームだ。ここにいる人たちにとっても珍しい話ではない
    突然 HN が後知恵と直近事例バイアスに満ちたセキュリティ専門家であふれ、企業がこの弾丸をどう避けられたかを説明しているが、そもそも Falcon を使うことで避けていた実際の弾丸については考慮していない

• これは法廷での証拠映像や訴訟に使われる可能性もあることで、笑い事ではない。
  本来はセキュリティ好き同士が語り合う閉じた場での一幕だったはずなのに、今では大きな被害を受けた一般大衆が好きなだけ嘲笑できる形で公開されてしまった。

  • CrowdStrikeの幹部が状況を軽く見ていたとはまったく思わなかった。むしろあのスピーチは、状況を真剣に受け止め、重大な失敗だったことを認め、そのトロフィーを恥の印であり、将来のCrowdStrike社員への戒めとして受け入れる、というものに見えた。
    その幹部がこの賞を受け取ったのは、本当に品格のある行動だったと思う。もちろん、そう言ったからといって、CrowdStrikeがこの件に関する責任や賠償責任を免れるという意味ではまったくない。
  • Tシャツにしたら面白いかもしれない。
    When I use
    REGEXP
    I use it in my
    KERNEL CODE
    悲劇と喜劇は表裏一体だ。

• xcancel経由: https://xcancel.com/singe/status/1822324795645575263

• コンピューターセキュリティの問題はベトナム戦争の時点ですでに現れており、米国は実際に有効なコンピューターセキュリティモデルを見つけ出す取り組みを行っていた。ところが私たちは、それを事実上記憶から消し去ってしまった社会に生きている。
  なぜコンピューターが実行しようとするあらゆるものの上で、スキャナーが24時間365日動き続けなければならないのか？
  なぜOSは周辺的な権限に依存しなければならないのか？
  CrowdStrikeを責めても、Linux、macOS、WindowsなどのOSにおいて私たちが日々無視している根本的な設計上の失敗から目をそらすだけだ。

• いまだに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を入れたこと自体が大きなミスだと思う。
    ただ、それをやった人は責任を逃れられるとわかっていた可能性が高いので、気にする理由もなかったのだろう。