小規模なセキュリティチームにとって、大量のアラートを限られたリソースで処理することは大きな課題です。突然発生した数百件のアラートのうち、多くは同じ事象の重複や誤検知ですが、その中に重要なアラートが埋もれている可能性もあります。
従来のSOAR(Security Orchestration, Automation and Response)ツールによる自動化は、厳密なワークフローの定義とメンテナンスに多大な労力を要します。システム構成の変更や新しい脅威が発生するたびにワークフローを更新する必要があり、小規模チームでは現実的ではありません。
そこで、生成AIを活用したセキュリティ監視ツール「Warren」を開発しました。Warrenは、厳密なワークフローを定義することなく、自然言語での指示によって複雑な分析タスクを実行できます。類似アラートの自動グループ化、脅威インテリジェンスサービスとの連携、SlackとWeb UIの両立など、小規模チームの実務に必要な機能を備えています。
本記事では、Warrenの開発背景となった小規模チームの具体的な課題から、Warrenがどのようにこれらを解決するか、そして実際の使い方までを詳しく説明します。
小規模チームとしてセキュリティ監視の効率化を目指した背景には、以下のような課題がありました。
反復的だが定型化しきれない作業の多さ
セキュリティ監視では、脅威情報の調査やアラートの分析など、似たような作業を繰り返すことが多いです。しかし、これらの作業はすべてを完全に定型化することが難しいという特徴があります。
例えば「不審なIPアドレスからのアクセス」というアラートの場合、基本的な調査の流れは以下のようになります:
- IPアドレスの所有者情報を確認
- 脅威インテリジェンスサービスでレピュテーションをチェック
- 過去に同じIPアドレスからのアクセスがあったか確認
- アクセス先のシステムの重要度を評価
しかし実際には、検知するシステム(内部/外部、クラウドプロバイダ)によって同じような種類のアラートでもスキーマが異なります。またIPアドレスが含まれるフィールドでも様々な意味を持つIPアドレスが1つのアラートに登場します。例えば、プロキシサーバーのログでは「クライアントIP」「プロキシIP」「接続先IP」といった複数のIPアドレスが存在し、それぞれ分析の観点が異なります。このようなスキーマの対応はSOARのようなシステムには必要です。
さらに、調査の過程で「このIPアドレスは過去にも似たようなアクセスをしていたか?」「同じ時間帯に他のシステムへのアクセスもあったか?」といった新たな疑問が生じることもあります。このような新たな疑問点について再帰的に対応させる方法を検討したくなります。
従来のSOARツールでは、これらすべての可能性を事前にワークフローとして定義する必要があります。複数のスキーマに対応しさまざまな条件分岐が複雑に組み合わさると、ワークフロー自体が非常に複雑になり、メンテナンスが困難になります。SOARのメンテナンスが困難であることは以前からも指摘されてきました。
分析に必要な前提知識の多さ
セキュリティアラートを適切に分析するためには、セキュリティに関する知識だけでなく、組織固有のドメイン知識が必要になります。
例えば「サーバーAからサーバーBへの大量のデータ転送」というアラートが発生した場合、アナリストは以下のような膨大な情報を頭の中で管理し、瞬時に判断する必要があります:
- 各サーバーの役割と通常の通信パターン
- データ転送が発生する場合の頻度と量
- 発生時間帯と業務時間の関係
- 最近のシステム変更の有無
小規模チームでは、セキュリティアナリストは数百から数千のシステムについて、これらの情報を記憶しておく必要があります。「このサーバーは月初に必ずバックアップ転送する」「あのアプリケーションは毎日午前3時にレポートを生成する」「この部署のユーザーは海外出張が多い」といった無数の例外パターンを、すべて人間の記憶に依存しているのが現状です。
ドキュメント化も限界があります。うまくドキュメント化されていたとしても、大量のドキュメントを深夜のインシデント対応中に該当箇所を探し出すのは現実的ではありません。結局、経験豊富なアナリストの記憶と勘に依存せざるを得なくなりがちです。
アラート整理の手間
ある朝、監視システムをチェックすると夜間に1,000件あまりのアラートが発生していたとします:
- ポートスキャン検知:900件(10台のサーバー×80ポート)
- ログイン失敗:150件(同一IPからの複数アカウントへの試行)
- 異常トラフィック:30件(定期バックアップによる誤検知)
- コンテナ上のプロセス異常:1件(真のインシデント、コンテナに侵入された形跡)
実際には、900件のポートスキャンは「10台へのスキャン」という1つの事象、150件のログイン失敗は「1つのIPからのブルートフォース攻撃」です。しかし、最も重要なのはたった1件のコンテナプロセス異常で、これは実際にコンテナが侵害されたことを示す重大なインシデントです。
小規模チームではセキュリティ監視に割ける時間が1日2〜3時間程度の場合、大量のアラートに圧倒されてこの重要な1件を見逃すリスクが非常に高くなります。結果として、アラート疲れ、対応の遅延、そして最悪の場合は真のインシデントの見逃しによる被害の拡大が発生します。
コミュニケーションコストの問題
セキュリティチームが他チームと連携する際の大きな課題は、状況によって使いたいコミュニケーションツールが異なることです。
日常的な確認や簡単な質問であれば、SlackやTeamsなどのチャットツールで素早くやり取りしたいものです。しかし、セキュリティ専用ツールが独立していると、アラート情報を共有するには手動でコピー&ペーストするなどしてシステムを横断する必要があります。これは地味に面倒な作業で、コミュニケーションしづらさが生まれてしまいます。
一方、詳細な調査や複雑な分析が必要な場合は、専門的な機能を持つWeb UIが欠かせません。フィルタリング、過去のインシデントとの比較、視覚的な情報表現など、チャットツールでは実現できない機能が必要です。また、深夜や休日のインシデント対応では、自宅からでもアクセスできることが重要です。
理想的なのは、カジュアルなコミュニケーションにはSlack、本格的な分析にはWeb UIという使い分けを、シームレスに実現することです。しかし、従来はメンテナンスコストの観点から二重のインターフェースを持つことは避けられていました。
ルール調整の難しさ
ノイズを減らし、重要なアラートを見逃さないようにするためには、検知ルールの継続的な調整が必要です。これは決定性のあるルールで実装する必要がありますが、ルールの作成と調整は意外と手間がかかる作業です。
検知ルールの調整がなぜ難しいのか、具体例を見てみましょう。例えば、「短時間での大量ログイン失敗」を検知するルールを考えます。最初は単純に「5分間で10回以上のログイン失敗」というルールを設定したとします。
if (login_failure_count > 10 and time_window
しかし、このルールを運用していくと、様々な問題が発生します:
- 正当なユーザーの誤入力: パスワードを忘れたユーザーが何度も試行する
- 自動化ツールの誤動作: 監視ツールやバックアップツールが間違った認証情報で接続を試みる
- テスト環境での動作: 開発者がテスト環境で意図的に失敗させる
これらの誤検知を減らすために、除外条件を追加していきます:
if (login_failure_count > 10 && time_window 7 ||
user_status != "inactive") {
alert("Possible brute force attack")
}
}
} else if (target_system in staging_environments &&
failure_pattern != "sequential_passwords") {
alert("Suspicious activity in staging")
}
}
}
}
しかし、除外条件を追加すればするほど、ルールは複雑になっていきます。そして、新たな問題が発生します:
- メンテナンスの困難さ: どの条件がなぜ追加されたのか、時間が経つと分からなくなる
- 相互作用の複雑さ: 複数のルールが相互に影響し合い、予期しない動作をする
- 変更の影響範囲: 一つの条件を変更すると、他の検知にも影響が出る可能性がある
実際のセキュリティ監視では、このようなルールが数十、数百と存在します。それぞれのルールが独自の条件と除外リストを持ち、相互に関連し合っています。新しい脅威が発見されたり、システム構成が変更されたりするたびに、これらのルールを見直す必要があります。
さらに、ルールの調整には高度な専門知識が必要です。どのような攻撃パターンが存在するのか、それをどのように検知するのか、誤検知をどのように回避するのか、これらすべてを理解している必要があります。また、組織固有の環境やビジネスロジックも考慮しなければなりません。
ルールをテストすることも重要ですが、これも簡単ではありません。本番環境でテストすることはリスクが高く、かといってテスト環境では本番環境の複雑さを完全に再現することは困難です。結果として、ルールの変更は慎重に行わざるを得ず、改善のスピードが遅くなってしまいます。
このような状況では、ルールの調整自体が大きな負担となり、結果として「動いているルールは触らない」という消極的な姿勢になりがちです。しかし、これでは新しい脅威に対応できず、また誤検知も減らすことができません。この作業も、生成AIの支援を受けることで大幅に効率化できる可能性があると考えました。
これらの課題に対して、Warrenでは生成AIを活用した新しいアプローチを採用しました。生成AIの登場により、これまで不可能だった柔軟な自動化が可能になってきています。特に、自然言語処理能力の向上により、曖昧な指示からでも適切な処理を実行できるようになりました。
Warrenの開発において重要だったのは、生成AIを単なる「チャットボット」として使うのではなく、実際のセキュリティ運用に組み込める実用的なツールとして設計することでした。以下、主要な解決策について説明します。
アラート分析におけるLLMの活用
Warrenの最も特徴的な機能は、LLM(Large Language Model)を活用したアラート分析です。従来のSOARツールのような厳密なワークフローを排除し、より柔軟な分析を可能にしました。
厳密なワークフローの排除
従来のワークフローベースのアプローチでは、アラートから必要な情報(IPアドレス、ドメイン名、ファイルハッシュなど)を抽出するために、アラートの種類ごとに細かくマッピングを定義する必要がありました。また、処理の流れも事前に定義しておく必要があり、これがメンテナンスコストの増大につながっていました。
Warrenでは、LLMがアラートの内容を理解し、自動的に分析対象となる指標(indicator)を抽出します。これにより、アラートごとに細かくワークフローを組む必要がなくなり、メンテナンスコストが大幅に削減されました。
AIエージェント化
Slack上でAIエージェントに問い合わせ可能
WarrenのAIエージェントは、ユーザーの簡単な指示から、どのような作業が必要かを自律的に判断します。例えば「このチケットのすべてのIPアドレスを分析して」という指示を与えると、エージェントは以下のような作業を自動的に実行します:
- チケットに含まれるアラートからIPアドレスを抽出
- 各IPアドレスに対して脅威インテリジェンスサービス(VirusTotal、OTX、AbuseIPDBなど)をチェック
- 結果をまとめて報告
さらに、複雑なタスクに対しては「Plan & Execution」モードが発動します。これは、Claude Codeなどの開発支援AIツールに搭載されている機能と同様のもので、タスクを複数のステップに分解し、進捗を表示しながら実行していきます。
利用可能なツールには、Warren内部ツール(アラート取得、類似チケット検索、調査結果更新など)と、外部脅威インテリジェンスサービス(VirusTotal、OTX、AbuseIPDB、Shodan、URLScanなど)があります。
MCPによる拡張性
ツール利用の文脈では、拡張性の観点から MCP(Model Context Protocol)へも対応しています。MCPは、AI エージェントと外部ツールを接続するための標準化されたプロトコルです。これにより、組織固有のツールやデータソースをWarrenに統合することが可能になります。
例えば、組織固有の資産管理データベースがある場合、MCPサーバーを実装することで、AIエージェントから直接アクセスできるようになります。この設定により、AIエージェントは「このIPアドレスが割り当てられている端末の情報を教えて」といった自然言語の指示に対して、組織の資産管理データベースを参照して回答できるようになります。
servers:
- name: "asset-db"
type: "http"
url: "https://internal-api.example.com/mcp"
headers:
Authorization: "Bearer YOUR_API_KEY"
MCPの特徴は実装が非常に容易である点です。プロトコル自体がシンプルなのと各言語に対してSDKが用意されており、基本的には必要なデータへのアクセスのロジックを記述するだけでMCPサーバーを実装できます。また近年の生成AI開発エージェントの活用も、MCP開発に大いに利用できます。これによって独自の情報源へのアクセスが可能となり、アラート分析の幅を広げられます。
BigQueryとの連携
Warrenは、BigQueryとの連携もサポートしています。これにより、大規模なログデータの分析が可能になります。AIエージェントは、自然言語での質問を適切なSQLクエリに変換し、結果を分かりやすく整理して提示します。
例えば、「先週、このIPアドレスからアクセスがあったユーザーを調べて」という指示に対して、AIエージェントは以下のような処理を行います:
- 適切なBigQueryテーブルを特定
- SQLクエリを生成して実行
- 結果を整理して、重要な情報をハイライト
- 必要に応じて追加の分析を提案
しかし、単純にBigQueryのテーブル情報を渡すだけでは、生成AIは何をすべきか判断できないというのが現実です。特にセキュリティ系で利用する監査ログなどは、フィールド数が膨大で、それぞれのフィールドの意味や関連性を理解するのは困難です。
そこでWarrenは、BigQueryテーブルの事前分析機能を提供しています。この機能は、スキーマ情報だけでなく、実際のデータも分析し、各フィールドの値の例や説明を自動生成します。例えば、Google Cloudの監査ログに対しては以下のような情報が生成されます:
dataset_id: google_cloud_audit
table_id: cloudaudit_googleapis_com_system_event
description: Google Cloudのsystem event audit log
columns:
- name: logName
description: The name of the log.
value_example: projects/gcp-project-id/logs/cloudaudit.googleapis.com%2Fsystem_event
type: STRING
fields: []
- name: operation
description: The operation associated with the log entry.
value_example: ""
type: RECORD
fields:
- name: producer
description: The producer of the operation.
value_example: google.cloud.example.ExampleService
type: STRING
fields: []
- name: first
description: Indicates if this is the first log entry for the operation.
value_example: "true"
type: BOOLEAN
fields: []
- name: last
description: Indicates if this is the last log entry for the operation.
value_example: "false"
type: BOOLEAN
fields: []
- name: timestamp
description: The time the event occurred.
value_example: "2023-10-27T10:00:00Z"
type: TIMESTAMP
fields: []
さらに、事前に参考となるクエリをRunbookとして登録しておくことも可能です。「不審なログイン試行を検出する」「特定のリソースへのアクセス履歴を調査する」といった用途の説明を付加しておくことで、Warrenはこれらのクエリを参考にして、より適切なSQLを組み立てることができます。
このような準備を行うことで、BigQueryの膨大なデータも、セキュリティ分析の文脈で効果的に活用できるようになるというのが、Warrenの特徴です。
シグナルとしてのアラートと対応チケットの分離
Warrenでは、「アラート」と「チケット」という2つの概念を明確に分離しています。
- アラート: セキュリティデバイスや監視システムから送られてくる個々のセキュリティイベント
- チケット: 1つ以上の関連するアラートをまとめた、調査と対応の単位
複数のアラートが同じ事象を指し示していたり、同じ誤検知の問題によるものだった場合、それらをまとめて1つのチケットとして扱うことができます。これにより、アナリストは個々のアラートではなく、意味のある単位で対応を進めることができます。
Embeddingによるアラートクラスタリング
アラートの関連性を判断するために、WarrenはEmbedding技術を活用しています。Embeddingとは、データの意味的特徴を高次元ベクトル空間にマッピングする手法です。
各アラートは256次元のベクトルに変換され、コサイン距離を使って類似度を計算し、希望のアラートの発見に利用されます。また、DBSCAN(Density-Based Spatial Clustering of Applications with Noise)アルゴリズムを使用して、類似したアラートを自動的にクラスタリングします。
これにより、以下のような機能が実現できました:
- 類似するアラートを自動的にグループ化
- クラスタからチケットを一括作成
- 既存のチケットに類似したアラートを自動的に関連付け
例えば、同じ攻撃キャンペーンによる複数のアラートや、同じ誤検知パターンによる大量のアラートを、簡単にまとめて処理できるようになりました。また、単純に近傍のアラートをまとめるだけだと意図しない情報が紛れ込む場合があるので、キーワードでの絞り込みもできるようにしています。
SlackとWeb UIの連携
従来の原則では、ユーザーインターフェースを二重に持つことはメンテナンスコストの観点からアンチパターンとされていました。しかし、生成AIによる開発生産性の向上により、この制約を克服することができました。
Slackインターフェース
先程も少しお見せしましたが、日常的なコミュニケーションツールであるSlackを、アラート通知と簡単な操作のインターフェースとして活用しています。
アラートが発生すると、以下のような形式でSlackに通知されます:
Slackから直接、以下の操作が可能です:
- アラートの確認(Acknowledge)によるチケット作成
- 既存チケットへのアラートの紐付け
- チケットの解決(Resolve)
- 類似アラートの検索(Salvage)
このスレッド上でチーム内外のメンバーとコミュニケーションをすることで、アラートの情報をスムーズに伝えつつ議論をすることができます。チーム外のメンバーには必要以上の情報を見せることなく、専用システムにログインせずに利用することができます。
Web UI
より詳細な分析や管理作業のために、フル機能のWeb UIも提供しています。Web UIでは以下のような機能が利用できます:
- ダッシュボードでの全体状況の把握
- 詳細なフィルタリングとソート
- 複数アラートの一括操作
- AIエージェントとのチャット機能
- 調査結果の記録と共有
SlackとWeb UIは完全に同期しており、どちらで行った操作も即座に反映されます。これにより、チーム外のメンバーとはSlackで簡単にコミュニケーションを取りながら、詳細な分析作業はWeb UIで行うという、それぞれの強みを活かした運用が可能になりました。
テキストベースでのルールとテストの実装
検知ルールの作成と調整においても、生成AIの恩恵を受けられるようにしました。もともとテキストベースのルールを利活用するのはDetection Engineering, Detection as Code, Autonomic Security Operationsなどの着想によるもので、ソフトウェア開発のベストプラクティスをセキュリティ監視に持ち込むことによる効率化の一環となります。
Regoによるポリシー記述
WarrenはOPA(Open Policy Agent)のポリシー言語であるRegoを使用してルールを記述します。テキストベースのルールであるため、Claude Codeのような開発用AIエージェントツールをそのまま活用できます。
例えば、以下のようなRegoポリシーで、特定の条件に基づいてアラートを生成できます:
package warren.alert
alert contains res if {
input.event_type == "login_failure"
input.failure_count > 10
input.time_window_minutes 5
not ignore
res := {
"title": sprintf("Multiple login failures from %s", [input.source_ip]),
"description": sprintf("%d failed login attempts in %d minutes",
[input.failure_count, input.time_window_minutes]),
"severity": "high",
"attributes": [
{"key": "source_ip", "value": input.source_ip},
{"key": "failure_count", "value": sprintf("%d", [input.failure_count])},
]
}
}
ignore if {
input.source_ip in internal_network
input.username in service_accounts
}
ignore if {
input.target_system in test_environments
regex.match("test_.*", input.username)
}
ignore if {
input.time_of_day >= "02:00"
input.time_of_day "05:00"
input.source_country in ["JP", "US", "GB"]
input.username in ["backup_user", "batch_processor"]
}
internal_network := ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
service_accounts := ["monitoring_service", "backup_service", "health_check"]
test_environments := ["test-env", "staging-env", "dev-env"]
AIを活用したルール調整
CLAUDE.mdのような事前指示のテキストに組織のコンテキストやルールの構成を記述しておくことで、AIが意図を汲み取ってルールを提案してくれます。
例えば、誤検知したアラートのデータを特定のディレクトリに配置し、「これを無視するようにルールを調整して」という指示を出すと、AIは既存ルールとの整合性を考慮した上で最適なルールを提案してくれます。このようなルール調整は、既存ルールの把握やどう構造化するかなど考えることが多く、地味に負担が大きい作業でしたが、AIの支援により大幅に効率化されました。
テスト機能の実装
さらに重要なのが、テスト機能の実装です。ルールを変更した際に、検知したいデータが適切に検知され、無視したいデータが適切に無視されているかを、都度チェックできるようになっています。
warren policy test --policy-dir ./policies --test-dir ./test-data
これにより、ルール変更による影響を事前に確認でき、より安心してルールの調整を行えるようになりました。
Warrenは、小規模なセキュリティチームが直面する課題を、生成AIを活用することで解決することを目的としたツールです。従来のアプローチでは実現が困難だった柔軟な自動化と、使いやすいインターフェースの両立を実現できたのではと考えています。
セキュリティ監視は、規模に関わらずすべての組織にとって重要なセキュリティ対策アプローチの一つです。しかし、その重要性に見合ったリソースを投入できる組織は限られています。特に製品やインフラにかかるコストが問題として挙がりやすいですが、実際には適切に運用していく継続的な対応が難しいと考えていました。Warrenが、リソースの制約がある中でも効果的なセキュリティ監視を実現する一つの参考となれば幸いです。
Views: 0