改めてISO/SAE 21434に思いを巡らせる

最近はテュフ社の連載を見ています

前々回からテュフ ラインランド ジャパン株式会社のサービスや連載記事について見てきました。

今回もテュフ社の連載記事を基にしつつ考えていきたいと思います。というわけで今回はこちら↓。

前回記事の流れを受けて、ISO/SAE 21434とCSMS要件との相違点の深堀りやそれに向けた対策が書かれていると期待したのですが、連載としてはいまいち内容に一貫性がなく、前回からの流れは受けず主に以下3点について書かれていました。

  • ISO/SAE 21434とは
  • サイバーセキュリティ目標 - コンセプトフェーズの重要性
  • マネジメントシステム(仕組み・手法)体制構築とプロセス

おさらいになってしまう部分もありますが、当ブログはゆっくりと論理的に数学の証明のような1ステップずつ進めていくことをモットーにしているので、これまでの記事との重複は気にしません。

改めてISO/SAE 21434を考える

さっそくISO/SAE 21434からおさらいしましょう。当ブログで初めて記載したのは下記だったと思います。

その際も説明を端折ってきた部分がありましたので、ちょうど良い機会です。わたしが調べた限りでは最もわかりやすく説明されていた、ニュートンコンサルティング株式会社のコラムから引用します。

ISO/SAE21434は、近年増加傾向にあるコネクテッドカーなど、外部ネットワークに接続されることによりサイバー攻撃の脅威にさらされることになった、車両のサイバーセキュリティに関する国際標準規格です。

章立てについても見てみましょう。

ISO/SAE21434は15章構成となっており、大きく分けて7つのフェーズに分かれています。 ここで1章から4章は、本国際標準規格のスコープ、参考文献、用語の定義、考慮事項が記載されており、5章から15章がサイバーセキュリティに関する内容となります。

f:id:rugbyfp91:20210301152505j:plain

以下、参考までに各フェーズについて詳述してみます。ニュートンコンサルティング社のHPに加え、pwc社のHP*1も参考にさせていただきました。

フェーズ1(5章、6章)では、車両のサイバーセキュリティ確保を目的とした組織体制、ガバナンス、ポリシー策定、監査、教育・文化醸成、情報共有体制の整備、品質管理システムといった全社的なサイバーセキュリティ活動基盤が求められます。またそれらを開発プロジェクトレベルで具体化し、サイバーセキュリティ計画として実施すべき工程と成果物を定義します。

フェーズ2(7章)では、車両のサイバーセキュリティに影響を与え得る情報を継続的に収集/トリアージ/分析/対応することを定義します。開発時において収集した情報を適切に設計へフィードバックするためのプロセスも求められています。

フェーズ3(8章)では、車両のサイバーセキュリティリスクを評価する方法を定義します。

フェーズ4(9章)では、コンセプトレベルでのリスクアセスメント(脅威分析)を行い、対応すべきリスクを洗い出し、以降の活動の起点となるサイバーセキュリティの目標(サイバーセキュリティゴール)を定義します。

フェーズ5(10章、11章)では、コンセプトフェーズの成果をもとに、特定の設計/実装内容、また設計/実装を通じて顕在化する脆弱性にも考慮したリスクアセスメントを通し、リスクおよびセキュリティ要求を具体化します。10章「製品開発」は、サイバーセキュリティの仕様を定義し、アイテムまたはコンポーネントに固有のサイバーセキュリティ要件を検証し実装します。11章「サイバーセキュリティの検証」は、各種セキュリティテストの手法によりセキュリティ要件が満たされていることを確認し、合わせてセキュリティ要件そのものが適切に設定されていることの妥当性を確認します。

フェーズ6(12章、13章、14章)では、車両の製造から販売後の運用と保守、そして廃棄までのフェーズについて記載しています。製造フェーズにおいては、工場全体のセキュリティ確保が求められます。運用/保守フェーズにおいては、サイバーセキュリティ発生時のインシデント対応とソフトウェアアップデートに関連する活動について説明しています。廃棄フェーズでは、車載器に登録されたセキュリティや利用者に関する情報の適切な削除ができることが求められます。こうした生産/運用・保守/廃棄時に求められるセキュリティ機能や運用については、後から追加・変更することが難しいため、製品開発フェーズからセキュリティ要件として考慮される必要があります。

フェーズ7(15章)では、サプライチェーンの観点から、Tier1やTier2等のサプライヤーに求められるサイバーセキュリティの対応、見積もりを依頼する際のサイバーセキュリティに関する要件、責任範囲、活動等について定義されています。OEM観点からはサプライヤーの能力評価や受け入れ基準の定義、選定プロセスの整備、サプライヤー観点ではOEMのセキュリティ要求を理解・整合し、自社のサイバーセキュリティ能力を実証することが求められます。

とまあ、細々としてきてしまいましたが、アプリオリに理解できる部分が多いですし、章立てや各項目の内容は必要時に参照する程度で良いのかと思います。

同じ対象を見ているとしても、見る人によって表現の仕方は変わってくるもので、当ブログにおいては様々な会社様の言い方・描き方を紹介してきていますが、ここで連載記事に戻ってテュフ社の表現も見てみましょう。

f:id:rugbyfp91:20210301163103p:plain

https://insights.tuv.com/jpblog/iso21434

これまでフェーズと呼んでいたものをテュフ社では要求領域としているようです。またこの表においては、ISO/SAE 21434の要求領域とUN-R155の主要成果物、そしてCSMS要求との関連を示しています。当ブログでは何度も触れてきていますが、ISO/SAE 21434がCSMS認証取得対策のガイドラインとして有益である、という点をテュフ社としてもここで言いたいようです。

記事で紹介されていた3点の内、今回は1点目のISO/SAE 21434のおさらいに特化してみました。次回は残り2点を見ていきたいと思います。フェーズ4 コンセプトフェーズのアウトプット導出方法が記載されているようです。