IoCのリストは、まだ「インテリジェンス」ではない
はじめに
「脅威インテリジェンス」は、セキュリティの現場では当たり前に飛び交う言葉です。ベンダーの提案資料にも、社内の企画書にも出てきます。
ただ、これほど頻繁に使われる割に、定義が共有されないまま話が進むことが多い言葉でもあります。ある人は不審なIPアドレスやハッシュ値のフィードを指し、別の人は攻撃者グループの分析レポートを指し、また別の人は「業界動向のことでしょ」と言う。同じ会議で3人が違うものを想像したまま進む、という場面は珍しくないと思います。
改めて体系的な資料に当たって整理してみると、この混乱の原因はかなりはっきりしていました。多くの人が「インテリジェンス」と呼んでいるものは、実はその一歩手前の「情報」で止まっているからです。
先に、この記事でいちばん言いたいことを書いておきます。インテリジェンスの価値は、集めた情報の量ではなく、意思決定にどれだけつながるかで決まります。だから、脅威インテリジェンスで最初に決めるべきなのは、「何を集めるか」ではなく「何を知りたいか」です。この順番を軸に、押さえておきたい3つを整理します。
① 「情報」と「インテリジェンス」は、はっきり別物
まずここが分かれ目です。よく使われる整理では、素のデータ、それに意味を与えた情報、そして意思決定に使える形にしたインテリジェンス、という3段階で捉えます。
データ・情報: 「IPアドレス 203.0.113.1 は不審」
インテリジェンス: 「203.0.113.1 は、ある攻撃者グループが2026年7月から使っている遠隔操作用のサーバー。自社のログを7月までさかのぼって確認すべき」
同じIPアドレスの話なのに、後者には誰が・いつから・だから何をすべきかが付いています。この差です。
天気に置き換えると分かりやすいかもしれません。「気温15度、湿度80%、気圧下降中」は観測データです。「明日は雨なので傘を持っていったほうがいい」が予報、つまりインテリジェンスです。データそのものは正しくても、それだけ渡されて「で、傘は要るの？」と聞き返したくなる状態は、まだインテリジェンスになっていません。
ここからは資料の定義をそのまま紹介するのではなく、私なりに「インテリジェンスとして使えているか」を確認する観点として、3つに整理してみます。
文脈がある（誰が、なぜ、どんな手口で）
鮮度が保たれている（その情報は、いつ時点の・どれくらい有効なものか）
意思決定につながる（読んだ人が、次の判断に使えるか）
この観点で見ると、侵害の痕跡を示すデータ（IoC: Indicator of Compromise）の羅列は、インテリジェンスの材料ではあっても、インテリジェンスそのものではありません。IoCはIPアドレスやハッシュ値だけを指すわけではありませんが、いずれにせよ「痕跡のデータ」であることは共通しています。
ここを曖昧にしたまま「うちも脅威インテリジェンスを入れよう」という話が始まると、フィードを契約したのに現場が使いこなせない、という結末になりがちです。導入の議論をする前に、自分たちが欲しいのは材料なのか、加工済みのものなのかをはっきりさせておく必要があります。
② 同じ脅威でも、届ける相手で「形」が変わる
脅威インテリジェンスは、目的や利用者、アウトプットの形などによって、戦略的・運用的・戦術的などに分類されることがあります。分類の仕方そのものは組織によって差があるとされていますが、代表的な3つを見ると、性格の違いがつかめます。
戦略的（Strategic） — 主な読み手は経営層
業界動向、攻撃者の目的、規制の流れ。時間軸は数ヶ月〜数年。「自社の業界を狙うランサムウェアが増加傾向で、取引先経由の侵入が主流になりつつある」といったレベルの話です。
運用的（Operational） — 主な読み手はセキュリティ管理者
特定の攻撃キャンペーンや、攻撃者が使う戦術・技術・手順（TTP）。時間軸は数週間〜数ヶ月。「あのグループはVPN機器の脆弱性から入り、その後こういうツールを展開する」という粒度です。
戦術的（Tactical） — 主な読み手はSOCのアナリスト、あるいは機器そのもの
IPアドレス、ドメイン、ハッシュ値、検知シグネチャ。時間軸は数時間〜数週間。「このハッシュ値のファイルをブロックする」で完結します。
ここで効いてくるのが、入手のしやすさと寿命の関係です。戦術的な情報は比較的手に入りやすい一方で、攻撃者がIPアドレスもドメインも簡単に変えられるため、鮮度がすぐに落ちます。逆に、戦略的・運用的なインテリジェンスは陳腐化しにくく意思決定への影響も大きいものの、作るのに分析力が要ります。
比較的手を付けやすいIoCフィードから始めると、集めること自体が目的になりやすい。私は、脅威インテリジェンスが「フィードを買って終わり」で止まる一因は、ここにあると考えています。
そしてもう一つ。同じ分析結果でも、経営層には「業界動向と投資判断」、SOCには「検知ルールとIoC」と、形を変えて届ける必要があります。全員に同じレポートを配ると、読み手によっては必要な情報が多すぎたり、逆に足りなかったりします。
③ つまずきやすいのは、たいてい「入口」
脅威インテリジェンスは、一度作って終わりではなく、サイクルとして回すものだとされています。整理の仕方は資料によって異なりますが、ここではDirectionから始まりFeedbackで戻る6フェーズのモデルで考えてみます。
なお、IPAのガイドラインは方針策定・収集加工・分析・配布・評価の5フェーズで整理しています。区切り方は違いますが、概念的には次のように対応づけて考えられます（Direction＝方針策定、Collection・Processing＝収集加工、Analysis＝分析、Dissemination＝配布、Feedback＝評価）。
図にすると当たり前に見えますが、現場でよく語られる悩みを並べると、詰まる場所はかなり偏っています。典型的なものを挙げると、こんな声です。
「IoCだけが届くが、どうしたらいいか分からない」
「数年続けているが、自社に関する脅威が得られているか分からない」
「内製化しようとしたが難易度が高すぎた」
1つ目は①で書いた「情報のまま届いている」問題、3つ目は④ Analysis に人材が要るという話です。この記事で注目したいのは、2つ目の「数年やっているが、自社に関係あるのか分からない」。これは① Direction を飛ばした結果だと説明されています。「何が知りたいのか」を先に決めていないので、集めた情報が役に立ったかどうかを評価する基準がそもそも存在しない。だから何年続けても手応えが出ない。②以降をどれだけ丁寧にやっても、①が空白だと成果を評価できなくなる、という構図です。
ここは脅威インテリジェンスに限らず、ログ収集でも監視ツールの導入でも同じことが起きます。目的の定義を飛ばして手段から入ると、後から成果を説明できなくなります。
このDirectionの効き目は、具体例にすると分かりやすいです。同じ「脅威情報」でも、問いが違えば必要なものはまるで変わります。
たとえば問いが「自社は今、侵害されていないか」なら、要るのはIPアドレスやハッシュ値などのIoCと、それを突き合わせる自社のログです。一方、問いが「来期のランサムウェア対策投資をどこに振るか」なら、IoCを大量に集めても、ほとんど判断材料になりません。要るのは、自社の業界を狙う攻撃者、主な侵入経路、想定される事業影響といった情報です。良いインテリジェンスとは、情報量が多いものではなく、その問いに答えられるものだ、ということです。
裏を返すと、始め方はシンプルです。現実的な順序はこうなります。
守るべき資産は何か、どんな判断に使いたいのかを紙1枚に書く（無料・最重要）
無料の情報源（JPCERT/CC、IPA、CISA、ベンダーブログ）で、要件に沿った情報が本当に取れるか試す
自社のログや過去のインシデントを分析する
足りないものが見えてから、商用フィードを検討する
3つ目は見落とされがちですが、重要です。自社のログは、自組織に関連する脅威を評価するうえで、外部から代替しにくい情報源だからです。外部の脅威情報と自社の観測データを突き合わせて初めて、その脅威が自社にどう関係するのかを評価できます。
④ 外部サービスは使っていい。ただし「問い」は手放さない
ここまで読むと、「結局は自前で分析しろということか」と受け取られるかもしれませんが、そうではありません。分析済みのレポートや攻撃者分析、業界別のインテリジェンスは、外部のサービスから買うことができます。使える手はどんどん使うべきです。
手放してはいけないのは、その手前の「何を知りたいのか」です。自社が何を決めるために、何を知る必要があるのか。この問いまで丸ごとベンダーに預けてしまうと、上がってきたものが自社に本当に必要なものだったのかを、評価する物差しが自分たちの側に残りません。
だから、外注する部分と、自社が握っておく部分を分けて考えるのがいいと思います。情報の収集や加工、分析の一部まで外部の力を借りてよい。けれど「何を知りたいか」という問いだけは、自社が持ち続ける。これは「ベンダーを使うな」ではなく、「ベンダーに丸投げしない」という話です。
フレームワークは「答え」ではなく「道具」
脅威インテリジェンスの周辺には、有名なフレームワークがいくつも登場します。並べて比較されることが多いのですが、そもそも目的が違うだけで、競合しているわけではありません。
Cyber Kill Chain: 攻撃の進行を7段階の時系列で捉え、どの段階で止められるかを考えるためのモデル。全体像を説明するのにも向く
MITRE ATT&CK: 実際に観測された戦術・技術を体系化したナレッジベース。検知の穴を可視化するのに使う。ただし「全部を埋める」ためのチェックリストではなく、MITRE自身も100%のカバレッジを目指さないよう促しています
Diamond Model: 1つの侵入を「敵対者・インフラ・能力・被害者」の4点で捉える。断片的な情報から攻撃者像を組み立てるときに向く
STIX / TAXII: STIXは脅威情報を構造化して表現するための標準、TAXIIはその情報をやり取りするためのプロトコル。自動連携の基盤になる
「防御の段階を考えるならKill Chain、検知の網羅性ならATT&CK、攻撃者像の分析ならDiamond Model」と目的別に置くと、どれか一つを選ぶ話ではないことがはっきりします。ただし、これらはあくまで情報の見方を助ける道具であって、インテリジェンスそのものではありません。フレームワークに沿って整理しただけでは、まだ「何を知りたいか」には答えていない、というのは押さえておきたいところです。
まとめ
IoCの羅列は、それだけではインテリジェンスではありません。文脈・鮮度・次の意思決定への接続があるかを見ると、その情報が「材料」で止まっていないかを確かめられます。
分類は組織によって差がありますが、手に入りやすい戦術的なものほど鮮度が落ちやすい、という傾向はつかんでおくと役に立ちます。
つまずきやすいのは、たいてい入口（Direction）です。「何を知りたいか」を決めずに集め始めると、何年やっても成果を評価できません。
こうして並べると、脅威インテリジェンスの本体は「攻撃者の情報を手に入れること」ではなく、情報を意思決定に使える形へ変える工程そのものだと分かります。集める・分析するといった工程は外部の力を借りてよい。ただし「何を知りたいか」という問いだけは、自社が持ち続ける。ここが、丸投げできない一点です。
そして「文脈・鮮度・次のアクション」という観点は、脅威情報に限らず使えます。この資料を渡された相手は、次に何をすればいいか分かるだろうか。社内へレポートを出すときにこれを一度通すだけでも、書くものがだいぶ変わりそうです。
セキュリティの考え方や新しい技術を、資格の知識とつなげて整理していきたいと思います。フォローしてもらえると、次を書く励みになります。
参考にした資料
出典：脅威インテリジェンス 導入・運用ガイドライン 2024｜IPA 産業サイバーセキュリティセンター
出典：実務者視点で考える脅威インテリジェンスの情報共有の在り方｜NTTデータ先端技術
出典：Threat Intelligence Lifecycle in 6 Phases｜Recorded Future
出典：サイバー脅威インテリジェンスとは？｜Splunk
出典：Cybersecurity Frameworks: MITRE ATT&CK, Kill Chain & Diamond Model｜Abusix
いいなと思ったら応援しよう！
記事が役に立ったら、応援してもらえると次を書く励みになります！いただいたチップは、書籍代や受験料にあてさせてもらいます！