JP2022506495A - セキュリティ監視処理のためのシステム及び方法 - Google Patents

Abstract

コンピュータによって実行される方法はセキュリティイベントの監視のために使用することができる。前記方法は、第１のオペレーティングシステムのセキュリティモジュールからデータを受け取ることと、セキュリティイベント監視アプリケーションによる収集のための監査クラスデータフィルタを定義することとを含んでもよい。さらに前記方法は、前記データと前記監査クラスデータフィルタとを比較することと、前記データと一連のブラックリストに登録された値とを比較することとを含んでもよい。更に前記方法は、前記データの、前記監査クラスデータフィルタ及び前記ブラックリストに登録された値との比較に基づき、共通構造フォーマットのデータを出力することを含んでもよい。

Description

本開示の様々な実施形態は、概して、オペレーティングシステムにおいて行われる監視プロセスに関し、より具体的には、オペレーティングシステム環境においてセキュリティに関するアクションを行うことに関する。

ネットワーク攻撃及びサイバーセキュリティはセキュリティ面を気にする企業にとって重要な問題である。全ての市場における事業や規制環境において、そのネットワークに接続された全てのコンピュータに対して、信頼できる監査とログ記録対策を行うことが求められている。伝統的なセキュリティ上のソリューションでは企業に対し予防的なエンドポイント防御を提供することができ、その際、ソフトウェアはコンピューティングデバイスに入る新しいファイルに反応し、そのファイルが悪意のあるものと認められれば、自動的にそのファイルがそのデバイス内で実行されないようにする。しかしながら、このような防御を起動させることなくアタッカーはなおコンピューティングデバイスに侵入することができる。

現行のオペレーティングシステムは、コンピューティングデバイスで実行される処理の収集及び監視のための組み込み型のツールを含んでいることがある。例えば、Ａｐｐｌｅ（商標）はｍａｃＯＳ（商標）が実行される全てのコンピュータにプレインストールされる形でＯｐｅｎＢＳＭの最新バージョンを出荷している。ＯｐｅｎＢＳＭはサン・マイクロシステムズのベーシックセキュリティモジュール（ＢＳＭ）監査ＡＰＩ及びファイル形式のオープンソース実装である。ＯｐｅｎＢＳＭは、ログインと監査のイベントをデフォルトの設定でのみ収集し、イベントは人間が読めるフォーマットでは保存されない。

しかしながら、既存のセキュリティソフトウェアツールは、オペレーティングシステムにあらかじめ組み込まれたＯｐｅｎＢＳＭのようなシステムを無視し、独自の収集方法と監視方法を構築し、多くの場合セキュリティ上の問題をオペレーティングシステムに持ち込む。したがって、既存のセキュリティソフトウェアを用いる企業は無意識のうちにそのコンピュータを危険にさらしていることがある。更に、ログ収集ツールは、ＯｐｅｎＢＳＭのログを所定の間隔で変換するアプリケーションやスクリプトがなければＯｐｅｎＢＳＭによって生成されたログを取り込むことができない。ネイティブのＯｐｅｎＢＳＭログフォーマットはリアルタイムでの監査や収集用には設計されていない。

さらに、ＯｐｅｎＢＳＭが生成するイベントを全て収集すると、既存のコンピュータシステムを著しくスローダウンさせて使用不能にする。例えば、全イベントの流れを観測すると、その観測の詳細を示すためのイベントが追加で生成されて無限ループが作成される。イベントが生成されるとコンピュータのスピードが落ちるため、この問題は時間が経てば必ず解消されるものではない。

特殊な条件下で、開発者のマシンでしか実行することができない概念実証コードを含む他の既存のツールもある。このツールは完全ではなく、スケールせず、遠隔管理するようには設計されていない。更に、このツールはＯｐｅｎＢＳＭを使用しない。ＯｐｅｎＢＳＭはＵｎｉｘ（商標）標準を使用することから、ある態様においては重要な場合がある。ＯｐｅｎＢＳＭは、非カーネルプログラムがセキュリティと監査の情報を収集するための唯一の方法である場合がある。他の収集方法にはベンダにカーネルレベルコードのインストールを求めるものもあり、これにより不安定さと新しいセキュリティ上の懸念が持ち込まれる。あるケースでは、第１のオペレーティングシステムでは特定のカーネル拡張しか実行できない場合があり、他のオペレーティングシステムに関するカーネル拡張が第１のオペレーティングシステムによって禁止される場合もある。

セキュリティイベントの監視、収集、ブロックのための独自のコードを優先し、ｍａｃＯＳにネイティブなシステムが無視される他のツールもある。ノンネイティブなツールセットではｍａｃＯＳのサブビルドごとに統合テストを行うことが要求される。ベンダのコードはシステムによって行われる全てのアクションを承認してからアクションを実行しなければならないことから、このベンダコードはシステム全体の不安定さとパフォーマンスの問題につながる。この従来のシステムではベンダのカーネル拡張（ｋｅｘｔｓ）が求められる。ｋｅｘｔｓによってセキュリティ上の重大な脆弱性の可能性が持ち込まれる。ｋｅｘｔｓはオペレーティングシステムの最下層のレベルで実行され、バグやエラーがあればシステムが完全にクラッシュしてしまう。ｍａｃＯＳ １０．１３．３＋上では、ｋｅｘｔｓはホワイトリストに登録されるか、ユーザによって承認される必要がある。

ベンダがベンダ自身のツールをアップデートできるように、会社でｍａｃＯＳのシステムアップデートを遅らせなければならなくなることがしばしば起こる。ベンダのツールをアップデートしないままｍａｃＯＳをアップデートすると、ＩＴからの専門的な支援を必要とするシステムが使用不能になることもよくある。ｍａｃＯＳの正確なバージョンに対応する正確なバージョンを持続的に求めることはほぼ不可能である。これらのツールは、処理や脅威の分析のために、（ファイル全体を含む）データをベンダのクラウドにアップロードする。ツールの中には、ログ分析を行うクラウドサーバであって、ベンダがホストであるクラウドサーバに対して直接データを送信するものがある。人間が可読なログはデバイスやクラウドの中に残らない。たとえそれが正確に行われたとしても、多くの組織は会社のデータを会社以外のシステムに置くことを望んでいない。Ｗｉｎｄｏｗｓ ＯＳは多くの会社において最も使用されているオペレーティングシステムであり、ほとんどのツールはまずＷｉｎｄｏｗｓ用に開発され、その後ｍａｃＯＳ用に開発される。

カーネル拡張は、ｍａｃＯＳ（例えば第１のオペレーティングシステム）上の最上位のパーミッションの下で実行されるコードであってもよく、また関連する操作のための実行チェーンに必要なリンクであってもよい。そのコードにエラーがあれば壊滅的なエラーを引き起こしかねない。アプリケーション実行と共に作動するカーネル拡張は、カーネルモジュールがその特定のアプリケーションと共に何かを行っているかどうかに関わらず、一つのアプリを実行するごとに必要とされるステップであってもよい。

既存のソリューションのための他の課題には、ｍａｃＯＳに対するドキュメンテーションのレベルが低く、ＯｒａｃｌｅのＳｕｎオペレーティングシステムからのドキュメンテーションが制限されている（時にはｍａｃＯＳにとって不適切である）ことが含まれる。セキュリティアプリケーションのベンダの中には、報告されている脅威よりもむしろ潜在的な脅威をブロックすることに対してより焦点を当てているところもある。

ｍａｃＯＳ専用に開発されたセキュリティアプリケーションは極めて少ない。典型的には、ｍａｃＯＳは二番目のプラットフォームであって第一の開発の焦点ではないことから、結果としてシステムのクラッシュにつながる。

本開示はこれら上述の課題のうちの１以上に対処することを目指す。本開示内の背景に関する記載は概して本開示の内容を提示する目的で記載されるものである。本開示において別段の指示がない限り、この項で述べる内容は、この項に取り入れることによって本願の特許請求の範囲に対する先行技術とするものではなく、また先行技術であることを認めるものでもなく、先行技術を示唆するものでもない。

本開示のある態様によれば、セキュリティイベントの監視を目的として、非一時的なコンピュータ可読媒体、システム、及び方法が開示される。本開示で開示される例はそれぞれ、他の開示された例のいずれかと関連付けて説明される１以上の特徴を含む。

ある例においては、コンピュータによって実行される方法はセキュリティイベントの監視のために使用することができる。上記方法は、１以上のプロセッサが、第１のオペレーティングシステムのセキュリティモジュールからデータを受け取ることと、上記１以上のプロセッサが、セキュリティイベント監視アプリケーションによる収集のための監査クラスデータフィルタを定義することと、上記１以上のプロセッサが、収集された監査クラスデータの量を定義する詳細度レベルとして、上記監査クラスデータフィルタの上記詳細度レベルを受け取ることと、上記１以上のプロセッサが、上記監査クラスデータフィルタの上記詳細度レベルに基づき上記データのフィルタリングを行うことと、上記１以上のプロセッサが、上記データと、上記監査クラスデータフィルタとを比較することと、上記データの、上記監査クラスデータフィルタとの比較に基づき、上記データが上記監査クラスデータと一致しないと判断された場合には上記１以上のプロセッサが上記データを削除することと、上記１以上のプロセッサが、上記データと、一連のブラックリストに登録された値とを比較することと、上記データの、上記一連のブラックリストに登録された値との比較に基づき、上記一連のブラックリストに登録された値の中の１以上のブラックリストに登録された値と上記データとが一致すると判断された場合には上記１以上のプロセッサが上記データを削除することと、上記監査クラスデータの一部であり、第１のコンピューティングデバイスによって行われるアクションに関する監査イベントデータを上記１以上のプロセッサが捕捉することと、上記１以上のプロセッサが、監査イベントの属性に関する少なくとも１つのトークンをトークン識別子に基づき決定することと、上記プロセッサが、上記少なくとも１つのトークンを共通構造フォーマットに構文解析することと、上記データの、上記監査クラスデータフィルタ及び上記ブラックリストに登録された値との比較に基づき、上記共通構造フォーマットのデータを上記１以上のプロセッサが出力することと、を含んでもよい。

本開示の別の態様によれば、セキュリティイベントの監視のための非一時的なコンピュータ可読媒体であって、上記非一時的なコンピュータ可読媒体は命令を格納し、上記命令は、１以上のプロセッサによって実行されると、上記１以上のプロセッサが、第１のオペレーティングシステムからデータを受け取り、上記１以上のプロセッサが、セキュリティイベント監視アプリケーションによる収集のための監査クラスデータフィルタを定義し、上記１以上のプロセッサが、上記データを上記監査クラスデータフィルタと比較し、上記１以上のプロセッサが、上記データと、一連のブラックリストに登録された値とを比較し、上記処理データの、上記監査クラスデータフィルタ及び上記ブラックリストに登録された値との比較に基づき、共通構造フォーマットのデータを上記１以上のプロセッサが出力する処理を行うように上記１以上のプロセッサを構成する命令である、非一時的なコンピュータ可読媒体が提供される。

