「 Log4j の脆弱性」を契機としたサプライチェーンリスクの抑制

この「 Log4j 」と呼ばれるソフトウェアの欠陥は、今後数ヶ月から数年にかけて、インターネットに甚大な被害をもたらすと予想されています。パッチの適用は、企業や政府機関にとって、まさに「軍拡競争」のような状況となっています。成功は、ネットワークの可視性、パッチ適用のスピード、およびワークフローにかかっています。

Log4j は、ロギングユーティリティです。世界中のほぼすべてのクラウドサービスや企業ネットワークで、サーバーへのアクセス手段として利用されています。これは、私たちのデジタルライフを今や悩ませている、最新のソフトウェア・サプライチェーンの脆弱性（大規模なSolarWinds攻撃で発覚したものと同様）に過ぎません。

しかし、こうしたサプライチェーンの脆弱性に関する真実は、次の通りです。それらは、被害をもたらす前に、監視・管理することが可能であり、またそうすべきなのです。

ブロックチェーンサービス企業Paxosの元最高セキュリティ責任者であるニック・セルビー氏は、ソフトウェアおよびサプライチェーンのセキュリティに関しては、不必要なリスクを冒すことに興味を持っていません。だからこそ、彼は現在、多くの組織が自分たちを守るためにとっている手法について懸念を抱いているのです。

「私たちは、 20 年前とほとんど変わらない方法で現代の環境のセキュリティを確保しようとしており、それが攻撃対象領域に対する完全な誤解を招いているのです」とセルビー氏は警告します。「これは業界が早急に改善すべき点です」と彼は付け加えます。

こうした誤解の多くは、サードパーティ製ソフトウェア、クラウドソフトウェアサービス、およびオープンソースソフトウェアのセキュリティリスクについて、十分な可視性が欠如していることに起因しています。「サプライチェーンや、サードパーティ製ソフトウェアコンポーネント内の脆弱性に起因するサードパーティリスクは、外部要因による情報漏洩の大きな要因であり続けています」と、フォレスター・リサーチのプリンシパル・アナリスト、サンディ・カリエリ氏は、同社が最近開催した『 Security & Risk Forum 2021』（）において警告しました。「組織のエコシステムには、おそらくかつてないほど多くの第三者が関わっているでしょう」と彼女は付け加えました。

自動化されたクライアント管理により、ネットワーク上のすべてのIT資産を数分で一元管理できます。

パンデミックの期間中、のソフトウェアサプライチェーンに対する攻撃が急増しました。ついこの前の夏、アトラシアンのアジャイルプロジェクト管理およびソフトウェアバグ追跡ツールに、「ワンクリック」攻撃の脆弱性が発見されました。これにより、ハッカーがアジャイル計画システムやコードリポジトリに侵入し、何も疑っていないユーザーのコードベースにエクスプロイトを注入することが可能となっていました。

フォレスターのセキュリティアナリスト、クリス・コンド氏が同社のセキュリティ・リスクフォーラムで述べたように、「誰かがログインしてソフトウェアを変更したことに、気づくことさえできないでしょう。」「こうした問題が、毎日のように発生しているのです。」

欧州連合サイバーセキュリティ庁（ENISA）によると、サプライチェーン攻撃（そのすべてが公表されているわけではありません）は、 2021 年から2020年にかけて4倍に増加した可能性が高いとのことです。 ENISAによると、こうした攻撃の 66％において、攻撃者はまずサプライヤーのコードベースを標的とし、そこから最終的な標的へと攻撃を拡大させていたとのことです。
攻撃者がサプライチェーン型攻撃にますます注力する中、組織は自組織をより効果的に保護する方法を理解する必要があります。これを、リスクベースの脆弱性管理における第一歩とお考えください。

変化する攻撃に対応するために戦術を転換する

