JP7808912B2 - トラスト管理装置及びトラスト管理方法 - Google Patents

Description

本発明は、トラスト管理装置及びトラスト管理方法に関する。

近時、産業制御システム（ＩＣＳ、Industrial Control System ）に対しオープン技術を活用することが浸透しつつあるが、その反面、サイバーセキュリティの問題がより深刻化している。例えば、ＩＣＳに多くのＩｏＴ（Internet of Things）機器が導入されることによりＩｏＴ機器経由で不正なソフトウェアがＩＣＳ内へ侵入する、サプライチェーン経由で不正なソフトウェアがＩＣＳ内の各機器にインストールされる等、攻撃の侵入源も多様化している。一方で、ＩＣＳのＤＸ（Digital Transformation）化を推進するためには、多様な技術を柔軟に取り入れるためのスケーラビリティ（拡張性）確保が必要不可欠であり、ＩＣＳにおいても、侵入を前提とした上でのセキュリティ対策が重要となっている。

また、エンタープライズ（大企業）向け情報システムを中心に、ゼロトラストの考えに基づくセキュリティ対策が浸透し始めている。この対策は、従来の境界防御ではなく「システムネットワークの内部に不正なソフトウェアが侵入した前提でセキュリティ防御策を設計する」という考えに基づき、エンドポイントでのセキュリティ強化や厳密なアクセス制御ポリシ管理を実施するセキュリティ対策である。

一方で、ＩＣＳは、エンタープライズ向け情報システムとは異なり、組込みコンピュータの処理性能が乏しい、リプレースやアップデート頻度がエンタープライズ向けシステムと比べて少ないといった点もある。このような点から、ゼロトラストアーキテクチャをＩＣＳにそのまま適用するのは課題が残る。したがって、すべてのエンドポイントでセキュリティ対策のための検証や制御を実施することが困難であり、前記の課題を踏まえた上で、ＩＣＳに適したトラスト管理アーキテクチャの実現が求められる。

トラスト管理を実現するためには、ＩＣＳにおける「トラスト」の定義の明確化と、ＩＣＳへの影響を最小化しつつ、ＩＣＳにおけるトラストを最大限評価するための仕組みが求められる。

特許文献１の技術は、クライアントプラットフォームがネットワーク上にあるリソース又はサービスへアクセスすることを許可する前に、クライアントプラットフォームから受信した複数のインテグリティ情報を元に、その許可の可否を決定することができる。

特表第２００９－５１８７６２号公報

ＩＳＯ／ＩＥＣ ＴＲ ２４０２８：２０２０（Ｅ），ｐ６，３.４２

特許文献１によれば、クライアントプラットフォームから受信した複数のインテグリティ情報を元にアクセス許可の可否を決定することができる。しかしながら、トラストを判断するためのインテグリティ情報を個別に定義する必要があり、最適化されたトラスト判断基準に関するデータベースをＩＣＳ毎に用意する必要がある。さらに、オープン技術の活用により、ＩＣＳが複雑になるほど、データベースに格納すべきトラスト判断基準が複雑になる傾向があり、ＩＣＳにとって意味のある判断基準を厳選する必要がある。

非特許文献１は、トラスト（trustworthiness）を”Ability to meet stakeholders’ expectations in a verifiable way”と定義する。この定義に従って、ステークホルダ（ＩＣＳ）が期待する性質を満足していることを測定可能な方法で実証又は検証することを「トラスト」と定義することも可能である。しかしながら、この場合、システム設計仕様や運用条件といった、ＩＣＳに求められる要件を厳選する必要があり、特許文献１では、その考慮が不十分である。

さらに、トラストを判定するための情報を収集するにあたり、クライアントから収集可能な情報が限られる場合もある。例えば、クライアントに情報収集用エージェントをインストールできない場合や、情報収集対象機器に対して様々な通信データを送信した後の応答を検証することによる情報収集（アクティブスキャン）を実行できない場合がＩＣＳでは多々存在する。

そこで本発明の目的は、これらの従来技術では解決できなかったＩＣＳにおけるトラストを踏まえた上で、ＩＣＳの運用への影響を最小化する方法で、トラストを判定するための情報を収集、評価するための仕組みを提供することである。

本発明のトラスト管理装置は、システムの設計情報又は運用情報から、前記システムがシステム構成要素としてのエンティティに期待する期待仕様を生成し、前記期待仕様と比較するための情報であって、前記システムに検知されたエンティティに関する情報を、前記検知されたエンティティから、前記システムへの影響が所定の基準を満たす程度に小さくなる方法で収集し、複数の前記期待仕様ごとに、計測可能なクライテリアを記憶しており、前記クライテリアに基づき、前記期待仕様を前記検知されたエンティティが充足する度合いを定性的な又は定量的な指標で評価し、前記クライテリアの根拠となった情報を入手又は追跡すること、を特徴とする。

