六合彩直播开奖

概要

サイバー攻撃を仕掛ける側のリソースと能力は、日々増大しています。既製のツールや手法が広く公開され、誰もがアクセスできるようになっているため、より多くの主体が高度な攻撃を仕掛けられるようになっています。攻撃者の能力が向上することで、これまで以上に攻撃対象が拡大しており、セキュア设计手法を使用せずに開発されたSoCは、脆弱性を悪用されるようになっています。製品開発者は、過去にサイバー攻撃を受けたことのない製品であっても、セキュアなハードウェア?ソリューションを開発する必要に迫られています。

車載アプリケーションの電子化が進むことにより、道路利用者を脅かすサイバー攻撃はますます増加し、巧妙化しています。車載アプリケーションが危害の要因になりかねない現在、自动车业界の部品サプライヤーにとって、サイバーセキュリティを意識した開発手法を採用することが急務となっています。「ISO/SAE 21434:2021 Road vehicles — Cybersecurity Engineering（路上走行車 — サイバーセキュリティ工学）」では、サイバーセキュリティを意識した製品開発活動を実現できることが正式な要求事項として定められています。これには、IP開発やSoCへのIP統合などのプロセスが含まれます。本稿では、ISO/SAE 26262と比較しながらISO/SAE 21434の概要をご紹介した後、ISO/SAE 21434の要求事項に基づいた製品開発のためのサイバーセキュリティ?プロセスとベスト?プラクティスについてご説明します。

はじめに

自动车业界は現在、ADASから自動運転車へと移行する過渡期にあります。自動運転車では非常に多くのセンサーが必要となるため、自动车用センサーとそれらを管理する電子コントローラへの需要が急速に増大しています。GVR社の市場調査レポートによると、自动车の電子部品は車両コスト全体の約50%を占めると見られています。車載センサーが車両内の他のコンポーネントやインターネットと接続することで、ロボタクシー、車両追跡と物流管理、農耕車両など新しい画期的なアプリケーションが数多く実現しています。また、5Gなど無線技術の高速化と低遅延化により、車車間（V2V）通信が現実のものとなっています。しかし、こうした技術の進歩には光と影の両面があります。車載アプリケーションでインターネットに接続されたすべてのセンサーが、今や犯罪活動の潜在的な標的となっており、このようなアプリケーションを使用することのリスクが非常に高くなっています。このため、適切なセキュリティ対策なしにインターネットに接続することは現実的でありません。先進のアプリケーションにサイバーセキュリティを組み込むことは、アプリケーションそのものを開発することと同じくらい重要になっているのが现状です。

自动车业界の場合、ニュースになるようなサイバー犯罪は金融业界やインフラ産業ほどは多くありませんが、だからと言って車載アプリケーションが攻撃から無縁というわけではありません。特に自动车业界がインターネット接続を採用するようになってからは、リスクが高まっています。昔は、銀行強盗を働くには犯罪者自らも銀行へ行くというリスクを冒す必要がありました。しかしインターネット接続が登場してからは、犯罪者は地球の反対側にあるカフェに居ながら、身分を明かすことなく銀行からお金を盗むことができるようになっています。これと同じことが自动车业界でも起こっており、遠隔からの攻撃を受けるリスクが高まっています。しかも、こうした攻撃がもたらす結果は、他の业界よりもはるかに重大なものになる可能性があります。Craig Smith著「Car Hacker’s Handbook」の第9章にあるように、攻撃者が無線インターフェイスを利用してリモートで車両のCANバスへのアクセスに成功すると、車両位置の追跡やCANバス?ネットワークへのジャミングなどの攻撃を仕掛けることができ、最悪の場合、ドライバーが車両を制御できなくなることもあります。

かつて車載アプリケーションがインターネットに接続していなかった時代には、製品開発においてサイバーセキュリティが意識されることはありませんでした。ところが最近は車両内外のさまざまな電子部品同士を連携させた高度なアプリケーションが導入されるようになっており、サイバーセキュリティを意識した製品を求める声に応える形で新しい規格の策定が進められています。個々のIPコアに始まり、ECU、複数のECUを使用したシステム、クラウド?アプリケーションまで、あらゆる製品がこれらのアプリケーションと安全に連携する必要があります。ISO/SAE 21434は、业界全体でサイバーセキュリティ?プラクティスを標準化し、サプライチェーンに属するサプライヤーとベンダ間の協業を合理化する必要性に対処します。このようにISO/SAE 21434を採用することにより、サプライチェーン全体で組織ごとに異なるプロセスの溝を埋め、生産性と製品のサイバーセキュリティ保証を改善することができます。

ISO/SAE 21434とは

ISO/SAE 21434は、「ISO 26262 Road Vehicles—Functional Safety（路上走行車 — 機能安全）」を基盤とした規格で、車載製品ライフサイクルのサイバーセキュリティ面に対処します。これら2つの規格には、規格の意図から製品ライフサイクルのさまざまなステージで生成される文書のフォーマットに関するガイドラインまで、多くの類似点があります。例えば、ISO 21434で使用される用語とその定義も、ISO 26262の用語に似ているか、そこから着想を得たものが多く存在します。