サプライチェーン攻撃が増加しているのは、数十年にわたりビジネステクノロジーやサードパーティのリスクを軽減する手法を変えていない大規模な組織を標的とすることができるためです。「企業は、現代の企業がテクノロジーをどのように購入し、構築し、管理しているかについて、その変化に追いつけていないのです」と、ポッドキャスト『 Tech Debt Burndown』（）の共同ホストであるセルビー氏は述べています。同氏は最近、Paxosを退社し、サイバーセキュリティの研究・コンサルティング会社Trail of Bitsに入社しました。「私たちは今でも、会計士が ’90s で作成したスプレッドシートに基づいて、第三者によるデューデリジェンスを実施しています。」

「組織のエコシステムには、おそらくかつてないほど多くのサードパーティが存在しているでしょう。」

当時、サードパーティによるセキュリティ侵害がもたらす主なリスクは、機密データの漏洩やサービスの停止であったため、こうした対策は効果を発揮しました。しかし、ランサムウェアを用いて組織の機能を麻痺させたり、ロックダウンさせたりすることを目的とした、直接的な侵入を意図したサードパーティによるリスクに対しては、十分な対策を講じられていないのが実情です。リスクベースの脆弱性管理戦略では、その点を考慮に入れる必要があります。
サプライチェーンへのハッキングは、このように行われます。サイバー犯罪者や国家が関与するハッカーは、組織を直接標的にするのではなく、ソフトウェアメーカーやソフトウェアサービスプロバイダーを標的にしています。彼らは、他の組織によって使用されるソフトウェアに攻撃コードを埋め込みます。これらの攻撃者は、特に脆弱性のあるソフトウェア開発パイプラインやセキュリティ対策が不十分なクラウド構成を標的にしたり、ソフトウェアの更新プロセスを悪用したりしています。
壊滅的な被害をもたらしたSolarWindsへのハッキング事件を受け、連邦当局は、政府機関や民間企業がソフトウェアのサプライチェーンリスクを適切に管理できるよう支援に努めています。。 2021年5月において、バイデン大統領は「国家のサイバーセキュリティの向上に関する大統領令（）」を発令しました。この大統領令では、連邦政府にソフトウェアを提供するベンダーに対し、製品に含まれるすべての構成要素についてソフトウェア部品表（SBOM）を添付することが義務付けられています。

SBOMとは、ソフトウェアアプリケーションやパッケージに含まれるコンポーネントや依存関係の「レシピ」のようなもので、プロプライエタリなコードやオープンソースコードも含まれます。

「この大統領令は、前例のない措置を講じています」と、フォレスターのシニアリサーチアナリスト、アラ・ヴァレンテ氏は、同社のセキュリティ・リスクフォーラムの聴衆に向けて述べました。これは万能の解決策でもなければ、やに記載されている適切なサイバーセキュリティ対策の代わりになるものでもありませんが、この命令により、サプライチェーンのセキュリティ対策が加速されました。

アラン・フリードマン氏も同意見です。サイバーセキュリティ・インフラセキュリティ庁（CISA）のSBOM推進担当者であるフリードマン氏は、先日開催されたSecurityWeek主催のCISOパネルディスカッション「：サプライチェーンセキュリティの透明性」（）において、「私が重視している点の一つは、サプライチェーンの分析と監視の強化です」と述べました。

スピードバンプを設置する

サードパーティのクラウドおよびソフトウェアプロバイダーの審査は、そのセキュリティ成熟度を把握することから始まります。セルビー氏は、ソフトウェアベンダーと取引を始める前に、セキュリティ対策が不十分な業者をふるい落とすことを目的とした、シンプルでわかりやすいテストから始めます。

「Paxosでは、予備評価として10問のアンケートを実施しており、これは極めて重要なものです。「これは、最終的なセキュリティやコンプライアンスの評価としてではなく、一時的な措置として導入したものです」と彼は述べています。

「もし［セキュリティ責任者が］エンジニアリング担当副社長であるなら、セキュリティプログラムは存在しないことになります。」
ニック・セルビー氏（元Paxos最高セキュリティ責任者）

事前の質問には、次のようなものがあります。「セキュリティに関する方針や手順を文書化して作成していますか？」それを見せていただけますか？トレーニングのメニューについて教えてください。情報セキュリティのみを担当する役員はいらっしゃいますか？

