ソフトウェアサプライチェーン攻撃とは何か【ベンダーの対策編】| Machina Record blog

セキュリティ/サイバーインテリジェンス最新トレンドをご紹介

Codebook|サイバーインテリジェンス/セキュリティNews|Machina Record Blog > Articles > NEWS > ソフトウェアサプライチェーン攻撃とは何か【ベンダーの対策編】 | 米CISA/NISTの資料から(3/3)

ソフトウェアサプライチェーン攻撃とは何か【ベンダーの対策編】 | 米CISA/NISTの資料から(3/3)

 

2020年12月、ネットワーク管理製品の SolarWinds Orion プラットフォームを狙ったサプライチェーン攻撃が発覚しました(*1)。

国内外で大きく報道されたこの攻撃では、多くの米国の政府機関や民間企業のネットワークが被害を受けたとされています。

 

先月ニュースで話題となったメルカリのデータ流出に影響を与えたとされるコードカバレッジツール「Codecov」への不正アクセスもサプライチェーン攻撃の一種と言えます(*2)。

 

2021年4月26日、米国の政府機関であるCISAとNISTは、ソフトウェアサプライチェーン攻撃の概要と対策をまとめた資料「Defending Against Software Supply Chain Attacks」(訳:ソフトウェアサプライチェーン攻撃に備える)を、ウェブ上に公開しました。

この資料では、ソフトウェアサプライチェーンにおけるリスクの概要が説明されているほか、ソフトウェア顧客とベンダーがNISTのフレームワークである「C-SCRM」と「SSDF」を利用して、リスクを特定・評価・緩和する方法について紹介されています。

(この資料のURLは本記事末尾で紹介しています)

 

これまでの2回の記事では、

この資料のうち、

ソフトウェアサプライチェーンとは何か

ユーザー側はどう対策すべきか

について書かれた部分を紹介しました。

 

今回の記事では、

【ソフトウェアのベンダー】に推奨される行動

について見ていきます。

*オリジナルの資料における11~15ページ目に相当する内容です。

 

 

目次

ベンダーへの推奨事項

ソフトウェア開発ライフサイクルの実施と遵守

SDLCにSSDFを導入する

【予防】悪意ある/脆弱なソフトウェアを供給しないために

【緩和】デプロイ済みのものへの対策

【復旧】開発プロセスにおけるレジリエンスを高めるために

最後に:計画とコミュニケーションの大切さ

まとめ

引用・参考資料

 

*資料を引用・要約した部分における太字は、ブログ筆者の手によるものです。読みやすさを向上させる観点で太字としました。

ベンダーへの推奨事項

 

ソフトウェア開発ライフサイクルの実施と遵守

資料によると、CISAはベンダーに対し、ソフトウェア開発ライフサイクル(以下、SDLC)の実施と遵守を推奨しており、ベンダーはこれらを考慮するようになってきているとのことです。(11ページ)

 

他方で、NISTの観点では、ソフトウェアセキュリティの詳細について明確に言及しているSDLCはほとんどなく、このため、通常は各SDLCモデルに安全なソフトウェア開発の習慣を追加する必要がある、といいます。

 

そこで、NISTは白書を公表し、ベンダーのSDLCに安全なソフトウェア開発の枠組み(SSDF:secure software development framework)を追加する上で特に役立つ習慣の一部を提案しています。

 

以下では【予防】・【緩和】・【復旧】のそれぞれの措置を紹介しますが、資料ではこれらの措置に先立って、安全なソフトウェア開発に向けた準備をすることが必須とされています。

 

 

SDLCにSSDFを導入する

上で述べられた「安全なソフトウェア開発」には、以下が含まれるとされています。

 

・ソフトウェア開発においてセキュリティ上必要なものを定義する

・SDLC における SSDF の役割と責任を確立する

・デベロッパーとセキュリティーツールチェーンを自動化する