本開示のさらに他の態様によれば、コンピュータによって実行される方法をセキュリティイベントの監視のために使用することができる。上記方法は、上記１以上のプロセッサが、第１のオペレーティングシステムからデータを受け取り、上記１以上のプロセッサが、（１）上記データと監査クラスデータフィルタとを比較すること、及び／又は（２）上記データと一連のブラックリストに登録された値とを比較すること、のうち少なくとも１つを行うことと、上記処理データの、上記監査クラスデータフィルタ及び上記ブラックリストに登録された値との比較に基づき、共通構造フォーマットのデータを上記１以上のプロセッサが出力することと、を含む。

開示された実施形態の追加の目的及び有利な点は、一部を以下の発明の詳細な説明において述べ、また一部は詳細な説明から明らかであるし、また開示された実施形態を実施することによって理解することもできる。

上記一般的な説明及び下記発明の詳細な説明は両方とも代表的かつ説明的なものでしかなく、特許請求の範囲に記載された内容のように、開示された実施形態に限定するものではないことを理解されたい。

本明細書に組み込まれ、本明細書の一部を構成する添付の図面は様々な代表的実施形態を例示するものであり、明細書と共に、開示される実施形態の基本原則を説明するのに役立つものである。

本開示のシステム、方法、及び他の態様を実行することができる代表的な環境を示す。

本開示の一態様に係る、セキュリティイベント監視の代表的なフロー図を示す。

本開示の一態様に係る、フィルタを用いたセキュリティイベント監視の代表的なフロー図を示す。

本開示の一態様に係る、イベントトークン処理の代表的なフロー図を示す。

本開示の一態様に係る、セキュリティイベント監視の構成の代表的なフロー図を示す。

本開示の一態様に係る、相互参照制御の代表的なフロー図を示す。

本開示の一態様に係る、詳細な相互参照エンジンプロセスの代表的なフロー図を示す。

本開示の一態様に係る、セキュリティイベント監視ツールの構成の更新の代表的なフロー図を示す。

本開示の実施形態又はその一部が実行されてもよい代表的なコンピュータデバイス又はシステムを示す。

発明の詳細な説明

以下、添付の図面を参照しつつ本明細書の主題をより完全に述べる。図面は本願の一部であり、例示的手段により、特定の代表的実施形態を示す。「代表的（例示的）」として本開示で説明される実施形態や実装形態は、例えば、他の実施形態や実装形態を上回るような好ましい例や有利な例として解釈されるべきものではなく、むしろその実施形態が「例」としての実施形態であることを反映又は指示していることを意図している。主題は様々な異なる形態で具体化することができ、そのため請求項でカバーされ、請求項に記載された主題は、本開示で述べる代表的な実施形態に限定されないものと解釈されることを意図している。代表的な実施形態は、ただ例示としてのみ提示される。同様に、特許請求の範囲に記載され、特許請求の範囲によってカバーされる主題は合理的な広さの範囲を有していることを意図している。とりわけ、例えば、主題は方法、装置（デバイス）、部品、又はシステムとして具体化されてもよい。したがって、実施形態は、例えばハードウェア、ソフトウェア、ファームウェア、又はそれらのいずれかの組み合わせ（但しソフトウェアそれ自体を除く）の形態をとってもよい。したがって、下記の詳細な説明は限定的な意味に解釈されるものではないことを意図している。

明細書及び請求項を通して、用語は、明確に述べられた意味を超えて、文脈において示唆又は暗示されているようなニュアンスの意味を有していることもある。同様に、本開示で使用される「ある実施形態において」という句は必ずしも同一の実施形態のことを指すのではなく、本開示で使用される「別の実施形態において」という句は必ずしも別個の実施形態のことを指すのではない。例えば、特許請求の範囲に記載された主題は、代表的な実施形態の全体又は一部の組み合わせを含むことを意図している。

下記で用いる用語は、たとえそれが本開示のある特定の例の詳細な説明と関連付けて使用される場合であっても、最も広い合理的な意味に解釈されてもよい。実際、ある特定の用語は下記において強調されてもよい。しかしながら、何らかの限定的な意味に解釈されることを意図した用語は、この発明の詳細な説明の章においては、限定的であることが明白かつ具体的に定義される。上記一般的な説明及び下記発明の詳細な説明は両方とも代表的かつ説明的なものでしかなく、特許請求の範囲に記載された特徴のように限定的なものではない。

本開示において「に基づく」という語は「少なくとも部分的に基づく」の意味である。単数形「ａ」、「ａｎ」、及び「ｔｈｅ」は、文脈上そうでないことが別途指示されない限り、複数の指示対象を含む。「代表的（例示的）」という語は「理想的」というよりも「例」の意味で使用される。「又は」という語は包括的であることを意味し、挙げられた項目のどちらか、いずれか、数種の、又は全てを意味する。「含む・含有する（ｃｏｍｐｒｉｓｅｓ、ｃｏｍｐｒｉｓｉｎｇ、ｉｎｃｌｕｄｅｓ、ｉｎｃｌｕｄｉｎｇに相当）」やその変形は、列挙された要素を含むプロセス、方法、又は製品が必ずしもそれらの要素以外のものを含まないのではなく、明示的に列挙されてない他の要素や、それらのプロセス、方法、物品、又は装置が本来供えている要素をも含んでもよいように排他的包含（ｎｏｎ－ｅｘｃｌｕｓｉｖｅ ｉｎｃｌｕｓｉｏｎ）をカバーすることを意図している。「実質的に」や「概して（一般的に）」などの相対的な語は、記載された値又は理解される値の±１０％の起こりうる変動を示すのに使用される。

上述のように、ソフトウェアセキュリティソリューションは十分な保護を提供できないこともあり、コンピューティングデバイスにさらなる安定さを持ち込むこともある。したがって、開示されたシステムに対し、例えばコンピューティングシステム上の実行可能なアクションやアクティビティを検出し、実行可能なアクションやアクティビティがシステム上で起動されたことを示す警告を出し、実行可能なアクションやアクティビティの有効性を検証し、もし有効であればその実行可能なアクションやアクティビティを処理し、有効でなければ、そのアクションやアクティビティを、警告が付随した状態で進行させる応答を作成するか、あるいはそのアクションやアクティビティを止めるか減らすように構成された全自動インテリジェントプログラマブルシステム、及び／又はそのようなアクティビティやアクションを監視し記録することに対するニーズが存在する。

本開示の実施形態は、セキュリティ動作検出器の役割を１つ以上果たすことができるシステム又は方法に関する。例えば、本開示で開示するシステム及び方法は、例えばｍａｃＯＳ（商標）などの第１のオペレーティングシステムが実行されるコンピュータにおいて実行されるあらゆるもの（例えばソフトウェア）やそのコンピュータに認証されるあらゆるもの（例えばソフトウェア又は実在の人間）を検知してもよい。次にそのシステムは、検出したそのデータを取り出し、第２のオペレーティングシステム（例えばＷｉｎｄｏｗｓ（商標））内の同種のイベントと同じ又は十分に類似した名前がフィールドに対して付けられるようにフォーマットし、ログ収集ツールが容易にそれを収集できるような様式に特別にフォーマットされていてもよいログファイルに書き込む。本開示で使用するように、第１のオペレーティングシステムは、例えば、ｍａｃＯＳ（商標）シリーズ又はＡｐｐｌｅ（商標）社から提供されるいずれかのオペレーティングシステムから選ばれる特定のオペレーティングシステムであってもよく、また第２のオペレーティングシステムはＭｉｃｒｏｓｏｆｔ（商標）ＯＳ製品から選ばれるオペレーティングシステム（例えばＷｉｎｄｏｗｓ（商標））であってもよい。

本開示はキュレーションされたセキュリティイベントデータのリアルタイムストリーミングと、複数の異なるツールにより分析することができる共通データ構造のデータオブジェクトの生成のために設計されたシステム及び方法について述べる。例えば、動的な又は未知の長さの監査コンテンツのストリーミングデータを受け取り、そのコンテンツを、分析しやすい構造化フォーマットのコンテンツのラベル化ピースを含む、構造データフォーマットへと構造解析する。更に、本開示はコンピュータリソース（例えばＣＰＵやメモリ等）やユーザエクスペリエンスへの影響が少ないように設計されていてもよい。

加えて、本開示は、例えばファイルシステムの変更と作成の監視；プロセス、認証、及び重要なシステム変更に関するイベントデータの収集；収集し検出したデータフィールドの、第２のオペレーションシステム（例えばＷｉｎｄｏｗｓ（商標））のフィールドスキームへの翻訳；フォーマットされた結果ストリームの、検出したデータからの相互参照情報によるエンリッチ化；事前に定義されたアクション又はイベントに応答して（例えばＡｐｐｌｅ（商標）構成プロファイルがデバイスに配信されたことに応答して）、事前に定義されたデバイス管理サーバを除く全てのデータ接続をシャットダウンするデバイス検疫機能；及び／又はフォーマットされた結果データ（例えばＪＳＯＮ、ｃｓｖ、ｘｍｌ）全体の、１以上の設定によって定義されたサーバへの直接の出力、等の機能を有するエンドポイント検出応答（ＥＤＲ）ツールについて述べる。

ＯｐｅｎＢＳＭ ＡＰｌは使用するのが難しい場合があり、デフォルトのフィルタクラスが極端に広く、多くの無関係なデータを含むことから、補正されたａｕｄｉｔ＿ｅｖｅｎｔのタイプを収集するのに必要な柔軟性（フレキシビリティ）を提供できない。本開示に係るシステム又は方法は、これらのＡＰＩの課題を解決することができ、ａｕｄｉｔ＿ｅｖｅｎｔフィルタの複数のレベルを実行して関係のあるデータのみを回収することができる。本開示の印刷エンジンはカスタマイズ可能であり、収集されたイベントデータを、人間や機械が容易に読み取ることができるＪＳＯＮや他の構造化データフォーマットに出力することができる。

本開示に係るシステムは、ＯｐｅｎＢＳＭから関係のあるａｕｄｉｔ＿ｅｖｅｎｔｓのみをストリーミングすることができ、既存の企業のセキュリティツールによって簡単に収集できるようにそのａｕｄｉｔ＿ｅｖｅｎｔｓをフォーマットしてもよい。ある実装形態においては、収集のためのａｕｄｉｔ＿ｅｖｅｎｔｓの特定のクラスを宣言してもよい。その際、ある実装形態においては、そのクラスから上記ａｕｄｉｔ＿ｅｖｅｎｔｓを更にフィルタリングして、関係があり且つ必要なデータのみを収集してもよい。次にこのフィルタリングされたａｕｄｉｔ＿ｅｖｅｎｔｓを、その中に特定の語や句があるａｕｄｉｔ＿ｅｖｅｎｔｓを削除することができるブラックリストフィルタと比較してもよい。両フィルタによるテストをパスしたａｕｄｉｔ＿ｅｖｅｎｔｓは、次にローカルコンピュータファイルシステムに出力するか、ネットワークを経由してログ収集サーバへと転送してもよい。

