設計フェーズでの入念なセキュリティ設計を経ても、「バグを含む実装ミスが見つかる」「利用したミドルウェアにバグが後から見つかる」といったことが高確率で発生することは、避けようのない事実です。
稀にハードウェアの仕様変更を行わないと解消できない脆弱性が発見されますが、この修正には多くのコストが必要となり、「脆弱性を修正せずリスクを受容するかどうか」の判断を管理者は求められます。
自動車側の脆弱性については、ITシステムのように資源が潤沢であったり脆弱性調査を自社資産で実施できたり、といったことが困難なケースが多いため、結果として「当該リスクは受容し、次のモデルイヤーで修正する」というケースが発生する可能性があります。
その際、前述の評価手法は各脆弱性の重大さ・攻撃容易性を定量的に理解するためには有益ですが、それらに加えて「脆弱性チェーン（Vulnerability Chaining）」、つまり「複数の脆弱性を組み合わせての悪用」を考慮する必要があります。なぜならば、新たに発見された脆弱性により「過去の調査で存在を把握したが何らかの事情で修正を行わなかった脆弱性」と組み合わせて悪用される余地があるか、という観点が個別の脆弱性評価では抜け落ちてしまうためです。
具体例として、アクセンチュアが自動車の車両全体を対象とした侵入テストを行なった事例をご紹介します。
- 自動車に搭載されたあるECUのLinux OSに設定されているパスワードが脆弱であり、総当たり攻撃によりアクセンチュアのテスターがパスワード情報の特定に成功した
- ただし、その脆弱なパスワードを入力する攻撃面がすべて適切に要塞化されていた。つまり、そのパスワードを使ってOSへログインし、CANなどを経由して他ECUへ攻撃する方法は見つからなかった
上記の状況において、そのECUの設計・製造を担当する海外ベンダーからは「そのパスワードが分かったところで使い道がないので修正不要だ」と主張されました。
複数回にわたる協議を経て、最終的にこの事例では「パスワードの強度の向上」という対策が取られることになりましたが、仮にベンダーの主張通り「修正なし」とし、その後、当該デバイスのOSへログインする攻撃面が露出する脆弱性が発見された場合の影響は甚大となります。
その攻撃面が無線でアクセス可能なものであれば、そのデバイスのみが検討対象となります。しかし仮にEthernetなどの有線アクセスが必要なものであれば、有線接続している他のデバイスを踏み台とした攻撃も考慮する必要があります。
よって、自動車における脆弱性チェーンを踏まえた評価を行なうためにはEnd to Endでの脆弱性情報を管理する必要があるため、完成車メーカ内の設計・テスト情報のみならず、サプライヤにおけるセキュリティ脆弱性の評価結果を含めた管理が重要となります。具体的に必要な情報は以下の４項目です。
- 各車両に搭載されているECU情報
- 各ECUのセキュリティ設計情報
- 各ECUの侵入テスト結果、脆弱性が見つかっていた場合はその修正方針及び修正適用対象車両
- 各ECUのセキュリティ設計後に発生した主なソフトウェア更新内容
これらは一朝一夕、かつ自動車セキュリティ担当部門だけで収集することは困難ですのでサプライヤと連携しながらR&D全体で情報整備を進める必要があります。また実際に脆弱性を発見した際には早急な調査や対策が求められるため、これらの情報をいち早く収集・分析するためにも、完成車メーカ－サプライヤ間の責任分担を明確にし、脆弱性監視や調査・対応のプロセスや体制を構築しておくことが重要になります。
