本記事では、脅威インテリジェンスの根幹をなすIOC（侵害指標）の収集・分析・活用を軸に、MITRE ATT&CK・STIX/TAXII・実践的なPythonコードまで体系的に解説します。
🛡️ 脅威インテリジェンス（Threat Intelligence）実践ガイド
IOCの収集・分析・活用から、MITRE ATT&CK・STIX・TAXIIまで完全解説
対象レベル：中級〜上級 ｜ シリーズ：やさしいサイバーセキュリティ ｜ OSINTシリーズ続編
サイバー攻撃を「起きてから対応する」のではなく、「起きる前に予測して防ぐ」。そのために必要なのが脅威インテリジェンス（Threat Intelligence）です。世界中のセキュリティチームが毎日収集・分析・共有している脅威情報は、適切に活用すれば自組織のセキュリティレベルを劇的に引き上げる武器になります。本記事では、脅威インテリジェンスの根幹をなすIOC（侵害指標）の収集・分析・活用を軸に、MITRE ATT&CK・STIX/TAXII・実践的なPythonコードまで体系的に解説します。
📋 目次
- 脅威インテリジェンスとは何か――定義と4つの種類
- IOC（侵害指標）の種類と特徴を完全理解する
- インテリジェンスサイクル――収集から活用までの流れ
- 無料で使えるTIフィード・プラットフォーム総覧
- STIX／TAXIIとは――脅威情報の標準フォーマット
- MITRE ATT&CK フレームワークの実践活用
- VirusTotalを使った高度なIOC分析
- PythonによるIOC収集・分析の自動化
- SIEMへのTIフィード統合――実装ガイド
- 脅威アクターのプロファイリング技法
- インシデントレスポンスへのTI活用
- TIプログラムの構築と成熟度モデル
- コミュニティ共有とISAC――情報共有の実際
- 法的・倫理的考慮点と2025年以降のトレンド
1脅威インテリジェンスとは何か――定義と4つの種類
脅威インテリジェンス（Threat Intelligence、略称：TI）とは、サイバー脅威に関する収集・処理・分析された情報のことです。単なるデータの羅列（IPアドレスのリストなど）ではなく、「誰が・何を目的に・どのような方法で・どこを狙っているか」という文脈（コンテキスト）を持った知識です。
Gartnerは脅威インテリジェンスを「証拠に基づく知識であり、脅威アクターの動機・意図・能力に関するコンテキスト・メカニズム・指標・影響・実行可能な助言を含み、既知または新興の脅威や危険に対する意思決定を可能にするもの」と定義しています（2014年）。この定義は現在も業界標準として参照されています。
脅威インテリジェンスの4つの種類
| 種類 | 対象読者 | 内容 | 更新頻度 |
|---|---|---|---|
| 戦略的 (Strategic) | 経営層・CISO | 脅威のトレンド・攻撃者の動機・地政学的リスク。長期的なリスク意思決定に使用 | 月次〜四半期 |
| 作戦的 (Operational) | セキュリティマネージャー・SOCリード | 具体的なキャンペーンの手口・攻撃対象・タイムライン。対策計画の立案に使用 | 週次〜月次 |
| 戦術的 (Tactical) | SOCアナリスト・インシデントレスポンダー | TTP（戦術・技術・手順）。MITRE ATT&CKのテクニック詳細。検知ルール作成に使用 | 日次〜週次 |
| 技術的 (Technical) | SOCアナリスト・自動化システム | IOC（IPアドレス・ドメイン・ハッシュ値等）。自動ブロック・SIEM連携に使用 | リアルタイム〜時間単位 |
多くの組織が「技術的インテリジェンス（IOCのリスト）」の収集・活用には取り組んでいますが、「戦略的・作戦的インテリジェンス」を経営判断やセキュリティ投資計画に活用している組織はまだ少ないのが現状です。成熟したTIプログラムはすべての層をカバーします。
TIが「データ」「情報」と異なる点
TIの価値を正確に理解するために、3層のピラミッドを意識することが重要です。
例えば「185.123.45.67」というIPアドレスはただのデータです。「このIPはロシアのISPが管理し、ポート443で通信している」が情報です。「このIPはAPT29が使用するC2サーバーであり、日本の金融機関を標的とした2024年Q3のキャンペーンで使用されており、類似インフラがさらに3件確認されている」になって初めてインテリジェンスです。
2IOC（侵害指標）の種類と特徴を完全理解する
IOC（Indicator of Compromise：侵害指標）は、システムへの侵入・マルウェア感染・不正活動の痕跡を示すデータ片です。TIの中核をなす要素であり、防御システムへの統合・調査での活用・情報共有の基本単位となります。
主要なIOCの種類
C2サーバー・スキャン元・エクスプロイトの送信元として使用される悪意のあるIPアドレス
フィッシング・マルウェアのC2・DGAドメインなど。IPよりも変更コストが高く長期使用される傾向
フィッシングページ・マルウェア配布URL・エクスプロイトキット。ドメインより粒度が細かい
マルウェアの固有識別子。MD5・SHA-1・SHA-256・SSDeep（類似度ハッシュ）がある
スピアフィッシングの送信元。なりすましアドレス・侵害された正規アカウント等
C2サーバーが使用する証明書の指紋（フィンガープリント）。IPが変わっても追跡可能
マルウェアが自動起動やデータ保存に使用するWindowsレジストリのパス
マルウェアが設置するファイルの場所・名前。正規ファイルを模倣することが多い
マルウェアが二重起動防止に使用するミューテックス。同一ファミリーの識別に有効
マルウェア通信の特徴的パターン。User-Agent文字列・HTTPヘッダー・通信プロトコル等
Pyramid of Pain――IOCの「痛み度」ランキング
セキュリティ研究者のDavid Bianco（2013年）が提唱した「Pyramid of Pain」は、各IOCタイプを「攻撃者にとっての変更コスト（痛み）」で順位付けしたモデルです。
Pyramid of Pain（下から上へ痛みが増大）：
① ハッシュ値（最も簡単に変更可能――1バイト変えるだけでハッシュが変わる）
② IPアドレス（変更が容易――クラウドサービスで即時に新IPを取得可能）
③ ドメイン名（やや変更コストがかかる――しかし安価で大量取得可能）
④ ネットワーク・ホストアーティファクト（変更に手間がかかる）
⑤ ツール（開発・習熟に時間とスキルが必要）
⑥ TTP（最も高コスト――攻撃者の行動様式そのものを変える必要がある）
上位のTTP（戦術・技術・手順）をベースにした検知ルールは、攻撃者に最大のコストを強いる最も効果的な防御策です。これがMITRE ATT&CKフレームワークが重視される理由です。
IOCの有効期限問題
IOCには「鮮度（Freshness）」の概念があります。特に技術的IOCであるIPアドレスは、攻撃者がクラウドサービスを使って頻繁に変更するため、有効期間が非常に短いです。
| IOCタイプ | 平均有効期間の目安 | 備考 |
|---|---|---|
| IPアドレス（C2） | 数時間〜数日 | クラウドIP・Torノードは特に短命 |
| ドメイン名 | 数日〜数週間 | DGAドメインはさらに短命（数時間） |
| URL | 数時間〜数日 | フィッシングURLは特に短命 |
| ファイルハッシュ（MD5/SHA） | 特定のキャンペーン期間中 | 多形型マルウェアは毎回異なるハッシュ |
| SSL証明書ハッシュ | 証明書の有効期間（最大1年） | IPより長命。追跡価値が高い |
| TTP（MITRE ATT&CKベース） | 数ヶ月〜数年 | 攻撃グループの根本的な手口。最も価値が高い |
3インテリジェンスサイクル――収集から活用までの流れ
脅威インテリジェンスは「一度収集して終わり」ではなく、継続的なサイクルとして運用されます。このサイクルを「インテリジェンスサイクル」と呼び、元来は軍事・諜報機関の手法が民間セキュリティに適用されたものです。
6ステップのインテリジェンスサイクル
「何を知りたいか」を明確にする最重要フェーズ。Priority Intelligence Requirements（PIR）として問いを設定する。例：「自社が属する金融業界を標的とした最新のランサムウェアグループはどこか？」「攻撃者はどのような初期侵入手法を使っているか？」
PIRに基づき、TIフィード・OSINT・ダークウェブ・ベンダーレポートなど複数ソースからデータを収集する。ソースの多様性と信頼性の評価が重要。
収集した生データを分析可能な形式に変換・正規化する。重複排除・フォーマット統一・タイムゾーン正規化・IOCの分類など。STIXフォーマットへの変換もここで実施。
処理されたデータにコンテキスト・判断・推奨事項を加えてインテリジェンスを生産する。攻撃グループの帰属・TTPのMITRE ATT&CKへのマッピング・影響範囲の評価など。
適切な形式で適切な読者に届ける。経営層向けの戦略レポート・SOC向けのIOCフィード・エンジニア向けのTTP詳細など、受け取る側に合わせた形で提供する。
「このインテリジェンスは役立ったか？」「PIRは適切だったか？」を評価し、次のサイクルに反映する。フィードバックなしにはサイクルが改善されない。
多くの組織はPHASE 2（収集）とPHASE 3（処理）は実施していますが、PHASE 1（計画）とPHASE 6（フィードバック）が欠落していることが多いです。目的なき収集は「IOCをため込むだけで活用されない」という典型的な失敗パターンにつながります。
4無料で使えるTIフィード・プラットフォーム総覧
脅威インテリジェンスの入り口として、まず無料のフィード・プラットフォームを活用することが重要です。有料サービスと組み合わせることで、より包括的な防御が実現できます。
主要な無料TIフィード・プラットフォーム
| サービス名 | 提供IOCタイプ | 特徴 | API |
|---|---|---|---|
| VirusTotal （virustotal.com） |
ハッシュ・URL・IP・ドメイン | 70以上のAVエンジンによる多角的スキャン。コミュニティコメント・グラフ機能 | ✅ 無料枠あり |
| OTX / AlienVault （otx.alienvault.com） |
IPアドレス・ドメイン・URL・ハッシュ・CVE | AT&T傘下。コミュニティ主導のPulse（脅威レポート）が充実。API無料。MISP連携可 | ✅ 完全無料 |
| MISP （misp-project.org） |
全IOCタイプ | オープンソースのTI共有プラットフォーム。自己ホスト型。STIX対応。組織間共有の標準 | ✅ 完全無料 |
| Abuse.ch | マルウェアハッシュ・C2 IP・URLhaus | MalwareBazaar・URLhaus・ThreatFox・FeodoTrackerを運営。専門性が高い | ✅ 完全無料 |
| Shodan （shodan.io） |
IP・ポート・バナー・証明書 | インフラIOCに特化。悪性IPの開放ポート・バナーを確認できる | ✅ 無料枠あり |
| PhishTank （phishtank.com） |
フィッシングURL | コミュニティ検証型のフィッシングURL DB。OpenDNS（Cisco）傘下 | ✅ 完全無料 |
| ThreatFox （threatfox.abuse.ch） |
IOCとマルウェアファミリーのマッピング | abuse.ch運営。IOCを特定のマルウェアファミリーに紐付けて提供 | ✅ 完全無料 |
| Feodo Tracker | Emotet・TrickBot・QakBot等のC2 IP | 主要バンキングマルウェアのC2リストをリアルタイム更新 | ✅ 完全無料 |
| AbuseIPDB （abuseipdb.com） |
悪意のあるIPアドレス | コミュニティ報告型。スキャン・DDoS・スパム等のカテゴリ別に確認可能 | ✅ 無料枠あり |
| OpenCTI | 全IOCタイプ | オープンソースのCTI（サイバー脅威インテリジェンス）プラットフォーム。STIX 2.1対応 | ✅ 完全無料 |
MISPプロジェクトは2012年にEU安全保障機関（ENISA）の支援を受けて発足し、現在は世界中の政府機関・CERT・民間企業が自組織のTI共有基盤として採用しています。2024年現在、公開されているMISPインスタンス間で共有されているIOCは数百万件規模に達しています。
有料TIサービス（参考）
| サービス名 | 特徴 | 対象組織 |
|---|---|---|
| Recorded Future | AI駆動のリアルタイム分析。脅威アクター追跡。ダークウェブ監視 | 大企業・政府機関 |
| CrowdStrike Falcon Intelligence | EDRと統合されたTI。APTグループの詳細レポート | 中〜大企業 |
| Mandiant Advantage | Google傘下。インシデントレスポンスで収集した実戦データ | 大企業・政府 |
| Palo Alto Unit 42 | マルウェア分析・APT追跡に特化した研究チームのTI | 中〜大企業 |
| Microsoft DTTI | Microsoft製品との深い統合。Sentinel/Defenderとのネイティブ連携 | Microsoft環境の組織 |
5STIX／TAXIIとは――脅威情報の標準フォーマット
脅威インテリジェンスの共有・交換を標準化するために、OASISによって策定された2つの規格があります。STIX（Structured Threat Information eXpression）がデータフォーマットを、TAXII（Trusted Automated eXchange of Intelligence Information）がデータ転送プロトコルを定義します。
STIX 2.1の主要オブジェクト（SDO）
| オブジェクトタイプ | 説明 | 使用例 |
|---|---|---|
indicator | IOCパターンの定義 | 「このIPがC2通信に使用される」というルール |
malware | マルウェアの特性・動作記述 | Emotetの感染メカニズム・C2通信方法 |
threat-actor | 脅威アクターの属性 | APT29の国籍・動機・スキルレベル |
attack-pattern | 攻撃手法（MITRE ATT&CKテクニック） | T1566.001 スピアフィッシング添付ファイル |
campaign | 特定の攻撃キャンペーン | 「Operation GhostShell」等の名前付きキャンペーン |
course-of-action | 対策・緩和策の記述 | 「特定レジストリキーを監視せよ」 |
tool | 攻撃者が使用するツール | Cobalt Strike・Mimikatz等の記述 |
vulnerability | 脆弱性（CVE参照） | CVE-2021-44228（Log4Shell） |
relationship | オブジェクト間の関係 | 「threat-actor XがmalwareYを使用する」 |
STIX JSONの基本構造
# STIX 2.1 indicatorオブジェクトの例
{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
"created": "2024-01-15T10:00:00.000Z",
"modified": "2024-01-15T10:00:00.000Z",
"name": "Malicious IP - APT29 C2",
"description": "APT29のC2サーバーとして確認されたIPアドレス",
"pattern": "[ipv4-addr:value = '185.220.101.34']",
"pattern_type": "stix",
"valid_from": "2024-01-15T10:00:00.000Z",
"labels": ["malicious-activity"],
"confidence": 85,
"kill_chain_phases": [{
"kill_chain_name": "mitre-attack",
"phase_name": "command-and-control"
}]
}TAXIIサーバーへの接続（Python）
from taxii2client.v21 import Server
# TAXII 2.1サーバーに接続
server = Server(
"https://cti.example.com/taxii/",
user="username",
password="password"
)
# 利用可能なコレクションを取得
api_root = server.api_roots[0]
for collection in api_root.collections:
print(f"Collection: {collection.title} / ID: {collection.id}")
# 特定コレクションからSTIXオブジェクトを取得
collection = api_root.collections[0]
objects = collection.get_objects()
for obj in objects.get("objects", []):
if obj["type"] == "indicator":
print(f"IOC: {obj.get('name')} / Pattern: {obj.get('pattern')}")TAXII 2.0は2017年にOASISにより正式公開され、TAXII 2.1は2021年に最新版として公開されました。現在、MITRE ATT&CK・US-CERT・ENISA・多くの商用TIプラットフォームがTAXII 2.xを使ったSTIX配信をサポートしています。日本のJPCERT/CCもTI共有にTAXII/STIXを採用しています。
6MITRE ATT&CK フレームワークの実践活用
MITRE ATT&CKは、MITREが2013年から開発・公開している実際に観測されたサイバー攻撃のTTP（戦術・技術・手順）のナレッジベースです。現在はEnterprise・Mobile・ICS（産業制御システム）の3マトリクスがあり、Enterprise版は14の戦術（Tactic）と200以上の技術（Technique）で構成されています。
MITRE ATT&CKは2024年現在、Enterprise版でv15が最新版として公開されています。14の戦術タクティック（偵察・リソース開発・初期アクセス・実行・永続化・権限昇格・防御回避・認証情報アクセス・発見・横展開・収集・C&C・流出・影響）と、それぞれに紐づく200以上のテクニック・サブテクニックが、実際の攻撃事例に基づいてドキュメント化されています。世界中のセキュリティチームが検知ルール・ペネトレーションテスト・脅威ハンティングの共通言語として使用しています。
ATT&CKの14戦術（Tactics）と概要
| ID | 戦術名 | 攻撃者の目的 | 代表的テクニック |
|---|---|---|---|
| TA0043 | 偵察（Reconnaissance） | 標的に関する情報収集 | T1595 アクティブスキャン |
| TA0042 | リソース開発（Resource Development） | 攻撃に必要なリソースの取得 | T1583 インフラの取得 |
| TA0001 | 初期アクセス（Initial Access） | ネットワークへの最初の侵入 | T1566 フィッシング |
| TA0002 | 実行（Execution） | 悪意のあるコードの実行 | T1059 コマンドラインインタープリター |
| TA0003 | 永続化（Persistence） | アクセスの維持 | T1053 スケジュールタスク |
| TA0004 | 権限昇格（Privilege Escalation） | より高い権限の取得 | T1068 脆弱性の悪用 |
| TA0005 | 防御回避（Defense Evasion） | セキュリティツールの回避 | T1055 プロセスインジェクション |
| TA0006 | 認証情報アクセス（Credential Access） | パスワード・トークンの窃取 | T1003 OSの認証情報ダンプ |
| TA0007 | 発見（Discovery） | 環境情報の収集 | T1082 システム情報の発見 |
| TA0008 | 横展開（Lateral Movement） | ネットワーク内での移動 | T1021 リモートサービス |
| TA0009 | 収集（Collection） | 関心データの特定と収集 | T1005 ローカルシステムのデータ |
| TA0011 | C&C（Command and Control） | 侵害システムとの通信 | T1071 アプリケーション層プロトコル |
| TA0010 | 流出（Exfiltration） | データの外部持ち出し | T1041 C&Cチャネル経由の流出 |
| TA0040 | 影響（Impact） | システムへのダメージ・妨害 | T1486 データの暗号化（ランサムウェア） |
MITRE ATT&CKを使った検知ルールの作成
ATT&CKのテクニックに基づいてSIEM検知ルールを作成することで、IOCに依存しない「振る舞いベースの検知（TTPベース）」が実現できます。
# Sigma（汎用SIEM検知ルール形式）によるATT&CK T1059.001対応ルール例
title: Suspicious PowerShell Encoded Command
id: 65531a81-a694-4e31-ae04-f8ba5bc33759
status: stable
description: PowerShellの-EncodedCommandパラメータの使用を検知
references:
- https://attack.mitre.org/techniques/T1059/001/
author: Security Team
date: 2024/01/15
tags:
- attack.execution
- attack.t1059.001
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\powershell.exe'
CommandLine|contains:
- '-EncodedCommand'
- '-enc '
- '-ec '
filter_legitimate:
CommandLine|contains: 'legitimate_app_pattern'
condition: selection and not filter_legitimate
falsepositives:
- 一部の正規管理スクリプトがエンコードされたコマンドを使用する場合がある
level: mediumATT&CK Navigatorによる可視化
MITRE ATT&CK Navigator（attack.mitre.org/workbench/）は、自社の検知カバレッジ・脅威グループのTTP・ペネトレーションテスト結果をマトリクス上に色分けして可視化するWebツールです。
- 自社のSIEM/EDRが検知できるテクニックを青色でマーク → 検知カバレッジを可視化
- 侵害を受けたインシデントのTTPを赤色でマーク → 攻撃経路をマッピング
- 特定のAPTグループ（例：APT29）のTTPをインポートして重ね合わせ → 脅威特化の対策優先度を設定
- レッドチーム演習のカバレッジと実際の検知ルールを比較 → ギャップを特定
7VirusTotalを使った高度なIOC分析
VirusTotalは単なる「ファイルスキャンツール」ではなく、高度なIOC分析に使える包括的なTIプラットフォームです。特にPremium（Enterprise）版のGraph機能とRetroHunt機能は、プロのアナリストが日常的に活用する強力な機能です。
VirusTotal APIによる自動分析
import vt
import json
client = vt.Client("YOUR_VIRUSTOTAL_API_KEY")
# ファイルハッシュのレポートを取得
def analyze_hash(file_hash):
try:
file_report = client.get_object(f"/files/{file_hash}")
stats = file_report.last_analysis_stats
print(f"ファイル名: {file_report.meaningful_name}")
print(f"悪意あり: {stats['malicious']} / 不審: {stats['suspicious']}")
print(f"検知なし: {stats['undetected']}")
print(f"タグ: {file_report.tags}")
return stats['malicious'] > 0
except vt.error.APIError as e:
print(f"エラー: {e}")
return None
# ドメインのレポートを取得
def analyze_domain(domain):
domain_report = client.get_object(f"/domains/{domain}")
print(f"カテゴリ: {domain_report.categories}")
print(f"評判スコア: {domain_report.reputation}")
print(f"作成日: {domain_report.creation_date}")
# 使用例
analyze_hash("44d88612fea8a8f36de82e1278abb02f")
analyze_domain("suspicious-domain.com")
client.close()VirusTotal Graphによるインフラマッピング
VirusTotal GraphはIOC間の関係をグラフ化する機能です。あるIPアドレスから出発して、そのIPに紐づくドメイン・ファイル・URL・関連IPを自動展開することで、攻撃者のインフラ全体をマッピングできます。
- 既知の悪意あるIP/ドメインをGraph上に配置
- 「Expand」機能で紐づくドメイン・ファイル・URLを展開
- SSL証明書ハッシュで共通インフラを特定（同一証明書を使う複数のC2を発見）
- Passive DNSで過去の紐づきを追跡し、退役したインフラも含めて全体像を把握
- 発見したIOCをSTIXフォーマットでエクスポートし、MISPに投入
IOC評価の5つの指標
IOCを受け取った際、そのまま鵜呑みにせずに品質を評価することが重要です。
| 評価指標 | 確認内容 | ツール・方法 |
|---|---|---|
| 信頼性（Confidence） | ソースの信頼度。自社インシデントから得られたIOCは最高評価 | ソースのトラックレコード確認 |
| 鮮度（Freshness） | 最終確認日。古いIPは正規サービスに再割り当てされている可能性 | 最終更新日・有効期限の確認 |
| コンテキスト | 「なぜこのIPが悪意あるとされるか」の根拠 | 関連レポート・インシデント情報 |
| 偽陽性リスク | 正規サービスと混同されるリスク。大手CDN・DNS Resolver等 | IPの所属ASN・ホスティング情報 |
| 関連性（Relevance） | 自組織の業種・環境に関連する脅威か | 業種・地域・使用技術との照合 |
8.8.8.8（Google Public DNS）や1.1.1.1（Cloudflare DNS）のような大手サービスのIPがTIフィードに含まれている場合があります。これらをブロックすると全社のDNS解決が停止するという壊滅的な影響が出ます。IOCの適用前には必ず偽陽性チェックを実施してください。
8PythonによるIOC収集・分析の自動化
大量のTIフィードを手動で処理することは現実的ではありません。Pythonによる自動化で収集・処理・評価・統合のパイプラインを構築します。
TIフィードの自動取得と処理
import requests
import json
from datetime import datetime, timezone
# Abuse.ch ThreatFox APIからIOCを取得
def fetch_threatfox_iocs(days_back=1):
url = "https://threatfox-api.abuse.ch/api/v1/"
payload = {
"query": "get_iocs",
"days": days_back
}
response = requests.post(url, json=payload, timeout=30)
data = response.json()
iocs = []
if data.get("query_status") == "ok":
for item in data.get("data", []):
iocs.append({
"ioc": item["ioc"],
"ioc_type": item["ioc_type"],
"malware_family": item["malware"],
"confidence": item["confidence_level"],
"tags": item.get("tags", []),
"first_seen": item["first_seen"]
})
return iocs
# OTX AlienVaultフィードを取得
def fetch_otx_pulses(api_key, modified_since_days=1):
headers = {"X-OTX-API-KEY": api_key}
url = "https://otx.alienvault.com/api/v1/pulses/subscribed"
params = {"modified_since": f"{modified_since_days}d"}
response = requests.get(url, headers=headers, params=params)
pulses = response.json().get("results", [])
all_iocs = []
for pulse in pulses:
for indicator in pulse.get("indicators", []):
all_iocs.append({
"ioc": indicator["indicator"],
"ioc_type": indicator["type"],
"pulse_name": pulse["name"],
"tags": pulse.get("tags", [])
})
return all_iocsIOCの重複排除・正規化・スコアリング
import ipaddress
import re
from collections import Counter
# IPアドレスの検証と正規化
def validate_ip(ip_str):
try:
ip = ipaddress.ip_address(ip_str)
# プライベートIPアドレスを除外
if ip.is_private or ip.is_loopback or ip.is_reserved:
return None
return str(ip)
except ValueError:
return None
# ドメインの基本検証
def validate_domain(domain):
pattern = r'^[a-zA-Z0-9]([a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])?(\.[a-zA-Z]{2,})+$'
if re.match(pattern, domain):
# 大手CDN・信頼済みドメインのホワイトリストチェック
whitelist = {'google.com', 'microsoft.com', 'cloudflare.com'}
if domain not in whitelist:
return domain
return None
# IOCの信頼スコアを算出（複数ソースで確認されるほど高スコア）
def calculate_ioc_score(ioc, source_counts):
base_score = 50
# 複数ソースで確認された場合にスコアを加算
source_bonus = min(source_counts.get(ioc, 1) * 10, 40)
return base_score + source_bonusAbuseIPDB APIを使ったIPレピュテーション確認
import requests
def check_abuseipdb(ip_address, api_key):
url = "https://api.abuseipdb.com/api/v2/check"
headers = {
"Key": api_key,
"Accept": "application/json"
}
params = {
"ipAddress": ip_address,
"maxAgeInDays": "90",
"verbose": ""
}
response = requests.get(url, headers=headers, params=params)
data = response.json()["data"]
return {
"ip": data["ipAddress"],
"abuse_confidence": data["abuseConfidenceScore"],
"country": data["countryCode"],
"isp": data["isp"],
"total_reports": data["totalReports"],
"last_reported": data["lastReportedAt"]
}9SIEMへのTIフィード統合――実装ガイド
収集・分析したIOCをSIEM（Security Information and Event Management）に統合することで、リアルタイムのアラート生成・自動対応・脅威ハンティングが可能になります。
SIEM統合の3つのアーキテクチャパターン
TIプロバイダーのAPI → SIEM内蔵のTI機能に直接投入。Splunk ES・Microsoft Sentinel・IBM QRadarはこのパターンをネイティブサポート。設定コストが低く最初のステップとして最適。
TIフィード → MISP/OpenCTI（TIP）→ SIEM。TIPで正規化・重複排除・スコアリングを行い、高品質なIOCのみをSIEMに送り込む。偽陽性を大幅に削減できる。
TIフィード → SIEM（検知） → SOAR（自動対応）。IOCがヒットしたアラートを自動的にSOARに送り、エンリッチメント（追加情報収集）→ チケット作成 → ブロック実行まで自動化。
Microsoft Sentinelへの統合例
# Azure CLI / Python SDKでSentinelにThreat Intelligenceを投入
from azure.identity import DefaultAzureCredential
from azure.mgmt.securityinsight import SecurityInsights
from azure.mgmt.securityinsight.models import ThreatIntelligenceIndicatorModel
credential = DefaultAzureCredential()
client = SecurityInsights(credential, "YOUR_SUBSCRIPTION_ID")
# IOCをSentinelのTI Indicatorsとして登録
indicator = ThreatIntelligenceIndicatorModel(
threat_intelligence_tags=["APT29", "C2"],
pattern="[ipv4-addr:value = '185.220.101.34']",
pattern_type="stix",
source="Internal-TI-Team",
confidence=85,
valid_from="2024-01-15T00:00:00Z",
description="APT29 C2 IPアドレス - 金融機関攻撃キャンペーンで確認"
)
client.threat_intelligence_indicator.create_indicator(
resource_group_name="rg-security",
workspace_name="sentinel-workspace",
ti_indicator=indicator
)Splunk ESへのTIフィード投入（KV Store活用）
# Splunk REST APIでTI KV Storeを更新
import requests
import json
SPLUNK_URL = "https://splunk.example.com:8089"
SPLUNK_TOKEN = "YOUR_SPLUNK_TOKEN"
def push_ioc_to_splunk(ioc_list):
# TI用KV Storeコレクションに一括投入
url = f"{SPLUNK_URL}/servicesNS/nobody/SA-ThreatIntelligence/storage/collections/data/ip_intel"
headers = {
"Authorization": f"Bearer {SPLUNK_TOKEN}",
"Content-Type": "application/json"
}
for ioc in ioc_list:
payload = {
"ip": ioc["value"],
"threat_key": ioc["malware_family"],
"weight": ioc["confidence"],
"description": ioc["description"]
}
requests.post(url, headers=headers, json=payload, verify=False)SIEMにIOCを大量投入すると偽陽性アラートが急増し、SOCアナリストが「アラート疲れ（Alert Fatigue）」に陥る危険があります。Confidence 70以上・複数ソースで確認済み・30日以内のIOCのみを投入するなど、品質フィルタリングを必ず設けてください。
10脅威アクターのプロファイリング技法
個別のIOCを追うだけでなく、「どの攻撃グループが・何を目的に・どのような方法で攻撃してくるか」を理解することが上級TIアナリストの仕事です。これを脅威アクターの「プロファイリング」と呼びます。
主要な国家関連APTグループの特徴
| グループ名 | 帰属国 | 主要ターゲット | 代表的TTPs | 別名 |
|---|---|---|---|---|
| APT29 | ロシア（SVR） | 政府・シンクタンク・医療・IT企業 | WellMess・SUNBURST・Cobalt Strike。サプライチェーン攻撃を多用 | Cozy Bear・Midnight Blizzard |
| APT28 | ロシア（GRU） | NATO・政府・選挙関連・メディア | X-Agent・Sofacy。フィッシング・ゼロデイ悪用 | Fancy Bear・Forest Blizzard |
| APT41 | 中国 | ゲーム・医療・テレコム・国防 | 国家スパイ活動と金銭目的の攻撃を並行。サプライチェーン・VPN脆弱性悪用 | Winnti・Double Dragon |
| Lazarus Group | 北朝鮮（RGB） | 金融・仮想通貨・航空宇宙・防衛 | 外貨獲得目的の仮想通貨窃取。SWIFT攻撃。ランサムウェア展開 | Hidden Cobra・Zinc |
| APT33 | イラン | 航空宇宙・エネルギー・サウジアラビア | スピアフィッシング・ワイパーマルウェア（Shamoon） | Elfin・Refined Kitten |
Microsoft社は2023年以降、APTグループの命名規則を刷新し、国家系は「〇〇 Blizzard/Typhoon/Sandstorm」、金銭目的系は「〇〇 Tempest」、ハクティビスト系は「〇〇 Flood/Sleet」という形式に統一しました。例えばAPT29は「Midnight Blizzard」、APT41は「Brass Typhoon」と命名されています。業界内では新旧の名称が混在しているため、どちらの命名規則かを把握しておくことが重要です。
プロファイリングに必要な7要素
動機（Motivation）
国家支援型スパイ活動・金銭目的・ハクティビズム・破壊工作のいずれか
帰属（Attribution）
国家・組織への帰属。複数の独立した証拠に基づく慎重な判断が必要
能力（Capability）
使用するツール・ゼロデイの調達能力・マルウェア開発能力
標的（Targeting）
業種・地域・組織規模・特定のポジション（CISO・CFO等）の傾向
TTP
MITRE ATT&CKにマッピングされた具体的な攻撃手順・ツール・手続き
インフラ（Infrastructure）
C2サーバーの特徴・ASN傾向・証明書パターン・VPS/自前ホスト
活動パターン（Tempo）
活動時間帯（タイムゾーン推定）・業務時間帯の有無・攻撃頻度
言語的証跡
マルウェア・コード・文書のメタデータに含まれる言語・文字コード
11インシデントレスポンスへのTI活用
脅威インテリジェンスはインシデント対応の各フェーズで活用できます。特に初期トリアージ・根本原因分析・封じ込め範囲の特定において、TIは対応時間を大幅に短縮します。
IRフェーズ別TI活用マップ
自組織が属する業種の最新攻撃トレンドをTIで把握。攻撃されやすい経路（フィッシング・VPN脆弱性等）に対応したプレイブックを事前作成。TI経由で得た攻撃グループのTTPに基づく検知ルールを事前に整備。
SIEMアラートのIPアドレス・ドメインを即座にTIで照合。VirusTotal・OTXで既知のマルウェアファミリーか確認。MITRE ATT&CKで観測されたTTPを特定し、どのキャンペーンに似ているか判断。
確認されたC2サーバーのIPレンジ・ドメインをファイアウォール・Proxyでブロック。TIPのパッシブDNSで関連する追加C2を特定し、ブロック範囲を拡大。SSL証明書ハッシュで同一インフラの別エンドポイントを特定。
使用されたマルウェアファミリーのTIレポートから、典型的な永続化手法（レジストリキー・サービス・スケジュールタスク）を把握し、見落としがないか体系的に確認。
インシデントから得られたIOCをSTIX形式で記録し、MISPに投入して組織内外に共有。攻撃者のTTPをMITRE ATT&CKにマッピングし、検知ギャップを特定。TIプログラムのPIRを更新。
IOCのエンリッチメント自動化
import requests
from concurrent.futures import ThreadPoolExecutor
# 複数のTIソースでIOCを並列にエンリッチメント
def enrich_ip(ip_address, vt_key, abuse_key):
results = {}
def check_vt():
headers = {"x-apikey": vt_key}
r = requests.get(
f"https://www.virustotal.com/api/v3/ip_addresses/{ip_address}",
headers=headers, timeout=15
)
if r.status_code == 200:
data = r.json()["data"]["attributes"]
results["virustotal"] = {
"malicious": data["last_analysis_stats"]["malicious"],
"country": data.get("country"),
"asn": data.get("asn")
}
def check_abuse():
r = requests.get(
"https://api.abuseipdb.com/api/v2/check",
headers={"Key": abuse_key},
params={"ipAddress": ip_address, "maxAgeInDays": "30"},
timeout=15
)
if r.status_code == 200:
results["abuseipdb"] = r.json()["data"]
# 並列でエンリッチメントを実行
with ThreadPoolExecutor(max_workers=2) as executor:
executor.submit(check_vt)
executor.submit(check_abuse)
return results12TIプログラムの構築と成熟度モデル
TIは単発のツール導入ではなく、継続的に運用・改善されるプログラムとして設計する必要があります。成熟度モデルを使ってロードマップを描きましょう。
TI成熟度モデル（5段階）
| レベル | 名称 | 特徴 | 目安 |
|---|---|---|---|
| Lv.1 | アドホック | TI活動が存在しない。インシデント発生時のみ断片的に情報収集 | 多くの中小企業 |
| Lv.2 | 初期 | 無料フィードをSIEMに統合。IOCの手動チェックを実施。PIRは未定義 | セキュリティ意識のある中小企業 |
| Lv.3 | 定義済み | MISPやOpenCTIを導入。TIPでIOCを管理。MITRE ATT&CKにTTPをマッピング開始 | SOCを持つ中規模企業 |
| Lv.4 | 管理済み | インテリジェンスサイクルが確立。PIRに基づくTI生産。ISACへの情報共有参加 | 成熟したSOCを持つ大企業 |
| Lv.5 | 最適化 | TIが経営判断・予算計画に統合。独自の脅威アクター追跡。業界全体への貢献 | 金融・通信・防衛等の重要インフラ |
小規模組織でのTIプログラム開始3ステップ
- PIRの設定（1週間）：「自社業種を狙うランサムウェアグループを把握する」等の具体的な問いを2〜3個設定。漠然とした「すべての脅威」ではなく絞り込みが重要
- 無料フィードの統合（2週間）：Abuse.ch ThreatFox・OTX・AbuseIPDBのAPIをSIEMに接続。既存のファイアウォール・Proxyへのブロックリスト投入
- レポーティングの習慣化（継続）：週1回、収集したTIから自組織への影響度を評価し、担当者（CISO等）に共有。フィードバックを次週のPIR改善に反映
13コミュニティ共有とISAC――情報共有の実際
TIの価値は組織内に閉じ込めておくより、信頼できるコミュニティで共有することで指数的に高まります。「1つの組織で観測した攻撃情報が、他の組織の被害を未然に防ぐ」という善のサイクルがTI共有の本質です。
ISAC（情報共有・分析センター）とは
ISACは特定業種の組織が集まり、サイバー脅威情報を相互に共有する業界団体です。1998年に米国で始まった概念で、現在は世界中に業種別のISACが設立されています。
2024年現在、米国には金融（FS-ISAC）・医療（H-ISAC）・エネルギー（E-ISAC）・航空（A-ISAC）・IT（IT-ISAC）など24以上の業種別ISACが活動中です。日本においては、2017年に設立された金融ISAC（金融機関向け）や、IPAが推進するJ-CSIP（サイバー情報共有イニシアティブ）が主要な情報共有組織です。J-CSIPには2024年現在、製造・自動車・防衛など幅広い業種から200社超が参加しています。
MISPを使ったコミュニティ共有
from pymisp import PyMISP, MISPEvent, MISPAttribute
# MISPインスタンスに接続
misp = PyMISP(
url="https://misp.example.com",
key="YOUR_MISP_API_KEY",
ssl=True
)
# 新しいTIイベントを作成
event = MISPEvent()
event.info = "Emotet Campaign - 2024-Q1 Japan Targeting"
event.threat_level_id = 2 # Medium
event.analysis = 2 # Completed
event.distribution = 3 # All communities
# IOCを追加
event.add_attribute("ip-dst", "185.220.101.34", comment="Emotet C2")
event.add_attribute("domain", "evil-update.com", comment="Distribution domain")
event.add_attribute("md5", "44d88612fea8a8f36de82e1278abb02f", comment="Dropper hash")
# タグの追加（MITRE ATT&CK対応）
event.add_tag("misp-galaxy:mitre-attack-pattern=\"Phishing - T1566\"")
event.add_tag("tlp:amber") # TLPレベルの指定
# イベントをMISPに投入
result = misp.add_event(event)
print(f"Event ID: {result.id}")TLP（Traffic Light Protocol）の理解と遵守
TLPは脅威情報の共有範囲を色で示す業界標準プロトコルです（FIRST.org が管理）。
| TLPカラー | 共有範囲 | 使用場面 |
|---|---|---|
| 🔴 TLP:RED | 情報提供者と受領者のみ（転送禁止） | 最高機密の脆弱性・インシデント情報 |
| 🟠 TLP:AMBER | 受領組織内の「Need to Know」の人員のみ | 顧客・パートナーに限定した情報 |
| 🟡 TLP:AMBER+STRICT | 受領組織のメンバーのみ（顧客への共有も禁止） | より厳格な制限が必要な場合 |
| 🟢 TLP:GREEN | コミュニティ全体（公開不可） | 業界内での広い共有 |
| ⬜ TLP:CLEAR | 制限なし・公開可能 | 一般公開の脅威情報・セキュリティ勧告 |
14法的・倫理的考慮点と2025年以降のトレンド
TI活動における法的考慮点
「ハックバック（反撃）」は日本では違法です。不正アクセス禁止法により、たとえ攻撃者のサーバーであっても、許可なく第三者のシステムにアクセスすることは違法です。TIは「防御的な情報収集・分析・共有」に限定し、攻撃者への能動的な反撃（ハックバック・アクティブディフェンス）は行ってはいけません。
| 法規制 | TI活動との関係 |
|---|---|
| 不正アクセス禁止法 | 攻撃者インフラへの直接アクセス・ハックバックは違法。PassiveDNS・ShodanなどのOSINTは合法 |
| 個人情報保護法 | TIフィードに個人情報（氏名・メールアドレス等）が含まれる場合は適用対象。収集・利用目的の明確化が必要 |
| 不正競争防止法 | 企業の内部情報（競合他社の脆弱性情報等）を不正に収集・利用することは適用対象 |
| GDPR（EU） | EU居住者のメールアドレス等の個人情報がTIデータに含まれる場合、日本企業でも適用の可能性 |
2025年以降の脅威インテリジェンストレンド
- AI駆動のTI（AI-Powered TI）：LLMによるマルウェアレポートの自動要約・未知のIOCパターン検出・脅威アクターの行動予測が実用化段階に入っています。Recorded FutureはAI分析を中核サービスに位置づけています
- 生成AI悪用への対応TI：AIが生成したフィッシングメール・ディープフェイク動画を使った標的型攻撃が増加。これらを検出するためのTI（AIコンテンツ検出IOC）という新カテゴリが誕生しています
- 量子コンピュータ準備（PQC）とTI：量子コンピュータによる暗号解読に向けた長期的な準備として、「Harvest Now Decrypt Later（今収集して後で復号）」攻撃が国家系APTで観測されています。TLSハンドシェイクのキャプチャを中心としたTI収集が重要性を増しています
- OT/ICS向けTIの成熟：工場・電力・水道などの産業制御システムを標的とした攻撃が急増し、OT環境特有のTI（Dragos・Claroty等が提供）への需要が高まっています
- サプライチェーンTI：SolarWinds（2020年）・Kaseya（2021年）・3CX（2023年）等のサプライチェーン攻撃を受け、ベンダーのセキュリティ状況を継続的にモニタリングするTIが標準化されつつあります
Verizon社の「Data Breach Investigations Report（DBIR）2024」によると、2023年に分析されたインシデントのうち68%にソーシャルエンジニアリングまたはフィッシングが関与しており、初期アクセス手法としては依然として最大の脅威です。また、ランサムウェアが関与したインシデントのうち中央値での身代金支払い額は150,000ドル（約2,200万円）を超えており、TIによる事前防御の経済的価値は明確です。
まとめ：脅威インテリジェンスを「使える武器」にするために
PIRを先に決める
「何を知りたいか」を定義しないTIは価値のないIOCの山になる
Pyramid of Painを意識
ハッシュより上位のTTPベース検知を目指す。IPブロックは一時的な対策に過ぎない
STIX/TAXIIで標準化
IOCをSTIXフォーマットで管理することで再利用性と共有性が向上する
ATT&CKにマッピング
すべての観測TTPをATT&CKに紐づけることで検知ギャップが可視化される
SIEMへの品質統合
大量投入より高品質なIOCを厳選して投入。偽陽性管理が運用継続の鍵
コミュニティで共有
TLPを遵守した情報共有が業界全体のセキュリティレベルを底上げする
学習を深めるための推奨リソース
- MITRE ATT&CK公式サイト（attack.mitre.org）：最新のTTP・グループ情報を確認
- SANS CTI Summit：年1回開催のTI専門カンファレンス。講演資料が後日公開
- FIRST TLP Guidelines（first.org/tlp）：TLPの公式ガイドライン
- Mandiant / Google Cloud Security Blog：APT分析レポートの最新事例
- JPCERT/CC Weekly Report：日本語で読める国内外の脅威情報
- 「The Threat Intelligence Handbook」（CrowdStrike・Recorded Future共同発行）：無料ダウンロード可能な定番書籍
コメント