セキュリティ運用に必須のパッチ管理とログ監視（後編）

はじめに

前回から、実際のセキュリティ運用に必須な「パッチ」の管理と「ログ」の監視について解説しています。

前回は、バッチの集中管理を行うツールを紹介しました。今回は「ログの集中監視を行うツール」について簡単に紹介します。

ログの集中監視ツールの存在意義

ログの集中監視は、ことセキュリティだけにとどまらず重要なものです。そのため、昔からOSSや商用製品、またハードウェアやソフトウェア/アプリを問わず、様々なログの収集監視方法が確立されています（図1）。

図1：機器/ソフトウェアのログ監視

このように、ログを個別の製品・レイヤで収集し監視を行っていると、運用面の簡便性から一か所にログを集中させて共通のインターフェースで監視したいというニーズが強くなります。また、ログを一か所に集中してバックアップを取得することで、システム全体に何か問題が発生した場合に、どのような経緯から問題が発生したかを解明・報告する際の証拠保全的な意味を持たせることもできます（図2）。

図2：機器/ソフトウェアのログの集中監視

さらに、ログを集中化させて表示させるところから一歩進んで、それぞれのログと時間から相関関係を持たせて分析（いわゆる相関分析）を自動で行わせるようなツールが出てきました。例えば、図3のように

1. 社内のPCが外部のブラックリストサーバに接続
2. その後、該当PCが社内Windowsサーバのファイルに接続（成功）
3. その後、該当PCが社内のUnix/Linuxに不正アクセス

図3：機器/ソフトウェアのログを組み合わせた相関分析

というようなログが時系列に沿って出力された場合には「社内のPCがC&Cサーバから指令を受け取り、ファイルの入手とサーバへの不正アクセスを試みている」と判断し、その旨を監視者に通知するような仕組みです。この場合、個々のログだけを見ていた場合には特に2の箇所が見逃されてしまうため、「怪しいPCが社内の情報を入手した」という所まではなかなかたどり着けません。

他にも、社内システムの位置（ネットワーク）情報を登録しておき、その位置情報からあり得ない動きをした際にアラートを出すようなシステムも考えられます。

例えば、図4のようにスイッチングハブやWindows上のログでは東京のLANに繋がっていたマシン上のユーザIDが、アプリサーバのログでは1時間後にニューヨークから接続／認証している、等です。このような場合にも個々のログを見ていれば特に問題はありません（エラーは出ず成功している）が、組み合わせることで不審な事象が見えてきます。

図4：機器/ソフトウェアのログを組み合わせた相関分析(1)

あるいは、1日のレポートを見ると営業時間外にメールサーバへ接続しているPCがあったとします。このPCが関係する過去のログを検索すると、数日おきに怪しいサイトへ接続したり、サーバ上の無関係なファイルにアクセスした形跡があるため、このPCが何らかの攻撃で踏み台にされ、検出を避けるために長期間の間隔を置いて不正アクセスしている可能性があることが窺えます（図5）。

図5：機器/ソフトウェアのログを組み合わせた相関分析(2)

このように、たくさんのログや時間、ID、接続元、接続先の情報を組み合わせて、特にセキュリティ上で問題となるような不審な行動や操作、発見が難しい攻撃の動きを見つけ出し、ユーザに通知する製品としてSIEM（Security Information and Event Management）があります。

商用のSIEM製品とOSSのSIEM製品

SIEM製品自体は、200X年代から様々な商用製品が展開されました。当時はSIM製品と呼ばれていましたが、現在も代表的な商用SIEM製品である「ArcSight」や「netForensics」、CiscoのMARS等が製品展開とサービスを行っていました。さらにMcafee等もSIEM製品を展開しており、現在では主要なセキュリティベンダーがそれぞれSIEM製品を持っている形になっています。また、OSSでは代表的なものとしてAlienVaultのOSSIM製品「SIEMonster」等があります（表）。

SIEM製品の一般的な構成

このようなSIEM製品は、一般的に図6のような構成になります。各コンポーネント間は専用プロトコルで通信を行います。それぞれのコンポーネントを説明しましょう。

図6：一般的なSIEM製品の構成

●Agent
各種製品からログの収集と正規化・集約化（後述）を行います。通常は専用アプリで、大量のログを処理できるようになっています。各機器がそれぞれ独自フォーマットのログを出力するため、Agentは機器（正確にはフォーマット）毎に専用のプログラムが用意されます。 このAgentは、大きく次の2つに分けられます。

• 独立したHWにインストールし、特定のポートから転送されてくるログを待機するもの。NW機器やFirewall、Windows、Linux/Unix等は、ほとんどがこちら
• 製品の入っているHWにインストールし、製品がローカルに出すログを転送するもの。Tomcat等のアプリやミドルウェアが該当

ApacheやSquid等、Syslog形式でログを転送することもできるアプリケーションに関しては、ログの量やネットワーク構成によってどちらかの形式を選ぶ形になります。

●Engine
SIEMの主要部分です。Engineが中心となってコンソールを通して設定される相関分析を行ったり、コンソールを通してクエリが投げられた過去ログを検索したりします。

●コンソール
Agentから上がってくる正規化・集約化されたログを、グラフやイベントビューアのようなGUI（WebUI）ツールで表示します。Engine部分で相関分析した結果等も表示されます。

また、ログの検索結果をまとめたレポート等を定期的にPDF等で表示します。グラフのカスタマイズや相関分析のルール作成、定時でログに検索を行うクエリ等もUIから設定します。一般的にシステム管理者（セキュリティ管理者）は、このモニタを見てシステムのセキュリティ状況を確認します。

