図面 (/)

技術 情報処理方装置、情報処理装置の制御方法、およびコンピュータプログラム

出願人 キヤノン株式会社
発明者 沖原健一
出願日 2015年3月2日 (3年10ヶ月経過) 出願番号 2015-040749
公開日 2016年9月5日 (2年4ヶ月経過) 公開番号 2016-162233
状態 特許登録済
技術分野 ストアードプログラムにおける機密保護
主要キーワード カーネルスレッド 脆弱性評価 アクセスログ解析 接続アプリケーション 常駐プロセス システムコール処理 アプリケーションテーブル 強制アクセス制御
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年9月5日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (11)

課題

強制アクセス制御の機能を有する情報処理方装置において、セキュリティ強度を維持しつつ、キュリティポリシー更新における作業負荷を軽減させる方法、およびコンピュータプログラムを提供する。

解決手段

強制アクセス制御の機能を有する情報処理装置であって、強制アクセス制御によってアクセスを管理するためのセキュリティポリシーを保持する保持手段113と、アプリケーション脆弱性に関する情報を取得する取得手段118と、取得手段で取得された情報に基づき、カーネルスレッドの機能で、セキュリティポリシーを更新する更新手段114と、を有する。

概要

背景

一般的なコンピュータシステムにおいては、通常、システム内の重要な情報にアクセスするためにはシステム管理者権限が必要になる。これは、システム管理者のみがシステム内の重要な情報にアクセスできるようにすることよって、悪意のある者によるコンピュータシステムの改竄などを防止するための仕組みである。

しかしながら、一方で、システム管理者の権限が悪意のある者に取られてしまうと、
コンピュータシステムの改竄などが容易に行われてしまう危険性もある。そこで、システム管理者の権限を持っていても、システムの特定の実行プロセスファイル、及びデバイスなどのコンピュータ資源へのアクセスを制限する仕組みがいくつか提案されている。

提案されている仕組みの一つに、強制アクセス制御(Mandatory Access Control、MACと呼ぶ)がある。これは、予め作成したセキュリティポリシー(以下、ポリシー)に基づいて、実行プロセスやファイルへのアクセスを制御するものである。特許文献1には、MACに関する技術が開示されている。

概要

強制アクセス制御の機能を有する情報処理方装置において、セキュリティ強度を維持しつつ、キュリティポリシーの更新における作業負荷を軽減させる方法、およびコンピュータプログラムを提供する。強制アクセス制御の機能を有する情報処理装置であって、強制アクセス制御によってアクセスを管理するためのセキュリティポリシーを保持する保持手段113と、アプリケーション脆弱性に関する情報を取得する取得手段118と、取得手段で取得された情報に基づき、カーネルスレッドの機能で、セキュリティポリシーを更新する更新手段114と、を有する。

目的

本発明は、上記課題を鑑みてなされたものであり、強制アクセス制御の機能を有する情報処理方装置において、セキュリティ強度を維持しつつ、セキュリティポリシーの更新における作業負荷を軽減させることを目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

強制アクセス制御の機能を有する情報処理装置であって、前記強制アクセス制御によってアクセスを管理するためのセキュリティポリシーを保持する保持手段と、アプリケーション脆弱性に関する情報を取得する取得手段と、前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記セキュリティポリシーを更新する更新手段と、を有することを特徴とする情報処理装置。

請求項2

前記取得手段で取得された情報は、前記アプリケーションによるアクセスのログであることを特徴とする請求項1に記載の情報処理装置。

請求項3

前記取得手段で取得された情報に基づき、前記アプリケーションによる所定のファイルへのアクセス数所定値以上であるか否かを判定する判定手段を更に有し、前記更新手段は、前記判定手段によって前記アクセス数が所定の値以上であると判定された場合、カーネルスレッドの機能で、前記セキュリティポリシーを更新することを特徴とする請求項1に記載の情報処理装置。

請求項4

前記取得手段で取得された情報は、前記アプリケーションの新たに発見された脆弱性の情報であることを特徴とする請求項1に記載の情報処理装置。