・セキュリティチェックに必須なデータ収集のためのソフトウェアセキュリティ基準・プロセスを確立する

(12ページ)

 

 

【予防】悪意ある/脆弱なソフトウェアを供給しないために

連邦政府の高価値資産(HVA)へのアプローチを参考にした開発環境

ベンダーは、安全な開発インフラストラクチャの中で SSDF を実施すべきです。ベンダーは、そのようなインフラを SDLC 全体のセキュリティを視野に入れて構築すべきであり、予想される開発活動に対して適切なセキュリティ管理を選択する上でリスクベースの手法をとることが可能です。SSDF の外部において、ベンダーは連邦政府が高価値資産(HVA)に取り組む場合と同じような方法で、ソフトウェア開発環境に取り組んでも良いでしょう。関心を持つベンダーは、以下を行ってください:

 

• 組織全体のHVAガバナンスプログラムを確立する

• HVAの情報システムを特定し、優先順位をつける

• どのシステムがHVAであるかを決定する際に、情報システムの相互接続性と依存性を考慮する

• 緊急性とミッションの重要性に基づいて HVA に優先順位をつけるための方法論を編み出す

• HVA の優先順位付けに基づく評価手法を編み出す

• 特定された脆弱性を、確実にタイミングよく修正する

 

これらの行動に続き、CISA はベンダーに対し、システム・セキュリティ・エンジニアリング・アプローチに従って開発インフラにセキュリティを組み込むことを推奨します。ベンダーは、インフラストラクチャ内の相互依存性と、外部システムとの接続に対する依存性を理解した上で、セキュリティを構築する必要があります。

(12ページ)

 

SSDFを活用した対策

ベンダーは、SSDF を利用することで、悪意のあるソフトウェアコンテンツや脆弱性がサイバーサプライチェーンに入り込むのを防ぐことができます。NISTは、ソフトウェアを保護し、安全性の高いソフトウェアを作成するのに役立つ手法を提案しています。これには次のようなものがあります。

 

• ソフトウェアのセキュリティチェックの基準を定義する(これは開発中のソフトウェアのセキュリティチェックの際に、SDLC の産物であるソフトウェアが、ベンダーの期待に沿ったものになっていることを確認するのに役立つ)

 

• セキュリティ要件を満たし、設計決定(design decisions)によりセキュリティリスクを緩和するソフトウェアを提供する

 

• 不正アクセスや改ざんからコードを保護する

 

•サードパーティ製ソフトウェア(ベンダーコードに組み込まれたライブラリやその他のパッケージなど)が、セキュリティ要件に準拠していることを確認する

 

• 可能であれば、機能を再構築するのではなく、安全性の高い既存のソフトウェアを再利用する(脆弱性が入り込むリスクを減らすため)

 

• 安全なコーディング方法でソースコードを作成する

 

• 内部およびサードパーティ機関でのコードレビュー、分析、テストを実施する

 

• 実行可能なコードのセキュリティを向上させるため、適切に設定されたコンパイルおよびビルドプロセスを使用する

 

• インストール時にデフォルトで安全になっているようにソフトウェアを設定する。例えば:

…ハードコードされたパスワードの使用を避ける

… OSのファイアウォールを有効にする

…最低限必要なサービスのみを「すぐに使えるよう」有効化する

 

• 顧客が購入するソフトウェアが改ざんされていないことを保証するために、ソフトウェアリリースの完全性を検証する仕組み(特にコードサイニング証明書の保護)を提供する

 

これらのアプローチへの取り組み方の詳細については、CISAはベンダーに対し、関連するNISTの刊行物「SSDF導入によるソフトウェア脆弱性リスクの緩和 (原題:Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework [SSDF])」を確認することを推奨しています。

(12~13ページ)

 

さらに導入できる場合は・・・

• 形式手法

— 型検査、正当性の証明、モデルベース開発、そして「Correct by Construction」など、数学や論理に基づくソフトウェア開発や分析の手法です

 

