誰がパッチに脆弱性を入れた？

なぜアップデートだけでは救えないのか

Welcome to the Security Theater

すべてのセキュリティパッチには、守備側と攻撃側の両方にとって特別な意味があります。各「修正」には必ず、元と同じ不完全な素材で作られた新たなコードが忍び込んでくるのです！

さらに悪いことに、これは攻撃者への設計図でもあります。変更はバイナリコードで提供され、振る舞いの変化と同様に diff で比較可能です。リバースエンジニアリングの格好の材料です。

WARNING: Patch may contain today’s fixes (and definitely tomorrow’s vulnerabilities.)

実際は思っているよりも混沌しています。迅速なアップデートについて、ベテランのシステム管理者に聞けば必ず得た教訓が返ってきます。「半年待て。彼らの無料ベータテスターになるな」。

ITチームのジレンマを一度整理してみましょう。

今すぐパッチを当てる：本番環境が壊れるリスク。
後でパッチを当てる：侵害されるリスク。
パッチを当てられない（当てたくない）：侵害される深刻なリスク。
防御・緩和策を講じる：システムをハードニング、弱い暗号を排除、パスワード変更など。そんな作業に時間があるか？！ CVE を読むか？ああ、甘い子供たちよ、残念なニュースがある…

パッチはシステムを壊すこともあります――攻撃者は不要です。

2024年7月の CrowdStrike インシデントは厳しい真実を示しました。「ベストプラクティス」に従っても、未テストのコードが重要インフラをクラッシュさせると免疫は得られません。数時間以内に、航空機は世界中で離陸が停止し、病院はほぼ麻痺状態に陥りました。

しかし、パッチを無視するということは、既知の脆弱性が悪用されることを保証するようなものです。

セキュリティに金銭を投じても、裏目に出ることが多い。複雑で層状のコントロールは管理が不可能になり、監視も不可能になる。

適切な投資額は？最適なコントロールは？完璧なセキュリティ‑使いやすさのバランスは？

それは状況次第です。（はい、コンサルタントのお決まりの答えです。）

しかし、実はそれが朗報です。個別のリスク管理は、画一的なアプローチを常に上回ります。

演劇的な見せかけをやめ、能動的なリスク管理に移行せよ。

重要項目をすべて特定し、文書化すること：

普遍的なベストプラクティスはあるか？ある。実装は組織により異なるが：

重要な検討事項

すべてのユーザーに YubiKey などのハードウェアセキュリティキーを導入するか、最低でもパスキーを義務付ける。
- OTP はソーシャルエンジニアリングに弱いが、ハードウェアトークンはそのリスクが低い。
- すべてのサービスで MFA を必須とする。
堅牢かつ検証済みのバックアップ。
- クラウドインフラはオフラインバックアップを確保する――理想は不変で地理的に分散させたもの。
  - 「オフライン」とはベンダー間またはアカウント間でのバックアップを指す（例：AWS のバックアップを GCP や Azure に保存、あるいは Backblaze B2 などのサードパーティーソリューション）。
- 従業員デバイスにもバックアップ戦略を拡張し、会議室の不安定な Wi‑Fi など回復シナリオを考慮する（SLA と復旧目標に合わせる）。
四半期ごとにリカバリードリルを実施する：未使用のリージョンでバックアップ、スナップショット、IaC ツールを用いてインフラ全体を復元する。
任意の実際の認証情報の横に CanaryTokens を配置し、侵害が始まった瞬間をいち早く検知できるようにする。

自組織のリスクプロファイルを把握せよ：保護すべきデータは何か？脅威はどれが重要か？許容できるダウンタイムはどれだけか？復旧と再構築、どちらがコストが低いか？

実際の露出を検討する：

魅力のない真実：セキュリティは層で構成され、銀の弾丸は存在しない。防御の深さ、オフラインバックアップ、災害ドリル、代替コントロールを組み合わせること。パッチは必要悪であり、万能な解決策ではない。