前回から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)について見ていきたいと思います。
