ゼロデイ攻撃は増加の一途をたどっています。今こそ、防御の要を固める計画を立てるべき時です。

本記事の一部は SC Magazine に掲載されたものです。本稿では改変・転載しています。


自宅に泥棒が入った経験があるなら、何かがおかしいという最初の嫌な予感と、実際に盗難に遭い、プライバシーを侵害されたという現実を突きつけられた時の感覚がわかるはずです。それは通常、長く続く不快感をもたらすだけでなく、フォートノックス（米国陸軍の金塊保管所）並みのセキュリティ対策を講じるきっかけにもなります。

では、泥棒が合鍵を作って家に侵入したと想像してみてください。彼らは気づかれないように注意しながら、自由に出入りを繰り返します。そしてある日、冷凍庫に隠しておいた宝石が消え、金庫は空になり、私物が荒らされていることに気づくのです。これこそが、組織がゼロデイ攻撃の被害に遭った際に直面する現実です。2020年のポネモン研究所の調査によると、データ侵害の80%がゼロデイ攻撃によるものでした。悲しいことに、ほとんどの企業は、この統計を大幅に改善するための備えができていません。

ゼロデイ攻撃とは、定義上、開発者が悪用され得る既存の脆弱性を発見して修正する時間を一切与えない攻撃です。脅威アクターが先手を打つためです。被害が発生した後に、ソフトウェアの修正とビジネス上の評判の回復という、大混乱の中での対応を強いられることになります。攻撃者は常に優位な立場にあり、その差を可能な限り縮めることが極めて重要です。

誰も望んでいなかったホリデーギフト「Log4Shell」が、現在インターネット上で猛威を振るっています。この壊滅的なJavaの脆弱性により、10億台以上のデバイスが影響を受けていると言われています。これは史上最悪のゼロデイ攻撃になりつつあり、まだ始まったばかりです。公開の数日前から悪用が始まっていたという一部の報告がある一方で、2016年のBlack Hatカンファレンスでの発表は、これが以前から知られていた問題であることを示唆しています。痛いですね。さらに悪いことに、悪用が非常に容易であるため、世界中のスクリプトキディや脅威アクターがこの脆弱性で一攫千金を狙っています。

では、このような狡猾で恐ろしい脅威や、ソフトウェア開発プロセスで見落とされた脆弱性に対して、どのような防御策が最善なのでしょうか。詳しく見ていきましょう。

大規模な標的を狙ったゼロデイ攻撃は稀（かつ高コスト）

ダークウェブには巨大なエクスプロイト市場が存在し、ゼロデイ脆弱性はかなりの高値で取引される傾向があります。執筆時点で、本記事で紹介されている一例は250万ドルで出品されていました。Apple iOSの脆弱性であると報告されており、セキュリティ研究者がこれほどの高値を要求するのも驚きではありません。結局のところ、これは数百万台のデバイスを侵害し、数十億件もの機密データを収集し、発見されて修正されるまで可能な限り長く悪用し続けるための入り口になり得るからです。

しかし、一体誰がそんな大金を持っているのでしょうか。通常、組織化されたサイバー犯罪シンジケートは、特に人気のあるランサムウェア攻撃のために、価値があると判断すれば資金を捻出します。しかし、世界各国の政府や国防省も、脅威インテリジェンスのために利用できるエクスプロイトの顧客となっており、より前向きなシナリオでは、企業自身が災害を未然に防ぐために、自社の製品に対するゼロデイ脆弱性を買い取ることもあります。

2021 saw records broken for live zero-day exploit discoveries, and it is large organizations, government departments, and infrastructure that are most at risk of being probed for any weaknesses. There is no way to be completely safe from the possibility of a zero-day attack, but you can “play the game” somewhat by offering a generous and well-structured bug bounty program. Rather than wait until someone offers the keys to your software castle on a dark web marketplace, get legit security buffs on your side and offer them decent rewards for ethical disclosure and potential fixes. 

