SIEM
ファイアウォール、サーバ、端末などが出力するログを一か所に集約し、形式をそろえる正規化を行ったうえで、複数のログを突き合わせる相関分析によって脅威を検知・可視化するセキュリティ製品・仕組みである。集めたログを保存し、インシデントの調査や監査への対応にも使う。
イマシルちゃんの解説
会社のネットワークでは、ファイアウォールやサーバ、PCがそれぞれ自分の記録を残しているんだ。
でも一台ずつ見ていたら時間がかかるし、攻撃のつながりにも気付きにくいよ。
SIEMは、こうしたログを一か所に集めて分析するセキュリティ製品なんだ。
書き方がばらばらなログを同じ項目にそろえてから、別々の機器の記録を照らし合わせるよ。
例えば「ログインの失敗が続いたあと、同じ相手からの成功があった」という流れを見つけて知らせてくれるの。
攻撃の兆しに早く気付けて、後から原因を調べるときの手がかりにもなるんだ。
この解説はわかりやすかったですか?
より深い解説
定義と生まれた経緯
SIEM(Security Information and Event Management)は、組織内の多様な機器やシステムからセキュリティに関わるログを集め、分析・検知・保管を行う製品群の総称である。2005年にGartnerのアナリストが、二つの製品分野を統合した呼び名として用いた。
| 元の分野 | 主な役割 |
|---|---|
SIM(Security Information Management) | ログの長期保存、検索、報告書の作成 |
| SEM(Security Event Management) | リアルタイムの監視、イベントの相関、通知 |
つまりSIEMは、過去の記録をさかのぼる機能と、いま起きている事象を見張る機能を一つにまとめたものである。どちらに強いか、どこまで自動で判断するかは製品によって異なる。
単体の機器のログだけでは、攻撃の全体像が見えないことが多い。例えば認証サーバには「ログインに成功した」としか残らず、その直前に同じ送信元から大量の失敗があったことはVPN装置にしか残っていない場合がある。別々の場所にある記録を同じ時間軸に並べることが、SIEMの存在理由である。
ログを集めてから通知するまで
SIEMの処理は、おおむね次の順序で進む。
- 収集:ネットワーク機器やLinuxサーバからはsyslog、Windowsからはイベントログ、クラウドサービスからはAPIなどでログを受け取る。端末にログ転送用のエージェントを置く方式もある。
- 解析と正規化:製品ごとに異なる書式から、時刻、送信元IPアドレス、利用者名、宛先、動作の結果などの項目を取り出し、共通の項目名にそろえる。
- 情報の付与:IPアドレスに対応する資産の重要度や部署、脅威インテリジェンスの悪性リスト、国・地域などの情報を加える。この処理をエンリッチメントと呼ぶ。
- 分析:あらかじめ定めた相関ルールや統計的な分析で、注意すべき事象を見つける。
- 通知と可視化:アラートを出し、ダッシュボードに集計結果を表示する。
- 保存と検索:生のログとそろえた結果を保存し、調査や監査で検索できるようにする。
手順2の書式の違いは想像以上に大きい。ある機器は送信元を src、別の機器は source_ip と記録し、時刻の形式やタイムゾーンもばらばらである。そろえておかないと、「同じIPアドレスが関わる記録をすべて出す」という基本の検索すらできない。
ログを残す側の考え方や管理計画は、NISTのSP 800-92(2006年の「Guide to Computer Security Log Management」)で整理されている。2023年には改訂版の草案(Rev.1)が公開され、ログ管理の計画づくりに重点を移している。
突き合わせの規則の例
相関分析とは、単独では判断できない複数の事象を、条件と時間の範囲で結び付けることである。次は、パスワードを総当たりで試す攻撃を想定した独自のルール例である。
条件1:同じ送信元IPアドレスから、5分以内に認証失敗が10回以上
条件2:その直後10分以内に、同じ送信元から認証成功が1回以上
結果 :条件1と条件2が両方成立したら「総当たり攻撃による侵入の疑い」として通知
失敗だけで通知すると、パスワードを忘れた利用者でも毎回アラートになる。成功だけでは、正規のログインと区別できない。両方を時間の順序で結び付けることで、「試行の末に突破された」という意味のある事象として扱える。
ほかにも、次のような組合せがよく使われる。
| 組み合わせる記録 | 疑われる事象 |
|---|---|
| EDRのマルウェア検知と、同じ端末からの外部への大量送信 | 感染端末からの情報の持ち出し |
| 同じアカウントによる、短時間での離れた国からのログイン | 認証情報の盗用 |
| 業務時間外の管理者ログインと、権限の変更 | 不正な管理者操作 |
| 悪性リストに載った宛先へのDNS問合せ | マルウェアの外部通信 |
閾値を下げれば見逃しは減るが、誤検知が増える。逆に上げれば通知は減るが、ゆっくり試す攻撃を見逃す。ルールは導入して終わりではなく、運用の結果を見ながら調整を続ける。
時刻をそろえる重要性
相関分析は時刻の順序を前提にしている。機器の時計が数分ずれていると、「失敗の後に成功」が「成功の後に失敗」に見えたり、時間の範囲から外れて関連付けられなかったりする。そこで、ログを出力するすべての機器をNTPで同じ時刻源に同期させる。
タイムゾーンの扱いも統一する。日本時間で記録する機器と協定世界時(UTC)で記録する機器が混在すると、9時間のずれが生じる。SIEM側で取り込み時に変換するか、出力側の設定をそろえる。
ログ管理基盤・SOAR・UEBA・EDRとの違い
SIEMの周辺には、似た役割の製品が多い。何を入力にし、何を出力するかで区別する。
| 名称 | 主な入力 | 主な役割 |
|---|---|---|
| ログ管理基盤(syslogサーバなど) | 機器のログ | 保存と検索。相関による検知は主目的ではない |
| SIEM | 多様な機器のログ | 正規化・相関分析による検知、可視化、保管 |
| SOAR | SIEMなどのアラート | 対応手順の自動化と、複数製品の連携 |
| UEBA | 利用者や機器の行動の記録 | 普段の行動との違いから異常を見つける |
| EDR | 端末内部の活動 | 端末での検知・調査・対応 |
SOAR(Security Orchestration, Automation and Response)は、アラートを受けてからの作業をプレイブックと呼ぶ手順書に沿って実行する。例えば「悪性の宛先を検知したら、脅威インテリジェンスで評価を調べ、該当端末をEDRで通信遮断し、担当者へ連絡する」といった一連の作業を実行する。SIEMが「見つける」側、SOARが「動かす」側と考えると区別しやすい。
UEBA(User and Entity Behavior Analytics)は、利用者や機器ごとに普段の行動を学習し、そこから外れた行動を見つける。固定の相関ルールでは書きにくい内部不正や、正規のアカウントを盗まれた攻撃の発見に使う。最近のSIEM製品には、UEBAやSOARの機能を組み込んだものも多い。
EDRは端末の内部を深く見る製品であり、SIEMは種類を問わずログを横断的に見る基盤である。EDRのアラートをSIEMに取り込み、ネットワーク機器や認証のログと突き合わせる構成がよく使われる。
設計の観点
SIEMの設計は「何を検知したいか」から逆算する。すべてのログを集めれば安心に見えるが、量が増えるほど費用と検索時間が増え、重要な事象が埋もれる。不正ログインを見つけたいなら認証サーバとVPN装置のログ、情報の持ち出しを見つけたいならプロキシサーバやファイアウォールの通信ログ、というように目的と対応付ける。
| 観点 | 検討すること |
|---|---|
| 収集対象 | 検知したい事象に必要な機器とログの種類。死角になる機器がないか |
| 量と性能 | 1秒当たりのイベント数(EPS)、1日のデータ量、検索の応答時間 |
| 保存期間 | 調査に必要な期間、社内規程や法令・業界基準の要求 |
| 完全性 | ログの改ざん防止、欠落の検知、管理者権限の分離 |
| 転送経路 | 帯域、送信の信頼性、暗号化、拠点からの経路 |
多くの製品は、取り込むデータ量や処理件数で費用が決まる。保存期間は、すぐ検索できる領域と安価な長期保存の領域に分けることが多い。
転送経路では、syslogの方式に注意する。UDPのsyslogは軽い反面、届かなかったログを再送しないため、輻輳時や受信側の停止中に欠落する。重要なログはTCPによる転送や、TLSで暗号化したsyslog(RFC 5425)を使う。ログの書式自体はRFC 5424で定められている。
攻撃者は侵入の痕跡を消すため、端末や機器のログを削除することがある。ログを発生と同時にSIEMへ送っておけば、元の機器で削除されても記録が残る。SIEM自身へのアクセス権も、監視対象のシステム管理者とは分けて管理する。
運用を担う組織との関係
SIEMは導入しただけでは役に立たない。アラートを見て判断する人がいて初めて機能する。この監視と分析を担う組織がSOCである。SIEMのアラートをこの組織の分析者が調べ、対応が必要ならCSIRTなどへ引き継ぐという分担が典型的である。
運用では、アラートの多くが誤検知であることが珍しくない。誤検知が続くと担当者が通知を軽視し、本物のアラートを見逃す。誤検知の原因を記録して除外条件やしきい値を見直し、逆に見逃した事例から新しいルールを作る。このように検知ルールを継続して改善する作業が、SIEM運用の中心になる。
トラブル時の切り分け
| 観測した状態 | 確認すること |
|---|---|
| ある機器のログだけが届かない | 送信設定、宛先のIPアドレスとポート、途中のファイアウォール、UDPでの欠落 |
| ログは届くが検索で見つからない | 解析ルールが書式の変更に追従しているか、正規化の失敗 |
| 相関ルールが成立しない | 機器間の時刻のずれ、タイムゾーン、項目名の不一致 |
| アラートが多すぎる | しきい値、除外条件、資産情報の不足 |
| ある日から急にデータ量が増えた | 機器のログレベル変更、障害による大量出力、攻撃の可能性 |
午後での問われ方
- 複数機器のログを示し、時刻をたどって攻撃の流れや侵入の起点を特定させる。
- 相関分析が成り立たない原因として、時刻同期の不備を指摘させる。
- ログを機器内に残すだけでなく、SIEMへ即時に転送する理由を、痕跡の削除と関連付けて説明させる。
- syslogの転送で欠落が起きる理由と、その対策を問う。
- 検知したい事象から、収集すべきログの種類や機器を選ばせる。
- SIEM・SOAR・EDRの役割分担や、SOCでの運用の流れを問う。