セキュリティ

自動車における「セキュリティ脆弱性評価」の手法と実践

2020/12/20

セキュリティの脆弱性を定量評価する手法はいくつか提案されていますが、IT向けの手法では自動車の脆弱性を適切に評価できない事例を踏まえ、その評価方法を考察します。本論考における要点は以下の4点です。

脆弱性の評価結果はセキュリティリスクへの対応方針を決めるために重要なインプットであり、リスクの大きさに基づいて脆弱性修正を含む対応方針を決めることが一般的です
CVSSは幅広い業界で採用されていますが、自動車の脆弱性に適用してみると脆弱性を攻撃された場合に発生する影響の大きさを正しく評価出来ない場合があるため、注意が必要です
自動車向けサイバーセキュリティの基準である ISO/SAE 21434では、「重大さ」「攻撃容易性」の2つに分解してリスクを評価する手法が紹介されています
量産前の侵入テストや出荷後に脆弱性が見つかった場合でも適切に影響評価を行なうことを想定し、R＆D全体で設計・テスト情報を管理することが重要です

汎用的に脆弱性を定量評価する手法は、自動車にも適用できるか？

自動車に対するハッキングは自動車業界のビジネス自体を脅かす可能性があると述べた前々回の『CASE時代の自動車におけるサイバーセキュリティの要諦』に続き、前回は『自動車セキュリティにおける、攻撃検知のための「組織・ツール・プロセス」』を解説しました。今回は「自動車セキュリティにおける脆弱性評価手法」をテーマに掘り下げてご説明します。

サイバー攻撃で攻撃者が悪用する脆弱性は、OWASP Top10（Open Web Application Security Project（オワスプ）が提唱する「特にリスクの高い上位10個の脆弱性」）などで紹介されている通り多岐にわたります。そこで、汎用的に脆弱性の特性と重大さを定量的に評価する手法が研究され続けています。

その中で最も有名なものは、情報システムの脆弱性を評価するフレームワーク「CVSS（Common Vulnerability Scoring System」^*1でしょう。CVSSは2004年10月に米国家インフラストラクチャ諮問委員会（NIAC: National Infrastructure Advisory Council）で原案が作成されて以来、継続的に改善が行われており、現在公表中の最新バージョンは3.1です。（2020年11月現在）

CVSSは、クレジットカード会員データを安全に取り扱う事を目的に策定されたクレジットカード業界のセキュリティ基準であるPCIDSS^*2（Payment Card Industry Data Security Standard、ただし参照されるCVSSのバージョンは2.0^*3）など、様々な業界で広く採用されています。

さて、自動車においても脆弱性の評価作業は要件定義時点からアフターセールスフェーズまでエンジニアリングチェーンにおける大半の行程で発生します。脆弱性の評価結果はセキュリティリスクへの対応方針を決めるために重要なインプットであり、リスクの大きさに基づいて脆弱性修正を含む対応方針を決めることが一般的です。

ところが、CVSSを自動車の脆弱性に適用してみると脆弱性を攻撃された場合に発生する影響の大きさを正しく評価出来ない場合があります。なぜそのようなケースが発生するのでしょうか。アクセンチュアが過去に発見した脆弱性を具体例として紹介しながら解説します。

■例１：GPS電波の偽装による位置情報データ改ざん

IVI（In-Vehicle Infotainment）の近くに、衛星から届くGPS電波より強力な「偽のGPS電波」を発信する機材を設置し、「偽の位置情報」を送信するとIVIが自機の位置を誤認識する脆弱性です。例えば、IVIを東京でテストしている際に偽電波で大阪の位置を示すように情報を送付すると、IVIは自機の現在地を「大阪」と認識してIVIの位置を表示してしまいます。

GPS電波の偽装による位置情報データ改ざん。IVI（In-Vehicle Infotainment）の近くに、衛星から届くGPSにおいて電波より強力な偽のGPS電波を発信する機材を設置し、偽の位置情報を送信するとIVIが自機の位置を誤認識してしまう。