• システムレベルセキュリティ

— 最近のハードウェアとソフトウェアの進歩により、性能とコストの両面で優れた、セキュリティ強化と侵入防止のためのシステムの可能性が高まっています

 

• 追加ソフトウェア分析

— 相乗効果を発揮するために複数の先進的なソフトウェアの検査ツールを協調して使用する上での障害に対処するための包括的方法です

 

• ドメイン特化ソフトウェア開発フレームワーク

— これにより、十分にテストされ、十分に分析されたコードの使用(および再利用)が促進され、その結果、悪用される可能性のある脆弱性の発生を減少させることができます

 

• 移動標的防御(Moving target defenses)とソフトウェアの自動多様化

— ソフトウェアの詳細な構造や属性を自動的に変化させることで、攻撃者が弱点を発見して悪用することを非常に困難にする技術の集まりです。例えばベンダーは、自社、特注コード、オープンソース、および第三者ベンダーから入手したソフトウェアにおける、未確認の脆弱性の影響を抑えるエクスプロイト緩和の技術を導入する場合があります。エクスプロイト緩和の性質は、コード内のリスクに固有の性質と合致させるべきです。

(13ページ)

 

 

【緩和】デプロイ済みのものへの対策

リリース済みソフトウェアのアーカイブと、脆弱性の特定・確認・修正プロセスの確立

(【】内は筆者による注釈です)

・【リリースのアーカイブ】

ソフトウェアの各リリースをアーカイブ化して保護する(リリース後に発見された脆弱性を解消するためのメカニズムをベンダーが分析・特定・開発できるようにするため)

 

・【脆弱性を特定・確認するプロセスやプログラムを維持する】

ソフトウェアの脆弱性の疑いを特定・確認するためのプロセス、さらには正式なプログラムを維持する(脆弱性の特定者がベンダー、顧客、サードパーティの研究者のいずれかに関わりなく)

 

・【脆弱性修正の手法の確立】

脆弱性を迅速に修正できるような評価・優先順位付け・修正の手法を確立する

(13~14ページ)

 

将来のパッチ適用を可能にするソフトウェアを開発する / コンポーネント目録を顧客に提供する

ベンダーは、望ましくないコンテンツを排除するための将来的なパッチ適用を可能にするソフトウェアを開発すべきです。さらに、ソフトウェアを使用する顧客のサポートにおいては、ベンダーはソフトウェアのリリースごとにソフトウェアコンポーネント・インベントリ(ソフトウェア部品表など)を作成し、 顧客に提供すべきです。主な受益者には、サードパーティ製ソフトウェアを自らの成果物に組み込む製品開発者や、技術力の高い顧客が含まれる場合があります。ソフトウェア部品のインベントリを既知の脆弱性と照合できるツールと組み合わせれば、ソフトウェア部品のインベントリは、顧客が新規のソフトウェア、または更新されたソフトウェアを自社環境に導入する前に顧客をサポートすることができます。

(14ページ)

 

脆弱性の公表の仕方も大切 〜 迅速な対策の特定・提供、CVEコミュニティへの届け出

最後に、これまでに指摘した脆弱性の特定と修正の行動習慣に加えて、ベンダーは発見された脆弱性を公表する行動習慣を実施するべきです。この行動習慣には、可能な限り迅速に(理想的には情報開示に先立って、または同時に)脆弱性緩和策を特定し、それを顧客が利用できるようにすること、脆弱性をCVEコミュニティに届け出ること、そして適切な場合には CVE Numbering Authority(CVE採番機関)になることも含めるべきです。

(14ページ)

 

 

【復旧】開発プロセスにおけるレジリエンスを高めるために

ここまで【予防】と【緩和】について、長めに述べてきましたが、【復旧】について述べているセクションは、以下の1段落のみです。

