Automotive Security Engineering

1 / 18

2015, Vector Consulting Services GmbH

セキュリティーエンジニアリングの成功要因

Dr. Christof Ebert

Vector Consulting Services GmbH (シュツットガルト)

※ 本稿は、2015 年 4 月に Vector Consulting Services GmbH（ドイツ）が発行したテクニカル

アーティクル「Success Factors for Security Engineering」をベクター・ジャパン* が和訳した

ものです。

要約

セキュリティーに対する懸念が業界の垣根を超えて広がっています。システムが相互接続され、

外部からの侵入に大なり小なりオープンである今日の状況では、セキュリティーはすでに、持たずに

済まされるものではなくなっています。さらに悪いことに、セキュリティーは機能に直接影響を及ぼす

ため、それに対する製造物責任が問われるようになりました。たとえば、機能安全は情報セキュリテ

ィーをカバーする簡明なアプローチなしには実現できません。自動車メーカーやサプライヤーは、自

動車セキュリティーに固有の課題を踏まえたうえで、自動車 E/E システムの不正な操作に対する効

果的な防御を実現しなければなりません。保護された E/E システムを開発する際の重要ポイントと

しては、セキュリティー要件の適切な特定、セキュリティー機能のシステマティックな実現、セキュリ

ティー要件が満たされたことを実証するためのセキュリティーの妥当性確認が挙げられます。本稿

では、複数の顧客プロジェクトでの経験を基に、セキュアなシステムを作り出すにはセキュリティー

エンジニアリングにおけるどのようなアクティビティーが必要になるのか、そしてどのようにすれば、

それらのアクティビティーを自動車開発において効率的に実施できるのかを紹介します。

本稿は常時更新されています。最新版（英語版）は Vector Consulting Services

(mailto:[email protected]) から入手いただけます。

* ベクター・ジャパン株式会社 www.vector-japan.co.jp

mailto:[email protected]

2 / 18


Vector Consulting Servicesは、製品の技術開発の最適化に焦点を合わせ、グローバルに展開

するコンサルティング会社です。自動車から情報技術、医療、運輸、航空宇宙に至る著名な企業が、

同社の専門的なソリューションを、製品開発の改善、製品戦略策定、組織内の変更管理とインテリ

ムマネージメント（一時的なマネージメント業務委託）のために利用しています。Vector Consulting

Servicesは、1,300名の社員を有するベクターグループの一員として、製品ライフサイクル全体をカ

バーする持続可能なコンサルティングソリューションと、それに関連したプロセスおよびツールで、世

界中のお客様をサポートしています。同社のマネージメントは共同出資者によって行われており、そ

れによって独立性と顧客指向のコンサルティングが保証されています。

詳しくは www.vector.com/consulting （英語サイト）をご覧ください。

Dr. Christof Ebert：Vector Consulting Services取締役社長。世界各地の顧客に対し、製品戦略

や製品開発の改善と組織変革の支援を行う。各諮問機関・業界団体で活動する傍ら、University of

Stuttgartで学生の指導に当たる。

http://consulting.vector.com/vc_index_en.html

3 / 18


セキュリティーエンジニアリングの成功要因

1. はじめに

高速道路の夜のドライブ。ディスプレイが点滅し、唐突にスピーカーから飛び出す「ピー」という音。

驚いたドライバーがディスプレイを確認し、音を止めようとしたところで事故が発生―。これは現実で

しょうか。それともフィクションなのでしょうか。複雑化とネットワーク化が進み、標準コンポーネントや

オープンインターフェイスが使用されるのに伴って、各種の電子システム、特にインフォテインメント

のシステムの脆弱性が高まり、その保護が求められるようになりました。

今日の機能安全には、情報セキュリティーが必要です。実際のところ、情報セキュリティーとは何

なのでしょうか。それは基本的にシステムの属性の 1 つであり、可用性、機能安全、ロバスト性、そ

してパフォーマンスと密接に関連しています。システムにおける「品質」とは一般に、自らに求められ

ているすべての事柄を、そのシステムが実行することを指します。情報セキュリティーはこのような

古典的な定義の範疇を超え、システムが悪意のある攻撃下においても、求められた事柄以外を行

なわないことを意味します。

情報セキュリティーが現在、そして将来の電子システムに及ぼす影響は拡大しています。自動車

の快適性、信頼性、安全性に関わる機能が、複数の電子制御ユニット (ECU) 上のソフトウェアアプ