本発明において、トラストは、システム（ＩＣＳ）の情報処理及び運用に関与する装置、ユーザ、サブシステム、ソフトウェアといった要素（エンティティ）が、システムが備えるべき仕様を満足することを、実証可能、検証可能又は測定可能な方法で検証する能力として定義する。ここで、システムが備えるべき仕様とは、対象システムの設計仕様、及びシステム運用上の条件である。

つまり、全体としてのシステム（ＩＣＳ）が、自身を構成する個々のエンティティに対し所定の仕様を期待している。ここでのエンティティは、システムが既にアクセス済であるもの、及び、未だアクセスしていないものを含む。そして、システムがエンティティに期待する仕様は、「期待仕様」とも呼ばれ、そのエンティティが実際に備える仕様（エンティティに関する情報）とは区別される。もちろん、エンティティが実際に備える情報は、期待仕様と比較され得る。

ここで、システムの設計仕様は、非機能要件を含むシステム要求仕様書、システムのネットワーク情報や装置構成といったシステム構成仕様書等を含むシステムの設計情報を示す。

例えば、システムネットワークの非機能要件として「ネットワークに参加するノード間で暗号通信できること」が要求されているとする。このとき、ネットワークに参加するエンティティが暗号通信できることを自ら実証するか、システム側がそれを検証することで、初めてエンティティとシステムに関するトラスト関係が満たされる。このシステム要件は、システム設計文書から引用され、又は、システム管理者によって個別に定義される。

また、システムの運用情報は、システムが置かれた環境や、システム利用者向けの運用マニュアルといった、システム運用に関する情報から構成される。例えば、システムがアプリケーションによって重要な制御プロセスの安全制御機能等を扱う場合、システムが扱うアプリケーションの重要性（問題発生時の深刻度合い）が、システムが置かれた環境の例となる。

本発明は、以上に示したシステムの設計情報及びシステムの運用情報から、システムがエンティティに対して期待する仕様（期待仕様）を生成することを特徴とするトラスト管理装置及びトラスト管理方法である。

さらに、本発明は、システム（ＩＣＳ）への影響を最小化しつつ、システムの稼働状態を観測し、前記のトラストを判定するために必要な情報を最大限収集することを可能とする。その方法として本発明は、システムの稼働状態や機器特性を観測・評価し、観測・評価結果及び期待仕様を元に情報収集手段をスケジュール化することを特徴とする。

本発明によれば、ＩＣＳにおけるトラストを踏まえた上で、ＩＣＳの運用への影響を最小化する方法で、トラストを判定するための情報を収集、評価するための仕組みを提供することが可能となる。

本実施形態の全体構成図である。 本実施形態におけるトラスト管理装置のハードウェア構成例を示す図である。 本実施形態における期待仕様生成処理の動作を示す図である。 本実施形態におけるシステム設計情報の入力画面を示す図である。 本実施形態におけるシステム運用情報の入力画面を示す図である。 本実施形態における入力解析処理フローを示す図である。 本実施形態における期待仕様生成処理フローを示す図である。 本実施形態における期待仕様一覧を示す図である。 本実施形態におけるトラストレベル判定基準テーブルを示す図である。 本実施形態における情報スキャン制御動作を示す図である。 本実施形態におけるトラストレベル判定動作を示す図である。 本実施形態における新規エンティティ検知時の処理フローを示す図である。 本実施形態におけるスキャン切り替えタイミングを示す図である。 本実施形態におけるトラスト管理装置の出力を示す図である。

＜全体構成＞
以下に本発明の実施形態について図面を用いて詳細に説明する。

図１は、本実施形態の全体構成図である。産業制御システム（ＩＣＳ）１０は、ＩＣＳネットワーク１１を介してトラスト管理装置１００と接続されている。産業制御システム（ＩＣＳ）１０は、多くの構成要素（エンティティ）１２～１６を備える。トラスト管理装置１００は、これらの構成要素が期待仕様を満たすか否かを、ゼロトラストの考え方に基づき決定する。

ＩＣＳネットワーク１１に対して、トラスト管理装置１００が接続されている。ＩＣＳネットワーク１１には、制御装置等のシステムコンポーネント１２が接続され、業務に係る処理を実行する。システムコンポーネント１２には、システムコンポーネント１２のハードウェアを制御するソフトウェア１２－１がインストールされており、所定の情報処理機能を実行する。

また、トラスト管理装置１００に対してリモートアクセスし、トラスト管理装置１００のユーザ（システム管理者）に対して操作処理を提供するリモート端末１３も、ＩＣＳネットワーク１１に接続されている。システム管理者は、トラスト管理装置１００を用いた管理業務をリモート端末１３経由で、又は、トラスト管理装置１００が具備するローカルユーザインタフェース経由で実施する。