さて添付の図面を参照すると、図１は本開示のシステム、方法、及び他の態様を実行することができる代表的な環境１００を示す。環境１００は少なくとも１つの（すなわち１以上の）第１のコンピューティングデバイス１０５と、少なくとも１つの（すなわち１以上の）第２のコンピューティングデバイス１０６と、ネットワーク１１０と、少なくとも１つの（すなわち１以上の）記憶装置１２０とを含んでもよい。上記少なくとも１つの第１のコンピューティングデバイス１０５及び少なくとも１つの第２のコンピューティングデバイス１０６はネットワーク１１０に接続されている。ネットワーク１１０は好適なネットワークのいずれか又はネットワークのコンビネーションであってもよく、システム環境１００内の様々なコンポーネントの間でのデータの通信に適した適切なプロトコルのいずれかに対応したものであってもよい。ネットワーク１１０はパブリックネットワーク（例えばインターネット）、プライベートネットワーク（例えば組織内のネットワーク）、又はパブリック及び／又はプライベートネットワークの組み合わせを含んでもよい。上記少なくとも１つの記憶装置１２０はローカルのハードドライブ、ネットワークサーバ、又はいずれかの他のユーザ定義の宛先リポジトリであってもよい。

上記少なくとも１つの第１のコンピューティングデバイス１０５及び少なくとも１つの第２のコンピューティングデバイス１０６は一人以上のユーザによって操作されてもよい。第１のコンピューティングデバイス１０５及び第２のコンピューティングデバイス１０６の例には、スマートフォン、ウェアラブルコンピューティングデバイス、タブレットコンピュータ、ラップトップコンピュータ、及びデスクトップコンピュータが含まれてもよい。第１のコンピューティングデバイス１０５は、そのコンピューティングデバイスにインストールされた様々なソフトウェア及び特定のオペレーティングシステム（第１のオペレーティングシステム）を有していてもよい。例えば、第１のオペレーティングシステムはｍａｃＯＳ（商標）であってもよく、又はＡｐｐｌｅ（商標）社から提供されるいずれかのオペレーティングシステムであってもよい。第２のコンピューティングデバイス１０６は、そのコンピューティングデバイスにインストールされた様々なソフトウェア及び特定の第２のオペレーティングシステムを有していてもよい。例えば、第２のオペレーティングシステムは、第１のオペレーティングシステムとは異なるオペレーティングシステムであってもよく、例えばＷｉｎｄｏｗｓ（商標）、又はＭｉｃｒｏｓｏｆｔ（商標）から提供されるいずれかのオペレーティングシステム、又はいずれかのオープンソースのオペレーティングシステムなどであってもよい。

環境１００は、データを集め、処理し、送り、及び／又は受け取るように構成された１以上の第１及び第２コンピュータデバイスを含んでもよい。概して、環境１００がデータを集め、処理し、送り、又は受け取る操作を行うものとして説明される場合は、その操作は、そのコンピュータシステムによって行うことができるものと解される。概して、コンピュータシステムは、下記図７に関連して示すような１以上のコンピューティングデバイスを含んでもよい。

図２は本開示の一態様に係る、セキュリティイベント監視の代表的なフロー方法２００を示す。方法２００は、基本セキュリティモジュール（ＢＳＭ）によってデータを収集するステップ２０１から始まってもよい。ＢＳＭは、第１のコンピューティングデバイス１０５上の全ての処理に対する詳細な監査証跡を生成するソフトウェアモジュールであってもよい。ＢＳＭは、監査記録を管理するための一連のシステムコールとライブラリインタフェース、及び拡張可能で一般化された監査証跡処理を可能にするトークンストリームファイルフォーマットを記述することができる。ＢＳＭによって集められるデータは、第１のコンピューティングデバイス１０５上の実行プロセス（例えばソフトウェアの実行）、認証プロセス（例えばソフトウェアの認証やユーザの認証）、接続プロセス（例えばネットワーク接続、ハードウェア接続、又はケーブル接続）及び／又は他のプロセスに関するものであってもよい。ＢＳＭは第１のコンピューティングデバイス１０５にインストールされていてもよく、ある実施形態においてはＯｐｅｎＢＳＭであってもよい。ＢＳＭによる収集の後、収集されたデータはステップ２０２においてセキュリティイベント監視アプリケーションに対してストリーミングされてもよく、セキュリティイベント監視アプリケーションは収集のための監査クラスを宣言してもよい。監査クラスは論理カテゴリーにグループ化された監査イベントであってもよい。監査クラスの例は、ファイル生成に関する第１のコンピューティングデバイス１０５のＣＰＵ、ネットワーク、及びプロセスによって行われるアクションであってもよい。

ステップ２０３では、上記セキュリティイベント監視アプリケーションは監査クラスデータのストリームを解析して、所定の監査イベントを取得してもよい。監査イベントは第１のオペレーティングシステムを実行するコンピュータに対しＣＰＵによって行われるアクションに応答してＢＳＭによって生成されるアクションであってもよい。監査イベントはセキュリティ操作及び／又はアプリケーションの実行に関するアクションであってもよい。監査可能なイベントはそれぞれ識別名、イベント番号、一連の事前選択クラス、及び短い説明によってファイル内に定義される。監査イベントが所定の監査イベントと一致することが判明した場合、次にステップ２０４において収集されたデータのストリームから監査イベントを削除して、それによりフィルタリングされた監査イベントのストリームを生成してもよい。フィルタリングされた監査イベントのストリームは、次にステップ２０５においてブラックリストに登録されたストリングがないかチェックされるか、あるいは解析される。このステップでは、フィルタリングされた監査イベントのストリームを１以上のブラックリストフィルタと比較してもよい。いずれかの監査イベントが１以上のブラックリストフィルタと一致する場合、次にステップ２０６において、一致した監査イベントを監査イベントのストリームから削除してもよい。ステップ２０７において、所定の監査イベントには一致するが、一以上のブラックリストフィルタには一致しない監査イベントのストリームをローカルコンピュータファイルシステムに出力するか、又はネットワーク経由でログ収集サーバに転送されてもよい。ローカルコンピュータファイルシステム又はログ収集サーバは少なくとも１つの記憶装置１２０に相当してもよい。

図３は本開示の一態様に係る、フィルタを用いたセキュリティイベント監視の代表的な方法３００を図示したものである。方法３００は第１のコンピューティングデバイス１０５上で行うことができ、ステップ３０１から始めてもよい。ステップ３０１では、第１のコンピューティングデバイス１０５の第１のオペレーティングシステムのカーネルスペースに常駐するＢＳＭカーネルモジュールが第１のコンピューティングデバイス１０５によって行われるアクティビティや第１のコンピューティングデバイス１０５が実行する方法に関するアクティビティや情報のログを記録してもよい。アクティビティと情報のログは、第１のオペレーティングシステム１０５上で起こる、又は第１のオペレーティングシステム１０５を介して起こる操作、障害、及び変更を記述するデータの１以上のストリームを含んでもよい。アクティビティと情報の収集は、ａｕｄｉｔｐｉｐｅ等の擬似デバイスに対する呼び出しを通じてステップ３０２でアクセスされてもよい。セキュリティイベント監視アプリケーションは、ステップ３０３で擬似デバイスを呼び出して、アクティビティや情報の収集のデータストリームを受け取ってもよい。セキュリティイベント監視アプリケーションはデーモンプロセスであってもよく、そのデーモンプロセスはカーネルスペースの外側の、第１のオペレーティングシステムのバックグラウンドで見えないように実行されるプロセスであってもよい。デーモンプロセスはシステム（例えばｒｏｏｔ）パーミッションと共に実行されてもよく、特定のユーザのために実行されてもよい。セキュリティイベント監視アプリケーションの起動の際、監視され、擬似デバイスから収集される特定の監査クラスの構成をステップ３０４で定義してもよい。

ステップ３０５において、バイナリ形式にエンコードされた監査イベントは、セキュリティイベント監視アプリケーションに捕捉されてメモリ（例えば記憶装置１２０）に記憶されてもよい。ステップ３０６において、捕捉した監査イベントを属性化可能なイベントと属性化できないイベントとに分類することで分類プロセスを完結させてもよい。ステップ３０７において、収集された監査イベントと予め定義されたフィルタ内の監査イベントタイプとの比較を行ってもよく、収集された監査イベントが予め定義されたフィルタ内の監査イベントタイプと一致しない場合、次にステップ３０８において、収集した監査イベントをメモリ（例えば記憶装置１２０）から削除してもよい。収集した監査イベントが予め定義されたフィルタ内の監査イベントタイプと一致する場合、次にステップ３０９において、バイナリ形式にエンコードされた監査イベント内のトークン行ごとにループ処理を開始してもよい。トークンは一連の監査データであってもよく、バイナリ形式で保存されていてもよい。各トークンは、プロセス、パス、又は他のオブジェクトなどの監査イベントの属性を記述する／表すものであってもよい。各トークンは、トークンタイプ識別子とそれに伴うトークンに固有のデータを有していてもよい。ステップ３１０において、入力されたトークン行のタイプ用に構成されたフィルタがあるかどうかを決定してもよい。入力されたトークンタイプ用にフィルタが構成されている場合、次にステップ３１１において、トークン行を調べて、トークン行がブラックリスト基準を含んでいるかどうかを判断してもよい。トークン行がブラックリスト基準を含んでいると判断された場合、次にステップ３１２において、そのトークンが属する監査イベントをメモリから削除してもよい。ステップ３１０又はステップ３１１における判断が否定的である（例えば入力されたトークン行タイプ用に構成されたフィルタがない、又はトークン行がブラックリスト基準を含んでいない）場合、次にステップ３１３でそのトークン行は第２のオペレーティングシステム（例えばＪＳＯＮテキストイベントフォーマット、又はｃｓｖ、ｘｍｌ等）によって認識可能な構造化データフォーマットに構造解析され、メモリ（例えば記憶装置１２０）に保存されてもよい。

