　脆弱性情報の入電は、社内の開発部門などが自ら発見するもの、社外から連絡を受けるもの、脆弱性データベース（DB）サイトやWebメディアの記事を監視して収集するものなどがある。中には、学会やハッカーコミュニティーに参加することで、脆弱性の発見者から内々に知らされる場合もある。PSIRTメンバーは、社外でのいわゆるロビー活動も求められる。この他、自動車に対してサイバー攻撃が仕掛けられた際に出力されるエラーログを収集して分析した情報も入ってくるであろう。

　まず社内に目を向けると、開発フェーズにおけるリスク分析やテストにおいて、脆弱性が発見されうる。生産フェーズへ移る前段階での脆弱性対応の場合、販売店を通じた顧客対応が不要となるため、できる限り発見しておきたいところである。OEMとサプライヤーは開発完了までに、脆弱性DBサイトの監視やセキュアプログラミングツールなどを用いて、脆弱性ゼロを目指したCS活動を積極的に進めたい。

　生産フェーズ後の社外からの入電としては、当局からの連絡、販売店や相談窓口を通じたお客さまからの問い合わせ、OEMやサプライヤーのPSIRT、AUTO-ISACからの通報などがある。こうした社外関係者から早く確実に脆弱性情報を受け取れるよう、自社のWebサイトなどに連絡窓口を設けると良い。

　脆弱性情報は専門家でも理解することが難しい場合もある中で、すぐに結論を求めがちな入電者との会話ですれ違いが生じると、未対応のまま脆弱性情報が公開されてしまう懸念がある。入電者からの初報としては、電話での受付を避けてメールで連絡を受け、PSIRTメンバーが内容をある程度確認した上で、メールや電話での会話へ移行する手順についても考えてみたいところである。図3-2に、メールでの連絡フォームの一例を示す。連絡のための記載が面倒で脆弱性情報を内密にされないためにも、あまり多くの情報を求めず、まずはトリアージ^（※3）できる最低限の情報と連絡先の記載をお願いすると良い。

（※3）PSIRT活動におけるトリアージとは、脆弱性情報の信ぴょう性の確認を経て、影響レベルや攻撃発生確率の分析による対応への優先順位付けの作業を指す。

図3-2　脆弱性情報の連絡用メールフォームの一例（クリックして拡大）出典：DNV GL

　脆弱性の監視については、脆弱性情報を公開するDBサイト^{（※4〜7）}、Webメディアの記事、SNSなどを定期的に確認する手法と、自動車に対するサイバー攻撃によって出力されうるログを収集して、分析する手法がある。

　DBサイトの定期確認については、自社が責任を担う製品に含まれるシステム、HW／SW部品をリスト化しておき、これらについて検索すると良い。このとき、OEMは、自動車レベル、自社開発製品があればそのシステム、HW／SW部品について確認し、サプライヤーは自社責任で開発したシステム、HW／SW部品について確認することで、階層化による網羅的な監視が可能になる。OEMとサプライヤーは、開発契約の中で、脆弱性の監視やパッチ作成などの対応について、その責任範囲や対応期間を、あらかじめ取り決めておく必要がある。

（※4）CVE（Common Vulnerabilities and Exposures）：https://cve.mitre.org/

（※5）NVD（National Vulnerability Database）：https://nvd.nist.gov/

（※6）JVN（Japan Vulnerability Notes）：https://jvn.jp/

（※7）JVN iPedia：https://jvndb.jvn.jp/

　次に、自動車へのサイバー攻撃の監視には、自動車側で攻撃ログを出力する機能を設けて、センター側で分析できるフレームワークが必要となる。誤検知に振り回されて肝心なときに対応できなくならないよう、確実に攻撃と判断できるログや分析手法として、どのようなものが適切かを考える必要がある。

　もしログに自動車の位置情報が含まれる場合には、自動車ユーザーの行動監視に該当する懸念もあり、プライバシー保護への対応も求められる。これについては、General Data Protection Regulation（GDPR）^（※8）などの各国法令への順守に配慮する必要がある。

（※8）個人情報保護委員会　GDPR（一般データ保護規則）：https://www.ppc.go.jp/enforcement/infoprovision/laws/GDPR/

リスクをどう分析し、公表するか

前のページへ 1|2|3 次のページへ