ＩＣＳネットワーク１１には、ネットワーク負荷やＩＣＳ１０に接続する各情報処理装置の処理状態といったＩＣＳ１０に関する計算資源の状態を観測、収集する監視装置１４が接続される。監視装置１４には、例えばＳＣＡＤＡ（Supervisory Control And Data Acquisition）やＨｉｓｔｏｒｉａｎと呼ばれるＩＣＳコンポーネント（制御システム集中管理機能）等が該当する。

ＩＣＳネットワーク１１には、ＩＣＳネットワーク１１に新規に参加したエンティティや既に接続されている機器からトラスト判断に関する情報を収集するスキャン端末１５も接続される。トラスト管理装置１００は、スキャン端末１５に対して、情報収集又はスキャン処理の実行を制御する権限を有している。

さらに、ＩＣＳネットワーク１１には、トラスト管理装置１００が指定するセキュリティ制御処理を実行するセキュリティ制御装置１６が接続される。セキュリティ制御装置１６は、ファイアウォールやＩＰＳ（Intrusion Prevention System）に代表されるネットワークやエンドポイントのアクセス制御（認証・認可・アカウンティング）をトラスト管理装置１００の指示に従い実行する。セキュリティ制御装置１６は、ＶＬＡＮ（Virtual Local Area Network）技術を活用したネットワーク分離、暗号通信制御等のセキュリティに係る制御処理をトラスト管理装置１００の指示に従い実行する。

＜ハードウェア構成＞
図２は、本実施形態におけるトラスト管理装置のハードウェア構成例を示す図である。本構成は、計算機における記憶領域に相当する記憶部１０１、計算処理を実行するＣＰＵ（Central processing Unit）１０４、プログラムやデータをロードし、計算処理を実行するためのデータを保持する揮発性記憶素子から構成される主記憶（メインメモリ）１０５、計算機とユーザ間でデータの遣り取りを担うユーザインタフェース１０６及び他計算機間の通信処理を担う通信処理部１０７を要素として含む。

記憶部１０１は、トラスト管理に係る処理情報が格納されたプログラム１０２及びトラスト管理に関するデータを格納するデータベース１０３を含む。記憶部１０１には、例えば、ＨＤＤ（Hard Disk Drive）やＳＤＤ（Solid State Drive）等の不揮発性記憶素子が該当する。

プログラム１０２は、ＣＰＵ１０４が解読可能な言語で表現されたソフトウェアであり、トラスト管理装置１００が提供する機能を実行する。なお、本構成は、物理的に存在するハードウェアに限らず、仮想化されたハードウェアにおいても実装され、ハードウェアブロックの実装形態は、物理的に存在するハードウェアに限らない。

ユーザインタフェース１０６は、コマンドベースで入力されるＣＬＩ（Command Line Interface）又はＧＵＩ（Graphical User Interface）で構成され、ユーザフレンドリーな形態である。
通信処理部１０７は、ＩＣＳネットワーク１１と接続するためのネットワークインタフェースカード等である。通信形式は、有線ネットワークの場合もあれば無線ネットワークの場合もある。

＜本発明におけるトラスト管理の仕組み＞
以下に本発明の実施形態のトラスト管理の仕組みについて図面を用いて説明する。

＜本発明における期待仕様生成の仕組み＞
図３は、本実施形態における期待仕様生成処理の動作を示す図である。ユーザによる手動入力によって又はリモート端末１３経由で、トラスト管理装置１００にシステム設計情報３０１及びシステム運用情報３０２が入力され、トラスト管理装置１００のユーザインタフェース１０６及び通信処理部１０７がそれらを受け付ける。つまり、システム設計情報３０１又はシステム運用情報３０２を所定の書式に従いユーザが文書として入力する。入力された情報は、トラスト管理装置１００の主記憶１０５にロードされたプログラム１０２に読み込まれる。

プログラム１０２として、入力情報解析部３１１及び期待仕様生成部３１２が存在する。まず、入力情報解析部３１１は、システムの期待仕様生成に必要な情報を抽出する。次に、期待仕様生成部３１２は、入力された情報を元に期待仕様を生成する。期待仕様生成部３１２は、標準仕様ＤＢ（Data Base）３１３を参照し、期待仕様の生成に必要な追加情報を抽出する。

入力情報解析部３１１は、テンプレート化された入力を読み取り、タグ付けされた情報を抽出することで期待仕様を生成してもよいし、システム設計情報３０１をテキストマイニング処理することで、期待仕様の生成に必要な情報を抽出してもよい。

期待仕様は、システム設計情報３０１又はシステム運用情報３０２から生成されるが、期待仕様を生成するための情報が不十分である場合、期待仕様生成部３１２は、標準仕様ＤＢ３１３に格納された期待仕様テンプレートを参照し、期待仕様の不足を補う。その期待仕様テンプレートは、テンプレート単位で属性情報を紐づけることが可能であり、入力情報からトラスト管理対象システム（ＩＣＳ１０）の属性を判断できる場合は、その属性情報からテンプレートを抽出することもできる。