ステップ３１４において、上記監査イベント内に処理すべき他のトークンがあるかどうかを判断する。上記監査イベント内に処理すべき他のトークンがない場合には、次にステップ３１５において、第３のフィルタが定義されているかどうかを判断する。第３のフィルタが定義されている場合、次にステップ３１６において、取集した監査イベントを、その第３のあらかじめ定義されたフィルタと比較してもよい。監査イベントが第３のあらかじめ定義されたフィルタと一致する場合、次にステップ３１７においてその監査イベントをメモリから削除してもよい。第３のフィルタが定義されていない場合、又は上記第３のあらかじめ定義されたフィルタと一致する監査イベントがない場合、次にステップ３１８において、完全な構造化データフォーマットのイベントを組み立て、ステップ３１９において、完全な構造化データフォーマットのイベントのログを記録して記憶装置１２０に保存してもよい。完全な構造化データフォーマットのイベントは、組み合わされることで構造化されたデータオブジェクト（例えばＪＳＯＮオブジェクト）が作成されてもよい、複数の構造化データフォーマット（例えばＪＳＯＮスタンザ）を含んでいてもよい。

図４は本開示の一態様に係る、イベントトークン処理の代表的な方法４００を図示したものである。方法４００は第１のコンピューティングデバイス１０５上で実行されてもよく、ステップ４０１から始まってもよい。ステップ４０１では、第１のコンピューティングデバイス１０５に常駐するセキュリティイベント監視アプリケーションにストリーミングされる、バイナリ形式の監査イベントを収集する。バイナリ形式の監査イベントは、それぞれ少なくとも１つのトークン（例えばトークン１～トークンＮ）を含んでいてもよい。ステップ４０２においては、監査イベント内の各トークンは、マッピング処理のためのセキュリティイベント監視アプリケーションの構造解析エンジンによって取得され、受け取られてもよい。ステップ４０３においては、上記トークンは、監査トークンタイプと一致していてもよく、ステップ４０４において、上記トークンは、上記監査トークンタイプ用の対応する構造化データフォーマットへとマッピングされてもよい。ある実施形態においては、ＪＳＯＮは構造化データフォーマット用に使用されてもよく、イベント行は、対応するＪＳＯＮスタンザへとマッピングされてもよい。当然ながら、他のタイプの構造化データフォーマットを利用することも考えられる。ヘッダートークンマッピングの例は“ＥＶＥＮＴ－ＩＤ－ＬＡＢＥＬ “ｅｖｅｎｔ－ｉｄ” ”、“ＥＶＥＮＴ－ＮＡＭＥ－ＬＡＢＥＬ “ｅｖｅｎｔ－ｎａｍｅ””、“ＴＩＭＥＳＥＣ＿ＬＡＢＥＬ “ｔｉｍｅ＿ｓｅｃｏｎｄｓ＿ｅｐｏｃｈ””、“ＴＩＭＥＭＳ＿ＬＡＢＥＬ “ｔｉｍｅ－ｍｉｌｌｉｓｅｃｏｎｄｓ－ｏｆｆｓｅｔ””、 “ＶＥＲＳＩＯＮ－ＬＡＢＥＬ “ｖｅｒｓｉｏｎ””、“ＥＶＥＮＴ－ＭＯＤＩＦＩＥＲ “ｅｖｅｎｔ－ｍｏｄｉｆｅｒ””、“ＮＡ－ＯＲ－Ａ－ＥＶＥＮＴ－ＬＡＢＥＬ “ｉｓ－ｎｏｎ－ａｔｔｒｉｂｕｔｅａｂｌｅ－ｅｖｅｎｔ””、“ＦＡＩＬＥＤ＿ＥＶＥＮＴ＿ＬＡＢＥＬ “ｉｓ＿ｆａｉｌｅｄ＿ａｕｄｉｔ＿ｅｖｅｎｔ””であってもよい。他のマッピングもまた使用することができ、第１のオペレーティングシステムのイベントの命名規則を、第２のオペレーティングシステムによって認識される命名規則へとマッピングしてもよい。マッピング処理が完了すると、ステップ４０５において、上記出力を、第１コンピューティングデバイス内のメモリ又は記憶装置１２０内の最終イベント記録に追加してもよい。ステップ４０６では、監査イベント内に更にトークンが存在するかどうかに関する判断を行ってもよい。判断の結果が肯定的な場合、方法４００はステップ４０２に戻り、より多くのトークンが受け取られて構造解析される。監査イベント内のすべてのトークンが構造解析されて、対応する構造化データフォーマットへとマッピングされると、次にステップ４０７において、構造化データフォーマット（例えばＪＳＯＮ）にフォーマットされた最終イベントは、第１コンピューティングデバイス内のメモリ又は記憶装置１２０内に記憶されてもよく、ステップ４０８において、フォーマットされたイベントのログが第１のコンピュータ又は記憶装置１２０で記録され、結果として生じる構造化データ（例えばＪＳＯＮ）オブジェクトは、単一バイナリイベントからの全ての関連データを有していてもよい。

図５は、本開示の一態様に係る、セキュリティイベント監視の構成の図法５００を図示している。方法５００はステップＳ１から始めることができる。ステップＳ１では第１のオペレーティングシステム用にフォーマットされた特性リスト構成ファイルが、第１のコンピューティングデバイス１０５に常駐するセキュリティイベント監視アプリケーション５０２へとロードされてもよい。セキュリティイベント監視アプリケーション５０２は、ステップＳ２で特性リストファイル５０１を読み出して特性リストキーと特性リスト値の組み合わせを決定する。上記特性リストファイル５０１は、上記一連の収集フィルタの用の詳細度レベルを構成するのに使用されてもよい。詳細度には、監査対象のシステムの相対的なセキュリティリスクに対応し、情報の推奨レベルを収集する３つのレベルがあってもよい。ある実施形態において、上記詳細度レベルは、例えば、公開されているリスク管理の枠組み（例えば米国国立標準技術研究所のＳＰ８００－３７）によって定義されるような、監査対象のシステムの相対的なセキュリティリスクに対応するものであってもよい。３つの詳細度レベルと、それに対応する収集情報の例は次のようなものであってもよい。「ログレベル１」（すなわち第１のログレベル）５０３：ログレベル１は最も低い詳細度レベル（最も低いリスク又は「最も低いリスクレベル」）を表していてもよく、ｉ）アプリケーションの実行、ｉｉ）スクリプト及び対話型端末命令、ｉｉｉ）認証プロンプト及び認証結果（例えばログイン）の全て、及び／又はｉｖ）認証プロンプト及び認証結果（例えば、ユーザＸがイベントＹを行うことを許可されているか）に関する情報を収集してもよい。「ログレベル２」（すなわち上記第１のログレベルとは異なる第２のログレベル）５０４：ログレベル２は、中程度の詳細度レベル（例えば第１のログレベルより高いリスクレベル又は「中位のリスクレベル」）を表していてもよく、ｉ）レベル１のログ記録イベントの全て、ｉｉ）アプリケーションネットワーク接続の作成、ｉｉｉ）スクリプト及び対話型端末ネットワーク接続、並びにｉｖ）ウェブブラウザ接続履歴（例えばブラウザログ）に関する情報を収集してもよい。「ログレベル３」（すなわち上記第１のログレベル及び上記第２のログレベルの両方と異なる第３のログレベル）５０５：ログレベル３は最も高い詳細度（例えば上記第２のログレベルよりも高いリスク又は「最も高いリスクレベル」）を表していてもよく、ｉ）レベル１とレベル２のログ記録イベントの全て、ｉｉ）プロセス間通信イベント、及びｉｉｉ）より低位のログ記録レベルにおいて収集されるイベントタイプに追加される詳細度に関する情報を収集してもよい。詳細度の３つのレベルがこの開示に記載されているが、詳細度レベルが多少異なっていても、それもまた本開示の範囲内である。

他の実施形態においては、「ログレベル１」、「ログレベル２」、「ログレベル３」は異なるリスクレベルに対応する。特に、ある実施形態においては、詳細度は、リスクレベルと直接的な関連性はない。例えば、最も低い詳細度レベルを表してもよい「ログレベル１」（すなわち第１のログレベル）５０３は「中程度のリスクレベル」又は「最も高いリスクレベル」のリスクレベルを有していてもよい。中程度の詳細度レベルを表してもよい「ログレベル２」（すなわち上記第１のログレベルとは異なる第２のログレベル）５０４は、「最も低いリスクレベル」又は「最も高いリスクレベル」のリスクレベルを有していてもよい。最も高い詳細度レベルを表してもよい「ログレベル３」（すなわち第１のログレベル及び第２のログレベルとは異なる第３のログレベル）５０５は、「最も低いリスクレベル」又は「中間のリスクレベル」のリスクレベルを有していてもよい。

ステップＳ２で特性リストキーと値の組み合わせが読み出されたあと、セキュリティイベント監視アプリケーションによって適切なログレベルが決定されてもよい。ログレベル１が望まれる場合、次にステップＳ３において、レベル１のクラスに関して収集されるべき所望のデータを擬似デバイスのａｕｄｉｔｐｉｐｅ上で定義してもよく、そのレベルクラスに関するフィルタをステップＳ４で実行してもよい。収集されたデータは、次にステップＳ５においてセキュリティイベント監視アプリケーションフィルタエンジンへと送られて、構造解析されてもよい。ログレベル２が望まれる場合、次にステップＳ６において、レベル２のクラスに関して収集されるべき所望のデータを擬似デバイスのａｕｄｉｔｐｉｐｅ上で定義してもよく、そのレベルクラスに関するフィルタをステップＳ７でアクティブにしてもよい。収集されたデータは、次にステップＳ８においてセキュリティイベント監視アプリケーションフィルタエンジンへと送られて、構造解析されてもよい。ログレベル３が望まれる場合、次にステップＳ９において、レベル３のクラスに関して収集されるべき所望のデータを擬似デバイスのａｕｄｉｔｐｉｐｅ上で定義してもよく、そのレベルクラスに関するフィルタをステップＳ１０でアクティブにしてもよい。収集されたデータは、次にステップＳ１１においてセキュリティイベント監視アプリケーションフィルタエンジンへと送られて、構造解析されてもよい。様々なログレベルから収集されたデータがセキュリティイベント監視アプリケーションフィルタエンジンによって構造解析されると、次にステップＳ１２において、セキュリティイベント監視アプリケーションはそのデータを、第２のオペレーティングシステムによって識別可能なフォーマットへと変換又は正規化し、そのデータを出力する。

