close search bar

Sorry, not available in this language yet

close language selection

自動車業界のサイバーセキュリティを軌道に乗せる

Synopsys Editorial Team

Jun 27, 2022 / 1 min read

自動車業界のセキュリティチームにとって、2021年は多忙な年でした。サイバーセキュリティが市場参入とコンプライアンスの要件となったため、業界全体が厳しいスケジュールに直面しました。

  • 国連規則WP.29 R155は、「欧州連合では、2022年7月からすべての新型車、および2024年7月から生産されるすべての新車に対してサイバーセキュリティに関する新しい規制が義務化される」と規定しています。
  • 2021年8月31日、ISO/SAE 21434規格が「Road vehicles – Cybersecurity engineering(道路車両 — サイバーセキュリティ・エンジニアリング)」として正式に発行されました。このドキュメントでは、車両製品のライフサイクル全体にわたるサイバーセキュリティ・プロセス要件とサイバーセキュリティ・リスク管理のフレームワークを定義しています。
  • 世界最大の自動車市場である中国では、2021年9月14日、工業情報化部機器産業開発センター(Equipment Industry Development Center)が「Opinions on Strengthening the Management of Intelligent Networked Automotive Manufacturers and Product Access(インテリジェントにネットワーク化された自動車メーカーの管理と製品アクセスの強化に関する意見)」を発行しました。この意見書では、完成車メーカー(OEM)に対し、車両データセキュリティ、サイバーセキュリティ、無線通信(OTA:Over-The-Air)によるソフトウェア更新、運転支援機能の自己評価を実施することを義務付けています。結果の報告期限は2021年10月12日でした。

自動車業界の企業のセキュリティグループは、厳格なサイバーセキュリティ・コンプライアンス要件による「強制的な成長」を経験しています。各規格は詳細で明確な要件を規定していますが、セキュリティ・グループはこれらの複雑なチェックリストを分類して、各組織の能力の範囲内で実装できる作業のアクションプランを策定する必要があります。

個々のセキュリティアクティビティがプロセスベースのサイバーセキュリティ管理システム(CSMS)に姿を変えさせられた一方で、自動車業界の企業は、限られたリソースを迅速に集中させて、コンプライアンス要件を満たすエンタープライズセキュリティ機能を効率的に確立する必要があります。完成車メーカー(OEM)のセキュリティチームは、この2つの全く異なるアプローチ(単眼と複眼、深さと幅広さ)を課されるという難題に直面していますが、他の企業がこの問題を解決するために取った方法を参考にすることは大いに有益です。

BSIMMについて

2008年、コンサルタント、リサーチ、データのエキスパートで構成される現在のシノプシス ソフトウェア・インテグリティ・グループは、ソフトウェア・セキュリティの課題に対処するために組織が取っている様々な進路についてデータを収集し始めました。その目的は、効果的なソフトウェア・セキュリティ対策を導入している組織を調査し、組織の活動に関して対面による聞き取りを行い、その結果を公表することでした。その成果が最初の「Building Security In Maturity Model」(BSIMM)レポートになりました。

その後、9社から始まったBSIMMの参加企業は成長・発展を続け、2021年には128社に約3,000人のソフトウェア・セキュリティ・グループ・メンバーと6,000人以上のサテライトメンバー(セキュリティチャンピオン)を擁するまでになりました。

BSIMMレポートは、実地観測によって収集されたデータに基づいて独自の視点を提供し、CISOをはじめとするセキュリティリーダーに、実装のために考慮すべき重要なアクティビティ、プラクティス、ツールなど、独自のソフトウェア・セキュリティ・プログラムをテスト、測定、ベンチマーキングするためのモデルとフレームワークを提供します。

BSIMMは、規制、標準、セキュア・ソフトウェア開発ライフサイクル(SSDL)、プロセスモデルなどの規範モデルとは異なり、観察結果の文書化、観察データの効率化、ソフトウェアセキュリティ対策を記述・伝達するための共通言語の作成に焦点を当てた「事実」に基づく記述モデルのアプローチを採用しています。

BSIMMの特定のセキュリティアクティビティを、対応する実装状況と比較しても、良し悪しの判断はできません。分析こそが、エンタープライズ・ソフトウェア・セキュリティ対策向上の基盤となり得ます。BSIMMはセキュリティグループにとっての評価の尺度であり、ルールブック(規則集)ではありません。