例えば、「システムの重要度」という属性情報があり、その属性値が「高・中・低」で構成される場合、属性値が「高」の場合の期待仕様テンプレート、「中」の場合の期待仕様テンプレート、「低」の場合の期待仕様テンプレートが標準仕様ＤＢ３１３に格納される。期待仕様生成部３１２は、入力情報解析部３１１が解析した結果に基づき「システムの重要度」を決定し、該当する期待仕様テンプレートを抽出する。

図４Ａは、本実施形態におけるシステム設計情報の入力画面を示す図である。システム設計情報３０１を入力する項目として、システム設計書やシステム要求仕様書等のシステム設計に関するドキュメントファイルを入力する項目や、個別にシステム情報を入力する項目が設けられる。ドキュメントファイルの例として、ＯＡ（Office Automation）業務で利用されるような文書作成ソフトウェア等で作成された文書（所定の書式に従う文書）が挙げられる。これら関連ファイルを複数入力することもできる。

システム情報は、トラスト管理対象システムのネットワーク情報と資産情報とに区分して入力される。ネットワーク情報の例として、ネットワークトポロジーや、有線ＬＡＮ、無線ＬＡＮ、シリアルネットワーク等のネットワークの種類、ネットワークに参加するノード間の接続関係が挙げられる。

ネットワーク情報の入力方法として、テキストベースの定義ファイル用意し、当ファイルを入力してもよいし、ＧＵＩとして画面上に描画してもよい。資産情報も同様に、テキストベースの定義ファイルで入力されてもよいし、ＧＵＩとして入力されてもよい。資産情報は、例えば、資産名の他、エンティティの種類や下位カテゴリ、システムを実現する上でのエンティティの要求仕様定義情報から構成される。

図４Ｂは、本実施形態におけるシステム運用情報の入力画面を示す図である。システム運用情報３０２を入力する項目として、システム運用マニュアルなどのシステム運用に関するドキュメントファイルを入力する項目や、個別にシステム運用に関する情報を入力する項目が設けられる。ドキュメントファイルの例として、ＯＡ（Office Automation）業務で利用されるような文書作成ソフトウェア等で作成された文書（所定の書式に従う文書）が挙げられる。図４Ａに示したシステム設計情報入力時と同様、これら関連ファイルを複数入力することもできる。

また、システム運用に関して個別入力する場合、「システムのアプリケーション」や「システムの重要度」といった、システム運用や環境に関する個々の入力項目があり、それぞれ該当する項目が選択される。なお、これら個々のシステム運用情報の定義をテキストベースの定義ファイルで入力する方法もある。
図４Ａ及び図４Ｂに示した画面は、リモート端末１３又はトラスト管理装置１００のローカルユーザインタフェース経由で表示される。

図５は、本実施形態における入力解析処理フローを示す図である。この入力解析処理は、トラスト管理装置１００内のプログラム１０２（入力情報解析部３１１）にて実行される。

ステップＳ５０１において、入力情報解析部３１１は、ユーザインタフェース１０６又は通信処理部１０７からシステム設計情報３０１又はシステム運用情報３０２を受信し、その後、これらの入力情報を解析する。このとき、入力情報解析部３１１は、入力情報から、期待仕様を生成する上で必要なシステム構造モデルやオペレーション（運用）モデルの構築に必要とする情報を抽出する。

ステップＳ５０２において、入力情報解析部３１１は、入力されたシステム設計情報３０１を元に、期待仕様となるシステム構造モデルを生成する。このシステム構造モデルは、複数の属性情報からなるメタデータとして定義される。

ステップＳ５０３において、入力情報解析部３１１は、入力されたシステム運用情報３０２を元にオペレーションモデルを生成する。オペレーションモデルも、システム構造モデルと同様、複数の属性情報からなるメタデータとして定義される。

ステップＳ５０４において、入力情報解析部３１１は、システム構造モデル及びオペレーションモデルを構造化データとして生成・出力する。この構造化データは、例えばＸＭＬ（Extensible Markup Language）やＪＳＯＮ（JavaScript Object Notation）等の構造化データを表現するデータ形式で生成される。この構造化データは、必要に応じてファイルとして保存され、ユーザインタフェース１０６又はリモート端末１３を介して参照可能である。

図６は、本実施形態における期待仕様生成処理フローを示す図である。この期待仕様生成処理も、トラスト管理装置１００内のプログラム１０２（期待仕様生成部３１２）にて実行される。本処理フローは、図５に示した処理により生成された構造化データを元に期待仕様を生成する。

ステップＳ６０１において、期待仕様生成部３１２は、構造化データを解析し、期待仕様モデルの生成に必要な情報を抽出する。

ステップＳ６０２において、期待仕様生成部３１２は、構造化データから抽出したシステム構造モデル及びオペレーションモデルから期待仕様モデルを生成する。この処理において、期待仕様生成部３１２は、システム構造モデル及びオペレーションモデルの情報をそのまま利用して期待仕様モデルを生成してもよいし、標準仕様ＤＢ３１３を参照し、テンプレート期待仕様を抽出することで期待仕様モデルを生成してもよい。