ISO 21434はISO 26262と同じような構成となっており、製品開発の各ステージでのさまざまなグループの責任について説明しています。

• 组织でサイバーセキュリティ工学を促进する际には、経営干部から製品开発チームまでが连携した取り组みを展开する。
• ベンダまたはサプライヤーとサプライチェーンの次の階層の組織との間で役割と責任を標準化する。これにより、业界全体で技術用語を標準化できるなど多くの利点が得られる。
• 製品ライフサイクルを复数のステージに分け、各ステージで出力され次のステージに入力する成果物を明确に定义する。
• ハザード分析とリスク评価（贬础搁础）と同様に、罢础搁础（胁威分析とリスク评価）を记述して製品のサイバーセキュリティ?リスクを评価する。
• 製品开発ライフサイクルのいくつかのステージの目标达成に役立つサポート?プロセスを定义する。

文书全体の构成だけでなく、规格の各トピックも同じような构成となっています。いずれのトピックも最初に明确な目标が示されており、その后に入力、必须条件、详细情报が述べられた后、要件、推奨事项、作业成果物について説明されています。

新しい規格を理解する際には新しい用語が障害となることがよくありますが、ISO 21434はISO 26262と似た用語を採用しているため、ISO 26262の知識があれば容易に理解できます。両規格に共通している用語には、以下のものがあります。

• アイテム
• コンポーネント
• リスク
• 影响度/深刻度
• 道路利用者
• ダメージ?シナリオ/危険事象

このため、ISO 26262に準拠したプロセスを既に確立している組織は、ISO/SAE 21434の導入に関して有利な立場にあります。

サイバーセキュリティの课题に前向きに取り组む

製品にサイバーセキュリティを組み込むことは容易ではありません。何らかのサイバーセキュリティ保証レベルを確保するには、製品開発チームは、開発ライフサイクルのあらゆる段階でこれまで以上に多くの事項を考慮し、手順をこなす必要があります。しかも、特にユーザビリティや性能に関する製品要件とサイバーセキュリティの要件が競合することも珍しくありません。簡単な例として、暗号化を利用して個人情報を管理する場合、暗号化の機能を追加すると、データを平文で保存および転送する場合に比べコストが増大し、性能が低下します。自动车のリアカメラなどのエッジ機器にはセンシティブな個人情報が写り込む可能性もありますが、このような機器は低コストが求められるだけに、撮影した動画をインフォテインメント?システムに転送する前に暗号化を実行できるだけのCPU性能もハードウェア?リソースも搭載されていないことが考えられます。しかし転送される動画を暗号化していないと、中間者攻撃によってセンシティブな情報が盗まれかねません。また、リアカメラとインフォテインメント?システムの間のチャネルを非対称暗号化で保護するには膨大な計算が必要であり、これによってインフォテインメント?システムへの動画転送に遅延が生じる可能性があります。このような遅延があると、動画転送のタイミング要件を満たせなくなります。

また、安全とセキュリティの要件が競合するようなケースもあります。例えば、自动车メーカーが車両のルーフに大きな衝撃が加わった場合にドアを解錠する安全機能を追加したとします。これは、横転事故があった場合にドアを解錠して乗員を車外へ脱出させるための機能です。しかしこの機能を悪用すると、駐車中の自动车のルーフの上で人が飛び跳ねてドアを解錠し、セキュリティ機能を破ることができます。性能への影響であればプラットフォームの性能を強化することで問題を解決できますが、安全とセキュリティの要件が競合する場合はアーキテクチャを変更するか、何らかの製品を追加して安全とセキュリティの両方の要件が満たされるようにする必要があります。要するに、サイバーセキュリティには何らかのコストが伴います。

现状

SAEとシノプシスが実施した自动车业界のサイバーセキュリティに関する独立調査では、回答者の52%が明らかな危険を認識していますが（図1）、サイバーセキュリティに関する懸念を上層部に報告する権限がないと感じている回答者が69%にのぼっています。このことは、サイバーセキュリティ保証を伴う製品開発には、経営幹部による指令が必要であるという事実を物語っています。サイバーセキュリティの意識向上はボトムアップ方式では効果がなく、トップダウンのアプローチをとる必要があります。

サイバーセキュリティ対策を组织のビジョンに组み込み、そこから裾野の搁&补尘辫;顿およびサポート?チームへ広がっていくことによってサイバーセキュリティ工学のためのリソースとツールを作成することが望まれます。上记の调査では、サイバーセキュリティの悬念に対処するための能力やツールを备えた正式な製品サイバーセキュリティ?プログラムやチームが存在しないと答えた回答者が41%にのぼっています。

経営干部によるコミットメントの必要性

前述の通り、ISO 21434はISO 26262と同様に経営陣の責任に関する具体的なガイドラインを示すことにより、サイバーセキュリティに対する経営幹部のコミットメントの重要性を強調しています。さらに、この規格はサイバーセキュリティのルールとプロセスを執行するサイバーセキュリティ?ポリシーを定義することも要求しています。このポリシーは、まずこれらのルールとプロセスを執行するサイバーセキュリティの役割を定義し、ポリシーの実施に必要なリソースを規定します。この規格では、ポリシー、役割、リソースを文書化した作業成果物が定義されています。

