脅威インテリジェンスとISMS｜ISO/IEC 27001:2022 新管理策5.7の実装・審査対応ガイド

ISO/IEC 27001:2022の改訂で、附属書Aに「5.7 脅威インテリジェンス」が新管理策として加わりました。本記事では、脅威インテリジェンスがISMSでどう位置づけられるのか、戦略・戦術・運用・技術の4分類、IPAやJPCERT/CCなどの情報源、TIPやSIEM連携といったツールの活用、内製と外部委託の判断基準までを整理します。さらに、上位記事が手薄なまま残している「移行審査で確認される運用証跡と文書化の具体例」「8.8技術的脆弱性管理や8.16監視活動との統合運用」まで踏み込み、認証取得・維持の実務に直結する形で解説します。これからISMSを取得する組織にも、2022年版へ移行済みの組織にも使える実装ガイドです。

まとめ：脅威インテリジェンス（管理策5.7）対応で押さえるISMS実装の要点

結論として、5.7対応は「脅威情報を集める」だけでは不十分で、収集した情報を分析し、自組織のリスクアセスメントに反映し、対応と記録まで回す一連の運用をルール化することが求められます。出発点はIPAとJPCERT/CCの無償情報の定期確認で十分ですが、審査では「誰が・いつ・どのように収集し、どう判断したか」を示す証跡が問われます。

投資対効果を高める鍵は、5.7を単独の管理策として扱わず、8.8技術的脆弱性管理や8.16監視活動と連携させる統合設計にあります。リソースが限られる組織はMSSや専門組織（5.6）の活用でスモールスタートし、内製化は段階的に判断するのが現実的です。2013年版の移行期限は2025年10月31日に終了しており、現行のISMSはすべて2022年版が前提である点も確認しておきましょう。

脅威インテリジェンスがISMS新管理策5.7として追加された背景と移行期限の現状

5.7がなぜ追加され、いつから必須になったのかを正しく押さえることが、過不足のない対応の前提になります。

附属書Aが114から93管理策へ再編されたISO/IEC 27001:2022改訂の経緯

ISO/IEC 27001:2022は2022年10月25日に発行され、日本語規格のJIS Q 27001:2023は2023年9月20日に発行されました。最大の変更は附属書Aで、従来14あった管理領域が「組織的・人的・物理的・技術的」の4区分に集約され、管理策数は114から93へ整理されました。この再編に伴い、最新の脅威動向に対応する新規管理策が11個追加され、その筆頭が項番5.7「脅威インテリジェンス」です。実装の手引となるISO/IEC 27002:2022が同年2月に先行改訂され、それを反映する形で27001本体が改訂された経緯も押さえておくと、両規格の役割分担が理解しやすくなります。

5.7が新規11管理策に選ばれたサイバー攻撃高度化という背景

改訂の動機は、境界型防御だけでは攻撃を防ぎきれなくなったという現実にあります。ゼロデイ攻撃やランサムウェア、サプライチェーンを狙った侵害が増え、「守りを固める」発想から「攻撃の兆候を先回りして掴む」発想への転換が求められました。新規11管理策のうち、5.7脅威インテリジェンス・8.16監視活動・8.23ウェブフィルタリングはいずれも検知と予防の強化を狙ったもので、識別・検知・対応・復旧というサイバーセキュリティフレームワークの考え方が規格に取り込まれています。5.7はその起点として、脅威環境を継続的に把握する役割を担います。

旧規格の「最新情報の収集」と5.7「分析・活用」要求の決定的な違い

2013年版にも「セキュリティに関する最新情報を収集する」趣旨の管理策はありました。5.7が異なるのは、収集にとどまらず「分析して社内に共有し、自組織のISMSに役立てる」という活用までを射程に含めた点です。たとえば同業他社で発生した攻撃事例を入手するだけでなく、その手口が自社に通用するかを分析し、結果を関連部門へ展開する——ここまでがワンセットになります。「情報を見ている」状態と「情報を判断に使っている」状態の差が、審査での評価を分ける分岐点になります。

2025年10月31日に失効した2013年版からの移行期限の現状

