つながるクルマの「修理権」で想定される課題と懸念：修理する権利とコネクテッドカー（2）（2/3 ページ）
前回の記事では、2020年に米国マサチューセッツ州で承認された「車両を修理する権利」の改正案を紹介した。今回は修理権に関するセキュリティの課題と懸念をさらに調査し、それらに対処するためのセキュリティのアプローチについて説明する。
適切なセキュリティコントロール
最初の項目「適切なセキュリティコントロール」に関しては、まず自動車のソフトウェアを開発する組織がユースケース全体の適切な脅威分析とリスクアセスメントを実行することが不可欠だ。ここではISO/SAE 21434（※3）の脅威分析とリスクアセスメントの条項に記載されている手順を参考にすることができる。
（※3）関連リンク：ISO/SAE 21434 Road vehicle - Cybersecurity engineering, https://www.iso.org/standard/70918.html
図2に表示されている通り、セキュリティコントロールを定義する手順にはいくつかのステップがある。
最初のステップでは診断や修理、メンテナンスに関連するデータ、一般の修理工場、ユーザーのモバイルアプリケーション、自動車メーカー固有のデータなどの資産を特定する。このステップでは機密性、完全性、可用性、認証、承認などさまざまな資産に関連するセキュリティプロパティを定義する必要もある。さらに、そのセキュリティプロパティが悪用された場合の影響のダメージシナリオを特定することも必要である。
例えば、位置データなどの個人データの機密性が悪用された場合のダメージシナリオは「ユーザーの同意なしに個人情報が開示されること」だ。これにより、攻撃者は車両の使用状況と場所の追跡が可能になる。
手順の次のステップでは、このユースケースに関連する脅威を特定する。例えば、適切な承認なしにデータにアクセスすること、オープンプラットフォームやユーザーのモバイルアプリケーションのなりすまし、データの改ざん、個人データまた機密データの開示、オープンプラットフォームに対してのサービス拒否攻撃などが考えられる。また、この脅威に関する攻撃経路や影響評価と攻撃の実現可能性の評価を決定する必要がある。
最後に、さまざまな脅威に対してのリスク値を、先に述べた脅威シナリオ、影響評価および攻撃実現可能性評価に基づいて計算する。組織はリスクの高い脅威を分析し、リスクを軽減するための適切なセキュリティコントロールを定義する。セキュリティコントロールには、オープンプラットフォームと一般の修理工場間のセキュアな通信、ユーザーの適切な認証、一般の修理工場がユーザーに関連する車両データにアクセスできるようにするための適切な承認が含まれる。
セキュアなソフトウェア開発プロセス
2番目の項目「セキュアなソフトウェア開発プロセス」では、組織がこのユースケースに関連するコンポーネントのセキュアなソフトウェア開発のためのベストプラクティスに従うことが不可欠である。例として、Microsoft Security Development Lifecycle （SDL）（※4）がある。これは、開発者がソフトウェアの脆弱性の数と重大度を減らし、開発コストを削減しながら、よりセキュアなソフトウェアを開発するのに役立つ一連のプラクティスで構成されている。
（※4）関連リンク：Microsoft Security Development Lifecycle （SDL）, https://www.microsoft.com/en-us/securityengineering/sdl
手順とアクティビティーとしては、セキュアな設計、標準暗号の使用およびコーディングガイドラインに沿ったセキュアなコーディングが挙げられる。さらに、さまざまな自動化ツールを使用して、セキュリティチェックを実行し、ソフトウェアの脆弱性を特定することを推奨する。例えば、ツールを使用して静的解析セキュリティテストと脆弱性スキャンやファジングテストなどの動的セキュリティテストを実行することだ。
さらに、熟練したセキュリティ専門家が侵入テストを実行することも勧める。開発中のベストプラクティスに従うことに加えて、組織が新しい脅威や攻撃の監視を含む継続的なサイバーセキュリティ活動を実行することも重要だ。例えばインシデント対応として重大な脆弱性に対処するためタイムリーなソフトウェアアップデートを提供することが重要である。
Copyright © ITmedia, Inc. All Rights Reserved.