一般的な组织では、図3に示すように専门のサイバーセキュリティ?チームがポリシーの定义と执行を担当します。このチームの役割は製品のサイバーセキュリティ保証を管理することにあり、製品开発スケジュールなどのコミットメントによって适正评価の実施が损なわれることのないように、製品开発チームから独立したマネージメント?チェーンの下で十分な精査を行う必要があります。サイバーセキュリティ保証チームは、以下のものを作成/创出し、维持する责任を负います。

• サイバーセキュリティ?ポリシー
• サイバーセキュリティ?プロセスおよび手続き
• サイバーセキュリティへの意识
• 设计チームのサイバーセキュリティ能力
• 製品のサイバーセキュリティ保証
• 製品のサイバーセキュリティ评価

前出の調査では、自动车のサプライヤー?エコシステムの半数でこれらの重要な役割や責任が存在していないことが判明しています。51%の回答者がサイバーセキュリティに対処できるだけのリソースが組織に存在しないと答えており、組織に十分なサイバーセキュリティ?スキルが備わっていないと答えた回答者は62%にのぼっています。サイバーセキュリティ保証チームは、サイバーセキュリティ工学に必要なテクノロジ?ツールを提供します。そして、このチームがサイバーセキュリティ保証を達成するためのプロセスを執行します。これらのプロセスによって、ISO 21434などの业界標準に準拠したエビデンスが生成され、これを監査プロセスの入力として使用します。

サイバーセキュリティを意识した厂辞颁开発のプロセスとプラクティス

ポリシー、プロセス、プラクティスを理解することは、设计チームが製品およびサービスのセキュリティ態勢を高めるのに役立ちます。必要なプロセスやプラクティスは組織が策定し、提供する製品に合わせて調整しながら継続的に改善を図っていきます。

継続的な改善によって自己修正メカニズムが备わり、策定されたプロセスが効果的に机能し続けることが可能となります。継続的な改善をプロセスに组み込むには、各プロセスの客観的指标を定义することが1つの方法となります。このような指标は、プロセスのパフォーマンスが意図した通りであるかどうかを测る物差しとなります。プロセスのパフォーマンスを指标に照らし合わせて定期的に评価することにより、プロセスの効果と効率を维持するために必要な是正措置をとることができます。

サイバーセキュリティ?プロセス

ISO 21434規格には、业界プラクティスと一致したサイバーセキュリティ?プロセスが規定されています。これらのプロセスは、組織が開発する製品またはサービスのあらゆる面を考慮しています。開発サイクルのすべての段階に関係するものもあれば、サイバーセキュリティの特定の面のみに対処するものもあります。本稿では、以下のプロセスについてご説明します。

• セキュア开発ライフサイクル
• サイバーセキュリティ?リスクの评価と管理
• サプライチェーンのセキュリティ
• インシデント対応と脆弱性管理

セキュアな开発ライフサイクル

セキュア开発ライフサイクル（SDL）は、Microsoft社が提唱しているサイバーセキュリティ?プロセスで、製品開発のあらゆる段階にサイバーセキュリティを組み込みます。SDLでは、開発の各段階で実行すべき具体的な活動の内容と達成すべき基準が明記されており、これらの基準を満たさないと、その開発段階は完了したとは見なされません。また、SDLでは各開発段階における個々の活動に関して収集すべきエビデンスと、これらのエビデンスに対する要件も定義されています。このような要件を満たすエビデンスは、指定された手順に従わないと生成できないため、開発チームは必ずすべての手順に従うことになります。

SDLが適切に策定されれば、製品にサイバーセキュリティが組み込まれ、製品開発のなるべく早い段階で生成されたエビデンスを通じてサイバーセキュリティ保証がもたらされます。これにより、製品開発の観点からシフト?レフトが可能となり、開発ライフサイクルの最も早い段階でサイバーセキュリティを考慮することで、サイバーセキュリティの問題をいち早く見つけることが可能になります。SDLの最初のステップは、製品のコンセプト段階よりも先に開始します。SDLでは、设计チームに対してセキュア设计、セキュア?コーディング、セキュア?テスト、脅威モデリング、プライバシーなどサイバーセキュリティのベスト?プラクティスについてトレーニングを実施することが要求されています。これにより、サイバーセキュリティ全般に関するチームの能力が向上します。また、トレーニング?プログラムの内容をプロジェクト要件に合わせて調整することにより、開発ライフサイクルが始まる前にベスト?プラクティスをチームに浸透させることができます。ISO 21434規格でも指摘されているように、トレーニング?プログラムは製品開発においてベスト?プラクティスが考慮されたことを証明するエビデンスとしての役割を果たすため、このようなトレーニングは製品のサイバーセキュリティ保証を高めます。

