(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024110832
(43)【公開日】2024-08-16
(54)【発明の名称】管理装置、管理システム、及び管理方法
(51)【国際特許分類】
G06F 21/57 20130101AFI20240808BHJP
【FI】
G06F21/57 370
【審査請求】未請求
【請求項の数】5
【出願形態】OL
(21)【出願番号】P 2023015671
(22)【出願日】2023-02-03
(71)【出願人】
【識別番号】000006507
【氏名又は名称】横河電機株式会社
(74)【代理人】
【識別番号】100147485
【弁理士】
【氏名又は名称】杉村 憲司
(74)【代理人】
【識別番号】230118913
【弁護士】
【氏名又は名称】杉村 光嗣
(74)【代理人】
【識別番号】100169823
【弁理士】
【氏名又は名称】吉澤 雄郎
(74)【代理人】
【識別番号】100195534
【弁理士】
【氏名又は名称】内海 一成
(72)【発明者】
【氏名】辻 宏隆
(57)【要約】
【課題】複数の脆弱性を適切に評価できる管理装置、管理システム、及び管理方法を提供する。
【解決手段】管理装置10は、製品の脆弱性のリスクの高さを評価する評価部12を備える。評価部12は、製品の複数の脆弱性のそれぞれのリスクの高さに基づいて、製品の脆弱性のリスクの高さを表す重大度の総和を算出する。評価部12は、重大度の総和がアラート基準以上である場合にアラートを出力する。
【選択図】
図4
【特許請求の範囲】
【請求項1】
製品の脆弱性のリスクの高さを評価する評価部を備え、
前記評価部は、
前記製品の複数の脆弱性のそれぞれのリスクの高さに基づいて、前記製品の脆弱性のリスクの高さを表す重大度の総和を算出し、
前記重大度の総和がアラート基準以上である場合にアラートを出力する、管理装置。
【請求項2】
前記評価部は、
前記複数の脆弱性のそれぞれのリスクの高さを定量化した数値を算出し、
前記複数の脆弱性のそれぞれの重大度を定量化した数値に基づいて、前記複数の脆弱性のそれぞれの重大度を複数のレベルに分類して前記複数の脆弱性のそれぞれの重大度レベルを決定し、
前記複数の脆弱性のそれぞれの重大度レベルを定量化した定量化重大度を算出し、
前記複数の脆弱性のそれぞれの重大度レベルを定量化した定量化重大度の総和を、前記重大度の総和として算出する、
請求項1に記載の管理装置。
【請求項3】
前記評価部は、前記複数の脆弱性のうち脅威情報が得られた脆弱性について、重大度レベルを上げて定量化し、前記定量化重大度を算出する、請求項2に記載の管理装置。
【請求項4】
請求項1から3までのいずれか一項に記載の管理装置と、製品の複数の脆弱性に関する情報を格納するデータベースとを備える、管理システム。
【請求項5】
製品の脆弱性のリスクの高さを評価する管理装置が実行する管理方法であって、
前記製品の複数の脆弱性に関する情報を取得することと、
前記複数の脆弱性のそれぞれのリスクの高さに基づいて、前記製品の脆弱性のリスクの高さを表す重大度の総和を算出することと、
前記重大度の総和がアラート基準以上である場合にアラートを出力することと
を含む管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、脆弱性対応における製品プロバイダのサイバーセキュリティリスクを管理する、管理装置、管理システム、及び管理方法に関する。
【背景技術】
【0002】
従来、コンピュータを応用した製品に複数のセキュリティーホールがある場合にセキュリティーホール毎の脅威レベルを評価するシステムが知られている(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
製品で認知された複数の脆弱性のリスクの高さを適切に評価することが求められる。
【0005】
本開示は、上述の点に鑑みてなされたものであり、製品で認知された複数の脆弱性のリスクの高さを適切に評価できる管理装置、管理システム、及び管理方法を提供することを目的とする。
【課題を解決するための手段】
【0006】
幾つかの実施形態に係る管理装置は、製品の脆弱性のリスクの高さを評価する評価部を備える。前記評価部は、前記製品の複数の脆弱性のそれぞれのリスクの高さに基づいて、前記製品の脆弱性のリスクの高さを表す重大度の総和を算出する。前記評価部は、前記重大度の総和がアラート基準以上である場合にアラートを出力する。
【0007】
幾つかの実施形態に係る管理システムは、上記管理装置と、製品の複数の脆弱性に関する情報を格納するデータベースとを備える。
【0008】
幾つかの実施形態に係る管理方法は、製品の脆弱性のリスクの高さを評価する管理装置が、前記製品の複数の脆弱性に関する情報を取得することを含む。前記管理方法は、前記管理装置が、前記複数の脆弱性のそれぞれのリスクの高さに基づいて、前記製品の脆弱性のリスクの高さを表す重大度の総和を算出することを含む。前記管理方法は、前記管理装置が、前記重大度の総和がアラート基準以上である場合にアラートを出力することを含む。
【0009】
複数の脆弱性のそれぞれの重大度の総和を考慮することによって、複数の脆弱性のそれぞれが単独で存在するとみなしてそれぞれのリスクの高さを評価する場合と比べて、複数の脆弱性が同時に存在する場合に生じるリスクの高さが適切に評価される。また、アラートの出力によって、製品責任者又は経営層等の人間が脆弱性の対策をタイムリーに指示できる。脆弱性の対策がタイムリーに指示されることによって、リスクが高まっている期間が短縮される。その結果、製品のユーザの生産システムのサイバーセキュリティリスクが軽減する。また、ビジネスリスクが軽減する。また、製品のサイバーセキュリティリスクが効率的に管理される。また、製品のサイバーセキュリティリスク管理のコストが削減される。
【0010】
一実施形態に係る管理装置において、前記評価部は、前記複数の脆弱性のそれぞれのリスクの高さを定量化した数値を算出してよい。前記評価部は、前記複数の脆弱性のそれぞれの重大度を定量化した数値に基づいて、前記複数の脆弱性のそれぞれの重大度を複数のレベルに分類して前記複数の脆弱性のそれぞれの重大度レベルを決定してよい。前記評価部は、前記複数の脆弱性のそれぞれの重大度レベルを定量化した定量化重大度を算出してよい。前記評価部は、前記複数の脆弱性のそれぞれの重大度レベルを定量化した定量化重大度の総和を、前記重大度の総和として算出してよい。また、一実施形態に係る管理装置において、前記評価部は、前記複数の脆弱性のうち脅威情報が得られた脆弱性について、重大度レベルを上げて定量化し、前記定量化重大度を算出してよい。
【0011】
脆弱性の重大度の定性的な評価が定量化されることによって、その評価結果の通知を受けた人間が脆弱性のリスクの高さを直感的に理解しやすくなる。また、人間が理解しやすい脆弱性の脅威情報に基づいて重大度のレベルが上げられることによって、人間がリスクの高さの評価結果を理解しやすくなる。
【発明の効果】
【0012】
本開示に係る管理装置、管理システム、及び管理方法によれば、複数の脆弱性のリスクの高さが適切に評価される。
【図面の簡単な説明】
【0013】
【
図1】比較例におけるアラート対象の判定を説明する図である。
【
図2】本開示の一実施形態に係る管理システムの構成例を示すブロック図である。
【
図3】本開示の一実施形態に係る管理方法の手順例を示すフローチャートである。
【
図4】本開示の一実施形態においてアラートを出力する基準を説明する図である。
【
図5】脆弱性の評価の対象とされる対象製品における、機能のつながり及び各機能に存在する脆弱性の例を示す図である。
【発明を実施するための形態】
【0014】
製品プロバイダにおいて、製品の脆弱性に関するサイバーセキュリティリスクの管理が求められる。製品の脆弱性調査案件は、同時多発的に発生する場合がある。脆弱性の対策は、例えば脆弱性を解消するために製品に適用するパッチを作成すること等によって実行される。脆弱性の対策の作成(例えばパッチの作成)のスケジュールは、脆弱性の内容によって異なる。脆弱性の対応を完了するまでにかなりの時間が必要とされる場合もある。複数の脆弱性が発生した場合、複数の脆弱性のそれぞれについて対策する必要がある。
【0015】
(比較例)
比較例として、複数の脆弱性が発生した場合に、脆弱性の対応が脆弱性単位で実行される。脆弱性の対応として、脆弱性の影響を受ける製品若しくは脆弱性のリスクの高さの把握、又は、脆弱性の対策を作成して情報を開示するまでの進捗の管理が実行される。
【0016】
脆弱性は、リスクの高さに基づいて複数のレベルに分類されることがある。比較例において、
図1に示されるように、個々の脆弱性が単体で存在するとみなして評価されたリスクの高さに基づいて、脆弱性のレベルが低、中、及び、高の3段階に分類されている。比較例において、個々の脆弱性について、脆弱性のレベルの高さに基づいてアラートを出力する必要があるか判定される。アラートの出力の判定の基準として、脆弱性のレベルの高さと比較するアラート基準が用いられる。アラート基準の意味は、アラートを発生させるリスクレベルの意味である。製品プロバイダが許容できないリスクレベルがアラート基準として定められる。リスクがアラート基準を超えた場合にアラートを出力することが判定される。比較例において、アラート基準は、脆弱性のレベルが中である場合と高である場合との間に設定されている。脆弱性のレベルが低又は中である場合、リスクの高さがアラート基準を下回っているので、その脆弱性はアラートの対象外である。一方で、脆弱性のレベルが高である場合、リスクの高さがアラート基準を上回っているので、その脆弱性はアラートの対象である。
【0017】
しかしながら、個々の脆弱性が単独で存在するとみなしてそのリスクを評価した結果、個々の脆弱性がアラートの対象外であったとしても、複数の脆弱性が発生していることによってリスクが高くなることがある。比較例において、製品における複数の脆弱性のリスクの高さによるサイバーセキュリティリスク評価が行われていない。したがって、比較例において、適切なリスク軽減対策が実行されない。
【0018】
製品がサイバー攻撃に利用できる脆弱性を複数保持している場合、サイバーセキュリティリスクが増すことから、製品が持つ複数の脆弱性を合わせたリスク評価及びリスク管理が必要である。複数の脆弱性のリスクの高さを考慮してサイバーセキュリティリスクの評価及び管理を実施することによって、製品プロバイダが複数の脆弱性に適切に対応することが可能になる。また、製品を利用するユーザのシステムのサイバーセキュリティリスクが軽減する。
【0019】
そこで、本開示は、複数の脆弱性を適切に評価できる管理装置、管理システム、及び管理方法について説明する。
【0020】
(管理システム1の構成例)
図2に示されるように、本開示の一実施形態に係る管理システム1は、管理装置10と、データベース20とを備える。
【0021】
<管理装置10>
管理装置10は、評価部12と、入力部14と、出力部16とを備える。
【0022】
評価部12は、製品の脆弱性に関する情報を取得し、製品の脆弱性に関する情報に基づいて製品の脆弱性のリスクの高さを評価し、製品の脆弱性のリスクの高さの評価結果に基づいて、脆弱性の対応を促すアラートを出力するかを決定する。評価部12は、例えばCPU(Central Processing Unit)等のプロセッサを含んで構成されてよい。評価部12は、プロセッサに所定のプログラムを実行させることによって所定の機能を実現してよい。
【0023】
評価部12は、記憶部を備えてよい。記憶部は、評価部12の動作に用いられる各種情報、又は、評価部12の機能を実現するためのプログラム等を格納してよい。記憶部は、評価部12のワークメモリとして機能してよい。記憶部は、例えば半導体メモリ等で構成されてよい。記憶部は、揮発性メモリ又は不揮発性メモリを含んで構成されてよい。記憶部は、HDD(Hard Disk Drive)等の電磁記憶媒体を含んで構成されてよい。記憶部は、非一時的なコンピュータ読み取り可能な記憶媒体として構成されてもよい。記憶部は、評価部12と一体に構成されてよいし、別体として構成されてよい。
【0024】
入力部14は、データベース20と有線又は無線で通信するように構成され、データベース20から製品の脆弱性に関する情報又は製品の脆弱性のリスクの高さを評価するためのデータを取得する。
【0025】
出力部16は、評価部12が脆弱性に関するアラートを出力すると決定した場合に、アラートを出力する。出力部16は、評価部12が脆弱性のリスクの高さを評価した結果を出力してもよい。出力部16は、アラート又は脆弱性のリスクの高さの評価結果を表示する表示デバイスを含んで構成されてよい。表示デバイスは、例えば液晶ディスプレイ等の種々のディスプレイを含んでよい。出力部16は、アラート又は脆弱性のリスクの高さの評価結果を音声情報として出力する、スピーカ等の音声出力デバイスを含んで構成されてよい。出力部16は、これらに限られず、アラート又は脆弱性のリスクの高さの評価結果を出力するための他の種々の出力デバイスを含んで構成されてよい。
【0026】
管理装置10は、PC(Personal Computer)として構成されてよいし、少なくとも1台のサーバ装置として構成されてよい。管理装置10は、クラウドコンピューティングのシステムで実現されてもよい。
【0027】
<データベース20>
データベース20は、脆弱性マスタ21のブロックと、脆弱性管理22のブロックと、ソフト管理マスタ23のブロックと、製品管理マスタ24のブロックとを備える。データベース20は、例えば半導体メモリ等で構成されてよい。データベース20は、揮発性メモリ又は不揮発性メモリを含んで構成されてよい。データベース20は、HDD等の電磁記憶媒体を含んで構成されてよい。データベース20は、複数のブロックがそれぞれ異なる記憶媒体に対応するように構成されてよい。データベース20は、複数のブロックが1台の記憶媒体に対応するように構成されてよい。データベース20は、各ブロックにおける情報又はデータの読み書きを制御するコントローラを備えてよい。データベース20の各ブロックがコントローラを備えてもよい。
【0028】
データベース20は、脆弱性のリスクの高さの評価の対象とする製品の情報(製品を構成するソフトウェア及びソフトウェアのバージョン等)をソフト管理マスタ23のブロックに格納する。データベース20は、情報提供元80から製品の脆弱性に関する情報を取得し、ソフト管理マスタ23からその製品の情報を取得し、製品の脆弱性に関する情報とその製品の情報とを関連づけた情報を脆弱性マスタ21に格納する。データベース20は、ソフト管理マスタ23から製品の情報を取得し、その製品が属するグループの情報に製品の情報を関連づけた情報を製品管理マスタ24のブロックに格納する。
【0029】
データベース20は、脆弱性マスタ21から製品の脆弱性に関する情報とその製品の情報とを関連づけた情報を取得し、製品管理マスタ24から製品の情報をその製品が属するグループの情報に関連づけた情報を取得し、取得した情報を関連づけた情報を脆弱性管理22のブロックに格納する。つまり、データベース20は、製品の情報とその製品が属するグループの情報とその製品の脆弱性に関する情報とを関連づけた情報を脆弱性管理22のブロックに格納する。
【0030】
データベース20は、脆弱性マスタ21及び脆弱性管理22に格納する脆弱性に関する情報に対して識別番号等の識別子を付与し、識別子によってリスクの高さの評価対象とする脆弱性を連携してよい。データベース20は、製品管理マスタ24及び脆弱性管理22に格納する脆弱性に関する情報に関連づけられている製品の情報によって脆弱性のリスクの高さの評価対象とする製品のグループを連携してよい。
【0031】
データベース20に対して製品の脆弱性に関する情報を提供する情報提供元80は、製品の脆弱性に関する情報を公開したり提供したりする、JVN(Japan Vulnerability Notes)等のウェブサイトであってよい。情報提供元80は、製品を使用しているユーザ又は製品を調査するリサーチャ等の人間であってもよいし、ユーザ又はリサーチャ等から脆弱性に関する情報を入手した、製品プロバイダで製品の脆弱性に対応するPSIRT(Product Security Incident Response Team)のメンバー等の人間であってもよい。情報提供元80が人間である場合、データベース20は、情報提供元80の人間からの情報の入力を受け付けるように構成されてよい。
【0032】
データベース20は、PSIRTから脆弱性をハンドリングするための情報の入力を受け付けてよい。データベース20は、脆弱性管理22に格納する情報に脆弱性をハンドリングするための情報を関連づけてよい。データベース20は、製品の脆弱性に対応する製品側脆弱性連絡窓口若しくは製品連絡窓口等のメンバー又は製品担当者等の人間からの脆弱性のリスクの高さの評価、又は、製品該非調査結果の入力を受け付けてよい。データベース20は、脆弱性管理22に格納する情報に、脆弱性のリスクの高さの評価、又は、製品該非調査結果を関連づけてよい。
【0033】
データベース20は、少なくとも1台のサーバ装置として構成されてよいし、クラウドコンピューティングのシステムで実現されてもよい。
【0034】
(管理システム1の動作例)
管理システム1において、データベース20は、製品の脆弱性に関する情報を格納する。脆弱性に関する情報は、脆弱性情報とも称される。管理装置10の評価部12は、製品の脆弱性の対策を実行する製品担当者等の人間に対して脆弱性情報を通知して脆弱性の調査又は対応を依頼する。製品担当者等の人間は、脆弱性のリスクの高さ又は脆弱性の対策の進捗等をデータベース20に入力する。脆弱性のリスクの高さは、重大度として表されるとする。言い換えれば、重大度は、脆弱性のリスクの高さを表す指標である。重大度は、後述するように、脆弱性のリスクの高さを定量化した数値として表されてもよいし、脆弱性のリスクの高さを定性的に評価したレベルとして表されてもよい。データベース20は、製品担当者等の人間が入力した情報を脆弱性情報に関連づける。評価部12は、データベース20において脆弱性情報に関連づけられた情報に基づいて製品の脆弱性のリスクの高さを評価し、脆弱性の対策を完了するまでの期間を管理する。評価部12は、製品の脆弱性のリスクの高さの評価結果を製品責任者等の人間が認識できるように、例えばダッシュボード等の形態で出力部16に表示させてよい。つまり、評価部12は、製品の脆弱性のリスクの高さの評価結果を見える化してよい。評価部12は、製品の脆弱性のリスクの高さの評価結果を、製品責任者等の人間に対するメール又はメッセージ等の送信によって通知してもよい。
【0035】
以下、評価部12が製品毎に脆弱性のリスクの高さを評価する動作の一例が説明される。評価部12は、
図3に例示されるフローチャートの手順例を含む管理方法を実行してよい。管理方法は、評価部12を構成するプロセッサに実行させる管理プログラムとして実現されてもよい。管理プログラムは、非一時的なコンピュータ読み取り可能な媒体に格納されてよい。
【0036】
評価部12は、データベース20の脆弱性管理22のブロックから脆弱性情報を取得する(ステップS1)。脆弱性情報は、上述したように、製品の情報とその製品が属するグループの情報とその製品の脆弱性に関する情報とを関連づけた情報である。
【0037】
評価部12は、評価対象とする製品が複数の脆弱性を有する場合、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定量化した数値として算出する(ステップS2)。評価部12は、例えばCVSS(Common Vulnerability Scoring System)のバージョン3に準拠した基準に基づいて、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定量化した数値を算出してよい。CVSSのバージョン3に準拠した基準に基づいて算出された、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定量化した数値は、CVSS値とも称される。言い換えれば、CVSS値は、CVSSのバージョン3に準拠した基準に基づいて算出された、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定量化した数値である。CVSSのバージョンはバージョン3に限られず最新のバージョンであってよい。CVSSのバージョン3によれば、CVSS値は、0.0から10.0までの範囲内の数値として表される。評価部12は、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定量化した数値を算出するために、CVSSに限られず他の種々の基準を用いてもよい。本実施形態において、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定量化した数値として、CVSS値が用いられる。
【0038】
評価部12は、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定量化した数値であるCVSS値に基づいて、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定性的に評価する(ステップS3)。具体的に、評価部12は、複数の脆弱性のそれぞれのCVSS値に基づいて、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを、定性的に表す、低、中及び高の3段階のレベルに分類してよい。複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定性的に表すレベルは、複数の脆弱性のそれぞれの重大度レベルとも称される。言い換えれば、重大度レベルは、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さを定性的に表すレベルである。
【0039】
評価部12は、複数の脆弱性のそれぞれについて、CVSS値と重大度レベルとを、以下の表1に例示される関係で対応づけてよい。評価部12は、表1に例示される関係に限られず他の種々の関係でCVSS値と重大度レベルとを対応づけてもよい。本実施形態において、評価部12は、表1に例示される関係に基づいて、複数の脆弱性のそれぞれが単独の脆弱性として存在する場合のそれぞれのリスクの高さの定量的な評価であるCVSS値から、定性的な評価である重大度レベルを決定する。
【0040】
【0041】
評価部12は、複数の脆弱性のそれぞれについて、脆弱性に関する脅威情報が得られた場合に、その脆弱性のリスクの高さの定性的な評価である重大度レベルを1段階上げてよい。脆弱性に関する脅威情報は、その脆弱性のリスクが悪用されるリスクに影響を与える情報である。脆弱性に関する脅威情報は、例えば、その脆弱性を利用した不正アクセスの予兆又は開始が確認された情報等を含んでよい。具体的に、評価部12は、脅威情報が得られた脆弱性の重大度レベルが低であった場合に単体脆弱性の重大度レベルを中に上げてよい。評価部12は、脅威情報が得られた脆弱性の重大度レベルが中であった場合に単体脆弱性の重大度レベルを高に上げてよい。評価部12は、脅威情報が得られた脆弱性の重大度レベルが高であった場合に単体脆弱性の重大度レベルを危険に上げてよい。つまり、評価部12は、脅威情報が得られた脆弱性の重大度レベルを1段階上げることを決定してよい。人間は、脅威情報が脆弱性のリスクの高さの評価に深く関係することを理解しやすい。つまり、脅威情報は脆弱性のリスクの高さの評価において人間が理解しやすい情報である。脆弱性の脅威情報に基づいて脆弱性の重大度レベルが上げられることによって、人間が脆弱性のリスクの高さの評価結果を理解しやすくなる。
【0042】
評価部12は、複数の脆弱性のそれぞれの重大度レベルに基づいて、複数の脆弱性のそれぞれのリスクの高さを定量化する(ステップS4)。評価部12は、以下の表2に例示される関係に基づいて複数の脆弱性のそれぞれの重大度レベルを定量化してよい。複数の脆弱性のそれぞれの重大度レベルを定量化した数値は、複数の脆弱性のそれぞれの定量化重大度とも称される。評価部12は、表2に例示される関係に限られず他の種々の関係で、複数の脆弱性のそれぞれについて、重大度レベルを定量化して定量化重大度を算出してもよい。本実施形態において、評価部12は、表2に例示される関係に基づいて、複数の脆弱性のそれぞれについて、重大度レベルを定量化して定量化重大度を算出する。
【0043】
【0044】
評価部12は、複数の脆弱性のそれぞれについて、重大度レベルを定量化して定量化重大度を算出する。定量化重大度は、脆弱性の重大度レベルを定量化した値である。評価部12は、評価対象とする製品が有する複数の脆弱性のそれぞれの定量化重大度の総和を算出する(ステップS5)。複数の脆弱性のそれぞれの定量化重大度の総和は、重大度の総和とも称される。
【0045】
評価部12は、重大度の総和がアラート基準以上であるか判定する(ステップS6)。アラート基準は、重大度の総和との比較基準として適宜設定された数値である。アラート基準の意味は、アラートを発生させるリスクレベルの意味である。製品ベンダーが許容できないリスクレベルがアラート基準として定められる。リスクがアラート基準を超えた場合にアラートを出力することが判定される。評価部12は、重大度の総和がアラート基準以上である場合(ステップS6:YES)、評価対象とする製品のサイバーセキュリティリスクが高まっていることを表すアラートを出力する(ステップS7)。評価部12は、ステップS7の手順の実行後、
図3のフローチャートの手順の実行を終了する。評価部12は、重大度の総和がアラート基準以上でない場合(ステップS6:NO)、つまり重大度の総和がアラート基準未満である場合、アラートを出力せずに
図3のフローチャートの手順の実行を終了する。
【0046】
本実施形態において、評価部12は、アラート基準の値を20に設定する。評価部12は、アラート基準の値を、20に限られず他の種々の値に設定してもよい。評価部12は、重大度レベルを定量化する関係に合わせてアラート基準の値を設定してもよい。
【0047】
評価部12は、アラートを出力部16によって出力することによって、脆弱性の対策を実行する製品担当者等の人間に通知する。出力部16は、ダッシュボード等の形式でアラートを表示してもよいし、アラートに関する情報を含む電子メール又はメッセージ等を人間に送ることによってアラートを通知してもよい。
【0048】
評価部12は、重大度の総和がアラート基準以上であるかアラート基準未満であるかにかかわらず、重大度の総和の算出結果、又は、複数の脆弱性のそれぞれの重大度レベルを製品責任者又は製品担当者等の人間に通知してもよい。複数の脆弱性のそれぞれの重大度レベルは、各脆弱性のリスクの高さの定性的な評価である。脆弱性のリスクの高さの定性的な評価結果が通知されることによって、人間が脆弱性のリスクの高さを直感的に理解しやすくなる。
【0049】
出力部16は、
図4に例示されるように脆弱性の重大度の総和をリスクの高さとして人間が認識できるように表示してよい。
図4において、横軸は時間を表す。縦軸はリスクの高さを表す。リスクの高さは重大度の総和の数値として表されてよい。ある時間帯において複数の脆弱性が同時に発生している場合、その時間帯におけるリスクの高さは、複数の脆弱性のそれぞれの重大度レベルを定量化した定量化重大度の総和である重大度の総和として表される。例えば、重大度レベルが低である脆弱性A、又は、重大度レベルが中である脆弱性Bが単独で発生している時間帯における製品の脆弱性のリスクの高さを定量化した数値は、アラート基準に対して十分に低い。脆弱性Bに加えて、重大度レベルが低である脆弱性C、並びに、重大度レベルが中である脆弱性D及びEが更に発生している時間帯における製品の脆弱性のリスクの高さを定量化した数値は、アラート基準以上になっている。人間は、
図4に例示されるような表示を認識することによって、製品の脆弱性のリスクの高さを定量化した数値がアラート基準以上になっており、製品の脆弱性に対して早急に対策を実施する必要がある状態になっていることを直感的に理解できる。
【0050】
評価部12は、
図4の例において脆弱性Eが発生したことによって製品の脆弱性のリスクの高さを定量化した数値がアラート基準以上になったときに、
図4に例示される表示の他の手段でアラートを出力してもよい。評価部12は、製品の脆弱性のリスクの高さを定量化した数値がアラート基準以上になっている期間にアラートを出力し続けてよい。評価部12は、製品の脆弱性のリスクの高さを定量化した数値がアラート基準以上になっているときのアラートとして、製品の脆弱性のリスクの高さを定量化した数値がアラート基準未満になるように製品の脆弱性の対策を実施する指示を、製品担当者等の人間に対して通知してよい。評価部12は、
図4の例において脆弱性Bが解消したことによって製品の脆弱性のリスクの高さを定量化した数値がアラート基準未満になったときに、他の手段で出力しているアラートを解消してもよい。
【0051】
<まとめ>
以上述べてきたように、本実施形態に係る管理システム1において、管理装置10は、製品において認知された複数の脆弱性のそれぞれのリスクの高さを定量化した数値の総和である重大度の総和に基づいて脆弱性のリスクの高さを評価してアラートを出力する。仮に製品の複数の脆弱性のそれぞれの重大度を個別に判定する場合、製品に複数の脆弱性が同時に存在する場合に生じるリスクが見逃されることがある。本実施形態によれば、製品の複数の脆弱性のそれぞれのリスクの高さを定量化した数値の総和である重大度の総和を算出することによって、製品に複数の脆弱性が同時に存在する場合に生じるリスクの高さの適切な評価及び脆弱性対策の管理が実現される。
【0052】
また、アラートの出力によって、製品責任者又は経営層等の人間が製品の脆弱性の対策をタイムリーに指示できる。製品の脆弱性の対策がタイムリーに指示されることによって、製品においてリスクが高まっている期間が短縮される。その結果、製品のユーザの生産システムのサイバーセキュリティリスクが軽減する。また、ビジネスリスクが軽減する。また、アラートの出力によって、製品のサイバーセキュリティリスクを管理するプロセスにおける属人性が排除される。その結果、製品のサイバーセキュリティリスクが人間のスキルに依存せずに管理される。また、本実施形態に係る管理システム1は、製品のサイバーセキュリティリスクを効率的に管理でき、製品のサイバーセキュリティリスク管理のコストを削減できる。
【0053】
上述したように、本実施形態に係る管理システム1において、管理装置10の評価部12は、製品の複数の脆弱性のそれぞれのリスクの高さを定性的に評価した重大度レベルを決定し、複数の脆弱性のそれぞれの重大度レベルを定量化した値である定量化重大度の総和である重大度の総和を算出してもよい。評価部12は、製品の複数の脆弱性のそれぞれの重大度レベルを製品責任者又は製品担当者等の人間に通知してもよい。脆弱性のリスクの高さが定性的に評価されることによって、人間が脆弱性のリスクの高さを直感的に理解しやすくなる。
【0054】
上述してきた実施形態において、脆弱性のリスクが高いほど定量化重大度又は重大度の総和が大きい数値で表されてきた。逆に、脆弱性のリスクが高いほど定量化重大度又は重大度の総和が小さい数値で表されてもよい。この場合、評価部12は、重大度の総和がアラート基準以下である場合にアラートを出力してよい。
【0055】
(他の実施形態)
以下、管理システム1の他の実施形態が説明される。
【0056】
<化学プラント等の脆弱性対策への適用>
上述してきた管理システム1は、他の実施形態として、アセットオーナーが所有するシステムのサイバーセキュリティリスク管理に活用されてもよい。管理システム1は、例えば、化学プラントのようにすぐに停止できない生産システムにおける脆弱性対策に適用されてよい。
【0057】
管理システム1において、管理装置10の評価部12は、生産システムのサイバーセキュリティリスクを総合的に評価し、生産システムの稼働スケジュールを考慮して、セキュリティパッチを適用する時期を計画してよい。評価部12は、生産システムで用いられている製品に存在する複数の脆弱性のそれぞれのリスクの高さを定量化した数値の総和である重大度の総和の推移を推定し、脆弱性の重大度の総和がアラート基準を超える前にセキュリティパッチを適用できるように、セキュリティパッチを適用する時期を計画してよい。管理装置10は、脆弱性の重大度の総和がアラート基準以上になる前に、又は、脆弱性の重大度の総和がアラート基準以上になる期間が所定の長さ以下で終わるように、複数の脆弱性の対策のセキュリティパッチをまとめて適用する時期を計画してよい。複数の脆弱性の対策のセキュリティパッチをまとめて適用できることによって、単体脆弱性について個別にセキュリティパッチを適用する場合よりも、生産システムを停止させる回数が減少する。生産システムの停止回数が減少することによって、脆弱性対策による生産システムの生産効率の低下が避けられる。
【0058】
<複数の脆弱性同士の関連を考慮した評価>
上述してきた実施形態に係る管理システム1において、管理装置10の評価部12は、複数の脆弱性のそれぞれのリスクの高さを定量化した数値である定量化重大度を算出し、複数の脆弱性のそれぞれの定量化重大度の総和である重大度の総和を算出した。評価部12は、複数の脆弱性同士の関連を考慮して複数の脆弱性のそれぞれの定量化重大度を算出してもよい。
【0059】
例えば、製品に第1の脆弱性と第2の脆弱性とが存在すると仮定する。また、第1の脆弱性が関連する機能と、第2の脆弱性が関連する機能とは、製品のシステムの中において互いにつながっている(パスを有する)と仮定する。この仮定において、評価部12は、第1の脆弱性と第2の脆弱性とが同時に存在する場合に、第1の脆弱性及び第2の脆弱性が両方とも利用された場合のセキュリティリスクを評価してよい。
【0060】
例えば、管理システム1において、データベース20は、第1の脆弱性及び第2の脆弱性のそれぞれに関する情報を取得したときに、PSIRTのメンバーから脆弱性をハンドリングするための情報として第1の脆弱性と第2の脆弱性とを1つのまとまった脆弱性とみなす情報の入力を受け付けてよい。データベース20は、脆弱性管理22に格納する情報に、第1の脆弱性と第2の脆弱性とを1つのまとまった脆弱性とみなす情報を関連づけてよい。
【0061】
データベース20は、製品側脆弱性連絡窓口若しくは製品連絡窓口等のメンバー又は製品担当者等の人間から、第1の脆弱性と第2の脆弱性とを1つのまとまった脆弱性とみなした場合の重大度評価の入力を受け付けてよい。データベース20は、脆弱性管理22に格納する情報に、第1の脆弱性と第2の脆弱性とを1つのまとまった脆弱性とみなした場合の脆弱性の重大度評価を関連づけてよい。
【0062】
データベース20は、第1の脆弱性と第2の脆弱性とをまとめた1つの脆弱性を第3の脆弱性として、第3の脆弱性に関する情報を脆弱性管理22に格納してよい。データベース20は、製品側脆弱性連絡窓口若しくは製品連絡窓口等のメンバー又は製品担当者等の人間から、第3の脆弱性の重大度評価の入力を受け付け、脆弱性管理22に格納する情報に第3の脆弱性の重大度評価を関連づけてよい。
【0063】
図5に示されるように、脆弱性の評価の対象として、複数の機能及び複数の脆弱性を有する対象製品50が仮定される。対象製品50は、機能1~5を有する。対象製品50の機能1に脆弱性1(F1)が存在する。対象製品50の機能2に脆弱性2(F2)が存在する。対象製品50の機能3に脆弱性3(F3)及び脆弱性4(F4)が存在する。対象製品50の機能4及び5に脆弱性が存在しない。つまり、対象製品50に複数の脆弱性が存在する。攻撃者60は、対象製品50の脆弱性1~4を悪用して攻撃する。
【0064】
対象製品50において、脆弱性3及び4は、機能3に存在する。また、対象製品50において、機能1~4のそれぞれは、互いにつながっている。以上のことから、評価部12は、脆弱性1~4のそれぞれが単独で攻撃に利用された場合のセキュリティリスクを評価してもよいし、脆弱性1~4のうち複数の脆弱性が攻撃に利用された場合のセキュリティリスクを評価してよい。
【0065】
ここで、攻撃者60は、(1)のルートで機能1に存在する脆弱性1を攻撃できる。攻撃者60は、(2)のルートで機能3に存在する脆弱性3を攻撃できる。攻撃者60は、(3)のルートで機能2に存在する脆弱性2を攻撃できる。攻撃者60は、(6)のルートで機能1を介して機能2に存在する脆弱性2を攻撃できる。攻撃者60は、(7)のルートで機能1を介して機能3に存在する脆弱性3を攻撃できる。攻撃者60は、(8)のルートで機能3に存在する脆弱性3を介して脆弱性4を攻撃できる。攻撃者60は、(9)のルートで機能3を介して機能2に存在する脆弱性2を攻撃できる。
【0066】
一方で、攻撃者60は、(4)のルートで機能5に攻撃を試みたとしても、機能5に脆弱性が存在しないことによって、攻撃に失敗する。攻撃者60は、(5)のルートで機能4に攻撃を試みたとしても、機能4に脆弱性が存在しないことによって、攻撃に失敗する。攻撃者60は、(10)、(11)及び(12)のルートで機能4を介した攻撃を試みたとしても、機能4に脆弱性が存在しないことによって、攻撃に失敗する。
【0067】
評価部12は、各機能が上述した関係を有し、かつ、上述した脆弱性を有する対象製品50について、脆弱性のセキュリティリスクとして、脆弱性の攻撃容易性を数値として算出してよい。評価部12は、脆弱性に対する攻撃の内容に応じて定められた評価値に基づいて、脆弱性の攻撃容易性を数値として算出してよい。
【0068】
評価値は、表3に例示されるように、脆弱性に対する攻撃元の区分(AV:Attack Vector)に基づいて定められてよい。
【0069】
【0070】
評価値は、表4に例示されるように、攻撃条件の複雑さ(AC:Attack Complexity)に基づいて定められてよい。
【0071】
【0072】
評価値は、表5に例示されるように、必要な特権レベル(PR:Privileges Required)に基づいて定められてよい。
【0073】
【0074】
評価値は、表6に例示されるように、ユーザ関与レベル(UI:User Interaction)に基づいて定められてよい。
【0075】
【0076】
評価部12は、各脆弱性の攻撃容易性の評価を表す数値を、8.22×AV×AC×PR×UIを計算することによって算出してよい。
【0077】
評価値は、上述した例に限られず他の種々の基準に基づいて定められてよい。この場合、攻撃容易性の評価を表す数値を算出する数式は、他の種々の基準を含む形式で表されてよい。
【0078】
評価部12は、機能1~4のつながりを利用して脆弱性1~4を組み合わせた攻撃を受けた場合における、各組み合わせにおける対象製品50の攻撃容易性を数値として算出してよい。評価部12は、例えば、表7に示されるように、最初に悪用される脆弱性と最終的に脆弱性との組み合わせ毎に、対象製品50の攻撃容易性を数値として算出してよい。
【0079】
【0080】
表7において、最初に悪用される脆弱性と最終的に悪用される脆弱性との各組み合わせにおいて経由される脆弱性の組み合わせが示されている。例えば、最初に悪用される脆弱性が脆弱性1(F1)であり、かつ、最終的に悪用される脆弱性が脆弱性2(F2)である場合、対象製品50の攻撃者60は、機能1に存在する脆弱性1(F1)を最初に悪用し、機能1とつながっている機能2に存在する脆弱性2(F2)を最終的に悪用できる。この場合の攻撃容易性は、Y12=F1→F2として記載されている。また、攻撃者60は、機能1に存在する脆弱性1(F1)を最初に悪用し、機能1とつながっている機能3に存在する脆弱性3(F3)を次に悪用し、機能3とつながっている機能2に存在する脆弱性2(F2)を最終的に悪用できる。この場合の攻撃容易性は、Y132=F1→F3→F2として記載されている。同様に、最初に悪用される脆弱性が脆弱性2(F2)であり、かつ、最終的に悪用される脆弱性が脆弱性1(F1)である場合における、他の脆弱性の組み合わせの攻撃容易性は、Y142、Y1342及びY1432として記載されている。
【0081】
また、最初に悪用される脆弱性が脆弱性3(F3)であり、かつ、最終的に悪用される脆弱性が脆弱性2(F2)である場合において、悪用される脆弱性の組み合わせのそれぞれの攻撃容易性は、Y32、Y312、Y342、Y3142及びY3412として記載されている。
【0082】
また、最初に悪用される脆弱性が脆弱性4(F4)であり、かつ、最終的に悪用される脆弱性が脆弱性2(F2)である場合において、悪用される脆弱性の組み合わせのそれぞれの攻撃容易性は、Y42、Y412、Y432、Y4132及びY4312として記載されている。
【0083】
また、最初に悪用される脆弱性が脆弱性2(F2)であり、かつ、最終的に悪用される脆弱性が脆弱性2(F2)である場合は、脆弱性2(F2)がいきなり悪用される場合に対応する。この場合の攻撃容易性は、Y2として記載されている。
【0084】
評価部12は、脆弱性1~4のそれぞれの攻撃容易性を定量化し、定量化した値で各脆弱性の重大度の重みづけを行う。例えば、攻撃容易性が大である場合、評価部12は、重大度のレベルを1段階上げる。攻撃容易性が中である場合、評価部12は、重大度のレベルを据え置く。攻撃容易性が小である場合、評価部12は、重大度のレベルを1段階下げる。
【0085】
評価部12は、脆弱性2の攻撃容易性を表す数値を、脆弱性2が攻撃されるルートのそれぞれについて計算された攻撃容易性の値の総和として算出できる。具体的に、各ルートにおける攻撃容易性の値は以下のように算出される。
・脆弱性2が直接攻撃される場合:脆弱性2の攻撃容易性(Y2)
・脆弱性1→2のルートで攻撃される場合:
Y12=脆弱性1の攻撃容易性(Y1)+脆弱性2の攻撃容易性(Y2)/2
・脆弱性1→3→2のルートで攻撃される場合:
Y132=Y1+脆弱性3の攻撃容易性(Y3)/2+Y2/3
・脆弱性1→4→2のルートで攻撃される場合:
Y142=Y1+脆弱性4の攻撃容易性(Y4)/2+Y2/3
・脆弱性1→3→4→2のルートで攻撃される場合:
Y1342=Y1+Y3/2+Y4/3+Y2/4
・脆弱性1→4→3→2のルートで攻撃される場合:
Y1432=Y1+Y4/2+Y3/3+Y2/4
・脆弱性3→2のルートで攻撃される場合:
Y32=Y3+Y2/2
・脆弱性3→1→2のルートで攻撃される場合:
Y312=Y3+Y1/2+Y2/3
・脆弱性3→4→2のルートで攻撃される場合:
Y342=Y3+Y4/2+Y2/3
・脆弱性3→1→4→2のルートで攻撃される場合:
Y3142=Y3+Y1/2+Y4/3+Y2/4
・脆弱性3→4→1→2のルートで攻撃される場合:
Y3412=Y3+Y4/2+Y1/3+Y2/4
・脆弱性4→2のルートで攻撃される場合:
Y42=Y4+Y2/2
・脆弱性4→1→2のルートで攻撃される場合:
Y412=Y4+Y1/2+Y2/3
・脆弱性4→3→2のルートで攻撃される場合:
Y432=Y4+Y3/2+Y2/3
・脆弱性4→1→3→2のルートで攻撃される場合:
Y4132=Y4+Y1/2+Y3/3+Y2/4
・脆弱性4→3→1→2のルートで攻撃される場合:
Y4312=Y4+Y3/2+Y1/3+Y2/4
【0086】
評価部12は、最終的に悪用される脆弱性が脆弱性2(F2)である場合の攻撃容易性Y2totalとして、Y2+Y12+Y132+Y142+Y1342+Y1432+Y32+Y312+Y342+Y3142+Y3412+Y42+Y412+Y432+Y4132+Y4312を算出できる。評価部12は、同様に最終的に悪用される脆弱性が脆弱性1(F1)、脆弱性3(F3)又は脆弱性4(F4)である場合の攻撃容易性Y1total、Y3total又はY4totalを計算できる。
【0087】
評価部12は、Y1total、Y2total、Y3total及びY4totalの和を対象製品50の攻撃容易性を表す数値として算出してよい。複数の脆弱性を悪用して最終的にある脆弱性を悪用する場合、ルート上の脆弱性の情報を入手し、攻略するなど時間とコストが必要となるので、ルートの段数が多くなるほど攻撃が難しくなる。したがって、攻撃容易性は、ルートの段数が多くなるほど小さくなり、上述した計算式で評価されてよい。以上述べてきたように対象製品50のセキュリティリスクは、複数の脆弱性のそれぞれの関連を考慮した数値として算出されてよい。
【0088】
上述してきたように脆弱性同士の関連を考慮することによって、脆弱性のリスクが適切に評価される。
【0089】
以上、本開示に係る実施形態について、図面を参照して説明してきたが、具体的な構成はこの実施形態に限定されるものではなく、本開示の趣旨を逸脱しない範囲においての種々の変更も含まれる。
【符号の説明】
【0090】
1 管理システム
10 管理装置(12:評価部、14:入力部、16:出力部)
20 データベース(21:脆弱性マスタ、22:脆弱性管理、23:ソフト管理マスタ、24:製品管理マスタ)
50 対象製品
60 攻撃者
80 情報提供元