図６は、本開示の一態様に係る、相互参照制御の代表的なフロー図６００を示す。図６に示すように、セキュリティイベント監視アプリケーションは、第１コンピューティングデバイス上の複数の異なるソースから情報を収集してもよく、正確さを期して情報を相互参照（相互参照）してもよい。ＢＳＭから取得したイベントデータは、イベントの真の信頼できる記録とみなしてもよい。更に別の実施形態においては、イベントデータの他のソースもまたイベントの真の信頼できる記録とみなしてもよい。ＢＳＭ記録の属性を他のソースにと照合して、関連するイベントを相互参照してもよい。相互参照のために使用されるソースには、ＢＳＭの記録、ネットワークインターフェースのログ（例えばトラフィック、成功した接続など）、ファイアウォールログ（例えばトラフィック、失敗した又は成功した接続）、ユーザセキュリティ及びプライバシー許可の変更、第１のオペレーティングシステムからのアプリケーション利用情報、ネットワークインターフェース構成及び属性データ、第１のオペレーティングシステムからのデバイス位置データ、ファイル変更イベント、構成変更イベント、ＢＳＭソケット通知、及び第１のオペレーティングシステム統合ログが含まれてもよい。相互参照に使用される属性には、プロセスＩＤ、ａｕｄｉｔＴｏｋｅｎ、セッションＩＤ、ファイルパス又はプロセスパス、監査ユーザ、有効ユーザ、ＢＳＭソケット、ｕｎｉｘファイルディスクリプタ、署名ＩＤ、又はタイムスタンプが含まれてもよい。信頼できないイベントが検出されると、データベースに記憶されたＢＳＭデータに対してそのイベントが検証されてもよい。検証が成功した場合には、最も低い信頼イベントの信頼レベルを上げてもよく、より高い信頼レベルが割り当てられてもよい。信頼できないイベントのソース、信頼できるイベントと一致する属性の数、及び／又はイベントによって報告されたアクションのカテゴリー（例えばログイン、設定の変更、ネットワークアクティビティなど）に基づいて、入ってくる信頼できないイベントに対し信頼スコアを付与してもよい。一致するするＢＳＭイベントからの信頼スコア及び情報を信頼できないイベントに付加してもよく、また顧客が定義した宛先に送ってもよい。顧客が定義した宛先に送ると共に、相互参照の目的でローカルデータベースに一時的にＢＳＭイベントのキャッシュを残してもよい。キャッシュが残されたデータベースにＢＳＭイベントが保存される期間はイベントのタイプによって変更してもよい。例えば、重要度の高いイベントを、重要度の低いイベントと比べてより長い期間保存してもよい。更に、その後複数の信頼レベルからの相互参照データを組み合わせて、起こったイベントやアクションに対してエンリッチ化された記録を作成してもよい。エンリッチ化されたその記録は、信頼のあるＢＳＭデータに対して検証され、その信頼のあるＢＳＭデータと組み合わせた、信頼されていないイベントであってもよい。ＢＳＭからの信頼されたデータを上記信頼されていないイベントに追加して、顧客が定義した宛先で後から分析するために追加のコンテキストと一貫性のあるデータフィールドを追加してもよい。

相互参照制御プロセスは、図６を参照して本開示にて説明することができる。フロー図６００はステップ６０１で始めてもよい。ステップ６０１では、信頼できるイベント（Ａ）に関するデータをセキュリティイベント監視アプリケーションに入力してもよい。信頼できるイベント（Ａ）に関するデータはＢＳＭから収集してもよく、また他の信頼できるソースから収集してもよい。相互参照される信頼できないイベントデータがない場合には、次にステップ６０２にて、上記信頼できるイベント（Ａ）のデータをログ保存システム（記憶装置１２０等）に直接送ってもよい。相互参照のための信頼できないイベントデータが存在する場合、次にステップ６０３において、セキュリティイベント監視アプリケーションは、信頼できるイベント（Ａ）のデータを、相互参照エンジンに渡してもよい。セキュリティイベント監視アプリケーション又は相互参照エンジンは、それぞれステップ６０４及びステップ６０５において、信頼できるイベント（Ａ）のデータを保存できる一時的なイベントキャッシュに対しても信頼できるイベント（Ａ）のデータを渡してもよい。ステップ６０６において、自動応答アクションの決定があるかどうかを判断するための判断が行われてもよい。自動応答アクションは、保護されたシステムの防御姿勢を高めたり低めたりする、システム上におけるセキュリティに関連する設定又はサービスの変更を含んでもよい。これらの設定又はサービスは、コンピューティングデバイス及び／又は企業データを潜在的なリスクに晒す可能性のあるローカルの、又は外部からの入力を拒絶するようにシステムの挙動を変更してもよい。判断の結果が肯定的な場合、次にステップ６０７において、とったアクションと結果の応答をログに記録し、ステップ６０８において、ログ保存システムに送ってもよい。ログ保存システムは記憶装置１２０であってもよい。

信頼できないイベント（Ｂ）に関するデータを取得する際、ステップ６０９において、その信頼できないイベント（Ｂ）のデータを相互参照エンジンに送ってもよい。信頼できるイベント（Ａ）のデータと信頼できないイベント（Ｂ）のデータの両方を有する相互参照エンジンは、ステップ６１０において、検証された信頼できないイベント（Ｂ）のデータを信頼できるイベント（Ａ）のデータに追加してもよい。ステップ６１１において、信頼できないイベント（Ｂ）のデータ及び信頼できるイベント（Ａ）のデータの集計を複合エンリッチド（ｅｎｒｉｃｈｅｄ）イベント（Ｃ）のデータに変換してもよく、またステップ６１２において、その複合エンリッチドイベント（Ｃ）のデータをログ保存システム（例えば記憶装置１２０）に送ってもよい。

図７は、本開示の一態様に係る、詳細な相互参照エンジンプロセスの代表的なフロー図７００を示す。フロー図７００はステップ７０１から始めてもよい。ステップ７０１では、信頼できるイベント（Ａ）のデータを収集してもよい。信頼できるイベント（Ａ）のデータは信頼できるログ記録システムから収集してもよく、「フィールド１１」、「フィールド２２」、及び「フィールド３３」等の代表的な情報を含んでいてもよい。ステップ７０２において、信頼できないイベント（Ｂ）のデータを収集してもよい。信頼できないイベント（Ｂ）のデータは信頼できないログ記録システムから収集してもよく、また信頼できるイベント（Ａ）のデータを有していない情報を含んでもよい。例えば、信頼できないベント（Ｂ）のデータは「フィールド１」、「フィールド２」、「フィールド３」、「フィールドＡＡ」、「フィールドＢＢ」、及び「フィールドＣＣ」などの代表的な情報を含んでいてもよい。イベント（Ａ）のデータ及びイベント（Ｂ）のデータは、既に生じた同一のアクションを報告する別のログ記録システムの結果であってもよい。ステップ７０３において、イベント（Ａ）のデータフィールドは、セキュリティイベント監視アプリケーションの事前に定義されたマッピングに基づいてイベント（Ｂ）の命名フォーマットへとマッピングされてもよく、ローカルデータベース（例えば記憶装置１２０）内に保存されてもよい。ステップ７０４において、イベント（Ｂ）に関するデータを、イベント（Ａ）のデータのデータベース内のイベント（Ｂ）のフィールドをルックアップするのに使用してもよい。ステップ７０５において、イベント（Ｂ）のデータフィールドのいずれかがイベント（Ａ）のデータベース内のデータに一致するかどうかを判断するために判断を行ってもよい。判断の結果が否定的な場合、次にステップ７０６において、そのイベント（Ｂ）のデータを短期間一時的なキャッシュに保存してもよい。このとき、保存する期間はイベント（Ｂ）のタイプやカテゴリーに関連づけてもよい。ステップ７０７において、イベント（Ａ）のデータのデータベース内の、イベント（Ｂ）のフィールドのルックアッププロセスを再試行してもよく、もし一致するものが見つからない場合、次にステップ７０８において、そのイベント（Ｂ）のデータをメモリ又は記憶装置から削除してもよい。もしステップ７０５又はステップ７０７において、ルックアッププロセスの結果として一致するものが見つかった場合、次にステップ７０９において、信頼できるイベント（Ａ）のデータ及び信頼できないイベント（Ｂ）のデータを複合エンリッチドイベント（Ｃ）のデータへと変換してもよい。複合エンリッチドイベント（Ｃ）のデータは、「フィールド１」、「フィールド２」、「フィールド３」、「フィールド１１」、「フィールド２２」、及び「フィールド３３」などの代表的な情報を含んでいてもよい。フィールドデータは、アクションがシステム上でどのように行われるか、及び／又はどのパーティー（人又はプロセス）によって行われるかを示してもよい。例えば、フィールドデータには、プロセスＩＤ、ａｕｄｉｔＴｏｋｅｎ、セッションＩＤ、ファイル又はプロセスパス、監査ユーザ、有効ユーザ、ＢＳＭソケット、ｕｎｉｘファイルディスクリプタ、署名ＩＤ、タイムスタンプ、又は関連データが含まれてもよい。ステップ７１０において、複合エンリッチドイベント（Ｃ）のデータはログ保存システム（例えば記憶装置１２０）に送られてもよい。

図８は、本開示の一態様に係る、構成の更新に対するセキュリティイベント監視ツールの応答の図法８００を図示している。方法８００はステップ８０１から始めてもよい。このステップでは、セキュリティイベント監視アプリケーションデーモンが、いずれかの設定ファイルの変更があったかをリッスンし、定期的にスキャンしてもよい。ステップ８０２において、アクション設定が設定され、第１のオペレーティングシステムの構成プロファイルを介した実施が検出された場合、次にステップ８０３において、セキュリティイベント監視アプリケーションが新しい設定キーと値のペアに対して割り当てられたセキュリティ応答アクションを行ってもよい。設定ファイルの変更が検出されない場合は、プロセスを終える。

図８に図示されたある実施形態において、上記新しい設定は、構成の更新を第１コンピューティングデバイスにプッシュした結果として、第１コンピューティングデバイス上の全てのネットワーク接続を無効にするためのものであってもよい。ステップ８０３ａにおけるセキュリティイベント監視アプリケーションは、ホワイトリストに登録されたネットワーク接続が定義されているかどうかを判断してもよい。判断が否定的な場合、次にステップ８０３ｂにおいて、共通のモバイルデバイス管理（ＭＯＭ）設定ファイルに、許可されたサーバのＵＲＬがないかをチェックしてもよい。許可されたサーバのＵＲＬが見つかった場合、ステップ６０３ｃにおいてＭＯＭサーバのＵＲＬをネットワーク接続のホワイトリストに追加してもよい。ステップ８０３ｄにおいて、許可されたネットワーク接続のホワイトリスト、アプリケーションマーカー規則、及びＩＰ（インターネットプロトコル）スペースと共に新しいファイアウォール構成を作成してもよい。ステップ８０３ｅにおいて、セキュリティイベント監視アプリケーションは生成した構成を適用してファイアウォールサービスがアクティブかどうかを検証し、ファイアウォールサービスがアクティブでない場合には、ステップ８０３ｆで新しいファイアウォール構成をアクティブにしてホワイトリストに登録されたネットワーク接続以外の全てのネットワーク接続をブロックしてもよい。ファイアウォール構成がアクティブな場合には、次にステップ８０３ｇにおいて、新しい構成が作成されるまでセキュリティイベント監視アプリケーションはその構成を維持してもよい。