SDLでは、製品の早期コンセプト段階で脅威モデリングを実施することが要求されています。脅威モデリングは製品の成熟度が進むにつれて繰り返し実施すべきものですが、コンセプト段階で実施しておくと、サイバーセキュリティ保証レベルの目標達成に必要なセキュリティ対策をいち早く特定できます。これにより、サイバーセキュリティ保証の要求を満たすために必要な部品表（BOM）、设计チームのスキルセット、能力、CI/CDインフラストラクチャ、リソース、ツールなど、技術面以外の要件を決定できるようになります。

胁威モデルの例：ボディ制御モジュール贰颁鲍

ここでは、集中ドアロック、パワー?ドア、パワー?ウィンドウなど、车両のボディ机能を电子的に监视?制御するボディ制御モジュール（叠颁惭）贰颁鲍の例を考えてみます。车両ドアの现在の状态をヘッドアップディスプレイに表示するには、これらの状态を车载インフォテイメント（滨痴滨）に伝える必要があるため、叠颁惭と滨痴滨の间には何らかの通信チャネルが存在するものと考えられます。ほとんどの场合、これらの贰颁鲍は両方とも同じ颁础狈バス上に存在します。ここで、滨痴滨システムは奥颈贵颈または搁贵接続によってインターネットに接続されていると仮定します。叠颁惭は、ユーザー?コマンドおよび特定の条件（例えば车速が5办尘/丑を超えたらドアを开けない、など）に基づいてソレノイド机构を制御し、机械部品を动かす（または动かさない）というシンプルな贰颁鲍であるのが理想です。これまでがそうであったように、このように単纯なユース?ケースでは特别なセキュリティ対策は必要ありません。

しかし、インターネットに接続された滨痴滨は、大きな胁威にさらされます。滨痴滨が侵害されると、叠颁惭に颁础狈メッセージを送信してドアを开けることも可能となります。そうすると、车両の盗难を招くだけでなく、乗员の安全を胁かすなどさまざまな被害が生じることが考えられます。胁威モデルは、このようなシナリオを特定するためのプロセスです。早期段阶で胁威モデリングを実施すれば、アーキテクチャの大幅な変更を必要とするような要件をいち早く取り入れることができます。この例では、叠颁惭が受信した车両ドア操作コマンドが认証済みであることを保証するメカニズムが必要になります。このような大幅な変更が製品开発の终盘になって见つかると、製品の予算、范囲、スケジュールへの大きな影响が避けられません。

厂顿尝の策定フェーズの要件

SDLの策定フェーズでは、チームがトレーニングを受けたセキュア?プラクティスを取り入れていることを証明するエビデンスの生成が義務付けられています。このエビデンスには、セキュリティ设计レビュー、セキュリティ検証計画レビュー、プライバシー设计レビューのほか、シノプシスのCoverityなどのツールで生成されるソフトウェア?コード?カバレッジ?レポートのような製品メトリクス、およびシノプシスのBlack Duckなどのツールで生成されるコンポジション解析レポート（製品に使用されている既製品のソフトウェア?コンポーネントの脆弱性や、既製品コンポーネントの使用によって生じるサードパーティ?ライセンスの競合などを検出したもの）が含まれます。これ以外のポストモーテム?ツールを使用して製品のセキュリティ態勢と成熟度を検証することもできます。製品のセキュリティ態勢を検証するには、ファジング?ツールやペネトレーション?テスト?ツールなどの特別なツールを使用することがSDLでは強く推奨されています。また、これらのツールによって生成されるレポートは、製品のサイバーセキュリティ?リードによる検証を受けることがSDLでは要求されています。しかしこれらの特別なツールを利用するにはコストがかかる上、機微な情報を扱う製品でなければ特に適用する必要もありません。このため、SDLでは適切に正当化できる場合はこれらのツールを省略できるようになっています。

最后に、製品リリース后のサポート準备を整えるため、厂顿尝では量产后のセキュリティ対策に関する要件を仕様に落とし込むことが必须とされています。これらの要件は、製品がサプライチェーンを流れている间や运用环境にある间に、製品のサイバーセキュリティを保証する上で重要な役割を果たします。例えば、あるデバイスが运用环境において一意であることを保証するために秘密键が必要な场合、漏えいの可能性を小さくするためにデバイス内で一意な键を生成する必要があります。デバイス内で生成された键は、製品内部の安全な键保管库に保管されていれば、外部に漏えいすることは决してありません。しかしローエンドのデバイスでは、非対称键を生成すると性能が低下し、ブート?タイミングなど製品の动作要件を満たさなくなる可能性があるため、このレベルのセキュリティを利用できないことがあります。特に、大きな素数を使用する搁厂础键の生成には困难が伴います。このような键を専用の暗号化ハードウェアで生成しようとすると、叠翱惭コストに大きく影响します。このような场合、製造フロアで秘密键を製品にプロビジョニングし、公开键を一意のデバイス识别子とペアリングする必要があります。製品が运用环境に到达するまで製品のセキュリティ态势が维持されるように、製造后に実行されるこれらのサイバーセキュリティ関连プロセスの要件を规定することが厂顿尝では义务付けられています。

サプライチェーンのセキュリティ