自動運転には正確な位置情報が必要なことを鑑みると、確かに位置情報を勝手に偽電波で変えられては困ります。しかし「そこまで大した影響は発生しない」と感じるのではないでしょうか。

ところが、CVSSで評価をすると、この脆弱性は「緊急」「重要」「警告」「注意」「なし」の５段階では上から２番目の「重要」、基本評価基準10点満点中8.2点という高いスコアになります。一般的な情報システムでは早々に修正を検討することが多いスコアです。前述の通り「そこまで大した影響は発生しない」脆弱性のはずですが、なぜスコアが高く出るか、計算に用いられる指標を見てみましょう。

例1: GPS電波の偽装による位置情報改ざんーCVSSv3.1による評価。重大さの評価指標3項目及び影響範囲の評価指標1項目、攻撃容易性の評価指標4項目により基本評価基準のスコアは10点満点で8.2点、深刻度のレベルは「重要」に分類される

ここでポイントになるのは左側に記載した「重大さ評価」です。場合によっては人を傷つけてしまう可能性がある自動車に搭載する機器の評価を、セキュリティの三要素である機密性・完全性・可用性だけで行なうのは、果たして適切なのでしょうか。

続いて、CVSSでは逆にスコアが低く計算される一方で、車両利用者に大きな影響がある脆弱性の例を紹介します。

■例２：エアバックのコントロールユニットに対するセキュリティアクセスの突破

エアバックの作動は、CAN-BUS（Controller Area Networkバス）経由で統合診断サービスメッセージを送信することで実行されます。このメッセージを送るには、"セキュリティアクセス"という防御策を解除する必要があります。

この例はあるECU（電子制御ユニット：Electronic Control Unit）において、セキュリティアクセスの仕組みの問題に起因する脆弱性でした。この脆弱性を悪用すると、CAN-BUSにアクセス出来る攻撃者が、停止している状態の車両に対してエアバッグを膨らませる誤動作をさせることで、車両利用者に怪我を負わせることが出来てしまいます。（詳細はCVE-2017-14937^*4参照）

エアバッグの種類によっては、膨らむ速さが時速300kmに達するものもあり、膨らむ際に車両利用者は骨折ややけどなどの被害を受けることがあります。ところがこの脆弱性をCVSSで評価をすると、「緊急」「重要」「警告」「注意」「なし」の５段階では上から３番目の「警告」、基本評価基準10点満点中4.7点という比較的低いスコアになります。車両利用者の安全が非常に重要であることを鑑みると、脆弱性の重大度を機密性・完全性・可用性の3つの軸のみで評価するのは難しいと言えます。

例2: エアバッグECUのセキュリティアクセス突破ーCVSSv3.1による評価。重大さの評価指標3項目及び影響範囲の評価指標1項目、攻撃容易性の評価指標4項目により基本評価基準のスコアは10点満点で4.7点、深刻度のレベルは「警告」に分類される。

Webアプリ、モバイルアプリ、ネットワーク機器など、あらゆる環境の脆弱性を汎用的に評価できる点においてCVSSは非常に優れたフレームワークだといえます。ですが上記の通り、自動車においてはこのように「違和感が残るケース」が残念ながら存在します。

なお、CVSSv3.1には基本評価基準以外に以下の２つの基準が用意されていますが、本稿では割愛致します。

現状評価基準^*5
脆弱性の現在の深刻度を評価する基準です。攻撃コードの出現有無や対策情報が利用可能であるかといった基準で評価し、CVSS現状値（Temporal Score)を算出します。
環境評価基準^*5
製品利用者の利用環境も含め、最終的な脆弱性の深刻度を評価する基準です。攻撃を受けた場合の二次的な被害の大きさや、組織での対象製品の使用状況といった基準で評価し、CVSS環境値（Environmental Score）を算出します。

自動車の脆弱性に利用される評価手法

では自動車の脆弱性評価に使用される手法にどんなものがあるかを、自動車向けサイバーセキュリティの基準であるISO/SAE 21434^*6（2020年11月時点では策定中、DIS（Draft International Standard）版が公開中）で紹介されている手法とその特徴を参照します。この手法は「使わなければならない」というものではなく、"informative"、つまり参考情報として紹介されている点をご留意下さい。

