WP29 CSMSに基づくセキュアな製品開発の実践―脆弱性テスト／ペネトレーションテストの実践とポイント

WP29 CSMS（※1）に対応する製品開発実践のポイントを紹介する連載「WP29 CSMSに基づくセキュアな製品開発実践」。第4回は開発の最後に実施する「脆弱性テスト」と「ペネトレーションテスト」に焦点を当てます。第3回までは「どのくらいの脅威があるのか」「それを防ぐにはどうすればよいか」を体系立てて考えるという防御側の視点をご紹介しました。一方、脆弱性テストやペネトレーションテストは「相手の隙を突いて攻撃する」という攻撃者側の視点に立って考える必要があります。攻撃者有利と言われているサイバーセキュリティの世界において、「攻撃者視点で製品の脆弱性をテストする」ことは、堅牢な製品をリリースする上で重要なプロセスになります。

※1 CSMS（Cyber Security Management System）：サイバーセキュリティに関連するリスクを処理し、自動車をサイバー攻撃から保護するための組織的なプロセス、責任及び管理を明確化したリスクベースアプローチの管理システム。

「検証」と「妥当性の確認」の違いとは

開発の最終ステップで行うセキュリティ関連のテストには、「検証」と「妥当性の確認」という2つの目的があります。

「検証」では、開発の上流工程で実施した脅威分析や、セキュア設計などに基づいた対策が適切に実施されているかを評価します。診断項目は「要件定義時に定義した○○を実施すること」「ソフトウェア設計／ハードウェア設計で実施した××を導入すること」という過去の検討結果を集約して作成します。

一方、「妥当性の確認」では、想定される脅威（攻撃）を“目標”として設定し、それが達成できてしまうかどうかを確認します。その確認手段には「脆弱性診断」と「ペネトレーションテスト」の2つがあります。

セキュリティテストには検証と妥当性確認があり、どちらもセキュア開発において必要になります。

「脆弱性診断」では、オープンソースソフトウェアの既知の脆弱性といった、想定される脅威に対してツールを用いて検証します。脆弱性診断は上流工程で想定した脅威に対し、対策状況を網羅的に評価できるというメリットがあります。ただし、上流工程で想定していない脅威に対しては、対策状況を評価できないというデメリットもあります。

一方、「ペネトレーションテスト」はあらゆる手法を駆使して攻撃し、実機に対して侵入を試みるテストです。同テストは上流工程で想定していなかった脅威に対する評価や、上流工程で検討した結果自体の評価ができるメリットがあります。反面、網羅性を説明することが困難であったり、各テスト項目が脆弱性診断と重複する可能性があったりするデメリットもあります。なお、同テストは製品の持つ機能特性や条件を組み合わせて実施することが推奨されています。

検証は開発の上流工程で実施した脅威分析、セキュア設計等に基づいた対策が適切に実施されているかを評価するテストです。

では、ペネトレーションテストを第三者に委託して実施する場合には、どのようなスケジュールで行うべきでしょうか。

下の図は実施スケジュールとタスクの例です。ここで注目したいのは、各タスクの「矢羽根の長さ（期間の長さ）」ではなく、テストを実施するベンダーと製品のテストを依頼したメーカーの関係性です。

製品のセキュリティレベルを担保する上でテストは重要であり、外部ベンダーに依頼すれば終わりというわけではありません。メーカー側はテスト要件の整合性を取る段階で、テスト項目やペネトレーションテストの手法などについてベンダー側と話し合う必要があります。

特にペネトレーションテストの目標は「ここまで設定すればよい」という基準がなく、際限なく実施できてしまいます。そのため、「何を目的にして」「どこまで実施するか」をメーカー側と外部ベンダー側で合意し、明確にする必要があります。

ペネトレーションテストで多用されているのは、業界で認知された標準テストやガイドラインに定義された項目に基づいて評価を決めるやり方です。例えば新製品をリリースする際には、リスクの高い機能やインタフェースを評価することはもちろん、ハッカーのように予測不可能な手段による攻撃や、一定時間継続的に攻撃をして耐性があるかというテストも実施する必要があります。こうしたテストは、複数のアプローチを組み合わせて実施することが重要です。

ペネトレーションテストは際限なく実施できるため、スコープを定義することが重要です。

4回にわたりセキュアな製品開発の実践ポイントを紹介してきましたが、いかがだったでしょうか。WP29 サイバーセキュリティ法規は2022年7月から順次法規制対応が義務付けられています。PwCが2021年6月にOEM40名とサプライヤー61名を対象に調査したところ、OEMでは80％がCSMS対応に着手していると回答しましたが、サプライヤーで着手しているのは49％にとどまっています。

対応が遅れている背景には、2022年7月から法規制が適用されるのは、無線によるアップデート機能を持った新車だけであることも一因として挙げられます。しかし、将来的なことを考えれば、準備は待ったなしの状態です。特にプロセス認証のために社内体制の整備を推進してきたOEMは、より実践的な現場での作業が必要になることは間違いありません。そうした意味においても、開発プロセスの最初と最後を担う「分析と検証」は重要であると言えます。

多くの企業がどこまでやればよいのかといった「相場観」を試行錯誤しながら見極めている状態です。今後の鍵はどのように情報を収集するかでしょう。監査が始まっていない現状では、こうした手探りの状況がしばらく続くと推測されます。

WP29対応への素朴な質問

【質問】

ペネトレーションテストを行うタイミングは、量産が開始される直前の開発終了間際になると思います。実際問題として、この段階でテストすることは困難であると考えますが、ペネトレーションテストは必須でしょうか。実施基準などはあるのでしょうか。

【回答】

現場で働く多くの方が、同じような疑問を抱えていると拝察します。量産直前の段階でなければ、ペネトレーションテストを実施するためのコンポーネントは揃っていません。また、量産直前の段階において、ハッカーによる攻撃を想定した網羅的な検証を実施する時間がないことは、現在の開発プロセスでは大きな課題として捉える必要があります。

「ペネトレーションテストは必須なのか」という問いに対する端的な回答は、「必須ではありません。ただし、“やらない根拠”と“やる根拠”をエビデンスとして正確に残すことが重要です」となります。

製品の妥当性やセキュリティレベルの検証は脆弱性検査でも可能であり、必ずしもペネトレーションテストをしなければならないわけではありません。ただし、「時間がないのでペネトレーションテストをしませんでした」という理由は、検証の根拠になりません。「なぜペネトレーションテストを実施するのか／しないのか」の根拠は、明確にする必要があります。

WP29 CSMS対応ツール活用メリットを2分で解説

自動車に関する国際法規であるWP29 UNR155に適合するため、車両OEMとサプライヤーは、適切なサイバーセキュリティ要件を導出し、それを満たす製品を開発することが求められています。PwCが提供する「WP29 Cyber Security Management System（CSMS）支援プラットフォーム」は、セキュアな製品開発において最も重要である脅威分析を効率的に実施するためのウェブツールであり、脅威や攻撃に関する最新の情報を提供します。

詳細はこちら

車両サイバーセキュリティの未来

車両のデジタル革命によって、次世代のモビリティ社会が形作られる一方で、各国の政策や規制により変化の速度が決定されている面があります。その要因の一つがサイバーセキュリティへの懸念です。
車両サイバーセキュリティに関する国際規格や製品ライフサイクルにおける重要論点の解説やクライアントとの対談を通じ、車両サイバーセキュリティの将来をひもときます。

詳細はこちら