パッチに脆弱性が混入？

なぜアップデートはあなたを救えないのか

セキュリティ劇場へようこそ

すべてのセキュリティパッチには、防御側と攻撃側の両方にとって特別な何かがあります。「修正」のたびに、 inevitably、より多くのコードが追加されます——それも元のコードと同じく不完全な材料から作られたものです！

さらに悪いことに、それは攻撃者にとっての設計図です！変更は、行動変化と同じくらい簡単に差分解析できるバイナリコードで構成されています。リバースエンジニアリングの格好の餌食です。

警告: パッチには今日の修正（そして明日の脆弱性）が含まれている可能性があります。

現実は私が望むものよりずっと複雑です。迅速なアップデートについてベテランのシステム管理者に尋ねれば、苦労して得た知恵が返ってくるでしょう：「6ヶ月待て。無料のベータテスターになるな。」

ITチームのジレンマを少し考えてみましょう：

パッチもまたシステムを殺します——攻撃者なしで。

2024年7月のCrowdStrike事件は、テストされていないコードが重要インフラをクラッシュさせた場合、「ベストプラクティス」に従っても免疫がないという厳しい真実を証明しました。数時間以内に、世界中で飛行機が grounded になり、病院はほぼ麻痺状態に陥りました。

しかし、パッチを無視する？それは既知の脆弱性の悪用を保証するものです。

セキュリティにお金を注ぎ込むだけでは逆効果になることが多いです。複雑で多層化されたコントロールは管理不可能になり——監視も不可能になります。

適切な投資レベルは？最適なコントロールは？完璧なセキュリティとユーザビリティのバランスは？

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

しかし、それは実際には良いニュースです：パーソナライズされたリスク管理は、画一的なアプローチを常に凌駕します。

劇場を止めて、積極的なリスク管理を始めましょう。

重要なすべてを決定し、文書化しましょう：

普遍的なベストプラクティスはありますか？はい、ただし実装は異なります：

主要な考慮事項

YubiKeysのようなハードウェアセキュリティキーを全ユーザーに導入するか、最低でもパスキーを義務化する。
- OTPはソーシャルエンジニアリングの影響を受けやすいが、ハードウェアトークンは影響を受けにくい。
- すべてのサービスでMFAを普遍的に要求する。
堅牢で検証済みのバックアップ。
- クラウドインフラにオフラインバックアップがあることを確認する——理想的には不変で地理的に分散されたもの。
  - 「オフライン」とは、クロスベンダーまたはクロスアカウントを意味する（例：GCPやAzureにAWSバックアップを保存、またはBackblaze B2などのサードパーティソリューション）。
- 従業員のデバイスにもバックアップ戦略を拡張し、信頼性の低い会議用Wi-Fiなどの復旧シナリオを考慮する（SLAと復旧目標に合わせる）。
四半期ごとの復旧ドリルを実施する：バックアップ、スナップショット、インフラストラクチャ-as-コードツールを使用して、未使用のリージョンでインフラ全体を復元する。
実際の資格情報と一緒にCanaryTokensを配置し、侵害が始まったときに最初に気づくようにする。

リスクプロファイルを理解する：どのようなデータを保護しているか？どの脅威が重要か？どの程度のダウンタイムが許容できるか？復旧と再構築、どちらが安いか？

実際の暴露度を考慮する：

見栄えのしない真実：セキュリティは銀の弾丸ではなく、層です。多層防御、オフラインバックアップ、災害ドリル、補償コントロール。パッチは万能薬ではなく、必要な悪として扱いましょう。