そして2022年7月がやってくる -WP29 UN規則への適合-
2022年となりましたが、くるまのセキュリティにとっては大きなイベントが待ち構えている年となります。具体的にその時が来るとどうなるのか、詳細なプロセスは今後明らかになるのでしょうが、新型車に関しては2022年7月から、WP29のUN規則、つまりUN-R155 CSMS/UN-R156 SUMSへの適合が求められます。
年始でもあるので、簡単に振り返っておきますと、
国連に設けられているUNECE、欧州経済委員会の下に、WP29(自動車基準調和世界フォーラム)がありましたね。2020年6月24日に開催されたWP29にて、自動車のサイバーセキュリティとソフトウェアアップデートに関する国際基準としてUN規則が成立し、それへの適合が迫っている、というのが現状となります。詳細は↓あたりをご参照下さい。
適合タイミングですが、もう1段階掘り下げてみると、OTA対応により別れている模様で、無線によるソフトウェアアップデートに対応している車両は、
| 新型車 | 2022年7月1日 |
| 継続生産車 | 2024年7月1日 |
無線によるソフトウェアアップデートに対応していない車両は、
| 新型車 | 2024年1月1日 |
| 継続生産車 | 2026年5月1日 |
となっています。既に新型車のほとんどが何らかのコネクテッドサービスを提供しているのが現状ですが、全ての車載ソフトウェアをOTAでアップデートできるのか、明確にHP等で見たことはありませんが、7月に向けて要チェックしていきたいと思います。
次回以降はこの年末年始にあった出来事をいくつか紹介していきたいと思っています。特にIBM社のセミナーレポートは、提供サービスの紹介をしつつも、重要ポイントをコンパクトにまとめている点は振り返りにもってこいです。
続 ソフトウェアだけじゃない、きっとRXSWINやCVEも -ソフトウェア部品表 SBOM-
前回までの「これからのくるまのセキュリティを考えるぶろぐ」・・・
最近のセキュリティ事情をざっと見つつ、その中でソフトウェア部品表(Software Bill of Materials: SBOM)を取り上げました。具体的にSBOMの管理ツールとしてBlackberry社のJARVIS 2.0を拝見し、CVEはもとよりRXSWINも一緒に管理したいなあ、などと妄想をしておりました。
今回は同様の管理ツールとしてCybellum(サイベラム)社を見てみたいと思います。
ところで、Cybellumといえば韓国のLG社に買収されるという記事には驚きましたね。
液晶に強いくらいのイメージしか持っていませんでしたが、いつの間にかスマートフォン市場から撤退し、自動車業界へ軸足を移そうとしているのでしょうか。既にEV向けバッテリーでは最大手の一角を占めているLG社ですが、Cybellum社を買収するあたりセンスを感じます。
(日本企業、特にパナソニック社あたりがなぜこういった動きを先んじてできないのか、甚だ残念な気持ちになります。乗り心地や加速のフィーリングなど、人が意思を持って運転する時代の車は日本の擦り合わせ型のものづくりが競争力を持ちましたが、もはやEVの自動運転が到来してしまった暁には、エクステリアやインテリアのカッコよさも求められるでしょうが、それ以上に車を包み込む各種のソフトウェアがその車の価値の大半を決めてしまう、とわたし自身は考えております。パソコンやスマートフォンを例に上げるまでもありません。)
少し脱線しましたが、SBOMの管理ツールに戻りましょう。Blackberry社のJARVIS 2.0と同様、Cybellum社はバイナリー解析に特化している、という話しまでは前回しました。製品セキュリティアセスメントなるソリューションを紹介している同社のHP↓を見てもそれっぽい概要しか書いてありませんでした。
が、別の記事ではBlackberry社の画面によく似たものを見つけました。
上は使用しているとあるソフトウェアについて、未解決のCVE一覧を表示しているものかと推測できます。下はひとつのモデルにおける主要なソフトウェアのリスクをスコア化し、該当モデルトータルでのリスクもスコアとして表示しているのではと推測します。いずれにせよ、前回見たBlackberry社の管理ツールとやろうとしていることは同様で、使用しているソフトウェアが抱えているCVEとそのCVEが解決されたバージョンを明らかにし、バージョンアップすべきソフトウェアの一覧を重要度も付記した上で見える化する、というものかと思います。
まだまだいろいろな機能があるはずですが、現時点で見えているものから察してみました。Blackberry社もCybellum社も、採用事例とともにツールの全容が見えてくることを期待しましょう。そして、ぜひとも、日本製のSBOM管理ツールの開発も待ってます!!
ソフトウェアだけじゃない、きっとRXSWINやCVEも -ソフトウェア部品表 SBOM-
ソフトウェア部品表(Software Bill of Materials: SBOM)とは
前回更新時に幾つか気になる記事を上げておきました。
今回はその中でも下記で取り上げられていた、ソフトウェア部品表(Software Bill of Materials: SBOM)を取り上げたいと思います。
このブログを読んで下さっている方には今更なことですが、車載ソフトに含まれるOSSなどの構成要素をすべて展開、閲覧できるようにし、脆弱性の有無を把握することは、サイバー攻撃を未然に防ぐ上で重要この上ありません。当ブログでもTop3のアクセスを頂いている下記でオリジナルのイメージ図を載せてみましたが、
まさにBOMで管理されている情報に加えて、各部品・モジュールで使用されているECUソフトウェアを関連づけて管理しましょう、という話しをしてきたわけですが、まさしくSBOMのイメージとなっているかと思います。(実用の際にはRXSWINで管理する必要がありますので、SBOMの要件だけでは足りませんが)
SBOMの管理ツールを見てみる
日経XTECHの記事では、Synopsys社の「Black Duck」、カナダBlackBerry社の「Jarvis」、イスラエルCybellum社のツールが紹介されていますが、今回は例としてBlackBerry社のJARVIS 2.0を見てみます。MONOistにも紹介記事がありました。
Blackberryというとわたしは携帯電話しかイメージできませんでしたが、このようなソフトウェアも開発していたのですね。このJARVIS 2.0は、組み込みシステム内のオープンソースソフトウェアとソフトウェアライセンス、およびそれらのサイバーセキュリティの脆弱性を検出して一覧表示できるソフトウェア構成分析ソリューション、とのことです。Synopsys社がソースコードを解析するのに対し、JARVIS 2.0やCybellum社はバイナリー解析に特化しているようです。えー、ソースコードはさすがにわかるのですが、恥ずかしながらバイナリって・・・という感じなので、改めて調べました。
メモ帳とかで音声ファイルや画像ファイル、exeファイル等を開いてしまったときの読めないあれですね。で、JARVIS 2.0では、アップロードされたバイナリデータをスキャンし、ライセンスや、検出された脆弱性を重要度で分類した上で、グラフィカルにレポーティングしてくれるとのこと。CVEダッシュボードなる画面もあるようです。
HPの説明と一部の画面だけでははっきりとはわかりかねますが、使用しているソフトウェアが抱えているCVEとそのCVEが解決されたバージョンを明らかにし、バージョンアップすべきソフトウェアの一覧を重要度も付記した上で、見える化してくれているようです。で、これも初めて知った用語なのですが、CVEです。
Common Vulnerabilities and Exposures、日本語だと共通脆弱性識別子となるようです。Red HatのHPが詳細を記載してくれていますが、米国国土安全保障省の一機関であるサイバーセキュリティおよびインフラストラクチャ・セキュリティ庁から資金援助を受けて MITRE 社が管理しているとのことです。
具体例はこちらがわかりやすかったです。
確かにこのようなCVEを一つひとつ確認していくことは非現実的であり、SBOM管理ツールに頼りたいところです。自動チェック機能は必須として、CVEを検知する際のパフォーマンスや品質はツール選定時における重要な判断基準となりそうですね。
というわけで、今回はSBOMならびにそのツールを1つ見てきましたが、他社のツールも比較検討のため今後見てみるようにします。しかし昔からそうですが、CADを始めこの手の自動車会社で核となるソフトウェア、残念ながらMade in Japanは見かけませんね。。。
