背景と重要性:インシデント対応における運用の混乱
セキュリティインシデントの発生時、1秒の遅れが攻撃者を利することになります。多くの中小規模のセキュリティチームは、大量のアラートノイズに忙殺されています。単一のファイアウォールの急増検知やエンドポイントアラートをきっかけに、SlackやTeams、共有メールボックスへ調整の取れていない通知が大量に押し寄せます。アナリストは対応に追われ、IPアドレスやドメイン、SHA-256ハッシュを手作業でVirusTotalやAbuseIPDB、ANY.RUNに1つずつコピー&ペーストして調査を進めることになります。
1シフトあたり40件ものアラートに対してこの作業を繰り返すことは、アナリストの急速な疲弊(バーンアウト)を招きます。また、対応中のインシデントをスプレッドシートやJiraで管理していると、死角が生じ、フォレンジックのコンテキストが抜け落ち、証拠保全(チェイン・オブ・カストディ)が損なわれます。結果として、脅威の封じ込め(コンテインメント)に数分ではなく数時間を要することになります。
筆者自身の踏み台サーバー(ジャンプホスト)が午前2時にSSHブルートフォース攻撃を受けた際にも、この教訓を痛感しました。誰かが対応する前に、14,000件以上ものログイン失敗ログが記録されていました。プレッシャー下での手動トリアージには限界があります。この課題を解決するのが、専用のセキュリティインシデント対応プラットフォーム(SIRP)です。ケース管理を担うTheHiveと、オブザーバブル(調査対象データ)の自動分析を行うCortexを連携させることで、機密性の高いテレメトリデータを自社ハードウェア内に保持したまま、ワンクリックで複数エンジンによる脅威判定を実行できるようになります。
インストール:Docker ComposeによるTheHiveとCortexのデプロイ
Ubuntu 22.04またはDebian 12において、Docker Composeは最もクリーンなデプロイ手法です。Cassandra、OpenSearch、Pythonランタイム間の依存関係の競合を防ぐことができます。ホストの最小要件は、4 vCPU、16 GB RAM、50 GBのSSDストレージです。
ステップ1:システムの準備と前提条件
ベースパッケージをアップデートし、カーネルの仮想メモリ上限を引き上げます。Linuxのデフォルト値のままでは、vm.max_map_countが不足してOpenSearchの起動に失敗します:
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git apt-transport-https ca-certificates gnupg lsb-release
# OpenSearchには最低262,144のメモリマップエリアが必要です
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
# Docker EngineとComposeプラグインをインストール
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
ステップ2:プロジェクトディレクトリとCompose仕様の準備
永続ボリュームとCortexのジョブ実行専用のディレクトリを作成します:
mkdir -p ~/thehive-cortex/{cortex-data,thehive-data,opensearch-data,cortex-jobs}
cd ~/thehive-cortex
# 検索バックエンドコンテナのUID(1000)に対する書き込み権限を確保
sudo chown -R 1000:1000 opensearch-data
docker-compose.ymlを作成します:
version: '3.8'
networks:
soc-net:
driver: bridge
services:
opensearch:
image: opensearchproject/opensearch:2.11.0
container_name: opensearch
environment:
- discovery.type=single-node
- plugins.security.disabled=true
- "OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g"
volumes:
- ./opensearch-data:/usr/share/opensearch/data
networks:
- soc-net
restart: unless-stopped
cortex:
image: thehiveproject/cortex:3.1.8
container_name: cortex
depends_on:
- opensearch
environment:
- http.port=9001
- job.directory=/tmp/cortex-jobs
volumes:
- ./cortex-jobs:/tmp/cortex-jobs
- /var/run/docker.sock:/var/run/docker.sock
networks:
- soc-net
ports:
- "127.0.0.1:9001:9001"
restart: unless-stopped
thehive:
image: thehiveproject/thehive:5.2.5
container_name: thehive
depends_on:
- opensearch
- cortex
environment:
- http.port=9000
networks:
- soc-net
ports:
- "127.0.0.1:9000:9000"
restart: unless-stopped
デタッチモードでスタックを起動します:
docker compose up -d
docker compose ps
設定:TheHiveとCortexの接続およびアナライザーの有効化
セキュリティのため、両アプリケーションはローカルループバック(127.0.0.1)にバインドされています。生のポートをインターネットに公開することなくWebコンソールへアクセスするには、作業用PC(ワークステーション)からSSHトンネルを開きます:
ssh -N -L 9000:127.0.0.1:9000 -L 9001:127.0.0.1:9001 user@<server-ip>
ステップ1:Cortexの初期化とアナライザーの有効化
ローカルブラウザで http://localhost:9001 を開きます。
- Update Database をクリックして、ES/OpenSearchのインデックスを初期化します。
- 16文字以上のパスフレーズでSuperAdminアカウントを設定します。
- Organizations に移動し、
SOC_Coreという名称の組織を作成します。 - アナライザーのAPIキーを管理するため、
orgadminロールを持つユーザーをSOC_Coreに追加します。 thehive-connectorという名前の自動化アカウントを追加します。read, analyzeロールを付与し、Create API Key をクリックしてトークンを安全に保存します。
orgadmin ユーザーとしてサインインし、Organization > Analyzers に移動して AbuseIPDB を検索します。Enable をクリックし、無料または商用のAPIキーを入力して、check_days を 30 に設定します。
ステップ2:Cortexと連携するためのTheHiveの設定
http://localhost:9000 にアクセスします。プロンプトが表示されたらデータベーススキーマを初期化します。デフォルトの認証情報([email protected] / secret)でログインし、この一時パスワードを直ちに変更してください。
続いて、TheHiveの管理画面からCortexを連携します:
- Platform Management > Organizations に移動し、プライマリSOCチームを設定します。
- Cortex Connectors に進み、Add Cortex Server を選択します。
- エンドポイントURLを
http://cortex:9001に設定します。コンテナはDockerの内部ブリッジネットワークを共有しているため、設定なしで名前解決が機能します。 thehive-connector用に生成したAPIキーを貼り付けます。- Test & Save をクリックします。ヘルスチェックアイコンが緑色に変わります。
検証とモニタリング:エンドツーエンドのインシデントワークフローの実行
実際のトリアージシナリオを使用して、パイプライン全体をテストします。
ステップ1:ケースの作成とオブザーバブルの登録
- TheHiveで、Cases > New Case に移動します。
- ケースの詳細を入力します。Title:
Suspicious Inbound SSH Brute-Force、Severity:Medium、TLP:Amber。 - 作成したケースを開き、Observables タブをクリックします。
- Add Observable をクリックし、Typeを
ipに設定して、198.51.100.24などのテスト用外部アドレスを入力します。
ステップ2:Cortexアナライザーのトリガー
新規追加したIPオブザーバブルの横にあるチェックボックスをオンにし、Actions > Run Analyzers をクリックして AbuseIPDB_1_0 を選択します。
CortexはDockerソケット経由で短命なコンテナを立ち上げ、AbuseIPDBにクエリを送信し、JSONペイロードをパースして、4秒以内にタクソノミーレポートをオブザーバブルドロワーへ直接追加します:
{
"status": "Success",
"observable": "198.51.100.24",
"taxonomy": [
{
"level": "malicious",
"namespace": "AbuseIPDB",
"predicate": "ConfidenceScore",
"value": "100%"
}
]
}
ステップ3:サービスの健全性およびモニタリングの確認
リソース使用状況とキューのログを定期的にモニタリングし、コンテナの安定性を維持します:
# リアルタイムのCPUおよびメモリ使用量を確認
docker stats --no-stream
# コネクタとインデックス作成のログをストリーミング表示
docker logs -f thehive --tail 50
docker logs -f cortex --tail 50
# OpenSearchクラスタの健全性ステータスを確認
curl -s -X GET "http://localhost:9200/_cluster/health?pretty"
これで、独立した自己完結型のインシデント対応スタックが稼働しました。Wazuh、Suricata、またはPythonのWebhookからアラートを取り込みましょう。バックグラウンドでのインテリジェンス収集はCortexに任せることで、アナリストは被害が拡大する前に脅威を隔離するために必要な正確なコンテキストを即座に把握できます。