ステップＳ６０３において、期待仕様生成部３１２は、期待仕様モデルを元に、期待仕様に対する満足度合いを評価するためのクライテリア情報を標準仕様ＤＢ３１３から取得する。

ステップＳ６０４において、期待仕様生成部３１２は、期待仕様モデル及びクライテリアの取得に成功した後に期待仕様を出力する。

図７は、本実施形態における期待仕様一覧を示す図である。期待仕様一覧は、図３の標準仕様ＤＢ３１３に格納されている期待仕様テンプレートの一部であり、ポイント・ドメイン、トラスト対象、期待仕様及びクライテリアを相互に関連付けている。

ポイント・ドメインは、トラスト管理対象システム上のネットワークやコンポーネント等である。
トラスト対象は、例えば、「制御情報ネットワーク」に対して接続するコンポーネント等の一覧である。

期待仕様は、例えば「強固な暗号通信機能をサポートすること（NW-01）」といった、トラスト管理対象システムに対するシステム要求仕様の形で定義される。
クライテリアは、例えば、前記の期待仕様を例にとると、「ＴＬＳ（Transport Layer Security）ｖ１．３以上の公開鍵暗号処理機能を具備していることを確認する」、「ＡＥＳ（Advanced encryption standard）と同等の共通鍵暗号能を具備していることを確認する」等、システムの期待仕様を測定可能な方法で検証する手段として定義される。

なお、期待仕様は、トラストに関する様々な観点で整理されることもある。例えば、あるエンティティの期待仕様を真正性（Authenticity）、信頼性（Reliability）、保護性（Protectivity）、セキュリティ（Security）、品質（Quality）、強靭性（Resilience）等の特性に応じて定めることもできる。なお、期待仕様に関する特性は、前記の項目だけには限られない。

図８は、本実施形態におけるトラストレベル判定基準テーブルを示す図である。トラストレベル判定基準テーブルは、図７の期待仕様一覧における期待仕様及びクライテリアの組合せに対して、詳細検証方法及びトラストレベルの複数の組合せを関連付けている。トラストレベル判定基準テーブルもまた、図３の標準仕様ＤＢ３１３に格納されている期待仕様テンプレートの一部である。

詳細検証方法は、前記の通り、定義されたクライテリアに対して、測定可能な方法で検証する具体的な手段である。詳細検証方法として、例えば、「（システムの利用が許可された）信頼できるユーザによる手動入力」、「（対象となるコンポーネントに）ＴＬＳ通信ライブラリを具備することをソフトウェアライブラリから確認」、「通信キャプチャ、またはアクティブスキャンによるＴＬＳｖ１．３セッション確立の確認」等がある。

トラストレベルは、詳細検証方法による検証の結果を示す数値である。トラストレベルとしては、例えば、「信頼できるユーザによる手動入力」に対してトラストレベル「１」が規定される。「ＴＬＳ通信ライブラリを具備することをソフトウェアライブラリから確認」に対してトラストレベル「２」が規定される。「通信キャプチャ、またはアクティブスキャンによるＴＬＳｖ１．３セッション確立の確認」に対してトラストレベル「３」が規定される。トラストレベルは、レベル１、レベル２といった定性的な仕様であってもよいし、期待仕様に対する確からしさを示すパーセンテージ等の定量的な割合であってもよい。トラストレベルは、エンティティが期待仕様を充足する度合いでもあるともいえる。

図９は、本実施形態における情報スキャン制御動作を示す図である。トラスト管理装置１００は、監視装置１４からトラスト管理対象システムのシステム状態を、通信処理部１０７を介して取得する。このシステム状態は、ＳＣＡＤＡ、Ｈｉｓｔｏｒｉａｎ、システムを構成する各情報処理装置のログ情報から取得するシステムの稼働状態情報、ネットワークの処理負荷状態情報、情報処理装置の処理負荷状態情報等を含む。

これらの情報から構成されるシステム状態を入力情報として、トラスト管理装置１００内のプログラム１０２から主記憶１０５にロードされたシステム状態解析部９１１は、システム状態の解析処理を実行する。システム状態解析部９１１は、この解析結果として、システムや各情報処理装置の処理リソースを時間軸で見たときの変化を得る。

情報収集スケジューラ９１２は、この解析結果及びトラスト管理対象システムのモデル情報を元に、期待仕様の満足度合いを評価するための情報収集スケジュールを策定する。データ収集指示部９１３は、情報収集スケジューラ９１２が策定した情報収集スケジュールに基づき、データ収集指示を生成する。データ収集指示は、ＩＣＳネットワーク１１に参加する１台以上のスキャン端末１５に対する指示である。データ収集指示部９１３は、通信処理部１０７を介して各スキャン端末１５にデータ収集指示を送信する。