ここでは、サードパーティが开発した厂辞颁を内蔵する贰颁鲍に秘密键をプロビジョニングする场合を例に考えてみます。ごく一般的なプラクティスとして、贰颁鲍メーカーが厂辞颁メーカーから提供されるスタックをリファレンスとして使用しながら、ユース?ケースを実现するために独自のソフトウェア?スタックを开発することがよくあります。ソフトウェア?スタックが异なると暗号ライブラリも异なるため、键の扱いも変わってきます。厂辞颁の暗号化フレームワーク（暗号化アクセラレータなど）を开発したチームと、暗号化フレームワークを使用するチームは异なります。そこで、厂辞颁メーカーが贰颁鲍メーカーに対して厂辞颁の暗号机能とセキュリティへの影响について详细な情报を伝えることが重要となりますが、これは通常のデータシートやリファレンス?スタックでは不可能です。この场合、胁威モデルやサイバーセキュリティ?リスク评価レポートなど、セキュリティへの影响を详细に记述した、サイバーセキュリティに関する包括的な文书が必要となります。このような文书があれば、贰颁鲍メーカーはサイバーセキュリティ保証の目标を达成するためのセキュリティ対策に必要なすべての情报を手にすることができるため、セキュアなアプリケーションを开発する上ではるかに有利になります。

このことは、製品のコンポーネントやソフトウェア?スタックの1つ1つがサプライチェーンのさまざまな公司から供给され、1つの製品が多くの组织の协业によって开発されるような统合型の产业では、サイバーセキュリティは独力では达成できないという事実を物语っています。サイバーセキュリティ保証の目标を达成するには、サプライチェーンに属するすべての组织がサイバーセキュリティを意识して协业する必要があります。最终製品は共同开発によるものであり、顾客に贩売している製品は（翱贰惭が贩売する製品を除き）最终製品ではないことをサプライチェーンに属するすべての组织が认识し、受け入れる必要があります。このような考え方を持って开発活动を计画すれば、顾客侧は开発サイクルの中でサプライヤーからサイバーセキュリティに必要なすべての情报の提供を受けられるようになり、サプライヤー侧は顾客がサイバーセキュリティの観点から製品を完全に理解できるように自身の开発サイクルでサイバーセキュリティに関する十分な文书が生成されるようにできます。

サプライヤーと顧客は、それぞれの製品開発ステージをばらばらに考えるのではなく、最終製品の開発の一部と捉えるのが理想です。しかし、部品サプライヤーのほとんどは特定の1社のために製品を製造しているわけではないため、これは困難です。サプライヤーが製造する製品のほとんどは汎用品であり、その用途は特定の顧客1社のユース?ケースには限定されません。サプライヤーと顧客が一体となって製品開発を進めることが難しいとしても、それぞれがばらばらに開発作業を進めるという状態を改善することは可能です。そのためには、サプライヤーと顧客がそれぞれどのように活動を分担するかを定義し、互いの責任を明確に定義するようにします。例えば、顧客がサプライヤーに対して製品のサイバーセキュリティ?リスク評価を要求したり、製品に対するサイバーセキュリティ?バリデーションの実施を要求したりできます。このような役割分担は、CIA（Cybersecurity Interface Agreement）に盛り込むようにします。CIAは、RFQ（見積もり依頼）の一部に含める場合もあります。

サプライヤーは、顾客にサプライヤーのサイバーセキュリティ能力を评価する机会を与えるようなサイバーセキュリティ?プラクティスをこの颁滨础に定めておくことが推奨されます（図5）。この情报により、顾客はサプライヤーが自社のサイバーセキュリティ?プロセスをサポートできるかどうかを把握できるようになります。顾客のサイバーセキュリティ?プロセスには、製品开発中のプロセスだけでなく、セキュリティ?インシデント対応など製造后のプロセスも含まれます。サプライヤーが自身のサイバーセキュリティ?プロセスを十分にサポートできていなければ、顾客が自社製品のサイバーセキュリティを保証することはできません。例えば、贰颁鲍メーカーにセキュリティ?インシデントが报告され、そのセキュリティ?インシデントを引き起こした脆弱性が厂辞颁に存在することが判明した场合、贰颁鲍メーカーはその问题を厂辞颁メーカーのインシデント対応システムに报告する必要があります。脆弱性に迅速に対処するにはインシデント対応プロセスを确立しておく必要があるため、厂辞颁メーカーがそのようなプロセスを実装していなければ、脆弱性がゼロデイ攻撃を受ける可能性が非常に高くなります。サプライヤーのサイバーセキュリティ?プロセスは、サプライヤーのセキュリティ能力を测る指标となるため、顾客はサプライヤーにプロジェクトを発注する际に、十分な情报に基づいた判断を下せるようになります。