リケーションの分散協調制御によって実現されるケースは増える一方です。レーダー/カメラシステ

ムといった革新的なセンサーや、極めて複雑なインフォテインメントおよび運転支援システムの開発

が進むのに加えて、自動車の車外ネットワークへの接続も明日の技術革新を後押ししています。イ

ンターネット接続は自動車ユーザーの情報ニーズを満たすだけではありません。eCall などの機能

や、車と車、あるいは車とインフラストラクチャーの間の通信 (Car2x) によって交通も進化するはず

です。インテリジェントな交通信号、自動車メーカーのバックエンドシステムから提供される最新の地

図データ、路側機からの警告、付近の車両のブレーキランプなどからの情報に基づく制御により、

車の流れが改善されることもその 1 つです。先進運転支援システムや自動運転は次第に日常のも

のとなりつつあります。

4 / 18


接続が増えれば車両への攻撃のリスクも高まります。一般的な IT/通信領域での多くの事例から、

分散型システムや通信が盗聴、メッセージ内容の操作、リソースの使用といった不正操作を受けや

すいことは周知のとおりです。車両でのデータ処理や通信のアクティビティーも例外ではありません。

むしろ、車とその E/Eアーキテクチャーの特性に起因して、他の多くのシステムよりも簡単に不正操

作が行われる恐れすらあります。

図 1：最新の自動車の接続機能

図 1は、車両に搭載された分散システム内の接続と、車両から環境への接続を示しています。無

線/有線に関わらず、どの接続にも潜在的な攻撃のリスクがあります。単に脅威の種類が異なるに

過ぎません。コネクターを経由した場合、アクセス可能な車両はその 1 台のみであるためリスクは

限定的ですが、遠距離無線接続には世界のあらゆる場所からアクセスできるため、その危険度は

はるかに大きくなります。しかし、走行中や駐車中の車からアクセスできる、タイヤ空気圧監視シス

テム、Bluetooth、無線 LANといった近距離無線接続も重要な役割を果たしています。

攻撃者は、十分な見返りがある限り、利用できるものは何でも利用します。そのため車載システ

ムにおいては、悪用そのものを不可能にするか、または得られる見返りを減らして、不正操作を割

ITS RoadsideStation

Car2x

OEMBackbone

NFC

Distributed onboard

communication across ECUs and

sensor fusion

ISO 15118 –Vehicle to grid communication

BlackBox (data collector) for

insurance, etc.

Off-BoardTester

Tire pressure monitoring via

near field communication.

Passengers internet(Google, E-Mail, ..)

Car Information (weather, traffic,

map, ..)

5 / 18


に合わないものにするかのいずれかが必要です。セキュリティーと信頼性は、現代の車載 IT およ

び電子システムの受容と成功に欠かせません。一般的な IT と電気通信の領域では、不正操作に

対する脆弱性が少ない IT システムを開発すべく、膨大な数の方法、テクニック、ベストプラクティス、

パターンが生み出されてきました。このような、セキュリティーを考慮した開発に関わる研究分野を

セキュリティーエンジニアリングと呼びます。セキュリティーエンジニアリングでは、セキュアな IT シ

ステムの設計、実装、テストのためのプロセス、方法、ツールを扱います。

本稿では、セキュリティーエンジニアリングを自動車システム開発に円滑に組み込むための方法

を説明します。次の 2章では自動車セキュリティーに固有の課題をまとめ、3章では、自動車セキュ

リティーエンジニアリングに関わる複数のプロジェクトで効果のあったソリューションを紹介します。

我々はこれらのソリューションでの経験を基に、セキュリティーエンジニアリングの効率的な応用を

促すいくつかのアクティビティーを割り出しました。4 章ではそれらについて概説します。本稿は常時

更新されています。最新版（英語版）は Vector Consulting Servicesから入手いただけます。

2. 自動車セキュリティーにおける課題

セキュリティーは安全に直接影響を及ぼすため、ドライバーとその周辺環境を保護することは極

めて重要です。セキュリティーエンジニアリング上の不備があれば、その影響が製品の製造責任に

即刻、ダイレクトに表れることを今日の自動車メーカーとサプライヤーはよく知っています。図 2 は、

セキュリティー攻撃から生じるハザードが安全に及ぼす影響を示しています。このようなハザードは、

