ISO/SAE 21434 悶悶

@名古屋ではなく愛知県

プログラムに対するリスクアセスメントは、脅威分析だけで終わらせられないのか?

自動車のリスクアセスメントは、脅威分析と脆弱性分析の2つに分けられる。「脅威分析と脆弱性分析の両方で、プログラムについて分析するのはなぜか」と指摘された。ハッとした。二重なのは確かに美しくない。
このまま二重に分析すべきか、それともどちらかにすべきか。

現状では、両方で分析するのがよいと思っているが、決定的な理由が見つからない。

案1:脅威分析では、基板上のデバックポートのようなインタフェースを攻撃経路から除外することがある。なぜならそのような経路からの攻撃により、仮に安全に影響が生じたとしても「それはそれを起こした人のせい」と説明ができるから。
案2:開発フェーズにおいて、仕様を明確化するときに、新たなプログラムが必要になるから。
案3:ソフトウェアの知的財産保護の観点で考える。OEMは、自社でプログラムを書かないことが多い。このため、コンセプトフェーズにおけるSFOPベースの分析では、プログラムの漏洩による知的財産上のリスクはあらわれてこない。
案4:まず、基板上のデバックポートからプログラムを抜き出し、それを解析して、わかった情報をもとに遠隔からのサイバー攻撃が成功したとする。このとき、最初にプログラムを抜き出した行為を、攻撃経路に表現するべきなのだろうか。冗長なので、美しくないと思う。