図１０は、本実施形態におけるトラストレベル判定動作を示す図である。ＩＣＳネットワーク１１に接続する各スキャン端末１５からの自動入力、又は、ユーザインタフェース１０６を介した手動入力により、検証対象エンティティに関する情報（エンティティ関連データ）がトラスト管理装置１００に入力される。

収集データ解析部１０１１は、入力されたエンティティ関連データを解析する。この解析は、図８で規定された詳細検証方法を満足する方法で実行される。
次に、トラストレベル判定部１０１２は、解析結果を元にトラストレベルを判定する。トラストレベル判定部１０１２は、図８のトラストレベル判定基準テーブルを使用して、規定された詳細検証方法を満足する度合いによりトラストレベルを判定する。

その後、通知・セキュリティ制御部１０１３は、トラストレベル判定結果を表示し、又は、セキュリティ制御内容を決定する。

通知・セキュリティ制御部１０１３は、ユーザインタフェース１０６を介してトラスト管理装置１００内のローカルユーザインタフェースに対して、又は、通信処理部１０７を介してリモート端末１３に対して、トラストレベル判定結果を通知する。セキュリティ制御を実行する場合、通知・セキュリティ制御部１０１３は、通信処理部１０７を介してＩＣＳネットワーク１１に接続する各セキュリティ制御装置１６に対してセキュリティ制御指示を送信する。

図１１は、本実施形態における新規エンティティ検知時の処理フローを示す図である。
ステップＳ１１０１において、収集データ解析部１０１１は、スキャン端末１５からの通知、又は、ユーザからの手動入力により、ＩＣＳネットワーク１１に参加する新規エンティティを検知する。

ステップＳ１１０２において、各スキャン端末１５は、情報収集スケジューラ９１２が生成したデータ収集スケジュールに従い、新規エンティティに対して、情報スキャンを実行する。なお、監視装置１４が出力するログ情報から、収集データ解析部１０１１部が新規エンティティの存在を検知する場合もある。

ステップＳ１１０３において、収集データ解析部１０１１は、得られたスキャン結果を収集・解析する。
ステップＳ１１０４において、トラストレベル判定部１０１２は、図８のトラストレベル判定基準テーブルを使用し、これらの情報の解析結果及び新規エンティティに対する期待仕様から、トラストレベルを判定する。
ステップＳ１１０５において、トラストレベル判定部１０１２は、新規エンティティのトラストレベルを、システム管理者に対して通知する、又は、セキュリティ制御指示を生成し各セキュリティ制御装置１６に通知する。

次に、本実施形態において、ＩＣＳへの影響を最小化する方法で情報スキャンする方法について述べる。

図１２は、本実施形態におけるスキャン切り替えタイミングを示す図である。例えば、システム状態としてのネットワーク負荷の時間変化を監視装置１４が監視した結果、図１２に示すグラフが得られたとする。一般に知られているように、スキャンの方法として、自ら通信データを生成しない受動的（パッシブ）スキャン、及び、自ら通信データを生成し、その応答を観測することができる能動的（アクティブ）スキャンが存在する。スキャン端末１５は、これら２つの方法を切り替える。

具体的には、スキャン端末１５は、例えば、ピーク時点（ネットワーク負荷の極大点）においては、過剰な通信を発生させるアクティブスキャンを控え、過剰な通信を発生させないパッシブスキャンのみを実行する。スキャン端末１５は、帯域が落ち着いた時点（ネットワーク負荷の極小点）においては、アクティブスキャンを実施する。

こうすることで、システム（ＩＣＳ）の負荷が少ないタイミングで最大限情報を収集することが可能となる。ＩＣＳは、周期的に所定の処理を実行する場合が多く、この方式はＩＣＳへの影響を最小化する手段として有用である。なお、スキャン方式を切り替えるタイミングは、前記の例に限定されない。他の例として、動的にＩＣＳの状態を観測し、ネットワーク負荷が減少傾向にある場合にアクティブスキャンを実行するといった、ＪＩＴ（Just-In-Time）型なスケジューリングもある。

さらに、スキャン対象の属性に応じて、スキャン方式を決定する方式もある。例えば、スキャン端末１５は、計算リソースが充分に大きい産業用パーソナルコンピュータやサーバ機器といったホストデバイスに対しては、タイミングにかかわらずアクティブスキャンを実行する。スキャン端末１５は、「保守」や「試運転」といったオペレーションモードの場合は、システム停止に繋がる業務影響は発生しないので、アクティブスキャンを常に実行する。