冒頭の物語にあるような意図的な誤動作によって、あるいは DOS 攻撃などによる意図しない誤動

作によって発生します。セキュリティーエンジニアリングは難しい理論ではないため、十分な能力と

意欲があれば導入できます。ただし、あらゆる車両のライフサイクル全体を通してそれを維持するこ

とが必要です。

自動車セキュリティーでは、偶発的な事象 (ECU の不良による異常動作など) と、攻撃の動機を

持つ人物が意図的に発生させる、以下のような事象の両方に対処しなければなりません。

「チップチューニング」のように、ソフトウェアの設定で有効にできる機能のアクティブ化

車両およびパーツの盗難

コンポーネントの盗用

6 / 18


リモートキーシステム、イモビライザーシステムなどの不正操作

ナビゲーションシステムの地図の入手などを目的とした、テレマティックスシステムの不正操作

さらに、Car2xサービスなどの新機能が、新たな攻撃を煽る恐れがある

図 2：セキュリティーの安全に対する直接的影響

攻撃者は、複数のアクセスポイントから、自動車とその E/E アーキテクチャーに攻撃を仕掛けま

す。多くの場合、車両内のデータ転送に使われる E/E バスへ、物理的なアクセスが可能です。関連

するバステクノロジーの多くには、セキュリティーメカニズムが組み込まれていません。最新の自動

