前回からCSMSの詳細要件に踏み込み始めたわけですが、予想通り複雑な内容で、如何にしてすんなりと解釈できるよう書き砕いていくか、苦心しつつがんばります。。。
前回記事、
で触れたCS Regulation(UN-R155)の7.2.2.2節、CSMSにおいてセキュリティを考慮しなければならないプロセスの中身に入っていきましょう。いつもどおり参考にする記事はMONOistから。
7.2.2.2節 (a)
まずは、7.2.2.2節の (a) 車両、車両のシステムおよび/または部品に対するサイバーセキュリティを管理するためにOEMの組織内で使用されるプロセス を理解するために、当記事に掲載されている組織構造の具体例を見ていきます。
またまた用語軍団に襲われ始めましたが、ひとまずは概観として言えることは、バックオフィスのような部門を除き、自動車の設計・生産・販売に関わる部門、子会社、サプライヤー全てが、この(a)で求められているプロセスに関与する必要がある、という理解をしました。
組織のセキュリティ管理システムの土台としてISMS*1を運用した上で、CSMSのプロセスが、車両システム、ハードウェアやソフトウェアを設計･開発する開発部門、それらの品質を管理する品質管理部門、脆弱性を監視し対応するPSIRT(Product Security Incident Response Team)*2へ上乗せされる形で運用される、ということのようです。
また上記図で示されている製品・情報セキュリティ委員会のような文言は例えばのお話しのようで、一般的に定義されている用語ではなさそうです。が、意味合いとしてはアプリオリにわかりますし、体制図的には非常にわかりやすくなりますね。対外的な説明が肝となっているCSMSにおいて、このようなパット見てわかる体制図は有益と考えます。
そしてここで忘れてはいけないのが、サプライヤーの存在です。当記事では、サプライヤーのCSMS対応能力の評価方法例も示していますが、このあたりは中小零細企業にどこまで求めるのか、自動車メーカー、Tier1、2がどの程度責任を肩代わりするのか等、議論が必要な部分でしょう。トヨタのような企業であれば上から下までズドーンと落とせるかもしれませんし、マツダのような比較的小規模でローカルサプライヤーを抱えているような企業では、ある程度上位層で担保してあげる必要があるのかもしれません。
7.2.2.2節 (b)-(e)
次に、7.2.2.2節の (b)-(e) 開発フェーズにおけるCSMSプロセス を見ていきます。当記事では特に(b)のリスクの特定に重きを置いているようです。確かに(c)-(e)については、特定されたリスクについての評価、分類し、テストを含めて処置し、それらを管理する、と理解できますので、特別なプロセスではないと言えますね。しかしリスクの特定に抜け漏れがあると、サイバー攻撃への耐性を担保できなくなるため、リスク特定の網羅性がポイントであるとのことです。ではどのようにリスクを特定していくかという例として図が示されています。
アイテムの設計情報から、守るべき資産を識別し、その資産が侵害された場合に想定される被害シナリオを分析する。この被害シナリオから、影響度の評価を行うことになる。次に、被害を引き起こすための脅威シナリオについて、攻撃方法や具体的な成立条件を分析する。この攻撃方法や成立条件から、攻撃発生確率の評価を行う。
守らなければならないもの、ここでは乗っている人の命を例に書かれていますが、熱中症にならないよう適切に車内の温度管理が行われること、としているようです。その温度管理システムが攻撃を受け、動作しなくなるもしくは極端な温度設定を強制されることを考えましょう。この温度管理システムへの攻撃を脅威として定義した際、それを可能とする手段や条件を分析し、攻撃パスの実現性評価を行う、といったもののようです。尚、ここではこの適切な温度設定なるものを資産と位置付けています。
今の一連の思考プロセスは図の左から右の流れでしたが、脆弱性を起点とし攻撃による発生した事象から考え始める、右から左の流れでの検討も加えることで、より網羅性が高まる、と理解しました。
新しいTier1サプライヤーが生まれる
当記事の最後にも触れられていましたが、やはり難しいのは、サプライヤーとの連携、責任分担になろうかと考えます。セキュリティ対策の作り込みは勿論実施するものの、それが自動車メーカーやTier1、2が求めているCS要求を満たしているのか、証明するためのドキュメント作りに小規模サプライヤーの工数を多く取られてしまうことが懸念されます。せめてテストパターンやテストシナリオをテンプレート化するなど、何らかの工夫が必要です。
またさらに突っ込んで考えると、これまでTier1、2とは呼べない程度のサプライヤーであっても、上記で見てきたようなCS要求に答えるプロセスを徹底的に整備してしまうことで、自動運転時代のデファクトスタンダードを持つことが可能となる、という発想もできると考えます。もしくはCSMSプロセスを準備できずにいるものの、コアな部品・モジュールを生産している中小企業を買収してしまう、という発想も現実味を感じます。系列縛りの無いような新興企業にとっては、そのような部品・モジュールを集めて組み合せれば、プラモデルのような自動運転車が生産できることでしょう。もちろん乗り心地などは既存メーカーに及ばないところから始まるでしょうが、それを補って余りあるコストパフォーマンスが出るような気がしてなりません。Google社らがさくっと作ってしまいそうな気が。。。
7.2.2.2節の(e)まで見てきましたが、残る(f)と(g)は次回に。
