先週の木曜日の深夜、私たちはここ数年で最も注目すべき情報セキュリティイベントの1つを経験しました。Java用の人気のあるロギングパッケージであるLog4jの新しいゼロデイエクスプロイトが発見されました。 正確な出所とタイムラインはまだ調査中ですが、これは単なる脆弱性の発表ではないことに注意することが重要です。開示された情報の直後に完全に機能するエクスプロイトコードが続き、エクスプロイト自体の実行は簡単であることが判明しました。
30億を超える機器がJavaを実行している一方で、ロギングライブラリはほんの一握りしかないため、それらの多くはLog4jを実行している可能性があります。さらに悪いことに、インターネットに公開された多くのターゲットアプリケーションは、認証なしで外部ユーザーによって悪用される可能性があります。 また、悪名高いHeartbleedや最近公開されたTrojan Sourceなど、他の注目すべきオープンソースの脆弱性とは異なり、この場合、ユーザーが対応を計画するのに十分な時間を確保するための事前の調整は「舞台裏」で行われませんでした。
バグに伴うアプリケーションの再構築が急ぎ始められることなく、ベテランのCISOは睡眠を削ることなく、通常の金曜日のルーチンよりも少しだけ楽だったであろう理由はここにあります。
チーズの穴
航空安全の専門家が言うように、スイスチーズの穴が重なると事故やインシデントが発生します。つまり、最悪のシナリオが現れるのを防ぐための保護と制御の複数のレイヤーがあっても、既知の壊滅的なイベントは、これらすべての緩和策が失敗した場合にのみ発生してきました。サイバーセキュリティも例外ではなく、多層防御についてもずっと語り続けられてきました。
スイスチーズの穴の影響を軽減し、すべてのCISOの金曜日を保護するのに役立つ6つの要素を次に示します。
- Log4j コンポーネントの脆弱性の告知と緩和
これは幾つかのアクションに分解できます。- 脆弱性が発見されてからチームが気付くまでの時間を最小限に抑える
- 能力を最大限に活かしてどのアプリケーションで問題のコンポーネントを使用しているか特定する
- 復旧能力を能率化し、影響を受けるアプリケーションに迅速にパッチを適用するか、補完的な対策を導入する
- 悪用に対する感受性：入力と出力の検証
この脆弱性の悪用を成功させるには、いくつかのセキュアコーディング規約を無視する必要があります。信頼できないソース（例えば、ユーザーが制御する入力）から入力されたデータは、通常、サニタイズせずにログファイルに連結しないようにします。これは、入力データが認証されていない発信元からのものである場合、（人間の）ユーザーであろうと他のアプリケーションであろうと同じことです。他に提出される可能性のあるデータベースやログなどの機密領域に流入するデータは、出力検証を行う必要があります。さもないとログインジェクションの脆弱性が発生する可能性があります。これは、CWE 117に分類され、長く知られており、CERT Javaのコーディングルールで解説されています。したがって、私たちの最初の防衛線は、アプリケーションにこの種の欠陥がないことを確認することです。 - ネットワークアーキテクチャとネットワークレベルのアクセス制御
悪用の次の段階を成功させるには、攻撃者がペイロードを転送したり、外部システムとの間でデータを盗み出したりできる必要があります。これには、シェルを実行するためのコードの転送や、暗号マイニングマルウェアの転送が含まれる場合があります。外部ホストとの通信の開始は、常に最小限に抑える必要があります。Center for Internet Security（CIS）のガイドラインは、MITRE ATT&CKといった他の多くのフレームワーク同様これをカバーしています。MITRE ATT&CKは、ネットワークフィルタリングをカバーするM1037の緩和策の全カテゴリを備えています。クライアントサイドのアプリケーションの場合、サンドボックス技術を使用すれば、組み込みシステムのOSやJVMであっても、利用可能な悪用経路の範囲をさらに減らすことができます。 - アプリケーションのアーキテクチャ上のリスク
アプリケーションが機能するために公開する必要のある要素アプリケーションに認証されていない外部ユーザーがアクセスするという最悪のシナリオでは、適用できる防御的プログラミング手法があります。そもそもログインページで$や{といった文字を許可する必要があるのはなぜでしょうか？フリーテキストによる検索フィールドでさまざまな文字を使用できるようにすることは理にかなっていますが、適切に設計されたアプリケーションでは、サーバー側の入力フィルタをロックダウンし、受け入れるデータを予想される情報の種類と範囲に制限する必要があります。パスワード文字列には特殊文字を含めることができますが、パスワードなどの機密データをログに保存できるようにする必要はありません。このような最悪の事態は、あらゆる入力において排除する必要があります。こういった問題を発見するためには、インタラクティブな分析ツールを用いてアプリケーションとマイクロサービスの境界を越えてアプリケーションのデータフローを視覚化し、どのデータをどこに移動する必要があるかを確認し、適切な入力フィルタの有無を検証できます。 - ログを取り、監視し、異常を検知する
いいえ、これは皮肉ではありません。異常検出ルーチンは、アプリケーションの異常な振る舞いを発見する必要があります。例えば、接続すべきでないホストへの接続の試みやプロセスの起動、必要の無いファイルへのアクセスなどの可能性があります。サンドボックス環境の一部として構成することで脆弱性が悪用された場合の影響を抑え、実際の悪用を事実上不可能にすることのできる保護・検知対策は非常に沢山あります。また、悪用されてしまった場合、アクセスされたものを特定し、侵害調査チームが実際のビジネスへの影響を判断するのをサポートできることが非常に重要です。 - ソフトウェアコンポーネントの透明性、ベンダー管理、成熟したOSSの利用
これによって、私たちが日常的に使用する製品に組み込まれているソフトウェアを含め、自分たちが開発していないソフトウェアのこの種のリスクにどのように対処するかという課題にたどり着きます。一方で、すでに一部の企業ではソフトウェア部品表（SBOM）の開示が定期的に要求され、開示されています。このようなソフトウェアコンポーネントのリストは、Log4jを（直接的または間接的に）使用しているユーザーと利用している製品またはベンダーを正確に特定できることから、修復のための対応と調査を能率化するのに役立ちます。しかし、この話にはオープンソースの成熟した管理という別の側面があります。Synopsys Cybersecurity Research Center（CyRC）の主任セキュリティストラテジストであるTim Mackeyは「オープンソースのようなベンダーはありません」と述べています。例えば、Log4jのライブラリはApache Foundationを介した広範なコミュニティイニシアチブの一部として、継続的かつ積極的に維持およびサポートされているようです。しかし、多くのライブラリは特定のグループや個人の支援なしに開発され、その後、放棄されたり、忘れられたりしています。コミュニティのサポートやメンテナンスといった側面を含むオープンソースコンポーネントの来歴を見れば、この種の潜在的なリスクを示す指標が得られ、信頼するコンポーネントを選択するのに役立ちます。Log4jではなく、影響を受けたコンポーネントが数年前に放棄されていて、最後のメンテナに連絡できなくなった場合はどうなるでしょうか？
実際にはどのようになるか
脆弱性への対応は、人、プロセス、テクノロジーの組み合わせによって実現します。ソフトウェア・コンポジション解析ツールは、ライブラリの使用状況を特定して追跡するのに役立ちます。新しい脆弱性が出現すると、シノプシスのBlackDuck®研究チームが問題を調査します。Log4jの脆弱性には、開示されてから数時間の間、詳細なCVEエントリが割り当てられていませんでしたが、シノプシスのアナリストはすでにBlack Duck Security Advisory（BDSA）番号を割り当ててシノプシスの顧客に通知をしました。
そして、Black Duckが新たなBDSAについてのアラートを発信すると、Black Duckを利用している開発チームのセキュリティアナリストは、影響を受けるアプリケーションを確認することができるようになります。この新しい脆弱性の影響を受けるアプリケーションを所有する開発者は、Black Duckアラートの構成方法に従い、Teams、Slack、またはJiraチケットや電子メールで通知を自動的に受け取ります。 次に、更新を迅速に展開するための組織的な仕組みを整える必要があります。ここで、DevOpsが機能しているかを確認する事になるわけです。
組織のDevOps能力を測定しベンチマークするための業界横断的なプログラムであるDevOps Research and Assessment（DORA）の主要な指標の1つは、変更のcommit から本番環境稼働までの所要時間（変更のリードタイム）です。DORAによると、エリートパフォーマーはこのサイクルを1時間以内に完了し、必要に応じて変更を展開できます。ただし、最新のState of DevOps Surveyで調査された1,200人の回答者のうち、エリートカテゴリに分類されるのは26％にすぎません。また次のカテゴリであるハイパフォーマーはこのサイクルを完了するのに1日から1週間かかります。これらの組織は、リードタイムを最短化する準備ができていないのです。つまり、セキュリティパッチを適用することを「通常のビジネス」活動と見なしていないのかもしれません。
エリートとハイパフォーマーの間のこの大きなギャップは、基本的なDevOpsプラクティスの採用を最大化することがすべての人に利益をもたらす理由を示しており、セキュリティ・チームが開発チームと連携してセキュリティ、品質、またはその他の種類の問題の迅速な修正に取り組むかどうか、適切に対応できるようにする必要がある理由を示しています。
図 1：ソフトウェア デリバリーのパフォーマンス指標、”State of DevOps Survey”より
最後に、基盤となるコンポーネントを修正するだけでなく、影響を受けないための3つの理由があります。
まず、優れたコードハイジーン、優れたネットワークアーキテクチャ、および一元化されたセキュリティおよびエンジニアリングチームが適切なセキュリティチェックをCI/CDパイプラインに統合し、開発者に実用的な情報を提供することで得られた信頼は、ユーザーを保護し、すべてのソフトウェアのデリバリーにおいてセキュリティ、品質、および安全性のリスクを回避するのに役立ちます。Coverity®のような静的コード解析ツールは、ログインジェクションの脆弱性を見つけることができます。また、最新のInfrastructure-as-Codeで構成されているのであれば、過度に寛容なネットワークルールを自動分析で検出できます。
十分に調整されたAppSecプログラムでは、チームまたは自動化機能によってASTツールを実行したかどうかを判断し、結果が修正された場合は、Application Security Orchestration and Correlation（ASOC）ダッシュボードを数回クリックする必要があります。
さらに、バイデン大統領によるEO 14028によって支持されたSBOMの採用が増加していることから、ソフトウェアコンポーネント情報は製品ベンダーとその顧客の間でよりシームレスに流れるようになっていくでしょう。すべてのサプライヤに連絡してコンポーネント情報を確認する代わりに、データベースを検索すれば済むのです。Black Duckなどのソフトウェア・コンポジション解析ツールのユーザーは、社内で開発したソフトウェアのSBOMの情報から恩恵を受けられますが、今ではSBOMの幅広い採用と組織間での流通が最前線で行われています。一度SBOMの流通が確立されると、リスクの軽減と管理のための強力なツールとなり、今回のような事態が発生しても迅速な対応（おそらく自動化された対応）がサポートされるのです。
オートパイロットによる対処
すでに起こっているこれらのことについて話すことは「後の祭り」と言えるかもしれません。セキュリティは単一の個人または部門の仕事ではないことを強調することが重要です。私たちの使命を成功させるためには、これらの活動のそれぞれをすべての人の仕事に組み込む必要があります。また、組織が成功を収めるためには、ITシステムの計画、構築、運用方法の文化にさまざまなセキュリティ活動を組み込む必要があります。たとえば、機能しないセキュリティ要件の策定や設計段階でのアーキテクチャのレビューなどのプラクティスは、アプリケーションが処理する必要のあるデータや、ソフトウェアが本番環境にリリースされる前に満たす必要のあるセキュリティチェックの要件を特定するのに役立ちます。
現代の組織の高度に自動化されたソフトウェア・デリバリー・プロセスやパイプラインでは、前提条件となる手順が完了していない場合に失敗するようにプログラムされているので、既知の脆弱性を含むか緩和策が組み込まれていない製品を発売することはできないでしょう。つまり、将来的にSBOM情報は、ゼロトラストアーキテクチャが、ソフトウェアが実行できる信頼と特権のレベル、または実行を停止するタイミングを動的に決定できる手段になる可能性があるということです。
幸いなことに、これらすべての重要な領域にわたって組織の能力を測定およびベンチマークし、Building Software in Maturity Model （BSIMM）フレームワークを使用して、改善すべきギャップや領域を明らかにすることが可能です。