移行スケジュールは確定しており、2024年5月以降に新規認証・再認証審査を受ける組織は2022年版での審査が必須となり、既存の認証組織は2025年10月31日までに移行審査を受ける必要がありました。この期限はすでに経過しているため、現時点で有効なISMS認証はすべて2022年版が前提です。「移行期限が迫っている」という古い前提で書かれた情報は実態と合わなくなっており、これから取得・維持を検討する組織は最初から2022年版の93管理策を基準に準備する必要があります。

国内大手を襲ったランサムウェア被害が示す5.7対応の実務的必然性

5.7が抽象論でない理由は、実際の被害事例を見れば明らかです。国内でも大手企業が大規模なサイバー攻撃で出荷停止や受発注の混乱に追い込まれた事案があり、攻撃の兆候や同種事例を事前に把握できていれば対応の初動が変わった可能性があります。こうした国内大手を襲ったランサムウェア被害の経緯を自組織のリスクシナリオに照らして分析することは、まさに5.7が求める活用そのものです。事例の蓄積が、自社で起こりうる脅威の優先順位づけに直結します。

ISMSが求める脅威インテリジェンスの定義と戦略・戦術・運用・技術の4分類

5.7を運用に落とすには、脅威インテリジェンスを一枚岩で捉えず、目的別の層に分けて扱うことが有効です。

規格が到達点とする「収集・分析・活用」の3段階

脅威インテリジェンスとは、脅威に関する情報を収集・分析することでリスクを認識し、適切に対応するための管理策です。規格が求めるのは、情報を集める段階、それを使える形に整え分析する段階、リスクアセスメントへのインプットとして活用し対応する段階の3つを切れ目なく回すことです。単発のニュース閲覧で終わらせず、収集した情報をデータベースや一覧として維持し、定期的に見直す仕組みにできているかが評価の基準になります。この3段階を誰が担うかを決めることが、運用設計の第一歩です。

戦略的インテリジェンスが経営層のリスク判断に果たす役割

戦略的インテリジェンスは、自社が属する業界を狙う攻撃者の動向や、地政学・規制の変化といった中長期のリスク傾向を扱います。読者は主に経営層やCISOで、セキュリティ投資の配分やリスク受容の判断材料になります。たとえば「自社業界を標的にしたランサムウェア攻撃が増加傾向にある」という分析は、予算承認や事業継続計画の見直しの根拠になります。技術的な詳細より、意思決定に効く粒度へ要約することが価値を生みます。

戦術的インテリジェンスが捉える攻撃者のTTP（戦術・技術・手順）

戦術的インテリジェンスは、攻撃者が使う戦術・技術・手順（TTP）に焦点を当てます。MITRE ATT&CKのようなフレームワークで攻撃手口を体系的に把握し、自社の防御策に抜けがないかを点検する用途に向きます。利用者はセキュリティ運用チームやSOCの担当者です。「この攻撃グループはこの初期侵入手口を多用する」という情報があれば、該当する入口の監視を強化するといった具体的な対策へ落とし込めます。

運用的・技術的インテリジェンスとIoC（侵害指標）の現場活用

運用的インテリジェンスは進行中・差し迫った攻撃に関する情報を、技術的インテリジェンスは不正なIPアドレス・ドメイン・ハッシュ値といったIoC（侵害指標）を扱います。これらは検知・遮断の現場で直接消費される性質が強く、鮮度が命です。たとえば判明したばかりの不正IPをファイアウォールやEDRの遮断リストへ反映する運用が典型例です。鮮度が落ちると価値が急減するため、自動連携の仕組みづくりが効果を左右します。

4分類を自組織のリスクアセスメントへ接続する判断軸

4分類をすべて自前で揃える必要はなく、自組織のリスクと体制に応じて重点を選ぶのが現実的です。経営判断を補強したいなら戦略的、SOCを強化したいなら戦術的・技術的に寄せる、といった配分になります。判断軸は「その情報が最終的にどの意思決定や対応につながるか」です。出口の見えない情報収集は形骸化の典型で、収集前に活用先を決めておくことが、リスクアセスメントへ確実に接続するコツになります。

5.7対応で使う情報源（IPA・JPCERT/CC・OSINT・商用フィード）の選定基準

情報源は無償の公的機関から商用フィードまで幅があり、自社の成熟度に合わせて段階的に広げるのが定石です。

無償で始めるIPA・JPCERT/CCの注意喚起と購読の活用法