請求項5

前記更新手段は、前記新たに発見された脆弱性に該当するアプリケーションが前記情報処理装置に存在する場合、カーネルスレッドの機能で、前記セキュリティポリシーを更新することを特徴とする請求項4に記載の情報処理装置。

請求項6

前記更新手段は、前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記アプリケーションによる所定のアクセスを拒否するルールを追加することによって、前記セキュリティポリシーを更新する請求項1乃至5のいずれか1項に記載の情報処理装置。

請求項7

前記更新手段は、前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記アプリケーションによる所定のアクセスを拒否するルールを含むセキュリティポリシーを新規作成することによって、前記セキュリティポリシーを更新する請求項1乃至5のいずれか1項に記載の情報処理装置。

請求項8

強制アクセス制御の機能を有する情報処理装置の制御方法であって、保持手段が、前記強制アクセス制御によってアクセスを管理するためのセキュリティポリシーを保持する保持工程と、取得手段が、アプリケーションの脆弱性に関する情報を取得する取得工程と、更新手段が、前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記セキュリティポリシーを更新する更新工程と、を有することを特徴とする情報処理装置の制御方法。

請求項9

コンピュータを、強制アクセス制御の機能を有する情報処理装置であって、前記強制アクセス制御によってアクセスを管理するためのセキュリティポリシーを保持する保持手段と、アプリケーションの脆弱性に関する情報を取得する取得手段と、前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記セキュリティポリシーを更新する更新手段と、を有することを特徴とする情報処理装置として機能させるためのコンピュータプログラム

技術分野

0001

本発明は、強制アクセス制御の機能を有する情報処理方装置、情報処理装置制御方法、およびコンピュータプログラムに関する。

背景技術

0002

一般的なコンピュータシステムにおいては、通常、システム内の重要な情報にアクセスするためにはシステム管理者権限が必要になる。これは、システム管理者のみがシステム内の重要な情報にアクセスできるようにすることよって、悪意のある者によるコンピュータシステムの改竄などを防止するための仕組みである。

0003

しかしながら、一方で、システム管理者の権限が悪意のある者に取られてしまうと、
コンピュータシステムの改竄などが容易に行われてしまう危険性もある。そこで、システム管理者の権限を持っていても、システムの特定の実行プロセスファイル、及びデバイスなどのコンピュータ資源へのアクセスを制限する仕組みがいくつか提案されている。

0004

提案されている仕組みの一つに、強制アクセス制御(Mandatory Access Control、MACと呼ぶ)がある。これは、予め作成したセキュリティポリシー(以下、ポリシー)に基づいて、実行プロセスやファイルへのアクセスを制御するものである。特許文献1には、MACに関する技術が開示されている。

先行技術

0005

特開2012−18102号公報

発明が解決しようとする課題

0006

上述の通りに、情報処理装置にMACを適用するためには、ポリシーを作成しておく必要がある。通常、ポリシーは、コンピュータシステムの構築者などによってあらかじめ作成されている。

0007

しかしながら、一般的に、オペレーティングシステムアプリケーションプログラムには未知脆弱性が多く存在する。そして、未知の脆弱性が発見されると、当該脆弱性を利用した不正アクセスが発生することがある。このような不正アクセスの発生は、あらかじめ作成したポリシーでは想定されておらず、あらかじめ作成したポリシーを使い続けると、不正アクセスを許容することになりかねない。よって、ポリシーを更新する必要があるが、未知の脆弱性の発見やその他の情報に基づき、ポリシーを逐次更新することは、コンピュータシステムの管理者にとって大きな作業負荷となってしまう。一方で、ユーザーインターフェースを持つ特定のアプリケーションにポリシーを自動的に更新させると、当該特定のアプリケーションが悪意のある者に乗っ取られてしまった場合、不正アクセスを許すことになりかねない。

0008

本発明は、上記課題を鑑みてなされたものであり、強制アクセス制御の機能を有する情報処理方装置において、セキュリティ強度を維持しつつ、セキュリティポリシーの更新における作業負荷を軽減させることを目的とする。

