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

この記事のバージョンは Revista SCに掲載されました。改訂の上、こちらで公開しています。


もしあなたの家が泥棒に襲われたことがあるなら、何かがおかしいという最初の沈み込むような感覚、そして実際に盗まれ、侵害されたことに気づく感覚を理解できるでしょう。通常、これは持続的な不安につながり、言うまでもなくフォートノックス級のセキュリティ対策の導入を招きます。

さて、あなたの家が泥棒に侵入されたと想像してください。彼らは鍵を偽造し、自由に動き回りながら、気づかれないよう慎重に行動しています。ある日、冷凍庫に隠した宝石が消え、金庫が空になり、私物が荒らされていることに気づくのです。 これが、組織がゼロデイ攻撃の被害に遭った場合に直面する現実です。2020年のポネモン研究所の調査によると、成功したデータ漏洩の80%はゼロデイエクスプロイトが原因であり、残念ながら、ほとんどの企業はこの統計を大幅に改善する準備が依然として不十分です。

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

誰も望んでいなかったクリスマスプレゼント、Log4Shellが現在インターネットを爆発させている。この壊滅的なJavaの脆弱性により、10億台以上のデバイスが影響を受けていると言われている。これは単一日に記録された最悪の攻撃となりつつあり、まだ始まったばかりだ。公開数日前に悪用が始まったとする報告もあるが、2016年のブラックハットカンファレンスでの発表によれば、この問題は以前から認知されていたようだ。ああ。さらに悪いことに、この脆弱性は驚くほど簡単に悪用可能であり、世界中のスクリプターや脅威アクターが金銭目的で狙っている。

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

ゼロデイ攻撃が重要な標的に向けられることは稀である（かつ費用がかかる）

ダークウェブには膨大なエクスプロイト市場が存在し、ゼロデイ脆弱性は通常、法外な金額で取引される。例えば本記事執筆時点で、あるゼロデイは250万ドルで取引されていた。 これはAppleのiOSシステムの脆弱性であると言われており、セキュリティ研究者が高値を付けているのも不思議ではない。何しろ、これが何百万ものデバイスを侵害し、何十億もの機密データ記録を収集するための入り口となり得るからだ。そして、発見され修正されるまでの間、可能な限り長く悪用し続けることができる。

しかし、そもそもそんな大金を用意できる者などいるのだろうか？通常、組織化されたサイバー犯罪シンジケートは、特に人気が高まっているランサムウェア攻撃において、価値があると判断した場合は金銭を要求する。 しかし、世界中の政府や国防機関は、脅威に関する情報を得るために悪用できるエクスプロイトの顧客層に含まれる。より前向きなシナリオでは、企業自身が災害を軽減するために、自社の潜在的なゼロデイ脆弱性を購入することさえある。

2021年にはゼロデイ攻撃をリアルタイムで発見する記録が更新され、大規模組織、政府機関、インフラが脆弱性調査の最大の標的となっています。 ゼロデイ攻撃の可能性から完全に身を守る方法はありませんが、寛大で体系的なバグ報奨金プログラムを提供することで、ある程度「対応策」を講じることが可能です。ダークウェブの闇市場で誰かがソフトウェア城の鍵を売り渡すのを待つ代わりに、正当なセキュリティ強化策を求め、倫理的な開示と潜在的な解決策に対して適切な報奨金を提示しましょう。

もしそれが恐ろしいゼロデイ脅威であることが判明した場合、間違いなくAmazonギフトカード以上の出費が必要になるだろう（そしてそれはそれだけの価値がある）。

それらのツールは、御社のセキュリティ担当者の責任となる可能性があります

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

セキュリティ分野では人材不足が深刻化しており、需要を満たす十分なスキルを持つ人材が不足している上、迅速な対応が求められる状況下では、セキュリティ専門家が膨大なデータ、レポート、監視ツール群といった情報過多に直面せざるを得ない。これは大きな負担となっている。 まさにこのような状況が、重大な警告を見逃す原因となり得る。Log4jの脆弱性を適切に評価する際に、まさにそのような事態が生じた可能性が高い。

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

開発者はコードレベルで脆弱性を導入しがちであり、安全なコーディングスキルを習得するには正確なガイダンスと定期的な学習経路が必要です。しかし、高度なセキュアシステムの開発者は、ソフトウェア構築プロセスの一環として脅威モデリングを学び実践する機会を得ています。
‍
ソフトウェアを最も熟知しているのは、実際に開発に携わった開発者であることは驚くべきことではありません。 彼らはユーザーがソフトウェアとどのようにやり取りするか、機能がどこで使用されるか、そしてセキュリティに対する十分な意識があれば、ソフトウェアが失敗したり悪用されたりする可能性のあるシナリオについて深い知識を持っています。

Log4Shellの脆弱性について再び言及すると、残念ながら専門家や複雑なツール群でさえこの壊滅的な脆弱性を検出できなかった状況に直面しています。しかし、ライブラリがユーザー入力のデシネクション（消毒）を行うように設定されていれば、そもそも発生しなかった可能性があります。 この設定を回避する判断は、利便性を優先したあまり知られていない特性として存在したようですが、結果として極めて容易に悪用される（SQLインジェクションレベルの脆弱性であり、決して優れた設計とは言えません）状態を生みました。もし脅威モデリングが熱心な開発者とセキュリティ専門家グループによって行われていたならば、このシナリオは理論的に予測され検討されていた可能性が高いでしょう。

優れたセキュリティプログラムには感情的な要素があり、人為的な問題の解決には人間の介入とニュアンスが不可欠です。脅威のモデリングには共感と経験が効果的に作用し、ソフトウェアやアプリケーションのアーキテクチャレベルでの安全なコーディングや設定も同様です。 開発者が一夜にして取り組むべき課題ではありませんが、理想はスキルを向上させる明確な道筋を見出し、セキュリティチームの負担を軽減できるレベルに到達することです（これは両チーム間の良好な関係を築く優れた方法でもあります）。

ゼロ日目はn日目に繋がる

ゼロデイ攻撃に対処する次の段階は、パッチを可能な限り迅速にリリースすることです。これにより、脆弱なソフトウェアの全ユーザーが攻撃者が先手を打つ前に、そして何よりも早急にパッチを適用することを期待します。Log4Shellの場合、何百万ものデバイスに組み込まれており、ソフトウェアのコンパイルに複雑な依存関係を生み出すという事実から、その持続性と影響力はHeartbleedを凌駕する可能性があります。

現実的に考えて、この種の陰険な攻撃を完全に阻止する方法はありません。しかし、安全で高品質なソフトウェアを構築するためにあらゆる手段を尽くすこと、そして重要インフラと同様の意識で開発に取り組むことを約束すれば、私たち全員に戦う可能性は残されています。