●DB
Agentで正規化・集約化されたログはDBに保存されます。一般的に商用のOracleやMySQL、PostgreSQL等が使われます。それぞれのDBで得意・不得意があるため、補完しあう形で複数のDBが使われるケースもあります。

SIEM製品の用語

SIEM製品では、一般的に使われる独特の用語があります。

ログの集約化

特にファイアウォールのようなセキュリティ製品では、数秒間で同じログが何度も上がってくることがあります。これをそのままAgentを通して転送することもできますが、帯域や処理のコスト・ストレージ容量を削減するため、デフォルトで決まっている一定間隔に来たログは「ログメッセージ×回数」という形で格納してログの量を削減します。これを「ログの集約化」と言います。

ログの正規化

「正規化」とは、製品群から上がってくる様々な形式のログを一括で検索したり、関連付けて処理したりできるように区分け・フィールドの対応付けを行うことです。

LinuxのsyslogとWindowsのログを正規化する例で説明します（図7）。SIEM内部に各フィールドを用意しておき、Agentから来たログがそれぞれのフィールドのフォーマットに従った形式で格納されます。これがログの正規化です。SIEM製品で一定時間内にログインに成功したユーザを検索する場合は「日付」フィールドと「ユーザ名」フィールドでクエリを掛けるとLinux/Windowsを意識せずに串刺しで検索できます。

また、各フィールドの情報は正規化されている前提で相関分析のルールを作成します。これにより「各機器でどうなったか」という機器毎の差異を意識せずに、相関分析のルールを作成できます。

図7：ログの正規化

ログの相関分析

「相関分析」とは、正規化で各フィールドに入った値を元に、ログとログを関連付けることです。

例えば、下記のようなルールを作成して内部テーブルを一定時間でクリアするようにすれば、一定時間内の行為が段階的にNotify/Warn/Errorとコンソールへ通知されていくようなシステムを作ることができます（図8）。

1. 設定された業務時間以外のメールサーバへのIMAP情報を内部テーブルに載せる。同時にアラート（Notify）を通知
2. Proxyからログを抽出してIPアドレスの宛先を追記する。1.のテーブルを参照し、情報がある場合はアラート（Warn）、ない場合はアラート（Notify）を通知。同時に内部の別テーブルにIPアドレスに接続しているログ情報を載せる
3. 部門外へのファイルアクセスがあり、1.でNotify、2.でWarnが出ている場合にはアラート（Error）を通知。2.でWarnが出ていない時にはアラート（Warn）を通知。1.でNotifyのみでファイルへのアクセスがあった場合にはアラート（Warn）を通知

図8：ルールベースの相関分析

SIEM製品の問題点と最近のトレンド

(1) SIEM製品の速度の問題

SIEM製品の速度は「ログをDBに入れ、どのようにクエリを掛けるか」に依存します。そのため、瞬間的にSIEMのEngineコンポーネントに到達するログの量が増えれば増えるほど性能の劣化が激しくなります。

しかし、セキュリティ上のログを詳細に取れば取るほど、また取得する台数を増やせば増やすほど、瞬間的に出力されるログは増えていきます。

例えば、筆者の経験した中～大規模の企業では、1日に出力されるFirewallのログだけで1台10GBytes程度でした。つまり、1秒間に10Gbytes/(24×60×60)=約100Kbytesのログが出力されるため、Firewallが5台ほどの規模では秒間500Kbytesのログが書き込まれることになります。当然、他のFirewall以外の機器（サーバやルータ、アプリなど）からもログが頻繁に書き込まれます。

さらに、同時に相関分析等を行うため、DBコンポーネント部分のディスクにはかなりのI/Oがかかります。そのため、昔はSIEM製品を導入する際はHDDのサイジングだけでなくHDD上での物理的なデータの配置（それこそ、円盤部分の外周か内周かでアクセス速度が変わる）も計算に入れて設計を行わなければ、ログ検索や相関分析自体が使い物にならないくらいの速度になってしまう場合がありました。

しかし、現在はSSDが一般的になり、ディスクI/Oの問題も解決されています。また、クラウドベースの製品にすることで、昔と比べてさらにディスクI/Oの問題も軽微になりつつある状況です（クラウドが利用できない環境では今もディスクI/Oの問題は残っています）。

(2) 相関分析のルールの問題

SIEM製品を使う上では「相関分析のルール作り」が肝になります。しかし、裏を返せば「攻撃が検知できるか否かはルールを作る人の能力と経験にかかっている」とも言えます。

そのため、各商用SIEMベンダーは基本的な相関分析のルールを別パッケージとして販売したり、適切なルールを作れるエンジニアを企業に「プロフェッショナルエンジニアサービス」として有償で派遣したりするサービスを提供しています。しかし、それでも「ルールを作った人間の想像の範囲を超える攻撃」を検知するのは困難です。

このようなケースに対応するため、SIEM製品各社は機械学習などのAIと連携して「普段と違う振る舞いのログが上がった場合」にアラートを出すなど、振る舞い検知を行えるように製品を対応させています。

おわりに

今回で、本連載は最終回となります。1年近くにわたり本連載をお読みいただき、ありがとうございました！

OSSを利用したセキュリティ技術は日進月歩、日々登場してきています。また興味深い技術が登場した際は、別の形で紹介させていただきたいと思います。