たとえば、アプリケーション内で一連の疑わしいコードを発見するとしましょう。アプリケーション・テスト・チームによる定期的なスキャンで、ソフトウェア・サプライチェーン内の悪意のある内部関係者が時限爆弾やバックドアなどの悪意のあるコードを挿入したことを示す重要なポイントが見つかる可能性があります。
まず、永続的な損害（データの盗難、ログ・キーストローク、金銭の吸い上げ、またはアプリケーションのその他の機能の破壊）が発生する前に問題を発見できたことは一安心です。
しかし、1つのアプリケーションに悪意のあるコードが挿入されたのなら、他のアプリケーションがターゲットにならないようにする方法を考えなければなりません。
そのためには犯人の正体を明らかにする必要があります。
悪意のあるコードは、オープンソース・コンポーネントの開発から最終製品ビルドまでのあらゆる段階で実行可能ファイルに挿入される可能性があります。つまり、ソフトウェア・サプライチェーン内の誰もが敵対行為を行う可能性があるということです。
通常考えられる容疑者をリストアップする
容疑者リストには、悪意のあるコードを挿入するために必要なアクセス権または能力を持つ人物が含まれます。
- 管理/運用
- 本番環境へのアクセス権限
- LANアクセスの権限
- 認証情報
- 開発者
- ソースコードを変更する能力
- サードパーティーおよびオープンソースのライブラリを選択する能力
- 設定ファイルを変更する能力
- 変更/構築/制御管理
- バイナリを再パッケージ化する能力
- ビルドサーバー上の依存関係を変更する能力
- 悪意のあるバイナリを使用するようにビルドファイルを設定する能力
証拠を集める
実行可能ファイルの分析だけでは、潜在的な容疑者のリストを絞り込むのに十分な情報は得られません。この種の検出作業を行うには、依存関係、ソースコード、ビルド・ファイル、設計書を入手する必要があります。これらのアセットを組み合わせると、悪意のあるコードが挿入されたときのタイムラインを時系列にまとめるのに役立ちます。次のような仕組みです。
実行可能ファイルとソースコードを分析する
アプリケーションの実行可能ファイルとソースコードの両方で悪意のあるコードが見つかった場合は、犯人が独自開発コードまたは外部の依存関係の開発者であることを示す有力な指標となります。
悪意のあるコードがソースコードに存在しない場合は、悪意のあるコードが分析される前にソースコードから削除されたか、ソフトウェア開発ライフサイクル（SDLC）の後工程でコードが挿入された可能性があります。
検索を絞り込むには、コードが取得された場所を考慮する必要があります。コードの変更が追跡され、ビルド・プロセスでコードが取得されるリポジトリから悪意のあるコードが検出された場合も、そのコードがSDLCの後工程で挿入されたことを示す有力な指標となります。
実行可能ファイル、ソースコード、ビルド・ファイルを分析する
開発工程以降で悪意のあるコードがアプリケーションに挿入される可能性もあるため、ビルド・ファイルの解析も必要です。
たとえば、次のAntビルド・ファイル・スニペットに示すように、単純なタスクを追加することで、ビルド時に悪意のあるコードを挿入するプログラムを実行するビルド・ファイルを作成することができます。
次のスニペットに示すように、ビルド・サーバー以外の場所から悪意のある依存関係を取得するようにビルド・ファイルを構成することもできます。
または
内部関係者なら、ビルド・サーバーのローカル・リポジトリ内の既存の依存関係を悪意のある依存関係に置き換えることもできます。ビルド・ファイルが安全でも、ビルド・プロセスでこれらの悪意のある依存関係が使用され、その結果、これらの依存関係を使用するすべてのアプリケーションに悪意のあるコードが挿入されます。このケースは、ソースコードもビルド・ファイルも無害であるように見える実行可能ファイル内にも悪意のあるコードが存在する場合があることを示しています。
「内部関係者」は、影響を受ける組織の従業員や請負業者であるとは限らないことに注意してください。内部関係者には、従業員がアクセスするシステムや情報に、悪意のある手段を通じてアクセスできる人物も含まれます。たとえば、攻撃者がSolarWindsのビルド・プロセスにアクセスして悪意のあるコードを挿入した際の手口を見てみましょう。このコードは顧客に到達するまで検出されませんでした。
設計書を分析する
設計書は、悪意があるように見えるコードに実際に悪意があるかどうかを判断するために役立ちます。例として、以下のweb.xmlのスニペットを見てみましょう。このコードは、代替パスがマッピングされている代替サーブレットを使用したアプリケーションを示しています。設計書を見れば、この代替パスが設計上必要かどうか、潜在的に悪意があるかどうかがわかります。
ケースを構築する
情報が多ければ多いほど、内部関係者による脅威の原因を見つけることが容易になります。どの工程で悪意のあるコードが挿入されたかを確信できれば、アクションを追跡して特定の個人またはソースを突き止めるのに十分な情報が得られる可能性がありますが、十分な情報が得られない場合は、チームをより注意深く監視する必要があります。疑惑が確定する前に調査に気付かれないよう、調査チームは小規模に保ちます。
Continue Reading
