(57)【特許請求の範囲】
【請求項１】
通信における規格内容を意味する属性値を含む要件データと規格に関する情報を備えた規格データを入力する規格データ入力部と、
対象システムの情報を属性として有し、前記要件データについてその属性値と属性の関係を予め定義し、指定された対象システムの情報に一致する前記要件データを出力する要件データ構造記憶部と、
前記規格データ入力部から得た前記規格データの前記要件データについて前記要件データ構造記憶部を参照して、その前記属性値に対応する前記属性の情報を付与した要件データとし、
前記規格に関する情報とともに新たな規格データとして保持する規格データ記憶部を備えたことを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
新たに定められ、前記規格データ入力部に得られた前記規格データについて、前記要件データの属性値を前記要件データ構造記憶部の既存の要件データに関連付けて記憶し、あるいは前記要件データ構造記憶部に作成した新規の属性に関連付けて記憶して、前記の規格データ記憶部を構成することを特徴とする情報処理装置。
【請求項３】
請求項１または請求項２に記載の情報処理装置であって、
通信における対策内容を意味する属性値を含む対策データを入力する対策データ入力部と、前記対策データについてその属性値と属性の関係を予め定義している対策データ構造記憶部と、
前記対策データ入力部から得た前記対策データについて前記対策データ構造記憶部を参照して、その前記属性値に対応する前記属性の情報を付与した対策データとして保持する対策データ記憶部を備えたことを特徴とする情報処理装置。
【請求項４】
請求項３に記載の情報処理装置であって、
前記対策データ入力部に得られた前記対策データについて、前記対策データの属性値を前記対策データ構造記憶部の既存の対策データに関連付けて記憶し、あるいは前記対策データ構造記憶部に作成した新規の属性に関連付けて記憶して、前記の対策データ記憶部を構成することを特徴とする情報処理装置。
【請求項５】
請求項３または請求項４記載の情報処理装置において、
処理手順を実装する前記要件データ、もしくは処理手順を実装する要件データ構造を前記要件データ構造記憶部に備えたことを特徴とする情報処理装置。
【請求項６】
請求項３または請求項４記載の情報処理装置において、
前記属性の拡張、あるいは要件データ構造が実装する処理手順の拡張により派生した要件データ構造を前記要件データ構造記憶部に備えたことを特徴とする情報処理装置。
【請求項７】
請求項３または請求項４記載の情報処理装置において、
前記対策データ記憶部に保持される前記対策データは、事前に関連付けた装置、ソフトウェア、サービス、規格データのいずれかを指定することで決定されることを特徴とする情報処理装置。
【請求項８】
請求項３または請求項４記載の情報処理装置において、
適用地域の属性に応じて、前記規格データ記憶部に保持される前記規格データを選択し解析する規格データ解析部を備えることを特徴とする情報処理装置。
【請求項９】
請求項３または請求項４記載の情報処理装置において、
ユーザの属性に応じて、前記規格データ記憶部に保持される前記規格データを選択し解析する規格データ解析部を備えることを特徴とする情報処理装置。
【請求項１０】
請求項３または請求項４記載の情報処理装置において、
複数の前記規格データの差分を出力することを特徴とする情報処理装置。
【請求項１１】
請求項３または請求項４記載の情報処理装置において、
指定された属性の属性値に一致する前記要件データを出力することを特徴とする情報処理装置。
【請求項１２】
請求項３または請求項４記載の情報処理装置において、
前記対策データは、前記属性の拡張により派生した対策データあるいは処理手順の拡張により派生した対策データを含むことを特徴とする前記情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および通信系統の運用方法に関する。
【背景技術】
【０００２】
社会インフラへの情報通信技術の導入にともない、セキュリティの懸念が増大している。これにあわせ、行政や関連する研究団体、あるいは国際規格においてもセキュリティに関する規格やガイドラインが整備されている。
【０００３】
これらの規格やガイドラインは、セキュリティに関する脅威をもとに算定されている。したがって、ベンダは、これらの規格やガイドラインに基づくことで一定のセキュリティ強度をそなえた製品やサービスを設計、運用、開発、提供することができる。
【０００４】
特に、電力分野やエネルギー分野など、重要インフラに深く係わる分野では、社会インフラの正常運用のため、所定規格の順守を強制化している。
【０００５】
セキュリティの対象範囲は広く、システムレベルの広い範囲を対象とした規格、ガイドラインや特定の装置を対象にした規格、ガイドラインまで幅広く存在する。対象範囲だけでなく、対象技術、対象フェーズなど、さまざまな観点で策定された規格、ガイドラインが存在する。
【０００６】
対象装置のセキュリティレベル評価の精度を向上させることに関連して、特許文献１には、「基本モデル選択部１は、評価者によって選択された基本モデルを表示装置９に表示する。インスタンス入力部３は、基本モデル上の構成要素と、当該構成要素について定義されたインスタンスとを関連付けたインスタンスリストを作成する。セキュリティ対策リスト生成部４は、選択済み基本モデルとインスタンスリストとをもとにセキュリティ対策リストを生成する。質問リスト生成部５は、セキュリティ対策リストと、質問テンプレートリストをもとに質問リストを生成する。回答集計部７は、質問リストに対する回答結果と、セキュリティ対策リストと質問テンプレートリストとを照らし合わせてレベル評価結果テーブルを生成する。また、回答集計部７は、レベル評価結果テーブルをもとに網羅性とセキュリティ性のセキュリティレベルをそれぞれ計算する。」ことが開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−１４０３６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
これらのセキュリティ規格、ガイドラインに準拠することにより、製品、サービスにおいて、一定のセキュリティ強度を保障することができる。一方で、対象レベル、対象技術、対象フェーズなどの観点で、複数の規格が存在するために対象装置、サービスにおいて、どの規格のどういった要件を満足すればよいかを判定することが難しいという課題がある。
【０００９】
また、情報通信技術の技術進展の速さにともない、セキュリティ規格においても改定周期が今後速くなることが予想される。一度対応したセキュリティ規格の改定にともない、追加で対応すべき要件の管理が課題となる。これは規格改定のみならず、他の規格に対応する場合においても同様である。
【００１０】
特許文献１によれば、セキュリティ対策の有効度を定義することで、所定のシステムに対して、どの程度セキュリティ対策が有効であることを判定できる。さらに、質問形式で容易にセキュリティ対策を登録することができる。
【００１１】
しかしながら、複数のセキュリティ規格対応を容易にすることや、規格改定時の対応を容易にすることはできない。
【００１２】
以上のことから本発明においては、複数のセキュリティ規格、ガイドラインの対応、規格、ガイドライン改定時の対応を容易にすることを可能とする情報処理装置および通信系統の運用方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は、上記課題を解決するために、通信における規格内容を意味する属性値を含む要件データと、規格に関する情報を備えた規格データを入力する規格データ入力部と、要件データについてその属性値と属性の関係を予め定義している要件データ構造記憶部と、規格データ入力部から得た規格データの要件データについて要件データ構造記憶部を参照して、その属性値に対応する属性の情報を付与した要件データとし、規格に関する情報とともに新たな規格データとして保持する規格データ記憶部を備えたことを特徴とする。
【００１４】
また本発明は、複数の規格データで構成された既存の第１の規格で運用される通信系統に対して、複数の規格データで構成された新規の第２の規格も含めて運用するための通信系統の運用方法であって、規格データは、通信における規格内容を意味する属性値を含む要件データと、規格に関する情報を含んで構成されており、第１の規格における要件データについてその属性値と属性の関係を予め定義して要件データ構造として保持し、新規の第２の規格について、その要件データの属性値を要件データ構造の属性に関連付けて記憶し、あるいは要件データ構造に追加作成した新規の属性に関連付けて保持することを特徴とする。
【発明の効果】
【００１５】
本発明によれば、複数のセキュリティ規格、ガイドラインの対応、規格、ガイドライン改定時の対応を容易にする。
【図面の簡単な説明】
【００１６】
【図１】本発明に係るセキュリティ関連情報処理装置のセキュリティ関連処理機能を示す図。
【図２】複数の情報処理装置を含んで構成された通信システムの典型的な一例を示した図。
【図３】本発明の処理で取り扱う規格データＤ１の主たる構成部分である要件データＤ１１の例を示す図。
【図４】要件データ構造記憶部１３０に記憶される要件データ構造例を示す図。
【図５】従来におけるセキュリティ対策の支援、評価手法を示した図。
【図６】規格データＤ１に属性を付与して規格データＤ２とする点について具体的に例示した図。
【図７】対策データ構造記憶部１３４に記憶される対策データ構造例を示す図。
【図８】本発明における実行手順の種別を示した図。
【図９】要件データ構造の定義手順プログラムＰｒ１について示した図。
【図１０】規格データの定義手順プログラムＰｒ２について示した図。
【図１１】対策データ構造の定義手順プログラムＰｒ３について示した図。
【図１２】対策データの定義手順プログラムＰｒ４について示した図。
【図１３】対策データの定義手順プログラムＰｒ４の代替案について示した図。
【図１４】解析処理の定義手順プログラムＰｒ５について示した図。
【図１５】解析処理の定義手順プログラムＰｒ５の一部を詳細に示した図。
【図１６】解析処理の定義手順プログラムＰｒ５の一部を詳細に示した図。
【図１７】具体的な表示画面例を示す図。
【発明を実施するための形態】
【００１７】
以下本発明に係るセキュリティ関連情報処理装置、情報処理ソフトウェア及び情報管理方について、図面を用いて詳細に説明する。
【実施例】
【００１８】
図２は、複数の情報処理装置を含んで構成された通信システムの典型的な一例を示した図である。図２の通信システムは、複数の情報処理装置Ｃ（Ｃａ、Ｃｂ、Ｃｃ、Ｃｄ）、データベースＤＢ（ＤＢａ、ＤＢｂ、ＤＢｃ、ＤＢｄ）、ネットワークＮＷ（ＮＷａ、ＮＷｂ、ＮＷｃ、ＮＷｄ、ＮＷｄ、ＮＷｅ）などで構成されている。
【００１９】
このうち情報処理装置Ｃとしては、パソコン、サーバ、ワークステーション、クラウド等が挙げられる。
【００２０】
データベースＤＢは、所定のデータのストレージであり、パソコン、サーバ、ワークステーション、クラウド、ＮＡＳ（ＮｅｔｗｏｒＫ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）、ストレージサーバ、ファイルサーバ等が例示される。データベースＤＢは集中型であっても、地理的、論理的に分散されていてもよい。
【００２１】
ネットワークＮＷは、各情報処理装置Ｃ、データベースＤＢを接続するものであり、通信規格としてはＩＥＥＥ  ８０２．３等が例示される。なお本発明においては情報を送受信できればよく、規格の種別は問わない。
【００２２】
なお図２において、情報処理装置Ｃ、データベースＤＢは別個に記載したが、複数台を１つの機器としてもよい。また、ネットワークＮＷは各情報処理装置Ｃ、データベースＤＢ間の接続として描いているが、複数のネットワークＮＷを１つに集約してもよいし、あるいは情報処理装置Ｃ、データベースＤＢの集約にあわせて、省略しても構わない。また図２に示す全ての情報処理装置Ｃ、データベースＤＢ、ネットワークＮＷをひとつの情報処理装置に集約してもよい。
【００２３】
また図２の典型的な通信システムにおいて、定義される規格は、以下のようである。本発明で想定する規格、ガイドラインとは、所定の組織、団体が定めた規格やガイドラインであり、一つまたは複数の要件によって構成するものとする。規格、ガイドラインは国際規格や地域規格、また所定組織、団体の独自の規格、ガイドラインを含む。またＮＩＳＴサイバーセキュリティフレームワークやＮＥＲＣ  ＣＩＰ、ＩＥＣ  ６２４４３、ＩＥＣ  ６２３５１、ＮＩＳＴＩＲ  ７６２８、ＩＥＥＥ  １６８６等を含むものである。なお本発明では、特に区別して説明する必要がない限りにおいて、これらをすべて含めてセキュリティにおける規格として説明する。
【００２４】
図１は、本発明に係るセキュリティ関連情報処理装置のセキュリティ関連処理機能を示している。このセキュリティ関連処理機能は、大きく３つの機能に分けられている。
【００２５】
大別した第１の機能１００は、規格データＤ１を取り扱うことから、規格データ処理機能と称する。規格データ処理機能１００は、規格データ入力部１３１、要件データ構造記憶部１３０、規格データ記憶部１３２の機能がこれに相当する。規格データ入力部１３１に取り込まれた新たな規格（規格データＤ１）は、要件データ構造記憶部１３０において規格データＤ１内の要件データＤ１１の構造が解析記憶され、最終的に規格データ記憶部１３２に規格データＤ２として保持される。
【００２６】
具体的には、要件データ構造記憶部１３０は、セキュリティ規格の要件を表す要件データＤ１１の集合の記憶部であり、データベースＤＢｃで構成する。規格データ入力部１３１は、要件データ構造記憶部１３０で定義される要件データＤ１１の構造を参照しながら、セキュリティ規格を構成する各要件をデータ化して、規格データ記憶部１３２に記憶する機能部であり、情報処理装置Ｃｃで構成する。規格データ記憶部１３２は、規格データ入力部１３１でデータ化された要件データＤ１１の集合を所定の規格データＤ２として記憶する機能部であり、データベースＤＢｄで構成する。
【００２７】
大別した第２の機能２００は、対策データＤ３を取り扱うことから対策データ処理機能と称する。対策データ処理機能２００は、対策データ入力部１３５、対策データ構造記憶部１３４、対策データ記憶部１３６の機能がこれに相当する。対策データ入力部１３５に取り込まれた新たな対策は、対策データ構造記憶部１３４において対策データ構造が解析記憶され、最終的に対策データ記憶部１３６に対策データＤ４として保持される。
【００２８】
具体的には、対策データ構造記憶部１３４は、セキュリティ対策を表す対策データＤ３の構造の集合の記憶部であり、データベースＤＢａで構成する。対策データ入力部１３５は、対策データ構造記憶部１３４で定義される対策データＤ３の構造を参照しながら、セキュリティ対策をデータ化して対策データ記憶部１３６に記憶する。対策データ記憶部１３６は、対策データ入力部１３５でデータ化された対策データＤ３の集合を、所定の対策データＤ４として記憶する機能部であり、データベースＤＢｂで構成する。
【００２９】
大別した第３の機能３００は、それぞれの書式、形式に整理された規格データＤ２と対策データＤ４を取り扱うことから解析処理機能と称する。解析処理機能３００は、規格データ解析部１３３、解析処理利用手段１３７の機能がこれに相当する。解析処理利用手段１３７において、解析処理を指示された場合に、規格データ記憶部１３２から規格データＤ２を、また対策データ記憶部１３６から対策データＤ４を規格データ解析部１３３に取り込み解析を行う。
【００３０】
具体的には、規格データ解析部１３３は、規格データ記憶部１３２に記憶された整理規格データＤ２を解析する機能部である。解析内容によって、対策データ記憶部１３６に記憶された対策データＤ４を用いる。規格データ解析部１３３は、情報処理装置Ｃｂで構成する。
【００３１】
規格データ解析部１３３での解析処理においては、規格データＤ２、あるいは対策データＤ４を用いることで、システム、装置、ソフトウェア、サービスの設計、構築、計画、運用、保守、更新、終了等において、所有者、設計者、運用者、ユーザ、それらのシステム、装置、ソフトウェア、サービスを利用する他のシステム、装置、ソフトウェア、サービスにおいて、有益な情報を提供する。
【００３２】
次に、図１の本発明に係るセキュリティ関連情報処理装置のセキュリティ関連処理機能で取り扱う規格データＤ１、Ｄ２、および対策データＤ３、Ｄ４と、その処理内容について説明する。まず規格データＤ１、Ｄ２と、その処理内容について説明する。
【００３３】
ここで取り扱う規格データＤ１は、図３に示すように規格を構成する要件を表わす要件データＤ１１の集合と、規格に関する情報Ｄ１２の集合と、で構成されている。
【００３４】
規格データＤ１のうち要件データＤ１１は、後述する属性値Ｋを含んだ情報Ｄ１１（Ｋ）である。要件データＤ１１は、規格データ処理機能１００における処理によって要件データ構造記憶部１３０に記憶される要件データ構造を参照して、それぞれに属性値Ｊを設定した要件データＤ１１（Ｊ、Ｋ）とすることで再定義される。規格データＤ２は、再定義された要件データＤ１１（Ｊ、Ｋ）を含む規格データである。
【００３５】
規格に関する情報Ｄ１２とは、規格名称や規格の策定者、策定組織に関する情報、規格の策定年月日、規格のバージョン等である。なお、要件データＤ１１は規格内における要件の参照番号があれば、該参照番号とあわせて保持してもよい。あるいは、規格データＤ１から他の規格データＤ１を参照し、規格データＤ１が階層構造となっていてもよい。このとき、要件データＤ１１と同じように、下位の規格データＤ１を参照番号、参照情報とあわせて記憶してもよい。規格データ記憶部１３２は、要件データＤ１１（Ｊ、Ｋ）を含んで編集された規格データＤ２の集合を記憶する。
【００３６】
図４は、要件データ構造記憶部１３０に記憶される要件データ構造例を示す図である。要件データ構造は、セキュリティ規格を構成する要件に共通する属性の集合である。図４には、属性値Ｋとその属性名Ｊが対構造として定義され、記憶されている。
【００３７】
図４には、属性名Ｊの代表的なものとして、セキュリティ技術種別Ｊ１、更新周期Ｊ２、対応必須度Ｊ３、要件確認方法Ｊ４、評価指数Ｊ５、寄与する性質Ｊ６、技術の独自性Ｊ７、システムのオープン性Ｊ８、対象Ｊ９が例示されている。
【００３８】
また、各属性名Ｊのさらに詳細な内容として属性値例Ｋが例示されている。具体的には、セキュリティ技術種別Ｊ１の属性値例Ｋ１について暗号化Ｋ１１、アクセス制御方式Ｋ１２、権限管理Ｋ１３が例示され、更新周期Ｊ２の属性値例Ｋ２について初回のみＫ２１または定期的Ｋ２２に行うことが示され、対応必須度Ｊ３の属性値例Ｋ３について必須Ｋ３１または推奨Ｋ３２または任意Ｋ３３のいずれかであり、要件確認方法Ｊ４の属性値例Ｋ４について手順定義文章の有無Ｋ４１または所定プロトコルの実行Ｋ４２が例示され、評価指数Ｊ５の属性値例Ｋ５についてパスワード長Ｋ５１、暗号鍵ビット長Ｋ５２、所定セキュリティ対策の実装率Ｋ５３が例示され、寄与する性質Ｊ６の属性値例Ｋ６について可用性Ｋ６１、完全性Ｋ６２、機密性Ｋ６３が例示され、技術の独自性Ｊ７の属性値例Ｋ７について独自技術Ｋ７１または標準技術Ｋ７２のいずれかであり、システムのオープン性Ｊ８の属性値例Ｋ８について外部接続なしＫ８１、外部接続ありＫ８２の区別、対象Ｊ９の属性値例Ｋ９についてシステムＫ９１／装置Ｋ９２／ソフトウェアＫ９３の区別が例示されている。
【００３９】
従って例えば、暗号化についての属性値Ｋ１を含んだ要件データＤ１１（Ｋ１）は、要件データ構造記憶部１３０に記憶される要件データ構造を参照して、該当する属性名Ｊであるセキュリティ技術種別Ｊ１が付与されて、要件データＤ１１（Ｊ１、Ｋ１）とすることで再定義され、この結果が規格に関する情報Ｄ１２とともに規格データ記憶部１３２に送られて、規格データＤ２として保持される。同様に、パスワード長の実装率についての属性値Ｋ５を含んだ要件データＤ１１（Ｋ５）は、要件データ構造記憶部１３０に記憶される要件データ構造を参照して、該当する属性名Ｊである評価指数Ｊ５が付与されて、要件データＤ１１（Ｊ５、Ｋ５）とすることで定義され、この結果が規格に関する情報Ｄ１２とともに規格データ記憶部１３２に送られて、規格データＤ２として保持される。
【００４０】
ここで、属性値Ｋについて説明を追加しておく。要件データＤ１１の属性値Ｋについて、規格上、属性値Ｋの取り得る値が決まっている場合には、それらの属性値Ｋを別途定義し、データ化に際して、該当する定義値を選択する、あるいは属性値Ｋには型を定義してもよい。例えば、属性値Ｋが数値である場合、属性値Ｋを数値型としてもよいし、真理値をとる場合、属性値Ｋを論理型としてもよい。あるいは属性値Ｋを定義できないことを示す特別な値を定義してもよい。これは例えば、要件データＤ１１における該当属性Ｊが未定義であることを示す。あるいは明示的に未定義であることを示す属性値Ｋを定義してもよい。未定義と、明示的な未定義を区別することで、データ化手順において、ユーザが誤って属性値Ｋを定義しなかった場合と、意図的に属性値Ｋを定義しなかった場合を区別することができる。
【００４１】
また、既存の要件データＤ１１の構造において、所定の解析処理に不要な属性の値を明示的な未定義にすることで、要件データ構造の種類を制限することができ、要件データ構造の選択を容易にすることや、要件データ構造記憶部１３０の計算機資源（演算能力や記憶容量等）を抑えることができる。
【００４２】
これらの属性値Ｋの定義により、より厳密な要件データＤ１１の定義が可能である。例えば、選択肢でない属性値Ｋを定義した場合や、数値型である属性値Ｋに対して、文字列を設定した場合に、要件データ構造を利用するユーザに対して、注意、警告を発し、データ化を正確にすることができる。さらに、属性値Ｋが未定義の要件データＤ１１をユーザに提示することで、データ化の失念を防止することができる。
【００４３】
なお、本発明の処理で取り扱う規格データＤ１の主たる構成部分である要件データＤ１１は、図４に示す属性の中で、ひとつ、または複数の属性を少なくとも有する基本要件データ構造を定義してもよい。
【００４４】
また、基本要件データ構造に対して、基本要件データ構造に含まれない属性を追加で定義する派生要件データ構造を定義してもよい。また派生要件データの構造をさらに派生させる等、要件データ構造が階層構造となっていてもよい。また、これらの要件データ構造は、規格データ解析部１３３の解析内容に応じた解析処理を定義してもよい。解析処理の追加によって、派生要件データ構造を定義してもよい。全ての派生要件データ構造を基本要件データ構造から派生させることで、全ての要件に共通する属性、処理を全ての要件データ構造がそなえていることを保証できる。
【００４５】
なお、基本要件データ構造に含まれない属性を追加で定義する派生要件データに関して、その派生方法にはいくつかの方法がある。例えば解析処理の内容の違いによって派生、継承させる場合（例えば、要件の満足判定方法）や、該当要件のセキュリティ技術の種別の違い、想定するセキュリティ課題の違いや、セキュリティで重視される機密性、完全性、可用性の違いによる派生、継承方法などである。
【００４６】
なおここで、従来におけるセキュリティ対策の支援、評価においては、図５に示すような部分的な対策手段のみを考慮していた。図５の従来における対策手段とは、対策手段の種別として例えばアクセス制御、暗号化、権限管理がある場合に、対策手段として方式Ａ、Ｂ、Ｃ、Ｄなどを固定的に定めた方式である。そのため、規格を達成しているかといった解析処理を実行する上で属性が不足する場合（例えば、更新周期や要件確認方法など）が生じる。さらに、各規格の属性を包含した共通のデータ属性で表現されていないために、複数のセキュリティ規格に対して解析処理を実行することができないというものであった。
【００４７】
本発明では、図４の表に示す要件データ構造を採用することにより、セキュリティ規格に対する解析処理を実行する上で必要な属性Ｊを備え、さらに複数のセキュリティ規格に対する属性Ｊを包含することで、複数のセキュリティ規格を対象とした解析処理（比較処理や差分の抽出など）が可能である。加えて、要件データ構造の派生、継承を可能とすることで規格改定に対応することが可能である。
【００４８】
規格データＤ１に属性を付与して規格データＤ２とする点について具体的に例示したものが図６である。図６において、例えば図２の通信システムが順守すべきセキュリティ規格や、ガイドラインが、Ｒ１，Ｒ２，Ｒ３であったとする。このうち規格Ｒ１は、暗号化Ｋ１１と定期的更新周期Ｋ２２と所定セキュリティ対策の実装率Ｋ５３の属性値を含む要件データＤ１１の集合Ｄ１１（Ｒ１）である。規格Ｒ２は、機密性Ｋ６３と外部接続ありＫ８２とソフトウェアＫ９３の属性値を含む要件データＤ１１の集合Ｄ１１（Ｒ２）である。また規格Ｒ３は、アクセス制御方式Ｋ１２と定義文章の有無Ｋ４１と暗号鍵ビット長Ｋ５２の属性値を含む要件データＤ１１の集合Ｄ１１（Ｒ３）である。
【００４９】
従来では、これらの属性値Ｋは規格Ｒ１，Ｒ２，Ｒ３ごとに個別管理されているので、相互の関係は把握し難いものであったが、本発明では属性Ｊの観点から整理される。図６の例では、セキュリティ技術種別Ｊ１の観点から暗号化Ｋ１１とアクセス制御方式Ｋ１２が同じ範疇に整理され、評価指数Ｊ５の観点から暗号鍵ビット長Ｋ５２と所定セキュリティ対策の実装率Ｋ５３が同じ範疇に整理される。そのほか、更新周期Ｊ２について定期的Ｋ２２、要件確認方法Ｊ４について手順定義文章の有無Ｋ４１、寄与する性質Ｊ６について機密性Ｋ６３、システムのオープン性Ｊ８について外部接続ありＫ８２、対象Ｊ９についてソフトウェアＫ９３の区別が含まれる規格形式に整理されることになる。
【００５０】
この場合に、属性Ｊは予め定めておき、各属性値Ｋが新規に設定、入力される都度、いずれかの属性Ｊに含むものとして整理すればよい。また最初に定義した属性Ｊに含めることが困難或はふさわしくないという場合には、属性Ｊを再度整理し、あるいは新規に属性を追加して属性値Ｋをその属性に定義するものとしてもよい。
【００５１】
なお、図４の表の要件データ構造の定義や、その派生構造の定義は後述する図９に示す手順にて実行し、実際の属性値Ｋを設定して、セキュリティ規格に対する要件データの定義は図１０に示す手順にて実行する。要件データ構造記憶部１３０は、これらの要件データ構造の集合を記憶する。
【００５２】
次に、対策データＤ３、Ｄ４と、その処理内容について説明する。図７は、対策データ構造記憶部１３４に記憶される対策データ構造例を示す図である。
【００５３】
図７の対策データ構造例においても、図４の要件データ構造と同様に属性Ｍと属性値Ｎを備えている。この例では、パスワードの暗号化方式Ｍ１、パスワードのパスワード長Ｍ２、パスワードの設定日Ｍ３、認証について認証方式Ｍ４，暗号化通信について通信方式Ｍ５が属性Ｍとして設定されている。さらにパスワードの暗号化方式Ｍ１の属性値Ｎ１として「ＭＤ５」が、パスワードのパスワード長Ｍ２の属性値Ｎ２として「１２文字」が、パスワードの設定日Ｍ３の属性値Ｎ３として「２０１５／０１／０１」が、認証について認証方式Ｍ４の属性値Ｎ４として「Ｋｅｒｂｅｒｏｓ認証」が，暗号化通信について通信方式Ｍ５の属性値Ｎ５として「ＩＰｓｅｃ」が設定されている。
【００５４】
この対策データ構造例も、要件データ構造と同様に予め想定可能な属性Ｍと属性値Ｎの関係が組み合わせとして記憶されている。従って、対策データＤ３として新たな対策が入力され、それが例えば「ＭＤ５」であったとするなら、既存の対策データ構造を参照して暗号化方式Ｍ１を属性とする範疇に登録されることになる。また対策データＤ３として新たな対策が入力され、それが例えば「ＭＤ５」であり、「ＭＤ５」が既存の対策データ構造を参照しても存在していないというような場合には、既存の属性Ｍの中から適切と思われる属性を選択して、例えば暗号化方式Ｍ１に登録し、あるいは「ＭＤ５」にふさわしい新たな属性Ｍを新規に設定する。これら一連の処理を含めて対策データ構造は、新たな対策データＤ３を反映した進化するデータ構造を形成していく。
【００５５】
而して対策データ構造記憶部１３４から取り出される対策データＤ４は、対策内容である属性値Ｎとその属性Ｍを含んで形成されたデータである。
【００５６】
以上説明したように、対策データ構造は、セキュリティ対策を表わす属性Ｍを備えたデータ構造である。対策データ構造は、少なくとも規格データ解析部１３３の定める解析処理を、要件データ構造記憶部１３０で定義する要件データ構造に対して実行する上で必要な属性Ｍ、対策処理Ｎをそなえる。対策データ構造についても、属性Ｍや対策処理Ｎを追加することで派生対策データ構造を定義してもよい。
【００５７】
全ての派生対策データ構造を基本対策データ構造から派生させることで、全ての対策に共通する属性、処理を全ての対策データ構造がそなえていることを保証できる。
【００５８】
対策データ構造の属性値Ｎについて説明する。属性値Ｎの取り得る値が決まっている場合、それらの属性値Ｎを別途定義し、データ化に際して、該当する定義値Ｎを選択する。あるいは、属性値Ｎには型を定義してもよい。例えば、属性値Ｎが数値である場合、属性値Ｎを数値型としてもよいし、真理値をとる場合、属性値Ｎを論理型としてもよい。あるいは属性値Ｎを定義できないことを示す特別な値を定義してもよい。これは例えば、対策データにおける該当属性Ｍが未定義であることを示す。あるいは明示的に未定義であることを示す属性値Ｎを定義してもよい。未定義と、明示的な未定義を区別することで、データ化手順において、ユーザが誤って属性値Ｎを定義しなかった場合と、意図的に属性値Ｎを定義しなかった場合を区別することができる。また、既存の対策データ構造において、所定の解析処理に不要な属性Ｍの値Ｎを明示的な未定義にすることで、対策データ構造の種類を制限することができ、対策データ構造の選択を容易にすることや、対策データ構造記憶部１３４の計算機資源（演算能力や記憶容量等）を抑えることができる。
【００５９】
これらの属性値Ｎの定義により、より厳密な対策データの定義が可能である。例えば、選択肢でない属性値Ｎを定義した場合や、数値型である属性値Ｎに対して、文字列を設定した場合に、対策データ構造を利用するユーザに対して、注意、警告を発し、データ化を正確にすることができる。
【００６０】
なお対策データ構造記憶部１３４は、対策データ構造を記憶する。また対策データＤ４は、対策データ構造記憶部１３４で記憶する対策データ構造の、属性Ｍ，属性値Ｎを定義したデータである。対策データ記憶部１３６は、対策データの集合を記憶する。
【００６１】
次に本発明における処理内容を具体的なフローチャートで説明する。図８は、本発明における実行手順の種別を示したものである。実行手順について、合計５つのプログラムＰｒが準備されている。
【００６２】
このうち、要件データ構造の定義手順プログラムＰｒ１と、規格データの定義手順プログラムＰｒ２は、大別した第１の機能である規格データ処理機能１００における処理であり、対策データ構造の定義手順プログラムＰｒ３と、対策データの定義手順プログラムＰｒ４は、大別した第２の機能である対策データ処理機能３００における処理であり、解析処理の実行手順プログラムＰｒ５は大別した第３の機能である解析処理機能３００における処理である。
【００６３】
以下、各手順プログラムについて説明するが、システム構成を示す図１において、要件データ構造をデータベースＤＢｃに記憶させるための方法（入力装置、入力ソフトウェア等）、及び対策データ構造をデータベースＤＢａに記憶させるための方法（入力装置、入力ソフトウェア等）は図示を省略している。
【００６４】
まず要件データ構造の定義手順プログラムＰｒ１について、図９で説明する。図９の処理では、はじめに処理ステップＳ１０１において要件データ構造を定義する。これは、要件データＤ１１について、図４に示した属性Ｊと属性値Ｋの関係を一覧にして、要件データ構造記憶部１３０に記録することを意味している。
【００６５】
次に処理ステップＳ１０２では、本システムの運用にあたり、図４の要件データ構造を変更する必要があるかを判定する。例えば、対応すべき規格やガイドラインに変更が生じる場合や、新たな規格、ガイドラインに対応する場合に、既存の要件データ構造で要件を表現できない場合がこれに該当する。なお以下の説明において、単に要件というときには、属性値Ｋを含んだ要件データＤ１１を意味している。
【００６６】
要件データ構造を変更する必要がある場合（処理ステップＳ１０２のＹ）は、処理ステップＳ１０３に移り、要件データ構造を変更する。必要ない場合（処理ステップＳ１０２のＮ）、ならびに処理ステップＳ１０３で要件データ構造を変更した後は、処理ステップＳ１０１へ戻る。なお当該処理は、全ての変更が反映されるまで継続実施されるものとする。
【００６７】
なお具体的な変更としては、新規属性Ｊの追加、新規属性値Ｋの追加、既存属性Ｊの変更が例示される。既存属性Ｊ、既存属性値Ｋが使用されなくなった場合は、属性Ｊ、属性値Ｋを削除してもよい。なお、新たな規格やガイドラインに対応する場合であっても、既存の要件データ構造で表現できる場合は要件データ構造を変更する必要はない。
【００６８】
次に、規格データの定義手順プログラムＰｒ２について、図１０で説明する。図１０の処理では、はじめに処理ステップＳ２０１において図３の規格に関する情報Ｄ１２（規格名称、規格発行日など）を定義する。なお、規格に関する情報Ｄ１２に関しては、値をそのまま定義してもよいし、値の種類、性質を表す情報と値を対に定義してもよい。例えば、規格発行日が２０１５年１月１日である場合に、前者では「２０１５年１月１日」という情報だけを定義し、後者では「規格発行日」と「２０１５年１月１日」という対の情報を定義する。
【００６９】
次に処理ステップＳ２０２では、必要な要件を全てデータ化したか判定する。基本的には、全ての要件をデータ化すべきであるが、例えば目的とする処理にとって不要な要件であればデータ化の必要はない。あるいは要件データ構造記憶部１３０で記憶する要件データ構造でデータ化できない要件の場合もデータ化の必要はない。このような場合には、ユーザに対して、データ化できないことを注意、警告してもよい。
【００７０】
なお以下の説明においては、図６の例を念頭において説明する。具体的には要件データ構造として図６の属性Ｊ、属性値Ｋのものが予め定義されており、ここでは規格Ｒ１，Ｒ２に示した属性値についてすでに反映されており、新たな規格としてＲ３を今から処理する場面を想定しているものとする。
【００７１】
処理ステップＳ２０２の判断で、必要な要件（上記例ではアクセス制御方式Ｋ１２、手順定義文章の有無Ｋ４１、暗号鍵ビット長Ｋ５２）を全てデータ化していなければ（処理ステップＳ２０２のＮ）、処理ステップＳ２０３においてデータ化すべき要件の中から１つ（例えばアクセス制御方式Ｋ１２）を選択する。このときに選択する要件は、要件間に因果関係がなければ、どの要件からでも構わない。ただし、要件間に因果関係が存在する場合は、前提となる要件を先に選択してもよいし、処理ステップＳ２０５において後述する要件データ構造の変更処理のために、他の要件に影響する要件を後に選択してもよい。
【００７２】
処理ステップＳ２０４では、該要件（アクセス制御方式Ｋ１２）に対して、要件データ構造記憶部１３０で記憶される要件データ構造の中から適切な要件データ構造を選択する。適切な要件データ構造とは、該要件（アクセス制御方式Ｋ１２）を表現する属性Ｊを全てそなえた要件データ構造である。なお要件データ構造が解析処理を定義に含む場合、該要件が対象となる解析処理をそなえた要件データ構造が望ましい。図６の例では、要件（アクセス制御方式Ｋ１２）に対応して選択される属性Ｊはセキュリティ技術種別Ｊ１である。
【００７３】
次に、必要があれば処理ステップＳ２０５において、処理ステップＳ２０４で選択した要件データ構造を変更する。例えば、属性値Ｋを所定の選択肢の中から選択して決定する場合、規格によって、選択肢が定義されている場合である。あるいは、要件データ構造の定義においては、属性値Ｋが数値であっても、規格によって、取り得る数値の選択肢が定義されている場合である。このような場合に要件データ構造を変更する。あるいは、ある要件Ａが、他のひとつ、または複数の要件Ｂ群に影響する場合、要件Ａに係わる属性値Ｋあるいは解析処理を要件Ｂ群に追加してもよい。例えば、「要件Ｂ１からＢｎの要件は、少なくとも１年毎に見直すこと」という要件Ａが存在する場合に、１年という期間を識別するために、時間に関する属性Ｋ（例えば、前回更新日時、あるいは更新までの残り日数、更新周期等）や、「更新までの残り日数が所定日数を切ったか」という解析処理を要件Ｂ１からＢｎの要件データに加えてもよい。
【００７４】
次に処理ステップＳ２０６では、要件データ構造の属性値Ｋに対して、規格、ガイドラインに定義されている情報から、属性値Ｋを定義し、要件をデータ化する。この時、解析処理に影響がなければ、属性値Ｋを定義できない属性Ｊに対して、未定義を示す特殊な値を定義してもよい。属性値Ｋを定義できない属性Ｊがある場合は、ユーザに注意、警告してもよい。
【００７５】
次に、処理ステップＳ２０７において、要件データに関する管理情報があれば、要件データに含める。あるいは、該管理情報と要件データを対にして管理してもよい。管理情報としては、規格内における該要件の参照情報や、該要件が最初に定義された規格のバージョン情報、該要件が変更された規格のバージョン情報や変更内容、策定者、策定組織、策定理由、策定に係わる会議録、議事録、あるいは、これらの情報に対する参照が例示される。
【００７６】
処理ステップＳ２０７を実行後、処理ステップＳ２０２へ戻る。処理ステップＳ２０２にて、必要な要件が全てデータ化していれば（処理ステップＳ２０２のＹ）、処理ステップＳ２０８において、定義した規格データを規格データ記憶部１３２に記憶する。
【００７７】
なお規格データＤ２の作成は、ある規格、ガイドラインの特定のバージョンごとに作成することが望ましい。これにより、バージョンごとに別個に規格データＤ２を作成することで、バージョンの違いによる差分処理が可能となるためである。あるいは、特定の規格に対して、バージョンごとに規格を修正し、差分情報を規格に関する情報として管理してもよい。あるいはバージョン間の差分を独立した規格データとしてもよい。なお、処理ステップＳ２０１の手順は処理ステップＳ２０８の前、あるいは後に実行してもよい。
【００７８】
なお、図８の処理ステップＳ２０３から処理ステップＳ２０７は、ユーザが手動で実行してもよいし、規格書やガイドラインの電子文書を解析（字句解析、構文解析、意味解析など）して、自動で実行してもよい。また、自動実行後にユーザが確認して修正してもよい。
【００７９】
対策データ構造の定義手順プログラムＰｒ３について、図１１を参照して説明する。
【００８０】
ここでは、はじめに処理ステップＳ３０１において、対策データ構造を定義する。処理ステップＳ３０２では、本システムの運用にあたり、例えば図７に例示された対策データ構造を変更する必要があるかを判定する。例えば、新たなセキュリティ対策を採用した場合に、既存の対策データ構造でセキュリティ対策を表現できない場合が該当する。なお、既存の対策データ構造で表現できる場合は、新たなセキュリティ対策であっても、対策データ構造を変更する必要はない。
【００８１】
対策データ構造を変更する必要がある場合（処理ステップＳ３０２のＹ）は、処理ステップＳ３０３において対策データ構造を変更する。変更としては、新規属性の追加、新規属性値の追加、既存属性の変更、既存属性値の変更が例示される。既存属性が使用されなくなった場合は属性を削除してもよい。必要ない場合（処理ステップＳ３０２のＮ）、ならびに処理ステップＳ３０３で対策データ構造を変更した後は、処理ステップＳ３０１へ戻る。
【００８２】
対策データの定義手順プログラムＰｒ４について、図１２を参照して説明する。
【００８３】
ここでは、はじめに処理ステップＳ４０１において、対象システム（装置、ソフトウェア含む）に関する情報を定義する。対象システムに関する情報としては、システム名称、システムに関する開発、運用、保守等のスケジュール（開始日、終了日、期間等）、実行者、関係者、ユーザに関する情報、適用サイトの情報、適用規模に関する情報、監査者に関する情報等が例示される。なお、対象システムに関する情報は、値をそのまま定義してもよいし、値の種類、性質を表す情報と値を対に定義してもよい。
【００８４】
次に処理ステップＳ４０２において、実施するセキュリティ対策（対策データＤ３の属性値Ｎ）を全てデータ化したかを判定する。全てデータ化していなければ（処理ステップＳ４０２のＮ）、処理ステップＳ４０３において、１つのセキュリティ対策を選択する。選択する対策は、対策間に因果関係がなければ、どの対策からでも構わない。ただし、対策間に因果関係が存在する場合は、前提となる対策を先に選択してもよい。
【００８５】
次に、処理ステップＳ４０４において、該対策に対して対策データ構造記憶部１３４で記憶される対策データ構造の中から適切な対策データ構造を選択する。適切な対策データ構造とは、該対策を表現する属性Ｍを全てそなえた対策データ構造である。あるいは、解析処理において、要件データ構造から対策データ構造が参照される場合は、解析処理において利用される処理をそなえた対策データ構造が望ましい。
【００８６】
次に、処理ステップＳ４０５において、選択した対策データ構造の属性値Ｎに対して、実施するセキュリティ対策の情報から属性値Ｎを定義し、対策をデータ化する。この時、解析処理に影響がなければ、属性値Ｎを定義できない属性Ｍに対して、未定義を示す特殊な値を定義してもよい。属性値Ｎを定義できない属性Ｊがある場合は、ユーザに注意、警告してもよい。
【００８７】
次に、処理ステップＳ４０６において、対策データに関する管理情報があれば、対策データに含める。あるいは、該管理情報と対策データを対にして管理してもよい。管理情報としては、案件内における該対策の参照情報（管理番号）や、該対策のバージョン情報、実行者、対策適用理由が例示される。
【００８８】
処理ステップＳ４０６の実行後、処理ステップＳ４０２へ戻る。処理ステップＳ４０２にて、必要な対策が全てデータ化していれば（処理ステップＳ４０２のＹ）、処理ステップＳ４０７において、定義した対策データを対策データ記憶部１３６に記憶する。
【００８９】
対策データＤ２の作成は、対象システムごとに作成することが望ましい。対象システムの運用中に、対策を変更した場合は、その変更にあわせて対策データを変更してもよい。このとき、対策時期、対策理由、変更内容を対策に関する管理情報として記憶してもよい。
【００９０】
なお、処理ステップＳ４０４、処理ステップＳ４０５の手順を独立して実行し、対策データを単独で対策データ記憶部１３６に記憶してもよい。この場合、図１２の手順の実行では、処理ステップＳ４０４、処理ステップＳ４０５のかわりに該対策データを選択することが例示される。また、処理ステップＳ４０１の実行手順は、処理ステップＳ４０７の前、あるいは後に実行してもよい。
【００９１】
また図１２の処理ステップＳ４０５は、ユーザが明示的に手動で実行してもよいし、対策手段を所定の形式で自動収集し、その結果を用いてデータ化してもよい。そのような手段としてＳＣＡＰ（Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔｅｎｔ  Ａｕｔｏｍａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）やＸＭＬなどの電子フォーマットを利用してもよい。独自にフォーマットを定めてもよく、その場合は属性名称と属性値を含むことが例示される。これらの自動収集は定期的に実行することや所定の事象が発生した場合に実行することが例示される。対策データのデータ化を自動実行することで、容易、かつ、運用中のシステムの実体に即したデータ化が可能である。なお、自動実行した結果に対してユーザが修正してもよい。
【００９２】
対策データの定義手順プログラムＰｒ４の代替案について図１３を用いて説明する。この代替方式は、装置、ソフトウェアによる対策データの指定を行うものである。ここでは、対策データを直接対象システムに関連付けるのではなく、所定の装置、ソフトウェアに対策データを関連付ける方法である。
【００９３】
図１３の処理では、はじめに処理ステップＳ４１１において、これから定義する装置、ソフトウェアが新規であることを判定する。新規かどうかの判定基準は、該当する装置、ソフトウェアが対策データ記憶部１３６に記憶されていなければ新規であると判定することが例示される。
【００９４】
新規であれば（処理ステップＳ４１１のＹ）、処理ステップＳ４１２において、装置、ソフトウェアのデータを新たに定義する。データの定義とは、例えば、対策データ記憶部１３６にデータ保存領域を新規に確保する等の処理である。
【００９５】
続いて処理ステップＳ４１３において、装置、ソフトウェアに関する情報を定義する。そのような情報としては、装置、ソフトウェアの名称やバージョンに関する情報、種類、製品であれば発売年月日、発売価格、発売元に関する情報、開発品であれば開発時期が例示される。さらに、装置であれば、サイズ、重量、耐環境性能、計算機仕様が例示され、ソフトウェアであれば、バイナリ容量、実行動作環境（オペレーティングシステムの種類とバージョン）、ＣＰＵの演算性能、メモリ容量、ハードディスク等の記憶容量、実行性能等が例示される。
【００９６】
処理ステップＳ４１３の実行後、あるいは処理ステップＳ４１１でＮの場合は、処理ステップＳ４０４、処理ステップＳ４０５を実行する。処理ステップＳ４０４、処理ステップＳ４０５の処理内容は、図１２で説明したものと同じであるので、その説明を割愛する。その後処理ステップＳ４１４において、装置、ソフトウェアデータに対策データを関連付ける。そして処理ステップＳ４１５において、装置、ソフトウェアデータを対策データ記憶部１３６に記憶する。
【００９７】
図１３に示す手順は、装置、ソフトウェアデータと対策データの関係が１対１であるが、それぞれ複数の対応関係になり得る。例えば、ひとつの装置、ソフトウェアが複数のセキュリティ対策を実行できるのであれば、一つの装置、ソフトウェアデータに対して複数の対策データが対応し得る。その場合、１つの装置、ソフトウェアデータに対して、図１３の実行手順を複数回実行する。
【００９８】
同様に、複数の装置、ソフトウェアデータが一つの対策データに対応し得る。この場合、各装置、ソフトウェアデータが単独で、ある対策を実現するのであれば、同じ内容であっても別個の対策データに関連付けることが例示される。
【００９９】
あるいは、複数の装置、ソフトウェアによって、はじめて、ある対策が実現し得るのであれば、複数の装置、ソフトウェアデータをひとつの対策データに関連付けることが例示される。これらの関係はデータの対応関係による表現ではなく、対応関係そのものを表す情報を装置、ソフトウェアデータ、または対策データのいずれか、あるいは両方に定義してもよい。
【０１００】
図１３による装置、ソフトウェアデータを定義した場合、図１２の実行手順において、処理ステップＳ４０４、処理ステップＳ４０５の代わりに、装置、ソフトウェアデータを選択してもよい。また、装置、ソフトウェアを指定する場合でも、指定後に選択された対策データを修正してもよい。
【０１０１】
さらに図１３における処理では、以下の代替案とすることも可能である。これは、規格による対策データの指定を行うものである。
【０１０２】
図１３に示す手順では、装置、ソフトウェアデータを対策データと関連付けていたが、装置、ソフトウェアではなく、別の規格、ガイドラインと対策データを関連付けてもよい。これは図１３に示すように、明示的に規格と対策データを関連付けてもよいし、規格を表す規格データの要件データを満足する対策データを関連付けてもよい。この場合、要件データはデフォルトの対策データを取得する処理をそなえることが例示される。あるいは、すでに対策データを関連付けた登録済みの規格データの対策データを関連付けてもよい。
【０１０３】
また、ひとつの規格データに対して複数の対策データを関連付けることが例示される。規格の指定により、対策データを指定する場合は、図１２の処理ステップＳ４０４、処理ステップＳ４０５の代わりに、規格を選択することが例示される。また、規格を指定する場合でも、指定後に選択された対策データを修正してもよい。
【０１０４】
以上、図１１から図１３を用いて説明した対策データについての各種プログラムの実行により、ここまでの手順において、対策データ構造記憶部１３４に記憶され得る情報としては、以下の種類がある。
【０１０５】
これらは、図１２の手順により得られた対象システムに対する対策データＤ３Ａ、図１２の処理ステップＳ４０４、処理ステップＳ４０５の手順により得られた個別の対策データＤ３Ｂ、装置、図１３の手順により得られたソフトウェアデータＤ３Ｃ、規格に関連付けられた対策データＤ３Ｄなどである。
【０１０６】
したがって、対策データ構造記憶部１３４に記憶される、これらの種類を識別可能としておくことが以後の処理や、判断に有効である。これらについては、それぞれのデータ（対策データあるいは、管理情報と対に管理する対策データ）を別のデータ型としてもよいし、データの種類を表す情報をあわせて定義してもよい。あるいは、対策データ構造記憶部１３４の実現手段であるデータベース自体を別個としてもよい。
【０１０７】
次に解析処理の実行手順プログラムＰｒ５について、図１４を用いて説明する。解析処理の実行手順プログラムＰｒ５は、特定の規格、あるいはその特定の要件に対して実行する手順である。
【０１０８】
図１４の処理では、はじめに処理ステップＳ５０１において、必要な規格データＤ１を処理したかどうかを判定する。必要な規格データＤ１とは、ある対象システムの対応において、順守、準拠すべき規格、ガイドラインかどうか、あるいは満足したい規格、ガイドラインであるかを判定する。
【０１０９】
必要な規格データを処理していなければ（処理ステップＳ５０１のＮ）、処理ステップＳ５０２において、処理する規格データを選択する。規格データの選択においては、前述のとおり、対象システムの対応にあたって、順守、準拠すべき規格、ガイドラインであるかという基準で選択する。あるいは、対応する対象システムの属性において、選択してもよい。例えば、所定の地域においては、特定の規格やガイドラインが強制、推奨される場合がある。したがって、地域属性によって、規格データを選択する。あるいはユーザ自身の属性によって、適用が強制、推奨される規格、ガイドラインも存在する。したがって、ユーザの属性によって規格データを選択する。これ以外にも、システム規模やシステムの構築時期、運用時期、用途、目的等が例示される。
【０１１０】
次に処理ステップＳ５０３では、必要な要件データを全て処理したかを判定する。基本的には、処理ステップＳ５０２で選択された規格の全ての要件を処理すべきであるが、解析処理内容によっては不要な要件については処理する必要はない。
【０１１１】
必要な要件を全て処理していなければ（処理ステップＳ５０３のＮ）、処理ステップＳ５０４において要件データを選択し、処理ステップＳ５０５において選択した要件データを処理する。処理ステップＳ５０５の要件データの処理内容については後述する。その後、処理ステップＳ５０１へ戻る。
【０１１２】
なお処理ステップＳ５０３において、全ての要件データを処理していれば（処理ステップＳ５０３のＹ）、処理ステップＳ５０１に戻る。処理ステップＳ５０１において、必要な規格データを全て処理していれば（処理ステップＳ５０１のＹ）、処理ステップＳ５０６において、解析結果を出力する。
【０１１３】
ここで、解析結果の出力とは、ＨＭＩ（Ｈｕｍａｎ  Ｍａｃｈｉｎｅ  Ｉｎｔｅｒｆａｃｅ）等のモニターへの出力や、電子メールによる所定宛先への通知、電子ファイルとしての保存や、ＬＥＤの点灯、音声出力等の外部出力が例示される。なお、処理ステップＳ５０６の解析結果出力は、処理ステップＳ５０５の要件データ処理ごとに随時更新出力してもよい。また、所定形式の電子ファイルとしての保存、文章としての印刷、出力することにより、所定規格、ガイドラインの順守、準拠の証明、証拠として活用することができる。
【０１１４】
図１５を用いて、図１４の処理ステップＳ５０５の処理（各要件データの処理内容）について説明する。各要件データは、他の要件データあるいは対策データとあわせて処理され得る。
【０１１５】
そこで図１５の処理では、はじめに処理ステップＳ５６０において、要件データを処理する必要があるかを判定する。必要があれば（処理ステップＳ５６０のＹ）、処理ステップＳ５６１において、該当する要件データが存在するかを判定する。要件データが存在するかどうかは解析内容に依存する。例えば、全ての要件を確認するという解析内容であれば、要件データが存在する限り、処理ステップＳ５６１はＹとなる。一方で、所定の属性値を持つ要件データを検索するという解析内容であれば、該当する要件データが存在しない場合（検索の結果、見つからなかった場合）がある。
【０１１６】
処理ステップＳ５６１で、存在すると判断された場合は（処理ステップＳ５６１のＹ）、処理ステップＳ５６２において、該当する要件データを選択し、処理を実行する。該当する要件データは、ひとつ、または複数であり、図１４の処理ステップＳ５０２で選択された同じ規格データの場合もあれば、異なる規格データの場合もある。
【０１１７】
処理ステップＳ５６１で存在しないと判断した場合は（処理ステップＳ５６１のＮ）、処理ステップＳ５６３において、所定のエラー処理を実行する。エラー処理は解析内容に依存するが、該当する要件データが見つからなかったことを出力してもよい。
【０１１８】
次に、処理ステップＳ５６４において、対策データを処理する必要があるかを判定する。処理する必要があれば（処理ステップＳ５６４のＹ）、処理ステップＳ５６５において、該当する対策データが存在するかを判定する。対策データが存在するかどうかは解析内容に依存する。なお対策データ処理の必要性判定は、処理ステップＳ５６０のN(要件データ処理の必要なし)、処理ステップＳ５６３（要件データエラー処理）、処理ステップＳ５６２（要件データ処理完了)のいずれかの処理、あるいは判断後に実行される。
【０１１９】
処理ステップＳ５６５で存在すると判断される場合は（処理ステップＳ５６５のＹ）、処理ステップＳ５６６において、該当する対策データを選択し、処理を実行する。該当する対策データはひとつ、または複数である。
【０１２０】
処理ステップＳ５６５で存在しないと判断される場合は（処理ステップＳ５６５のＮ）、処理ステップＳ５６７において、所定のエラー処理を実行する。エラー処理は解析内容に依存するが、該当する対策データが見つからなかったことを出力してもよい。
【０１２１】
最後に、処理ステップＳ５６８において、要件データ単独で可能、かつ、必要な処理を実行する。なお、処理ステップＳ５６０、処理ステップＳ５６１、処理ステップＳ５６２、処理ステップＳ５６３の手順、および処理ステップＳ５６４、処理ステップＳ５６５、処理ステップＳ５６６、処理ステップＳ５６７の手順は、どちらを先に実行しても構わない。
【０１２２】
また、処理ステップＳ５６６において、要件データに関連する対策データがある場合、要件データとあわせて対策データを規格データ記憶部１３２に記憶してもよい。そのようにすることで、他の解析処理への応用が可能であることや、次回以降の対策データの検索処理を省略して、解析処理を速めることが可能である。この場合、要件データ構造もしくは要件データは、関連する対策データを取得する処理をそなえることが例示される。要件データに関連付ける対策データは複数でもよいし、その関連性を示す情報（例えば、「本要件を満足する対策」）とあわせて関連付けてもよい。
【０１２３】
図１６には、図１４の処理ステップＳ５０５の処理（各要件データの処理内容）のさらなる代替案について記載している。この内容は、対策データを中心とする解析処理の実行手順を示したものである。規格データまたは要件データに対する処理を示す図１５に対し、図１６に示す手順は対策データに対する処理を示している。
【０１２４】
はじめに処理ステップＳ５７０では、必要な対策データを全て処理したかを判定する。処理していなければ（処理ステップＳ５７０のＮ）、処理ステップＳ５７１において対策データを選択する。
【０１２５】
処理ステップＳ５７２において、次に必要な規格データを処理したかを判定する。処理していなければ（処理ステップＳ５７２のＮ）、処理ステップＳ５７３において規格データを選択する。
【０１２６】
続いて、処理ステップＳ５７４において、必要な要件データを処理したかを判定する。処理していなければ（処理ステップＳ５７４のＮ）、処理ステップＳ５７５において、要件データを選択する。そして、処理ステップＳ５７６では、選択した要件データとあわせて、処理ステップＳ５７１で選択した対策データを処理する。その後、処理ステップＳ５７４へ戻る。
【０１２７】
処理ステップＳ５７４にて、必要な要件データを処理していれば（処理ステップＳ５７４のＹ）、処理ステップＳ５７２へ戻る。処理ステップＳ５７２で、必要な規格データを処理していれば、処理ステップＳ５７０へ戻る。処理ステップＳ５７０にて、必要な対策データを処理していれば（処理ステップＳ５７０のＹ）、処理ステップＳ５５５において解析処理結果を出力し、終了する。
【０１２８】
以下、解析手順の事例について、具体例をもって説明する。なお以下の解析処理を具体例にして、図１４、図１５、図１６に示す手順を説明する。
【０１２９】
解析手順具体例では、以下の処理１から処理１０が、図１４、図１５、図１６に示す手順の、どのような流れに沿って実行されるのかを具体的に説明する。
処理１：要件を確認する。
処理２：対策が要件を満足しているかを判定する。
処理３：所定期間内に更新対応すべき要件を提示する。
処理４：対象システムの各フェーズにおける要件を確認する。
処理５：より強固なセキュリティ対策を提示する。ある対策が与える影響を判定する。
処理６：追加で他の規格に対応する場合の追加の対策を提示する。
処理７：規格改定時の差分を確認する。
処理８：あるサービス、装置が他のサービス、装置と通信する際に、通信相手のセキュリティレベルを確認する。
処理９：装置の設計時の推奨要件を提示する。
処理１０：所定の対策手段が寄与するセキュリティ規格の要件を提示する。
【０１３０】
上記各処理１〜１０の実行手順について、さらに詳述する。まず、「処理１：要件を確認する」について説明する。
【０１３１】
最も基本的な解析処理は、要件の確認である。この場合には、図１４の処理ステップＳ５０２において、ユーザが明示的に規格、ガイドラインを指定するか、あるいは対象システムの属性Ｊにしたがって、規格データＤ２を選択する（以下の具体例においても、規格、ガイドラインの選択は同様である）。これを受けて、次に図１４の処理ステップＳ５０３、処理ステップＳ５０４、処理ステップＳ５０５、図１５の処理ステップＳ５６８において、全ての要件が選択され、その要件の内容が出力される（例えば、モニターへの表示）。この時、要件データ構造の属性Ｊの中から、出力対象を選択してもよい。あるいは、要件データ構造の属性値Ｋをもとに、出力対象を選択してもよい。要件データ構造が解析処理をそなえる場合、属性値Ｋを出力する解析処理が例示される。なおこの処理１のケースでは、他の要件データＤ１１、対策データＤ４とあわせて処理する必要はないため、図１５の処理ステップＳ５６０、処理ステップＳ５６４はいずれもＮとなり、処理ステップＳ５６２、処理ステップＳ５６６は省略され、処理ステップＳ５６８における要件データ処理のみが実行される。
【０１３２】
次に、「処理２：対策が要件を満足しているか」について説明する。
【０１３３】
この処理２は、対象システムに講じた対策が、対象の規格、ガイドラインを満足するか、あるいは対象の規格の要件が全て満足しているかを判定する例を示す。図１４の処理ステップＳ５０３、処理ステップＳ５０４では、基本的に全ての要件データＤ１１が選択され、処理される。この場合、他の要件データＤ１１とあわせて処理する必要が無いため、図１５の処理ステップＳ５６０ではＮとなり、処理ステップＳ５６２は省略される。対策データＤ４は処理されるため、処理ステップＳ５６４はＹとなり、処理ステップＳ５６５が実行される。
【０１３４】
図１５の処理ステップＳ５６５でＹであれば、処理ステップＳ５６６においては、選択される要件データＤ１１で定義される要件を満足する対策データＤ４が選択される（要件を満足する対策データＤ４を検索する）。このとき、要件データ構造は、指定される対策データＤ４をもとに自身の要件が満足するか否かを判定する処理をそなえてもよい。
【０１３５】
例えば、要件が「パスワード長が所定文字数以上でなければならない」であった場合に、対策データＤ４にパスワード長を取得する処理をもうけ、要件データＤ１１は対策データＤ４のパスワード長が所定しきい値以上の場合に要件満足と判定する処理をもうけることが例示される。なお、対策データＤ４がパスワードに関する対策でない場合は、０を取得することや、無効であることを示す特別な値を取得すること、あるいは対策データ自身がパスワード関連でないことを示すようにしてもよい。以上は、要件がパスワードの場合であるが、他の要件においても同様の実装が例示される。
【０１３６】
該要件データＤ１１を満足する対策データＤ４が存在すれば、処理ステップＳ５６６は終了する。結果として、該要件は満足されること、該要件を満足する対策データＤ４が結果として出力される。なお、該要件を満足する対策データＤ４が複数存在する可能性があり、その全て、あるいは複数を確認する必要がある場合は、全ての対策データＤ４について処理する。一方、該要件を満足するか否かのみが重要であれば、最初に該要件を満足する対策データＤ４が見つかった時点で終了する。
【０１３７】
該要件を満足する対策データが見つからなければ、処理ステップＳ５６７のエラー処理として、該要件データＤ１１を未達成の要件として提示することや、該要件を満足するための推奨対策を提示することが例示される。後者の場合、該要件データＤ１１は推奨対策を提示する処理をそなえていることが例示される。
【０１３８】
図１５の処理ステップＳ５０６において、これらの出力結果により、ユーザは満足している条件とそれに寄与する対策、満足していない要件、満足していない場合に推奨される対策を確認することができる。したがって、システム、装置、ソフトウェアをセキュリティ規格、ガイドラインに順守、準拠させて、セキュアに構築することができる。
【０１３９】
次に、「処理３：所定期間内に更新すべき要件を提示する」について説明する。
【０１４０】
ここでは、システム、装置、ソフトウェア、サービスの運用中等に定期的、あるいは所定の期限までに更新する必要のある要件を確認する例を示す。図１４の処理ステップＳ５０２で選択された規格データＤ２の中から、更新期間を有する要件データＤ１１を選択する。更新期限を有する要件データＤ１１かどうかは、要件データＤ１１が更新期限に関する属性Ｋを有しているかどうかで判断することや、要件データ構造そのものに更新期限を有することを意味づけることや、更新期限を有するかどうかを取得する処理を要件データ構造に定義してもよい。
【０１４１】
他の対策データＤ４とあわせて処理する必要がないため、図１５の処理ステップＳ５６４はＮとなる。所定期間内に更新する必要がある要件データを抽出する場合は、残り期間、あるいは有効期日とあわせて要件データＤ１１を処理する。要件データＤ１１は、前回更新日、更新周期、残り有効期間のいずれか、または複数の属性Ｊ、あるいは取得する処理をそなえることが例示される。この場合、他の要件データＤ１１とあわせて処理する必要がないため、図１５の処理ステップＳ５６０はＮとなる。
【０１４２】
一方で、残り有効期間の短い順に並べる場合は、上記で選択された要件データ群をソートしてもよいし、処理ステップＳ５６２において、他の要件データＤ１１と比較してソートしてもよい。要件に一致する要件データ群が、図１４の処理ステップＳ５０６において出力される。出力例としては、モニターに出力してもよいし、図１４の手順を定期的（例えば、毎日）に実行して、該当する要件データを所定の宛先に電子メールなどで通知してもよい。こうすることで、ユーザは要件の更新手続きを失念することなく、システム、装置、ソフトウェア、サービスをセキュアに保つことができる。
【０１４３】
次に、「処理４：各フェーズの手順を確認する」について説明する。
【０１４４】
この処理４は、システムのフェーズごとに考慮すべき手順などを確認する例を示す。例えば、計画時、保守時、停止時といった各段階で考慮すべき対策を確認する場合である。本例は、一般化すれば要件データＤ１１を属性値Ｋによって選択する場合を示す。
【０１４５】
図１４の処理ステップＳ５０２で選択された規格データＤ２に対し、適用フェーズという属性Ｊにおいて、指定の属性値Ｋに該当する要件データＤ１１を選択する。図１４の処理ステップＳ５０６では、選択された要件と、もしあれば対応する対策を提示する。このとき、関連する情報があれば、その情報、あるいは参照情報（例えば、ＨＴＭＬのＵＲＬリンクや、ＵＲＩ等）を提示してもよい。例えば、「システム停止時の手順は定めているか」という要件であれば、停止手順を定めた文章、写真といった画像ファイル等の電子データそのもの、あるいは参照情報を提示する。これにより、ユーザは各フェーズで考慮すべき対策、手順を確認することができ、項目の抜けなく、効果的にセキュリティ対策を実施することができる。
【０１４６】
次に、「処理５：より強固な対策、適用予定対策の評価」について説明する。
【０１４７】
この処理５は、よりセキュアな対策の推奨、あるいは適用しようとしている対策がどのような影響を及ぼすかを判定する例を示す。図１４の処理ステップＳ５０２で選択される規格データＤ２の中で、処理ステップＳ５０３、処理ステップＳ５０４で選択される要件データＤ１１について処理する。図１５において、他の要件データＤ１１とあわせて処理する必要がないため、図１５の処理ステップＳ５６０はＮとなる。対策データＤ４について処理するため、図１５の処理ステップＳ５６４はＹとなる。図１５の処理ステップＳ５６５では要件データＤ１１を満足する対策データＤ４が存在する場合、その対策データＤ４が該当する。よりセキュアな対策を推奨するために、該要件データＤ１１は、セキュア度を高める対策案を提示する処理が例示される（この場合、対策データＤ４とあわせて処理する必要がないため、図１５の処理ステップＳ５６４はＮとなる）。
【０１４８】
適用しようとしている対策データＤ４について、既存の対策に対する優劣を判定するために要件データ構造は、指定された対策データＤ４について、セキュリティレベルを算出する処理をそなえていてもよい。このようにすれば、該要件データＤ１１が、既存の対策データＤ４と、適用しようとしている対策データＤ４のそれぞれについてセキュリティレベルを算出することで、優劣を判定することができる。あるいは、２つの対策データＤ４を指定することで、セキュリティレベルの比較結果を取得する処理を実装してもよい。
【０１４９】
比較結果としては、２つの対策データＤ４をそれぞれ対策データＤ４Ａ、Ｄ４Ｂとすれば、「Ｄ４Ａの方が優れている」「Ｄ４ＡとＤ４Ｂは同等である」「Ｄ４Ｂの方が優れている」という意味を表わす値を返すことや、Ｄ４Ａが優れていればプラスの数値、Ｄ４Ｂが優れていればマイナスの数値、Ｄ４ＡとＤ４Ｂが同等であれば０として、セキュリティレベルを数値として算出することが例示される。あるいは対策データＤ４が複数の要件データＤ１１に影響する場合、セキュリティレベルは複数の要件データＤ１１と、関連する対策データＤ４で算出するため、算出式を任意に定め（例えば、各要件データＤ１１の重みを決める）、システム全体の値として算出して、比較してもよい。
【０１５０】
次に、「処理６：他の規格に対応する場合」について説明する。
【０１５１】
この処理６は、規格Ａに対応していて、新たに別の規格Ｂに対応する場合の例を示す。図１２の処理ステップＳ５０２にて、規格Ｂの規格データＤ２Ｂを選択する。次に、処理ステップＳ５０３、処理ステップＳ５０４において、規格Ｂの規格データＤ２Ｂの要件データＤ１１Ｂを選択する。次に図１５の処理ステップＳ５６０において、他の要件データＤ１１とあわせて処理する必要がないため、処理ステップＳ５６０はＮとする。図１５の処理ステップＳ５６４においては、Ｙとし、処理ステップＳ５６５、処理ステップＳ５６６において、すでに対応している規格Ａの規格データＤ２Ａの各要件データＤ１１Ａを満足するための対策データＤ４Ａを選択する。
【０１５２】
図１４で選択されている規格Ｂに係わる要件データＤ１１Ｂを、図１５の処理ステップＳ５６６で選択した対策データＤ４Ａで満足できるかを判定する。これらの判定結果を用いて、図１４の処理ステップＳ５０６では、規格Ａに適用した対策データＤ４Ａで満足できなかった規格Ｂの要件データＤ１１Ｂを提示することができる。
【０１５３】
これにより、追加で必要な対策を判定することができ、規格Ｂに対して、効率よく準拠することができる。それだけでなく、規格Ａに適用した対策の中で、規格Ｂに関与しない対策を提示することができ、規格Ｂに対応して規格Ａに対応する必要がない場合は、それらの不要な対策を除去することで、セキュリティに係わる投資を抑制することができる。
【０１５４】
また、規格Ａ、規格Ｂの両方に対応する場合は、いずれの規格準拠でも有効な対策を提示し、セキュリティ対策の貢献度を判別することができ、セキュリティに係わるポートフォリオを評価、最適化することができる。
【０１５５】
これは、ひとつの規格が複数の規格に分割された場合であっても、同様の手順で有効である。また、上記の手順で図１５の処理ステップＳ５６４における対策データの選定において、複数の規格データを対象とすることで複数の規格が少数の規格に集約された場合にも同様の手順で有効である。
【０１５６】
次に、「処理７：規格改定時の差分」について説明する。
【０１５７】
この処理７は、規格が改定された場合の例を示す。前述の、他の規格に対応する場合と同様の手順を用いることで、新たに追加すべき対策、不要となる対策を確認して、対策を変更することができる。加えて、図１５の処理ステップＳ５６０において、新しい規格の要件データＤ１１Ｎと元の規格の要件データＤ１１Ｏを比較することで、変更（追加、削除など）された要件を把握することができる。新旧の要件データＤ１１Ｎ、Ｄ１１Ｏの一致は、元の要件データＤ１１Ｏを満足する対策手段が新しい規格の要件データＤ１１Ｎを満足できる場合に、要件が同じと判定してもよいし、要件データ構造の定義や、その属性値Ｋの全て、あるいは重要度に応じて定めた所定の属性Ｊの属性値Ｋが一致する場合に、要件が同じと判定してもよい。
【０１５８】
元の規格の要件データＤ１１Ｏの中で、同じと判定する要件データＤ１１が見つからなかった場合に、新しい規格の該要件データＤ１１Ｎを「変更された要件」と判定することが例示される。要件レベルで差分を判断することで、必要な対策を効率よく適用することができる。あるいは、対策データ構造を新規に定義する必要あるかを判定することで、必要な対策データ構造を定義できることで、本システムの適用精度を高めることができる。
【０１５９】
また、規格のバージョンの差が複数バージョンにわたる場合（例えば、バージョン１とバージョン３）は、その特定のバージョン間の差分を処理する構成（例えば、バージョン１とバージョン３を指定する）でもよいし、隣接するバージョン間の差分を処理する手順（例えば、バージョン１とバージョン２、バージョン２とバージョン３を指定する）をもうけ、それを必要なだけ繰り返し（例えば、バージョン１からバージョン２、バージョン２からバージョン３への２回）、処理してもよい。
【０１６０】
次に、「処理８：あるサービス、デバイスが他のサービス、デバイスを通信する際に通信相手のセキュリティレベルを確認する」について説明する。
【０１６１】
この処理８は、あるシステムＡ（装置、ソフトウェア、サービスを含む）が別のシステムＢに対して一定のセキュリティレベルを要求する例を示す。この場合、システムＡは、図２の解析処理利用手段１３７、図１の情報処理装置Ｃｄに相当し、システムＢの情報を保持する図１の規格データ解析部１３３、図２の情報処理装置Ｃｂにアクセスする。
【０１６２】
図１４の処理ステップＳ５０２において、システムＡが要求する規格を選択し、処理ステップＳ５０３、処理ステップＳ５０４において、要求する要件データＤ１１が、何らかの対策データＤ４で満足しているかを判定する（図１５の処理ステップＳ５６６）。満足していれば、図１４の処理ステップＳ５０６において、システムＡに対して、システムＢが要求セキュリティレベルを満足していることを通知する。これにより、システムＡはシステムＢに対して通信可能である。なお、システムＡと本システム（規格データ解析部１３３）間はセキュアな通信が可能なように構成する。
【０１６３】
なお、システムＡがシステムＢに要求するセキュリティレベルは、上記したように所定の規格、ガイドラインを満足しているかどうかで判定してもよいし、特定の属性値Ｋにあわせたひとつ、または複数の規格の要件を満足しているかどうかで判定してもよい。これにより、ＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）やｗｅｂサービス、ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）等のアプリケーションにおいて、システムとシステム間のセキュアな通信を保証することができる。
【０１６４】
次に、「処理９：装置設計時、運用時の推奨要件を提示する」について説明する。
【０１６５】
この処理９は、装置の設計時に考慮すべき要件を提示する例を示す。本例における装置は、システム、ソフトウェア、サービスでもよい。加えて、設計時とは、対象フェーズという特定の属性における「設計時」という属性値Ｋによる一例であり、任意の属性Ｊの任意の属性値Ｋによる要件データＤ１１の選択に一般化できる。
【０１６６】
例えば、電力分野であれば、適用対象という属性Ｊとして、発電、送電、変電、配電といった違いや、電力、電圧レベルの違い、発電機、変圧器、遮断器、保護リレー、ＩＥＤ（Ｉｎｔｅｌｌｉｇｅｎｔ  Ｅｌｅｃｔｒｏｎｉｃ  Ｄｅｖｉｃｅ）という対象機器の違いが例示される。対象装置、システムにおいても、制御用コントローラやＤＣＳ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｎｔｒｏｌ  Ｓｙｓｔｅｍ）やＳＣＡＤＡ（Ｓｕｐｅｒｖｉｓｏｒｙ  Ｃｏｎｔｒｏｌ  Ａｎｄ  Ｄａｔａ  Ａｃｑｕｉｓｉｔｉｏｎ）、ＰＬＣ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｃｏｎｔｒｏｌｌｅｒ）の違いが例示される。
【０１６７】
図１４の処理ステップＳ５０２においては、図１の規格データ記憶部１３２に記憶されている全ての規格データＤ２を選択する。次に処理ステップＳ５０３、処理ステップＳ５０４においても、規格データＤ２の全ての要件データＤ１１を選択する。他の要件データＤ１１、他の対策データＤ４はあわせて処理しないため、処理ステップＳ５６０、処理ステップＳ５６４ではＮである。処理ステップＳ５６６において各要件データが指定される対象装置、指定される対象フェーズに一致するかを判定する。一致すれば、該当するひとつ、または複数の要件データを図１４の処理ステップＳ５０６において提示する。
【０１６８】
これにより、例えば、制御装置の設計時において、推奨される複数の要件を確認することができ、これに基づいて機器の設計、開発をすることで一定のセキュリティレベルをそなえた装置を設計、開発することができる。これを例えば、装置をシステム、設計を構築、計画に変更すれば、同様に、一定のセキュリティレベルをそなえたシステムを構築することができる。
【０１６９】
なお、装置やソフトウェアから直接、要件データを検索するのではなく、システム定義やＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）ツール等を用いて定義したシステム記述から、必要な装置、ソフトウェア、システムを抽出し、それらの抽出した装置、ソフトウェア、システムから要件データを選択してもよい。この場合、システム定義としてＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）、ＳｙｓＭＬ、ＩＥＣ  ６１８５０のＳＣＬ（Ｓｙｓｔｅｍ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｌａｎｇｕａｇｅ）、単線結線図等が例示される。これらのシステム定義やＧＵＩツールで記述可能な要素、コンポーネントと、関連する装置、ソフトウェア、システムは事前に関連付けておく。
【０１７０】
このようにすることで、システムの構成要素を個別に指定することなく、システム定義を用いることで容易にシステムを構成するコンポーネントに係わる要件を抽出することができる。
【０１７１】
次に、「処理１０：所定のセキュリティ対策が寄与するセキュリティ規格の提示」について説明する。
【０１７２】
この処理１０は、所定のセキュリティ対策がどの規格の要件に寄与するかを提示する例を示す。図１４の処理ステップＳ５０２において、全ての規格データＤ２を選択し、処理ステップＳ５０３、処理ステップＳ５０４で全ての要件データＤ１１を選択する。他の要件データＤ１１とあわせて処理しないため、図１５の処理ステップＳ５６０はＮである。
【０１７３】
指定された対策データＤ４が寄与する要件データＤ１１を提示するため、図１５の処理ステップＳ５６４はＹとなり、処理ステップＳ５６５、処理ステップＳ５６６にて、指定する対策データＤ４が図１４の処理ステップＳ５０４で選択された要件データＤ１１を満足するかを判定する。満足すれば、その要件データＤ１１を図１４の処理ステップＳ５０６にて出力する。該当する要件データＤ１１は複数になり得る。あるいは、要件データ構造に要件の満足度合いを数値化する処理を定義することが例示される。このとき、対策データＤ４が要件を満足することができない場合であっても、満足度合いが所定のしきい値以内であれば、図１４の処理ステップＳ５０６において出力してもよい。なお、満足度合いの数値はセキュリティ技術の水準を表わすパラメータに基づいて算出することが例示される。例えば、パスワード長、パスワードで想定される組み合わせの数、暗号化の強度、暗号鍵の鍵長などである。
【０１７４】
これにより、セキュリティ対策が有効な規格の要件の数や質を把握することができ、該対策の有効度の判定やセキュリティ施策のポートフォリオを効率的に組むことができる。
【０１７５】
あるいは、図１６に示す手順のように、対策データを中心に処理してもよい。この場合、図１６の処理ステップＳ５７１では該対策データを選択し、処理ステップＳ５７２、処理ステップＳ５７３、処理ステップＳ５７４、処理ステップＳ５７５、処理ステップＳ５７６では図１４、図１５で説明した手順と同様に、該対策データによって満足される要件データ、あるいは所定の満足度合いを達成する要件データを選択し、図１６の処理ステップＳ５０６において出力する。
【０１７６】
次に、本発明の実装形態について説明する。実装に関しては、要件データ構造、対策データ構造、要件データ、規格データ、対策データ、解析処理のいずれか、または複数のオブジェクト指向プログラミング言語を適用することが例示される。それらの方法は、スクリプト型のプログラミング言語でも構わないし、コンパイル型のプログラミング言語でも構わない。要件データ構造、対策データ構造を、クラス定義を示すソースファイル、あるいはコンパイル後のバイナリファイル（中間バイナリ形式を含む）で表し、規格データ、要件データ、対策データをオブジェクトファイル、あるいはストレージ等への永続化（ファイル保存含む）、ネットワークを経由した転送のために、シリアライズ化した形式でも構わないし、ダンプ化した形式でも構わない。
【０１７７】
オブジェクト指向言語としては、Ｃ＋＋、Ｃ＃、．ＮＥＴ、ＪＡＶＡ（登録商標）、Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎ、Ｌｕａ、その他を含む。あるいはオブジェクト指向言語ではなく、Ｃ言語等の手続き型言語を用いてもよい。その場合、要件データ構造、対策データ構造はデータ構造体、共用体等で表現することが例示される。
【０１７８】
要件データ、対策データ、規格データは、属性と属性値の組み合わせで表したテキストファイル（ＪＳＯＮ、ＸＭＬ）や所定のバイナリ形式でも構わない。属性値を未定義、あるいはデフォルト値としたテキストファイル、あるいは所定のバイナリ形式で要件データ構造、対策データ構造を表してもよい。
【０１７９】
要件データ構造、対策データ構造、規格データに処理手順を実装する場合は、プログラミング言語における関数、メソッド、メッセージ、コール、プロシージャ等を用いることが例示される。また、要件データ構造、対策データ構造を派生させる場合は、クラス継承、多重継承、ＪＡＶＡ（登録商標）言語におけるインターフェースを用いることが例示される。
【０１８０】
なお、プログラミング言語におけるクラス定義に対する処理の拡張、派生だけではなく、オブジェクトに対する拡張（特異メソッドと呼ばれる手法など）を用いてもよい。これは、例えば図８の処理ステップＳ２０５等が例示される。オブジェクトに対する処理は要件データ、対策データの定義時に拡張してもよい。
【０１８１】
要件データ構造の定義、対策データ構造の定義、要件データの定義、対策データの定義、規格データの定義は、ｗｅｂブラウザや専用ＧＵＩ、ＣＵＩ（Ｃｈａｒａｃｔｅｒ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を用いてもよい。要件データ構造、対策データ構造の定義においては、属性の編集（追加・修正・削除等）、ならびに派生させる場合は、元となるデータ構造を選択可能とすることが例示される。同様に、要件データの定義においては、定義済みの要件データ構造を選択可能とすることが例示される。対策データの定義においては、定義済みの対策データ構造を選択可能とすることが例示される。規格データの定義においても、定義済みの要件データ構造、要件データ、対策データ構造、対策データを選択可能とすることが例示される。
【０１８２】
また、規格データ解析部１３３の解析処理は、要件データ構造、または要件データの関数、メソッド、コールとして定義し、その内部では対策データ構造、対策データ（図１５の処理ステップＳ５６６）、要件データ構造、要件データ（図１５の処理ステップＳ５６２）の処理としての関数、メソッドを呼んでもよい。
【０１８３】
なお、言語によっては、該当メソッドを定義していない場合でも、呼び出す事ができ、実行時エラーとなる場合がある。その場合、ユーザに注意・警報してもよいし。該当処理の実装画面に遷移してもよい。ユーザはプログラム内容を入力することで、エラーの生じた関数、メソッド、コールの内容を実装することができる。
【０１８４】
図１７は具体的な表示画面例を示している。図１７の１４０は、注意メッセージを示し、例えば、未実装の関数名をあわせて表示することが例示される。テキストエリア１４１はプログラム内容を入力するエリアであり、確定ボタン１４２で内容を確定する。
【０１８５】
本画面は、他の関数、メソッド、コールを確認できる表示領域があってもよいし、テキストエリア１４１は、既存の関数をブロックで表わし、論理演算ブロック（論理積、論理和等）、パラメータブロック等をグラフィカルに接続してプログラミングできる機能でもよい。また、確定ボタン１４２押下後には、入力内容の正常、異常を示す画面に遷移してもよい。
【０１８６】
また、入力された内容は、新しい派生データ構造として、要件データ構造であれば図１の要件データ構造記憶部１３０、対策データ構造であれば対策データ構造記憶部１３４に記憶してもよい。あるいは、データ化された要件データ、対策データへの拡張（特異メソッド等）であれば規格データ記憶部１３２に記憶してもよい。既存のデータ構造への追加拡張としてもよい。
【０１８７】
また、サービス提供に関して、図２のシステム構成、図１の機能構成において、いずれの要素の数量も１つであるが、複数であってもよい。例えば、要件データ構造記憶部１３０、規格データ入力部１３１、規格データ記憶部１３２、あるいは対策データ構造記憶部１３４、対策データ入力部１３５、対策データ記憶部１３６のいずれか、または両方の組み合わせを１つとして、規格データ解析部１３３を複数とすれば、基本のデータ構造、データは共通にして、複数のユーザに異なった解析処理を提供することができ、セキュリティ規格サービスを提供できる。
【０１８８】
あるいは、要件データ構造記憶部１３０、規格データ入力部１３１、規格データ記憶部１３２、規格データ解析部１３３、対策データ構造記憶部１３４、対策データ入力部１３５、対策データ記憶部１３６をひとつにして、解析処理利用手段１３７を複数とすれば、やはり、特定の解析処理を複数のユーザにサービス提供することができる。いずれの場合においても、要件データ構造記憶部１３０、規格データ記憶部１３２、対策データ構造記憶部１３４、対策データ記憶部１３６の記憶内容を定期的、あるいは規格データ構造改定時や規格適用のルール改正（法改正）にあわせて更新することが例示される。
【０１８９】
あるいは、要件データ構造記憶部１３０、規格データ記憶部１３２、対策データ構造記憶部１３４、対策データ記憶部１３６のいずれか、または複数をひとつではなく、複数とすることで、要件データ構造、対策データ構造、要件データ、対策データ、規格データを流通させることができ、規格データ解析部１３３においては、異なったデータ構造、データを利用することができる。
【０１９０】
以上の本発明の実施例による効果について説明する。これによれば、複数の規格やガイドラインを共通のデータ構造とすることで共通の処理の適用を可能とし、さまざまな解析処理が可能となる。これにより、所定の規格への対応や、更新すべき要件の確認、システムの各フェーズにおけるセキュリティ手順の確認や、規格改定時、他の規格への対応を容易にすることができる。結果的に、社会インフラなどに係わるシステムをセキュアに構築、開発、設計、計画、保守することができる。
【符号の説明】
【０１９１】
Ｃ：情報処理装置
ＤＢ：データベース
ＮＷ：ネットワーク
１３０：要件データ構造記憶部
１３１：規格データ入力部
１３２：規格データ記憶部
１３３：規格データ解析部
１３４：対策データ構造記憶部
１３５：対策データ入力部
１３６：対策データ記憶部
１３７：解析処理利用手段
１４０：注意メッセージ
１４１：テキストエリア
１４２：確定ボタン
【図１】
0006591899.tif 000002
【図２】
0006591899.tif 000003
【図３】
0006591899.tif 000004
【図４】
0006591899.tif 000005
【図５】
0006591899.tif 000006
【図６】
0006591899.tif 000007
【図７】
0006591899.tif 000008
【図８】
0006591899.tif 000009
【図９】
0006591899.tif 000010
【図１０】
0006591899.tif 000011
【図１１】
0006591899.tif 000012
【図１２】
0006591899.tif 000013
【図１３】
0006591899.tif 000014
【図１４】
0006591899.tif 000015
【図１５】
0006591899.tif 000016
【図１６】
0006591899.tif 000017
【図１７】
0006591899.tif 000018