図１２において、スキャン端末１５は、ネットワーク負荷の極小点においてアクティブスキャンを実行しているが、これは一例である。監視装置１４は、ネットワーク負荷以外のシステム状態の時間変化を監視してもよい。スキャン端末１５は、任意のシステム状態が厳密に極小値となるタイミングにのみアクティブスキャンを実行する必要はなく、システムへの影響が所定の基準を満たす程度に小さくなる方法（小さくする方法）でエンティティに関する情報を収集すればよい。なお、スキャン端末１５は、ネットワーク負荷の接線の傾きを常時監視し、極小点及び極大点を判別してもよいし、ネットワーク負荷の過去の時系列変化を機械学習することによって、それらを判別してもよい。

つまり、システムへの影響を小さくするため、トラスト管理装置１は、策定した情報収集スケジュールに従い、システム（ＩＣＳ）内部にインストールされたスキャン端末１５に対して、パッシブスキャン又はアクティブスキャンを選択的に実行するスキャン指示を生成する。

トラスト管理装置１００は、検知されたエンティティの属性情報、又は、システム（ＩＣＳ）の運転状態に応じてパッシブスキャン又はアクティブスキャンを切り替えてもよい。例えば、スキャン端末１５が２つ存在し、第１のスキャン端末が利用可能になるタイミング（第１のタイミング）の後に第２のスキャン端末が利用可能になるタイミング（第２のタイミング）が到来するとする。さらに、第１のスキャン装置よりも第２のスキャン端末のほうが多くの情報を収集可能であるとする。

この場合、トラスト管理装置１００は、第２のタイミングまでは、検知されたエンティティが期待仕様を充足する度合いを第１のスキャン端末に暫定的に判定させる。そして、トラスト管理装置１００は、第２のタイミングが到来した後に、検知されたエンティティが期待仕様を充足する度合いを前記第２のスキャン端末に再度判定させる。

図１３は、本実施形態におけるトラスト管理装置の出力を示す図である。トラスト管理装置１００は、図１３に示した情報を、ユーザインタフェース１０６又はリモート端末１３を介して出力する。トラスト管理装置１００は、トラスト管理される対象エンティティ（図１３の「対象」）毎に、エンティティのカテゴリ、期待仕様、トラストレベル、クライテリアの確認手段、及び、トラストレベルを判定した最終確認日時を出力する。

ユーザは、トラストレベル又は最終確認日時を確認することで、トラスト管理の点で問題のあるエンティティを識別することが可能となる。また、クライテリアの確認手段として、トラスト管理装置１００が管理する他のエンティティが関与することがある。

本実施形態におけるトラスト管理装置１００は、あるエンティティのクライテリアを確認した他のエンティティを入手又は追跡することもできる。つまり、エンティティ１における期待仕様のクライテリアを確認する手段としてエンティティ２を利用した場合、エンティティ１の期待仕様は、エンティティ２によって検証できていると言える。

換言すると、エンティティ２の期待仕様が満足できていないことが後で判明した場合、エンティティ１の期待仕様の妥当性も保証できなくなる。本実施形態におけるトラスト管理装置１００は、前記のようなクライテリアを確認する手段をトレースする機能を有する。

また、セキュリティ制御装置１６に対して、セキュリティ制御処理の内容を、トラストレベル及び最終確認日時に合わせて決定することもできる。この場合、セキュリティ制御処理の内容も出力（図１３の表）に含まれることとなる。なお、本実施形態におけるトラスト管理のプロセスは、ハードウェアとして存在する装置を例に示したが、実装形態はハードウェアに限られず、一連の手順を実行するものであれば何でもよい。例えば、クラウドコンピューティングを前提とする、何らかのプログラミング言語で記述された手順も適用できる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、前記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、前記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

１０ 産業制御システム（ＩＣＳ）
１１ ＩＣＳネットワーク
１２ システムコンポーネント（装置）
１２－１ ソフトウェア
１３ リモート端末
１４ 監視装置
１５ スキャン端末
１６ セキュリティ制御装置
１００ トラスト管理装置
１０１ 記憶部
１０４ ＣＰＵ
１０５ 主記憶
１０６ ユーザインタフェース
１０７ 通信処理部
３０１ システム設計情報
３０２ システム運用情報
３１１ 入力情報解析部
３１２ 期待仕様生成部
３１３ 標準仕様ＤＢ
９１１ システム状態解析部
９１２ 情報収集スケジューラ
９１３ データ収集指示部
１０１１ 収集データ解析部
１０１２ トラストレベル判定部
１０１３ 通知・セキュリティ制御部

Claims (7)

1. システムの設計情報又は運用情報から、前記システムがシステム構成要素としてのエンティティに期待する期待仕様を生成し、
   前記期待仕様と比較するための情報であって、前記システムに検知されたエンティティに関する情報を、前記検知されたエンティティから、前記システムへの影響が所定の基準を満たす程度に小さくなる方法で収集し、
   複数の前記期待仕様ごとに、計測可能なクライテリアを記憶しており、
   前記クライテリアに基づき、前記期待仕様を前記検知されたエンティティが充足する度合いを定性的な又は定量的な指標で評価し、
   前記クライテリアの根拠となった情報を入手又は追跡すること、
   を特徴とするトラスト管理装置。
