ゼロデイ攻撃が増加しています。防御上の優位性を計画する時が来ました。

本記事の一部は Revue SCに掲載されました。改訂の上、こちらで公開しています。


もしあなたの家に泥棒が入った経験があるなら、何かがおかしいという最初の感覚、そして実際に盗まれ、侵害されたという認識がそれに続く気持ちを理解できるでしょう。これは通常、持続的な不快感をもたらし、フォートノックス並みのセキュリティ対策に移行する必要性は言うまでもありません。

さて、あなたの家が泥棒に侵入されたと想像してください。彼らは鍵を複製して侵入し、自由に行き来しながらも、気づかれないよう細心の注意を払っています。ある日、冷凍庫に隠していた宝石が消え、金庫が空になり、私物が荒らされていることに気づくのです。 これは組織が「ゼロデイ攻撃」の被害に遭った場合に直面する現実と同じです。2020年のポネモン研究所の調査によると、成功したデータ侵害の80％はゼロデイ攻撃によるものでした。残念ながら、ほとんどの企業は依然としてこの統計を大幅に改善する態勢が整っていません。

定義上、「ゼロデイ攻撃」は、開発者が悪用される可能性のある既存の脆弱性を検知し修正する時間を与えません。なぜなら脅威の作者が最初に介入したからです。 被害は既に発生しており、ソフトウェアの修復と企業評判の回復に向けた激しい競争が始まる。攻撃者は常に優位に立っており、この優位性を可能な限り縮小することが極めて重要である。

誰も望まなかったクリスマスプレゼント、Log4Shellが現在インターネットを爆発させている。10億台以上のデバイスがこのJavaの壊滅的脆弱性の影響を受けると見られている。史上最悪のゼロデイ攻撃となる可能性が高く、これはまだ始まりに過ぎない。一部の報告では公開数日前から悪用が始まっていたとされるが、2016年のブラックハットカンファレンスでの発表によれば、この問題は以前から認知されていたようだ。痛い。さらに悪いことに、この脆弱性は極めて悪用しやすく、世界中のスクリプターや脅威アクターがこぞってこの穴を狙っている。

では、ソフトウェア開発プロセスで検出されなかった脆弱性は言うまでもなく、不気味で巧妙な脅威から身を守る最善の道筋とは一体何でしょうか？ 早速見ていきましょう。

大規模な標的に対する「ゼロデイ攻撃」は稀（かつ高コスト）である

ダークウェブにはエクスプロイトの巨大な市場が存在し、ゼロデイ脆弱性は高額で取引される傾向にある。本記事で例示した事例では、執筆時点で250万ドルの値が付けられていた。 Apple iOSの脆弱性として報告されたこのエクスプロイトに対し、セキュリティ研究者が法外な価格を要求しているのも不思議ではない。何しろ、この脆弱性は数百万台のデバイスを侵害し、数十億件の機密データを収集するゲートウェイとなり得る。しかも、発見・修正されるまでの間、可能な限り長期にわたり悪用を継続できる可能性があるのだ。

しかし、そもそもそんな大金を持っている者などいるのか？一般的に、組織化されたサイバー犯罪者グループは、特にますます流行しているランサムウェア攻撃のために、必要と判断すれば資金を調達する。 しかし、世界の政府や国防総省も顧客の一角を占めており、脅威情報収集の目的で悪用可能なエクスプロイトを購入している。より前向きなシナリオでは、企業自体が潜在的なゼロデイエクスプロイトを買い取り、災害を軽減できるようにしている。

2021年はリアルタイムでのゼロデイ脆弱性発見が過去最高を記録し、大規模組織、政府機関、インフラが潜在的な弱点を検出されるリスクが最も高まっています。 ゼロデイ攻撃から完全に身を守る方法はありませんが、寛大で体系的なバグ報奨金プログラムを提供することで、ある程度「ゲームに参加」することは可能です。 ダークウェブ市場で誰かがソフトウェア城の鍵を売り渡すのを待つよりも、正当なセキュリティ専門家を招き、倫理的な開示と修正案に対して適切な報酬を提供すべきです。

もしこれが驚くべきゼロデイ脅威であることが判明した場合、Amazonギフトカード以上のものが必要になるでしょう（そしてそれはその価値があるはずです）。

御社の設備は、御社の警備員にとって障害となる可能性があります

セキュリティツールの煩雑さは長年の課題であり、平均的なCISOはセキュリティ対策として55～75のツールを管理している。これは世界一混乱した（比喩的な）スイスアーミーナイフであることに加え、ポネモン研究所の調査によれば、53％の企業が自社の対策が効果的であることすら確信していない。別の調査では、セキュリティソリューションが「完全に効果的」だと考えるCISOはわずか17％に過ぎないことが明らかになった。

過労が蔓延し、需要に応えるための有資格セキュリティ人材が不足し、機敏性が求められる分野において、セキュリティ専門家に対し、データやレポート、膨大なツール群の監視といった情報過多の状態で作業を強いることは、煩わしい作業である。 まさにこの種の状況が、重大な警告を見逃す原因となり得る。Log4jの脆弱性を適切に評価できなかった事例も、その一例かもしれない。

予防的安全対策には、開発者主導の脅威モデリングを含める必要がある

コードレベルの脆弱性は、開発者によって導入されることが多く、安全なコーディングスキルを習得するには具体的なガイダンスと継続的な学習経路が必要です。しかし、上級レベルのセキュア開発者は、ソフトウェア開発プロセスにおいて脅威モデリングを学び実践する機会を得ています。

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

これをLog4Shellの脆弱性に当てはめると、専門家や複雑なツール群による検知を逃れた壊滅的な脆弱性が残念ながら発生したシナリオが見て取れます。しかし、ライブラリがユーザー入力のサニタイズを行うように設定されていれば、そもそも発生しなかった可能性があります。 この設定を省略した判断は、利便性のために採用された不明瞭な機能のように見えますが、結果として脆弱性を極めて容易に悪用可能にしてしまいました（SQLインジェクションレベルの脆弱性を想像してみてください。決して優れた設計とは言えません）。もし脅威モデルが、セキュリティに精通した情熱的な開発者グループによって構築されていたならば、このシナリオは理論化され、想定されていた可能性が高いでしょう。

優れたセキュリティプログラムには感情的な要素が含まれており、人間による介入とニュアンスが人為的問題の解決の核心となる。脅威のモデリングは、ソフトウェアやアプリケーションのアーキテクチャレベルでの安全なコーディングや設定と同様に、効果を発揮するには共感と経験が必要である。 開発者がこの課題に突然直面すべきではありませんが、理想は明確な改善経路を見出し、セキュリティチームがこの重要な業務で抱える負担を軽減できるレベルまで開発者のスキルを向上させることです（これは両チーム間の関係構築にも極めて有効な手段となります）。

ゼロ日目からn日目へ

ゼロデイ攻撃に対処する次のステップは、修正プログラムを可能な限り迅速に公開し、脆弱なソフトウェアの全ユーザーが攻撃者が先んじる前に、確実に、そして可能な限り速やかにそれらを適用することを期待することである。 Log4Shellの場合、何百万ものデバイスへの組み込みやソフトウェア設計内の複雑な依存関係の構築により、その持続性と影響力はHeartbleedを凌駕する可能性がある。

実際には、この種の陰湿な攻撃を完全に阻止する手段は存在しません。しかし、あらゆる手段を尽くして安全で高品質なソフトウェアを創り出すことに取り組み、その開発を重要インフラと同様の意識で臨むならば、私たち全員に成功のチャンスはあります。