ゼロデイという状況に陥ったとき：準備がなければ何もできない？

What Does it Mean to Be Zero-Day?

2022/03/29 SecurityBoulevard — ゼロデイ脆弱性とは、コンピュータ・ソフトウェアの未知の脆弱性のことであり、その存在にセキュリティ・チームが気付く前に、ステルス・モードでの攻撃を可能にするものである。 ゼロデイとは、ソフトウェアの欠陥が発生してから、修正プログラムが提供されるまでの期間を指す、不定形な概念である。それにより、リスクに満ちたユニークなセキュリティ態勢の状況が生み出される。

ゼロデイには、それぞれ固有のストーリーがあり、すべてのゼロデイが壊滅的な影響を与えるわけではない。ゼロデイ攻撃の規模は、組織の業種や規模などの、多くの要因に左右される。知的財産 (IP) や銀行情報などの、貴重なビジネスデータや財務データを保管している組織は、攻撃者にとって魅力的な選択肢となる。

アプリケーション・セキュリティに属する欠陥の多くは、ゼロデイ脆弱性と考えるられるが、それらはアプリケーションに特有のものであることが多いため、一般的な脆弱性データベースで追跡されることはあり得ない。

その好例が、一般的な Web アプリケーションの欠陥であるクロス・サイト・スクリプティング (XSS) である。この欠陥は、HTML テクノロジーの基本的な弱点に起因しており、検出／修正するためには、開発者の高い意識が必要となる。XSS はクライアント・サイドの攻撃である。つまり、攻撃を成功させるためには、Web ブラウザを介して被害者が悪意のペイロードを読み込む (リンク・クリック／Web ページ・アクセス) する必要がある。続いて、このペイロードは、XSS に脆弱なサイト上で、被害者の名前で攻撃者のアクションを実行することになる。

意欲的な悪意ある行為者が XSS を実施するための完全なキャンペーンを組織し、攻撃フレームワークと武器となるエクス・プロイトを構築し、可能な限り多くの被害者をターゲットとして、悪意のペイロードを広く配信することが、この種の攻撃に内在する脅威となる。この脅威は、すべてのビジネスに関連するものではないが、IT 業界としては XSS の影響度を様々なレベルでマークしている。

オンライン・バンキングや決済システムなどを有する金融業界の組織は、その影響度の高さから、このような攻撃ベクターの有利なターゲットとなる。Payment Card Industry (PCI) コンプライアンスとは、カード所有者から提供され、カード処理トランザクションを通じて送信されるクレジットカード・データを、一定の技術／運用の基準を満たすことで、安全に保護するためのものだ。同じ脆弱性でも、影響の少ないクラウド・ソーシング・サービスなどの組織では、$50〜$5,000 の報酬が支払われるバグバウンティ・プログラムの利用などの、別の戦略で脆弱性を軽減できる。

ゼロデイ・インパクトの深刻度の測定

以下のゼロデイ影響度チャートは、業種と脆弱性のタイムラインに基づいて、特定の組織に与える影響の重大性を示している。

SBOM データベースの作成

すべての資産に対して、クエリベースの Software Bill Of Materials (SBOM) データベースを維持する。この種のデータベースでは、欠陥のタイトルにより検索するだけで、アプリケーション環境の全資産において、対象となる欠陥が存在していることが記録される。これは、負担を軽減するための最短の道である。

ゼロデイ・ポリシーを作成する

もし、あなたの組織がゼロデイ戦略を未策定の状況であれば、また、プレイブックが提供されず、推奨される行動方針が定めていないのであれば、それらを優先することが推奨される。この種のプレイブックは、組織全体に行き渡るものであり、リスク計算および、コストに関する利害関係者の合意、重大な欠陥の管理に関する合意済みのアプローチ、修復プロセスの SLA を考慮する必要がある。

ゼロデイ対応への挑戦と評価

アプリケーションのセキュリティには、ツールや手法への挑戦を繰り返し、テスト／調整することが必要となる。ファイアウォール／アンチウイルス／スキャナなどのソリューションの導入は重要だが、アプリケーション・セキュリティが完全に解決されるわけではない。組織は生き物であり、ビジネス・プロフェッショナルやプロダクション環境の急速な成長と変化に合わせて、常に進化している。

ユーザー組織は、既存のツールを取り入れ、新しいソリューション／サービス／コンテキストと組み合わせることで、柔軟性と俊敏性を維持し、手を抜かず、疑う余地のない、無駄のないセキュリティ・マシンを形成する必要がある。常にツールや手法をテストし、評価することで、次のゼロデイ欠陥を発見する可能性を高められる。

文中の表にある Introduced → Unknown Event → Disclosed → Fix Available → Fix Applied という時間軸ですが、Introduced は始まりと解釈すべきなのでしょう。そして、Fix Available までは外部からの情報に依存しますが、Fix Applied へたどり着くには、Inventory という問題を何とかしなければなりません。そこで、ゼロデイ・ポリシーを作成する前に、Software Bill Of Materials (SBOM) となるのでしょう。そんな、文章の構成になっていますね。