自動車セキュリティにおける、攻撃検知のための「組織・ツール・プロセス」

• 物理的接続による攻撃

  まず、最もシンプルな攻撃手法は、自動車に搭載されている機器に対して物理的に接続して攻撃することです。（図中の①）
  

  一般的なコネクテッド・ヴィークルであれば数十のECU（電子制御ユニット：Electronic Control Unit）、及びECU間のネットワークが搭載されており、"タイヤに乗ったスマートフォン"と完成車メーカーが形容するほどソフトウェアによる制御が進んでいます。ECUへの具体的な攻撃方法としては、USBメモリをIVI（車載インフォテイメント機器）に挿してランサムウェアを送り込んだり、メモリへ物理的に接続して暗号化されていない個人情報を盗み出したりといった手法が挙げられます。当然、各社で十分なテストが実施済みと考えられますが、あらゆるソフトウェアにセキュリティ脆弱性が存在している可能性があります。

   

• Bluetooth等の近距離無線通信に対する攻撃

  近距離無線通信の一つであるBluetoothやWifiで運転手のスマートフォンと自動車のIVIを接続する機能が提供されている場合は、その通信の乗っ取り、盗聴、改ざんを行う攻撃が考えられます。（図中の②）

  例えば公表されてから数年経過した通信規格に潜む既知の脆弱性を悪用したり、使用されているパスワードが初期値のままで暗号を解読されてしまったり、というケースが想定されます。このケースは車両内に侵入することなく攻撃を実行できるため、攻撃者から見ると自動車への物理接続攻撃よりも魅力的に見えます。

  ただし近距離無線通信に対して攻撃を行なうには、通信を行なっているその場に攻撃者が物理的に赴く必要があります。

   

• 利用者の携帯端末（スマートフォンやタブレット）に対する攻撃

  ②の手法で「攻撃するために現地に行くのは煩わしい」と攻撃者が考えた場合、次に狙うのは利用者の携帯端末（スマートフォンやタブレット）です。（図中の③）

  何らかの手法を用いて運転者の携帯端末をリモートで乗っ取ることが出来れば、現地に赴くことなく自動車を操作可能となることが想定されます。携帯端末で自動車を操作する前にパスワード入力や指紋認証などを求めるセキュリティ機能があれば攻撃者にとって難易度は上がりますが、ユーザーが使い勝手を優先して「2回目以降の認証を省略」等しているケースにおいては、攻撃者が自由に操作できてしまう可能性があります。

   

• コネクテッド・ヴィークルを支えるシステム群への攻撃

  携帯端末を乗っ取って攻撃できるのは、その端末と接続されている自動車（ほとんどの場合は１台）のみです。そのため、攻撃者はより効率的に多数の自動車を攻撃したいと考えるかも知れません。その場合に狙うのはコネクテッド・ヴィークルを支えるシステム群です。（図中の④）

  テレマティクスサービスを処理するプラットフォーム、自動車製造時に鍵情報を書き込む工場のシステム、ディーラーを含む多くのメンテナンス関係者が使用する車両診断システム、及びそれらのシステムへファームウェアデータを提供するシステムなどのバックエンドシステムがその一例となります。

  例えば攻撃者がファームウェアに遠隔操作可能な攻撃コードを追加し、多くのチェックをすり抜けて自動車へFOTA（無線によるファームウェア更新機能）で展開されてしまった場合、FOTAが実施された分だけ攻撃者は現地に赴くことなく遠隔操作可能な車両を手に入れることができます。

   

• 防御側の検知機能の3つのキーカテゴリー

  上記のように、自動車への攻撃経路は多岐にわたります。ここからは視点を変えて、守る側はそれらの攻撃をどのようにして検知するかを考察します。

  前述のNIST Cybersecurity Framework Version 1.1*3では検知機能の中で以下３点をキーとなるカテゴリーとしています。

   

1. "異常とイベント"

   異常な処理を検知し、イベントがもたらす潜在的な影響を把握すること

    

2. "セキュリティの継続的なモニタリング"

   サイバーセキュリティイベントを識別し保護対策の有効性を検証するために、情報システムと資産をモニタリングすること

    

3. "検知プロセス"

   異常なイベントに気付くことが出来るように、検知プロセスと手順を維持しテストすること

    

