SUMSの運用は容易ではないことに気付かされる -RXSWINとは-
はじめに
サイバーセキュリティに関してWP29で検討されているWP29 CS Regulations(UN-R155)を見てきたのと同様に、今回はソフトウェアアップデートについてWP29 SU Regulations(UN-R156)の中身を見ていきたいと思います。前回最後に触れた通り、今回もMONOist記事を参照しながら勧めます。
大きくは7.1節 SU Management System(SUMS)への要件、7.2節 SU機能を含む車両型式の要件となるようです。
7.1節 SU Management System(SUMS)への要件
まずは7.1節から見ていきましょう。
中身に入る前にまた1つ難しそうな用語が出てきます。RXSWIN(Regulation x に対する Software Identification Number)というものです。型式認証を受けた車載システムにインストールされたソフトウェアのバージョン情報を集約し管理する概念として考案された、とのことです。なんだかなあ、という感じもしますが、pwcさんのHPに具体例が書かれていましたので、そちらを見ながら解釈してみます。
この例では、とあるRegulation No.Xに該当する車載用ECU(Electronic Control Unit)、例えばUN規則におけるUN 89(速度制限装置)の認可取得が必要となる車間距離制御システムを想像しましょう。(あくまで考え方の事例であり、申し訳ありませんが、実際にUN 89が該当するかどうかは確証がありません。参考までに。)*1
そんな車間距離制御システムが2つのECUからなっていたとし、各ECUが2つのマイコン(MCU)を含んでいるものとします。あくまで車間距離制御システムとしてUN 89の認可取得をしているため、1つのマイコンにソフトウェアアップデートの必要が出た場合でも、改めてシステム全体として認可取得を行う必要がある、そのために前回のバージョンの識別子とアップデート後の最新版の識別子が必要となり、それをSWIN(Software Identification Number)として採番し管理できるようにする、と理解しました。(図ではECU2のマイコン2のバージョンがアップデートされたことによりSWINを新規採番しています。)
そしてこのRXSWINを利用しソフトウェアアップデート前後のバージョンを管理することで、車両一台一台について、実際に搭載されているソフトウェアのバージョンが何なのか確認できることとなり、7.1.1.2節から7.1.1.4節の要件を満たすことができます。
※RXSWINについては下記に詳細を記載してます。
7.1.1.5節から7.1.1.7節では、更新対象のシステムと他のシステムの依存関係や、更新対象車両の特定、更新前後の互換性を確認するプロセスが求められています。
7.1.1.8節と7.1.1.10節は、ソフトウェアアップデートによって変化する機能や性能、パラメータの有無を確認し、車両型式や安全への影響を評価するプロセスが求められています。7.1.1.11節は、車両のユーザーがソフトウェアアップデートについて通知を受けるプロセスが求められています。
概観としては以上で充分だと思いますが、詳細を参考までに記載しておきます。
-
7.1.1節 認証機関/技術サービスによって検証されるプロセス
7.1.1.1節 この規則に関連する情報が文書化され、OEMによって安全に管理され、認証機関もしくは技術サービスからの要求によって利用できるプロセス。
7.1.1.2節 完全性検証データと型式認証済みシステムのHWコンポーネントを含む初期および更新SWのバージョンに関する情報を一意に識別できるプロセス。
7.1.1.3節 RXSWINに関する情報の参照や更新を行えるようにするプロセス。各RXSWINに関連する全てのSW、SWバージョン、その完全性検証データに関する情報を更新する機能が含まれる。
7.1.1.4節 システムに搭載されているSWバージョンと、RXSWINとして登録されている情報が一致していることを確認できるプロセス。
7.1.1.5節 更新されるシステムと他のシステムとの依存関係を識別できるプロセス。
7.1.1.6節 OEMが、SUの対象となる車両を特定できるプロセス。
7.1.1.7節 対象車両の更新前後のHW／SW構成の互換性を検証するプロセス。
7.1.1.8節 認証済みシステムに対して、影響を与えるかを評価し、識別し、記録するプロセス。これはSUにより、影響を与える可能性のあるシステムの特定や、法規に関連するパラメータの変更を伴うかなどに配慮する。
7.1.1.9節 SUによって追加、変更、有効化される機能、または法令で規定されているパラメータもしくは機能の変更、無効化を評価、識別、記録するプロセス。評価は、次の事項を考慮すること。（a）関連する情報の更新（b）テスト結果が更新後の車両をカバーしなくなるのか（c）車両の機能変更は、車両型式認証に影響を及ぼすのか
7.1.1.10節 SUが車両の安全性に関わる他のシステムに影響を及ぼすか、または車両への機能追加や変更があるかなどを評価し、識別し、記録するプロセス。
7.1.1.11節 車両ユーザーがSUについて通知を受けることができるプロセス。
7.1.1.12節 認証機関もしくは技術サービスが、7.1.2.3節および7.1.2.4節に記される情報を利用できるようにするプロセス。
7.1節の残り部分の詳細はアプリオリかつ若干煩雑な内容でもあるので、MONOist記事を参照いただくとして、概観のみ触れることとします。
7.1.2節はソフトウェアアップデートに関する情報の記録を求めています。7.1.2.1節から7.1.2.4節は、7.1.1節のプロセス活動を通じて生成される情報を文書化するよう求めています。主にソフトウェアアップデートプロセスの説明、型式認証を受けるシステム構成の説明、ソフトウェアアップデート前後のRXSWINに関連するドキュメント、ソフトウェアアップデートバージョンと完全性検証データ、車両の構成情報や互換性検証の結果です。7.1.2.5節では、車両型式の認可取得のためにソフトウェアアップデートに関わる文書に求められる要件が述べられています。特に(h)において、ソフトウェアアップデートがセキュアに行われていることを確認できる文書が求められています。
7.1.3節では、ソフトウェアアップデートへの不正操作の防止、ソフトウェアアップデートプロセスの危殆化阻止、更新ソフトウェアの機能と有効性の検証といった、ソフトウェアアップデートを実行するにあたってのセキュリティ対策を求めています。
7.1.4節では、運転中にOTAによるソフトウェアアップデートを実行する場合の安全性と、OTAによるソフトウェアアップデートが完了するまで担当の整備士が携わっていることが確認できるようなプロセスについての説明を求めています。
7.2節 SU機能を含む車両型式の要件
次に7.2節を簡単に見ていきましょう。こちらもアプリオリに理解できる部分が多いため、各節の詳細はMONOist記事を参照いただくとして進めます。
7.2.1節を見ます。7.2.1.1節は、ソフトウェアアップデートの信頼性と完全性を担保することを求めています。7.2.1.2節は、型式認証にRXSWINを用いることとし、車両からRXSWINもしくはソフトウェアバージョンを読み出すことで、車両の状態を確実に把握できることを求めています。当然の内容ですよね。
7.2.2節はOTAのための追加要件が述べられています。7.2.2.1節は、ソフトウェアアップデートのために車両に求められる要件とし、ソフトウェアアップデートを完了するのに十分なパワーを有している場合にのみ実行され、もしソフトウェアアップデートが失敗もしくは中断しても、以前の状態に復元できるか、車両を安全な状態にできることを求めています。また、ソフトウェアアップデートを安全に実行できることの説明と、車両ユーザーによって検証できるプロセスを求めています。このあたりもそりゃそうだよね、といった感ですね。もちろん大変重要な部分ではありますが。
さらに要件が追加されたようで、7.2.2.2節では車両ユーザーへの通知項目、7.2.2.3節では運転中の更新が安全でない場合の対処とし、更新中は運転できなくするか、影響を受ける車両機能を使用できなくすること、そして7.2.2.4節では更新後に車両ユーザーへ更新の成否や変更点について通知することを求めています。ええ、勝手に更新されては困りますからね、通知はしてくれないとですよね。
BOMでソフトウェアアップデートも管理する!?
かなりアプリオリな概念が多かったMONOist記事内でのWP29 SU Regulationsですが、ここでは触れられていない重要な点として、CSMSで考慮されていたフェーズ・工程の概念を上げる必要があります。pwcさんはそこに気付いているようで以下のような図で示しています。
前回の記事でたまたま東大の藤本隆宏先生のセミナーに触れましたが、藤本先生の本で学んできた者としては、BOMが常に頭の片隅にありますので、設計・生産・販売といった製品ライフサイクル全体で設計変更同様にソフトウェアアップデートを考えなければいけない、と記事を書きながら考えていました。
特に量産に入った後の管理の仕方は考えものですね。図では製造部門で1台ごとに構成管理とありますが、そこまでデータを持ってしまうとデータボリュームが膨大になってしまうデメリットが発生します。実際にラインオフした実車にインストールされているソフトウェアのバージョンが識別できるよう、ソフトウェアの管理も含めた製造BOMとの確実な紐付けが必要となりますね。
また、視点をソフトウェア開発自体に移しますが、一言にソフトウェアアップデートと言っても仕様変更のような大きな更新もあれば、処理が少しだけ早くなるような小さな更新もあります。それら種々の更新を製造BOMへ反映させるタイミングをどう判断するのか、この基準策定も難しいなあと感じます。部品のリコール同様に重大なソフトウェアの異常がある場合は別として、ユーザがほんの少し快適に使用できる程度の更新をどのような方針の下で適用させていくのか、一歩間違えるとユーザのロイヤルティも失いかねない機微な領域ですね。スマホのアプリのように気付かないうちに毎日のようにアップデートがかかるのもどうかと思いますし、新モデルに搭載されているソフトウェアが旧モデルのハードウェアでも使用できるものであるならば、既存ユーザはもちろんアップデートを求めます。でも実は奥深い所で旧モデルの別システムとの相性が悪く、適用することはできない、みたいなことが起きると思いますし、それを現場では説明しなければならないでしょう。そしてネット上では、ユーザから厳しく追求されることでしょうね。。。
情報を隠すことは最も忌み嫌われることだとは思いますが、どのように開示していくか、またユーザもどのように受け止めるのが適切なのか、車という生命を預けるものであるが故に、自動車業界だけでなくユーザも巻き込んで広く議論されることが必要と考えます。
※こちらにソフトウェア部品表(Software Bill of Materials: SBOM)について記載しましたので、ご参考まで。
*1:UN規則の体型はJASICのHPを参照 https://www.jasic.org/j/08_publication/hh/un.htm
新年最初はSUMSを考えるはずだったが
これまでの振り返り
2020年11月頃から始めたわけですが、年が明けても未だにその全貌を理解するには遠く及ばず、日々努力を積み重ねていこうと新たに思う新年となりました。
さて、自動車メーカーや部品メーカーなど、もう15年以上も関わらせて頂いた者として、いわゆるサプライチェーンはある程度経験を積んできましたが、気がつけが世はデジタル一色。そんななか自動車にも否応なしにセキュリティが求められる、というわけで始めた当ブログです。
まずは、国連の中にある欧州経済委員会(UNECE)の下で活動している自動車基準調和世界フォーラム(WP29)により、自動車のサイバーセキュリティとソフトウェアアップデートに関する国際基準(UN規則)が現在進行系で更新されている、という話をMONOistの記事等を参考にし、やさーしく理解していくことを試みて来ました。UN規則で語られている、サイバーセキュリティ及びソフトウェアアップデートの国際基準の主な要件について調べ始め、サイバーセキュリティ管理システム(CSMS)とソフトウェアアップデート管理システム(SUMS)という仕組みが必要だ、という点にようやく辿り着きました。
途中で関連記事にも派生したりしつつも、CSMSの概観についてはこれまで見てくることができました。大まかに結論付けるならば、社外へ出てしまっている製品やサービスに対してセキュリティインシデントが発生した際に対応するチームであるPSIRT(Product Security Incident Response Team)を作りましょう、と言った点を前回までで見てきました。
まだまだ隙間を埋めきれておらず概観の理解でしかありません。特にCSMSが則っているISO/SAE 21434については、これ自体をきちんと理解する必要があり、なるべく早い時期に取り掛かるつもりです。
EV信仰になっていないか
振り返りだけでだいぶかかってしまいましたが、今回からはSUMSを調べていきたいと思います。と書きながらも最近の自動車を取り巻くニュースでどうしても避けられないものとして、EVを取り上げたく思います。
都内で販売される乗用車についてガソリン車を2030年までにゼロにする目標を都知事が表明した、というものです。他にも、2030年代半ばまでに新車販売を全てEVやHV等にする目標に、軽自動車も対象に含めるとのこと。
日本人の足とも言うべき軽自動車までもEVシフトの波に飲まれてしまうという話ですが、ここまで来るとただのEV信仰と言いたくもなってきます。軽自動車の生産時に排出される温室効果ガス、そして利用時の燃費を考えたら、いくらハイブリッドだとしてもア○ファードのような大型車の方が、よっぽど生産時の温室効果ガスも多く、燃費も悪いことは容易に想像できます。
もう少し冷静で現実的な議論を望むところです。
藤本隆宏先生のセミナー
12月に東大の藤本先生のオンラインセミナーを拝聴したことにも触れておきたいと思います。およそ20年程前に購入し、わたしにとって生産管理のバイブルとして助け続けてくれた本「生産マネジメント入門」ⅠⅡの著者としても憧れを頂いていた藤本先生のお話を聞くことができ、素直に嬉しかったです。
2021年3月末でご退職されるとのことで、非常に貴重な体験となりました。わたしの質問への回答も丁寧にいただき、感謝感謝です。別の機会に当セミナー内容については書くつもりです。
SUMSの触りだけ・・・
話が派生してしまったので、SUMSは次回から本格的に始めようと思います。いつもの通りMONOistの記事を参照します。
以前の記事でも書きましたが、ポイントは7.1節 Software Update Management System(SUMS)の要件と、7.2節 Vehicle Types(車両型式)の要件です。7.1節では自動車OEMが認証機関もしくは技術サービスからSUMSプロセス認証を取得するための要件が規定されており、7.2節ではこのSUMSプロセスに基づき管理されるソフトウェアを、セキュリティに配慮されたSU機能を通じて適用される自動車の型式認証を取得するための要件が規定されているようです。
CSMS同様にややこしいこと請け合いですが、 いつも申し上げている通り、数学の証明のように一歩一歩、論理的でわかり易い記載で読み砕いていきたいと思います。
CSMS解釈その2 -見つけてしまったその時、平然とPSIRTが動き始める-
前回からCS Regulation(UN-R155)の7.2.2.2節に踏み込んでみたわけですが、その内(a)-(e)までを見てきました。
かなり七面倒臭いであろうCS要求に応える必要が出てくるサプライヤーにとって大きな分岐点となり得、買うもの、買われるものが出てくるのでは、という問いかけをして終わりました。
今回は残っている7.2.2.2節の(f)、(g)を見ていきます。参考にするMONOistの記事はこちら。
7.2.2.2節の(f)、(g)をおさらいすると、
(f) リスク評価を最新に保つためのプロセス
(g) 車両型式へのサイバー攻撃、サイバー脅威、脆弱性の監視、検出、対応に使用されるプロセス
でした。順序は逆になりますが、(g)では新たに発覚する脆弱性の監視、自動車に対するサイバー攻撃の監視、こうした脆弱性や攻撃に関するリスク分析や評価、対策のプロセスに対する要件が記載されているようです。PSIRT(Product Security Incident Response Team)という言葉もこれ以後頻繁に使われるので、この用語は先に見ていきます。(f)については、(g)を受けてのPDCA、改善活動のような位置付けであり、PSIRT活動で発覚した脆弱性が何故組み込まれてしまったのか、その原因を振り返るものとされています。
まずはPSIRTから。わたしも用語として初めて見聞きしましたがピーサートと読むようです。
自社で製造・開発する製品やサービスを対象に、セキュリティレベルの向上やインシデント発生時の対応を行う組織がPSIRT(Product Security Incident Response Team)です。自組織の保護やインシデント対応を目的とするCSIRTに対し、PSIRTは外部に提供する製品やサービスの保護を目的にする点が大きな違いです。PSIRTの業務内容には、製品およびサービスのセキュリティレベル向上を目的とした安全管理、セキュリティ面におけるユーザーサポート、そして製品/サービスに関連するインシデントが発生したときの対応などがあります。特に自社製品/サービスの脆弱性の発見は重要であり、新たな脆弱性が見つかった際には迅速にユーザーに通知して対応を促すといった役割を担っています。
社内でクローズしたセキュリティインシデントへの対応チームがCSIRT(Computer Security Incident Response Team)であるのに対し、PSIRTは社外へ出てしまっている製品やサービスに対してセキュリティインシデントが発生した際に対応するチーム、ということのようです。
結局のところ、このPSIRTを適切に構築し運用することが、7.2.2.2節 (f) (g)の要件を満たすために必要である、という解釈がなされ、MONOistの同記事では、このPSIRTが担うプロセスについて具体的事例が示されています。
というわけで、PSIRTをどのように構築し運用すべきなのかに論点が移るわけですが、FIRST(Forum of Incident Response and Security Teams)という、世界中のCSIRTが相互の情報交換やインシデント対応に関する協力関係を構築する目的で1990年に設立されたフォーラムにより、PSIRTはフレームワーク化されています。FIRSTが公開したPSIRT Services Frameworkの日本語版が下記に公開されています。
Software ISAC(一般社団法人コンピュータソフトウェア協会)、同じく一般社団法人のJPCERT/CC(Japan Computer Emergency Response Team / Coordination Center)が共同で翻訳したもののようです。(まあ、こういった組織、たくさんありますよね。気が向いたら詳細を見ることとし、この場は一旦はしょります。)
PSIRT Services Frameworkは100ページ超の大作なので、ここではMONOist記事の具体的事例を見ていくことで、PSIRTの理解を深めていくこととします。
PSIRTを中心に関係者が連携して調整を進めるプロセスの一例として、脆弱性の入電から始まり、リスクを分析して脆弱性もしくはインシデント対応方針を決定し、脆弱性情報とその対策を公表する、といったイメージ図が同記事に掲載されています。
記事では、情報がどこから入ってくるのか、社内からか、脆弱性データベースやWebサイトの情報からか、販売店や使用しているユーザーからか等の記載から始まり、かなり丁寧に細かく書かれているので、それをなぞることはここではやめておきます。製造業、とりわけ自動車関連会社はこういった報連相は得意中の得意分野であるので、コンセプトさえ理解できれば、こういったプロセスをマニュアル化することは容易のはずです。
リコール時の対応と大きな流れは変わらないように考えますが、実際の施術を受ける時点になって、販売店や修理工場への持ち込みではなく、OTAを通じたSoftware Updateとなる部分については大きな違いと言えますね。CSMSのざっくりとした解釈は今回までとし、次回からはこのあたりに関わる、SUMS(Software Update Management System)について見ていきたいと思います。