ISO/SAE< 21434では脆弱性の評価を以下の2つに分解しています。

重大さ：攻撃された場合にどれくらいの影響を及ぼしうるか
攻撃容易性：どの程度容易に攻撃できるか

■重大さに対する評価

ISO/SAE 21434では重大さのランク付けについて、Safety(S)、Finance(F)、Operation(O)、Privacy(P)の４観点でそれぞれSevere／Major／Moderate／Negligibleの４段階評価の方法を紹介しています。機密性・完全性・可用性への影響度で評価するCVSSとは評価観点が大きく異なりますが、車両利用者への影響がよりわかりやすいといえます。

先述の「例１：GPS電波偽装」をこの手法で評価すると、以下のようになります。

Safety: Negligible（傷害なし）
Finance: Negligible（金銭的ダメージなし）
Operation: Moderate（位置情報を使った一部の機能を喪失）
Privacy: Negligible（プライバシー侵害なし）

なお、CVSSと異なり、ISO/SAE 21434ではこの評価に基づき定量化する仕組みは紹介されていません。別の評価手法となりますが「HEAVENS（HEAling Vulnerabilities to ENhance Software Security and Safety）」^*7では点数化し重大さを総合的に定量評価しています。

■攻撃容易性に対する評価

ISO/SAE 21434では攻撃容易性の評価手法として３つのアプローチを紹介しています。

攻撃能力に基づくアプローチ

以下の５項目の評価を点数化し、その総合点で攻撃容易性を4段階に分解する手法です。ISO/IEC 18045で定義されています。
1. 攻撃者が脆弱性を識別し悪用するまでの所要時間
  - 製品やシステムで実装されているプロトコルやハードウェア、構造や採用されているセキュリティの原理などについて知見を持っている
  - アプリケーションやOS・プロトコルなどについての一般的な知識をどの程度有しているか
2. 攻撃対象に対する知識
  - インターネットで得られる公開情報、開発者向け情報、ソースコード含む機密情報など、攻撃対象についてどのレベルの知識を有しているか
3. 攻撃機会
  - 攻撃を実施する対象に物理的な接触が必要なのか遠隔攻撃が可能なのか、またその時間制限があるのかないのか
4. 攻撃に必要な設備
  - 脆弱性を識別・悪用するために必要な設備は容易に入手可能か
CVSSv3.0に基づくアプローチ

ISO/SAE 21434（DIS版）で紹介されているCVSSv3.0では、前述のCVSSv3.1と同様に攻撃容易性を４指標により評価します。
1. 攻撃元区分
2. 攻撃条件の複雑さ
3. 攻撃に必要な特権レベル
4. 攻撃時の利用者関与要否
このフレームワークの攻撃容易性に関する部分のみを使って評価を行なうことは、厳密にはCVSSの使い方に準拠していないという点は留意が必要です。また、CVSSでは脆弱性の影響範囲が攻撃を受けた機能のみか、他機能にも影響を及ぼすか、という点も評価していますが、この手法ではその指標を考慮していません。
攻撃元区分に基づくアプローチ

CVSSの指標に出てくる攻撃元区分のみを使用する簡便な方法です。ハイレベルにリスク評価を行なう場合に適しています。

先程のGPS電波偽装をこの３手法で評価すると、以下のように評価できます。
1. 攻撃能力に基づくアプローチ: High
2. CVSSv3.0に基づくアプローチ: Medium
3. 攻撃元区分に基づくアプローチ: Medium

評価方法について、概説します。