2. システムの設計情報又は運用情報から、前記システムがシステム構成要素としてのエンティティに期待する期待仕様を生成し、
   前記期待仕様と比較するための情報であって、前記システムに検知されたエンティティに関する情報を、前記検知されたエンティティから、前記システムへの影響が所定の基準を満たす程度に小さくなる方法で収集し、
   ＳＣＡＤＡ（Supervisory Control And Data Acquisition）若しくはＨｉｓｔｏｒｉａｎを含む制御システム集中管理機能を使用し、又は、前記システムを構成する情報処理装置が生成するログ情報を元に前記システムの状態を観測した結果を使用して情報収集スケジュールを策定し、
   前記策定した情報収集スケジュールに従い、前記システム内部にインストールされたスキャン端末に対して、パッシブスキャン又はアクティブスキャンを選択的に実行するスキャン指示を生成し、
   前記検知されたエンティティの属性情報、又は、前記システムの運転状態に応じてパッシブスキャン又はアクティブスキャンを切り替え、
   第１のスキャン端末が利用可能になる第１のタイミングの後に、前記第１のスキャン端末よりも多くの情報を収集可能な第２のスキャン端末が利用可能になる第２のタイミングが到来する場合、前記第２のタイミングまで、前記検知されたエンティティが前記期待仕様を充足する度合いを前記第１のスキャン端末に暫定的に判定させ、
   前記第２のタイミングが到来した後に、前記検知されたエンティティが前記期待仕様を充足する度合いを前記第２のスキャン端末に再度判定させること、
   を特徴とするトラスト管理装置。
3. 前記システムの設計情報又は運用情報を所定の書式に従いユーザが文書として入力することを受け付けること、
   を特徴とする請求項１又は２に記載のトラスト管理装置。
4. 前記期待仕様が前記システムを構成する構成要素の分類に応じてテンプレート化されたデータベースを参照することによって前記期待仕様を生成すること、
   を特徴とする請求項１又は２に記載のトラスト管理装置。
5. 前記検知されたエンティティが前記期待仕様を充足する度合いを判定した結果を、前記トラスト管理装置のユーザインタフェースに通知し、又は、通信インタフェースを介して前記トラスト管理装置の外部に通知し、
   前記検知されたエンティティが前記期待仕様を充足する度合いを判定した結果を元に、前記システム内にインストールされたセキュリティ制御装置に対して指令を生成すること、
   を特徴とする請求項１又は２に記載のトラスト管理装置。
6. トラスト管理装置が、
   システムの設計情報又は運用情報から、前記システムがシステム構成要素としてのエンティティに期待する期待仕様を生成するステップと、
   前記期待仕様と比較するための情報であって、前記システムに検知されたエンティティに関する情報を、前記検知されたエンティティから、前記システムへの影響が所定の基準を満たす程度に小さくなる方法で収集するステップと、
   複数の前記期待仕様ごとに記憶された計測可能なクライテリアに基づき、前記期待仕様を前記検知されたエンティティが充足する度合いを定性的な又は定量的な指標で評価するステップと、
   前記クライテリアの根拠となった情報を入手又は追跡するステップと、
   を実行することを特徴とするトラスト管理方法。
7. トラスト管理装置が、
   システムの設計情報又は運用情報から、前記システムがシステム構成要素としてのエンティティに期待する期待仕様を生成するステップと、
   前記期待仕様と比較するための情報であって、前記システムに検知されたエンティティに関する情報を、前記検知されたエンティティから、前記システムへの影響が所定の基準を満たす程度に小さくなる方法で収集するステップと、
   ＳＣＡＤＡ（Supervisory Control And Data Acquisition）若しくはＨｉｓｔｏｒｉａｎを含む制御システム集中管理機能を使用し、又は、前記システムを構成する情報処理装置が生成するログ情報を元に前記システムの状態を観測した結果を使用して情報収集スケジュールを策定するステップと、
   前記策定した情報収集スケジュールに従い、前記システム内部にインストールされたスキャン端末に対して、パッシブスキャン又はアクティブスキャンを選択的に実行するスキャン指示を生成するステップと、
   前記検知されたエンティティの属性情報、又は、前記システムの運転状態に応じてパッシブスキャン又はアクティブスキャンを切り替えるステップと、
   第１のスキャン端末が利用可能になる第１のタイミングの後に、前記第１のスキャン端末よりも多くの情報を収集可能な第２のスキャン端末が利用可能になる第２のタイミングが到来する場合、前記第２のタイミングまで、前記検知されたエンティティが前記期待仕様を充足する度合いを前記第１のスキャン端末に暫定的に判定させるステップと、
   前記第２のタイミングが到来した後に、前記検知されたエンティティが前記期待仕様を充足する度合いを前記第２のスキャン端末に再度判定させるステップと、
   を実行することを特徴とするトラスト管理方法。