「CASE」時代の自動車におけるサイバーセキュリティの6つの要諦

本論考では、自動車向けセキュリティ規制やCASEによる新たなセキュリティ課題に自動車業界が対応するために必要となる包括的取り組み方針を紹介します。本論考でご説明する内容の要点は以下の4点です。

• CASEは自動車社会の未来像ですが、それゆえに未知のセキュリティリスクが潜んでいる可能性があります。自動車業界では、完成車メーカーからサプライヤに至るまで、一丸となって自動車セキュリティに取り組むことが必要です
• CASEのような新しい技術を社会が受け入れるには、新しいセキュリティリスクへの対応が重要となります。それらのリスクを適切に管理し、積極的に継続対応することが肝要です
• UN Regulation No.15（以下、UN-R155）がWP29にて採択され、日本でも法規として施行されたことを踏まえ、要求事項の十分な理解と継続的なセキュリティへの取り組みが不可欠です
• CASE時代の自動車セキュリティの要諦は「①自動車セキュリティのプログラムマネジメント」「②車両／プラットフォームセキュリティ要件のトレーサビリティ確立」「③設計によるセキュリティ作り込み」「④OT（工場）セキュリティ」「⑤PSIRT／VSOC（ピーサート/ブイソック）」「⑥E2Eセキュリティテスト」の6つに集約されます

この世界観へ自動車が対応するための要素技術として求められているのが、自動車業界で取り組みが進んでいるCASEです。

CASEは、コネクテッド（Connected）、自動運転（Autonomous）、シェアリングとサービス（Shared and Services）、電動化（Electric）の頭文字を並べたもので、2016年のパリモーターショーが公の場での初出です。

CASEは、モビリティ社会の未来像として瞬く間に自動車業界を席巻しました。2020年代は、自動車のアーキテクチャやビジネスモデル自体といったパラダイムが大きく変革する時代になると、多くの完成車メーカー、サプライヤは考えており、各社ともに新たなチャレンジへの取り組みを加速させています。

しかしCASEは「新たな取り組み」です。それ故に、これまで十分に検討を行なってこなかった新規のビジネスリスクも生み出している可能性を認識する必要があります。

では、設計／生産／アフターセールスで構成される自動車の製品ライフサイクルの中で、CASE時代のサイバーセキュリティはどのように位置付けられ、企業は何に取り組むべきでしょうか。アクセンチュアはこの複雑かつ困難な取り組みの要諦を以下６点にまとめています。

1. 自動車セキュリティのプログラムマネジメント

   車両／プラットフォームのサイバーセキュリティを維持／改善するには多くの社内部門とサプライヤを巻き込んだ包括的な活動が必要であり、大変な労力がかかります。更に日本の製造業は部門間の壁が厚いことが多く、また各部門の全員がセキュリティの知見を持ち合わせているとは限らず、場合によってはセキュリティ強化に対するコストや工数に協力的ではないこともあり得ます。これらに対する打ち手は、車両／プラットフォームに対するサイバーセキュリティの施策を個別プロジェクトとして管理するのではなく、全社プログラムへと昇華させ、経営陣のリーダーシップの元で「組織横断の活動として管理」することが有効です。特にサプライヤ管理については調達部門と連携し、契約条件から協働しながら検討を重ねるなど、息の長い活動が必要になります。

   
   

2. 車両／プラットフォームセキュリティ要件のトレーサビリティ確立

   セキュリティ要件に限った話ではありませんが、車両開発においては時にある要件が他機能要件と競合を起こしたり、車両開発後半でのハードウェア変更が困難な状況下で当初想定通りの実装が難しい状況になったりすることがあります。また車両／プラットフォーム共に多くのノードが連携して複雑なシステムを形成する場合、とある要件がどこにどのように関連するかという影響分析が困難なこともあります。このため、設計からアフターセールスまで全製品ライフサイクルを支えるセキュリティ要件トレーサビリティを確立し、仕様変更による設計上の影響を短時間で追跡できるようにしておくことが重要です。現時点ではISO 26262への対応として、主にTier1サプライヤでALM（Application Lifecycle Management：アプリケーションライフサイクル管理）が活用されていますが、今後はトレーサビリティ確立のような使い方も視野に入れて完成車メーカーへの導入が進むと想定されます。

   
   

3. 設計によるセキュリティ作り込み

   ITに比べて車両開発はハードウェアの制約が大きいこともあり、開発後期にセキュリティ要求仕様を追加するのは困難です。車両／プラットフォーム開発においても一般的なITセキュリティと同様にSecure by Designが納期／スケジュール／保守性の観点で有効だといえます。ハイレベルなユースケースからデータフローを把握して、TARA（Threat Analysis and Risk Assessment：脅威／リスク分析）を実施。リスク管理策を検討後、対策を行なうリスクに紐づくセキュリティ要求仕様を策定します。設計段階で要求仕様自体が漏れていて後続のテストフェーズで脆弱性が見つかった場合、プロジェクト予算にも影響します。こうしたトラブルを回避するためにもSecure by Designによる念入りな実施が必要です。

   
   

4. OT（工場）セキュリティ

   プラットフォーム上でのコネクテッド・ヴィークル認証やCAN-FD（CAN with Flexible Data Rate）上の通信セキュリティ技術など、多くのユースケースで鍵情報を使用しますが、その鍵、あるいは鍵を呼び出すための情報は工場で車両に書き込むことがあります。その鍵情報は関係者でも簡単にアクセスできないよう厳重に保護する必要がある一方で、アフターセールスフェーズでディーラーが保守に使用する場合もあります。そのため、IT／OT（Operational Technology）の環境間受け渡しが必要となるものの、OT環境から情報が漏えいしては元も子もありません。また工場において、設計フェーズで作り込んだファームウェアを、ハッカーがマルウェアを注入したファームウェアにすり替えられてしまってはこれまでの苦労が水泡に帰すことになります。工場設備をR&D部門が直接管轄することは通常ありませんが、OTに対するセキュリティも無視できない要素だと言えます。

   
   

5. PSIRT／VSOC

   「PSIRT/VSOC」は「Product Security Incident Response Team／Vehicle Security Operation Center」の略であり社内組織の名称です。VSOC（ブイソック）にて車両やプラットフォームのセキュリティイベントを監視し、サイバー攻撃を検知、PSIRTにてそのイベントや検知した攻撃に対して必要な対応を行ないます。PSIRT（ピーサート）は、最悪のケースの発生時にテレマティクスサービスの停止を宣言する権限を持つ組織です。そのため、事前のプロセス定義、内部関係者巻き込み（CxO、法務、調達、営業、R&D、広報、危機管理など）、外部関係者巻き込み（サプライヤ、セキュリティリサーチャー、ベンダーなど）などの準備を念入りに行なった上で、高い技術力とコミュニケーション能力を備えたチームに育て上げる必要があります。

   
   

6. E2E（End to End）セキュリティテスト

   エンドユーザが使用するモバイルアプリからプラットフォームを経由して車両に操作指示が発行される全プロセスに対して、「セキュリティ要件が適切に実装されているか」という仕様評価、「セキュリティ運用が適切に実行されているか」という運用評価の両面で継続的にセキュリティテストを実施することが推奨されます。車両においてはソースコードの入手が困難であったり、誤検知が大量に発生したりという理由からソースコードレビューの実施はまだ一般的ではありませんが、PSIRT活動の一環として今後はデジタルツイン上で継続的に評価を実施する活動が増えるものと想定されます。