メインコンテンツに移動する

マルチメディアのセキュリティ強化

トヨタ、ブラック・ダック、デロイト トーマツによる手の内化とセキュリティテスト

自動車業界がSDV(Software-Defined Vehicle)時代を迎える中、車載システムのセキュリティ確保は喫緊の課題です。特にマルチメディアをはじめとするIn-Vehicle Infotainment(以下、マルチメディア)は多様な通信プロトコルと接続するため、従来のカーナビゲーションとは比較にならないほど広範囲なアタックサーフェスを抱えています。トヨタ自動車はこの課題に対し、ブラック・ダック・ソフトウェア合同会社、デロイトトーマツサイバー合同会社との協働プロジェクトにより、ファジングテストを中心とした包括的なセキュリティテストプロジェクトを実施しました。本稿ではそのプロジェクトを推進した3社のキーパーソンを迎え、プロジェクトの全体像や技術的な取り組み内容を紹介するとともに、ソフトウェア開発の“手の内化”への道筋や今後の展開について伺いました。(本文敬称略)

出席者

倉茂 廉太郎氏
トヨタ自動車株式会社
ソフトウェアPF開発部 IVI ソフトウェア開発室

土谷 宜広氏
ブラック・ダック・ソフトウェア合同会社
ストラテジック営業本部 営業部 リージョナルセールスマネージャー

古賀 一眞氏
ブラック・ダック・ソフトウェア合同会社
カスタマーデリバリーエンジニア/コンサルタント

松本 匡氏
ブラック・ダック・ソフトウェア合同会社
カスタマーデリバリーエンジニア/コンサルタント

片山 泰輔
デロイト トーマツ サイバー合同会社
ディレクター

太田尾 亘
デロイト トーマツ サイバー合同会社
マネジャー

SDV時代の中核技術 ――マルチメディアのセキュリティ課題と取り組み体制

――(太田尾) 最初に基本的な質問ですが、「マルチメディア」とは何でしょうか。

倉茂:マルチメディアとは、ナビゲーションや音声認識、エンターテインメントなどの機能を統合した次世代の運転席周辺システムです。クラウドを介してソフトウェアを追加すれば様々な体験をお客様に提供できるため、MaaS(Mobility as a Service)の中枢を担うシステムに位置づけられています。

ただし、マルチメディアはBluetoothやWi-Fi、携帯回線など多様な無線ネットワークと接続するため、アタックサーフェスも広範囲にわたります。そのため、サイバー攻撃の標的になりやすく、従来のカーナビゲーションとは異なり、ITシステム同等のセキュリティ対策が必須なのです。

倉茂 廉太郎氏(トヨタ自動車株式会社 ソフトウェアPF開発部 IVI ソフトウェア開発室)

――(太田尾) 今回のプロジェクトは、トヨタ、ブラック・ダック、デロイトの3社によるマルチメディアの高度化と安全性の検証が目的だと伺っています。それぞれの役割と、連携体制について教えてください。

片山: 本プロジェクトは、トヨタが主体となって進めたマルチメディアの開発において、我々3社が協力しながらセキュリティテストを実施した取り組みです。デロイトは、主に脆弱性スキャンやセキュリティ機能テスト、ファジングテストなど、テスト工程全般においてトヨタのチームと連携しながら支援を行いました。

ブラック・ダック(土谷): ブラック・ダックはファジングテストの専門家として参画し、自社ツール「Defensics」を提供しました。このツールを活用して、BluetoothやWi-Fi、Ethernetなど多様な通信プロトコルに対するファジングを実施しました。

ブラック・ダックは、オープンソースの脆弱性やライセンスリスクの管理に強みを持つアプリケーションセキュリティ企業です。SCA(ソフトウェア構成解析)やSBOM(ソフトウェア部品表)対応に加え、ファジングなどの動的解析技術にも注力しており、DevSecOpsの現場で広く利用されています。

※ファジングとは、対象ソフトウェアに意図的に不正なデータや予期しない入力を送り込み、その反応を観察して未知の脆弱性を洗い出すテスト手法

土谷 宜広氏(ブラック・ダック・ソフトウェア合同会社 ストラテジック営業本部 営業部 リージョナルセールスマネージャー)

――(太田尾) デロイト トーマツはなぜこのような車両領域のセキュリティテストについて支援ができるのでしょうか