最低限の取り組みとしてまず着手したいのが、IPA（情報処理推進機構）とJPCERT/CCの活用です。両機関は脆弱性や攻撃キャンペーンに関する注意喚起を継続的に公開しており、メールマガジン購読やRSS登録で受動的に最新情報を受け取れます。費用がかからず始めやすいため、5.7のスモールスタートとして最適です。重要なのは「登録して終わり」にせず、受け取った注意喚起を週次など定期で確認し、自社該当性を判断する担当と頻度を決めておくことです。

OSINT（公開情報）収集の範囲とノイズを抑える運用ルール

OSINT（オープンソース・インテリジェンス）は、ベンダーの脅威レポート、セキュリティ研究者の公開情報、SNS上の注意喚起などを指します。情報量が豊富な一方でノイズも多く、無計画に集めると分析が追いつきません。収集対象を「自社が使う製品・サービス」「自社業界」に絞り、信頼できる発信元をリスト化しておくとノイズを抑えられます。誰が・どの情報源を・どの頻度で確認するかを手順化することが、OSINTを実務で回す前提条件になります。

商用脅威インテリジェンスフィードを導入する判断基準

無償情報では鮮度や網羅性が足りないと感じる段階で、商用の脅威インテリジェンスフィードが選択肢に入ります。判断基準は、自社が守るべき資産の重要度、SOCの運用体制の有無、そして既存のSIEMやEDRと連携できるかです。フィードは月額のサブスクリプション型が多く、IoCの自動配信やレポート提供を受けられます。導入前に、得られる情報を実際に検知・対応へ反映できる体制があるかを見極めないと、コストに見合わない結果になりがちです。

業界ISACや専門組織から共有される脅威情報の位置づけ

金融や医療など業界ごとに、会員間で脅威情報を共有するISAC（情報共有・分析組織）が整備されています。同業界を狙う攻撃は手口が共通しやすいため、ISAC経由の情報は自社該当性が高く、優先度を上げて扱う価値があります。会員制で守秘義務を伴うものが多く、得た情報の社内取り扱いルールを定めておく必要があります。自組織だけでは見えない攻撃の予兆を、業界横断で早期に掴める点が最大の利点です。

CVE・脆弱性データベースを技術的情報源として使う方法

技術的情報源の基盤になるのが、共通脆弱性識別子であるCVEと、それを集約する脆弱性データベースです。自社が利用する製品のCVEを継続的に追い、深刻度（CVSSスコア）と自社環境での影響を突き合わせて対応を判断します。CVEの識別・管理の仕組みを理解しておくと、脆弱性情報の優先順位づけが格段に速くなります。CVEの追跡は5.7と8.8技術的脆弱性管理をつなぐ結節点でもあり、両管理策を効率よく満たす起点になります。

収集分析を効率化するツール・脅威インテリジェンスプラットフォームとSIEM連携

情報源が増えるほど手作業の限界が見えてくるため、集約と自動連携を担うツールの理解が欠かせません。

脅威インテリジェンスプラットフォーム（TIP）が担う集約と正規化

脅威インテリジェンスプラットフォーム（TIP）は、複数の情報源から集めた脅威データを一元的に取り込み、重複排除や形式の正規化を行うツールです。IoCに信頼度スコアを付け、優先度を整理する機能を持つ製品もあります。情報源がIPA・JPCERT/CC・商用フィード・ISACと増えるほど、人手での突き合わせは破綻します。TIPは、収集・分析・共有という5.7の運用を仕組みとして支える土台であり、規模が大きい組織ほど導入効果が高くなります。

SIEM連携で実現する検知ルールの自動更新と運用負荷の削減

脅威インテリジェンスはSIEM（セキュリティ情報イベント管理）と連携させると効果が跳ね上がります。TIPやフィードから配信されるIoCをSIEMの検知ルールへ自動反映すれば、新たな不正IPやドメインを人手を介さず監視対象に加えられます。「siem 脅威インテリジェンス」という検索が一定数あるのは、この連携運用に関心が集まっているためです。手動更新では鮮度が落ちる技術的インテリジェンスを、自動連携で活かしきる設計が現場の負荷削減に直結します。

代表的な商用ツールと選定時に比較すべき4つの観点

商用ツールは情報の質や得意領域が異なるため、複数観点での比較が欠かせません。代表的な製品にはRecorded Future、Google Threat Intelligence、CrowdStrike Falconなどがあります。選定時は次の観点で整理すると判断しやすくなります。