車には接続機能 (Car2x、インターネット接続など）が増えているため、E/Eコンポーネントへのアク

セスが可能な LTE、Bluetooth、無線 LAN、USB といった外部通信インターフェイスが不正操作に

使われる恐れがあります。さらに、攻撃者が ECU ハードウェアに物理的にアクセスすることにより、

パッシブ (サイドチャネル) 攻撃やアクティブな (非) 侵襲型攻撃といった多種多様な不正操作を行っ

て、既存の保護メカニズムを突破することが可能になります。

自動車システムの脆弱性に加えて、攻撃者側と車両側のリソースにも圧倒的な差があり、ソフト

ウェアベースの自動車保護のメカニズムは極めて不利な立場に置かれています[2、3]。攻撃者がほ

しいままに時間を費やしてこれらのメカニズムを突破できるのに対し、保護メカニズムの実行 (メッセ

ージの暗号化など) に与えられる時間は少ししかありません。計算性能やメモリー容量についても

Attack Hazard

People and environment attack the system thus creating malfunctions.

Security: Prevention of unintended behaviors

People and environment can be harmed by malfunctions.

Safety: Prevention of harm and injuries

7 / 18


同様で、攻撃者が 1 台あるいはそれ以上の高性能のコンピューターを使えるのに比べ、車両 ECU

が持つプロセッサーやメモリーのリソースはわずかです。

自動車セキュリティーは比較的新しい問題です。そのため、情報セキュリティーと自動車システム

エンジニアリングの両方の知識を持つ専門家は多くありません。しかも、セキュリティーの基本的な

構成要素 (暗号化アルゴリズムなど) を自動車の環境に適合させたうえ、それらの構成要素をもと

にセキュアなプロトコルを組み上げるのは容易ではありません。

さらに悪いことに、自動車 E/E システムは複雑なだけでなく、その開発と生産は一般に複数の組

織にまたがって行われています。自動車メーカー (OEM) がシステムアーキテクチャーの仕様と各

種コンポーネントの要件を提供し、複数のサプライヤーがそれらのコンポーネントを開発、製造する

のです。一方、セキュリティーとはシステム全体に関わる新しい属性であって、1 つの組織だけで達

成できるものではありません。

3. 自動車セキュリティーエンジニアリングに有効なソリューション

自動車 E/E システムは多様な機能、ECU、通信システムから構成されており、それらはさまざま

な手口の攻撃を受ける可能性があります。攻撃によってどのような影響が出るかは、攻撃対象とな

る具体的な機能に応じて異なります。膨大な数のターゲット、攻撃方法、影響が入り組むために状

況は複雑ですが、これを理解しやすくするために、自動車セキュリティーを 3つの観点に分け、その

それぞれの観点から、関連性のある確認事項を分かりやすくまとめて、その対策を考えていくことに

します。以下にこれらの観点と、それぞれに対応する確認事項を示します[2]。

製品とそのアーキテクチャー：セキュリティーが破られる可能性のあるものは何か。潜在的な不

正操作によってどのようなリスクが生じるか。保護する必要のあるものは何か

セキュリティーのためのエンジニアリング：車両を保護するために実行すべきアクティビティーは

何か。自動車セキュリティーに関する技術的なソリューションには何があるのか。特定の制約

のもとでそうしたソリューションを実装するには、どのような方法を取ればよいか。そのシステム

のセキュリティーは、どのような方法で実証できるか

アフターセールス：保護メカニズムによって診断やパーツ交換などにどのような影響が及ぶか。

SOP (量産開始) まで検出されなかった脆弱性にはどのように対処するか

8 / 18


次の節では、これらの観点 (図 3を参照) につき顧客プロジェクトで成果をあげた手法を説明しま

す。

図 3：自動車セキュリティーに関する 3つの観点

3.1. 製品とそのアーキテクチャー

効率的なセキュリティーへの鍵は、保護すべき (および保護しなくてもよい) 資産がどれかを把握

することにあります。自動車の観点からは、どの車両機能が攻撃者からの攻撃を受け得るのか、そ

して攻撃によってどのような結果が生じるのかを知りたいところです。したがって、セキュリティー対

策の開発に着手する前に、セキュリティー要件を特定することが必要です。セキュリティー要件を徹

底して洗い出さなければ、重要な資産が十分に保護されずに放置されたり、重要でない機能の保

護に無駄な労力が費やされるといった状況が生じかねません。セキュリティー要件には、その他の

要件と同じく、完全であること、一貫性のあること、わかりやすいこと、そしてテスト可能であることが

求められます。また、他のほとんどの要件とは違って、セキュリティー要件では、意図的な不正操作

を含むどのような状況下でも、そのシステムが何をすべきでないかを考えます。そのため、セキュリ

ティー要件を特定するための具体的な方法が必要です。

最近のある顧客プロジェクトで、我々は車載 E/E コンポーネントのセキュリティー要件を特定し、

それらに優先順位を付ける必要がありました。そのために、コンポーネント開発プロジェクトの規模

と複雑さ、そしてセキュリティーエンジニアリングに対するキャパシティーに基づいたアジャイルなア

Product /Architecture

Engineering After Sales

9 / 18


プローチ[1] を、何回かのワークショップの形で実施しました。顧客エンジニアからはコンポーネント

機能とその実装に関する専門知識が提供されました。我々はワークショップの司会進行を行ったほ

か、セキュリティー要件の分析、使用されているテクノロジーの脆弱性と適切な保護メカニズムに関

する知識を提供しました。

このアプローチでの主なアクティビティーには、アブユーザー（不正ユーザー）ストーリーの策定と

評価、そしてセキュリティー関連のユーザーストーリーの作成が含まれます。アブユーザーストーリ

ーは、攻撃者がシステムをどのように不正利用するかを簡潔に、非形式的に記述したものです。ア

ブユーザーストーリーは、開発者に分かりやすい言葉で、インデックスカードに書き込みます。「チッ

プチューニング会社が不正なソフトウェアを ECU にフラッシュ書き換えする」というのがその一例で

す。これらのインデックスカードをホワイトボードの、アブユーザーストーリーが発生する確率とその

影響に応じた位置に貼り付けます。こうすることで、そのアブユーザーストーリーのリスク (図 4) が

明確になります。なお、ここではある事象の発生確率にその影響を掛けたものをリスクとして定義し

ています。

図 4：アブユーザーストーリーのリスク評価

防止すべきアブユーザーストーリーをリスクに基づいて選び出し、セキュリティー関連のユーザー

ストーリーを作成します。たとえば「ECU アプリケーションはいずれも、使用前に認証されなければ

ならない」というのが、セキュリティー関連のユーザーストーリーの一例です。さらにこれに基づき、

特定された脅威への対抗策を実現するためのセキュリティー要件を定義します。

Impact

Probability

AbuserStory 2

AbuserStory 3

AbuserStory 5

AbuserStory 6

AbuserStory 4

AbuserStory 1

High riskMedium risk

Low risk

10 / 18


セキュリティー要件を極めて短い時間枠で特定する必要があったため、このアプローチは効率的

でした。このアプローチは手軽なうえ、結果が簡明で、自動車エンジニアを始めとするその領域の専

門家とのワークショップで利用するのに大変適しています。ただしシステマティックな手順がないた

め、複雑なシステムにはあまり適しません。このアプローチは、システムとセキュリティーの両方の

関係者とその知識に大きく依存します。他のアプローチでこれらの制限を乗り越えることはできます

が、その代わりに手間が増えます。セキュリティー要件の分析方法の概要は [2] で説明されていま

す。

どのアプローチを使用する場合でも、技術的機能に関わる脅威を特定するには、関連技術だけ

でなく、攻撃者のマインドセットに関する詳しい知識も必要になる点に注意してください。

3.2. セキュリティーのためのエンジニアリング

セキュリティー要件の関心は「何を保護するか」にありますが、「その保護をいかにして実現する

か」を定義するのがセキュリティーエンジニアリングです。それはシステム設計、ソフトウェア構築、

テスト、アフターセールスといった、「通常」のエンジニアリングのあらゆるアクティビティーに影響しま

す。以下では、これらのアクティビティーを説明します。

設計

車両のアーキテクチャー設計で最初からセキュリティーが考慮されていれば理想的ですが、アー

キテクチャーに関する決定の多くは、残念ながら旧モデルの既存のアーキテクチャー、事実上の標

準となっているテクノロジー、コストといった、それとは別の因子に基づいて下されているのが現実で

す。しかも、車両レベルではなく機能レベル（たとえば、リモートキー機能、イモビライザー機能、タコ

メーター機能などといったレベル）でしかセキュリティー要件が特定されていない場合が少なくありま

せん。

結果として、多くの自動車 E/E アーキテクチャーにはセキュリティー機能が組み込まれておらず、

後からセキュリティーを付け足さざるを得なくなります。通常、ある特定の機能の保護メカニズムを

設計する場合には、以下のようなタスクが発生します。

11 / 18


その機能が仕様に従って動作することを保証する。このためには、その機能の実装の不正な

変更に対する保護が必要です

その機能が現在の状況に即して適切に動作することを保証する。このためには、その機能が

入力として使用するすべての情報の保護が必要です

どちらのタスクにも技術的ソリューションが存在し、従来型の暗号や楕円曲線暗号に基づいて完

全性や真正性を提供する暗号アルゴリズムなどを利用できます。ただし、確立されたアルゴリズム

自体は安全だとしても、通信や認証などを規定するプロトコルをそれを用いて設計するのは非常に

困難で失敗しやすく、結果としてセキュリティーを侵害する恐れがあることを改めて強調したいと思

います。

通常、機能の実装を不正な変更から保護することで車両の他の機能に影響が及ぶことはありま

せんが、入力情報を暗号化プロトコルで保護する場合は違います。そのため、車両の E/E バス経

由で送信される情報をセキュリティーで守ることが必要になります。攻撃者がこれらのバスにアクセ

スし、メッセージを不正操作することもありえるため、セキュリティープロトコルの実装は送信側の

ECUと受信側の ECUの両方に組み込む必要があります (図 5)。ベクターは、自動車メーカーやコ

ンポーネントに固有のアドホックな実装ではなく、共通のセキュリティーソリューションを、基本ソフト

ウェアから基盤となるハードウェアまでもを含めて統合することを推進しています。たとえば、ベクタ

ーの AUTOSAR ソリューションは、セキュアなエンドツーエンド通信のためのセキュアな通信プロト

コルを含みます[4]。

12 / 18


図 5：送信側 ECU、受信側 ECU双方へのセキュリティープロトコル組込

我々はある自動車メーカーとのプロジェクトで、基本的なセキュリティーアーキテクチャーの開発と

そのリファレンス実装をサポートしました。このアーキテクチャーは、セキュリティークリティカルな通

信のためのセキュリティープロトコルをシステムレベルで規定しています。セキュリティーアーキテク

チャー単体に対する試行とテストは、多数の個別機能のテストに比べより徹底的に実行できるため、

より高いレベルの成熟度とセキュリティーが得られます。これと併せて専用のセキュリティープロトコ

ルを開発し、標準コンポーネント要件の仕様の上位レベルに導入しました[4]。

実装

セキュリティークリティカルな機能では、その設計だけではなく、実装も楽ではありません。まず、

攻撃者が利用できるリソース (タイムスパンが長く、コンピューティング性能が高い) と ECUが利用

できるリソース (タイムスパンは短く、低性能) の間には差があります。効果的な暗号アルゴリズム

は大量のリソースを消費することが多いため、通常はターゲットの ECUに専用に実装しなければな

りません。第二に、バッファーオーバーフローを引き起こす入力などの不正操作に対し、コードがロ

バストでなければなりません。第三に、高度な技能を持つ攻撃者が、サイドチャネル攻撃や侵襲型

攻撃などのハードウェア攻撃を実行する可能性があります。

External communication

moduleHSMGateway

Body

Chassis

Powertrain

ADASInfotain-ment

Low security zone

Medium security zone

High security zone

ECU 2

Security protocolimplementation

Functionimplementation

ECU 1

Security protocolimplementation

Functionimplementation

Protectedmessage

Com

pany 1

Com

pany 2

Dependancy

13 / 18


リソースを効率的に利用する実装はセキュリティーに固有のものではないため、ここでは特に取り

上げません。我々が最近の顧客プロジェクトで見る限り、セキュアなコーディングルールを導入する

ことによって、ソフトウェアの潜在的な脆弱性を明らかにし、結果としてそれを減らすことができます。

このようなセキュアなコーディングルールでは、たとえば C プログラミング言語の場合であれば、セ

キュリティーが確保されないコーディングの慣行や、悪用される恐れのある未定義の挙動が禁止さ

れています。原則として、MISRA-C のガイドラインを利用することと、コンパイラーの警告レベルを

最大に設定するなどの「無料」でできる対策をすべて講じることをお薦めします。可能であれば、

LDRAの TBsecure を始めとする自動解析ツールを使用してルールを厳密にチェックし、適用してく

ださい。

ハードウェア攻撃への防御策としては、耐タンパー性のあるハードウェアの採用が考えられます。

このような対策を講じた場合でも、それに加え攻撃が拡大しないようなシステム設計、すなわち攻撃

を受けた ECUが他の要素に影響を及ぼさないような設計を心掛けてください。セキュアな実装に関

しても、結局のところは、コーディング言語と環境に対するしっかりした基礎知識が必要です[4]。

検証および妥当性確認

セキュリティーの脆弱性は、コンセプトレベル (セキュアでない通信プロトコルなど) と実装レベル

(タイミング攻撃への脆弱性など) の両方から生じます。そのため、セキュリティー要件からセキュリ

ティークリティカルな機能 (およびその保護メカニズム) の設計、そして実装に至る全体で、セキュリ

ティーコンセプトを厳格に検証することが必要です。セキュリティークリティカルなソフトウェアの開発

にも、Automotive SPICE などでベストプラクティスとして推奨されている、異なるレベルでのレビュ

ー、インスペクション、テストといった検証メカニズムを使用できます。

我々はある顧客プロジェクトで、セキュリティー要件のレビューとセキュリティーアーキテクチャー

のインスペクションを実施しましたが、それらの初期フェーズで特定された問題は、比較的低コスト

で除去できました。このプロジェクトでは、ECU やネットワークの設計と解析に広く使われているツ

ールを使用して、セキュアな通信プロトコルの設計に基づくシミュレーションも行いました。これによ

って、複雑な環境でのセキュリティー特性を、実際のハードウェアがなくても、早い段階から評価す

ることができました (図 6)。

14 / 18


図 6：ベクターのモデリング／テストツールを使用した、セキュリティープロトコルのシミュレーションとテスト

システムのセキュリティーに対する妥当性確認、すなわちシステムのセキュリティー要件に照らし

た実際のシステムのパフォーマンスのチェックにおいて、検討すべきアプローチは 2 つあります。ま

ず挙げられるのはセキュリティーメカニズムの機能テストで、これによってその実装が要件に適合し

ており、すべてのセキュリティー要件が実現されていることを確認する必要があります。これは「通

常」の妥当性確認テストと変わりません。これに加えてお薦めするのが侵入テストです。これはセキ

ュリティー要件とは別個に、システムへの攻撃をシミュレーションするテストです。最初のアプローチ

は通常のテスト担当者が実行できますが、2 番目のアプローチには専門的なセキュリティーの知識

が必要です。つまり、このようなテストを設計し、テスト結果を解釈するには、攻撃者のマインドセット

をもつことが欠かせません。

3.3. アフターセールス

セキュリティーメカニズムによる制約の下で、アフターセールスのアクティビティーを効率的に行う

には、いくつかの課題への対応が必要です。不正操作へのセキュリティーを確保し、物流面の負担

も適正化したうえで、フィールドでソフトウェア更新を行うにはどうすればよいのでしょうか。ベクター

SecurityProtocolDesign

Specification

Test Cases

Simulation / Test

Test Results

15 / 18


は現在、AUTOSAR 基本ソフトウェア内のセキュアな通信プロトコルに力を入れており、進化するプ

ロトコルスタック上での安全なエンドツーエンド通信の実現を図っています。ただし、これに関わる物

流インフラを具体的にどう実現するかを考えなければなりません。

アフターセールスにおける重要な観点のひとつに、すでに市場に出ている車両でセキュリティー

問題が検出された場合、自動車メーカーとサプライヤーがどう対処すべきか、という点があります。

そういったシナリオは、車両の SOP 前に予想して、行動と責任を定めた手続きを準備しておく必要

があります。計画しておくべき行動としては、問題のリスクアセスメント、クリティカルなソフトウェア脆

弱性の修正、フィールドでのソフトウェア更新などが挙げられます。問題に効率的に対処するには、

自動車メーカーとサプライヤーの円滑な連携が必要です。

4. セキュリティーエンジニアリングの促進

セキュリティーエンジニアリングのためには、顧客状況にあったカスタムメイドのソリューションが

必要です。それ 1 つですべてのアーキテクチャー、製品、実際のユースケースに対応できる、という

ソリューションはありません。たとえば、我々は多くの顧客プロジェクトにおいて、顧客固有の環境と

セキュリティーリスクに合わせて修正したチェックリストを使用しています。このチェックリストは本来

は汎用的なものですが、たとえば多くの情報セキュリティー評価基準を適用するような場合、リスク

の曝露とセキュリティーのコストのバランスを考えなければなりません。セキュリティー対策によって

は多大なコストが生じることもあるため、常に優れたビジネス感覚が必要です。コモンクライテリア

（CC、IT セキュリティー評価基準）やコードチェッカーを使うように言われて導入したものの、膨大な

オーバーヘッドが発生してしまった、という話はよく耳にします。MISRA 規格を個々の環境に適合さ

せずに使用するケースはまずありませんが、それと同じく、リスク、コスト、能力に合わせてセキュリ

ティールールを調整する必要があります。

適用されるアプローチとは独立に、セキュリティーエンジニアリング全般の導入と実施を助けるア

クティビティーもいくつか判明しています (表 1) [1、2、3、4] 。ただし、これらが唯一の有効なソリュ

ーションであるというわけではありません。企業文化、これまでの経験、プロジェクトの規模や複雑さ

などによっては、他のソリューションの方が適していることもありえます。

16 / 18


アクティビティーメリット

セキュリティーエン

ジニアリングのア

クティビティーを含

んだ、開発プロセ

ス定義

セキュリティーエンジニアリングのアクティビティーが、場当たり的にではなく、

「通常」の開発の中で円滑に把握、スケジュール、実施されます。プロジェクト

の最初から最後までセキュリティーが考慮されます。さらに、たとえば「構成

管理プロセスによって、セキュリティー脆弱性のテストを行っていない修正が

安易に適用されるのを防ぐ」といった相乗効果も生かせます。

セキュリティー要

件のシステマティッ

クな洗い出し

保護が必要な要素を当初から把握することにより、セキュリティーの厳重な実

現が可能になります。さらに、セキュリティー要件をもとに、セキュリティーの

妥当性確認を行うためのテストケースを導出できます。

セキュリティー関

連作業成果物の

包括的なレビュー

／テスト

セキュリティー要件やセキュリティーコンセプトなどのセキュリティーエンジニ

アリングの成果物をレビューするほか、セキュリティー機能のシミュレーション

とコード解析を行うことで、可能な限り早い段階で脆弱性を特定できます。

解析／テストツー

ルの使用

自動化ツールによって負担が軽減され、効率的かつ包括的な解析と (回帰)

テストが可能になります。たとえば、ベクターのモデリング／データ管理環境

である PREEvision は、開発ライフサイクル全体を通して上記が確実に実行

されることを支援する、協調設計／データ管理環境を提供します。

組込セキュリティ

ー開発能力の確

保

脆弱性の特定、セキュリティーアーキテクチャーの設計、セキュアな実装、セ

キュリティーテストの実施、セキュリティー関連の作業成果物のレビューとい

ったセキュリティーエンジニアリングのアクティビティーの多くには、組込セキ

ュリティーの専門知識が必要です。この専門知識がなければ、効率的なセキ

ュリティーエンジニアリングはほぼ不可能です。そのため、組込セキュリティ

ーの能力を組織内で育成するか、外部業者から調達します。

表 1：セキュリティーエンジニアリングを促進するアクティビティー

5. まとめ

セキュリティーエンジニアリングは、自動車メーカーとサプライヤーのいずれにとっても難題です。

現状では自動車セキュリティーはお客様の注目を浴びているとは言えないかもしれません。しかし

17 / 18


我々は、セキュリティーが今や当然のものとなった他の業界の教訓から学ぶべきです。本稿では、

我々が自動車業界の中で応用してきたセキュリティーエンジニアリングのアプローチをいくつか説明

しました。

他のセキュリティークリティカルな業界での実績を、以下のような形で自動車システムに生かさな

い手はありません。

サイバーセキュリティーの原則と方法を応用し、組込分散制御システムを堅牢化する

IT規格である「コモンクライテリア」を自動車 IT インフラストラクチャーへ適合させ、保護プロ

ファイルを作成する

自動車業界では同時に、セーフティーエンジニアリングとセキュリティーエンジニアリングのアプロ

ーチを整合させると同時に、経済性を維持することが極めて重要です。

脅威モデリングを、ハザードリスク分析の一環として適用する

セキュリティーのさまざまな側面 (真正性、完全性、機密性など)や資産とアクセス方法の妥

当性 (攻撃強度など) などにセキュリティーレベルを適用し、それを自動車用安全度水準

(ASIL)に対応させる

アーキテクチャーの設計と評価、セキュリティー設計、コーディングルール、堅牢化、ロバス

ト化、セキュリティーテスト、開発ライフサイクルのロバスト化といった、基盤となる開発方法

とプロセスの確立。セーフティーとセキュリティーが組み合わされたエンジニアリングのため

の開発支援ツールを活用し、ライフサイクル全体での一貫性を保持する

ベクターは長年に及ぶグローバル市場のトップ企業であり、PREEvision をはじめとする充実した

モデリングツール、テストツールのポートフォリオを提供するだけでなく、世界各地の企業において

セキュリティーエンジニアリング／セーフティーエンジニアリングを効率的に根付かせてきた、豊富な

コンサルティング実績を持っています。これらを通じて、AUTOSAR などの標準ソフトウェアを始めと

する、自動車セキュリティーエンジニアリングにおける必要なすべての領域をサポートします。図 7

では、ベクターのセキュリティー関連製品／サービスのポートフォリオと、それらがセキュリティーを

どう向上させるかを説明しています。

18 / 18


自動車業界は、セキュリティーエンジニアリングの観点で他の業界にキャッチアップしなければな

りません。最近の経験から言えることは、基本的なセキュリティーの専門知識を組織内に早急に構

築し、適切な外部サポート、具体的にはセキュリティーとセーフティーの両方に対応できるサポート

を入手する必要があるということです。成熟した開発プロセスは優れた基盤ではあるものの、セキュ

リティーエンジニアリングのアクティビティーに合わせた修正が必要です。

図 7：自動車のセーフティーとセキュリティーに活用できるベクターのポートフォリオ

参考資料

[1] Ebert, C.:Global Software and IT:A Guide to Distributed Development, Projects, and

Outsourcing.ISBN:978-0470636190-368.Wiley, Hoboken, NJ, USA, 2012..

[2] S. Burton, C. Ebert, et al:Automotive Information Security.VDI, Baden-Baden, 2007.

[3] Ebert, C:Functional Safety with ISO 26262 – Principles and Practice

https://vector.com/portal/medien/vector_consulting/webinar_podcast/Vector_FunctionalSa

fety_BestPractices_Webinar_EN.mp4

[4] A.Happel and C. Ebert:Security in Vehicle Networks of Connected Cars.

https://www.vector.com/portal/medien/vector_consulting/publications/Happel_Ebert_Secur

ity_Connectivity_2015.pdf

Standard Software

Technical measures to protect hardware and software security

Examples: Robustness and Hardening in AUTOSAR, Security adjusted to safety integrity needs

Tools

Consistent approach for all development activities.

Examples: Threat and Hazard analysis during concept definition, consistent modeling in PREEvision

Consulting

Support for methodsand skills as well as the necessary cultural changes.

Examples: Security engineering, culture change, hazard analysis

Documents

Automotive Security Engineering