• 物理接続／近距離無線通信への攻撃検知

  上記のキーを自動車に置き換えますと、図中の①と②に分類される自動車への物理接続／近距離無線通信経由の攻撃を判別するには、「自動車で実行されたあらゆる処理を記録」、その記録であるログデータに「異常な処理を検知したデータが含まれていないかをモニタリング」、「検知に必要なプロセスの継続的な更新」が必要であると言えます。

  とはいえ、非コネクテッドカーの場合は自動車のログデータを直接自動車に接続して収集することが出来るのは車両診断ツールを物理的につなぐ場合など、方法が限られます。よって、タイムリーにサイバー攻撃を検知することは困難です。一方、コネクテッドカーであればプラットフォームに自動車のログデータを送付・格納して異常を検知することで、比較的リアルタイムに近い形で検知できる可能性があります。

• コネクテッド・ヴィークルを支えるシステム群への攻撃検知

  図中の④に分類されるコネクテッド・ヴィークルを支えるシステム群への攻撃検知はITシステムへの攻撃検知と同様に、ログの収集と解析によって運用します。各サーバは自社の裁量で運用でき、特にクラウド上に設置されたサーバであれば潤沢な性能を生かして十分なログを収集出来ます。さらに、OSやミドルウェアなど汎用品から出力されるログに対しては、汎用的な攻撃検知ツールの調達も可能です。

   

  一方で自動車への攻撃検知は一般的なITシステムとは勝手が異なります。そもそも自動車が自社資産でない場合、利用者の協力がなければ詳細調査が出来ません。また、ログをプラットフォームへ送付するにもハードウェアや通信帯域の制約により、ログを十分に生成し送付出来ない場合もあります。さらにECUの仕様は診断仕様など標準化が進んでいる領域を除けば各社各様であるため、攻撃検知ルールは各完成車メーカーがそれぞれ作り込む必要があるなど、業界全体における今後の課題だと認識されています。この点を次章で掘り下げて解説します。
  

• パターンA：テレマティクス一式をVSOCが担当

  パターンAは、テレマティクスサービスを構成するシステムを統合的にモニタリングできるのがメリットですが、"どこまでをテレマティクス関連システムとするのか"という線引きに苦労することになります。例えばファームウェア管理システムはFOTAでも診断システムでも連携するため、VSOC／IT-SOCのどちらでモニタリングを行なうのかという定義が困難です。

  また、IT-SOC管理下のシステムを踏み台にしてVSOC管理下のシステムへ攻撃された場合、それぞれのSOCが持つ攻撃検知情報を総合的に分析／調査することは困難です。両SOC間の連携方法を検討しておく必要があります。

• パターンB：自動車への攻撃のみVSOCが担当

  パターンBは、自動車への攻撃のみをVSOCが管理するモデルで、役割分担の明確さがメリットです。自動車のログ品質次第では、自動車専用の組織・ツールを用意する価値がある可能性があります。

  ただし、バックエンドシステムを経由して自動車を攻撃するパターンについてはVSOCだけでは気付けない可能性があります。確実な検知を実現するために、両SOC間の連携方法を検討しなければなりません。また、自動車のためだけに監視体制と自動車専用攻撃検知システムを用意することになるため、分割する価値が十分にあるかどうか検討の余地があります。

• パターンC：自動車もIT-SOCが担当

パターンCは、勝手が違うものの自動車への攻撃検知もIT-SOCで実施するモデルです。自動車のログ品質次第では攻撃検知ルールの開発コストや監視体制のコストも抑えられるため、結果として最も安価に運用できる可能性があります。

このパターンを採用する場合、IT-SOCが自動車のログを取り扱えるよう体制・プロセス・ツールにおいて様々なチャレンジがあります。各関係者の協力や自動化技術などを活用して、課題を一つずつ乗り越えていくことが重要です。

UN-R155においては、サイバー攻撃の検知だけでなく、検知した攻撃を分析し合理的な時間枠の中で対処することが完成車メーカーに対して求められています。そのため完成車メーカーがサイバー攻撃を検知した場合に、早急に脆弱性調査や対策提案を行うよう完成車メーカーからサプライヤに対し求められる可能性があります。また、有事における早急な対応を確実に実行するために、連絡窓口・OSS脆弱性監視プロセス・攻撃検知時の調査プロセス等をあらかじめ定義するよう完成車メーカーから求められる可能性もあります。

よって、サイバー攻撃検知の国際基準化はサプライヤと無関係ではなく、完成車メーカーとの責任分担を明確にした上でプロセスや体制を事前に定義しておくことが必要となります。