課題を解決するための手段

0009

上記課題を鑑み、本発明は、強制アクセス制御の機能を有する情報処理装置であって、前記強制アクセス制御によってアクセスを管理するためのセキュリティポリシーを保持する保持手段と、アプリケーションの脆弱性に関する情報を取得する取得手段と、前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記セキュリティポリシーを更新する更新手段と、を有することを特徴とする。

発明の効果

0010

本発明によれば、強制アクセス制御の機能を有する情報処理方装置において、セキュリティ強度を維持しつつ、セキュリティポリシーの更新における作業負荷を軽減させることが出来る。

図面の簡単な説明

0011

(A)情報処理装置の全体構成を示す模式図である。(B)情報処理装置のプログラム構成を示す模式図である。
(A)第1の実施形態におけるOS110の構成を示す概略図である。(B)プロセス情報117の例を示す図である。
第1の実施形態におけるポリシー更新処理フローチャートである。
第1の実施形態における強制アクセス制御処理のフローチャートである。
第2の実施形態におけるポリシー更新処理のフローチャートである。
(a)〜(d)ポリシーの例を示す図である。
(a)、(b)アクセスログの例を示す図である。
(a)既知脆弱性情報の例を示す図である。(b)アプリケーションテーブルの例を示す図である。
第1の実施形態におけるアクセスログ解析処理のフローチャートである。
第2の実施形態におけるOS110の構成を示す概略図である。

実施例

0012

以下、本発明の一実施形態である第1の実施形態について図面を用いて説明する。

0013

(第1の実施形態)
本実施形態は、アプリケーションのアクセスを強制的に管理する強制アクセス制御の機能を有する情報処理装置に関するものである。本実施形態では、カーネルスレッドの機能を用いて、アクセスログを解析し、対応するアプリケーションのポリシー(セキュリティポリシー)の更新又は新規作成を行う。カーネルスレッドは、一般的にユーザーインターフェースを持たないため、悪意のある者に操作されてしまう可能性が低い。よって、ポリシーの更新においてセキュリティ強度を維持することが可能となる。

0014

(情報処理装置の全体構成)
図1(A)は、本実施形態における情報処理装置100の全体構成を示したものである。

0015

情報処理装置100は、CPU101、ROM102、RAM103、I/F104、HDD105、操作部106、表示部107、およびエンジン108を有する。そして、それぞれの構成はバス109で接続されている。

0016

CPU101はROM102に格納されたコンピュータプログラムに沿って情報処理装置100内の各部の動作を制御する。また、RAM103にロードしたコンピュータプログラム(OS(Operating System)やアプリケーション)を実行したりする。ROM102は、読み出し専用メモリであり、ブートプログラムファームウェア、後述する処理を実現するための各種コンピュータプログラム、各種データが格納されている。RAM103はCPU101にて処理を行うために一時的にプログラムやデータを格納しておくワークメモリであり、CPU101により各種コンピュータプログラムやデータがロードされる。

0017

I/F104はネットワーク機器USBデバイスといった外部装置通信するためのインタフェースである。ネットワークを通じたデータ通信や、外部装置とデータの送受信を行う。HDD105はOSや各種コンピュータプログラム、または各種データを保持する不揮発性記憶装置である。

0018

次に、本実施形態における情報処理装置100のコンピュータプログラムの構成を図1(B)に示す。本実施形態における情報処理装置100は、OS110と複数のアプリケーション111を動作させる。複数のアプリケーション111は、OS110上で動作するコンピュータプログラムである。

0019

アプリケーション111は、情報処理を実施するものであれば、どのようなものでも良い。例えば、文書編集アプリケーション画像編集アプリケーションおよびWeb接続アプリケーションなどがある。また、プリント処理アプリケーション、スキャン処理アプリケーション、コピー処理アプリケーションなどもある。アプリケーション111がデータをHDD105に書き込む場合には、OS110を介して書込み処理を実施する。読出し処理も同様になる。読み書きの際には、OS110は、HDD105の論理アドレスを指定してHDD105に対する読み書きを実施する。

