(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-05-26
(45)【発行日】2025-06-03
(54)【発明の名称】セキュアシステム自動設計装置、セキュアシステム自動設計方法、及びプログラム
(51)【国際特許分類】
G06F 21/57 20130101AFI20250527BHJP
【FI】
G06F21/57 370
(21)【出願番号】P 2023547964
(86)(22)【出願日】2021-09-14
(86)【国際出願番号】 JP2021033729
(87)【国際公開番号】W WO2023042257
(87)【国際公開日】2023-03-23
【審査請求日】2024-02-09
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【氏名又は名称】家入 健
(72)【発明者】
【氏名】黒田 貴之
(72)【発明者】
【氏名】桑原 拓也
【審査官】青木 重徳
(56)【参考文献】
【文献】国際公開第2020/179173(WO,A1)
【文献】GRESSL, Lukas et al.,Security Driven Design Space Exploration for Embedded Systems,2019 Forum for Specification and Design Languages (FDL),米国,IEEE,2019年09月02日
【文献】磯部 義明 ほか,ベイジアンネットワークを利用した動的モデリングによるセキュリティリスク評価システムの開発,情報処理学会研究報告,日本,2015年02月26日,第1-6頁
(58)【調査した分野】(Int.Cl.,DB名)
G06F 21/57
(57)【特許請求の範囲】
【請求項1】
システム要件の入力を受け付けると共に、システム構成を出力する入出力部と、
前記システム要件を、複数の具体化の手続きによって前記システム構成に変換する構成情報具体化部と、
前記システム構成のセキュリティを評価するセキュリティ評価部と、を備え、
前記構成情報具体化部は、前記具体化の各手続きにおいて、複数の具体化の方法の選択肢へ分岐し、変換途中の構成情報である複数の構成ドラフトを生成し、
前記セキュリティ評価部は、前記各手続きによって生成された前記構成ドラフトについてもセキュリティを評価し、
前記構成情報具体化部は、前記セキュリティ評価部による前記構成ドラフトの評価結果に基づいて、分岐すべき前記選択肢を判断し、分岐すべきと判断されなかった前記選択肢の先にある
変換途中の構成ドラフトを棄却する、
セキュアシステム自動設計装置。
【請求項2】
システムの構成要素に関する情報を記憶する記憶部を更に備え、
前記記憶部に記憶された構成要素に関する情報には、当該構成要素の脆弱性に関する情報が付与されており、
前記セキュリティ評価部は、各々の前記構成ドラフトについて、当該構成ドラフトに含まれる各構成要素の脆弱性に基づいて、当該構成ドラフトのセキュリティを評価する、
請求項1に記載のセキュアシステム自動設計装置。
【請求項3】
前記入出力部は、設計時に考慮すべきリスクに関する情報の入力を更に受け付け、
前記セキュリティ評価部は、前記構成ドラフトに含まれる前記各構成要素の脆弱性と、前記入力されたリスクに対応する脆弱性と、に基づいて、当該構成ドラフトのセキュリティを評価する、
請求項2に記載のセキュアシステム自動設計装置。
【請求項4】
攻撃の起点から攻撃目標に至るパスである攻撃パスの情報を具体化する脅威情報具体化部を更に備え、
前記脅威情報具体化部は、各々の前記構成ドラフトについて、当該構成ドラフトの内容に基づいて、防御されるべき1つ又は複数の前記攻撃パスの情報を具体化し、
前記セキュリティ評価部は、各々の前記構成ドラフトについて、前記攻撃パスの具体化された内容に基づいて、当該構成ドラフトのセキュリティを評価する、
請求項1に記載のセキュアシステム自動設計装置。
【請求項5】
前記入出力部は、設計時に考慮すべきセキュリティのレベルに関する情報の入力を更に受け付け、
前記セキュリティ評価部は、
前記構成ドラフトについて、攻撃が発生した際のリスクのレベル及び発生頻度を更に評価し、
前記入力されたセキュリティのレベルと、攻撃が発生した際のリスクのレベル及び発生頻度と、に基づいて、考慮すべき攻撃を選択し、
前記選択された攻撃に基づいて、前記構成ドラフトのセキュリティを評価する、
請求項4に記載のセキュアシステム自動設計装置。
【請求項6】
前記入出力部は、前記システム要件に含まれる構成要素及び当該構成要素に付与される脅威に関して編集可能なユーザインタフェースを含む、
請求項4又は5に記載のセキュアシステム自動設計装置。
【請求項7】
前記入出力部は、前記構成情報具体化部による分岐すべき前記選択肢の判断が少なくとも行えない場合に、分岐すべき特定の選択肢の選択及び前記複数の具体化の手続きを、前記複数の具体化の手続きのうち、ユーザが所望の具体化の手続きに関して編集可能なユーザインタフェースを含む、
請求項1から5のいずれか1項に記載のセキュアシステム自動設計装置。
【請求項8】
セキュアシステム自動設計装置により実行されるセキュアシステム自動設計方法であって、
システム要件の入力を受け付ける第1ステップと、
前記システム要件を、複数の具体化の手続きによってシステム構成に変換する第2ステップと、
前記システム構成のセキュリティを評価する第3ステップと、
前記システム構成を出力する第4ステップと、を含み、
前記第2ステップでは、
前記具体化の各手続きにおいて、複数の具体化の方法の選択肢へ分岐し、変換途中の構成情報である複数の構成ドラフトを生成し、
前記各手続きによって生成された前記構成ドラフトについてもセキュリティを評価し、
前記構成ドラフトの評価結果に基づいて、分岐すべき前記選択肢を判断し、分岐すべきと判断されなかった前記選択肢の先にある
変換途中の構成ドラフトを棄却する、
セキュアシステム自動設計方法。
【請求項9】
コンピュータに、
システム要件の入力を受け付ける第1手順と、
前記システム要件を、複数の具体化の手続きによってシステム構成に変換する第2手順と、
前記システム構成のセキュリティを評価する第3手順と、
前記システム構成を出力する第4手順と、を実行させるためのプログラムであり、
前記第2手順では、
前記具体化の各手続きにおいて、複数の具体化の方法の選択肢へ分岐し、変換途中の構成情報である複数の構成ドラフトを生成し、
前記各手続きによって生成された前記構成ドラフトについてもセキュリティを評価し、
前記構成ドラフトの評価結果に基づいて、分岐すべき前記選択肢を判断し、分岐すべきと判断されなかった前記選択肢の先にある
変換途中の構成ドラフトを棄却する、
プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、セキュアシステム自動設計装置、セキュアシステム自動設計方法、及びコンピュータ可読媒体に関する。
【背景技術】
【0002】
非特許文献1には、セキュアなシステム構成を自動設計する技術が開示されている。当該技術は、まず、複数のシステム構成案を生成し、それぞれのシステム構成案のセキュリティを評価し、セキュアであると評価されたシステム構成案を抽出して出力する。生成されるシステム構成案は、具体的なシステム構成情報であり、セキュリティの評価は、具体的なシステム構成情報に基づいて実施される。
【0003】
また、特許文献1、非特許文献2、及び非特許文献3には、システム構成を効率的に自動設計する技術が開示されている。当該技術は、まず、抽象的なシステム構成情報を入力として受け付け、受け付けた抽象的なシステム構成の未確定な部分に具体化規則を適用して具体化することによって、未確定な部分が含まれていない具体的なシステム構成情報を導出する。具体化は複数のステップに分けて段階的に実施される。各ステップで生成される具体化途中のシステム構成を構成ドラフトと呼ぶ。各ステップでは、複数の具体化の方法の選択肢に分岐し、複数の構成ドラフトが生成される。当該技術は、生成された構成ドラフトを評価し、有望な構成ドラフトを優先して次のステップに進めることで、生成される構成ドラフトやシステム構成案を限定し、自動設計の効率を高めている。
【先行技術文献】
【特許文献】
【0004】
【非特許文献】
【0005】
【文献】Lukas Gressl, Christian Steger, and Ulrich Neffe, "Design Space Exploration for Secure IoT Devices and Cyber-Physical Systems", ACM Transactions on Embedded Computing Systems (TECS) 20.4 (2021): 1-24.
【文献】黒田 貴之, 桑原 拓也, 丸山 貴志, 八鍬 豊, 田辺 和輝, 福田 達也, 里田 浩三, 大崎 隆夫, "ICTシステムの設計に関する知識の機械学習による獲得", 電子情報通信学会論文誌 B Vol.J104-B No.3 pp.140-151, 2021.
【文献】Takuya KUWAHARA, Takayuki KURODA, Takao OSAKI, Kozo SATOD, “An intent-based system configuration design for IT/NW services with functional and quantitative constraints”, IEICE Trans Commun. Vol.E104-B, No.7, pp.791-804, 2021, [令和3 年8 月10 日検索],インターネット <URL : https://doi.org/10.1587/transcom.2020CQP0009>
【発明の概要】
【発明が解決しようとする課題】
【0006】
非特許文献1に例示されるシステム構成の自動設計技術では、条件を満たすシステム構成案を探索するために、システム構成案の生成及び評価を多数繰り返す必要があるため、解の導出に長い時間を要する。
【0007】
特許文献1、非特許文献2、及び非特許文献3に例示されるシステム構成の自動設計技術では、探索範囲を絞込むことで解の導出にかかる時間を短縮している。しかし、その処理の過程において、生成されるシステム構成案のセキュリティについては考慮されておらず、セキュアでないシステム構成が導出されてしまう。
【0008】
非特許文献1と同様の方法でセキュリティの評価を実施することで、セキュアなシステム構成を導出することは困難である。特許文献1、非特許文献2、及び非特許文献3に例示される技術において、解の導出にかかる時間を短縮する工夫は、抽象的なシステム構成情報である構成ドラフトが生成された段階で、この構成ドラフトを評価して、探索範囲を限定することにある。しかし、非特許文献1におけるセキュリティの評価手段は具体的なシステム構成情報を対象とするため、構成ドラフトには適用できない。具体的なシステム構成情報が生成された段階であれば、上記のセキュリティの評価手段を適用できるが、具体的なシステム構成情報の生成とセキュリティの評価とをセキュアなシステム構成情報が生成されるまで繰り返すと、解の導出に長い時間を要してしまう。
【0009】
そこで、本開示の目的は、上述した課題を解決し、セキュアシステムの自動設計を効率的に行うことができるセキュアシステム自動設計装置、セキュアシステム自動設計方法、及びコンピュータ可読媒体を提供することにある。
【課題を解決するための手段】
【0010】
一態様によるセキュアシステム自動設計装置は、
システム要件の入力を受け付けると共に、システム構成を出力する入出力部と、
前記システム要件を、複数の具体化の手続きによって前記システム構成に変換する構成情報具体化部と、
前記システム構成のセキュリティを評価するセキュリティ評価部と、を備え、
前記構成情報具体化部は、前記具体化の各手続きにおいて、複数の具体化の方法の選択肢へ分岐し、変換途中の構成情報である複数の構成ドラフトを生成し、
前記セキュリティ評価部は、前記各手続きによって生成された前記構成ドラフトについてもセキュリティを評価し、
前記構成情報具体化部は、前記セキュリティ評価部による前記構成ドラフトの評価結果に基づいて、分岐すべき前記選択肢を判断する。
【0011】
一態様によるセキュアシステム自動設計方法は、
セキュアシステム自動設計装置によるセキュアシステム自動設計方法であって、
システム要件の入力を受け付ける第1ステップと、
前記システム要件を、複数の具体化の手続きによってシステム構成に変換する第2ステップと、
前記システム構成のセキュリティを評価する第3ステップと、
前記システム構成を出力する第4ステップと、を含み、
前記第2ステップでは、
前記具体化の各手続きにおいて、複数の具体化の方法の選択肢へ分岐し、変換途中の構成情報である複数の構成ドラフトを生成し、
前記各手続きによって生成された前記構成ドラフトについてもセキュリティを評価し、
前記構成ドラフトの評価結果に基づいて、分岐すべき前記選択肢を判断する。
【0012】
一態様によるコンピュータ可読媒体は、
コンピュータに実行させるためのプログラムが格納された非一時的なコンピュータ可読媒体であって、
前記プログラムは、
システム要件の入力を受け付ける第1手順と、
前記システム要件を、複数の具体化の手続きによってシステム構成に変換する第2手順と、
前記システム構成のセキュリティを評価する第3手順と、
前記システム構成を出力する第4手順と、を含み、
前記第2手順では、
前記具体化の各手続きにおいて、複数の具体化の方法の選択肢へ分岐し、変換途中の構成情報である複数の構成ドラフトを生成し、
前記各手続きによって生成された前記構成ドラフトについてもセキュリティを評価し、
前記構成ドラフトの評価結果に基づいて、分岐すべき前記選択肢を判断する。
【発明の効果】
【0013】
上述した態様によれば、セキュアシステムの自動設計を効率的に行うことができるセキュアシステム自動設計装置、セキュアシステム自動設計方法、及びコンピュータ可読媒体を提供することができるという効果が得られる。
【図面の簡単な説明】
【0014】
【
図1】実施形態1に係るセキュアシステム自動設計装置の機能構成例を示す概略ブロック図である。
【
図2A】構成情報の図による表現例を示す図である。
【
図2B】構成情報のテキストによる表現例を示す図である。
【
図6】システム要件が段階的に具体化される様子の例を示す図である。
【
図7】構成ドラフトが分岐して生成される様子の例を示す図である。
【
図9】実施形態1に係るセキュアシステム自動設計装置の動作例を示すフローチャートである。
【
図10】実施形態2に係るセキュアシステム自動設計装置の機能構成例を示す概略ブロック図である。
【
図11A】実施形態2の構成情報の図による表現例を示す図である。
【
図11B】実施形態2の構成情報のテキストによる表現例を示す図である。
【
図12】実施形態2の構成要素型の例を示す図である。
【
図14】脅威が具体化される様子の例を示す図である。
【
図16】脅威が具体化される様子の例を示す図である。
【
図17】セキュリティレベルの定義例を示す図である。
【
図18】セキュリティの評価に基づき構成ドラフトが選択される様子の例を示す図である。
【
図21】実施形態2に係るセキュアシステム自動設計装置の動作例を示すフローチャートである。
【
図22】実施形態3に係るセキュアシステム自動設計装置の機能構成例を示す概略ブロック図である。
【
図23】実施形態4に係るセキュアシステム自動設計装置のハードウェア構成例を示す概略ブロック図である。
【発明を実施するための形態】
【0015】
以下、図面を参照して本開示の実施形態について説明する。なお、以下の記載及び図面は、説明の明確化のため、適宜、省略及び簡略化がなされている。また、以下の各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。
【0016】
<実施形態1>
まず、本実施形態1の構成について説明する。
図1は、本実施形態1に係るセキュアシステム自動設計装置100の機能構成例を示す概略ブロック図である。
図1に示されるように、セキュアシステム自動設計装置100は、入出力部101と、セキュリティ評価部102と、構成情報具体化部103と、記憶部104と、を備える。構成情報具体化部103は、入出力部101、セキュリティ評価部102、及び記憶部104と、それぞれ通信可能に接続されている。
【0017】
入出力部101は、利用者の端末(不図示)から、システム要件の情報や利用者が許容するリスクの入力を受け付けて、これを構成情報具体化部103へ渡す。また、入出力部101は、構成情報具体化部103から、具体的なシステム構成情報を受け付けて、これを利用者の端末に出力する。
【0018】
構成情報具体化部103は、システム要件を複数のステップ(「段階」又は「手続き」)に分けて段階的に具体化し、その結果としてシステム構成情報を生成する。上記の各ステップでは、複数の構成ドラフトを生成する。構成ドラフトを生成するために、構成情報具体化部103は、記憶部104から構成要素及び具体化規則に関する情報を取得する。また、構成情報具体化部103は、各構成ドラフトをセキュリティ評価部102に渡して、各構成ドラフトのセキュリティの評価結果を取得する。
【0019】
セキュリティ評価部102は、構成情報具体化部103から構成ドラフトを受け付けると、その構成ドラフトのセキュリティを評価して評価結果を返す。
【0020】
記憶部104は、構成要素及び具体化規則に関する情報を記憶し、構成情報具体化部103からの要求に応じて、構成要素及び具体化規則に関する情報を返す。
【0021】
続いて、本実施形態1で扱うデータについて説明する。
構成情報は、システムの構成を表す情報である。システム要件、システム構成、及び構成ドラフトは、いずれも構成情報の一種である。システム要件は、利用者が期待する要件として入力する構成情報であり、構成ドラフトは、セキュアシステム自動設計装置100が設計中に生成する構成情報であり、システム構成は、セキュアシステム自動設計装置100の設計結果として出力される構成情報である。システム要件及び構成ドラフトには、不確定な要素、すなわち抽象的な要素や不足した要素が含まれてもよいが、システム構成には不確定な要素は含まれない。
【0022】
構成情報は、ノード及びエッジからなる。ノードはシステムを構成する構成部品を表しており、エッジは構成部品間の関係性を表している。構成部品及び関係性を総称して構成要素と呼ぶ。構成要素には、ID(Identification)と当該構成要素の種類を表す型名とが付与される。加えて、構成要素には、属性値が付与されていてもよい。また、構成情報には、ノード及びエッジの他に、ノード及びエッジが満たすべき制約条件が付与されていてもよい。
【0023】
図2A及び
図2Bに、構成情報の例を示す。構成情報の表現方法としては、図による表現方法とテキストによる表現方法とがある。本明細書では、厳密性が問題にならない範囲で、主に図による表現方法を利用する。
【0024】
図2Aは、構成情報の図による表現例を示している。丸はノードを示しており、丸の間を繋ぐ矢印はエッジを示している。構成部品の型名は丸の内部に示す。関係性の型名は矢印に添える。関係性の型名は両端の型に関する情報を省略して記載する。構成部品のIDを丸に添えて示すが、これは適宜省略する。点線は抽象的な構成要素、実線は具体的な構成要素を示している。
【0025】
図2Bは、
図2Aと同様の構成情報のテキストによる表現例を示している。本明細書におけるテキストによる定義例では、基本的にYAML形式を用いる。構成情報は、ノードのリストとエッジのリストとからなり、各ノードには、id及び型が定義される。各エッジには、接続元のノードのid、関係性の型、及び接続先のノードのidが定義される。頭にドルマーク“$”のついたidは、別の箇所で定義されたidを参照していることを示している。関係性の型名の後ろに付与された括弧“<>”内のカンマで区切られた2つの要素は、それぞれノードの型名であって、当該関係性の接続元と接続先に指定されるノードの型を指定している。ノードの型を指定しない部分にはアスタリスク“*”を指定している。
【0026】
図3に、6種類の構成部品型の定義例を示す。各構成部品型には、継承元(parent, source of inherit)、抽象フラグ、提供機能、利用機能、及び期待する周辺構成を指定できる。継承元には、当該構成部品型が継承(inherit)する他の構成部品の型名を指定する。AP及びVMは、基本となるクラスであるため、何も継承していない。これに対して、AP
1及びAP
2はAPを、VM
1及びVM
2はVMを、それぞれ継承している。他の型を継承している型は、継承元から、提供機能、利用機能、及び期待する周辺構成に関する情報を引き継ぐ。ただし、他の型を継承している型において、継承元から引き継いだ情報は省略される。抽象フラグは、当該構成部品型が抽象的な構成要素であるか否かを示すフラグである。AP及びVMは抽象的であるが、他の4つの構成部品は具体的である。提供機能には、当該構成部品が他の構成部品から接続されると想定している関係性を定義する。また、利用機能には、当該構成部品から他の構成部品へ接続することを想定している関係性を定義する。期待する周辺構成には、当該構成部品が動作するために満たされるべき当該構成部品の周辺の構成が表現されている。例えば、APが動作するためには、VMが必要であって、なおかつ当該APが当該VMとHostedOnの関係で接続されている必要がある。そのため、APが期待する構成として、係る状況を表す周辺構成が定義されている。なお、期待する周辺構成は複数指定してもよく、複数指定した場合には、いずれかの周辺構成が満たされればよいと解釈される。
【0027】
図4に、3種類の関係性型の定義例を示す。各関係性型には、継承元、抽象フラグ、及び期待する周辺構成を指定できる。ConnTo<AP, AP>は、基本となるクラスであるため、何も継承していない。これに対して、Http及びHttpsは、ConnTo<AP, AP>を継承している。他の型を継承している型は、継承元から、期待する周辺構成に関する情報を引き継ぐ。ただし、他の型を継承している型において、継承元から引き継いだ情報は省略される。ConnTo<AP, AP>は、2つのアプリケーションが通信可能に接続されている関係を表す抽象的な関係性型である。ConnTo<AP, AP>の具体的な型には、Http及びHttpsがある。ConnTo<AP, AP>が成立するためには、低レイヤの通信が確立している必要があるため、低レイヤの通信に関する構成を、期待する周辺構成として定義している。その具体的な構成は、両端のAPが同じVMにホストされているのか、異なるVMにホストされているかによって異なるため、異なる2種類の期待する周辺構成が定義されている。1つ目は、両端のAPがそれぞれ異なるVMにホストされている状況を示しており、その場合には2つのVMが通信可能に接続された構成を指定している。2つ目は、両端のAPが同じ1つのVMにホストされている状況を示しているが、その場合にはそれ以上の構成を必要としないため、特段の記載はない。
【0028】
図5に、3種類の具体化規則の定義例を示す。具体化規則とは、構成情報を具体化する方法を定義した情報である。各具体化規則には、具体化対象、想定する周辺構成、及び具体化後の構成を指定する。具体化対象には、具体化する対象となる構成要素の型名を指定する。各具体化規則は、1つの構成要素のみを具体化対象としており、1ステップの具体化では1つの構成要素のみが具体化される。想定する周辺構成には、この具体化規則を適用するにあたって事前に満たされるべき周辺構成を指定する。すなわち、具体化対象の構成要素の周辺に、想定する周辺構成に示された構成が認められた場合に限り、当該具体化規則が適用される。具体化後の構成は、当該具体化規則が適用された後に残る構成を指定する。具体化規則が適用されると、具体化対象の構成要素が具体化後の構成に示された構成に置き換えられることになる。具体化規則1は、APにVMをホストさせる規則である。具体化後の構成の中に記載されている“$_self”は、具体化対象の構成要素を示しており、これにより具体化後にも具体化対象の構成要素が保存される。加えて、新たにVM型のノードを用意し、$_selfと上記のVM型のノードとをHostedOn型の関係性で接続している。具体化規則2は、抽象的なVM型の構成要素を、具体的なVM
1型の構成要素に置き換えている。具体化規則3は、ConnTo<AP, AP>の関係性に対して、その両端のAPがそれぞれ異なるVMにホストされている状況において、それぞれのVM間を接続するConnTo<VM, VM>型の関係性を補完している。なお、具体化規則3に記載されている“$_src”及び“$_dest”は、それぞれ具体化対象である関係性の接続元及び接続先のノードのIDを示している。
【0029】
図6に、システム要件が段階的に具体化される様子の例を示す。例えば、(a)におけるap1のノードに、
図5に記載の具体化規則1を適用することで(b)が生成される。また、(d)のvm1に
図5に記載の具体化規則2を適用することで(e)が生成される。また、(f)のHttpに
図5に記載の具体化規則3を適用することで(g)が生成される。
【0030】
各構成要素は、その型の抽象フラグがtrueであることと、期待する周辺構成が満たされることの2つが満たされる場合に、具体的であると判断される。構成ドラフトは、内包する全ての構成要素が具体的である場合に、具体的であると判断される。
【0031】
図7に、構成ドラフトが分岐して生成される様子の例を示す。同じ構成要素型に対して、複数の異なる具体化規則が定義され得る、1つの構成ドラフトには複数の抽象的な構成要素が含まれる、という2つの事情により、1つの構成ドラフトを1ステップ具体化することで複数の構成ドラフトが生成され得る。こうして得られるツリー上の構成ドラフトの集合を構成ドラフトツリーと呼ぶ。1つのシステム要件からは、膨大な数の構成ドラフトが生成され得る。しかし、生成され得る全ての構成ドラフトを実際に生成することは避け、条件を満たす有望な構成ドラフトに絞って具体化を進めることにより、システム構成を効率的に導出することが期待される。
【0032】
図8A及び
図8Bに、本実施形態1における脆弱性に関する情報の例を示す。脆弱性に関する情報には、
図8Aに示す構成要素の脆弱性と、
図8Bに示す各脆弱性の定義と、がある。
図8AではVM
1とVM
2の2つの構成要素に関する脆弱性が定義されており、前者には脆弱性001及び脆弱性002が、後者には脆弱性002及び脆弱性003が、それぞれ指定されている。また、
図8Bでは、脆弱性の定義として、各脆弱性のリスクの大きさが指定されており、脆弱性001は大、脆弱性002は中、脆弱性003は小がそれぞれ定義されている。なお、
図8A及び
図8Bに示される情報は、記憶部104に記憶されている。
【0033】
次に、本実施形態1の動作について説明する。
図9は、本実施形態1に係るセキュアシステム自動設計装置100の動作例を示すフローチャートである。初めに動作の全体的な概要を述べる。
【0034】
まず、構成情報具体化部103は、利用者の端末から、入出力部101を介して、システム要件及び許容するリスクの入力を受け付ける(S101)。続いて、構成情報具体化部103は、許容するリスクを踏まえて、システム要件を段階的に具体化し(S102~S109)、完全に具体化されたシステム構成を、入出力部101を介して、利用者の端末に出力する(S110)。構成情報具体化部103は、段階的な具体化として、まず、1段階の具体化(S102~S106)を実施し、得られた複数の構成ドラフトの中に具体的な構成ドラフトが含まれているかを確認する(S107)。構成ドラフトは、内包する全ての構成要素が具体的である場合に、具体的であると判断される。各構成要素は、その型の抽象フラグがtrueであることと、期待する周辺構成が満たされることの2つが満たされる場合に、具体的であると判断される。構成ドラフトが具体的かの判断に必要な構成要素型の情報は、記憶部104に記憶されており、構成情報具体化部103は、記憶部104からこれを読み出す。具体的な構成ドラフトが含まれていれば(S107のYes)、構成情報具体化部103は、その具体的な構成ドラフトをシステム構成として出力する(S110)。具体的な構成ドラフトが含まれていなければ(S107のNo)、構成情報具体化部103は、構成ドラフトツリーの中に他にまだ抽象的な構成ドラフトが残っているかを確認する(S108)。抽象的な構成ドラフトが残っていれば(S108のYes)、構成情報具体化部103は、次に具体化する構成ドラフトを適宜選択して(S109)、1段階の具体化を再度実施する。構成ドラフトが残っていなければ(S108のNo)、構成情報具体化部103は、それ以上設計を検討できないため、失敗して終了する(S111)。
【0035】
1段階の具体化においては、まず、構成情報具体化部103は、S101で入力されたシステム要件又はS109で次に具体化すると選択された構成ドラフトに対して、適用可能な具体化規則を適用することで複数の構成ドラフトを生成する(S102)。構成ドラフトの生成に必要な構成要素型の情報(例えば、
図3及び
図4の情報)及び具体化規則の情報(例えば、
図5の情報)は、記憶部104に記憶されており、構成情報具体化部103は、記憶部104からこれを読み出す。その後、構成情報具体化部103は、実際に1つ以上の構成ドラフトが生成されたかを確認する(S103)。構成ドラフトが生成されなかった場合には(S103のNo)、1段階の具体化は失敗であるため、構成情報具体化部103は、構成ドラフトツリー上の他の構成ドラフトの具体化へ進む(S108)。1つ以上の構成ドラフトが生成された場合には(S103のYes)、構成情報具体化部103は、各構成ドラフトに脆弱性を付与する(S104)。例えば、
図8Aに例示した脆弱性が定義されている場合であれば、構成情報具体化部103は、構成ドラフト内に新規に生成されたVM
1型の構成部品があれば、これに脆弱性001及び脆弱性002の属性を付与し、同様にVM
2型の構成部品があれば、これに脆弱性002及び脆弱性003の属性を付与する。構成ドラフトへの脆弱性の付与に必要な情報(例えば、
図8Aの情報)は、記憶部104に記憶されており、構成情報具体化部103は、記憶部104からこれを読み出す。
【0036】
続いて、構成情報具体化部103は、付与された脆弱性を踏まえて、各構成ドラフトを評価し、不適格と判断された構成ドラフトは棄却する(S105)。構成ドラフトを評価するため、構成情報具体化部103は、構成ドラフトと許容するリスクの情報とをセキュリティ評価部102に渡して評価結果を受け取る。セキュリティ評価部102は、構成ドラフトに含まれる各構成要素の脆弱性の中に、許容するリスクを超える大きさのリスクを含む脆弱性がなければ、上記の構成ドラフトはセキュアであると評価し、それ以外の場合にはセキュアでないと評価する。構成ドラフトの評価に必要な情報(例えば、
図8Bの情報)は、記憶部104に記憶されており、セキュリティ評価部102は、記憶部104からこれを読み出す。
【0037】
例えば、
図7に示した構成ドラフトツリーにおいて、VM
1が含まれる構成ドラフトについては、脆弱性001及び脆弱性002が懸案となる。利用者から与えられる許容するリスクが中であれば、いずれの脆弱性も許容されるため、これらはセキュアであると評価される。一方、許容するリスクが小であれば、脆弱性002は許容されないため、これらの構成ドラフトはセキュアでないと評価される。セキュアでないと評価された構成ドラフトは、棄却されるため、それ以降の具体化はキャンセルされる。
図7に示す構成ドラフトツリーにおいて、(a)及び(b)の段階でセキュアでないと評価されれば、(a)及び(b)から先の具体化は省略される。
【0038】
最終的に棄却される構成ドラフトにつながる構成ドラフトは、具体化のステップのより早い段階で棄却されるほど、自動設計の処理の効率化に寄与する。例えば、VM型を具体化した後の構成部品型にはVM1及びVM2しかない場合であれば、VM型の構成部品には必ず脆弱性002が付与されることになるため、VM型の構成要素の脆弱性として脆弱性002を更に付与してもよい。この場合、構成ドラフトにVMが登場した時点で早期にセキュリティを評価することで、設計の効率を改善することが期待できる。
【0039】
なお、構成ドラフトの評価は、更に、図示しない他の評価手段を用いて、システム要件や構成要素型や具体化規則に別途定義された制約条件に基づいて実施されてもよい。また、セキュリティに関する評価と他の観点に基づく評価(例えば、性能やコストなど)とを総合して、構成ドラフトの評価を判断してもよい。
【0040】
本実施形態1によれば、構成情報具体化部103は、セキュリティ評価部102により脆弱性の存在が明確となった構成ドラフトを、直ちに棄却し、それ以降の具体化を省略することが可能となり、セキュアシステムを効率的に導出することができる。
【0041】
<実施形態2>
次に、本実施形態2の構成について説明する。
図10は、本実施形態2に係るセキュアシステム自動設計装置200の機能構成例を示す概略ブロック図である。
図10に示されるように、セキュアシステム自動設計装置200は、上記の実施形態1に係るセキュアシステム自動設計装置100と比較して、脅威情報具体化部201が追加されている点が異なる。脅威情報具体化部201は、構成情報具体化部103及び記憶部104と、それぞれ通信可能に接続されている。
【0042】
本実施形態2に係る入出力部101が受け付ける情報は、システム要件の情報及び利用者が要求するセキュリティレベルの情報である。本実施形態2に係るシステム要件及び構成要素型は、防御すべき脅威に関する情報を更に含む。また、本実施形態2に係る記憶部104は、脅威に関する具体化規則である脅威具体化規則の情報とセキュリティレベルの定義に関する情報とを更に記憶する。
【0043】
本実施形態2に係る構成情報具体化部103は、具体化の各ステップで構成ドラフトを生成すると、上記の構成ドラフトを脅威情報具体化部201に渡して、上記の構成ドラフトに含まれる脅威情報を具体化し、続いて、具体化された脅威情報を含む構成ドラフト及び利用者が要求するセキュリティレベルの情報をセキュリティ評価部102に渡してセキュリティを評価する。
【0044】
本実施形態2に係るセキュリティ評価部102は、構成情報具体化部103から受け付けた構成ドラフトに含まれる脅威情報とセキュリティレベルの情報とに基づいて、上記の構成ドラフトのセキュリティを評価する。
【0045】
本実施形態2に係る脅威情報具体化部201は、構成情報具体化部103から構成ドラフトを受け付けると、受け付けた構成ドラフトに含まれる脅威情報を当該構成ドラフトの内容に基づいて具体化して、具体化された脅威情報を含む構成ドラフトを構成情報具体化部103に返す。
【0046】
続いて、本実施形態2で扱うデータについて説明する。
図11A及び
図11Bに、本実施形態2の構成情報の例を示す。本実施形態2の構成情報には、防御すべき脅威に関する情報が付与されている点が、上記の実施形態1の構成情報とは異なる。
図11A及び
図11Bは、AP
1型とAP
2型の2つのアプリケーションがあり、前者と後者はConnTo<AP, AP>型の関係性で接続されており、またそれぞれ外部ドメインと内部ドメインの2つのネットワークドメインに所属している構成を例示している。加えて、上記の2つのアプリケーションを接続するConnTo<AP, AP>型のエッジには、盗聴型の脅威が指定されており、そのリスクの大きさは中程度と指定されている。
【0047】
図11Aは、構成情報の図による表現例を示している。上記のConnTo<AP, AP>型のエッジに脅威が付与されていることを、ウイルスのアイコンによって示している。なお、ネットワークドメインはノードであるが、本実施形態2では、丸ではなく、角丸長方形で示している。そして、ネットワークドメインの内部にノードを配置することで、内部のノードが当該ネットワークドメインとJoinIn<*, Domain>型の関係性で接続されることを表現するものとする。また、“外部ドメイン::d_ex”の記載は、外部ドメイン型のノードであって、IDがd_exであることを示している。
【0048】
図11Bは、
図11Aと同様の構成情報のテキストによる表現例を示している。
図11Bでは、$ap1と$ap2を接続するConnTo<AP, AP>型のエッジに、脅威が定義されており、型は盗聴であって、属性としてリスクの大きさが中であることが表現されている。
【0049】
図12に、本実施形態2の構成要素型の例を示す。本実施形態2の構成要素型には、防御すべき脅威に関する情報が付与されている点が、上記の実施形態1の構成要素型とは異なる。
図12では、新たにAP
3型の構成部品が定義されており、期待する周辺構成に含まれる構成要素に脅威が指定されている。構成要素型の定義には、当該構成要素型の開発者が防御すべきと考える脅威が付与される。これにより、利用者は、当該構成要素型に関する脅威を認識していなくても、当該構成要素を構成情報内に取り込む際に、必要な脅威の情報も併せて取り込むことができる。
【0050】
図13に、脅威具体化規則の例を示す。本開示における脅威は、抽象的な構成情報に対して付与されることがあるため、抽象的に表現されることがある。脅威具体化規則は、抽象的な脅威を具体化する具体化規則である。脅威具体化規則には、具体化対象と想定する構成に加え、具体的脅威又は事前脅威のいずれか1つを指定する。
図13に記載の脅威具体化規則には、具体的脅威が指定されている。具体化対象には、具体化する対象の脅威の型と、当該脅威が付与されている構成要素の型と、を指定する。想定する周辺構成には、この脅威具体化規則を適用するにあたって事前に満たされるべき周辺構成を指定する。具体的脅威には、具体化対象の脅威の具体的な実現方法に相当する他の脅威を指定する。事前脅威については
図15を用いて後述する。
【0051】
図13に記載の脅威具体化規則1-1には、Http<AP, AP>の盗聴が、当該Http<AP, AP>の接続元にあたるアプリケーションがホストされているVMにおいて盗聴コマンドを実行することによって実現できることが示されている。すなわち、想定する周辺構成には、あるVM型の構成部品vmが定義されていて、上記のHttp<AP, AP>の接続元である$_srcと上記のvmである$vmがHostedOn<*, VM>型の関係性で接続されている状況が示されている。また、具体的脅威には、上記の$vmにおける盗聴コマンドを実行することが示されている。
【0052】
また、
図13に記載の脅威具体化規則1-2には、同じくHttp<AP, AP>の盗聴が、当該Http<AP, AP>の接続先にあたるアプリケーションがホストされているVMにおいて盗聴コマンドを実行することによっても実現できることが示されている。加えて、脅威具体化規則1-3には、同じくHttp<AP, AP>の盗聴が、当該Http<AP, AP>の接続元と接続先にあたる2つのアプリケーションが、それぞれホストされている異なる2つのVM間を接続する通信を盗聴することによっても実現できることが示されている。このように、同じ脅威に対して異なる複数の具体的な実現方法を与えることができる。
【0053】
図14に、脅威具体化規則1-1、脅威具体化規則1-2、脅威具体化規則1-3によって、脅威が具体化される様子の例を示す。構成ドラフト(a)にて、Http<AP, AP>に付与されている脅威は、構成ドラフト(b)では3つの脅威具体化規則によって具体的脅威として指定された3つの脅威に置き換えられている。構成要素を具体化する具体化規則の場合には、同じ具体化対象を具体化する具体化規則が複数定義されていた場合にはそれぞれ異なる構成ドラフトへ分岐していたが、脅威具体化規則の場合には、1つの構成ドラフトに派生した複数の具体的な脅威を全て付与する。これにより、各構成ドラフトについて、あらゆる脅威を網羅的に検証し、抜け穴のないセキュアな構成ドラフトを選択することができる。
【0054】
図15に、脅威具体化規則の他の例を示す。
図15に記載の脅威具体化規則には、事前脅威が指定されている。事前脅威には、具体化対象の脅威を実現するために事前に実施するべき作業を定義する。
【0055】
図15に記載の脅威具体化規則2には、VM型の構成部品において盗聴コマンドの実行を実現するには、事前に、上記のVMにおいてRoot権限の取得を実施する必要があることが示されている。なお、$_entityの記載は、当該脅威具体化規則の具体化対象における構成要素を参照していることを示している。
【0056】
また、
図15に記載の脅威具体化規則3-1及び脅威具体化規則3-2には、VM型の構成部品においてRoot権限の取得を実現するには、事前に当該VMが所属するネットワークドメインに応じた攻撃者の存在が必要であることを示している。脅威具体化規則3-1は、上記のVMが内部ドメインに所属する状況を想定した規則であり、事前脅威として内部の攻撃者の存在を指定している。また、脅威具体化規則3-2は、上記のVMが外部ドメインに所属する状況を想定した規則であり、事前脅威として外部の攻撃者の存在を指定している。
【0057】
図16に、脅威具体化規則によって脅威が段階的に具体化される様子の例を示す。まず、(a)に
図13に記載の脅威具体化規則1-1又は1-2を適用することで(b)が生成され、Httpの盗聴は、VMにおける盗聴コマンドの実行へと具体化されて置き換えられている。次に、(b)に
図15に記載の脅威具体化規則2を適用することで(c)が生成され、事前の作業として、上記のVMにおけるRoot権限の取得が付与されている。更に、(c)に
図15に記載の脅威具体化規則3-1を適用することで(d)が生成され、そのRoot権限の取得の事前の想定として、内部ドメインにおける内部の攻撃者が付与されている。
【0058】
図16に示す例に登場した、Httpの盗聴、盗聴コマンドの実行、Root権限の取得、及び内部の攻撃者の各脅威は、それぞれ異なる位置付けの脅威として解釈できる。Httpの盗聴及び盗聴コマンドの実行は、システム要件や構成要素型において直接防御すべきであると指定された脅威であり、実現されてはならない攻撃目標に相当する。Root権限の取得は、実現されても本来は脅威にはならない行為であるが、攻撃目標を実行するための準備作業に相当する。また、内部の攻撃者は、攻撃の起点に相当する。攻撃の起点から、任意個の準備作業を経由して、攻撃目標に至るパスを攻撃パスと呼び、攻撃パスが成立するときに実際に脅威が実現されると評価できる。なお、
図16には1つの攻撃パスのみを例示したが、1つの構成ドラフト内には複数の攻撃パスを生成してもよく、1つでも攻撃パスが成立した場合にはセキュアでないと評価してもよい。
【0059】
どの脅威が攻撃の起点と見なされるかについては、事前に何らかの方法で定義しておく必要があるが、例えば、利用者が指定したセキュリティレベルと
図17に例示したセキュリティレベルの定義とによって決定してもよい。
【0060】
図17に、セキュリティレベルの定義例を示す。
図17には、セキュリティに寛容なレベル1から厳格なレベル3までの3つのセキュリティレベルが定義されている。各セキュリティレベルには、想定される攻撃の起点及び許容リスクが指定されている。セキュリティレベル1及び2では、外部の攻撃者のみを攻撃の起点として想定し、内部の攻撃者の存在は看過している。一方、セキュリティレベル3では、外部の攻撃者及び内部の攻撃者の両方を攻撃の起点として想定しており、より強固なセキュリティを要求している。また、セキュリティレベル1は、中程度までのリスクを許容し、セキュリティレベル2は、小さなリスクのみを許容し、セキュリティレベル3は、いかなるリスクも許容しない。なお、
図17に示される情報は、記憶部104に記憶されている。
【0061】
図18に、セキュリティの評価に基づいて構成ドラフトが生成され選択される様子の例を示す。ここでは、利用者が、セキュリティレベルとしてレベル2を指定することを想定する。すなわち、利用者は、外部の攻撃者のみを攻撃の起点として想定し、小さなリスクのみを許容するものとする。システム要件に指定されたConnTo<AP, AP>の盗聴は、リスクが中であるため、防御すべき脅威として認識される。構成要素が具体化されても、脅威は継承されるため、ConnTo<AP, AP>の盗聴はHttpの盗聴やHttpsの盗聴へと引き継がれる。(a)では、攻撃パスが成立したため、セキュアでないと評価され、以降の具体化はキャンセルされている。Https上の盗聴は、それを実現する具体的な手段が定義されていないため、攻撃パスが生成されず、(b)、(c)、及び(d)の構成ドラフトが順次生成されている。ここでは、完全に具体化された構成ドラフトである(c)又は(d)が、システム構成として出力されることとなる。
【0062】
なお、本開示の焦点から外れるが、
図18において、(e)及び(f)はセキュリティとは異なる理由により棄却されている。本実施形態2では、AP型及びVM型の構成要素は、それぞれDomain型の構成要素に所属すること、すなわちJoinIn<*,Domain>型の関係性によって接続されることを想定している。ここで、あるAP型の構成要素ap1と、上記のap1がホストされるVM型の構成要素vm1は、同一のDomainに所属することが期待される。そこで、あるDomainに所属する構成要素が、他の構成要素にホストされている状況であれば、上記のホストしている他の構成要素も上記のドメインに所属しなければならないことを示す制約条件を定義する。そして、本実施形態2におけるシステム要件には、上記の制約条件を付与して、これを満たさない構成を棄却しつつ、システム要件の具体化を実施する動作を想定している。(e)及び(f)の構成ドラフトでは、AP
1型とAP
2型の構成要素は同じVM型の構成要素vm1にホストされているため、当該vm1は2つのドメインに所属することとなる。本実施形態2では更に、1つのVM型の構成要素は1つのドメインにしか所属できないという制約の存在を想定しており、この制約は、上記の制約条件と矛盾する。これにより、(e)及び(f)は棄却される。
【0063】
次に、本実施形態2に係る入出力部101が、利用者の端末に表示するGUI(Graphical User Interface)画面の例について説明する。
図19に、設計画面210の例を示す。
図19において、(a)の「要件編集ペイン」は、利用者がシステム要件を編集するための領域である。(c)の「選択可能な部品の一覧」には、利用者が選択可能な構成要素、脅威などの部品の一覧が表示される。利用者は、(c)に一覧表示された部品の中から所望の部品を選択し、システム要件を編集する。このように、利用者は、システム要件において考慮したい所望の脅威を選択しながら、システム要件を編集できる。なお、脅威はウイルスのアイコンとして表示される。(b)の「設計結果確認ペイン」には、(a)のシステム要件を段階的に具体化することにより得られたシステム構成が表示される。
【0064】
図20に、設計過程確認画面220の例を示す。
図20において、(a)の「設計過程の全体像」には、セキュアシステム自動設計装置200による上述した設計処理の各段階における具体化の態様として、システム要件、各段階の具体化で得られた構成ドラフト、及び最終的なシステム構成の一覧が表示される。利用者は、(a)の中から、所望のある1段階の具体化の具体化前後の構成情報を選択可能である。(d)の「1ステップの具体化」は、係る各段階における具体化の態様のうち、利用者が選択したある1段階における具体化の態様が表示されている。(b)の「1ステップの具体化前」には、利用者が選択した1段階の具体化前の構成情報が表示される。(c)の「1ステップの具体化後」には、利用者が選択した1段階の具体化後の構成情報が表示される。このように、利用者は、設計の過程を遡って、脅威の具体化過程を確認できる。そのため、利用者は、セキュアな設計とならなかった場合には、何が原因であるかを確認できる。また、入出力部101は、構成情報具体化部103による分岐すべき選択肢の判断が少なくとも行えない場合に、
図20に示される設計過程確認画面220を表示してもよい。
【0065】
次に、本実施形態2の動作について説明する。
図21は、本実施形態2に係るセキュアシステム自動設計装置200の動作例を示すフローチャートである。上記の実施形態1と同様の箇所は、上記の実施形態1と同様の記号を付し説明を省略する。
【0066】
まず、構成情報具体化部103は、利用者の端末から、入出力部101を介して、脅威の指定を含むシステム要件及び利用者が要求するセキュリティレベルの入力を受け付ける(S201)。続いて、構成情報具体化部103は、システム要件内の各脅威の内、利用者が指定したセキュリティレベルに対応する許容するリスクよりも大きなリスクを指定している脅威を、対象とする脅威として選択する(S202)。セキュリティレベルに対応するリスクの判断に必要な情報(例えば、
図17の情報)は、記憶部104に記憶されており、構成情報具体化部103は、記憶部104からこれを読み出す。以降の流れは、上記の実施形態1と概ね同様であるが、各構成ドラフトについて脅威を更新・具体化する処理(S203)と構成ドラフトを評価する処理(S204)だけが異なる。
【0067】
S203では、まず、構成情報具体化部103は、S102で生成された構成ドラフトに新規に追加された構成要素がある場合には、当該構成要素の型を確認し、脅威が指定されていれば、これを付与する。脅威の指定の有無の判断に必要な構成要素型の情報(例えば、
図12の情報)は、記憶部104に記憶されており、構成情報具体化部103は、記憶部104からこれを読み出す。また、構成情報具体化部103は、S102で生成された各構成ドラフトを脅威情報具体化部201に渡し、脅威情報具体化部201は、当該構成ドラフト内に存在する各脅威に対して、適用可能な全ての脅威具体化規則を適用する処理を、適用可能な脅威具体化規則が無くなるまで繰り返すことで、攻撃パスを出来る限り具体化して生成する。脅威具体化規則の情報(例えば、
図13及び
図15の情報)は、記憶部104に記憶されており、脅威情報具体化部201は、記憶部104からこれを読み出す。
【0068】
S204では、構成情報具体化部103は、構成ドラフトを評価するため、構成ドラフトと利用者に指定されたセキュリティレベルの情報とをセキュリティ評価部102に渡して、評価結果を受け取る。セキュリティ評価部102は、指定されたセキュリティレベルに応じて決定される攻撃の起点から、構成ドラフトに含まれる脅威(すなわち、システム要件及び構成要素型によって指定された脅威)に至る攻撃パスが成立しているか否かを確認し、攻撃パスが成立している場合にはセキュアでないと評価し、攻撃パスが成立していない場合にはセキュアであると評価する。セキュリティレベルに対応する攻撃の起点の判断に必要な情報(例えば、
図17の情報)は、記憶部104に記憶されており、セキュリティ評価部102は、記憶部104からこれを読み出す。
【0069】
なお、以上の説明において、構成ドラフトの評価は、ある特定の条件を満たすか満たさないかの2値評価のみを扱ってきたが、例えば性能値やコストといった連続値による評価を扱うことができれば、具体化の対象とする構成ドラフトを、より評価値の高い構成ドラフトへ集中して、絞込みを先鋭化し、設計の効率を更に高めることが期待できる。そのため、セキュリティの評価においても、どの程度セキュアであるかを評価してもよい。例えば、脅威のサイズに応じた点を、小は1点、中は2点、大は3点と設定しておき、成立した脅威の点数を合計した値を脅威の大きさとして、その逆数をセキュリティの評価値としてもよい。又は、攻撃パスの長さと本数に基づいて、長いパスが多数あるほど脅威が大きくなるような値を設定し、その逆数をセキュリティの評価値としてもよい。
【0070】
本実施形態2によれば、構成情報具体化部103は、セキュリティ評価部102により攻撃パスの成立が明確となった構成ドラフトを、直ちに棄却し、それ以降の具体化を省略することが可能となり、セキュアシステムを効率的に導出することが期待できる。
【0071】
<実施形態3>
次に、本実施形態3の構成について説明する。
図22は、本実施形態3に係るセキュアシステム自動設計装置300の機能構成例を示す概略ブロック図である。本実施形態3は、上記の実施形態1,2を上位概念化した実施形態に相当する。
【0072】
図22に示されるように、セキュアシステム自動設計装置300は、入出力部301と、セキュリティ評価部302と、構成情報具体化部303と、を備える。入出力部301、セキュリティ評価部302、及び構成情報具体化部303は、それぞれ、入出力部101、セキュリティ評価部102、及び構成情報具体化部103に対応する。
【0073】
入出力部301は、システム要件の入力を受け付けると共に、システム構成を出力する。
構成情報具体化部303は、システム要件を、複数の具体化の手続きによってシステム構成に変換する。
セキュリティ評価部302は、システム構成のセキュリティを評価する。
【0074】
ここで、構成情報具体化部303は、具体化の各手続きにおいては、複数の具体化の方法の選択肢へ分岐し、変換途中の構成情報である複数の構成ドラフトを生成する。
セキュリティ評価部302は、各手続きによって生成された構成ドラフトについてもセキュリティを評価する。
構成情報具体化部303は、セキュリティ評価部302による構成ドラフトの評価結果に基づいて、分岐すべき選択肢を判断する。
【0075】
本実施形態3によれば、構成情報具体化部303は、セキュリティ評価部302による構成ドラフトのセキュリティの評価結果に基づいて、選択肢を判断する。そのため、セキュアでないことが明確となった構成ドラフトを、直ちに棄却し、それ以降の具体化を省略することが可能となり、セキュアシステムを効率的に導出することができる。
【0076】
なお、セキュアシステム自動設計装置300は、システムの構成要素に関する情報を記憶する記憶部を更に備えていてもよい。この記憶部は、記憶部104に対応する。また、記憶部に記憶された構成要素に関する情報には、当該構成要素の脆弱性に関する情報が付与されてもよい。セキュリティ評価部302は、各々の構成ドラフトについて、当該構成ドラフトに含まれる各構成要素の脆弱性に基づいて、当該構成ドラフトのセキュリティを評価してもよい。
【0077】
また、入出力部301は、設計時に考慮すべきリスクに関する情報の入力を更に受け付けてもよい。セキュリティ評価部302は、構成ドラフトに含まれる各構成要素の脆弱性と、入力されたリスクに対応する脆弱性と、に基づいて、当該構成ドラフトのセキュリティを評価してもよい。
【0078】
また、セキュアシステム自動設計装置300は、攻撃の起点から攻撃目標に至るパスである攻撃パスの情報を具体化する脅威情報具体化部を更に備えていてもよい。この脅威情報具体化部は、脅威情報具体化部201に対応する。脅威情報具体化部は、各々の構成ドラフトについて、当該構成ドラフトの内容に基づいて、防御されるべき1つ又は複数の攻撃パスの情報を具体化してもよい。セキュリティ評価部302は、各々の構成ドラフトについて、攻撃パスの具体化された内容に基づいて、当該構成ドラフトのセキュリティを評価してもよい。
【0079】
また、入出力部301は、設計時に考慮すべきセキュリティのレベルに関する情報の入力を更に受け付けてもよい。セキュリティ評価部302は、構成ドラフトについて、攻撃が発生した際のリスクのレベル及び発生頻度を更に評価し、入力されたセキュリティのレベルと、攻撃が発生した際のリスクのレベル及び発生頻度と、に基づいて、考慮すべき攻撃を選択し、選択された攻撃に基づいて、構成ドラフトのセキュリティを評価してもよい。
【0080】
また、入出力部301は、システム要件に含まれる構成要素及び当該構成要素に付与される脅威に関して編集可能なユーザインタフェースを含んでもよい。また、入出力部301は、構成情報具体化部303による分岐すべき選択肢の判断が少なくとも行えない場合に、分岐すべき特定の選択肢の選択及び複数の具体化の手続きを、複数の具体化の手続きのうち、ユーザが所望の具体化の手続きに関して編集可能なユーザインタフェースを含んでもよい。
【0081】
<実施の形態4>
次に、本実施形態4の構成について説明する。
図23は、本実施形態4に係るセキュアシステム自動設計装置400のハードウェア構成例を示す概略ブロック図である。
図23に示されるように、セキュアシステム自動設計装置400は、プロセッサ401及びメモリ402を備える。
【0082】
プロセッサ401は、例えば、マイクロプロセッサ、MPU(Micro Processing Unit)、又はCPU(Central Processing Unit)であってもよい。プロセッサ401は、複数のプロセッサを含んでもよい。
【0083】
メモリ402は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ402は、プロセッサ401から離れて配置されたストレージを含んでもよい。この場合、プロセッサ401は、図示されていないI(Input)/O(Output)インタフェースを介してメモリ402にアクセスしてもよい。
【0084】
上記の実施の形態1~3に係るセキュアシステム自動設計装置100~300は、
図23に示されるハードウェア構成を有することができる。メモリ402には、プログラムが記憶される。このプログラムは、コンピュータに読み込まれた場合に、上記の実施の形態で説明された1又はそれ以上の機能をコンピュータに行わせるための命令群(又はソフトウェアコード)を含む。上記のセキュアシステム自動設計装置100~300における、入出力部101,301、セキュリティ評価部102,302、構成情報具体化部103,303、及び脅威情報具体化部201は、プロセッサ401がメモリ402に記憶されたプログラムを読み込んで実行することにより実現されてもよい。また、上記のセキュアシステム自動設計装置100~300における記憶部104は、メモリ402により実現されてもよい。
【0085】
また、上記のプログラムは、非一時的なコンピュータ可読媒体又は実体のある記憶媒体に格納されてもよい。限定ではなく例として、コンピュータ可読媒体又は実体のある記憶媒体は、random-access memory(RAM)、read-only memory(ROM)、フラッシュメモリ、solid-state drive(SSD)又はその他のメモリ技術、CD-ROM、digital versatile disc(DVD)、Blu-ray(登録商標)ディスク又はその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又はその他の磁気ストレージデバイスを含む。プログラムは、一時的なコンピュータ可読媒体又は通信媒体上で送信されてもよい。限定ではなく例として、一時的なコンピュータ可読媒体又は通信媒体は、電気的、光学的、音響的、又はその他の形式の伝搬信号を含む。
【0086】
以上、実施形態を参照して本開示を説明したが、本開示は上記の実施形態に限定されるものではない。本開示の構成や詳細には、本開示のスコープ内で当業者が理解し得る様々な変更をすることができる。
【符号の説明】
【0087】
100,200,300,400 セキュアシステム自動設計装置
101,301 入出力部
102,302 セキュリティ評価部
103,303 構成情報具体化部
104 記憶部
201 脅威情報具体化部
401 プロセッサ
402 メモリ