適用開始はしたのにUPDATEが久しくない -UN-R155-

時が経つのは早いとしか表現のしようがありませんが、前回記事がおよそ9ヶ月前のこちら。。。

言い訳にしかなりませんが、こちらで主に取り上げてきたUN-R155、つまりはCSMSに関し、世の中で大きなUPDATEがこの間なかったのです。

この間も一応WP29、自動車基準調和世界フォーラムは追いかけております。記事にしたのが187回目でしたが、

以降188回、189回と開催済ではあります。が、議事録を読んでもUN-R155に関するUPDATEは見当たらず、が現状です。

(さらに言うならば、ぜひ「UN-R155」「CSMS」等の用語で検索してみて下さい。見たことあるページしかヒットしません。。。)

しかし、しかしです。次回、190回のAgendaを見るとUN-R155に関するUPDATEを予感させる記載が既にあります。

同じくジュネーブで開催される190回目のWP29、自動車基準調和世界フォーラムは2023/6/20からの開催予定となっておりますので、今度こそ当ブログで取り上げるべきUPDATEがあらんことを。。。

いつの間にか2022/7はやって来ていた -UN-R155/UN-R156の適用開始-

あまり日経新聞で取り上げられることのない、サイバーセキュリティのマニアックな情報ですが、今回の2022年7月適用開始の件については記事になっていたので、取り上げようと思います。

まずは、わかりやすい図がありましたのでそのまま拝借します。

https://www.nikkei.com/article/DGXZQOUC101610Q2A810C2000000/

当ブログを見て下さってる方にはいまさらですが、OTAによるオンラインでのソフトウエア更新機能を備えた新車に対し、CSMS/SUMSの各プロセスに基づいた認証が必要となります。規制車種は少しずつ拡大し、26年には発売済の車も含め全車種が対象となる見通しです。

審査の期間についてまとめてくれていたので、そのまま引用しますが、

審査自体の負担も増す。安全装置などの審査では車種ごとの型式審査に6週間程度かかるのが通例だ。新規制では型式審査の前にメーカーの組織体制が基準に見合うものかの審査に2カ月程度かかる。組織の審査は毎回行う必要は無いが、3年ごとに更新が必要だ。

わたしが普段お世話になっている自動車OEMでも今後新車が出る予定がありますが、OTAを使っているのか定かではなく、今度聞いてみようと思います。ただ、CSMSやSUMSが整備されたとは聞いてないので、まだ適用範囲外かもしれませんが。

ふとUN-R155 7.2.2節が加筆されていたことに気付く

前回の記事で186回目のWP29、自動車基準調和世界フォーラムがスイスのジュネーブで開催されたことをお伝えしました。

187回目のWP29も同じくスイスのジュネーブで6/21より開催されたようで、今回はそこでのUPDATEを見ていきたいと思います。

https://unece.org/info/events/event/366142

7.2.2.2節の追加要件

当ブログを始めた頃、CS Regulation(UN-R155)の7.2.2.2節に着目して2つの記事を書きました。

今回の報告書を見ている中で、新たに挿入されていた節を見つけることができたので、その点に触れていきたいと思います。実際にはだいぶ前に追加されたと思われますが、MONOistなど、どこにも取り上げられていなかったため、気付くのが遅れました。

上記2つの記事を書いた頃には、7.2.2.2節には(a)-(g)の7つの要件が記載されていましたが、8つ目の(h)が追記されていました。原文は以下の通りです。

The processes used to provide relevant data to support analysis of attempted or
successful cyber-attacks

失敗に終わった、もしくは残念ながら被害が出てしまったサイバー攻撃の分析をサポートするため、関連データを提供するプロセスが必要である旨、追加されたようです。脆弱性が見つかった場合、もしくは実際にインシデントが発生してしまった場合に、どの情報をどういった手順で分析担当へ提供するのかについて、明らかにしておきなさい、ということでしょう。(a)-(g)では、組織としてどうあるべきか、リスクをどのように特定するのか、そのリスクをどう評価するのか、それらを最新に保つには、監視・検出・対応はどうすべきか、といったプロセスに対する要件が語られていましたが、最新版ではそのプロセスを通る、情報・データの流れについての要件が追加されていると考えられます。PSIRT(Product Security Incident Response Team)をより強固なものにするためにもデータの流れを定義しておくことは理にかなっていますね。

7.2.2.3節と7.2.2.4節

新しく見つけたこの2つ。まずは7.2.2.3節の原文を見てみましょう。

The vehicle manufacturer shall demonstrate that the processes used within their
Cyber Security Management System will ensure that, based on categorization
referred to in paragraph 7.2.2.2. (c) and 7.2.2.2. (g), cyber threats and
vulnerabilities which require a response from the vehicle manufacturer shall be
mitigated within a reasonable timeframe.

7.2.2.2節(c)と(g)ではリスクや実際の攻撃、脆弱性等に対応するプロセスへの要件が述べられていましたが、ここではその対応プロセスが合理的な時間内で行われることが求められているように読めます。続く説明文では、リスクの分類結果から対応時間のリミットを決めるプロセスが確立されていること、と補足されています。timeframeという単語がしきりに使われていますが、OEMが設定するtimeframeは正しく説明できる必要がある、とも記載されています。つまりは、いくらプロセスが精緻に定義されていても、あまりに時間がかかり過ぎるのはダメよ、ということでしょうか。ごもっともですね。

次に7.2.2.4節です。

The vehicle manufacturer shall demonstrate that the processes used within their
Cyber Security Management System will ensure that the monitoring referred
to in paragraph 7.2.2.2. (g) shall be continual. This shall:

  1. Include vehicles after first registration in the monitoring;
  2. Include the capability to analyse and detect cyber threats, vulnerabilities and
    cyber-attacks from vehicle data and vehicle logs. This capability shall respect paragraph 1.3. and the privacy rights of car owners or drivers, particularly with respect to consent.

ここではCSMSで利用されているプロセスにより、監視が継続的なものであることが求められているようです。続く説明文では、サイバー攻撃や脅威、型式毎の脆弱性を監視するプロセスが継続的であり、監視対象である全ての登録車両に対応できることを保証すること、とあります。つまりは、監視活動が寸断されることなく、全ての車両に行き届いていること、と解釈できますね。

尚、今まで当ブログでは7.2.2.3節に位置づけていたOEMサプライヤー間の連携に関する要件は、7.2.2.5節に移動してました。

最後に、今回のようにまだまだCSMSもSUMSも変遷があると思いますので、わたし自身もcontinualに情報を追いかけねばと改めて思った次第です。