今回は、サイバーセキュリティに関する非営利組織「Center for Internet Security, CIS」がとりまとめた「CIS クリティカルセキュリティ コントロール トップ20 ( CIS top 20 Critical Security Controls)」の第7版から、「コントロール2 ソフトウェア資産のインベントリとコントロール」を見ていきます。そして必須要件として挙げられている10のサブコントロール項目を確認し、その上で気づいたことをシェアしていきます。
内容:すべてのビジネスシステム上ですべてのビジネス目的のために組織が要求した、すべての許可されたソフトウェアの最新リストを維持します。
留意点: 大きな組織のリストを一から作るのは難しいと思います。他のコントロールでも指摘したように、今存在しているもののベースラインから始めて(下記必須要件3)、リストにあるどのソフトウェアが承認されているかに注目していく方が簡単かもしれません。言うまでもなく、環境内の新しいソフトウェアも監視します。
内容:ソフトウェアベンダーが現在サポートしているソフトウェアアプリケーションまたはオペレーティングシステムのみが、組織が認可したソフトウェアインベントリに追加されるようにしてください。サポートされていないソフトウェアは、サポートされていないとインベントリシステム上でタグ付けしなければなりません。
内容:組織全体のソフトウェアインベントリツールを使用して、ビジネスシステム上のすべてのソフトウェアの文書化を自動化します。
留意点:Tripwire Enterpriseといったファイル整合性監視(File Integrity Monitoring)ツール を使用すると、新しいソフトウェアのための環境をスキャンできます。このような自動化ツールをドライバにして、インベントリデータベースにデータを追加します。
内容:ソフトウェアインベントリシステムは、組織によって許可されたオペレーティングシステムを含むすべてのソフトウェアの名前、バージョン、発行元、およびインストールした日付を追跡する必要があります。
留意点:もし上記の必須要件3で指摘されたツールを使用している場合、この必須要件のすべての項目ではないとしても、ほとんどを追跡することができます。オペレーティングシステムのスナップショットでは、データの収集方法によってインストールの日付を収集できないことがあります。その場合、時間をかけて継続的にシステムをスキャンし、結果を追跡するのが最善です。
内容:ソフトウェアインベントリシステムはハードウェア資産インベントリに紐付ける必要があります。それによってすべてのデバイスと関連ソフトウェアが一箇所から追跡できます。
留意点:Tripwire IP360のような脆弱性管理製品等のツールには、新しいデバイスの環境をスキャンすることと、そこで実行されているもののインベントリを作成することの2つの目的を持つものがあります。目的が1つしかないツールに関しては、資産管理システムとの統合のために徹底に調査されたかを確認し、1つのリポジトリにデータを保管できるようにします。
内容:認可されていないソフトウェアは削除されるか、インベントリが適時更新されるようにします。
留意点:ベースラインさえあれば、このコントロールの管理は簡単です。システムにインストールされているアプリケーションの変更は滅多にあることではありません。
内容:すべての資産にアプリケーションのホワイトリストテクノロジーを適用し、許可されているソフトウェアのみ実行し、すべての許可されていないソフトウェアの資産上での実行を防止してください。
留意点:これは、コントロール全体において、最も重要な推奨事項です。これが適切に実行されれば、攻撃者を止めることができます。現在(サポートされているバージョンで)Windowsを実行しているすべての人が自由に利用できるので、AppLockerの機能について話したいと思います。まず最初に、フォルダー/ファイル名でホワイトリストを作成できます。これにより、ホワイトリストの管理が非常に簡単になります。また、攻撃者に既存のフォルダ/名前構成を再利用する機会も提供します。次に、ファイルハッシュによってホワイトリストの作成が可能であり、これは驚くほど効果的です。しかしながら、ファイルハッシュのリストを絶えず更新するという代償を払わねばならず、これは組織全体にとっての悪夢となるでしょう。最後に、デジタル署名されたファイルに基づいてホワイトリストを作成するという選択肢があります。これは前述の2つの選択肢の間で良いバランスをとっています。しかしながら攻撃者からもバイパスが可能です。環境全体を簡単に管理できるホワイトリストテクノロジーを選びましょう。もしもそれが不可能なら、重要なシステムのためにAppLockerについて考慮します。
内容:組織のアプリケーションのホワイトリストソフトウェアは、必ず許可されたソフトウェアライブラリ(* .dll、* .ocx、* .soなど)だけがシステム工程にロードされるようにしなくてはなりません。
留意点:ホワイトリストのソリューションを決定するときは、この点が守られるように確認してください。私が知る限り、AppLockerはどのライブラリがロードされたのかを定義することはできません。そのため、このサブコントロールの実行には、有料の選択肢しかないことになります。
内容:組織のアプリケーションホワイトリストソフトウェアは、許可されたデジタル署名されたスクリプト(*.ps1、*.py、macrosなど)だけがシステムで実行されることを保証しなくてはなりません。
留意点:前述の必須要件と同様、使用中のホワイトリストのテクノロジーで上述の点が確保されていることを確認してください。 AppLockerの観点からどのユーザに実行能力があるか定義することも可能です。
内容:業務の実行に必要だが組織に高リスクを招くソフトウェアを実行する際には、物理的にもロジック的にも分離されたシステムを利用して隔離する必要があります。
留意点:このことがコントロールに含まれているのは非常によいことです。ビジネスでは高リスクのアプリケーションを環境下で実行しなければならないことがあるものです。その際に重要なのは、攻撃を防御し、かつ検出するために、コントロールを適切に調整する必要があることです。これらのシステムへのトラフィックやアクティビティは、充分に精査されなくてはなりません。これらのシステムは、真っ先にアプリケーションのホワイトリストとホワイトリストネットワークトラフィックの対象とすべきです。
By Travis Smith