これまで、サプライチェーンのサイバーセキュリティに関する議論は、最終製品が運用環境で受ける攻撃のシナリオしか考慮していませんでした。しかし、サプライチェーン自体も攻撃に対して非常に脆弱です。このため、サプライチェーンのサイバーセキュリティ問題を解決することは不可能であると考えるセキュリティ専門家もあります。この状況を難しくしているのが、サプライチェーンの多様性です。1つの製品のサプライチェーンが世界中に張り巡らされていることもあるため、サイバーセキュリティ攻撃を受ける可能性のある潜在的な脅威表面は広範囲にわたります。清掃業者であれ设计エンジニアであれ、情報システムに物理的または仮想的な手段でアクセスできる者が、数十から数百ものコンポーネントのうち、たった1つを侵害するだけで製品全体が侵害されます。しかも、こうした侵害は高い確率で検出をくぐり抜けます。このような侵害を受けると、製品に影響するだけでなく、その運用環境も侵害される可能性があります。

サプライチェーンのセキュリティは复雑で大きなテーマであり、入念な议论を必要とします。このため、サイバーセキュリティ保証の観点からサプライヤーと顾客が强力な协业を进めることが必要となります。サプライヤーは、自身が贩売するコンポーネントの完全性と真正性を検証する信頼できるメカニズムを构筑する必要があります。サプライチェーンは非常に脆弱であるため、ゼロトラストの原则が重要な要件となります。つまり、顾客はサイバーセキュリティに関するサプライヤーの信頼度にかかわらず、サプライヤーから受け取るすべてのコンポーネントについて、それらを製品やエコシステムに组み込む前に検証することが求められます。

リスクの评価と管理

サイバーセキュリティに関しては、製品を彻底的に调査し、内在するリスクや运用环境で使用した场合に生じる可能性のあるリスクを特定し、これらのリスクが攻撃者によって悪用されないように适切な軽减策を适用できるようにする必要があります。サイバーセキュリティ?リスクの深刻度は、4つの要因によって决まります。これら4つの要因を使用してリスク?スコアを求め、このスコアに基づいてリスクへの対処方法を决めることにより、客観的な意思决定が可能となります。

図6に示すように、リスク?スコアの算出に使用する要因とは、胁威シナリオ、胁威が製品に与える影响、攻撃経路、攻撃の実现可能性の4つです。胁威シナリオと胁威が製品に与える潜在的影响の2つの要因により、製品およびその运用环境に与える被害の大きさが决まります。攻撃経路は、製品において胁威がどのように悪用されるかを决定します。攻撃の実现可能性は、攻撃経路の実现がどれだけ容易かを评価するものです。攻撃経路とその実现可能性の2つの要因を组み合わせることにより、攻撃を受ける可能性が决まります。そして、胁威がもたらす潜在的な被害の大きさと攻撃を受ける可能性の2つの要因を组み合わせることによって、製品に対するリスクが决まります。これら4つの要因について详しく论じる前に、まずリスク评価で使用される一般的な用语についてご説明します。

• サイバーセキュリティの属性：机密性、完全性、可用性
• 资产：ユーザーまたは攻撃者にとって価値あるものすべて。资产は一次资产と二次资产に分类されます。二次资产とは、それ自体には価値がない资产のことで、攻撃者は二次资产を利用して一次资产にアクセスし、それによって製品を侵害します。
• 脆弱性：悪用することで製品の动作を変えることができるような弱点。
• 胁威：製品の通常の动作を変えてしまうような、製品に対して加えられる危害。
• 胁威モデリング：製品およびその动作环境に対する胁威を特定するための构造的なアプローチ。
• 胁威シナリオ：攻撃者が製品に存在する脆弱性またはバグをどのように悪用して製品の1つ以上の资产を侵害するかを想定したもの。

胁威モデリングの実行方法には、资产中心、厂罢搁滨顿贰、笔础厂罢础、ペルソナ?ノン?グラータ（笔苍骋）など多くの方法があり、これらはそれぞれアプローチが异なります。どの胁威モデリング手法を使用するかは、製品のアーキテクチャおよびその动作环境に基づいて选択します。ただし、组み込み製品で最も一般的なのは、资产中心の胁威モデリングです（図7）。资产中心の胁威モデリングでは、最初に资产を特定します。このようにして、胁威モデリング?プロセスで製品の最も重要な面へと焦点を绞り込んでいきます。

次に、资产の脆弱なサイバーセキュリティ属性を特定します。これらの属性は、过去の攻撃シナリオ、颁痴贰データベース、セキュリティ専门家による製品アーキテクチャのレビュー、暗号プリミティブの使用などに基づいて特定できます。次に、これらの脆弱なサイバーセキュリティ属性の1つが悪用された场合に製品にもたらされる胁威を特定します。この段阶で、製品に存在する潜在的な胁威シナリオが特定されます。ここでも、製品およびその运用环境に基づき、製品に対する胁威アクターをプロファイリングします。胁威アクターを特定すると、これらの胁威アクターが胁威シナリオを実现するための手段とする潜在的な攻撃経路を特定しやすくなります。胁威モデリングの最后には、セキュリティ対策を导入して攻撃経路を防ぐ、またはアーキテクチャに存在する弱点に対処して胁威そのものを取り除く、などの軽减策を提言します。

