未修补的攻撃が増加傾向にある。防御優位性を計画する時が来た。

この記事のバージョンは SC誌。こちらでは改訂・共同掲載されています。


もしあなたの家に泥棒が入った経験があれば、最初に「何かおかしい」と感じ、やがて実際に盗難や侵害に遭ったと気づくあの沈み込むような感覚を理解できるでしょう。これは通常、持続的な不快感をもたらし、言うまでもなくノックスバーグに匹敵するほどのセキュリティ対策へと向かわせます。

今、あなたの家に泥棒が侵入したと想像してみてください。彼らは自分で鍵を作り、自由に動き回っています。しかし、見つからないよう慎重に行動しています。ある日、冷蔵庫に隠していた宝石が消え、金庫が空になり、私物が荒らされていることに気づきます。手遅れだった。これは組織がゼロデイ攻撃の被害者となった際に直面する現実と全く同じです。2020年のポネモン研究所の調査によれば、成功したデータ漏洩の80%は修正されていない脆弱性の悪用によるものでした。残念ながら、ほとんどの企業は依然としてこの統計を大幅に改善する能力を持っていません。

その名の通り、ゼロデイ攻撃では脅威行為者が先に侵入するため、開発者は悪用される可能性のある既存の脆弱性を発見・修正する時間がありません。被害が発生した後は、ソフトウェアの修復と企業の評判回復に必死で追われることになります。攻撃者は常に優位に立っており、この優位性を可能な限り縮小することが極めて重要です。

誰も欲しくないクリスマスプレゼント——Log4Shell——が今まさにインターネットを破壊中だ。この壊滅的なJava脆弱性の影響を受けるデバイスは10億台を超えると言われている。これは記録上最も深刻なゼロデイ攻撃となるだろうが、まだ始まったばかりだ。一部の報道によれば、脆弱性の悪用は公開の数日前から始まっていたが、2016年のブラックハットカンファレンスでの発表によれば、これは以前から知られていた問題だった。おっと。さらに悪いことに、この脆弱性は悪用が容易であり、地球上のあらゆるスクリプト少年や脅威アクターが利益を求めてこの脆弱性を狙っている。

では、滑稽でありながら危険な脅威、ましてやソフトウェア開発プロセスで見落とされた脆弱性に対抗する最善の道筋とは何でしょうか？見ていきましょう。

大規模な標的に対するゼロデイ攻撃は稀であり（しかもコストが高い）

ダークウェブ上の脆弱性利用市場は巨大であり、ゼロデイ脆弱性はしばしば高額で取引される。一例を挙げると、本稿執筆時点で公開価格は250万ドルに達している。これはApple iOSの脆弱性であると報じられており、セキュリティ研究者の要求価格が高止まりしているのも不思議ではない。何しろ、これは数百万台のデバイスへの侵入、数十億件の機密データ収集、そして発見・修正されるまでの最大限の攻撃継続を可能にする入口となり得るからだ。

しかし、いずれにせよ、そんな大金を出せる者などいるだろうか？通常、現金が価値あるものと見なされる場合、組織化されたサイバー犯罪グループは現金を要求する。特に人気のあるランサムウェア攻撃ではそうだ。しかし、世界中の政府や国防部門は、脅威インテリジェンスに利用できる脆弱性の顧客層であり、より積極的なケースでは、これらの組織自体が潜在的な未修正の脆弱性を自ら購入し、災害を軽減しようとする可能性がある。

2021年はリアルタイム未修正脆弱性の発見において記録を塗り替え、大規模組織・政府機関・重要インフラが最も脆弱性の調査対象となりやすい。ゼロデイ攻撃の可能性を完全に排除する方法は存在しないが、寛大かつ体系的な脆弱性報奨金プログラムを提供することで 「ゲームに参加する」ことが可能です。闇市場でソフトウェアの城の鍵が売り出されるのを待つよりも、合法的なセキュリティ愛好家を味方につけ、倫理的な開示と潜在的な修正に対して手厚い報酬を提供すべきです。