ベンダーは、学んだ教訓とフィードバック・ループを利用して、レジリエンス(回復力)を高めることができます。具体的には、発見された脆弱性を分析し、その根本的な原因を特定することで、ベンダーは SDLC(SSDF含む)を改善するチャンスを正確に特定することができます。これは過去に配布されたソフトウェアの脆弱性を予防または緩和するものではありませんが、継続的な改善プロセスが実施されることから、ベンダーはより安全なコードを作成することが可能になります。

(14ページ)

 

 

最後に:計画とコミュニケーションの大切さ

最後の章では、顧客とベンダーは、独自の取り組みと、協力による取り組みの両方を通じて(ソフトウェアサプライチェーンの)リスクを管理できると指摘されています。

 

また同じ章では、顧客とベンダーはテクニカルなセキュリティ管理を利用してもよいが、強固な計画とコミュニケーションがこの領域のリスク管理の基礎だということを顧客とベンダーは認識すべきだと、述べられています。

 

その上で、改めて顧客側がすることと、ベンダー側がすることについて述べられています。

ベンダーは、自社のソフトウェア設計プランにセキュリティ機能を組み込む必要があります。顧客は、セキュリティ要件をベンダーに伝達することにより、援助を行うことができます。

また、顧客はソフトウェアの購入・配備に関して、リスク情報を活用した意思決定をすべきです。顧客はそのような考察を購入プロセスの中に組み入れることができ、そしてベンダーの SDLC の習慣に基づいてソフトウェアを選択することができます。顧客はそういった習慣を要求すべきであり、ベンダーはこれを公表すべきです。他方でベンダーは、自社のソフトウェアに関する技術的な詳細情報を利用可能にしておく必要があります。想定されるソフトウェアの振る舞い(外部通信の周期、外部通信に用いられるポートやプロトコル、通信に使用されると予想されるIPアドレスの範囲やドメインなど)を理解していれば、顧客はそういった接続のみを許可し、逸脱を監視するコントロールを実装することができます。

(15ページ)

 

これに続く文章では顧客・ベンダーによる【緩和】の必要性に再び触れられ、ソフトウェアコンポーネントの目録が顧客の役に立つということが述べられ、最後は参考資料へのリンクで資料が締め括られています。

 

 

まとめ

ここまで、【ソフトウェアのベンダー】に推奨される行動について見てきました。

3回にわたってソフトウェアサプライチェーン攻撃について見てきましたが、これでシリーズは最後です。

参考までに以下、資料のリンクを掲載しましたので、
お時間のある方は、ぜひ英語原文もご参照ください。

なお、前回/前々回の記事では、攻撃の概要(定義・事例・攻撃手法)や、ユーザーに推奨される行動についてもまとめていますので、もしよろしければご覧いただければ幸いです。

 

引用・参考資料

CISA : Defending Against Software Supply Chain Attacks
(Publication: April 2021)

*掲載サイト: https://www.cisa.gov/publication/software-supply-chain-attacks

*PDF : https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508.pdf

 

 

*1) 12月は、SolarWinds社がインシデントを公表した時期であり、後に同社が発表したところによると攻撃プロセス自体は2019年9月から始まっていたという(以下サイト参照)。

SolarWinds 公式サイト:New Findings From Our Investigation of SUNBURST (2021年1月11日付)

https://orangematter.solarwinds.com/2021/01/11/new-findings-from-our-investigation-of-sunburst/

 

*2)

・メルカリ公式サイト:「Codecov」への第三者からの不正アクセスによる当社への影響および一部顧客情報等の流出について
https://about.mercari.com/press/news/articles/20210521_incident_report/

・infosecurity : “Codecov Supply Chain Attack May Hit Thousands: Report”
(訳:「Codecov」のサプライチェーン攻撃 影響は数千のネットワークに及ぶ可能性)
https://www.infosecurity-magazine.com/news/codecov-supply-chain-attack-may/