ゼロデイ攻撃を阻止せよ。防衛ラインを構築する時が来た。

この記事のバージョンは SC Magazineに掲載されました。ここでは修正・再配信されています。


自宅に泥棒が入った経験があれば、何かがおかしいという最初の感覚、そして実際に盗まれ、傷つけられたという認識がそれに続く感覚を理解できるでしょう。これは、フォートノックス並みのセキュリティ対策を導入するまで、しつこい苦情が続くという原則に当てはまります。

想像してみてください。あなたの家に泥棒が侵入しています。彼らは鍵を複製し、自由に動き回り、出入りを繰り返しながら、決して見つからないように注意を払っています。そしてある日、冷凍庫に隠していた宝石が消え、金庫が空になり、私物が荒らされていることに気づくのです。 これが企業にゼロデイ攻撃が仕掛けられた場合の現実です。2020年のポネモン研究所調査によれば、成功したプライバシー侵害の80%がゼロデイエクスプロイトによるもので、残念ながら大半の企業はこの統計を大幅に改善する準備が整っていません。

ゼロデイ攻撃は、定義上、開発者が悪用される可能性のある既存の脆弱性を発見し修正する時間を与えません。なぜなら攻撃者が先に侵入しているからです。被害が発生した後は、ソフトウェア自体にも企業の評判にも甚大な損害が生じます。攻撃者は常に優位に立っており、この優位性を可能な限り埋めることが極めて重要です。

誰も望まなかったクリスマスプレゼント——Log4Shell——が今、インターネットを破壊している。この壊滅的なJavaのセキュリティホールの影響を受けるデバイスは約10億台に上るとされる。史上最悪のゼロデイ攻撃となる兆候が見え始めており、事態は始まったばかりだ。 公開数日前から悪用が始まっていたとの報告もあるが、2016年のブラックハットカンファレンスでの発表から、この問題は以前から認知されていたと推測される。痛ましい。さらに悪いことに、この脆弱性は驚くほど簡単に悪用可能で、世界中のスクリプトキディから脅威アクターまでがこぞってこの穴を狙っている。

では、滑りやすく不気味な脅威から身を守る最善の方法は何か？ましてやソフトウェア開発プロセスで見落とされたセキュリティ上の脆弱性については言うまでもない。さっそく見ていこう。

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

ダークウェブにはエクスプロイトの巨大な市場が存在し、ゼロデイ脆弱性は通常かなりの金額で取引される。本記事執筆時点での一例を挙げれば、250万ドルで出品されていた。 これはApple iOSの脆弱性を利用したエクスプロイトであり、セキュリティ研究者が提示した価格が天井知らずであるのも当然だ。結局のところ、この脆弱性は実際に何百万ものデバイスを侵害し、何十億もの機密データを収集する入り口となり得る。そして、発見され修正されるまでの間、可能な限り長くその状態を維持できるのだ。

しかし、そもそもそんな大金を持っているのは誰なのか？通常、組織化されたサイバー犯罪シンジケートは、特に人気の高いランサムウェア攻撃において、価値があると判断されれば金を支払う。 しかし、世界各国の政府や防衛当局は、脅威情報として活用できるエクスプロイトの顧客であり、好ましいケースでは、企業自身が潜在的なゼロデイエクスプロイトとなり、災害を防ぐ可能性すらある。

2021年にはゼロデイ攻撃の発見件数が過去最高を記録し、最大のリスクに晒されている大規模組織、政府機関、インフラが脆弱性のテスト対象となっています。ゼロデイ攻撃を完全に防ぐ方法はありませんが、手厚く体系化されたバグ報奨金プログラムを提供することで、ある程度「対応策」を講じることが可能です。 闇ウェブ市場で自社ソフトウェア城の鍵を売り渡す前に、正当なセキュリティ愛好家を自社サイトに招き入れ、倫理的な開示と修正の可能性に対して適切な報酬を提供すべきです。

もしゼロデイ脅威が発生した場合、Amazonギフトカードを1枚以上発行する必要があると考えてください（そしてそれは行う価値があります）。

あなたのツールは、あなたの警備員にとって負担となる可能性があります

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

セキュリティ分野は、バーンアウト、需要を満たすセキュリティ専門家の不足、俊敏性の必要性で知られており、セキュリティ専門家がデータ、レポート、監視ツールの洪水の中で作業することを強いることは負担となる。 まさにこの種の状況が、重大な警告を見落とす原因となり得る。Log4jの脆弱性を適切に調査する際に、まさにそのような事態が発生したのである。

予防的安全性は、開発者指向の脅威モデリングを含むべきである

コードレベルのセキュリティ上の脆弱性は開発者によって頻繁に悪用されるため、安全なプログラミング知識を提供するには正確な指示と定期的な学習経路が必要です。次世代のセキュリティ開発者は、ソフトウェア開発プロセスにおいて学習と実践の機会を得なければなりません。
‍
ソフトウェアを最も熟知しているのは、それを構築し開発した開発者であることは驚くべきことではありません。 彼らはユーザーがソフトウェアをどのように扱うか、機能がどこで使用されるかについて深い知識を持ち、十分なセキュリティ意識があれば、ソフトウェアが破損したり悪用されたりする可能性のあるシナリオについても理解しています。

Log4Shellエクスプロイトに話を戻すと、専門家や複雑なツールセットでも発見できなかった壊滅的なセキュリティギャップが存在したシナリオが見えてくる。ただし、ライブラリがユーザー入力をサマライズするように設定されていれば、そもそも発生しなかった可能性がある。 この判断は実用上の理由で採用された難解な機能のように見えたが、結果として悪用を極めて容易にした（SQLインジェクションレベルの単純さであり、決して優れた設計とは言えない）。もし脅威モデリングが熱心でセキュリティ意識の高い開発者グループによって行われていたなら、このシナリオは理論化され実践に移されていた可能性が高い。

優れたセキュリティプログラムには感情的な要素があり、人間が引き起こした問題の解決において、人的介入とニュアンスが中心となる。脅威モデリングは効果を発揮するために共感と経験が必要であり、ソフトウェアやアプリケーションの安全なコーディングと設定も同様に、アーキテクチャレベルで重要である。 開発者は夜を徹して取り組むべきではなく、明確な道筋を示すべきです。この重要な任務をセキュリティチームに委ねられるよう、明確な道筋を確立することが理想的です（そしてこれは両チーム間の関係を構築する絶好の機会となります）。

ヌル日数はN日数につながる

ゼロデイ脆弱性を含むプロセスの次の段階では、パッチを可能な限り迅速に適用し、脆弱なソフトウェアの各ユーザーが、プロバイダーよりも先に、可能な限り迅速に修正することを切望する。 Log4Shellは、その持続性と影響力においてHeartbleedを凌駕する可能性がある。何百万ものデバイスに組み込まれており、ソフトウェアビルド内で複雑な依存関係を生み出すという事実を考慮すればなおさらである。

現実的に見て、この種の秘密裏の攻撃を完全に阻止する方法は存在しません。しかし、高品質で安全なソフトウェアを開発するためにあらゆる手段を尽くすことを約束し、重要インフラを扱うのと同じ考え方で開発に取り組むならば、私たち全員に真のチャンスが訪れる可能性があります。