図９は、例えばコンピュータ可読なコードのような、本開示の実施形態又はその一部が実行されてもよい代表的なコンピュータデバイス又はシステムのハイレベル機能ブロック図を示す。さらに、図１～８を参照して上で説明した代表的なコンピュータサーバ、データベース、ユーザインターフェース、モジュール、及び方法はそれぞれ、ハードウェア、ソフトウェア、ファームウェア、命令が保存された有形のコンピュータ可読媒体、又はその組み合わせを用いたデバイス９００において実行することができ、１以上のコンピュータシステム又は他の処理システムにおいて実行されてもよい。ハードウェア、ソフトウェア、又はそれらの組み合わせは、図１～８を参照して上述したような代表的なシステム、ユーザインターフェース、及び方法のそれぞれを実行してもよい。

プログラマブルロジックを使用する場合、そのロジックは市販の処理プラットフォーム又は専用のデバイス上で実行することができる。開示された主題の実施形態が、マルチコア・マルチプロセッサ・システム、ミニコンピュータ、メインフレームコンピュータ、分散された機能によりリンクされた又はクラスター化されたコンピュータ、及び事実上どのようなデバイスにも組み込まれる可能性のある普及型コンピュータ又はミニチュアコンピュータ等の様々なコンピュータシステム構成を用いて実施することができることは当業者であれば認識できる。

例えば、少なくとも１つのプロセッサデバイス及びメモリを用いて上述の実施形態を実行してもよい。プロセッサデバイスは単一のプロセッサでも複数のプロセッサでもよく、その組み合わせでもよい。プロセッサデバイスは１以上のプロセッサ「コア」を有していてもよい。

本開示の様々な実施形態は、図１～８の例の中で上述したとおり、デバイス９００を用いて実施することができる。この明細書を読んだ後、他のコンピュータシステム及び／又はコンピュータアーキテクチャを用いて本開示の実施形態をどのように実行するかは当業者にとって明らかになるであろう。操作は逐次プロセスとして記述することができるが、実際は、操作の一部を平行して行ったり、同時に行ったり、及び／又は分散環境において行うことができ、シングル又はマルチプロセッサマシンによってアクセスできるようにローカルで又は遠隔で保存されたプログラムコードを用いて行うことができる。さらに、ある実施形態において、開示された主題の趣旨から逸脱することなく操作の順番を再配列してもよい。

図９に示すように、デバイス９００は中央処理装置（ＣＰＵ）９２０を含んでもよい。ＣＰＵ９２０は、例えば、いずれかのタイプの専用又は汎用のマイクロプロセッサデバイス等を含む、いずれかのタイプのプロセッサデバイスであってもよい。当業者によって認識されるように、ＣＰＵ９２０もまた、単独で動作するシステムであるマルチ・コア／マルチプロセッサシステムにおけるシングルプロセッサであってもよく、クラスター又はサーバファームで作動するコンピューティングデバイスのクラスター内のシングルプロセッサであってもよい。ＣＰＵ９２０は、例えばバス、メッセージキュー、ネットワーク、又はマルチ・コアメッセージ転送スキームなどのデータ通信インフラストラクチャ９１０に接続することができる。

さらにデバイス９００は、メインメモリ９４０、例えばランダムアクセスメモリ（ＲＡＭ）を含んでもよく、セカンダリメモリ９３０を含んでもよい。セカンダリメモリ９３０、例えば読み取り専用メモリ（ＲＯＭ）は、例えばハードディスクドライブ又はリムーバブル記憶ドライブであってもよい。そのようなリムーバブル記憶ドライブは、例えばフロッピーディスクドライブ、磁気テープドライブ、光学ディスクドライブ、フラッシュメモリ等を含んでもよい。この例におけるリムーバブル記憶ドライブは、周知の方法で、リムーバブル記憶ユニットから読み込み、及び／又はリムーバブル記憶ユニットに書き込む。リムーバブル記憶ユニットはフロッピーディスク、磁気テープ、光学ディスク等を含んでもよく、リムーバブル記憶ドライブによってこれらは読み込まれるか、これらに対して書き込まれる。当業者によって認識されるように、そのようなリムーバブル記憶ユニットには一般的にコンピュータソフトウェア及び／又はデータが格納された、コンピュータで使用可能な記憶媒体が含まれる。

別の実装形態においては、セカンダリメモリ９３０は、コンピュータプログラム又は他の命令がデバイス９００へとロードされるようにする他の類似の手段を含んでいてもよい。そのような手段の例には、プログラムカートリッジ及びカートリッジインターフェース（ビデオゲームデバイスにおいて見られるようなもの等）、リムーバブルメモリチップ（ＥＰＲＯＭ又はＰＲＯＭなど）と関連のソケット、及びリムーバブル記憶ユニットからデバイス９００へとソフトウェア又はデータを転送することを可能にする他のリムーバブル記憶ユニットやインターフェースなどが含まれてもよい。

デバイス９００は通信用インターフェース（「ＣＯＭ」）９６０を更に含んでもよい。通信用インターフェース９６０によって、ソフトウェアやデータをデバイス９００と外部装置の間で転送することができるようになる。通信用インターフェース９６０には、モデム、ネットワークインターフェース（イーサーネットカード等）、通信用ポート、ＰＣＭＣＩＡスロットとカード等が含まれてもよい。通信用インターフェース９６０を介して転送されるソフトウェアやデータは信号の形式であってもよく、通信用インターフェース９６０によって受け取ることができる、電子的、電磁的、光学的、又は他の信号であってもよい。これらの信号は、デバイス９００の通信用パスを介して通信用インターフェース９６０に供給されてもよく、デバイス９００の通信用パスは例えば配線又はケーブル、光ファイバ、電話回線、携帯電話リンク、ＲＦリンク、又は他の通信用チャネルを用いて実装されてもよい。

その装置のハードウェア要素、オペレーティングシステム、及びプログラミング言語は本質的に従来品であり、当業者であればそれらに十分に精通していると推測される。デバイス９００はキーボード、マウス、タッチスクリーン、モニター、ディスプレイ等の入力・出力デバイスと接続するための入力・出力ポート９５０を更に含んでもよい。当然ながら、様々なサーバ機能をいくつかの類似のプラットフォームに分散させて実行させてもよく、それにより処理負荷を分散させてもよい。また、上記サーバは、コンピュータハードウェアプラットフォームの適切なプログラミングによって実行されてもよい。

詳細

上述した実施形態と矛盾することなく、本開示に従って、システム又は方法は、セキュリティ監視ツールによる収集と分析を容易にするために、第１のオペレーティングシステムが実行されるコンピュータからセキュリティイベントログを収集して、そのログを共通構造フォーマット（例えばＪＳＯＮ、ｃｓｖ、ｘｍｌ等）で１以上のハードドライブに保存してもよい。そのようなシステム又は方法は、セキュリティ又は安定性に関する問題を第１のオペレーティングシステムが実行されるコンピュータに持ち込むことなく実行されて、これらのステップを実施してもよい。

ある実装形態においては、本開示で開示するシステムによって提供される利点の例は以下に述べるようなものが含まれ得る。（１）ネイティブのｍａｃＯＳ（第１のオペレーティングシステム）サブシステム（例えばＯｐｅｎＢＳＭ）と整合させて、どのｍａｃＯＳコンピュータが何をして、どのように作動しているかについてのアクティビティや情報を収集する。（２）第１のオペレーティングシステムのより高位のアクセス許可コード（ｋｅｘｔｓ）を活用して、第１のオペレーティングシステムによって提供されるＡＰＩアクセスを介してこれらのより高位なアクセス許可を要求とすることなく、フォレンジックに健全な情報を収集し、収集するのに望ましいａｕｄｉｔ＿ｃｌａｓｓｅｓを宣言する。（３）長さ、トークン（行）タイプ、トークン行内のコンテンツが不明なバイナリＯｐｅｎＢＳＭイベントを収集して翻訳する。（４）各ＯｐｅｎＢＳＭイベントのヘッダートークンで定義されているａｕｄｉｔ＿ｅｖｅｎｔタイプに基づいて、ａｕｄｉｔ＿ｃｌａｓｓｅｓからイベントをフィルタリングし、アクティブな収集レベルで定義されていないａｕｄｉｔ＿ｅｖｅｎｔタイプを削除する。（５）収集されたデータを正規化してＷｉｎｄｏｗｓベースの（第２のオペレーティングシステムをベースとする）ログ収集又はセキュリティツール命名規則（例えばｍａｃログインイベントからｗｉｎｄｏｗｓログインイベントへ）に合わせる。（６）収集したデータを、既に企業で使用されているセキュリティ運用ツールにネイティブに取り込めるようにフォーマットする。（７）セキュリティ運用ツールによって収集するための監査されたシステム上のＪＳＯＮログファイルにこれらの改名された又はフォーマットされたイベントを保存する；（８）顧客がホストであり、顧客が管理するセキュリティ監視サーバに完成した出力データを直接ストリーミングする；及び／又は（９）特定のｋｅｙ＝ｖａｌｕｅペアを有する特定の設定ファイルを設定するＡｐｐｌｅ（商標）構成プロファイルに応じたアクションを行う（例えば設定されている設定ファイルに応じて、また構成プロファイルを介してオンザフライで全てのネットワークをオフにする）。

ＪＳＯＮは、データを（ｋｅｙ＝ｖａｌｕｅ）フィールドに分類する、人間が可読なフォーマットである。ＪＳＯＮはデータ送信のためのオープンウェブ標準であり、ほぼ全てのログ収集・セキュリティツールにおいて解析可能である。構成プロファイルは、第１のオペレーティングシステムに特有のデバイス管理ペイロードである。

本開示に係るシステム又は方法はベンダのカーネル拡張を必要としなくてもよい。一以上の実施形態において、システム又は方法は、第１のオペレーティングシステムと共に発送するＯｐｅｎＢＳＭカーネル拡張を活用してもよい。

第１のオペレーティングシステムは、オペレーティングシステムの将来のバージョンにおけるサードパーティーのｋｅｘｔｓを引き続き許可してもよい。

一以上の実施形態において、上記システム又は方法は、ｍａｃＯＳ’／ｄｅｖ／ａｕｄｉｔｐｉｐｅ上で収集されるａｕｄｉｔ＿ｃｌａｓｓｅｓや収集パラメータを定義してもよい。

一以上の実施形態において、上記システム又は方法は／ｄｅｖ／ａｕｄｉｔｐｉｐｅから収集された、バイナリコードのイベントをフィルタリングして、収集のために事前に定義されたａｕｄｉｔ＿ｅｖｅｎｔｓのみを保存してもよい。

