"CAPEC攻撃パターン"を活用したサプライチェーンセキュリティ(2023/6/16)

2023年06月16日 10:00 (JST)

"CAPEC攻撃パターン"を活用したサプライチェーンセキュリティ

こんにちは、ディフェンシブセキュリティ部の小林です。
今やビジネスに関係する以上、誰もがセキュリティ対策を求められる時代です。一方で「何のための対策なのか理解できない」、「どこに対策すべきなのか分からない」といった戸惑いの声や不安の声をお客様からも根強く伺っています。

そのため、本稿では、企業のサイバーセキュリティ対策を担当されている方に向けて、この課題の解消に役立つ「CAPEC」と、その活用例を紹介します。

CAPECとは”Common Attack Pattern Enumeration and Classification”の略で、「共通攻撃パターンの列挙と分類」と直訳でき、CVEの採番やATT&CKの公開などで知られる米国の非営利組織であるMITRE社によって運営されている公開情報です。

その目的は「攻撃パターンを理解することで脆弱な箇所を特定し、より効果的な防御策を取ること」です。

本稿ではCAPECを活用することで、深刻化する「サプライチェーンリスク」に対して「攻撃者目線」を用いてセキュリティ対策を講じてゆく、その過程を説明します。

[出典]　MITRE、CAPEC、https://capec.mitre.org/index.html

サプライチェーンを狙った間接的および段階的なサイバー攻撃が深刻化しています。

この状況に対して、取引先や委託先、国内外の子会社等ではより強固なセキュリティ対策が求められるようになっており、ITライフサイクルにおける企画・設計といった上流工程からセキュリティ対策の必要性は一層高まっています。

表1.サプライチェーンに対する組織に対する脅威の高まり

順位	脅威
1位	ランサムウェアによる被害
2位	サプライチェーンの弱点を悪用した攻撃
3位	標的型攻撃による機密情報の窃取
4位	内部不正による情報漏えい
5位	テレワーク等のニューノーマルな働き方を狙った攻撃
6位	修正プログラムの公開前を狙う攻撃（ゼロディ攻撃）
7位	ビジネスメール詐欺による金銭被害
8位	脆弱性対策の公開に伴う悪用増加
9位	不注意による情報漏えい等の被害
10位	犯罪のビジネス化（アンダーグラウンドサービス）

[出典] IPA、情報セキュリティ10大脅威2023
https://www.ipa.go.jp/security/10threats/10threats2023.html

サイバー攻撃のリスクが高まっていることは事実ですが、手がかりがないままの、やみくもな対応は多くの混乱を招きます。本稿では「どんな攻撃があるのか」を知るところから、セキュリティ対策の検討を進めます。

企業風土やシステム環境によってセキュリティ対策は千差万別となり得ますが、「脅威の理解」は企業防衛を行う上での重要な共通認識です。

しかしながら、サイバーセキュリティに関する意思決定のほとんどは「攻撃者についての洞察を得ることなく行っている」というのが実情です。

図1　サイバーセキュリティに関する意思決定について

[出典]　Mandiant、グローバルな視点から見た脅威インテリジェンス、https://www.mandiant.jp/resources/blog/global-perspectives-threat-intelligence

CAPECにはv3.9時点で559もの攻撃パターンが掲載され、攻撃パターンの追加と更新が順次行われています。これらの膨大な数から必要とする情報に辿りつくためには、主に「ビュー」を用います。
ビューには大きく3つの区分があり、その中からさらに項目を選択する形で目的に沿った情報を読み取っていきます。

図2 CAPECのビュー区分

[出典] MITRE、CAPEC
https://capec.mitre.org/index.html

ビューのうち「サプライチェーンリスク」では、ITライフサイクルの各段階についての攻撃パターンと緩和策が掲載されています。

本稿では上流工程のうち「企画・設計」を対象としてCAPECの活用例を解説します。

図3　CAPEC活用例の対象スコープ

企画・設計では6つの攻撃パターンが定義されています。それぞれの攻撃概要と被害事例（理論上の事例を含む）は以下の通りです。

表2　企画・設計に対する主要な攻撃パターンと被害事例