機能の多さより、自社が実際に消費できる範囲かどうかを軸に絞り込むことが、過剰投資を避ける鍵になります。

STIX／TAXIIなど脅威情報共有の標準フォーマット

ツール間や組織間で脅威情報をやり取りするには、共通の形式が必要です。STIXは脅威情報を構造化して記述する標準フォーマットで、TAXIIはそれを安全に交換するためのプロトコルです。ISACや商用フィードの多くがこれらに対応しているため、自社が導入するツールが標準形式に対応していれば、情報源の追加や乗り換えが容易になります。独自形式に依存すると将来の拡張で手戻りが生じるため、標準対応の有無は選定段階で確認しておく価値があります。

ツール導入だけでは満たせない運用体制という前提条件

注意したいのは、ツールを入れれば5.7を満たせるわけではない点です。TIPやフィードが配信する情報も、それを読み解き、自社該当性を判断し、対応へ展開する人とプロセスがなければ宝の持ち腐れになります。審査でも問われるのは製品名ではなく運用実態です。まず手順と役割を固め、その運用を効率化する手段としてツールを位置づける順序が、投資を成果に変える前提条件になります。

内製と外部委託（MSS・専門組織5.6連絡）を分けるISMS運用の判断基準

すべてを自前で抱える必要はなく、内製と委託の線引きをどこに置くかが運用の成否を決めます。

自組織で内製する場合に必要なスキルと工数の見積もり

内製を選ぶ場合、情報源の監視・IoCの分析・自社該当性の判断・対応指示までを担える人材が要ります。脆弱性情報の読解や攻撃手法の分析は専門性が高く、片手間では精度が出ません。最低でも週次で情報を確認し、緊急時には即応する体制が前提になるため、専任または兼任担当の工数を現実的に見積もる必要があります。スキルと工数を確保できないまま内製化すると、運用が止まり形骸化する典型パターンに陥ります。

MSS（マネージドセキュリティサービス）へ委託する範囲の決め方

MSS（マネージドセキュリティサービス）は、監視・分析・通知を専門事業者が代行するサービスです。委託範囲は「監視と一次分析まで」「対応指示まで」など段階で選べます。自社に専門人材がいない場合は監視・分析を委託し、最終的なリスク判断と対応決定は自社に残す切り分けが現実的です。委託しても、得た情報を自社のリスクアセスメントへ反映する責任は残るため、報告を受けて判断する社内の窓口は必ず設けます。

管理策5.6「専門組織との連絡」と5.7の補完関係

5.7は単独ではなく、5.6「専門組織との連絡」と一体で考えると実装しやすくなります。脆弱性情報の収集や攻撃手法の分析には高い専門性が必要な領域があり、規格自体も専門組織から情報を得ることを選択肢として認めています。IPA・JPCERT/CCやセキュリティベンダーとの連絡体制を5.6で整え、そこから得た情報を5.7の収集・分析に流し込む——この補完関係を設計に織り込むと、限られた自社リソースでも5.7の要求を満たしやすくなります。

コストとリスク低減効果から見た内製・委託の判断表

内製と委託は、自社の規模・人材・守るべき資産価値で最適解が変わります。判断材料を整理すると次のようになります。

多くの組織は「監視・分析は委託、判断は内製」のハイブリッドに落ち着きます。

中小組織がスモールスタートで委託を活用する手順

中小組織は、いきなり高度な体制を目指さず段階的に立ち上げるのが得策です。まずIPA・JPCERT/CCの無償購読と週次確認のルール化から始め、担当と頻度を決めます。次に運用が回り始めた段階で、監視や一次分析をMSSへ委託して手薄な時間帯を補います。最後に守るべき資産の重要度が高い領域だけ商用フィードを足す、という順序です。この段階設計なら、初期コストを抑えつつ審査で問われる「継続的な運用」を無理なく示せます。

ISMS移行審査で確認される管理策5.7の運用証跡と文書化の具体例

5.7対応の成否は、最終的に審査で「運用している証跡」を示せるかに集約されます。

審査員が5.7で確認する「誰が・いつ・どのように」の手順化

