企業がサプライチェーンのセキュリティに取り組む際に必要な6つのポイント
2021年もセキュリティ関連のニュースには事欠きませんでした。中でも大々的に報じられたのは、広く利用されているApache Log4jのゼロデイ脆弱性で、この脆弱性によって攻撃者による任意のコード実行が可能となります。この例が示すように、オープンソースの脆弱性は、ソフトウェア開発業界だけでなく幅広い企業に甚大な影響を与えます。
シノプシスが毎年発行している「オープンソース・セキュリティ&リスク分析レポート(OSSRA)」でも指摘しているように、オープンソースおよびサードパーティソフトウェアの利用は急拡大を続けています。
つまり、自社の開発チームもソフトウェア開発ライフサイクルにおいて何らかの形で、ある程度はオープンソースを使用していると見て間違いないでしょう。
もし自社がソフトウェアプロバイダー(ソフトウェアの開発提供元)として活動しており、提供するアプリケーションの開発にオープンソースおよびサードパーティ/商用コンポーネントを使用している場合、その企業は利用しているオープンソースや商用ソフトウェアのサプライチェーンの一員ということになります。
注意が必要なのは、このサプライチェーンは自社での開発やデリバリ活動で終わるわけではなく、提供しているアプリケーションのエンドユーザーにまで及ぶという点です。
サプライチェーンには、アプリケーションに関わるものすべて、つまりアプリケーションのアセンブル、開発、デプロイに何らかの役割を果たすものすべてが含まれます。
その意味では自前のコードやコンポーネント、ソフトウェアで使用するAPIとクラウドサービス、さらに、それらのソフトウェアをビルドしてエンドユーザーにデリバリする際に使用するインフラもサプライチェーンに含まれます。
自動車製造を例に考える
ソフトウェアサプライチェーンの理解を深めるために、自動車製造のサプライチェーンを例に考えてみましょう。この業界のサプライチェーンは原材料から始まります。まず、原材料サプライヤーが金属、プラスチック原料、皮革、木材などを部品メーカーに納入します。
部品メーカーはこれらの原材料を使用して、ネジ、布地、ナット、ボルトなどの民生品を製造します。これらの部品は自動車部品/システムメーカーに納入され、ここで車両の製造に必要な自動車部品(エンジンやトランスミッションなど)が製造されます。
最後に、これらの車載部品の納入を受けた自動車メーカー(OEM)が組立ラインで車両を製造し、出荷したものが消費者に販売されます。
このように製造プロセスには多くの「入力」があることを考えると、多くのリスク混入カ所が存在することが理解できるはずです。
この自動車を製造するために調達された部品の品質はどうでしょうか。自動車メーカーによる、これら部品の組み立て方法に問題はなかったでしょうか。ユーザーがハンドルを握った際に、この自動車はどのような走行性能を発揮するでしょうか。事故や劣悪な走行状態といったインシデントに対してどれだけうまく対処できるでしょうか。
サプライチェーンの現実として、最終製品とそのユーザーはプロセスに関与するすべての部品、人間、活動、材料、手順の影響を受けます。このワークフローの一部にでも弱点があれば、そこからリスクが混入します。このリスクを軽減するには、サプライチェーン全体を完全に理解する以外にありません。
これは、ソフトウェアサプライチェーンの場合もまったく同じです。簡単に言えば、組織はサプライチェーンを完全に可視化しない限りそのリスクを正確に、あるいは完全に管理することができません。
サプライチェーンは非常に多くの歯車が噛み合って動いているため、弱点や設計上の欠陥を1つでも見落としてしまうと、そこを突かれて全体が攻撃を受けることになります。
サプライチェーンのセキュリティ対策を成功させるために考えるべきこと
基本的に、サプライチェーンのセキュリティ対策では、アプリケーションをアップストリームリスク(ソフトウェアのディストリビューションにおける上流でのリスク)から守ること、そして自らがダウンストリームリスク(ソフトウェアのディストリビューションにおける下流でのリスク)を生み出さないようにすることを考える必要があります。
シノプシスは、サプライチェーンのセキュリティ対策をより簡潔に始めるにあたっての、セキュリティアクティビティの指針とすべき6つのポイントを洗い出しました。これにより、サプライチェーンのセキュリティ対策のあるべき姿と現在の弱点を把握することができます。
1. セキュアなオープンソースを使用しているか？
現代の開発ではオープンソースを使用している可能性が高く、アプリケーションの大部分を占めていることが知られており、組織にとって大きなリスクと成り得ます。
また、開発者が意図せずにオープンソースがプロジェクトに紛れ込んでしまうこともあり、アプリケーションにアップストリームリスクが混入することになります。
自社のサプライチェーン上のオープンソースコンポーネントが抱える脆弱性などのリスクは、自社の責任で管理する必要があります。この作業は非常に大がかりなものとなるため、手作業での追跡と維持管理は現実的ではありません。
さらに法的リスクも考慮する必要があります。ライセンス違反などが訴訟問題に発展すれば、その影響はビジネスの広範におよび、サプライチェーンの法的リスクは組織の評判や財務の健全性への脅威となります。
最後に、開発が活発に行われていないコンポーネントを使い続けることは運用面でのリスクと成り得ます。例えばバグを特定・修正する開発者がプロジェクトからいなくなれば、セキュリティ上の不具合は修正されません。このようなコンポーネントは脅威アクターにとって格好のターゲットとなります。
2. 自社開発のコードはセキュアか？
アプリケーション・コードはその大半がオープンソースで構成されているため、当然アタックサーフェスとなるのも大半がオープンソースです。とはいえ、自社開発のコードが機微なデータやシステムをサイバー攻撃から確実に保護できていることの確認を怠るわけにはいきません。
セキュリティ上の欠陥や弱点が意図せずしてアプリケーション・コードに混入してしまうと、バッファオーバーフローやSQLインジェクション、クロスサイトスクリプティングなどの攻撃を招きます。
万一システムに侵入されると、これらセキュリティ上の欠陥によって機微なデータが流出する可能性があります。脅威アクターはこれらの弱点を突いて悪意あるコードを挿入し、そのソフトウェアを運用している組織が保守しているオペレーティング・システムやその他のシステムへの侵入経路を確保します。
3. 巧妙に仕込まれた悪意あるコードから防御できているか？
Forrester社の予測では、2021年にはセキュリティ侵害の3分の1が内部脅威によって引き起こされるだろうという見方が示されていました。
不満を持つ開発者がバックドアを作成するにせよ、ハッカーがシステムに侵入して大規模な攻撃を仕掛けるにせよ、巧妙に仕込まれた悪意あるコードは、自社で開発・運用するソフトウェアにとってリスクとなります。
悪意あるコードのほとんどはソフトウェア・システムを熟知した人物によって仕込まれるため、脆弱なシステムと通常のシステムは見分けがつかないことが多く、こうしたリスクを昔ながらのツールで特定するのは困難です。
4. 開発およびデリバリに使用しているインフラはセキュアか？
必要なデータストレージは増え続け、デプロイのスケジュールは厳しさを増し、拡張性の迅速さがこれまで以上に重要になっています。
こうした中、ソフトウェア業界はアプリケーションの運用基盤としてクラウドへの依存を強めています。クラウドネイティブアプローチに欠かせないのが、拡張性と俊敏性に対するニーズをサポートしたアプリケーションデプロイ方法の導入であり、これに適しているのがコンテナ化とIaC(Infrastructure as Code)です。
したがって、企業はコンテナにパッケージ化されているソフトウェアの中身と、クラウドプラットフォームにおけるデプロイ用のIaCの安全な使用方法について十分に理解する必要があります。
5. 他システムとの通信に使用しているAPIとプロトコルはセキュアか？
APIとプロトコルは、アプリケーションとユーザーの間でデータやサービスの迅速な転送を可能にします。近年、APIとプロトコルの利用が大きく増えているにもかかわらず、ほとんどの組織は使用しているAPIのインベントリの適切な整備に苦労しています。
このため、どのアプリケーションおよびどのユーザーがどのサービスにアクセスできるかを十分に統制できていないのが現状です。APIの可視化と統制ができていないと、重要なシステムや機微なユーザー情報の安全が脅かされます。
ハッカーはそこにつけ込んで内部の欠陥を悪用して、重要なシステムをクラッシュさせ、あるいは中間者攻撃(MITM)を仕掛けます。中間者攻撃は盗聴の一種で、鍵、パスワード、ログイン資格情報、アカウント詳細など、サプライチェーンの別の場所でより大規模な攻撃を仕掛けるために必要な情報を窃取するために行われます。
6. 顧客やその他のステークホルダーにソフトウェアサプライチェーンの透明性が確保されているか？
SBOM(Software Bill Of Management:ソフトウェア部品表)の提供により、利用者が調達するアプリケーションの構成内容を把握でき、セキュリティおよびコンプライアンスの問題を適切なタイミングで正確に特定して軽減することが容易になることが重要です。
SBOMを保守管理することは、サプライチェーンセキュリティプログラムの成功を左右する重要なベストプラクティスです。アプリケーションの構成内容を完全かつ動的に可視化しておかないと、自社がどのようなリスクにさらされているのかを、自社だけでなくベンダーや利用者も確かめることができません。
シノプシスが毎年発行している「オープンソース・セキュリティ&リスク分析レポート(OSSRA)」でも指摘しているように、オープンソースおよびサードパーティソフトウェアの利用は急拡大を続けています。
もし自社がソフトウェアプロバイダー(ソフトウェアの開発提供元)として活動しており、提供するアプリケーションの開発にオープンソースおよびサードパーティ/商用コンポーネントを使用している場合、その企業は利用しているオープンソースや商用ソフトウェアのサプライチェーンの一員ということになります。
注意が必要なのは、このサプライチェーンは自社での開発やデリバリ活動で終わるわけではなく、提供しているアプリケーションのエンドユーザーにまで及ぶという点です。
サプライチェーンには、アプリケーションに関わるものすべて、つまりアプリケーションのアセンブル、開発、デプロイに何らかの役割を果たすものすべてが含まれます。
その意味では自前のコードやコンポーネント、ソフトウェアで使用するAPIとクラウドサービス、さらに、それらのソフトウェアをビルドしてエンドユーザーにデリバリする際に使用するインフラもサプライチェーンに含まれます。
自動車製造を例に考える
ソフトウェアサプライチェーンの理解を深めるために、自動車製造のサプライチェーンを例に考えてみましょう。この業界のサプライチェーンは原材料から始まります。まず、原材料サプライヤーが金属、プラスチック原料、皮革、木材などを部品メーカーに納入します。
部品メーカーはこれらの原材料を使用して、ネジ、布地、ナット、ボルトなどの民生品を製造します。これらの部品は自動車部品/システムメーカーに納入され、ここで車両の製造に必要な自動車部品(エンジンやトランスミッションなど)が製造されます。
最後に、これらの車載部品の納入を受けた自動車メーカー(OEM)が組立ラインで車両を製造し、出荷したものが消費者に販売されます。
このように製造プロセスには多くの「入力」があることを考えると、多くのリスク混入カ所が存在することが理解できるはずです。
この自動車を製造するために調達された部品の品質はどうでしょうか。自動車メーカーによる、これら部品の組み立て方法に問題はなかったでしょうか。ユーザーがハンドルを握った際に、この自動車はどのような走行性能を発揮するでしょうか。事故や劣悪な走行状態といったインシデントに対してどれだけうまく対処できるでしょうか。
サプライチェーンの現実として、最終製品とそのユーザーはプロセスに関与するすべての部品、人間、活動、材料、手順の影響を受けます。このワークフローの一部にでも弱点があれば、そこからリスクが混入します。このリスクを軽減するには、サプライチェーン全体を完全に理解する以外にありません。
これは、ソフトウェアサプライチェーンの場合もまったく同じです。簡単に言えば、組織はサプライチェーンを完全に可視化しない限りそのリスクを正確に、あるいは完全に管理することができません。
サプライチェーンは非常に多くの歯車が噛み合って動いているため、弱点や設計上の欠陥を1つでも見落としてしまうと、そこを突かれて全体が攻撃を受けることになります。
サプライチェーンのセキュリティ対策を成功させるために考えるべきこと
基本的に、サプライチェーンのセキュリティ対策では、アプリケーションをアップストリームリスク(ソフトウェアのディストリビューションにおける上流でのリスク)から守ること、そして自らがダウンストリームリスク(ソフトウェアのディストリビューションにおける下流でのリスク)を生み出さないようにすることを考える必要があります。
シノプシスは、サプライチェーンのセキュリティ対策をより簡潔に始めるにあたっての、セキュリティアクティビティの指針とすべき6つのポイントを洗い出しました。これにより、サプライチェーンのセキュリティ対策のあるべき姿と現在の弱点を把握することができます。
1. セキュアなオープンソースを使用しているか？
現代の開発ではオープンソースを使用している可能性が高く、アプリケーションの大部分を占めていることが知られており、組織にとって大きなリスクと成り得ます。
また、開発者が意図せずにオープンソースがプロジェクトに紛れ込んでしまうこともあり、アプリケーションにアップストリームリスクが混入することになります。
自社のサプライチェーン上のオープンソースコンポーネントが抱える脆弱性などのリスクは、自社の責任で管理する必要があります。この作業は非常に大がかりなものとなるため、手作業での追跡と維持管理は現実的ではありません。
さらに法的リスクも考慮する必要があります。ライセンス違反などが訴訟問題に発展すれば、その影響はビジネスの広範におよび、サプライチェーンの法的リスクは組織の評判や財務の健全性への脅威となります。
最後に、開発が活発に行われていないコンポーネントを使い続けることは運用面でのリスクと成り得ます。例えばバグを特定・修正する開発者がプロジェクトからいなくなれば、セキュリティ上の不具合は修正されません。このようなコンポーネントは脅威アクターにとって格好のターゲットとなります。
2. 自社開発のコードはセキュアか？
アプリケーション・コードはその大半がオープンソースで構成されているため、当然アタックサーフェスとなるのも大半がオープンソースです。とはいえ、自社開発のコードが機微なデータやシステムをサイバー攻撃から確実に保護できていることの確認を怠るわけにはいきません。
セキュリティ上の欠陥や弱点が意図せずしてアプリケーション・コードに混入してしまうと、バッファオーバーフローやSQLインジェクション、クロスサイトスクリプティングなどの攻撃を招きます。
万一システムに侵入されると、これらセキュリティ上の欠陥によって機微なデータが流出する可能性があります。脅威アクターはこれらの弱点を突いて悪意あるコードを挿入し、そのソフトウェアを運用している組織が保守しているオペレーティング・システムやその他のシステムへの侵入経路を確保します。
3. 巧妙に仕込まれた悪意あるコードから防御できているか？
Forrester社の予測では、2021年にはセキュリティ侵害の3分の1が内部脅威によって引き起こされるだろうという見方が示されていました。
不満を持つ開発者がバックドアを作成するにせよ、ハッカーがシステムに侵入して大規模な攻撃を仕掛けるにせよ、巧妙に仕込まれた悪意あるコードは、自社で開発・運用するソフトウェアにとってリスクとなります。
悪意あるコードのほとんどはソフトウェア・システムを熟知した人物によって仕込まれるため、脆弱なシステムと通常のシステムは見分けがつかないことが多く、こうしたリスクを昔ながらのツールで特定するのは困難です。
4. 開発およびデリバリに使用しているインフラはセキュアか？
必要なデータストレージは増え続け、デプロイのスケジュールは厳しさを増し、拡張性の迅速さがこれまで以上に重要になっています。
こうした中、ソフトウェア業界はアプリケーションの運用基盤としてクラウドへの依存を強めています。クラウドネイティブアプローチに欠かせないのが、拡張性と俊敏性に対するニーズをサポートしたアプリケーションデプロイ方法の導入であり、これに適しているのがコンテナ化とIaC(Infrastructure as Code)です。
したがって、企業はコンテナにパッケージ化されているソフトウェアの中身と、クラウドプラットフォームにおけるデプロイ用のIaCの安全な使用方法について十分に理解する必要があります。
5. 他システムとの通信に使用しているAPIとプロトコルはセキュアか？
APIとプロトコルは、アプリケーションとユーザーの間でデータやサービスの迅速な転送を可能にします。近年、APIとプロトコルの利用が大きく増えているにもかかわらず、ほとんどの組織は使用しているAPIのインベントリの適切な整備に苦労しています。
このため、どのアプリケーションおよびどのユーザーがどのサービスにアクセスできるかを十分に統制できていないのが現状です。APIの可視化と統制ができていないと、重要なシステムや機微なユーザー情報の安全が脅かされます。
ハッカーはそこにつけ込んで内部の欠陥を悪用して、重要なシステムをクラッシュさせ、あるいは中間者攻撃(MITM)を仕掛けます。中間者攻撃は盗聴の一種で、鍵、パスワード、ログイン資格情報、アカウント詳細など、サプライチェーンの別の場所でより大規模な攻撃を仕掛けるために必要な情報を窃取するために行われます。
6. 顧客やその他のステークホルダーにソフトウェアサプライチェーンの透明性が確保されているか？
SBOM(Software Bill Of Management:ソフトウェア部品表)の提供により、利用者が調達するアプリケーションの構成内容を把握でき、セキュリティおよびコンプライアンスの問題を適切なタイミングで正確に特定して軽減することが容易になることが重要です。
SBOMを保守管理することは、サプライチェーンセキュリティプログラムの成功を左右する重要なベストプラクティスです。アプリケーションの構成内容を完全かつ動的に可視化しておかないと、自社がどのようなリスクにさらされているのかを、自社だけでなくベンダーや利用者も確かめることができません。