No	攻撃パターン	被害事例（理論上の事例を含む）
1	機能制限を回避するためのドキュメント改ざん	輸出制限があるシステムにて製造要件が変更される。これにより、製造時に制限または削除されるべき機能が制限・削除されず含まれたままとなる。
2	システムの品質を落とすためのドキュメント改ざん	暗号化保護されているシステムにて暗号化の有効化要件が変更される。これにより、特定状況で暗号化が無効となる。
3	システム設計に誤りを引き起こすためのドキュメント改ざん	依存関係を含むルールが構成されているシステムにて依存要件が変更される。これにより、特定状況でルールの読み込みと適用に失敗する。
4	ハードウェア設計仕様の改ざん	高度処理を実行するハードウェアにてCPU要件が変更される。これにより、処理遅延や処理情報のドロップが発生する。
5	ASIC要件の改ざん	特定顧客向けのASICにて機能要件が変更される。これにより、悪意のある機能の混入や意図しない動作が発生する。
6	FPGA設計の改ざん	組織内で変更されるFPGAにて構成要件が変更される。これにより、悪意のある機能の混入や意図しない動作が発生する。

[出典] MITRE、CAPEC
https://capec.mitre.org/index.html

企画・設計での攻撃パターンに対する緩和策は以下の通りです。
本稿は業種を限定せずにCAPEC活用を目指した解説とするため、集積回路の取り扱いに特化した5.「ASIC要件の改ざん」と6.「FPGA設計の改ざん」の対応策は割愛します。

表3　攻撃パターン1~4に共通する緩和策

No	緩和策
a	文書を電子化・電子署名して真偽を確認する
b	文書をパスワードで保護して、編集権限のないユーザーは読み取り専用にする
c	重要な文書や設定はメールで送信することは避ける
d	削除したファイルが実際に削除されたことを確認する
e	復旧・検証のため文書のバックアップを保持する

表4　攻撃パターン2と4に追加する緩和策

No	緩和策
f	システム構成情報と通常の知るべき情報は分離する

[出典] MITRE、CAPEC
https://capec.mitre.org/index.html

CAPECの緩和策は既存のガイドライン等と関連付けることで、解像度を高めることができ、より具体的な実践につなげやすくなります。

本稿では例として、「政府機関等の対策基準策定のためのガイドライン」との関連付けを行っていますが、自組織のガイドラインや特定業種向けのガイドラインと関連付けることもお勧めできます。

表5　政府機関等の対策基準策定のためのガイドラインとの関連付け

緩和策	ガイドライン内容 （緩和策に応じて一部改変）	参照箇所
a.文書を電子化・電子署名して真偽を確認する	電子化・電子署名・真偽確認の手順を整備する	基本対策事項 3.1.1(1)-1
	電子化した文書に格付及び取扱制限を明記する	基本対策事項 3.1.1(1)-2
	電子化・複製は業務上で必要最小限の範囲のみ実施する	基本対策事項 3.1.1(4)-1
b.文書をパスワードで保護して、編集権限のないユーザーは読み取り専用にする	管理者権限などの特権は業務上で必要最小限の権限のみ付与する	基本対策事項 6.1.3(1)-1
c.重要な文書や設定はメールで送信することは避ける	複数の情報に分割し、それぞれ異なる経路及び手段を用いて授受する	基本対策事項 3.1.1(6)-2
	セキュリティが十分確保されたオンラインストレージ環境を利用する	基本対策事項 3.1.1(6)-3
d.削除したファイルが実際に削除されたことを確認する	情報の抹消方法及び履行状況の確認手段について手順を整備する	基本対策事項 3.1.1(7)-1
	情報の抹消を外部委託する場合は抹消の証明書等で履行状況を確認する	遵守事項解説 3.1.1(7)(b)
e.復旧・検証のため文書のバックアップを保持する	災害等により生ずる業務上の支障を考慮し、適切な保管場所を選定する	基本対策事項 3.1.1(8)-2
f.システム構成情報と通常の知るべき情報は分離する	分離の範囲は関係者の意見を付し、情報の格付及び取扱制限などを確認して行う	基本対策事項 3.1.1(4)-1