0020

(OS110の論理構成
図2(A)は図1のOS110の機能構成を示す模式図である。尚、以下のOS110の各機能の少なくとも一部は、カーネルスレッドで実行される。
また、図2(B)は、OS110上で動作するプロセスのプロセス情報117の例を示す図である。なお、OS110の各機能はCPU101がOSのプログラムコードを実行することにより実現される。

0021

脆弱性情報解析部118は、OS110の起動とともに起動する常駐プロセスである。

0022

起動後は、定期的(例えば、一時間ごとや一日ごと)にログDB112から取得したシステムのアクセスログを解析し、解析結果をポリシー処理部114に渡す。

0023

ポリシー処理部114は、脆弱性情報解析部118からアクセスログの解析結果、または制御対象のアプリケーション111のシステムコールおよびプロセス情報117を受け取ると次に述べる処理を実施する。アクセスログの解析結果を受け取った場合、ポリシー処理部114は解析結果に基づいて、ポリシーの更新または新規作成を行い、ポリシーDB113に渡す。一方、システムコールおよびプロセス情報117を受け取った場合、ポリシー処理部114は、システムコールと対応するポリシーをアクセス制御部115へ渡す。ここで、プロセス情報117は例えば、図2(B)で示される。1行目の「Status」はプロセスの情報を示しており、例えば、休眠中を示す「sleeping」や実行中を示す「running」などがある。2行目の「Pid」は各プロセスの識別子、3行目の「Cmdline」は、実行ファイルパスを示している。

0024

ポリシー処理部114が、仮に、キーボードマウスなどのインタフェースやネットワークを有していたとすると、悪意のある者に乗っ取られてしまう可能性がある。よって、本実施形態では、ポリシー処理部114は、ユーザーインターフェースを持たないOS110のカーネルスレッドとして機能する。強制アクセス制御でアクセスや処理を制御できる対象は、OS110のアプリケーションやコマンドなどのユーザ空間に存在するプログラムである。カーネルスレッドは、ユーザ空間とは別空間であるカーネル空間で処理される一関数である。よって、明示的にユーザ空間からのアクセスするためのユーザーインターフェースを実装しない限りは、ユーザからのアクセスが困難である。そのため、悪意のある者による乗っ取りを防ぐことが可能となる。

0025

アクセス制御部115は、制御対象のアプリケーション111に対応するポリシーに基づいて、システムコールから取得した要求を拒絶する。拒絶されない場合は、システムコール処理部116に要求を入力する。システムコール処理部116は要求に対応したシステムコール処理を行う。以上が、本実施形態におけるOS110の機能構成である。

0026

次に、OS110の<強制アクセス制御処理>と<ポリシー更新処理>について説明する。

0027

(強制アクセス制御処理)
図4は、ROMに格納されたOS110によって実行される強制アクセス制御処理を示すフローチャートである。以下では、図2(A)の各構成と対応づけて説明する。

0028

まず、図4のステップS401において、図2(A)のポリシー処理部114がアプリケーション111から発行されたシステムコール(OSへの要求)を取得する。

0029

ステップS402において、図2(A)のポリシー処理部114が強制アクセス制御をするか否かを判定する。強制アクセス制御をする場合(YES)は、ステップS403に進む。そして、ステップS403において、図2(A)のポリシー処理部114がポリシーDB113から各アプリケーションのポリシーを入力し、アクセス制御部115に渡す。

0030

一方、ステップS402において、強制アクセス制御をしない場合(NO)は、ステップS405に進む。そして、ステップS405において、図2(A)のシステムコール処理部116がアプリケーションからの要求を処理するシステムコール処理を行い、OS110の処理を終了する。

0031

ステップS404において、図2(A)のアクセス制御部115が入力されたポリシーに基づいてアプリケーション111がアクセスするコンピュータ資源のアクセス要求許可するか否かを判定する。アクセス要求を許可する場合(YES)は、ステップS405に進む。そして、ステップS405において、図2(A)のシステムコール処理部116がアプリケーションからの要求を処理するシステムコール処理を行い、OS110処理を終了する。

0032

一例として、アプリケーション「App1」がファイル「/usr/local/user_data/text.txt」を読み込む要求が入力された場合について説明する。このような入力があった場合、図6(a)の601にあるポリシーが入力される。601の601aには、どのアプリケーションのポリシーかを示すために、アプリケーションの実行ファイルのパスが記述されている。601bには、具体的なルールが記載されており、ファイル毎一行ずつ記載されている。各行の前半はファイルのパス名を示し、後半は許可する制御情報が記載される。「read」と記載されていれば、読み取りを許可し、「write」と記載されていれば、書き込みを許可する。例えば、601cの行は、ファイル「/usr/bin/App1」の読み取りを許可する。なお、特殊な記号を使用して一行で複数のファイルのルールをまとめて記載しても良い。例えば、602dの「/usr/local/user_data/* read」は「/usr/local/user_data」フォルダ以下にあるファイル全ての読み取りを許可することになる。

0033

そして、今回は、「/usr/local/user_data」フォルダ以下にある「text.txt」の読み取りは許可されているため、この要求は許可され、処理が実行される。一方、ステップS404において、アクセス要求を許可しない場合(NO)は、要求を拒否し、OS110の処理を終了する。

0034

(ポリシー更新処理)
図3は、OS110で実行されるポリシー更新処理の詳細を示すフローチャートである。以下では、図2(A)の各構成と対応づけて説明する。なお、この処理は、あらかじめ定められた時間間隔で定期的に実施される。例えば、一時間ごとや一日ごとに実施される。

0035

まず、図3のステップS301において、図2(A)の脆弱性情報解析部118がログDB112からアクセスログを取得する。例えば、図7(a)に示す701、図7(b)に示す702のようなアクセスログを取得する。

0036

次に、ステップS302において、図2(A)の脆弱性情報解析部118がステップS301で取得したアクセスログを解析する。解析は異常なアクセスの有無の観点で行われる。ステップS302の具体的な処理は、例えば、図9(a)や図9(b)に示す処理になる。ステップS302の具体的な処理として、図9(a)および図9(b)に示す処理について説明する。

0037

図9(a)の処理では、同じファイルへのアクセスが異常に多いか否かで異常なアクセスを判定している。

0038

まず、ステップS302aにおいて、同じファイルへのアクセス数が所定の閾値TH_A以上か否かを判定する。閾値TH_Aは、例えば100などと設定しておいても良い。閾値TH_A以上の場合(YES)は、ステップS302bに進み、ステップS302bにおいて、異常発見フラグをONにする。なお、異常発見フラグの初期値は<ポリシー更新処理>の開始前はOFFである。閾値TH_A未満の場合(NO)は、処理を終了する。

0039

例えば、図7(a)の701の場合は、701aの各行のファイルアクセスカウントすると、同じファイル「text.txt」へ140回アクセスがあるので、閾値TH_A以上となる。ステップS302cにおいて、閾値TH_A以上の対象ファイルのパスを記録する。以上が、図9(a)の処理である。

0040

一方で、図9(b)の処理は、不明なIPアドレスからのアクセスが異常に多いか否かで異常なアクセスを判定している。

0041

まず、ステップS302dにおいて、不明なIPアドレスを持つ端末からのアクセスが閾値TH_B以上か否かを判定する。閾値TH_Bは例えば、10とする。閾値TH_B以上の場合(YES)は、ステップS302bに進み、ステップS302bにおいて、異常発見フラグをONにする。閾値TH_B未満の場合(NO)は、処理を終了する。例えば、図7(b)の702の場合は、702aの不明なIPアドレスをカウントすると、同じ不明なIPアドレス「XXX.XXX.XXX.YYY」から30回アクセスがあるので、閾値TH_B以上となる。ステップS302eにおいて、閾値TH_B以上の対象IPアドレスを記録する。以上が図9(b)の処理である。

0042

なお、ステップS302における、同じファイルへのアクセスや同じIPアドレスからのアクセスのカウントは、シェルスクリプトやPerlなどを使用して文字列カウントすれば良い。

0043

ステップS303において、図2(A)における脆弱性情報解析部118が異常発見フラグを検知し、異常が発見されたか否かを判定する。異常発見フラグがONになっており、異常が発見された場合(YES)は、ステップS304に進む。そして、図2(A)のポリシー処理部114がポリシーDB113から各アプリケーションのポリシーを入力する。異常発見フラグがOFFになっており、異常が発見されない場合(NO)は、処理を終了する。

0044

ステップS305においては、図2(A)のポリシー処理部114によって、異常が発見されたアプリケーションのポリシーがあるか否かを判定する。ポリシーがある場合(YES)は、ステップS306に進み、図2(A)のポリシー処理部114がポリシーを更新して処理を終了する。更新方法としては、2つある。一つは、異常アクセスがあったファイルへのアクセスや異常なアクセスがあったIPアドレスからのアクセスを拒否するルールのみを追加する方法である。例えば、元のポリシーが図6(a)の601だとすると、図6(b)の602bや602cのようにルールを追加する。ルールの先頭に「deny」を記述することで拒否するルールになる。なお、602cはIPアドレス「XXX.XXX.XXX.YYY」からの全て「ALL」のアクセスを拒否する。もう一つは、拒否する範囲を拡大して追加する方法である。異常アクセスがあったファイルが所属するフォルダへのアクセスを拒否したり、異常なアクセスがあったIPアドレスがあれば、全ての外部のIPアドレスを拒否するルールのみを追加する。例えば、元のポリシーが図6(a)の601だとすると、図6(c)の603bや603cのようにルールを追加する。なお、603cは全ての外部のIPアドレス「OUTSIDE_IP_ALL」からの全て「ALL」のアクセスを拒否する。また、他の更新方法があれば、その方法を適応しても良い。

0045

一方、ポリシーがない場合(NO)は、ステップS307に進み、図2(A)のポリシー処理部114がポリシーの新規作成を行い、処理を終了する。ポリシーの新規作成は、例えば、まずは、たたき台として、図6(a)の601aに示すようなアプリケーションの実行ファイルのパスおよび601bに示すような実行ファイルの読み込みを許可のルールのみのポリシーを作成する。次に、異常アクセスが見つかったファイルの読み込みを拒否するルールを追加する。

0046

なお、上記実施形態では、異常アクセスが発見されたら、ポリシーを更新した。しかし、異常アクセスが無くなったり、異常アクセスに対応したアプリケーションのパッチが適応されたら、元のポリシーに戻しても良い。

0047

(第2の実施形態)
第1の実施形態では、まず、アクセスログを解析した。そして、特定のアプリケーションへの攻撃がされているとみなすことが出来る場合は、カーネルスレッドを用いて、対応するアプリケーションのポリシー更新または新規作成を行った。本実施形態では、アプリケーションが既知となった脆弱性に対応していない場合に、カーネルスレッドを用いて、既知となった脆弱性情報に基づき、ポリシー更新または新規作成を行う。これによって、ポリシーを手動で更新または新規作成することなく、既知となった脆弱性にアプリケーションを対応させることが出来る。

0048

本実施形態と第1の実施形態とは、(OS110の論理構成)の一部と(ポリシー更新処理)のみが異なり、それ以外は全て同じである。よって、以下では、(OS110の論理構成)の第1の実施形態からの差分と(ポリシー更新処理)のみを説明する。

0049

(OS110の論理構成)
図10は、本実施形態におけるOS110の機能構成を示す模式図である。なお、OS110の各機能はCPU101がOSのプログラムコードを実行することにより実現される。また、ポリシーDB113、アクセス制御部115、システムコール処理部116及びプロセス情報117は、図2(A)の同一名称の各部と同様なので、説明は省略する。

0050

脆弱性情報解析部118は、OS110の起動とともに起動する常駐プロセスである。起動後は、定期的にOS110の外部にある通信ネットワーク119を通じて、既知脆弱性情報DB120から、新たに既知となった脆弱性情報を取得する。取得する間隔は、例えば、一時間ごとや一日ごとなどに設定しておけばよい。既知となった脆弱性情報は、例えば、CVE(Common Vulnerabilities and Exposures)で示され、図8(a)に示すようなものである。そして、既知となった脆弱性情報とOS110の内部にある図8(b)に示すようなアプリケーションテーブルとを比較した後、既知となった脆弱性情報を解析する。解析後、解析結果をポリシー処理部114に渡す。

0051

また、ポリシー処理部114は、脆弱性情報解析部118から既知となった脆弱性情報の解析結果、または制御対象のアプリケーション111のシステムコールおよびプロセス情報117を受け取ると次に述べる処理を実施する。既知となった脆弱性情報の解析結果を受け取った場合、ポリシー処理部114は解析結果に基づいて、ポリシーの更新または新規作成を行い、ポリシーDB113に渡す。一方、システムコールおよびプロセス情報117を受け取った場合、ポリシー処理部114は、システムコールと対応するポリシーをアクセス制御部115へ渡す。

0052

ここで、第1の実施形態と同様に、ポリシー処理部114は、ユーザーインターフェースを持たないカーネルスレッドとする。これによって、悪意のある者による乗っ取りを防ぐことが可能となる。

0053

(ポリシー更新処理)
図5は、OS110におけるポリシー更新処理の詳細を示すフローチャートである。図2(A)の各構成と対応づけて説明する。なお、この処理は第1の実施形態と同様に定期的に実施する。

0054

まず、図5のステップS501において、図2(A)の脆弱性情報解析部118がOS110の外部にある既知脆弱性情報DBから、新たに既知となった脆弱性情報を取得する。例えば、図8(a)に示すような脆弱性情報を取得する。

0055

次に、ステップS502においては、図2(A)の脆弱性情報解析部118によって、発見された脆弱性に該当するアプリケーションが存在するか否かを判定する。当該判定は、脆弱性情報に記載されたアプリケーションの情報とOS110の内部にあるアプリケーションテーブルとを比較して行われる。具体的には、まず、アプリケーションテーブルに記載されたアプリケーション名が脆弱性情報のタイトル概要に対する存在するかを既存の文字列検索を使用して行う。検索して該当するアプリケーション名があった場合は、バージョンが該当するかについて同様に文字列検索する。例えば、図8(a)の脆弱性情報と図8(b)のアプリケーションテーブルを用いた場合は、801aの「App1 before 5」を見ると、まず、アプリケーション名が802aの「App1」と一致することが分かる。次に、801aからバージョンが「5以前」だと分かるので、802bの「4.2」が該当することが分かる。従って、脆弱性情報に対応していないバージョンだと分かる。

0056

脆弱性が発見されたアプリケーションが存在する場合(YES)は、ステップS503に進み、ステップS503において、脆弱性情報を解析する。アプリケーションのどこの部分に脆弱性があるのかを「func」や「process」などの機能や処理を示す文字列から分かる範囲で解析する。例えば、図8(a)の脆弱性情報の場合は、801bより「hoge」機能で脆弱性があることが分かる。

0057

一方、脆弱性が発見されたアプリケーションが存在しない場合(NO)は、処理を終了する。

0058

ステップS504においては、図2(A)のポリシー処理部114がポリシーDB113から各アプリケーションのポリシーを入力する。

0059

ステップS505においては、図2(A)のポリシー処理部114によって、異常が発見されたアプリケーションのポリシーがあるか否かを判定する。ポリシーがある場合(YES)は、ステップS506に進み、図2(A)のポリシー処理部114がポリシーを更新して処理を終了する。例えば、図8(a)の脆弱性情報の場合は、「hoge」機能に関するデータを拒否するルールを追加する。その場合は、図6(a)の601に示すポリシーが図6(d)の604に示すポリシーに変更される。604bに示すルールは「hoge」機能に関するデータを拒否するルールである。また、第1の実施形態のステップS306で説明したように、拒否する範囲を拡大して追加したり、他の更新方法があれば、その方法を適応しても良い。

0060

一方、ポリシーがない場合(NO)は、ステップS507に進み、図2(A)のポリシー処理部114がポリシーの新規作成を行い、処理を終了する。ポリシーの新規作成は、第1の実施形態のステップS307で説明した例と同様に行えば良い。

0061

なお、上記実施形態では、既知となった脆弱性情報に該当するアプリケーションがあれば、ポリシーの更新や新規作成を行った。しかしながら、深刻な脆弱性のみに対応し、軽微な脆弱性には対応しないことで、ポリシーの更新や新規作成の処理の負荷を軽減しても良い。具体的には、例えば、CVEでは、脆弱性の共通脆弱性評価システムCVSS(Common Vulnerability Scoring System)のベーススコアが記載されている。このスコアが高いほど、脆弱性の深刻だと判断できる。そのため、ベーススコアが一定以上の場合のみ、ポリシーの更新または新規作成を行っても良い。

0062

(第3の実施形態)
第1の実施形態では、まずアクセスログを解析した。そして、特定のアプリケーションへの攻撃がされていると見なすことが出来る場合は、ユーザーインターフェースを持たないカーネルスレッドを用いて、対応するアプリケーションのポリシー更新または新規作成を行った。

0063

第2の実施形態では、アプリケーションが新たに既知となった脆弱性に対応していない場合に、ユーザーインターフェースを持たないカーネルスレッドを用いて、既知となった脆弱性情報を基づき、アプリケーションのポリシー更新または新規作成を行った。

0064

本実施形態では、上記の2つの実施形態を組み合わせる。これによって、未知脆弱性と、新たに既知となった脆弱性の両方に対応したポリシーの更新または新規作成を効率的に行うことが出来る。

0065

第1の実施形態とは、(OS110の論理構成)の一部と(ポリシー更新処理)のみが異なり、それ以外は全て同じである。以下では、(OS110の論理構成)の第1の実施形態からの差分と(ポリシー更新処理)のみ説明する。

0066

(OS110の論理構成)
第1の実施形態からの差分は以下の通りである。脆弱性情報解析部118は、OS110の起動とともに起動する常駐プロセスである。起動後は、定期的(例えば、一時間ごとや一日ごと)にログDB112から取得したシステムのアクセスログを解析し、解析結果をポリシー処理部114に渡す。それに加えて、図10に示すようなOS110の外部にある通信ネットワーク119を通じて既知脆弱性情報DB120から既知となった脆弱性情報を取得する。そして、既知となった脆弱性情報とOS110の内部にある図8(b)に示すようなアプリケーションテーブルを比較する。比較後、既知となった脆弱性情報を解析し、解析結果をポリシー処理部114に渡す。

0067

また、ポリシー処理部114は脆弱性情報解析部118からアクセスログまたは既知となった脆弱性情報の解析結果、または制御対象のアプリケーション111のシステムコールおよびプロセス情報117を受け取ると次に述べる処理を実施する。アクセスログまたは既知となった脆弱性情報の解析結果を受け取った場合、ポリシー処理部114は解析結果に基づいて、ポリシーの更新または新規作成を行い、ポリシーDB113に渡す。一方、システムコールおよびプロセス情報117を受け取った場合、ポリシー処理部114は、システムコールと対応するポリシーをアクセス制御部115へ渡す。

0068

ここで、ポリシー処理部114は、第1の実施形態と同様に、ユーザーインターフェースを持たないカーネルスレッドとする。これによって、攻撃者による乗っ取りを防ぐ。以上が第1の実施形態からの差分であり、その他は第1の実施形態と同様である。

0069

(ポリシー更新処理)
本実施形態では、第1の実施形態の(ポリシー更新処理)と第2の実施形態の(ポリシー更新処理)の両方を定期的に実施する。

0070

(その他の実施例)
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。

0071

114ポリシー処理部
118脆弱性情報解析部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

新着 最近 公開された関連が強い 技術

この 技術と関連性が強い 技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する挑戦したい社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