自動車業界における現在のサイバーセキュリティの問題のほとんどは、車両のネットワークとインテリジェンスに関連しています。さらに、ソフトウェア定義型車両テクノロジの普及により、自動車業界におけるソフトウェアセキュリティとソフトウェア開発プロセスは、別個のカテゴリとして扱わなくてはならないほど重要性が増しています。BSIMMはソフトウェアセキュリティに重点を置いていますが、ハイテク業界の製品メーカーでは、ソフトウェアやアプリケーションのセキュリティだけでなく、製品関連のセキュリティアクティビティを測定するためにも使用されています。

BSIMMは、ガバナンス、インテリジェンス、SSDLタッチポイント、デプロイの4つの領域で構成され、現在122のアクティビティを含む、12のソフトウェア・セキュリティ・プラクティスのフレームワークを採用しています。BSIMMアクティビティは、ソフトウェア・セキュリティ・リスク管理のフレームワークに実装された対策と見なすことができます。実装されたアクティビティは、ソフトウェアセキュリティ対策において、予防的、発見的、修正的、または補正的な対策として機能する場合があります。これらのアクティビティを対策として位置づけることで、ガバナンス、リスク、コンプライアンスの各チーム、および法務、監査、その他のリスク管理グループはBSIMMの価値を理解しやすくなります。

BSIMMが自動車業界、特にソフトウェア・セキュリティ・システムの構築にもたらす価値を理解しやすくするために、セキュリティプラクティスの具体例をご紹介します。

ガバナンス主導の取り組み

UN R155では、完成車メーカー(OEM)はまずサイバーセキュリティのシステムとプロセスの基本的な能力を証明する必要があると規定しています。生産された各モデルは、製品が認定されたサイバーセキュリティ・システムおよびプロセス要件に従って実装されていることを証明するために、型式承認を必要とします。しかし、多くの完成車メーカー(OEM)は逆のアプローチを取り、規制と規格をプロジェクトのサイバーセキュリティ要件として採用しています。これにより、作業成果物を企業全体のコンプライアンスの証明として役立てることが可能になります。

BSIMM12レポートは、企業がセキュリティシステムの成熟度を高めるための進路は2つあると指摘しています。一つは、コンプライアンス要件に従ってセキュリティシステム全体を構築する方法で、もう一つは、エンジニアリングチームを活用してセキュリティ能力を向上させる方法です。

BSIMMは記述モデルであるため、この2つのアプローチを記述および比較しますが、長所と短所の評価はしません。ガバナンス主導のアプローチを選択する場合は、通常、ソフトウェアセキュリティ対策を定義することから始めます。この対策は、ソフトウェア・セキュリティ・アクティビティを統合的に浸透させ、測定、管理、推進する全組織的プログラムです。このような対策では、まずリーダーが一元化されたチーム構造を確立します。直ちに従業員を雇用する必要はないとしても、組織レベルでのソフトウェアセキュリティ関連のポリシー、スタンダード、手順のさらなる定義と制度化をサポートするための重要な活動を実施するために、常勤のチームを結成する必要があるかもしれません。

BSIMM12レポートでは、3つの主要なセキュリティアクティビティが定義されています。

  • ポリシー:ポリシーを策定する
  • スタンダード:セキュリティスタンダードを確立する。
  • プロセス:プロセスを公開し、必要に応じて展開する

しかし、多くの完成車メーカー(OEM)の現在の組織構造では、セキュリティチームの人員はエンジニアリング研究開発チームから選任されることが多く、セキュリティ関連のポリシー、スタンダード、手順を全社レベルで実装するための十分な権限を持っていません。しかも、セキュリティグループに対するサポートと予算は不足気味の傾向があるため、これらの主要アクティビティの対象を絞り込んで特定のプロジェクトに制限し、プロジェクトの予算内に収める必要があります。

BSIMMでは、ソフトウェアセキュリティ向上に対するガバナンス主導のアプローチとエンジニアリング主導の新たなアプローチには、関連性がないものも含めて、リスク管理に関する様々な視点が包含されていることが観察されました。ガバナンス主導のグループは、多くの場合、ルール、ゲート、コンプライアンスに焦点を当てていますが、エンジニアリング主導の新しい取り組みでは、通常、機能の速度、自動化によるエラー回避、ソフトウェアの回復力に焦点を当てています。