片山:私自身もかつて車載ソフトウェアの開発やペネトレーションテストに従事していました。今回デロイトが加わった背景には、トヨタ社内をはじめ、自動車業界全体でセキュリティ分野の専門人材が不足しているという課題があります。デロイトには、車載ECUや通信プロトコルに詳しい技術者が多数在籍しており、そうした人材がトヨタの評価チームと連携しながら、技術面の支援を行っています。

倉茂: トヨタはプロジェクト全体の企画・推進を担当しました。社内規定に基づくプロセス設計や品質要件の設定、各部署との調整、設計方針の意思決定などを一手に担いました。
今回のプロジェクトはソフトウェア開発を社内で開発・テストできるようにする“手の内化”の一環として位置づけており、将来的にソフトウェアのセキュリティテストを自社で実施できるよう、両社の専門的な支援を受けながら進めました。

トヨタの社内体制としては、マルチメディア開発のセキュリティメンバーを設計、開発、テスト、プロセス改善、PSIRT(Product Security Incident Response Team:製品セキュリティインシデント対応チーム)など専門分野に応じて分担し、その中の評価チームは海外拠点と連携しながらペネトレーションテスト、脆弱性スキャン、ファジングテスト、セキュリティ機能テストを担当しました。

OTA時代に求められる開発スピード、トヨタが“手の内化”にこだわる理由

――(太田尾) “手の内化”について伺います。トヨタが車載ソフトウェアの自社開発を推進しているのは、どのような理由からでしょうか。

倉茂: 従来のマルチメディアでは、仕入先様と連携してソフトウェア開発することが多くあります。私たちは主にスケジュール管理や全体調整を担当し、実際の設計や実装は仕入先様が担っていました。しかし、この体制では不具合や仕様変更が発生した際に、修正の依頼から実装完了までに時間がかかってしまう課題がありました。特に、OTA(Over-the-Air)による迅速なアップデートが求められる中で、このスピード感の遅さは大きな制約となっていたのです。

そのため、ソフトウェアの“手の内化”、つまり社内での開発体制の構築が重要になりました。手の内化することで、不具合や仕様変更など想定外の事象が発生した際にも、社内の開発チームと迅速に連携し、最短で翌日から修正に着手できます。外部調達の場合には着手に多くの時間を要することもありますが、内製であればスピードが圧倒的に違います。

現在トヨタでは、SDVの考え方を基盤に、アジャイルな手法で継続的にアップデートを重ねていく体制にシフトしています。そのためには、ソフトウェア開発だけでなくセキュリティも含めて、自社で一貫して実施できる体制が必要だったのです。

――(太田尾) 今回のプロジェクトは、ブラック・ダックやデロイトが外部業者としてセキュリティテストを請け負うのではなく、トヨタの手の内化を支援する側面が強かったのですね。

倉茂: そうですね。今回の取り組みは従来のテスト委託ではなく、将来的なセキュリティ人材の育成や、社内運用体制の確立を見据えたものでした。

現在、高度なスキルを持つセキュリティ人材の多くがベンダー側に集中しており、メーカー内部での人材確保や定着が難しい状況です。加えて、セキュリティエンジニアは主体的に手を動かしたいという志向が強いため、受動的な業務に終始する環境では、長期定着化が難しいという課題もありました。

そこで私たちは、「仕様を仕入先様にお渡しして開発スケジュールと品質を管理する」従来のスタイルを見直し、開発と並走しながら、社内でテスト・プロセス改善を回す体制にシフトしたのです。現在はセキュリティ領域でも、自ら手を動かして実務に携われる環境が整いつつあります。とくにマルチメディアや車載システムの分野に関心のある技術者にとっては、チャレンジングかつ実践的なフィールドだと感じています。

管理や調整だけでなく、開発・テストなど現場での実装に関わりたい、自身で手を動かしてテストを実施していきたいと考えているセキュリティエンジニアの方には、ぜひトヨタの取り組みに注目していただきたいです。

――(太田尾) 現時点での手の内化の進捗はいかがですか。

倉茂: アプリケーションレイヤーのセキュリティについては、ほぼすべて手の内化しています。UI周辺も含め、最もユーザーに近い領域は既に完結しています。

多様な通信プロトコルに対するファジングテスト

――(太田尾) 次にセキュリティテストについて伺います。どのようなアプローチでテストをしたのですか。その内容を教えてください。

倉茂: まずセキュリティが設計どおりに実装されているか確認するセキュリティ機能テストがあります。そのほか、既知の脆弱性を発見するテスト、未知の脆弱性を発見するテストがあります。今回、未知の脆弱性を発見するテストの一つとして、ブラックボックス型のファジングテストを実施しました。これら一連のテスト手法を効率的に組み合わせることが重要で、どれか一つだけでは不十分です。