「もしそうだとすれば、しかもその人物がエンジニアリング担当副社長であるなら」とセルビー氏は言います。「それなら、御社にはセキュリティ対策が整っていないことになります。」「『はい、当社には最高セキュリティ責任者、最高情報セキュリティ責任者、情報セキュリティ担当取締役がいます』――つまり、セキュリティの実現に対して責任を負い、説明責任を果たす人物がいる、というお話を伺いたいのです。」
ソフトウェアのセキュリティ評価において、サードパーティのコードレビューも不可欠な要素として含める必要があります。セルビー氏は、サプライチェーンソフトウェアの導入を検討している組織に対し、ベンダーのソフトウェア開発体制や、そのエンジニアリングチームによるセキュアコーディングの実践状況を理解することに重点を置くよう助言しています。「セキュアコーディングの研修は行っていますか？また、具体的にどのようなことを行っていますか？」セルビーが尋ねます。「トレーニングの取り組みについて教えてください。」
セキュリティ審査に合格したからといって、そのベンダーが契約を獲得できるとは限りません。とはいえ、これは彼らが最も基礎的かつ重要な試験のハードルをクリアしたことを意味します。「少なくとも、彼らが当社のコンプライアンス、セキュリティ、および法的な審査をクリアしてくれるという確信は持っています」とセルビー氏は述べています。

「そして、まさにそれが、組織がすべきことだと私は考えています。つまり、新しいベンダーの導入プロセスにおいて、早い段階からセキュリティ部門を巻き込むことです。」「残念ながら、企業では依然として、セキュリティ対策が最後の段階になるまで取り入れられていないのです。」

オープンソースは無料ですが、リスクがないわけではありません

適切なサプライチェーンのセキュリティを確保するためには、ネットワーク環境内でどのようなオンプレミスおよびクラウドのソフトウェアサービスやソフトウェアが稼働しているかを特定し、把握することも必要です。「一見したよりも、これはもっと複雑な課題なのです」とセルビー氏は述べています。

オープンソースのコンポーネントを使用していることで、その難しさはさらに増しています。「組織がオープンソースを利用してアプリケーションを開発したり、それ自体が最大 90％ものオープンソースコードを含む市販ソフトウェア内でオープンソースを利用したりするにつれ、自社の環境に恐ろしいほどのサードパーティリスクを取り込んでいるのです」と、ヴァレンテ氏はセキュリティ・リスクフォーラムで述べました。

「市販のソフトウェアには最大 90％ものオープンソースコードが含まれており、恐ろしいほどのサードパーティリスクをもたらしています。」

オープンソースソフトウェアのリスクを管理するには、セキュリティチームがソフトウェアのコードを綿密に検証する必要があります。それは、既知の脆弱性を確認し、のすべてのパッチが最新の状態であれば安全だと安易に考えることではありません。。

「たいていの場合、セキュリティチームのレビューではそういうことが起こります」とセルビー氏は述べています。「彼らはオープンソースプロジェクトについてCVE（共通脆弱性情報）を確認し、重大な脆弱性がなければ、問題ないと判断します。」「それはとんでもないですね。」
その代わりに、セキュリティチームは、オープンソースプロジェクト内のすべてのコンポーネントとソフトウェアの依存関係を精査し、各コンポーネントがセキュリティ上の脆弱性についてどのように評価・テストされてきたかを把握する必要があります。

「オープンソースとは、ソースコードが公開されており、誰でもそれを利用し、評価し、改良できることを意味します」とセルビー氏は述べています。「オープンソースとは、受け入れるか、受け入れないかの二者択一というわけではありません。」

実践におけるソフトウェア・サプライチェーンのセキュリティ

バイデン大統領の大統領令では、連邦機関に対し、セキュリティプログラムの改善に向けた新たな要件――例えば、のゼロトラストの導入、のクラウドセキュリティ戦略の強化、およびSBOMの導入など――が求められていますが、米国国立標準技術研究所（NIST）は、これらのツールを現実のものとするべく取り組んでいます。

