AIと機械学習を活用したセキュリティユースケース
SplunkのAIと機械学習機能の効果的な活用方法を、お客様の成功事例とともにご紹介します。
Splunkダッシュボード作成の基礎！〜ログイン状況を可視化してみよう〜
Splunkには、単一値表示や折れ線グラフの他、地理情報へのマッピングなど、様々な視覚化機能があります。
これら視覚化機能について理解を深めるためには、実際にパネルやダッシュボードを作成してみるのが近道です。しかし、どのような可視化を行えばいいのか、何のダッシュボードを作成すればよいか、など悩んでしまう方も多いのではないでしょうか？
今回は、Splunkの内部ログをソースとして、Splunkのログイン情報を可視化するためのダッシュボード作成の例と手順をご紹介します。
ちなみに、Splunkのセキュリティ全般を向上させるための考え方のポイントは、Splunk Docにまとまっております。こちらもぜひ一度、ご参照ください。
Splunkの内部ログについて
Splunkでは、ログインに関する情報を内部ログとして保管しています。これらログを活用し、ログイン情報について集計とレポーティングを行うことができます。
具体的には、監査ログである「_audit」インデックスにログイン/ログアウトに関するログが保管されています。Actionフィールドが”login attempt”であるログがログイン試行ログですので、まず以下のサーチを実行してみます。
index="_audit" action="login attempt*"
ログイン試行に関するログが表示されました。ちなみに、上記のサーチでlogin attemptの後に*が使用されている理由は、login attempt以外にlogin attempt locked out userなどの複数のactionが存在しており、このログも対象に含めるためです。
Splunkの監査ログについては、こちらのドキュメントも参考にしてください。
ダッシュボードデザインの考え方の一例
次に、ダッシュボードデザインの考え方の一例をご紹介します。
ダッシュボードをデザインする際は、実際の運用業務を想定し、どのような状態であることを確認したいのか、または逆にどのような兆候を発見したいのか、などを踏まえて必要な情報やパネルの種類を決定する必要があります。
ダッシュボードデザインの考え方の一例としては、まず目的を定め、その目的に沿って3つの階層を意識した画面設計にするというものがあります。以下のように階層を分けてそれぞれのパネルを配置するという考え方です。
- 1階層：最初に見る階層。目的に対する、最も重要なメトリックスやKPIを決定して表示する。このメトリックスやKPIが異常な値を示していた場合、すぐに調査が必要だと判断できるものを表示する。単一数値であると分かりやすい。
- 2階層：メトリックスやKPIに関するインサイトや詳細情報を表示する。メトリックスや関連する値を時系列表示、グループ化、リストすることで、単一数値だけでは判断しづらい情報を表示する。
- 3階層：問題があると判断した場合、更なる調査や分析を行うために必要な情報やサーチを行うためのパネルを表示させる。
参考記事「ダッシュボード設計：ベストプラクティスをもとに作成を始める(パート1)」
今回は、Splunkログイン情報を可視化するためのダッシュボードを作成します。上記のダッシュボードデザインの考え方に沿って、例えば以下のようにダッシュボードをデザインすることを考えました。
目的：Splunkに対して不正なログインが試行されていないかを調べたい。また不審なログインがあった場合、すぐにそれに気づいて調査を行いたい。
- 1階層：最も重要なメトリックスとして、(a)ログイン試行回数および(b)ログイン成功率をパネルで表示する。これら指標が急変した場合、理由を調査するべきと考えられる。
- 2階層：最も重要なメトリックスに対する詳細情報として、(c)ログイン試行回数およびそれら成否の割合の時系列表示、(d)ログイン失敗率の高いユーザーのリスト、(e)最近ユーザーがロックアウトされたイベントのリスト、(f)滅多にログインしないユーザーがログインに成功したイベントのリスト、(g)ログインを試行したユーザーの物理的アクセス元、を表示する。これらによって、追加のインサイトを得ることができ、場合によっては追加の調査や分析を行う。
- 3階層：調査や分析のため、(h)特定のユーザーを指定して、関連するイベントをサーチして表示するパネルを用意する。このパネルによって、更に詳細な調査を行うべきかどうかを判断する。
企業によっては、守らなければならないセキュリティポリシーがあらかじめ定められている場合もあると思います。その場合、それらポリシーを出発点としてダッシュボードをデザインすることになるでしょう。
また、よく私自身がダッシュボードデザイン時に経験することとして、デザインの細部にこだわりすぎて実際に使い始めるまでに時間がかかってしまうという問題が発生することがあります。これは、日本の文化や気質によるところもあり良し悪しでもあると考えているのですが、可能であれば、早い段階で実業務にダッシュボードを利用してみて、業務を行いながらダッシュボードを修正していくという流れで進めていったほうが、精神的に疲弊などせず、素早く効率的に役に立つダッシュボードが作成できると個人的には考えています。
(ただし、大規模なプロジェクトなどで、ダッシュボード開発と実運用業務を担当する部署や人が明確に分けられている場合もあると思います。その場合は画面レビューなど、十分な部署間のコミュニケーションを行いながらデザインを行う必要があると思っています)
ログイン状況を可視化するためのパネル/サーチの実装
最後に、Splunkログイン情報を可視化するためのパネル/サーチを実装します。
(a)ログイン試行回数
(b)ログイン成功率
(c)ログイン試行回数およびそれら成否の割合の時系列表示
(d)ログイン失敗率の高いユーザーのリスト
(e)最近ユーザーがロックアウトされたイベントのリスト
(f)滅多にログインしないユーザーがログインに成功したイベントのリスト
(g)ログインを試行したユーザーの物理的アクセス元
(h)ユーザーやIPアドレスを指定して、関連するイベントをサーチして表示するパネル
それぞれのSPL、サーチの時間範囲の指定、可視化の種類は以下の通り実装しました。
| パネル名 | SPL | 時間範囲 | 可視化の種類 |
|---|---|---|---|
| (a)ログイン試行回数 | index="_audit" action="login attempt*" NOT user=internal* | stats count | ダッシュボード中で指定する時間範囲1にて指定(デフォルト24時間) | 単一値 |
| (b)ログイン成功率 | index="_audit" action="login attempt*" NOT user=internal* | eval result=if(info="succeeded", "succeeded", "failed") | stats count(eval(result="failed")) as failures, count(eval(result="succeeded")) as successes | eval login_success_rate = round((successes / (successes + failures)) * 100, 2) | table login_success_rate | ダッシュボード中で指定する時間範囲1にて指定(デフォルト24時間) | 単一値 |
| (c)ログイン試行イベントの時系列表示 | index="_audit" action="login attempt*" NOT user=internal* | eval date=strftime(_time, "%Y-%m-%d") | eval result=if(info="succeeded", "succeeded", "failed") | timechart count by result | ダッシュボード中で指定する時間範囲2にて指定(デフォルト7日間) | 面グラフ(スタックモード) |
| (d)ログイン失敗率の高いユーザーのリスト | index="_audit" action="login attempt*" | eval result=if(info="succeeded", "succeeded", "failed") | stats count(eval(result="failed")) as failures, count(eval(result="succeeded")) as successes by user | eval total_attempts = successes + failures| eval failure_rate = round(failures * 100 / total_attempts, 2) | sort - failure_rate| table user, total_attempts, failure_rate | ダッシュボード中で指定する時間範囲2にて指定(デフォルト7日間) | イベント表示 |
| (e)ロックアウトされたユーザーによるログイン | index="_audit" action="login attempt locked out user" | table _time, user src | ダッシュボード中で指定する時間範囲2にて指定(デフォルト7日間) | イベント表示 |
| (f)一ヶ月以上、ログインしていないユーザーのログイン | index=_audit action="login attempt" info="succeeded" NOT user=internal* | stats max(_time) as last_login_time by user | where last_login_time <= relative_time(now(), "-30d") | join user [ search index=_audit action="login attempt" info="succeeded" NOT user=internal* ] | table _time, user, last_login_time | ダッシュボード中で指定する時間範囲2にて指定(デフォルト7日間) | イベント表示 |
| (g)ログインを試行したユーザーの物理的アクセス元 | index="_audit" action="login attempt*" NOT user=internal* | iplocation clientip | geostats count by user | ダッシュボード中で指定する時間範囲2にて指定(デフォルト7日間) | クラスターマップ |
| (h)ユーザーやIPアドレスを指定して、関連するイベントをサーチして表示するパネル | index=_audit user=$field3$ ※$field3$は、ダッシュボード上部のタブから入力を指定してそれを受け取るトークンを指定しています | ダッシュボード中で指定する時間範囲2にて指定(デフォルト7日間) | イベント表示 |
上記サーチをパネル化し、ダッシュボード上に追加して、適切な時間範囲やユーザーを指定するタブを作成すると、以下のようなダッシュボードが作成できます。
上記のダッシュボード設定ファイル(xml)は、こちらのGitHubからも取得可能です。気になる方はダウンロードいただき、自分のSplunk環境にインポートして表示を確かめてみたり、カスタマイズしてみてください。
(ダッシュボードはClassic環境で作成しています。Classic環境で新規ダッシュボードを作成した後、「編集」-「ソース」を選択することでxmlソース編集を行うことができますので、そのソースをダウンロードしたxmlファイルで上書きすれば利用可能になります)
また、Splunkログインに関するセキュリティ向上の観点では、上記のダッシュボードに加えて、ログイン試行回数や成功率が閾値を超えた際にアラートなどを設定することも有効な方法です。今回はアラートに関する設定例は省略しますが、ログの中身を理解すればサーチやアラートを作成することはそこまで難しくありませんので、ぜひご自身でも手を動かしてSplunkの機能を学び、実務に役立てていただければと思います。
参考情報として、いくつかのダッシュボードのサンプルが記載されている公式ドキュメントや、ダッシュボードのサンプル集であるSplunk Appのリンクもご紹介しますので、ダッシュボード作成の際は参考にしてください。
(ちなみに、現在Splunkのダッシュボードには従来のXMLで定義されるClassic dashboardと、新型のJSONで定義されるDashboard Studioの種類があります。今回は従来のClassic dashboardでダッシュボードを作成しておりますのでご注意ください)
関連記事
Splunkについて
Splunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。
Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は1,020を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキストに基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。
ブログのメール配信
Splunkの最新ブログ記事をメールでお知らせします。
XでSplunkとつながる
@splunkをフォロー