移行審査では、新規管理策が適切に運用されているかが重点的に確認されます。5.7で問われるのは、誰が・どのタイミングで・どのように情報を収集し、分析し、周知し、対応へつなげるのかがルール化・手順化されているかです。口頭で「IPAを見ています」と答えるだけでは不十分で、手順書として明文化され、その通りに運用された記録が伴っている必要があります。担当者・頻度・情報源・判断の流れを1枚の手順に落としておくことが、審査対応の出発点になります。

適用宣言書（SoA）への5.7の反映と記述のポイント

附属書Aの全面改訂に伴い、適用宣言書（SoA）の更新は必須です。5.7については「適用する」と宣言したうえで、適用理由と実装方法を具体的に記述します。「最新の脅威情報を収集・分析し、リスクアセスメントへ反映する」といった抽象表現にとどめず、参照する情報源や運用頻度まで踏み込むと、審査での説明がスムーズになります。SoAと実際の手順書・記録が整合していることが、文書管理の観点で重要です。

収集・分析・共有を示す記録様式と報告書の具体例

運用していることを示すには、活動の記録が欠かせません。具体的には次のような証跡が有効です。

• 収集した脅威情報の一覧（情報源・取得日・概要を記載した台帳）
• 自社該当性を判断した分析メモや会議議事録
• 関連部門への周知記録（メール・社内通知の控え）
• 脅威情報を受けて実施した対応の記録（設定変更・パッチ適用の履歴）

様式は凝る必要はなく、継続して埋まっているかが評価されます。

リスクアセスメントへ脅威情報を反映した証跡の残し方

5.7の核心は、集めた情報をリスクアセスメントのインプットに使うことです。したがって、ある脅威情報をきっかけにリスク評価を見直した、あるいは新たなリスクを登録した、という形で記録が残っていると説得力が高まります。たとえば「業界向けの新たな攻撃キャンペーンの情報を受け、該当リスクの評価を再実施し対策を追加した」という一連の流れを残せば、収集から活用までが回っている証明になります。情報と判断のひも付けが、形だけの収集との違いを示します。

形骸化と判断されやすい不備パターンと回避策

審査で指摘されやすいのは、収集はしているが分析・活用の記録がない、手順書はあるが実運用が伴っていない、担当が不在で更新が止まっている、といった形骸化のパターンです。回避策はシンプルで、収集の頻度を現実的な水準に設定し、分析と判断を必ず記録に残す運用を最初から組み込むことです。無理に高頻度・広範囲を狙うより、確実に回る最小の運用を定義し、それを継続する方が審査では高く評価されます。

8.8技術的脆弱性管理・8.16監視活動と連携させる5.7の統合運用設計

5.7を孤立させず関連管理策と束ねることで、同じ労力からより大きな効果を引き出せます。

5.7と8.8技術的脆弱性管理を連動させる脆弱性トリアージ

5.7で得た脆弱性情報は、8.8技術的脆弱性管理のインプットとして直結します。新たに公開された脆弱性が自社の利用製品に該当するかを判定し、深刻度と悪用状況を踏まえて対応の優先順位を決めるトリアージが、両管理策をつなぐ実務です。たとえば7-Zipの脆弱性のような個別の注意喚起を受けたら、該当バージョンの利用有無を確認し、影響があれば速やかにパッチ適用へ動きます。脅威インテリジェンスが「気づき」を、脆弱性管理が「対処」を担う関係です。

8.15ログ取得・8.16監視活動へ脅威情報を供給する流れ

技術的インテリジェンスのIoCは、8.15ログ取得・8.16監視活動と組み合わせて初めて検知力になります。判明した不正IPやドメインを監視対象に加え、取得済みのログと突き合わせれば、過去にさかのぼって侵害の痕跡を探せます。5.7が供給する最新の脅威データを、8.16の監視ルールへ継続的に流し込む設計にすると、検知の精度が脅威環境の変化に追従します。情報を集める管理策と、それを使って異常を見つける管理策を一本の流れにすることが要点です。

5.23クラウドサービス利用と脅威インテリジェンスの接点

同じ新規管理策である5.23クラウドサービスの利用における情報セキュリティとも接点があります。クラウド事業者を狙う攻撃や設定不備に起因する漏えいの情報は、5.7で収集すべき脅威の一部です。利用中のクラウドサービスに関する脆弱性や攻撃情報を監視し、事業者の対応状況と自社の設定を点検する運用は、5.7と5.23をまたいで成立します。クラウド前提の環境では、この二つの管理策を切り離さずに設計する視点が欠かせません。