見解の一致は成功するための必須条件ではありませんが、企業の安全を確保するためには視点を統一する必要があります。つまり、リスク管理の問題にチーム間で協力して取り組むことで、強みを活かし、弱点を強化する必要があるということです。多くの完成車メーカー(OEM)はエンジニアリングプロジェクトを通じてサイバーセキュリティ・システムを構築していますが、この手法ではセキュリティグループがフレームワーク全体を理解する必要があります。そのため、セキュリティチームが特定のプロジェクトに限らず、十分な全社的サポートを受けられる体制が重要です。

TARA(Threat Analysis and Risk Assessment:脅威分析とリスク評価)によるリスク評価

正式に発行されたISO/SAE 21434では、脅威分析とリスク評価(TARA)のアクティビティおよび関連する要件に一章が割かれています。これは自動車業界におけるTARAアクティビティの重要性を反映しています。

TARAは単に製品のセキュリティ要件を策定するための準備作業と見なされている場合があり、多くの完成車メーカー(OEM)や部品サプライヤーは依然として外部のセキュリティエキスパートやコンサルタントを雇ってTARAを実装していますが、 現在は、TARAを実装する際にはISO/SAE 21434で定義されている詳細な要件に従う必要があります。セキュリティチームはセキュリティ保護のメカニズム(サイバーセキュリティ対策)をよく理解していますが、サイバーセキュリティ要件をエンジニアリングチームに伝えることが課題になっています。

TARAアクティビティは、潜在的な脅威を特定し、その脅威によってもたらされるリスクを評価することによって、サイバーセキュリティ要件の根拠を明らかにし、最適化します。また、TARAのもう一つの重要な目的は、外部の脅威やリスクとセキュリティ対策との関係を追跡し、様々なリスクレベルに基づいてサイバーセキュリティに関する後続の開発とテストのアクティビティの優先順位を決定することです。これにより、セキュリティチームはリスクの高い脅威への対応に集中できます。ISO/SAE 21434では、このようなトレーサビリティの確保のためにサイバーセキュリティ保証レベル(CAL)を使用します。TARAアクティビティの成果を上げるには、重要分野のセキュリティを強化するために(限られた)予算をどこに投入すべきかをセキュリティグループが把握できるようにする必要があります。

BSIMMのセキュリティフレームワークは、インテリジェンスドメインの攻撃モデルのプラクティスを重視しています。攻撃モデルは、脅威モデリング、悪用ケース、データの分類化、テクノロジ固有の攻撃パターンに関する情報を収集し、セキュリティの問題を攻撃者の視点で考えるために役立ちます。BSIMM12は、セキュリティグループがこの分野の不備を補うための参考になる、攻撃モデリングに関連する11のセキュリティアクティビティが観察されたと記述しています。

ペネトレーションテストでセキュリティ上の問題を検出する

セキュリティ機能とSSDLがスタンダードになる以前には、完成車メーカー(OEM)のセキュリティグループの間で一般的に使用されるセキュリティアクティビティはペネトレーションテストでした。ペネトレーションテストにより、製品の脆弱性を発見して公開することが可能になり、それに伴ってセキュリティ要件の必要性が高まりました。BSIMM12によると、参加企業の87%が外部のペネトレーション・テスト・サービスを利用して問題を発見しています。ペネトレーションテストは、セキュリティの問題の影響と無縁ではいられないことを組織に対して明確に立証し、敵対的な思考を提示して、盲点を排除することを可能にします。

ペネトレーション・テストでセキュリティ上の問題を検出する

効果的な侵入攻撃を行うには、テスターがシステムの脆弱性と、その脆弱性を悪用する効果的な方法を見つける必要があります。ペネトレーション・テスト・プロジェクトでは、一般にテストスケジュールが固定されており、多くの場合、テスト環境とターゲットを「ブラックボックス化」してテスターに提供します。そのため、テスターが未知の脆弱性を詳しく調べたり、プロジェクトの期限内に検索の範囲を拡大することが困難で、システムの脆弱性を狙ってエクスプロイトを仕掛けるよりも脆弱性の発見に多くの時間を割かれることになりがちです。