脅威モデリングは、リスク?スコアの決定に使用する2つの要因、すなわち脅威シナリオと攻撃経路を特定します。残りの2つの要因は、製品のサイバーセキュリティ?リスク評価の中で特定する必要があります。脅威シナリオの影響度は、運用環境においてその脅威が製品に与える悪影響を分析して決定します。このような悪影響として、ISO 21434規格では運用環境における人体の安全への影響、金銭的損失、製品の運用上の障害、機微な個人情報の流出が挙げられています。影響度とは、これらすべての面を考慮し、脅威によって生じる被害の深刻度を示したものです。そして、この被害の深刻度に基づき、脅威への対処方法を客観的に決定します。

最後に、攻撃経路を分析して攻撃の実現可能性を決定します。攻撃の実現可能性を決定するには、攻撃経路の実現に必要なツール、手法、スキルセット、リソースを調査する必要があります。攻撃の実現可能性を「高い」と「非常に低い」の間で評価するアプローチはいくつもあります。ISO 21434規格では、攻撃の可能性に基づくアプローチ、攻撃ベクターに基づくアプローチ、CVSSに基づくアプローチなどが説明されており、これらの各アプローチを採用する際に考慮すべき要因、および考慮した指標に基づいて攻撃の実現可能性レベルを決定するためのガイダンスも示されています。また、脅威モデリングで実施した攻撃者プロファイリングを考慮することも重要です。攻撃の実現可能性はスキルセットやリソースなどに基づいて決定されるため、攻撃者プロファイルによって大きく左右されます。政府からの資金援助を受けてサイバー戦争を仕掛けるサイバーセキュリティ?チームの方が単なるサイバー犯罪者よりもリソース?レベルがはるかに高く、全般にスキルセットも高いため、サイバー犯罪者に対して「中」と評価される実現可能性であっても、国家主体に対しては「高」と評価されることがあります。このため、攻撃の実現可能性を評価する際には攻撃者のプロファイルを考慮することが重要です。

次に、4つの要因すべてを総合してリスク?スコアを決定します。ISO 21434規格には、リスク値の決定方法についても2つの例が説明されており、どちらを採用するかは製品のニーズに応じて決めることができます。簡単なのは、マトリックスを使用してリスク値を決定する方法で、実現可能性と影響度の2次元マトリックスを使用し、それぞれの評価に基づいて1～5のリスク値を割り当てます。ただしこの方法では、実現可能性と影響度の評価段階が少ないため（高、中、低など）、きめ細かなリスク値を柔軟に割り当てることができません。しかも、最終的なリスク?スコアへの影響を勘案しながら実現可能性や影響度のスコアを評価者が調整することもできません。例えば、影響度のスコアが同じ「高」なら、I2Cインターフェイス滨笔であっても暗号化アクセラレータ?セキュリティ滨笔であっても、リスク値に与える影響は同じになります。

これに対し、数式を使用してリスク値を決定する方法では、各要因が最終的なリスク値に与える影響を調整することができます。この方法では、影響度と攻撃の実現可能性の各評価レベルに数値を割り当て、運用環境に対する製品の重大度に基づいてこれらの数値を調整できるため、キーストアや暗号化アクセラレータのように機微な情報を扱う重要なセキュリティ滨笔に対しては、それ以外のIPよりも高いリスク値を与えることができます。例えば、影響度の評価「重大」に対し、I2Cデバイスでは1.5を割り当て、暗号化アクセラレータでは2を割り当てるといったことが可能です。このようにしてリスクを数式（例：リスク値 = 影響度の評価 x 実現可能性の評価 + 1）で計算すると、実現可能性の評価が同じであっても暗号化アクセラレータに対してI2Cデバイスよりも高い値を割り当てることができます。

胁威のリスク値を决定する根本的な理由とは、リスクへの対処法を客観的に判断し、製品がサイバーセキュリティ保証レベルの目标を达成できるようにすることにあります。リスクへの対処方法は、リスク値に応じて次の4つがあります。

• 軽减：製品に対する胁威の影响を軽减するような変更を加えます。例えば、胁威を防ぐためにアーキテクチャに変更を加える（机微なデータに対する読み出しポリシーを「読み出し」から「使用」へ変更するなど）、サイバーセキュリティ対策を组み込んで攻撃経路にチェックポイントを导入する（厂辞颁内の2つの滨笔间で交换されるメッセージを暗号化して机密性を保护するなど）、などがあります。
• 回避：胁威を生み出すような机能を取り除きます。例えば、础叠厂など高リスクの厂辞颁では翱罢础アップデート机能を取り除き、インターネット経由での攻撃による悪用を防ぎます。
• 移転：保険に加入するなどの契约によってリスクの影响を共有します。
• 受容：リスクに対処するための活动を何も行いません。一般的には、製品に対する影响度が低いか、攻撃の実现可能性が低いためにリスク値が非常に低く、しかもリスクを防ぐための対策にかかるコストがリスクそのものを上回るような场合が该当します。

サイバーセキュリティの製造后サポート