本開示の実施形態は、Ｗｉｎｄｏｗｓツール（第２のオペレーティングシステム）へのイベントの正規化が含まれてもよい。例えば、ＡＵＥ＿ｕｓｅｒ＿ｌｏｇｉｎ（例えば第１のオペレーティングシステム用のイベント命名規則）よりもむしろ、既存の第２のオペレーティングシステムツールが、第２のオペレーティングシステムのログインイベントと同じように（又は十分に似た方法で）第１のオペレーティングシステムのログインイベントを認識できるように、ログヘッダーが改名されてもよい。

正確性を高めるために、これらの正規化には、例えば、手動入力が含まれてもよい。

本開示の方法及びシステムは、第１のオペレーティングシステム内のコード移植性を含んでもよい。本開示に係るシステム及び方法は、例えばｍａｃＯＳ２０１２から、最新のベータ版までのｍａｃＯＳ上で、変更を行うことなく実行することができる。第１のオペレーティングシステム（ｍａｃＯＳ）のカーネルコードを利用することからこのケイパビリティとポータビリティを達成することができ、本開示で開示する実装形態は正常なシステムコンテキストにおいてのみ実行することができる。これは、例えば、独自のｋｅｘｔモジュールを実行する従来のセキュリティツールと対照的である。更に、本開示で開示する実装形態は、より古いシステム（２０１２以前）でも同様に実行することができる。ｋｅｘｔｓを活用するツールは、ｍａｃＯＳ（第１のオペレーティングシステム）の特定のバージョン上で、セキュリティアプリケーションの特定のバージョンに対してのみ実行されるようにして、システムの稼働を正常に保つようにしてもよい。

本開示の実施形態は、最新のセキュリティアプリケーションがどのように実行されるか、及びどのように第１のオペレーティングシステム上で構成されるべきかについての第１のオペレーティングシステムの厳しい仕様を満たすこともできる。例えば、最も低いパーミッションから最も高いパーミッションまでのコンテキストレベルの以下のリストにおいて、本開示で開示するシステム及び方法をシステム・コンテクストデーモン上で実行することができる。（１）ユーザ固有のアクション、（２）ユーザ固有のデーモン、（３）全ユーザデーモン、（４）システム・コンテクストデーモン、（５）第１のオペレーティングシステム専用のシステムデーモン、及び（６）カーネルコンテクスト。

アプリケーション設定は、第１のオペレーティングシステムのｐｌｉｓｔフォーマットファイルを介して構成されてもよい。これらのファイルはＡｐｐｌｅの構成プロファイルを介して即座に適用され、実行することができる。構成プロファイルは、第１のオペレーティングシステムの構成管理において重要な場合がある。

一以上の実施形態において、本開示に係るシステム及び方法は、特別にキュレーションされたセキュリティイベントデータのリアルタイムのストリーミング用に、多くの異なるツールで解析可能な共通のデータ構造で設計されていてもよい。

１以上の実施形態においては、本開示はコンピュータリソース（例えばＣＰＵやメモリ等）やユーザエクスペリエンスへの影響ができるだけ少なくなるように設計されていてもよい。このようにブロッキングプロセスの実行よりもユーザエクスペリエンス及び監視に注目することは、第１のオペレーティングシステムのセキュリティスペースに特有のものであってもよい。

１以上の実施形態は、設定ファイル実施の第１のオペレーティングシステムの構成プロファイルモバイルデバイス管理（ＭＯＭ）の実施に対応できる１以上の能力を許容してもよい。これらの設定とアクションは全て、オペレーティングシステム又はＭＯＭプロバイダによって提供される機能よりもむしろ、本開示で開示するシステム又は方法に関連する１以上のコードで作成されていてもよい。

例えば、“ｓｈｏｕｌｄＫｉｌｌＮｅｔｗｏｒｄ？”を“ｔｒｕｅ”に設定する設定を有する構成プロファイルは、システムファイアウォールの設定を変更して、コンピュータ上の全てのネットワークトラフィックを無効にしてもよい。第２の設定“ａｌｌｏｗｅｄＮｅｔｗｏｒｋｌｏｃａｔｉｏｎｓ”が、企業のＭＯＭサーバや第１のオペレーティングシステムのサーバ等の特定のウェブサイトをホワイトリストに登録した場合、コンピュータは脅威を軽減するために遠隔で制御することができる。

本開示で開示するシステム又は方法は、グラフィカルユーザインターフェース又は視覚的要素を多用しなくてもよい。

ある実装形態においては、本開示で開示するシステム又は方法は、非常に軽いセキュリティツールであってもよい。他のセキュリティツールは最新で最速のｍａｃでさえも定期的に減速させる。

全ての構成は、設定が遠隔で行えるように。第１のオペレーティングシステム（ｍａｃＯＳ）の構成プロファイルを用いてもよい。

本開示で開示するシステム又は方法はその独自の「クラウド」に呼び戻さなくてもよく、それよりも企業のログツールを用いてログが収集されるまでは、ログはローカルに保存される。

ある実施形態において、本開示のシステムは、セキュリティ又は運用上の価値があるログのみを収集する。

ＯｐｅｎＢＳＭから全てのログを収集することは現実的ではないかもしれない。実際には、エンドポイントのリソース使用量（ＣＰＵ及び記憶装置）によって、ラップトップやデスクトップを極端に遅くする場合がある。財務上、一日当たりコンピュータ毎に３００ＭＢを超える量を保存することはライセンス、ホスト型ストレージコスト、及びインターネット帯域幅の面で極端に高価である。

第１のａｕｄｉｔ＿ｅｖｅｎｔフィルタのために誤ったａｕｄｉｔ＿ｃｌａｓｓｅｓを収集するとＣＰＵに負荷がかかる。例えば、／ｄｅｖ／ａｕｄｉｔｐｉｐｅ上で誤ったａｕｄｉｔ＿ｃｌａｓｓｅｓを収集すると、一貫してＣＰＵ使用率が４０％以上となることが観察された。

本開示の実施形態は、全ての関連のセキュリティイベントを確実に捕捉するのに役立つ。収集されたａｕｄｉｔ＿ｃｌａｓｓはａｕｄｉｔ＿ｅｖｅｎｔのタイプを含んでいてもよく、ネットワークイベント、ログインイベント、及びプロセス実行などのカテゴリーに分類されてもよい。全てのａｕｄｉｔ＿ｃｌａｓｓｅｓ及びａｕｄｉｔ＿ｅｖｅｎｔｓは、ｍａｃＯＳにデフォルトでインストールされるオペレーティングシステムのオリジナルの開発者によって構成されてもよい。否定的な結果である失敗の状態を検出する成功率は高い場合もある。システムへのログインなどのアクションごとに、例えば、３～１０の異なるａｕｄｉｔ＿ｅｖｅｎｔｓを生成してもよい。これら、例えば３～１０のａｕｄｉｔ＿ｅｖｅｎｔｓは、それぞれ異なる重要な情報を含んでいてもよい。

本開示で開示するシステム又は方法は、／ｄｅｖ／ａｕｄｉｔｐｉｐｅ上の監査カーネル成分から、収集のために望まれるａｕｄｉｔ＿ｃｌａｓｓｅｓを定義してもよい。そのａｕｄｉｔ＿ｃｌａｓｓｅｓから、本開示で開示する１以上の実施形態では更にデータストリームをフィルタリングして、関連する各ａｕｄｉｔ＿ｃｌａｓｓからのａｕｄｉｔ＿ｅｖｅｎｔｓのみを保持するようにしてもよい。

本開示の実施形態はＫｅｘｔフリーアプリケーションデザインを含んでいてもよい。例えば、ある実施形態は、カーネルアクセスのために第１のオペレーティングシステムのコードを活用することができ、多くの安定性とセキュリティ上の利点を提供し得るが、改ざんに対する耐性のような運用上の課題をもたらすこともある。

本開示に係るシステム又は方法は、悪意のあるアプリケーション又は十分な権限を持っているユーザに対し、コンピュータシステムからツールを削除することについて警告することができる。

１以上の実施形態においては、システムは、「管理者」以上の権限を持つユーザ又はアプリに対してのみ脆弱である場合がある。

一以上の実施形態において、バイナリ及び構成ファイルは悪意のある改ざんから保護されていてもよい。

一以上の実施形態においては、これらの保護により、アタッカーは、本開示に記載のツールをコンピュータデバイスから削除するための複数のアクションを行うよう強いられるため、改ざんイベントをログに記録するのに十分な時間が提供される。

関連ファイルは、第１のオペレーティングシステムにネイティブな“ｕｃｈｇ”フラグで保護されていてもよい。“ｕｃｈｇ”は、ファイルを改変したり削除したりできる全てのユーザ及びアプリに対して、第２のコマンドである“ｎｏｕｃｈｇ”を要求することができる。この２ステップ構成への変更により、スキルの低いアタッカーを妨害し、高度なスキルを持ったアタッカーのログをとるのに十分な時間が提供される。全ての設定は、第１のオペレーティングシステムによってカーネルレベルで実施される構成プロファイルを使用して設定することができる。システム上の設定ファイルに悪意のある改変があっても、構成プロファイルが使用されていれば影響はない。一以上の実施形態において、アプリケーションが終了するか又は“ｋｉｌｌｅｄ”の場合、バックグラウンドで実行されるアプリケーションは自動的に再起動される。バックグラウンドプロセスファイルは、他のサポートされるファイルと同じ“ｕｃｈｇ”フラグによって保護される。

アプリケーション出力をフォーマットするために、ある実装形態においてＪＳＯＮスタンザは手入力されてもよく、これにより第１のオペレーティングシステムのイベント命名規則を第２のオペレーティングシステムのセキュリティツールの命名規則にマッピングする。各スタンザはＯｐｅｎＢＳＭ監査トークンフォーマットへとマッピングされてもよい。各イベントは、最終的に組み合わされてそのイベントを表すＪＳＯＮオブジェクトが作成される、複数のＪＳＯＮスタンザを有していてもよい。フィルタリングされたイベントは、次にＪＳＯＮオブジェクトに構造解析されてもよい。構文解析エンジンを通した単一のイベントのフローを以下に述べる。例えば、単一のバイナリａｕｄｉｔ＿ｅｖｅｎｔが構造解析エンジンによって受け取られ、バイナリイベントはトークンごとにパーサに読み込まれ、イベント行は対応するＪＳＯＮスタンザへとマッピングされ、単一のフィルタリングされたイベント由来のＪＳＯＮスタンザは組み合わされてＪＳＯＮオブジェクトとなる。結果的に得られるＪＳＯＮオブジェクトは、単一のバイナリイベントからの全てのデータを有していてもよい。

本開示で開示するシステム及び方法が占める、バックグラウンドで利用可能なＣＰＵの割合が大きくない場合もあり、その場合システムの速度が低下する。