「攻撃能力に基づくアプローチ」を数値化すると、次のように想定できます。
- 所要時間は１週間以内（0点）
- GPSの偽装に関する知見を有していれば実行可能（3点）
- GPS情報に関する情報は公開情報で十分（0点）
- 攻撃機会はIVIが稼働している車両の近辺であるという制約あり（4点）
- 数万円以下の専用機器調達が必要（4点）
括弧内の通りISO/SAE 21434で提案された表に従って数値化すると合計11点、分類は「High」となります。
「CVSSv3.0に基づくアプローチ」では、4指標のスコアを使い数値化します。
1. 攻撃元区分：偽電波の届く範囲なので隣接（0.62）
2. 攻撃条件の複雑さ：安価な装置で実施可能なので低（0.77）
3. 攻撃に必要な特権レベル：認証機能なしであるため不要（0.85）
4. 攻撃時の利用者関与要否：関与不要（0.85）
攻撃容易性指標=8.22xAxBxCxD≒2.8
と算出し、ISO/SAE21434のマッピング表に則り「Medium（2.00～2.95）」と分類します。
「攻撃元区分に基づくアプローチ」の評価は以下の通りです。
- 攻撃元区分：偽電波の届く範囲なので隣接
ISO SAE21434のマッピング表に則り「Medium」と分類します。

なお、アプローチによって導出された分類が異なる結果となっていますが、どのアプローチが正しい、ということはありません。この手法には、評価に際して比較的細かい情報収集や検討が必要となるため、脆弱性評価を行なうフェーズや検討に使える時間などを踏まえ、一貫性のある手法適用を行なうことが重要です。

また、これらの評価手法はCVSS同様、継続的に見直されるものと想定されます。

量産前の侵入テストや出荷後に脆弱性が見つかった場合の評価における考慮事項

設計フェーズでの入念なセキュリティ設計を経ても、「バグを含む実装ミスが見つかる」「利用したミドルウェアにバグが後から見つかる」といったことが高確率で発生することは、避けようのない事実です。

稀にハードウェアの仕様変更を行わないと解消できない脆弱性が発見されますが、この修正には多くのコストが必要となり、「脆弱性を修正せずリスクを受容するかどうか」の判断を管理者は求められます。

自動車側の脆弱性については、ITシステムのように資源が潤沢であったり脆弱性調査を自社資産で実施できたり、といったことが困難なケースが多いため、結果として「当該リスクは受容し、次のモデルイヤーで修正する」というケースが発生する可能性があります。

その際、前述の評価手法は各脆弱性の重大さ・攻撃容易性を定量的に理解するためには有益ですが、それらに加えて「脆弱性チェーン（Vulnerability Chaining）」、つまり「複数の脆弱性を組み合わせての悪用」を考慮する必要があります。なぜならば、新たに発見された脆弱性により「過去の調査で存在を把握したが何らかの事情で修正を行わなかった脆弱性」と組み合わせて悪用される余地があるか、という観点が個別の脆弱性評価では抜け落ちてしまうためです。

具体例として、アクセンチュアが自動車の車両全体を対象とした侵入テストを行なった事例をご紹介します。

自動車に搭載されたあるECUのLinux OSに設定されているパスワードが脆弱であり、総当たり攻撃によりアクセンチュアのテスターがパスワード情報の特定に成功した
ただし、その脆弱なパスワードを入力する攻撃面がすべて適切に要塞化されていた。つまり、そのパスワードを使ってOSへログインし、CANなどを経由して他ECUへ攻撃する方法は見つからなかった

上記の状況において、そのECUの設計・製造を担当する海外ベンダーからは「そのパスワードが分かったところで使い道がないので修正不要だ」と主張されました。

複数回にわたる協議を経て、最終的にこの事例では「パスワードの強度の向上」という対策が取られることになりましたが、仮にベンダーの主張通り「修正なし」とし、その後、当該デバイスのOSへログインする攻撃面が露出する脆弱性が発見された場合の影響は甚大となります。

その攻撃面が無線でアクセス可能なものであれば、そのデバイスのみが検討対象となります。しかし仮にEthernetなどの有線アクセスが必要なものであれば、有線接続している他のデバイスを踏み台とした攻撃も考慮する必要があります。

よって、自動車における脆弱性チェーンを踏まえた評価を行なうために必要な情報は以下の４項目です。これらは一朝一夕、かつ自動車セキュリティ担当部門だけで収集することは困難ですのでR&D全体で情報整備を進める必要があります。