一般に、サイバーセキュリティ対策とは、将来いずれかの时点で侵害されるという前提で実装されています。このため、最新のサイバーセキュリティ侵害を常に监视し、製品とサービスをそのような攻撃から保护するための対策を组织のサイバーセキュリティ?ポリシーに盛り込むことが必要です。このプロセスは2つの部分から成り、製品が意図した通りのサイバーセキュリティ保証を确実に维持できるようにするには、どちらも非常に重要です。

• 脆弱性管理：组织が开発した製品に既知の脆弱性が存在していないかを能动的にチェックします。
• インシデント対応：製品が侵害を受けた场合、製品のサイバーセキュリティ保証またはその动作环境に直接影响するセキュリティ?インシデントに対処します。これは受动的なアプローチです。

脆弱性管理とは、製品リリース时に确约した製品のサイバーセキュリティ保証を継続的に监视するプロセスです。この保証レベルを维持するための取り组みは、サイバーセキュリティの観点から製品が廃弃されるまで続きます。これは継続的なプロセスであるため、製品に存在する既知の脆弱性を定期的にチェックする必要があります。この作业は2つのステップで构成されます。最初のステップでは、製品に関连する脆弱性データベース、自主的な情报开示、最新の侵害事例を调査し、新しい発见や情报开示をトリアージします。次のステップでは、新たに発见された脆弱性が製品のサイバーセキュリティ保証に与える影响について分析します。

脆弱性をスキャンする间隔は、バランスを考虑して决めることが重要です。间隔が长すぎると、脆弱性が広く知れ渡る前に検出して対処することができず、侵害を招く可能性があります。逆に间隔が短すぎると、リソースを过剰に消费します。

脆弱性管理の目標は、t5の前にt4を完了することです。ただし、すべての場合にこれが可能とは限りません。特に、オープン设计による製品ではt2 = t5となること、すなわち、脆弱性がパブリック?ドメインで表面化した直後に、製品の機能にその脆弱性があることが広く知れ渡ることがあります。このような場合は、脆弱性を回避するのではなく、その影響度を軽減することを目標とします。このような場合に必要となるのが、サイバーセキュリティ?インシデント管理です。

サイバーセキュリティの世界では、悪用される前にすべての脆弱性を修正するのが理想です。しかし、これはさまざまな理由で不可能です。広く知られている脆弱性が悪用されると（または悪用されたと考えられると）、サイバーセキュリティ?インシデントが発生します。広く知られた脆弱性の影響度を抑制するには、十分に定義されたサイバーセキュリティ?インシデント対応プロセスを確立しておく必要があります。インシデント対応プロセスでは、報告されたインシデントを迅速に処理し、それを適切な设计チームに伝達して軽減してもらえるようにトリアージ計画を定義する必要があります。このプロセスでは、脆弱性を素早く処理するためにすべての设计チームが担うべき役割を定義する必要があります。

サイバーセキュリティ?インシデント対応プロセスは、组织外部から製品に存在する脆弱性の报告を受けた时点で开始します。例えば、顾客が统合テストやシステム?テスト时に製品の脆弱性を発见して报告する场合や、セキュリティ研究者が调査中に脆弱性を発见した场合などがこれに该当します。このプロセスでは、まだ一般に公开されていないセキュリティ?インシデントを扱うため、组织に対してインシデントを秘密里に报告できるようなメカニズムが必要です。报告メカニズムがセキュアでないと、组织に报告されるすべての脆弱性が攻撃者に筒抜けになるため、脆弱性の悪用が容易になります。また、このプロセスでは、报告された脆弱性に関する情报にアクセスできる人员を、组织内でその情报を本当に必要とする者に限るよう、厳密に管理する必要があります。组织に不満を持った従业员が金銭目的で脆弱性に関する情报をリークすることもあります。このため、このプロセスではインシデントの报告に関してだけでなく、トリアージ、軽减、および运用环境での製品への解决策の导入时にも机密性を维持できるようなメカニズムを用意しておく必要があります。

解决策の导入には、影响を受ける当事者（製品を最终製品に统合した顾客や、エコシステムに製品を导入した顾客など）に脆弱性の存在を知らせ、その解决策を提供することも含まれます。既製品のコンポーネントなど、広く运用される製品の场合は、インシデント管理プロセスの一环として责任ある脆弱性开示メカニズムを用意し、影响を受けるすべての当事者が脆弱性情报を入手して迅速に是正措置を讲じられるようにする必要があります。

まとめ

自动车业界が新しい可能性を求めて電子化を進める中、道路利用者に対する潜在的な危害は指数関数的に増大しており、サイバーセキュリティへの取り組みが必須となっています。この指数関数的な増大は、自动车业界におけるエレクトロニクスの導入とサイバーセキュリティの脅威の両方が急速に拡大していることに原因があります。このように脅威への露出が増えたことにより、顧客は今後、製品の安全および品質保証と同様にサイバーセキュリティ保証を求めるようになってきます。また、顧客は単なる認証だけでなく、サプライヤーのサイバーセキュリティ?プロセスに関する詳細も要求してくる可能性があります。コンポーネント?サプライヤーが自动车市場で競争力を維持するには、標準化が進められているサイバーセキュリティの原則とプロセスを採用することが不可欠となっています。