Maltiverse を SIEM／SOAR／EDR／FW に連携すると、環境によっては アラートが増えたように見えることがあります。本記事では、 アナリスト（ユーザー）が今すぐできる対処と、 管理者がポリシーで調整できる恒久対策を整理します。 Maltiverseの検出品質そのものに問題があるわけではなく、運用前提を合わせることで ノイズは大きく低減できます。
目次
なぜノイズが出るのか
脅威インテリジェンスは広く集めるほど有用ですが、そのまま適用すると 組織のリスク許容度・業務特性・既存ルールとの不整合で ノイズが増えることがあります。
代表例：
- スコア閾値の不一致：Suspiciousまで取り込むと 観測段階のIoCが増え、アラートが過多に。
- 有効期限（エイジング）の不足：Last Seenが古いIoCを残すと 現在無害でも検知され続ける。
- 活動タイプの違い：Spam／Abuse／Anonymizationなどは 環境により許容範囲が異なる。
- 地理・ASNの偏り：自社と関わりが薄い地域・ネットブロックの アラートが相対的に多くなる。
- 重複取り込み：複数経路（TAXIIとRESTなど）で同一IoCを投入して二重検知。
ユーザー向け：すぐにできる対処
- 時系列を確認： First/Last Seenが古いものは優先度を下げ、最新の観測に重み付け。
- 活動タイプで優先順位付け： Phishing／Bruteforce／Attackerは高優先、 Spam／Anonymizationは業務要件に応じて監視レベルで扱う。
- 関連情報でピボット： 同一ASN／同一ドメイン／同系マルウェア名の「群れ」を確認。単発より群発を重視。
- 地理情報を参照： 通常トラフィックの少ない国・地域・ASNからのIoCは真陽性の可能性を相対評価。
- 既知の正当トラフィックを整理： CDN／主要SaaSなど誤検知が出やすい宛先をホワイトリスト候補として控える （申請フローを明確化）。
管理者向け：ポリシーと設定の見直し
- 段階導入： 初期はMaliciousのみを連携 → 安定後にSuspiciousを領域限定で解放。
- エイジング（TTL）： Last Seenが一定日数を超えたIoCは自動失効。短命インフラ対策に有効。
- 活動タイプ別ハンドリング： Phishing/Bruteforceはブロック、 Spam/Anonymizationは監視やレート制御など段階的処置。
- 地理・ASNポリシー： ビジネス必須の地域・ASNは許可、関与薄い領域は検知 → ブロック強化。
- 指標タイプの分離： IP／Domain／URL／Hashでフィードを分け、SIEM／SOARのルールも粒度別に最適化。
- 重複・循環防止： 各宛先製品に専用フィードを割り当て、二重取り込みを回避。
- KPIとレビュー： True Positive率、例外化までの時間、失効済みIoC比率をダッシュボード化し、 月次で棚卸し。
運用のヒント（調査・一般業務の両面）
- 高精度検索の習慣化： ポータルやAPIで「asn:」、「domain:」、「hash:」などの絞り込みを活用。
- プレイブック整備： 活動タイプ別の対応（ブロック／隔離／監視／無視）を図解化し、当番者の判断を標準化。
- 段階展開： まずEDRへ連携 → 影響が小さい範囲で検証 → FW/Proxyへ拡大。
- 教育・周知： Malicious／Suspicious／Neutral／Whitelistedの違いと、 例外申請フローを社内Wiki化。
よくある質問
Q. Suspiciousを止めると見逃しが心配です。
A. 初期は誤検知抑制を優先してMaliciousのみで安定化し、
影響の少ない領域から段階的にSuspiciousを有効化するのが実務的です。
Q. TAXIIとREST APIはどちらを使うべき？
A. 既存プロダクトの適合度が高ければTAXII、
柔軟なフィルタや自動化を重視するならRESTが向きます。
要件に応じて併用も可能です。
Q. 国別・ASNポリシーは必須ですか？
A. 必須ではありませんが、業務と無関係な地域・ネットブロックを明確にすると、
ノイズの抑制と対応スピード向上に効果的です。
まとめ
- まずはMaliciousのみで連携し、 スコア閾値・TTL・活動タイプでノイズを抑制。
- 地理・ASNポリシーとホワイトリスト運用で、自社業務に合った精度へ最適化。
- ダッシュボードKPIと月次棚卸しで継続改善。二重取り込みは構成で回避。
当ブログでは今後も様々な製品をさらに便利に使いこなすための情報を発信してまいります。 ぜひブックマークのうえ、最新記事をお見逃しなく！