しかも、もしそれがたまたま背筋が凍るような新たな脆弱性の脅威であるなら、間違いなく言えるのは、あなたが必要とするのはAmazonギフトカードだけではないということだ（そして、そうする価値は十分にある）。

あなたのツールは、おそらくあなたのセキュリティ担当者の責任です

煩雑なセキュリティツールは長年の課題であり、一般的な最高情報セキュリティ責任者（CISO）は、自社のセキュリティツール群において55から75個ものツールを管理している。世界で最も混乱を招く（比喩的に）スイスアーミーナイフであることに加え、53％の企業は自社の効率性すら把握できていないと、ポネモン研究所による調査が明らかにした。別の調査では、自社のセキュリティスタックが「完全に有効」だと考えるCISOはわずか17％に過ぎないことが明らかになった。

疲労困憊し、安全スキル不足の要員で需要を満たし、柔軟性が求められることで知られる分野において、セキュリティ専門家がデータやレポート、大規模なツールセットの監視といった形で情報過多に対処することを強いるのは重荷である。まさにこれが、Log4jの脆弱性を適切に評価する際に、彼らが重要な警告を見逃す可能性のある状況だ。

予防的安全対策には開発者主導の脅威モデリングを含めるべきである

コードレベルの脆弱性は通常、開発者によって導入されます。彼らは安全なコーディングスキルを育成するために、正確なガイダンスと定期的な学習経路を必要とします。しかし、ソフトウェア作成プロセスの一部として、次のレベルのセキュリティ開発者は脅威モデリングを学び実践する機会を得ます。

ソフトウェアを最もよく理解しているのは、実際にそれを構築している開発者であることは驚くべきことではない。彼らは、ユーザーがどのようにソフトウェアと対話するか、どこで機能を使用するか、いつ十分なセキュリティ意識を持っているか、そしてそれが破壊されたり悪用されたりする可能性のあるシナリオについて豊富な知識を持っている。

この問題をLog4Shell脆弱性に当てはめると、残念ながら専門家や複雑なツールセットの検出をすり抜けた壊滅的な脆弱性が存在したことがわかります。しかし、ライブラリがユーザー入力を消毒するよう設定されていれば、そもそも発生しなかった可能性があります。利便性を高めるためにこの設定を拒否する決定は、一見些細な機能のように思えますが、非常に悪用されやすいものです（SQLインジェクションレベルの脆弱性を考えてみてください。天才的な手法ではありません）。鋭敏でセキュリティに精通した開発者チームによって脅威モデリングが行われていれば、このシナリオは理論上考慮されていたでしょう。

優れたセキュリティ計画には感情的な要素が含まれており、人的介入と微妙な差異こそが人的課題解決の核心である。脅威モデリングを効果的に行うには共感と経験が必要であり、ソフトウェアやアプリケーションアーキテクチャ層における安全なコーディングと設定も同様だ。これは開発者が一夜にして陥るべき難題ではないが、彼らのスキルを向上させ、セキュリティチームがこの重要な任務を遂行する負担を軽減できる明確な道筋である。これは理想的な方法であり（両チームの良好な関係を築く上でも有効な手段だ）。

ゼロデイが n 日を引き起こす

未修正の脆弱性に対処する次の段階は、パッチをできるだけ早くリリースすることです。彼は、攻撃者が先に到達する前に、脆弱なソフトウェアの全ユーザーが速やかにパッチを適用することを強く望んでいます。Log4Shellの場合、その持続性と有効性は非常に高く、何百万ものデバイスに組み込まれ、ソフトウェアのバージョン全体に複雑な依存関係を生み出すため、Heartbleedを凌駕する可能性さえあります。

実際には、この陰険な攻撃を完全に阻止する方法はありません。しかし、あらゆる手段を用いて高品質で安全なソフトウェアを作成し、重要インフラと同等の意識で開発に取り組むことを約束する限り、私たち全員にこれに対抗する機会があります。