クラウドベースのセキュリティ情報イベント管理（SIEM）を利用する企業もあれば、ローカルのデータセンターに導入したSIEMを利用する企業もあります。こうしたオンプレミスのSIEMは、Windows ServerやLinux Server、仮想マシン（VM）またはコンテナ上で稼働させることができます。これらの環境ごとにセキュリティ上の脆弱性は異なり、設定に大きく左右されますが、以下で紹介する同じチェックリストを使い、セキュリティを確認できます。このチェックリストの手順を表す頭字語をVIDA DUCAと呼びます。
チェックリストの各項目は、脆弱性の潜在的な原因に対処するためのリマインダーです。このチェックリストは、初回導入時だけでなく、継続的・定期的な更新（四半期ごと、年次）にも使用してください。チェックリストに従うことで、自社のSIEM導入環境のセキュリティが損なわれる可能性のある方法に、チームが目を向けやすくなります。
おすすめのSIEMソリューションもご覧ください。
脆弱性
脆弱性は、あらゆるプログラム、アプリケーション、システムに存在する可能性があります。SIEMをホストするシステム（サーバー、VMなど）では、脆弱性の多くが、導入時のミスや見落としから生じます。パッチが適用されていない脆弱性は軽減する必要があり、外部接続にSIEMシステムを公開する前にパッチを適用しなければなりません。
既知の脆弱性を特定するには、ペネトレーションテストや脆弱性テストを利用できますが、将来発見されるゼロデイ脆弱性が残る可能性もあります。残念ながら、ソフトウェアやハードウェアの脆弱性を徹底的にテストできるリソースを持つ企業は多くありません。そのため、研究者が脆弱性を発見して報告するのを頼りにせざるを得ない場合があります。報告を受けると、ベンダー（SIEM、OSなど）はパッチやアップデートを提供できるため、脆弱性を解消するため、できるだけ早く適用してください。
関連記事：SIEMシステムのテストと評価：Rapid7 InsightIDRレビュー
統合
SIEMを有用なものにするには、多数の異なるシステムと統合する必要があります。たとえば、エンドポイント、IoT、サーバー、ネットワーク機器、VM、クラウドリソースなどです。デバイスの種類ごとに、分析のためSIEMへログを送信できなければならず、各システムとの統合が必要です。直接統合できるデバイスもありますが、ログデータを抽出して取り込むために、個別のコードを記述しなければならないものも少なくありません。
このチェック項目は、各統合ポイントを、SIEMの潜在的な障害点として考慮し、入念に再確認するよう促すものです。統合のセキュリティを確認し、ペネトレーションテストやコードレビューによってコードをテストする必要があります。
実務上は、リスクが最も高いシステムを優先するとよいでしょう。最も価値の高い資産や業務プロセスに接続する統合はどれでしょうか。類似するサブシステムに最も多く接続するものはどれでしょうか。
デフォルト設定
多くのSIEMにはデフォルト構成が付属しています。その中には、明らかに誤っていて安全に使用できないものもあります。保持されているデフォルト設定がセキュリティに及ぼす影響を、慎重に調査・検討してください。
すべてのデフォルト設定が分かりやすいとは限りません。オプションのネストされたメニューを深く調べたり、ソフトウェア関連の構成ファイルを確認したりする必要がある場合もあります。後で確認すべき項目を把握できるよう、導入時にSIEMプロバイダーとこの点を必ず話し合ってください。ベンダーにデフォルト設定のチェックリストを求めるのは、妥当な依頼の範囲内です。
アラート
初期設定が終わると、データの取り込みが始まり、システムはアラートを生成し始めます。おめでとうございます。ここからが本当の作業です。SIEMはアラートを生成するために存在するのであり、そのアラートを価値あるものにする必要があります。
アラートについては、反復的なサイクルの中で4つの主な問題を検討する必要があります。
- 本来、どのアラートを受け取るべきか。
- 実際にはどのアラートを受け取っているか。
- どのアラートが必要か。
- アラートが多すぎるのは何件からか。
まず、SIEMの設定を調べることから始めてください。どのアラートが設定されているはずかは分かっていても、実際にそのアラートを受け取っているでしょうか。そのアラートは、本来知らせるべき内容を実際に通知しているでしょうか。
アラートを検討する際は、統合時に用いたのと同じリスクベースの優先順位に従うべきです。最も価値の高い資産についてアラートを受け取っていますか。最重要の業務プロセスが脅かされたときにアラートを受け取っていますか。そうでなければ、不足しているものを追加する必要があります。
イベントをシミュレートして、想定したアラートが発生するか確認することもできます。発生しない場合は、なぜでしょうか。設定に問題があるのでしょうか、それともシミュレーションでしょうか。必要なすべてのシステムで、望ましいアラートを定期的に受け取れるまで繰り返してください。
アラートに関するもう1つの大きな要因はコストです。SIEMでは、システムに投入されるデータ量に応じて課金されることが多いため、多くの組織はSIEMに送信する前にアラートを事前選別します。こうした事前選別フィルターを調査し、除外されたデータやアラートが本当に無害なものなのか、また人工知能（AI）アルゴリズムの学習に使うべきものではないのかを確認する必要があります。
必要なアラートを受け取り始めたら、セキュリティアナリストが監視・対応するアラートの量を確認します。無視されるアラートが出るほど大量に生成していませんか。単にノイズを増やすだけの、重要度の低いアラートはありませんか。アラートを過剰に生成しないため、より有用な監視対象となり得る別のアラートを検討してください。
SIEMを適切に調整できたら、パープルチームでテストできます。この種のテストでは、チームの一部が従来のレッドチームの役割を担い、アラートの発生を試みます。その後、ブルーチーム役を担ったメンバーがレッドチームとともに結果を検証します。アラートは想定どおり発生したでしょうか。SIEMまたはセキュリティチームは、データとアラートを適切に解釈したでしょうか。不一致があれば対処し、解決する必要があります。
データソース
SIEMは、受け取ったデータを使って判断を下します。悪いデータは、誤った判断やアラートの見逃しにつながります。SIEMを稼働させる際、エンドポイントが正常な状態にあると仮定してはいけません。エンドポイントの状態が変化したときにのみ発生するSIEMアラートもあり、エンドポイントが最初から侵害され、その状態が続いた場合、アラートは生成されません。
興味深いことに、ブロックチェーンシステムのスマートコントラクトにも、同様の問題があります。これは「オラクル」問題と呼ばれます。データソース、つまり「オラクル」が破損していたり、誤っていたり、汚染されていたりすると、スマートコントラクトが正しく実行されるとは信頼できません。
エンドポイントの検証監査を通じて、SIEMに入ってくるデータの品質に確信を持てるようになります。初回はすべてのシステムを監査する必要があるかもしれませんが、時間に余裕がない場合や、翌年以降の年次更新を行う場合は、代わりにシステムを無作為抽出して検証する方法もあります。
データの破損だけが悪い結果を生むわけではありません。誤ったログファイルが取得されたり、エンドポイントから不完全なログファイルが生成されたりすると、SIEMが誤解を招く結論に至る可能性があります。多くのSIEMは、AIまたは機械学習（ML）アルゴリズムを使ってデータから学習します。こうしたアルゴリズムに誤った種類のデータを与えると、解消が難しい偏りが生じる可能性があります。
ITやセキュリティのチームメンバーは通常、データサイエンティストではないため、ログファイルの設定がSIEMのアルゴリズムをどのように偏らせるか理解していない可能性があります。この問題に対処するには、チームにデータサイエンティストを加えるか、SIEMプロバイダーと連携する必要があります。この連携は、設定の初期段階から行うべきです。
ユーザー
SIEMのユーザー数は制限し、管理者ユーザーはさらに限定すべきです。ユーザーを決める際は、人数、アクセスの種類、トレーニングを考慮してください。
初回導入時には、すべてのシステムの統合・実装を支援するため、多くのユーザーが必要になるかもしれません。しかし、その多くは継続的なアクセスを必要としません。継続的なユーザー数は、SIEMの変更、検証、管理を必要とする社内外の専門家に限定すべきです。
適切なデータフィードを確認するだけでよく、継続的には読み取り専用の基本的なアクセス権限だけを必要とするユーザーもいます。一方、SIEM内のアラートを調整したりアルゴリズムを変更したりするため、より高いレベルのアクセス権限を必要とするユーザーもいます（後述の「アクセス」を参照）。ユーザー数と同様、特定のアクセス権限を持つユーザーについても、開始時に慎重に評価し、定期的（四半期ごと、年次など）に確認すべきです。
ユーザーには、想定される業務レベルに応じた入念なトレーニングも行うべきです。SIEMを適切に設定するため、初期段階では集中的なトレーニングを実施し、その後も定期的に更新して、SIEMの新機能やAI/MLアルゴリズムが生成するアラートの種類を理解できるようにします。
構成
SIEMは、次の3つの方法で構築できます。
- ローカルのデータセンターにあるサーバー、VM、コンテナに導入する
- クラウドのサーバー、VM、コンテナに導入する
- SIEMサービスプロバイダー（データの送信先）と契約する
選択肢にかかわらず、設定ミスはSIEMの機能とセキュリティを損なう可能性があります。外部委託の場合、設定に伴う問題をサービスプロバイダーに移せることもありますが、自社のデータセンターでは責任はチームにあります。
SIEMソフトウェアをホストする環境は、Active DirectoryやDomain Name Service（DNS）など、他の重要な企業機能と同様に厳格に保護する必要があります。悪意ある攻撃者がローカルマシンにアクセスできれば、SIEMに流入するデータやSIEMから出力されるアラートの流れに影響を与え、セキュリティプロセスを妨害できる可能性があります。
SIEMプログラムの設定も確認する必要があります。デフォルト設定を確認したのと同じように、意図的に変更した設定も再確認してください。目的に合うよう正しく変更できていますか。本番稼働前に、これらの設定を検証する必要があります。
設定の確認は継続しなければなりません。2年後の点検時にも、導入時の設定はビジネスに適していますか。ビジネスは固定されたものではないため、SIEMの設定も変化に合わせて調整する必要があります。
アクセスレベル
SIEMやその他の高度なソフトウェアを構築すると、さまざまなアクセスレベルが存在します。基本的なユーザーアカウントから最高レベルの管理者権限まで、各アカウントはセキュリティ設定に対する異なる範囲の制御権とアクセス権を提供します。
SIEMのアクセスを検討する際は、最小権限の原則とゼロトラストを適用すべきです。これを実装するには、ソフトウェアで利用可能なアクセスレベルも把握する必要があります。
利用可能な範囲を確認したら、アクセスレベルを比較する表を作成します。各アクセスレベルで変更できる設定や構成は何か、それぞれのユーザー種別に適したアクセスレベルはどれかを確認してください。決定後も、ソフトウェアのアップデートによって基盤となるソフトウェアや権限に関する理解が変わっていないことを確認するため、アクセスレベルを定期的に見直すべきです。
SIEMを正しく導入する
SIEMは非常に便利なツールです。柔軟で強力であり、組織のインフラの状態に関する重要な洞察を提供できます。しかし、導入が不十分だと、セキュリティチームを誤らせ、誤警報への対応に時間を浪費させ、重大なセキュリティ脅威を見逃す可能性があります。このチェックリストを使えば、SIEMの導入と設定を体系的に見直し、後のトラブルを回避するのに役立ちます。