脅威ハンティングと脅威インテリジェンスを統合するメリット

脅威インテリジェンスを脅威ハンティングと統合すると、受け身の防御から能動的な探索へ踏み出せます。脅威ハンティングは「侵害されている前提」で痕跡を探す活動で、インテリジェンスが示す攻撃者のTTPやIoCが、どこを・どう探すかの指針になります。両者を統合する利点は、既知の検知ルールをすり抜けた攻撃を発見できる点にあります。高度な取り組みのため全組織に必須ではありませんが、守るべき資産が大きい組織では投資価値の高い発展形です。

単独運用を避け統合設計で投資対効果を高める方針

5.7を独立した「やることリスト」として扱うと、収集だけが目的化し形骸化しやすくなります。本来は、5.6専門組織との連絡で情報を得て、5.7で分析し、8.8・8.15・8.16で対処・検知し、5.23でクラウド領域を補完する——という一連の運用の起点に位置づけるのが合理的です。管理策を線でつなぐ統合設計にすれば、同じ情報収集の労力が複数の管理策の要求を同時に満たし、結果として投資対効果が高まります。

よくある質問

脅威インテリジェンスとISMS（管理策5.7）について、検討段階で問い合わせの多い点をまとめました。

脅威インテリジェンスとは何ですか？

脅威インテリジェンスとは、サイバー攻撃や脆弱性に関する情報を収集・分析し、自組織のリスクを認識して適切な対応につなげるための取り組みです。単なる情報収集ではなく、集めた情報を分析し、社内で共有し、対策に活かすまでの一連の活動を指します。ISO/IEC 27001:2022では附属書Aの管理策5.7として明文化され、戦略・戦術・運用・技術の4つの層に整理して扱うのが一般的です。

脅威インテリジェンスはISMSのどの管理策にあたりますか？

ISO/IEC 27001:2022（JIS Q 27001:2023）の附属書A、組織的管理策の項番5.7「脅威インテリジェンス」が該当します。2022年版の改訂で新規追加された11管理策の一つで、5.6専門組織との連絡、8.8技術的脆弱性管理、8.16監視活動などと密接に関連します。これらと連携させて運用することが、効果と審査対応の両面で推奨されます。

ISO/IEC 27001:2022への移行期限はいつまででしたか？

2013年版から2022年版への移行期限は2025年10月31日で、この日をもって2013年版は失効しました。期限はすでに経過しているため、現在有効なISMS認証はすべて2022年版が前提です。また2024年5月以降の新規認証・再認証審査は2022年版で行われています。これから取得・維持を進める組織は、最初から93管理策を基準に準備することになります。

脅威インテリジェンスの情報収集は自社だけで行う必要がありますか？

必ずしも自社だけで行う必要はありません。規格でも、専門組織から情報を取得したり支援を受けたりすることが選択肢として認められています。IPAやJPCERT/CCの無償情報から始め、体制や守るべき資産に応じてMSS（マネージドセキュリティサービス）や商用フィードを組み合わせるのが現実的です。ただし、得た情報を自社のリスク判断に反映する責任は委託先に丸投げできないため、社内の判断窓口は必ず設けます。

中小企業でも管理策5.7に対応できますか？

対応できます。中小企業は、IPA・JPCERT/CCの注意喚起をメルマガ等で受け取り、週次など定期的に確認して自社該当性を判断するルールを決めるところから始められます。担当者・頻度・情報源・判断の流れを簡潔な手順書にし、確認と対応の記録を残せば、審査で求められる「継続的な運用」を示せます。必要に応じてMSSを部分的に活用すれば、限られた人員でも無理なく運用できます。

関連記事

• 国内大手企業を襲ったサイバー攻撃・ランサムウェア被害の解説：5.7が求める脅威分析の対象となる、実際の被害事例として参考になります。
• CVEとは｜共通脆弱性識別子の仕組み：技術的な脅威情報源の基礎であり、5.7と8.8をつなぐ脆弱性管理の起点になります。
• 7-Zipの脆弱性に関する解説：脆弱性インテリジェンスを受けたトリアージの具体例として活用できます。