もしそれが背筋の凍るようなゼロデイの脅威であれば、Amazonギフトカード以上の報酬を用意する必要があるでしょう（そして、それだけの価値は十分にあります）。

ツールがセキュリティ担当者の足かせになっている可能性

扱いにくいセキュリティツールは長年の課題であり、平均的なCISOは55から75ものツールをセキュリティ対策に導入しています。ポネモン研究所の調査によると、世界で最も混乱を招く（比喩的な）十徳ナイフであるだけでなく、企業の53%は、それらが効果的に機能していると確信すら持てていません。また別の調査では、自身のセキュリティスタックが「完全に効果的」だと考えているCISOはわずか17%でした。

燃え尽き症候群、需要を満たすセキュリティスキルの不足、そして俊敏性が求められるこの分野において、セキュリティ専門家に膨大なデータ、レポート、ツールセットの監視という情報の過負荷を強いることは大きな負担です。これこそが、重要なアラートを見逃す原因となるシナリオであり、Log4jの脆弱性を適切に評価する際にも、まさに同じことが起きていた可能性があります。

予防的セキュリティには、開発者主導の脅威モデリングを含めるべき

コードレベルの脆弱性は開発者によって作り込まれることが多く、セキュアなコーディングスキルを構築するためには、的確なガイダンスと継続的な学習経路が必要です。しかし、一歩進んだセキュアな開発者は、ソフトウェア作成プロセスの一環として脅威モデリングを学び、実践する機会を与えられています。
‍
ソフトウェアを最もよく知っているのは、実際にそれを作成した開発者であることは言うまでもありません。彼らは、ユーザーがどのように操作するか、どの機能がどこで使われているか、そしてセキュリティ意識が高ければ、どこで問題が発生したり悪用されたりする可能性があるかという強力な知識を持っています。

Log4Shellの脆弱性に話を戻すと、残念ながら、専門家や複雑なツールセットによる検知をすり抜けた壊滅的な脆弱性のシナリオを目の当たりにしています。しかし、もしライブラリがユーザー入力をサニタイズするように構成されていれば、このような事態は発生しなかったかもしれません。サニタイズを行わないという決定は、利便性を高めるための隠れた機能だったようですが、結果として悪用を非常に容易にしてしまいました（SQLインジェクションレベルの、決して天才的な手法ではありません）。もし熱心でセキュリティに精通した開発者グループによって脅威モデリングが行われていれば、このシナリオは予測され、検討されていた可能性が高いでしょう。

優れたセキュリティプログラムには感情的な要素があり、人間が作り出した問題を解決する中心には、人間の介入とニュアンスが存在します。脅威モデリングを効果的に行うには、共感と経験が必要です。ソフトウェアやアプリケーションのアーキテクチャレベルでのセキュアなコーディングや構成も同様です。これは開発者に突然丸投げしてよいものではありませんが、セキュリティチームの負担を軽減できるレベルまでスキルアップさせる明確な道筋を作ることは理想的です（そして、両チーム間の信頼関係を築く素晴らしい方法でもあります）。

ゼロデイはNデイにつながる

ゼロデイ攻撃への次の対応策は、可能な限り迅速にパッチをリリースすることです。脆弱性のあるソフトウェアを使用しているすべてのユーザーが、攻撃者に先を越される前に、一刻も早くパッチを適用してくれることを切に願うしかありません。Log4Shellは、Heartbleedを凌駕する可能性があります。数百万ものデバイスに組み込まれ、ソフトウェア構築全体に複雑な依存関係を生じさせているため、その影響は長期にわたり、極めて強力です。

現実的に、この種の巧妙な攻撃を完全に阻止する方法はありません。しかし、高品質で安全なソフトウェアを構築するためにあらゆる手段を尽くし、重要インフラを扱うのと同じ心構えで開発に取り組むことで、私たちは皆、対抗するチャンスを得ることができます。