これに対処するために、セキュリティグループは、社内または外部のペネトレーションテスターに詳細な技術情報を提供することで、ブラックボックス・テストをグレーボックス・テストに変えることができます。テスターは、ソースコード、設計書、アーキテクチャ分析結果、悪用ケース、コードレビューの結果、クラウド環境のデプロイコンフィグレーションを用いることで、より詳細な解析を行い、より重要な問題を特定することができます。ペネトレーションテストの内容例を以下に示します。

  • 概念設計フェーズでのTARAレポートと、特定された脅威シナリオ、攻撃方法、および構築された攻撃ツリー。ペネテーションテスターは、システム実装の効果、残留リスクが許容可能かどうかの判断などについて、対応するセキュリティ保護対策と詳細事項を推奨するために、テスト中に対応する検証の実行を要求されることがあります。
  • 実装されたコードに対する静的解析とセキュリティスキャンにより、ペネトレーションテスターはペネトレーションテストの動作をターゲットにしてその妥当性を改善できます。
  • テスターがシステムの内部に直接侵入できるように、既に開かれているインターフェイスでテストします。この方法でインターフェイスを開くと、実際の攻撃者がターゲット資産に直接アクセスするのではなく、段階的な攻撃方法を取った場合の動作をシミュレーションします。この手法は、多層防御設計が適切に実装されているかどうかを確認するためにも利用できます。

BSIMM12レポートでは、ペネトレーションテストに関連する7つのセキュリティ・アクティビティで構成される3レベルのテストが定義されており、セキュリティグループが製品のセキュリティを向上させるための参考にできるようになっています。

レベル1

  • 外部のペネトレーションテスターを使用して問題を特定する
  • 不具合管理および低減システムに結果をフィードバックする
  • ペネトレーション・テスト・ツールを社内で使用している

レベル2

  • ペネトレーションテスターが存在する情報すべてを使用している
  • アプリケーションカバレッジの定期的なペネトレーションテストを計画する

レベル3

  • 外部のペネトレーションテストを使用して詳細な解析を実行する
  • ペネトレーション・テスト・ツールをカスタマイズする

インシデント対応計画を作成する

100%安全なシステムや製品は存在しません。セキュリティの主な目標は、セキュリティインシデントに速やかに効果的に対応し、リスクを適切に管理することです。BSIMM12のソフトウェア・セキュリティ・フレームワークは、構成管理と脆弱性管理を重要なセキュリティプラクティスとして具体的に定義し、関連する12のセキュリティアクティビティの詳細を規定しています。例えば、BSIMM12の参加者の84%は、ソフトウェア・セキュリティ・チームが組織のインシデント対応チームと緊密に連携し、重要なセキュリティ情報の双方向のやり取りを続けています。インフラストラクチャベンダーやソフトウェアベンダーとの通信チャネルを開くことも、ソフトウェア・セキュリティ・グループにとって重要なタスクです。さらに、BSIMMには、セキュリティインシデント対応により既存のセキュリティプロセスを改善する方法を示すセキュリティアクティビティも含まれています。

成功への道

サイバーセキュリティにおける課題は、絶えず進化する外部の脅威への対応です。多くの場合、コンプライアンス証明書がある組織でも、網羅しているのは基本的なセキュリティ機能のみです。企業のセキュリティチームは、業務を推進するために継続的な改善を必要としています。年次BSIMMレポートは、実データの観察と分析に基づいて変化し、進化する生きたドキュメントです。開発手法の進化につれて新たな脅威が出現し、セキュリティ手法がこれに適応して、BSIMMデータは一歩ずつ進化していきます。BSIMMレポートは、ソフトウェアセキュリティ分野の新しいトレンドに関する洞察と分析の結果を詳述し、企業のセキュリティ・チームが時代に後れを取らないための参考資料を提供しています。参加企業のBSIMMコミュニティは、情報を交換しながらお互いに学び合っています。BSIMMレポートは完全に公開されており、オンラインで入手できます。Synopsysのエキスパートにご連絡いただけば、より詳細な分析や解釈を入手し、詳細な評価のスケジューリングについて学ぶこともできます。

 

BSIMM: アプリケーション・セキュリティの成功モデル

BSIMM: アプリケーション・セキュリティの成功モデル

BSIMMレポートは、AppSecの成熟度評価の基準を提供し、セキュリティ専門家同士をつなぐコミュニティの役割を果たし、対策アクションプランの策定を支援する推進モデルです。

Continue Reading

トピックを探索する