
【特別対談】「プロセス」「組織」「ツール」の三位一体でセキュアなプロダクト開発を実現(パイオニア)
今回はTier1サプライヤーとして車両セキュリティの根幹を支えるパイオニア株式会社のご担当者をお招きし、CSMSに対応した開発プロセスや組織構築の具体的な取り組みなど、CSMS対応製品の開発で留意しているポイントなどについてお話しいただきました。
2023-02-21
国連欧州経済委員会(United Nations Economic Commission for Europe)の自動車基準調和世界フォーラム(WP29)は2021年1月、自動車のサイバーセキュリティ対応の国連標準となる「UN-R155」を策定しました。これにより、自動車メーカーには製品ライフサイクル全般を通じたサイバーセキュリティマネジメントシステム(CSMS)の構築および、セキュリティ対策を含む型式認証(※1)への対応が義務となりました。本連載ではUNR155がもたらすインパクトと車両サイバーセキュリティの未来をテーマに、自動車業界のキーマンをお招きして車両セキュリティ活動に関する知見や今後の展望などを伺います。
今回はTier1サプライヤーとして車両セキュリティの根幹を支えるパイオニア株式会社のご担当者をお招きし、CSMS(Cyber Security Management System ※2)に対応した開発プロセスや組織構築の具体的な取り組みなど、CSMS対応製品の開発で留意しているポイントなどについてお話しいただきました。(本文敬称略)
対談者
パイオニア株式会社 技術開発本部 技術戦略推進部
友部 真一氏
パイオニア株式会社 技術開発本部 技術統括G IVI開発マネジメント部2課
木元 恭平氏
PwCコンサルティング合同会社
ディレクター 山田 素久
PwCコンサルティング合同会社
マネージャー 亀井 啓
(左から)亀井 啓、友部 真一氏、木元 恭平氏、山田 素久
亀井:
CSMS法規が義務化されたのは2022年7月ですが、パイオニアでは法規施行前から組織的なセキュリティ対応の体制構築に着手されていたと伺っています。なぜでしょうか。
友部:
2015年頃からパイオニアが開発を担うプロダクトに、外部接続が可能なWi-FiやBluetooth、USBなどのインタフェースを実装するようになり、自動車電子制御ユニット(ECU)のネットワーク化が急激に進みました。これにより、顧客からのセキュリティに対するニーズは高まりました。当時は社内からも、自動車ECUを狙った攻撃に対する監視活動の必要性を訴える声が高まっていたと記憶しています。
自動車メーカーからサプライヤーに対してCSMSの開発要件概要が説明されたのは2019年末頃でしたが、パイオニアは2019年よりもずっと以前からソフトウェア脆弱性の監視活動を目的として、品質保証部門が主体となるPSIRT(Product Security Incident Response Team)の設立を目指したワーキンググループ(以下、WG)の活動を開始していました。
木元:
パイオニアはカーナビゲーションシステムを軸とした「次世代車載情報通信システム(In-Vehicle Infotainment system:IVI ※3)」の開発を担っています。IVIシステムは、さまざまな通信技術や機能が備わっている複雑なシステムです。開発スピードを上げるため、利用するOSS(Open Source Software)もおのずと膨大になっていました。
2015年の時点で、危機・脆弱性の管理プロセスは確立していました。しかし、当時のソフトウェアの脆弱性管理は、各開発者が開発をしながら担当する機能の範囲で管理している状態でした。この、「ほぼ手作業管理方式」では管理工数が膨大となってしまうため、限界を感じていました。ですから、会社として組織的に管理するプロセスの構築が急務であるとの結論に至ったのです。
友部:
そうした状況下、WP29はサイバーセキュリティ対策を義務付けるCSMSを採択しました。
私たちは情報システム領域のサイバーセキュリティ対策に全社を挙げて取り組んでいました。ただ、プロダクト領域のサイバーセキュリティに関する知見やノウハウは、一部のアーキテクトやバックエンド開発者に依存していることや、複数の自動車メーカーとOEMビジネスを手掛けていることもあり、組織的に対応するためのプロセスの構築を行う契機としてとらえました。
パイオニア株式会社 技術開発本部 技術戦略推進部 友部 真一氏
パイオニア株式会社 技術開発本部 技術統括G IVI開発マネジメント部2課 木元 恭平氏
亀井:
全社へと対応を広げる中で、社内の関連部門を巻き込んでCSMS対応の体制・仕組みを構築するために、どのようなアプローチを採りましたか。
友部:
まずはCSMS対応の体制を構築する手段として、国際規格であるISO/SAE 21434を参照し、既存のプロセス群や社内規定とのギャップを詳らかにする作業から着手しました。その結果、プロダクトのライフサイクル全般で対応するWGが必要だとの結論に至りました。具体的には、市場対応(PSIRT)の「リスクマネジメントWG」、生産・保守・廃棄の「開発後フェーズWG」、開発領域の「セキュア開発・サポートWG」、全社活動の「全体管理WG」の4つのWGを立ち上げて、開発プロセスの構築を一気に推進しました。
この中の開発領域については、新たに組織を作るところから始めました。実は、これまで開発プロセスの社内標準化は、開発者が自発的に提案する方法を採用していました。しかし、CSMS法規に沿った開発プロセスは、そうした方法で策定できるレベルではないと判断したのです。
開発プロセスの構築は、規程を策定して終わりではありません。パイオニアの企業文化にそのプロセスを馴染ませると同時に、開発のスピードアップを図ることも求められます。ですから今後の法規改正にも対応できるよう、専門チームである「エンジニアリング プロセス グループ(以下、EPG)」をケイパビリティのあるメンバーで結成し、技術戦略推進部へ設置しました。
木元:
新たな開発プロセスを策定する作業だけであれば、それほど難しくはありません。しかし、現場には長年馴染んだ開発プロセスが存在します。ですから、既存のプロセスから違和感なく新しく策定したプロセスに移行できるかを考えなければなりませんでした。
そのためには現場で実務を担当している開発者もセキュア開発・サポートWGに参加し、実際に利用している成果物をベースにしながら最小限の変化でISO/SAE 21434に準拠できるよう、既存プロセスを理解することから始めました。
友部:
策定した開発プロセスに沿って作業をするのは開発者ですから、開発者がEPGメンバーと共にセキュア開発・サポートWGへ参加し、策定した規定をレビューしてフィードバックを繰り返すという方法を採用しました。規定を策定する段階でPDCAを回せば、効率的かつ迅速にプロセスを構築できます。
この方法によって、長年馴染んだプロセスの中には「現在は前工程で設計品質を担保しており重複している」「この成果物は後工程で誰も使っていない」といった工程があることが明らかになりました。その結果、「開発プロセス全体を見直してプロセスのスリム化を推進できる」という副次効果も生まれました。
山田:
法規に沿った開発プロセスの作成を目指すのではなく、自社の文化に馴染むCSMS対応の開発プロセスを構築することで、開発自体の価値向上を目指したのですね。EPGの結成段階から“その先の開発”を意識されていたことはすばらしいと思います。
友部:
ありがとうございます。パイオニアは、「A-SPICE(Automotive-Software Process Improvement and Capability dEtermination ※4)に則したプロセスで開発するよう、長年にわたって自動車メーカーから鍛えられていました。そのおかげもあり、社内の開発プロセス群の大部分はA-SPICEに準拠していました。ISO/SAE 21434のコアになる部分はA-SPICEを参照しており、その点ではパイオニアにとって有利に働いたと考えています。
亀井:
現在、組織体制の構築やプロセスの運用はどのような状況でしょうか。
友部:
ISO/SAE 21434への準拠は、2021年末までにプロセスの規定化を完了しました。また、ソフトウェアマネジメントシステム(SUMS)の国連法規である「UN-R156」への対応も2022年春に完了しています。
亀井:
すでに運用フェーズに入っているのですね。実際に運用していく中で、何か気付いたことはありますか。
木元:
開発者にとってISO/SAE 21434への準拠は、作業負担の増加を意味します。私はセキュア開発・サポートWGのメンバーとして開発プロセスを策定する活動に参加していましたが、そこで気付かされたのは、「開発者の作業負担増加を極力抑えつつパイオニアの企業文化に馴染む開発プロセスを構築するには、プロセス、組織、ツールを『三位一体』として考えなければならない」ということです。
山田:
「プロセス」「組織」「ツール」を三位一体として考えるとは、具体的にどのようなことでしょうか。
友部:
この三位一体として考えるということは、「プロセス」を土台に、開発スピードを落とさないようにするスキルを「組織」として教育し、質を担保しながら効率的に開発するための「ツール」が必要であるということです。
パイオニアでは「骨太な事業」を目指していますが、その土台となる“骨”の部分は仕事を進める「プロセス」だと考えています。そのプロセスを実行するためには組織が必要で、組織が自らに課せられた役割を担うためには組織内メンバーのスキル(知識)が不可欠です。基礎となるスキルがなければ開発スピードが落ちるのは当然です。
そうしたスキルの習得を個人に任せていては効率が悪いため、現在は組織的にサイバーセキュリティ関連の教育拡充を図っています。会社としてもサイバーセキュリティ知識の底上げは重要課題ですから、中期経営計画にセキュリティ人材の育成を盛り込み、年間6名のサイバーセキュリティ人材を育成できるよう予算を確保しています。
またここで言う「ツール」とは、プロジェクト管理・ソフトウェア開発・ハードウェア開発などを司るパイオニア独自の「5-JIRA」や、成果物のテンプレートを指します。そこでISO/SAE 21434対応においては、必要となる成果物のテンプレートを策定しました。さらに、そのテンプレートをどのように活用するかについて明文化したガイドライン(手順書)も準備しています。
こうしたガイドラインは、開発プロセスを組織全体に馴染ませるために役立ちます。開発プロセスの規定はあくまでも社内法規であり、「この範囲を超えずに仕事をしてください」と定めているに過ぎません。規定はあらゆるプロジェクトに適用されるため、表現も抽象的です。ですから、ガイドラインで「誰が」「何を」「いつまでに実施すべきか」を明示する必要があると判断しました。
亀井:
実際に開発プロセスを構築するにあたり、どのようなことを意識されましたか。
友部:
開発プロセスを構築して規定化することだけが目的とならないように心がけました。時間とお金をかけて開発プロセスを構築するからには、「パイオニアのプロダクトを選んでくださる顧客に対して、安心・安全をお届けする」ことを価値にできるよう、常に意識して活動しました。
木元:
従来パイオニアではウォータフォール(V字モデル)型の開発を行っていました。しかし、工程前後で擦り合わせが多く発生してしまい、時間を余計に消費することがありました。ですから、成果物を完成させるための前行程で実施する入力情報や、後工程に渡す出力情報などで無駄な擦り合わせが発生しないよう、実態に合わせて課題を整理していきました。
そんな折、パイオニアは自動車メーカーからサイバーセキュリティ対応のプロダクト開発ビジネスを受託することになりました。これをよい機会と捉え、開発しながら運用面で実際のプロセスの流れや規定の解釈のされ方をフィードバックして改善を繰り返し、効率的に完成度を高めることができました。
自動車メーカーに迷惑をかけないよう、またプロセスにも抜け漏れがないように、外部の専門家の支援を受けながら取り組んだことで、パイオニアとしてもサイバーセキュリティに関するノウハウを蓄積できたと考えています。
PwCコンサルティング合同会社 ディレクター 山田 素久
PwCコンサルティング合同会社 マネージャー 亀井 啓
亀井:
実際に開発プロセスを運用していく中で直面した課題はありましたか。
友部:
大きく分けて3つの課題がありました。1つ目は市販プロダクトに対するセキュリティコストです。パイオニアでは自社ブランドとして市販プロダクトの企画・開発・製造を手掛けていますが、そうした市販プロダクトを自動車メーカーへ納入するケースもあります。
市販プロダクトを車載した状態で型式認証が行われる場合は、CSMSに準拠する必要があります。しかし、徹底的にコストを抑えたプロダクトは、CSMS対応のプロセスに準拠して開発・製造をすると採算が合わない可能性もあります。
木元:
一方、顧客にとって強固なセキュリティは、プロダクトを安心して使用することにつながります。ですから、しっかりと脅威分析・リスクアセスメントを行い、パイオニアとしてどこまで対応するべきかの「サイバーセキュリティゴール」を見極めなくてはなりません。
友部:
完璧なサイバーセキュリティゴールを目指して時間とお金をかければ、より強固なセキュリティは実現できます。しかし、サイバーセキュリティ対応に100点はありません。セキュリティ対策の費用対効果を考えつつ、いかに堅牢で安全なプロダクトを顧客に提供できるのか。その“相場観”を養うことも今後の大きな課題です。
そして2つ目の課題は、構成管理と一貫性の確保(トレーサビリティ)です。
CSMSでは開発プロジェクトに関わる全ての成果物にIDとバージョンを割り当て、上流から下流までのトレーサビリティが確保できていることを証明する必要があります。とはいえ、多くの企業ではプロジェクト管理・ソフトウェア開発・ハードウェア開発といったそれぞれの領域で最適なツールを個別に利用しているのが現状です。
CSMSが要求するトレーサビリティを確保するためには、各領域で利用しているツール同士の“差”を埋める構成管理用の中間成果物を作成し、独立した形でトレーサビリティを確認する作業が必要です。しかし、この方法では手間とコストがかかり非効率です。潤沢な資金があれば統合ツールを作り直すことも可能ですが、現実的ではありません。
最適な解決策は、長年利用しているツールでトレーサビリティを確保する方法です。現在、パイオニアではプロジェクト管理・ソフトウェア開発・ハードウェア開発で利用できる「5-JIRA」を活用し、構成管理とトレーサビリティを効率的に実行する取り組みを始めています。
木元:
3つ目の課題は、開発時のセキュリティ対応です。サイバーセキュリティ対応を組み込むことで、開発環境や開発効率の柔軟性が失われるという課題です。
例えば完全性の確保を目的に、ソフトウェアを簡単に書き換えできない仕組みにしたとしましょう。その場合、開発中にソフトウェアの書き換えが必要になっても、すぐには書き換え(バージョン変更)はできません。この問題に対処するためには、セキュリティ対策と平行し、ソフトウェア書き換え防止の回避方法やリカバリ方法までを検討しておかなければなりません。
友部:
こうした課題を解決すべく、私たちは2022年度から開発者を中心としたメンバーで構成する「プロダクトサイバーセキュリティ委員会」を設置しました。同委員会ではサイバーセキュリティ動向の情報を収集したり、社内でセキュリティ対応を議論したりとさまざまな活動を行っています。
例えば、同委員会では開発中に詳らかになったプロセスの滞りを検証することでフィードバックを行い、プロセスの改善に務める活動もしています。PDCAを高速に回すことでセキュリティ強化はもちろん、プロダクトの品質向上にもつなげられます。
山田:
自社ブランドプロダクトのCSMS対応も検討する必要があったのですね。2つ目と3つ目の課題に対して、先行していたOEM製品の法規対応はどのように進んだのでしょうか。
木元:
自動車メーカー側も私たちと同様、法規施行前の準備段階ではプロセスや手順などでよりよい手法を模索している状態でした。パイオニアではこの段階から自動車メーカーとの意見交換や認識の共有などを積極的に実施し、サイバーセキュリティ対応の構築に向けて協力関係を築きつつ、法規対応を推進していました。パイオニアはサプライヤーという立場でさまざまな自動車メーカーと仕事をする機会があるため、サイバーセキュリティ対応でも各社の特色を肌で感じることができています。
亀井:
次に部門間の連携について教えてください。友部さんはプロセス構築のリーダー、木元さんは具体的なプロダクト開発のリーダーという立場です。お二人はお互いの部門をどのように意識していましたか。
友部:
EPGではアセッサー(評価者)資格を取得し、構成監査やプロセス監査も担える体制を構築しています。私たちにとって、プロダクト領域のサイバーセキュリティ対応は初めてのことです。ですからCSMS品質を確保するためには知識のある監査者が実際のプロダクト開発に入り込んだほうが効率的であると考え、監査のポイントとなるプロセスや成果物の作成などを一緒に学びながら進めています。
こうした体制を構築することでプロセスを管理する側は、現場担当者のプロセスに対する捉え方を把握できたり、小さな課題を吸い上げて次のプロセス改善へ活かせたりできます。
一方、開発者側は監査者が「このように開発してください」という成果物(手順書)を作成することで、開発と監査を同時に推進し、プロセス理解の時間を節約できます。これにより、初めて回すプロセスに対する不安を排除できると考えています。
木元:
「監査者が開発に入り込む」というパイオニア独自の進め方ではありますが、「プロセスから逸脱しないように監視する」という本質からは外れていません。こうしたアプローチは組織全体にサイバーセキュリティ文化を定着させる有効な手段であると考えています。
友部:
パイオニアでは出荷と開発のフェーズへの移行判定に対する品質の承認として、品質保証部門に監査者を配置し、監査プロセスを設けています。このプロセスでは厳格な監査が行われますが、最終工程で手戻りが生じた場合は、時間的なロスが多いという課題を抱えていました。こうした課題もEPGに評価者を配置することで、効率よくプロセス改善ができますし、監査ポイントで不具合も修正できます。
山田:
友部さんは「ルールを作成する側」で、木本さんは「そのルールに則って作業する側」ですよね。意見の違いなどから反目し合うことはありませんでしたか。
木元:
CSMS対応は社内規定ではなく、自動車のOEMビジネスを推進する企業にとって準拠すべき義務です。友部さんが率いる技術戦略推進部は、「いかに効率的で、かつ現場での作業負担を最小限にした形で有用な規定を作るか」を第一に考えてくれています。ツールの開発や人材育成の部分にまで目を配り、「開発のスピードを落とすことなく対応する」という視点でルールの策定に取り組んでいます。こうした姿勢はIVI開発マネジメント部門にとってすごくありがたいのです。
友部:
よく指摘されるような「管理と現場の対立」はありませんね。むしろ「意見の違い」という点から考えられる今後の課題は、「委託先へ開発プロセスをどのように展開するか」です。特に国連協定に加盟していない国の企業に対して「ISO/SAE 21434に準拠して開発してください」とお願いしても、ISO/SAE 21434自体を知らないケースも少なくありません。そうした企業に対してパイオニアの開発プロセスを守ってもらうためには、契約書に「サプライヤー監視規定」を盛り込むなどの対策を講じる必要があると考えています。
パイオニア株式会社 技術開発本部 技術戦略推進部 友部 真一氏
パイオニア株式会社 技術開発本部 技術統括G IVI開発マネジメント部2課 木元 恭平氏
亀井:
今後の展望を聞かせてください。CSMSを定常運用していくうえで克服すべき課題は何でしょうか。
友部:
セキュリティコストに対する顧客の理解だと考えています。CSMS対応で、メーカー側は遵守しなければならない規格が1つ増えて、その分のコストもかかります。しかし、プロダクトを使用する顧客にとって、メーカーのサイバーセキュリティ対応は目に見えない付加価値です。そのためセキュリティコストを販売価格へ転換することは、顧客の理解を得づらいのです。
木元:
その背景には、サイバーセキュリティ領域で先行しているIT業界のプロダクトの存在があります。例えば、パソコンOSのセキュリティ修正プログラムは、定期的に無償配布されますよね。つまり、「メーカーがセキュリティ対策を講じるのは当たり前」という考えが浸透しているからです。こうした状況の中、私たちはCSMS準拠を1日でも早く当たり前の品質として効率よく運用し、セキュリティコストの販売価格への転換が最小限になるよう、企業の使命として努力していかなければなりません。
友部:
そのために必要なのは開発スピードを上げることです。そして、開発スピードの源泉は、知識と経験です。車載セキュリティに関する知識はもちろん、開発の要所で即断即決できる知識を身に付けることです。先述したとおり、セキュリティ人材の育成は中期経営計画にも盛り込まれています。現在はCSMS基礎講座や、システム開発者向け脅威分析・リスクアセスメント講座、開発者向け脆弱性分析講座などを提供しています。
山田:
お話を伺って、パイオニアが人材教育に注力していることがよく分かりました。会社としてセキュリティに関する知見や経験値の蓄積はどのように進めていますか。
友部:
ISO/SAE 21434対応としては顧客がサイバー攻撃の脅威にさらされないように、脅威分析やリスクアセスメントを実行し、プロダクトに合ったサイバーセキュリティゴールを定め、その手法を関係部門に提供しています。また、個人の知識量や経験値に左右されないために、分析手法についてもデータベース化して蓄積しています。こうした取り組みでサイバー脅威に対するレスポンス時間を短縮し、迅速な対応ができるようにしたいと考えています。
山田:
パイオニアはJapan Automotive ISAC(J-Auto-ISAC)にも加盟していますよね。
友部:
はい。サイバー攻撃の手法は日々進化しており、一企業の力だけではその脅威を排除することは困難です。J-Auto-ISACは企業横断的に自動車のサイバーセキュリティ情報を共有・分析し、対応能力の強化に取り組んでいますよね。パイオニアはこうした業界の取り組みに積極的に参画しています。同時にプロダクト開発や生産に携わる全ての協力会社に対しても協働プロセス合意書を取り交わし、CSMSに準拠した「モノ×コトづくり」を推進していきたいと考えています。
CSMS対応で、仕事のやり方は大きく変化します。私たちはこのタイミングを好機と捉え、まずは“骨”となるプロセスを「どう使われるか」を意識して固めました。そして組織を構成する人材と実際に利用するツールで“肉付け”し、「三位一体」で強靱な体制を構築しました。これこそが活動が円滑に進んだ大きな要因だと考えています。
亀井:
パイオニアの「三位一体でモノ×コトづくりに邁進する」という姿勢は、CSMS対応に悩む企業にとって有用な道しるべになりますね。本日はありがとうございました。
※1 型式認証:自動車製作者等が新型の自動車等の生産または販売を行う場合に、あらかじめ国土交通大臣に申請または届出を行い、保安基準への適合性等について審査を受ける制度
(出典:国土交通省 https://www.mlit.go.jp/kisha/kisha05/09/090928/02.pdf)
※2 CSMS:産業用オートメーションおよび制御システム(IACS: Industrial Automation and Control System)を対象としたサイバーセキュリティのマネジメントシステム
※3 IVI:情報(Information)とエンターテインメント(Entertainment)の両方を提供する情報通信システム。
※4 A-SPICE:車載ソフトウェア開発におけるプロセスの定義や評価の指標を規格化した業界標準のプロセスモデル
車両のデジタル革命によって、次世代のモビリティ社会が形作られる一方で、各国の政策や規制により変化の速度が決定されている面があります。その要因の一つがサイバーセキュリティへの懸念です。
車両サイバーセキュリティに関する国際規格や製品ライフサイクルにおける重要論点の解説やクライアントとの対談を通じ、車両サイバーセキュリティの将来をひもときます。
今回はTier1サプライヤーとして車両セキュリティの根幹を支えるパイオニア株式会社のご担当者をお招きし、CSMSに対応した開発プロセスや組織構築の具体的な取り組みなど、CSMS対応製品の開発で留意しているポイントなどについてお話しいただきました。
J-Auto-ISAC 理事 セキュリティオペレーションセンターでセンター長を務める井上弘敏氏と、UNR155適用で自動車業界に求められる対応について議論を深めました。
今回は主に自動車に関わるサイバーセキュリティ情報の収集・分析を行う「一般社団法人J-Auto-ISAC」でサポートセンター長を務める中島一樹氏に、活動内容についてお話を伺いました。
自動車のサイバーセキュリティとソフトウェアアップデートに関する国際法規基準は、自動車業界を今後どう変え得るのか。車両サイバーセキュリティのプロフェッショナルが意見を交わしました。
SDV(Software Defined Vehicle)の普及に向け、日本の自動車産業は「4つの領域」における取り組みが求められています。各領域で対応が必要となる「ビジネス戦略」と「サイバー脅威」、および「望ましいサイバーセキュリティの未来」について、PwCの知見と公開情報をもとに解説します。
社会のデジタル化が進展する中、サイバーリスクも増加しています。連載シリーズ「望ましいサイバーセキュリティの未来」では各業界における新たなサイバーリスクと、その対策を講じる際の「あるべき将来像」について解説します。
オーストラリアサイバーセキュリティ法では、製品セキュリティにかかるセキュリティスタンダードへの準拠義務や身代金支払い報告義務などが定められています。製造業者や販売者の義務と、対応を効率化するためのアプローチについて解説します。
「能動的サイバー防御」を議論していた政府の有識者会議は、2024年11月29日に法制化に向けた提言をまとめました。提言の背景や概要について解説します。