――(太田尾) ファジングテストとは具体的にどのようなテストなのでしょうか。

ブラック・ダック(松本): ファジングとは、対象ソフトウェアに意図的に不正なデータや予期しない入力を送り込み、その反応を観察して未知の脆弱性を洗い出すテスト手法です。従来の静的解析や既知のシグネチャベースでは発見できない問題を検出できます。

今回はDefensicsを用い、BluetoothやWi-Fi、Ethernetなどの通信プロトコルに対してパケットレベルでの入力異常を与えてマルチメディアの挙動を観測しました。Defensicsは単に異常の有無だけでなく、「どのプロトコルの、どの領域が問題を引き起こしたか」までを可視化できます。 

松本 匡氏 ブラック・ダック・ソフトウェア合同会社 カスタマーデリバリーエンジニア/コンサルタント

倉茂: 国際規格 ISO/SAE 21434でも、セキュリティテストの手法としてファジングが例示されており、車両セキュリティ確保に不可欠な技術です。我々もこの規格に準拠してセキュリティテストを実施しています。

――(太田尾) ファジングツールに求める要件とは何ですか?

倉茂: 最も重要な要件は、対応プロトコルの幅広さです。マルチメディアではWi-Fi、Bluetooth、USBなどスマートフォン向けの通信手段に加え、CAN(Controller Area Network)やSOME/IPといった自動車固有の通信プロトコルにも対応する必要があります。

市販のセキュリティテストツールは、HTTPやREST APIなどWebサービス系に特化したものが多く、車載システムを網羅的にカバーするには不十分です。その点、Defensicsはこれらの多様なプロトコルに対応しており、私がファジングテストで実現したい要件をすべて満たしていました。

また、ファジングの妥当性を定量的に説明できる点も重要でした。Defensicsは送信するファズデータ(意図的に異常や予期しない値を含んだ入力データ)の構成や対象プロトコルのカバレッジをレポートで可視化できるため、テストの妥当性を説明しやすいという利点があります。

片山: もう一つの利点は柔軟なカスタマイズ性です。車載システムでは、通信タイミングやタイムアウトの挙動が製品ごとに異なり、汎用的なテストケースがそのまま使えないこともあります。Defensicsは、こうした機器固有の条件にあわせてエラー判定を細かく調整できるため、実運用に即したテストが可能でした。

ただしその分、初期設定の調整には一定の手間と時間がかかります。とはいえ、実際の車載システムにフィットする柔軟性は大きな強みでした。 

片山 泰輔 デロイト トーマツ サイバー合同会社 ディレクター

立ち上げ期の試行錯誤 ――技術面・組織面の課題と突破口践

――(太田尾) プロジェクト立ち上げ初期には、技術面や組織面でさまざまな壁があったかと思います。どのような点に最も苦労されましたか?

倉茂:最も悩んだのは「ファジングテストの妥当性」をどう担保するかという点でした。ファジングはブラックボックステストの一種として実施されることが多く、特に何が起こるか予測しづらいのですね。そのため、どのようなデータや条件で実施すれば十分なテストになるのか、手探りの議論が続きました。

また、社内の期待値調整も課題でした。複数の手法を組み合わせる必要性や、それぞれで検出できる脆弱性の違いを説明しても、「すべての脆弱性が検出できるのでは」と過剰に期待されたり、「なぜ複数のテストが必要なのか」と疑問を持たれたりしました。テストの限界や目的を社内で正しく理解してもらうのに、時間を要しました。

片山: 技術面では、限られた期間と設備で「どの部分を優先的にテストするか」の判断が難しかったです。攻撃者は一つの脆弱性を見つければ侵入できますが、我々には時間的制約があります。デバイスの特性やリスクを見極め、テストの優先順位を付けることに苦労しました。

また、マルチメディアには、トヨタが開発したソフトウェアに加えて、ハードウェアメーカーが提供するドライバや、オープンソースソフトウェア(OSS)なども含まれています。これらの中には、ソースコードへのアクセス権がなかったり、他社が保守していたりするものもあり、トヨタ側で自由に修正できないケースもあります。そのため、脆弱性が見つかった際の対応方針については、ISO/SAE 21434(自動車向けのサイバーセキュリティ規格)を参考にしながら、リスク値の評価を行い、関係部署と協議を重ねて判断する必要がありました。