「調達部門のずる賢い連中が ’90s以来使い続けてきたようなスプレッドシートはもうやめましょう。」
ニック・セルビー

先ごろ開催されたワークショップにおいて、NISTは、特別刊行物『 SP 800-218』の改訂内容について検討を行いました。『 2021年9月』で公開されたこの文書では、組織が自社のソフトウェア開発ライフサイクルに組み込むことができる、高水準のセキュアなソフトウェア開発実践の主要なセットについて詳しく説明しています。 SBOMの利用に関する最終ガイドラインは、『 2022年2月』に掲載される予定です。
一方、米国電気通信情報局（NTIA）は最近、SBOMに必須とされる最低限の要素を定義しました。これらには、ソフトウェアメーカー名、ソフトウェアのバージョン情報、ソフトウェアコンポーネントを識別するための一意な方法、コンポーネント間の依存関係の一覧、およびSBOMを作成した人物と作成日時に関する記録が含まれる必要があります。 NTIAは、SBOM情報の共有に関する3つのオープン標準、すなわちSPDX、CycloneDX、およびSWIDを認定しました。
アナリストによると、これら3つの標準はそれぞれ異なる特徴を持っているとのことです。 SWIDはソフトウェアのライセンスや商用利用権を追跡するために設計されていますが、SPDXはライセンス、ソフトウェアコンポーネント、セキュリティ情報、その他のメタデータを対象としています。同時に、CycloneDX規格はソフトウェアのセキュリティを重視しています。
”「CycloneDXは、NTIAが公表した最低限必要な要件をはるかに超える、幅広いサイバーセキュリティのユースケースに対応できるよう特別に設計されています」と、スティーブ・スプリングエット氏は先ごろ開催されたSecurityWeekのCISOパネルディスカッションで述べました。スプリネット氏は、ウェブアプリケーションセキュリティに関する無料の記事、手法、ドキュメント、ツール、技術を提供するオンラインコミュニティである「Open Web Application Security Project（OWASP）」のワーキンググループ「CycloneDX SBOM Standard」の議長を務めています。

[関連記事：御社の組織は、ソフトウェアのサポート終了に備えていますか？]

標準規格が進化し続ける中、セキュアなソフトウェア開発の効率化を目指す組織は、利用可能な手段で対応せざるを得なくなるでしょう。こうしたプロセスを導入するのは容易ではなく、その支援ツールも絶えず進化しています。

とはいえ、組織としては、ソフトウェア・サプライチェーンのセキュリティ対策に着手することが不可欠です。「企業は、GRC［プラットフォーム］であれ、サードパーティ・リスク管理プラットフォームであれ、既存のソフトウェアをどのように活用すべきか検討すべきです」と、ヴァレンテ氏はフォーラムの聴衆に語りました。

ソフトウェアのサプライチェーンセキュリティは、セキュリティプロセスや安全なソフトウェア開発ライフサイクルの綿密な検証から始まりますが、サイバー犯罪者や国家は、今後もサービスプロバイダーに対する攻撃を仕掛け続け、それを足掛かりとして顧客を攻撃し続けるでしょう。全般的なセキュリティ対策が最も適切に実施されているお客様ほど、組織内のセキュリティを維持することに成功するでしょう。

そのためには、組織内で稼働しているソフトウェアを把握し、パッチを適用して常に最新の状態に保つこと、適切な構成管理を維持すること、そして効果的な監視およびインシデント対応体制を整えることが必要です。

セルビー氏によると、組織が今できる最も重要なことの一つは、サードパーティ製ソフトウェアやサプライチェーンのリスクを管理する従来の方法から、できるだけ迅速に脱却することだといいます。

「調達部門のずる賢い連中が ’90sの頃から使い続けているようなスプレッドシートはもう使うのをやめなさい」と彼は言います。「そろそろ、こうした質問の内容を見直し、各組織が環境に対するリスクをどのように管理しているかに焦点を当てるべき時が来ています。」