大ボリュームのイベントが第１のａｕｄｉｔ＿ｅｖｅｎｔマッチングフィルタによってフィルタリングされてもよく、この能力を達成するためには、コードが高度に最適化されていなければならない。

ある実施形態において、開示されるシステム又は方法は、検出した脅威をブロックしない。あるケースでは、脅威をブロックするために、アプリケーションは、カーネル内に独自のｋｅｘｔを必要とする場合があり、その場合は本開示で議論したような他の問題を引き起こしかねない。しかしながら、必要であれば、開示されるシステム及び方法は脅威をブロックできると考えられる。

本発明の代表的な実施形態の上記説明において、本開示を合理化し、様々な発明の態様のうち一以上の態様を理解する一助とすることを目的として、本発明の様々な特徴が時折単一の実施形態や、図や、その説明においてまとめられることは認識されるであろう。しかしながら、開示されるこの方法は、各請求項に明示的に記載されたものよりもより多くの特徴を必要とする、という意図を反映するものである、と解釈されるべきではない。むしろ、特許請求の範囲が表すように、発明の態様は、単一の、上で開示された実施形態の全ての特徴よりも少ないところにある。したがって、発明の詳細な説明に続く特許請求の範囲は、これにより、この発明の詳細な説明に明示的に組み込まれ、各請求項は、本発明の別個の実施形態として独立に成立するものである。

更に、本開示に記載の実施形態の中には、他の実施形態に含まれる一部の特徴は含むものの他の特徴は含まないものもあるが、当業者であれば理解できるように、異なる実施形態の特徴の組み合わせは本発明の範囲内であり、異なる実施形態を形成することを意味する。例えば、以下の特許請求の範囲において、特許請求の範囲に記載された実施形態はいずれもどのような組み合わせによって用いられてもよい。

したがって、ある特定の実施形態が述べられていても、本発明の趣旨を逸脱することなく他の、更に別の改変を加えてもよいことは当業者であれば認識できるであろうし、そのような変更や改変は全て本発明の範囲内のものであるとして権利要求することが意図されている。例えば、ブロック図に機能を追加しても、ブロック図から機能を削除してもよく、機能ブロックの間で操作を入れ替えてもよい。本発明の範囲内で、記載の方法に対してステップを追加しても削除してもよい。上で開示された主題は例示的なものであって限定的なものではないと考えられるべきであり、添付の特許請求の範囲は本開示の真の趣旨及び範囲に属する全ての改変、変更、拡張、及びその他の実装形態をカバーすることを意図している。したがって、法律によって認められる最大の範囲で、本開示の範囲は、特許請求の範囲及びその均等物の可能な限り広範な解釈によって決定され、上述の詳細な説明によって制限又は限定されるものではない。本開示の様々な実装形態を説明したが、当業者にとっては、本開示の範囲内で実施可能なより多くの実装形態があることは明らかであろう。したがって、本開示は添付のクレームとその均等物を除いて制限的なものではない。

Claims (20)

1. コンピュータによって実行される、セキュリティイベントの監視のための方法であって、
   １以上のプロセッサが、第１のオペレーティングシステムのセキュリティモジュールからデータを受け取り、
   前記１以上のプロセッサが、セキュリティイベント監視アプリケーションによる収集のための監査クラスデータフィルタを定義し、
   前記１以上のプロセッサが、収集された監査クラスデータの量を定義する詳細度レベルとして、前記監査クラスデータフィルタの前記詳細度レベルを受け取り、
   前記１以上のプロセッサが、前記監査クラスデータフィルタの前記詳細度レベルに基づき前記データのフィルタリングを行い、
   前記１以上のプロセッサが、前記データと、前記監査クラスデータフィルタとを比較し、
   前記データの、前記監査クラスデータフィルタとの比較に基づき、前記データが前記監査クラスデータと一致しないと判断された場合には前記１以上のプロセッサが前記データを削除し、
   前記１以上のプロセッサが、前記データと、一連のブラックリストに登録された値とを比較し、
   前記データの、前記一連のブラックリストに登録された値との比較に基づき、前記一連のブラックリストに登録された値の中の１以上のブラックリストに登録された値と前記データとが一致すると判断された場合には前記１以上のプロセッサが前記データを削除し、
   前記監査クラスデータの一部であり、第１のコンピューティングデバイスによって行われるアクションに関する監査イベントデータを前記１以上のプロセッサが捕捉し、
   前記１以上のプロセッサが、監査イベントの属性に関する少なくとも１つのトークンをトークン識別子に基づき決定し、
   前記プロセッサが、前記少なくとも１つのトークンを共通構造フォーマットに構文解析し、
   前記データの、前記監査クラスデータフィルタ及び前記ブラックリストに登録された値との比較に基づき、前記共通構造フォーマットのデータを前記１以上のプロセッサが出力する、方法。
2. 前記共通構造フォーマットは、ＪＳＯＮ、ｃｓｖ、又はｘｍｌのうち少なくとも１つである、請求項１に記載のコンピュータによって実行される方法。
3. 前記１以上のプロセッサが、前記第１のオペレーティングシステムを実行する第１のコンピューティングデバイスのための設定ファイル変更を受け取ることと、
   前記１以上のプロセッサが、前記設定ファイル変更に基づき、前記セキュリティイベント監視アプリケーションによる応答アクションを行うことと、を更に含む、請求項１に記載のコンピュータによって実行される方法。
4. セキュリティイベントの監視のための非一時的なコンピュータ可読媒体であって、前記非一時的なコンピュータ可読媒体は命令を格納し、前記命令は、１以上のプロセッサによって実行されると、
   前記１以上のプロセッサが、第１のオペレーティングシステムからデータを受け取り、
   前記１以上のプロセッサが、セキュリティイベント監視アプリケーションによる収集のための監査クラスデータフィルタを定義し、
   前記１以上のプロセッサが、前記データと、前記監査クラスデータフィルタとを比較し、
   前記１以上のプロセッサが、前記データと、一連のブラックリストに登録された値とを比較し、
   前記処理データの、前記監査クラスデータフィルタ及び前記ブラックリストに登録された値との比較に基づき、共通構造フォーマットのデータを前記１以上のプロセッサが出力する
   処理を行うように前記１以上のプロセッサを構成する命令である、非一時的なコンピュータ可読媒体。
5. 前記データの、前記監査クラスデータフィルタとの比較に基づき、前記データが監査クラスデータと一致しないと判断された場合には前記１以上のプロセッサが前記データを削除することを更に含む、請求項４に記載の非一時的なコンピュータ可読媒体。
6. 前記データの、前記一連のブラックリストに登録された値との比較に基づき、前記一連のブラックリストに登録された値の中の１以上のブラックリストに登録されたストリングと前記データとが一致すると判断された場合には前記１以上のプロセッサが前記データを削除することを更に含む、請求項４に記載の非一時的なコンピュータ可読媒体。
7. 監査クラスのデータの一部であり、第１のコンピューティングデバイスによって行われるアクションに関する監査イベントデータを前記１以上のプロセッサが捕捉することを更に含む、請求項４に記載の非一時的なコンピュータ可読媒体。
8. 前記１以上のプロセッサが、監査イベントの属性に関する少なくとも１つのトークンをトークン識別子に基づき決定することを更に含む、請求項７に記載の非一時的なコンピュータ可読媒体。
9. 前記１以上のプロセッサが、前記少なくとも１つのトークンを前記共通構造フォーマットに構文解析することを更に含む、請求項８に記載の非一時的なコンピュータ可読媒体。
10. 前記共通構造フォーマットは、ＪＳＯＮ、ｃｓｖ、又はｘｍｌのうち少なくとも１つである、請求項９に記載の非一時的なコンピュータ可読媒体。
11. 前記１以上のプロセッサが、収集された監査クラスデータの量を定義する詳細度レベルとして、前記監査クラスフィルタの前記詳細度レベルを受け取ることを更に含む、請求項４に記載の非一時的なコンピュータ可読媒体。
12. 前記１以上のプロセッサが、前記監査クラスフィルタの前記詳細度レベルに基づき前記データをフィルタリングすることを更に含む、請求項１１に記載の非一時的なコンピュータ可読媒体。
13. 前記１以上のプロセッサが、前記第１のオペレーティングシステムを実行する第１のコンピューティングデバイスのための設定ファイル変更を受け取ることと、
    前記１以上のプロセッサが、前記設定ファイル変更に基づき、前記セキュリティイベント監視アプリケーションによる応答アクションを行うことと、を更に含む、請求項１１に記載の非一時的なコンピュータ可読媒体。
14. コンピュータによって実行される、セキュリティイベントの監視のための方法であって、
    前記１以上のプロセッサが、第１のオペレーティングシステムからデータを受け取り、
    前記１以上のプロセッサが、（１）前記データと、監査クラスデータフィルタとを比較すること、及び／又は（２）前記データと、一連のブラックリストに登録された値とを比較すること、のうち少なくとも１つを行い、
    前記処理データと、前記監査クラスデータフィルタ及び／又は前記ブラックリストに登録された値との比較に基づき、共通構造フォーマットのデータを前記１以上のプロセッサが出力する、方法。
15. 前記データの、前記監査クラスデータフィルタとの比較に基づき、前記データが前記監査クラスデータと一致しないと判断された場合には前記１以上のプロセッサが前記データを削除することを更に含む、請求項１４に記載のコンピュータによって実行される方法。
16. 前記データの、前記一連のブラックリストに登録された値との比較に基づき、前記一連のブラックリストに登録された値の中の１以上のブラックリストに登録された値と前記データとが一致すると判断された場合には前記１以上のプロセッサが前記データを削除することを更に含む、請求項１４に記載のコンピュータによって実行される方法。
17. 監査クラスのデータの一部であり、第１のコンピューティングデバイスによって行われるアクションに関する監査イベントデータを前記１以上のプロセッサが捕捉することを更に含む、請求項１４に記載のコンピュータによって実行される方法。
18. 前記１以上のプロセッサが、監査イベントの属性に関する少なくとも１つのトークンをトークン識別子に基づき決定することを更に含む、請求項１７に記載のコンピュータによって実行される方法。
19. 前記１以上のプロセッサが、前記少なくとも１つのトークンを前記共通構造フォーマットに構文解析することを更に含み、前記共通構造フォーマットは、ＪＳＯＮ、ｃｓｖ、又はｘｍｌのうち少なくとも１つである、請求項１８に記載のコンピュータによって実行される方法。
20. 前記１以上のプロセッサが、収集された監査クラスデータの量を定義する詳細度レベルとして、前記監査クラスデータフィルタの前記詳細度レベルを受け取ることと、
    前記１以上のプロセッサが、前記監査クラスデータフィルタの前記詳細度レベルに基づき前記データのフィルタリングを行うことと、を更に含む、請求項１４に記載のコンピュータによって実行される方法。

Images