倉茂:テスト環境の整備も大きな課題でした。開発中の製品は仕様変更が頻繁にあるため、セキュリティ品質を維持しつつ脆弱性の修正と継続的なテストを両立させる必要がありました。24時間体制のテスト実施やテストの自動化にも試行錯誤がありましたね。

――(太田尾) ファジングを含む今回の検証では、脆弱性の発見だけでなく、設計や開発プロセスにも影響があったと聞いています。実際に得られた成果や気づきについて、具体的に教えていただけますか。

倉茂: とくに印象的だったのは、発見した脆弱性が、設計レベルの改善まで及んだ点は大きな収穫でした。テストツールの判定基準や、脆弱性のリスク評価手法の見直しにもつながり、セキュリティテストのプロセスの成熟度を高める契機になったと考えています。

片山: 設計方針の変更に伴い、当初作成したテストケースも随時見直す必要がありました。その際は単なる手順変更ではなく、「なぜこのテストが必要か」という設計上の意図に立ち返り、必要な観点を洗い出して検証項目を追加するように努めました。結果的に、全員が探索的テストの視点を持ちながら、柔軟かつ実践的に対応できたと感じています。

ブラック・ダック(古賀): テストの自動化も大きなテーマでした。たとえば、少ない人員でテストを遂行するためマルチメディアのタッチパネル操作を自動化したり、ツールのレポート結果をそのまま型式認証に必要なドキュメントへと変換できる仕組みを構築し、RPAに近い形で業務の効率化を図りました。 

古賀 一眞氏 ブラック・ダック・ソフトウェア合同会社 カスタマーデリバリーエンジニア/コンサルタント

片山: また、テスト担当とPSIRT担当が密に連携し、検出された脆弱性の対応方針や管理方法についての議論も重ねました。これにより、単発のテストにとどまらず、セキュリティ体制全体の改善にもつなげることができたと捉えています。

知見共有から水平展開まで、今後の展開と業界貢献の実践

――(太田尾) 技術面だけでなく、現場での改善の姿勢にもトヨタらしさが感じられます。今回のセキュリティテストにも、「現場力」や「継続的改善」といった製造哲学は反映されているのでしょうか。

倉茂: はい。たとえば、「自工程完結」という考え方を、セキュリティ領域にも応用しています。これは、評価チームが最終段階で不具合を見つけるのではなく、各工程の担当者が自らの作業品質に責任を持ち、問題のない状態で次工程に引き渡すという思想です。

――(太田尾) テストを最終段階で行うものではなく、日常の開発プロセスに組み込んでいくという考え方ですね。

倉茂: その通りです。より良いプロセス、セキュリティテストにしていく改善文化も、今回の取り組みで重視した点です。ファジングで見つかった課題を開発プロセスに反映し、セキュリティテストを開発プロセスに織り込むことができるように継続的に改善します。

――(太田尾) 今回の取り組みを踏まえ、今後はどのような展開をお考えでしょうか。 

太田尾 亘 デロイト トーマツ サイバー合同会社 マネジャー

ブラック・ダック(土谷): 今回のような取り組みを通じて、セキュリティテストの実践知が蓄積されつつあることは非常に意義深いと感じています。今後は、車両バリエーションの増加に対応していくためにも、テストのさらなる自動化が重要になります。特に、脆弱性スキャンやポートスキャンといった定型的なテストについては、自動化の余地がまだ多く残されており、効率化とセキュリティ品質確保の両立を図っていく必要があります。

倉茂: 社外に向けては、トヨタの他部署とも連携しながら、OSSコミュニティへの脆弱性情報のフィードバックや、JASPARなど業界団体を通じた知見の共有を進めていきたいと考えております。こうした取り組みにより、日本全体の車両サイバーセキュリティ水準の底上げに貢献したいと考えています。

また社内では、他ECU開発部門にも展開を広げており、実験設備の見学やテスト手法の紹介を通じて、ノウハウの水平展開を図っています。

片山: デロイトもカンファレンスや所属業界団体等を通じて、セキュリティテストの重要性を広く発信していきたいと考えています。デロイトの日本法人には、実車環境でのペネトレーションテストを専門とするチームが在籍しており、今後もテスト手法の高度化に向けた技術支援を継続していきます。

――(太田尾) セキュリティを「製品品質の一部」として捉え、改善と自律的な取り組みを積み重ねていく姿勢は、業界全体にとっても大きな示唆となるものだと感じました。本日は貴重なお話をありがとうございました。