[出典] 内閣サイバーセキュリティセンター、政府機関等の対策基準策定のためのガイドライン、https://www.nisc.go.jp/policy/group/general/kijun.html

CAPECでは緩和策の実施主体は示されていません。そのため、サプライチェーンにおいてどの組織が責任をもって緩和策を実施するかは、業務内容などを鑑みながら都度判断する必要があります。

本稿では例として、発注元（顧客）、元請（親会社）、下請（子会社）という関係性の下で企画・設計に関連する業務を想定し、緩和策の責任分担を行っています。

表6　サプライチェーンにおける緩和策の責任分担

　 　　 　　　 　　　 　　　 　　 　　 　　　 　　　 　　　 　　 　　 　　　　 　　　　 　　　　 　　 　　

発注元（顧客）が所掌する 業務内容	元請（親会社） が所掌する 業務内容	下請（子会社） が所掌する 業務内容
1.要件を取りまとめて元請に業務委託する 2.要件は一部紙面を交えて提示する	1.要件を受領し、全体の企画・設計を実施する 2.システム領域を切り出し、下請に業務委託する	1.システム領域の企画・設計を実施する
緩和策の責任範囲	緩和策の責任範囲	緩和策の責任範囲
c.重要な文書や設定はメールで送信することは避ける e.復旧・検証のため文書のバックアップを保持する	a.文書を電子化・電子署名して真偽を確認する b.文書をパスワードで保護して、編集権限のないユーザーには読み取り専用にする c.重要な文書や設定はメールで送信することは避ける d.削除したファイルが実際に削除されたことを確認する e.復旧・検証のため文書のバックアップを保持する f.システム構成情報と通常の知るべき情報は分離する	b.文書をパスワードで保護して、編集権限のないユーザーには読み取り専用にする c.重要な文書や設定はメールで送信することは避ける d.削除したファイルが実際に削除されたことを確認する e.復旧・検証のため文書のバックアップを保持する

CAPECの活用により、「ソフトウェア開発を行っている」、「ハードウェアを保持している」、等の大まかな状況さえ分かっていれば、攻撃パターンを洗い出すことができます。
本稿での活用例の以外では、既に脅威分析を行っている場合は、「脅威観点の抜け漏れ確認」などが考えられます。

CAPECの活用だけでは、攻撃活動のライフサイクルに伴う攻撃推移や攻撃経路の推定はできません。CAPECにて洗い出した攻撃パターンがどのような経路でどのように進行していくかを考察する場合はATT＆CK等の併用が必要です。

このほか、CAPECだけではできないことの例は以下の通りです。

（例1）攻撃パターンが自組織にとってどの程度脅威であるかの判断
（例2）法令や業界基準に沿っているかどうかの確認

「攻撃パターンに対する緩和策」をチェックリスト化しました。

企画・設計での簡易的なサプライチェーン・セキュリティチェックにお役立てください。

企画・設計におけるサプライチェーン・セキュリティ対策の簡易チェック

No.	確認内容	確認結果
確認1	・重要な文書は電子化しているか ・真偽確認が必要な文書には電子署名しているか
確認2	・文書をパスワードで保護しているか ・編集権限のないユーザーには読み取り権限のみ付与しているか
確認3	・重要な文書や設定はメール以外でやり取りしているか
確認4	・削除した文書が実際に削除されたことを確認しているか
確認5	・復旧、検証のため文書のバックアップを保持しているか
確認6	・システム構成情報と通常の知るべき情報は分離しているか

今回は「CAPEC攻撃パターンを活用したサプライチェーンセキュリティ」と題して、「企画・設計」での活用例を紹介しました。CAPECの膨大な情報量や幅広い活用シーンはセキュリティ対策を進めるうえで非常に心強い存在ですが、実際に自組織や関係組織に適用してゆくためには一工夫が必要となりますので、本稿の活用例が役立てば幸いです。

弊社では、セキュリティに特化した様々なエンジニアが在籍しております。お困りの際は、是非お気軽にご相談ください。

※本稿はCAPEC公開の英文についての非公式翻訳を含んでいます。
※翻訳文と英文との差については英文が優先されます。
※当社は翻訳文への責任を持ちません。