セキュリティ・キャンプ2026コネクト 脅威コースの設計について

IPAより、2026年3月26日～29日に開催されるセキュリティ・キャンプ2026コネクトの概要と参加募集要項が公開されました。

www.ipa.go.jp

今回、その中のクラスの一つ、脅威クラスのプロデューサ兼講師を務めさせていただくことになりました。この投稿では、プロデューサとしてどのような設計思想でコース策定をしたか、その考えを記載したいと思います。

セキュリティ・キャンプコネクトとは？

セキュリティ・キャンプコネクトとは、公式サイトにも記載されている通り、他分野とサイバーセキュリティの橋渡しをする人材として、従来の枠にとらわれない人材育成を目的にしています。

その中で、脅威クラスでは、「脅威×サイバーセキュリティ」をテーマにしています。

www.ipa.go.jp

具体的には以下の通りですが、特にサイバーセキュリティ空間における脅威は、多種多様にわたっています。そのため、脅威を包括的に学んでもらうというコンセプトでクラス設計を行っています。

サイバーセキュリティ上の問題は、常に「脅威主体」で行われます。
本講義では、脅威情報の収集・分析技法、および脅威自体の理解（攻撃者の理解）について、技術的・非技術的な観点から学ぶことで、セキュリティ対策/対応を進められるようにすることを目的としています。
前半では、サイバー空間における技術的な観点から外観を学ぶとともに、脅威分析手法、脅威に基づいてシステムを分析する脅威モデリングを学びます。
後半では、サイバー空間における偽情報や情報作戦、および情報心理学について学び、非技術的なサイバー空間上の脅威について学びます。
技術・非技術両方の観点から脅威情報の収集・分析技法について体系的に学びたい方にとって、実例を学びながらできる講義を行います。

脅威クラスの設計思想

今回の脅威クラスは、「2×2＋1」という軸を用いて設計しています。

まず、2×2の各軸は以下を意味します。

• 軸１：技術 － 非技術
• 軸２：マクロ － ミクロ

軸１：技術 － 非技術

サイバー空間における脅威は、いわゆるサイバー攻撃のような技術的な脅威だけではありません。近年では、偽情報の流布や情報操作といった非技術的な脅威も大きな影響力を持つようになっています。特に、誰もが自由に情報発信できる現代のサイバー空間において、偽情報は社会や政治、国際関係にまで影響を及ぼす重要な脅威の一つです。

そのため本クラスでは、「技術」「非技術」の両面から脅威を理解できるよう、以下の構成で講義を行います。

• Day2（27日）：技術的な脅威分析
• Day3（28日）：非技術的な脅威分析

軸２：マクロ － ミクロ

縦軸では、脅威をミクロとマクロの視点で捉えます。

技術的観点においては、

• 個別の攻撃手法や具体的な脅威に注目するミクロな分析を石川が担当します。
• 攻撃キャンペーンや攻撃グループといった単位で脅威を捉えるマクロな分析については、佐々木先生にご講義いただきます。

非技術的観点においては、

• 偽情報のメカニズムを理解するためには、個人と情報の関係、すなわち心理学的な理解が欠かせません。このミクロな視点については鈴木先生にお願いしています。
• それに対し、偽情報や情報作戦を社会・国家レベルで捉えるマクロな視点については、長迫先生にご講義いただきます。

国際関係と脅威分析

2×2の軸を通じて、「さまざまな視点から脅威にどう向き合うか」を学んだ上で、最後の「＋1」として位置づけているのが国際関係の視点です。

現代の脅威活動は、外交や地政学と強く結びついており、国際関係の文脈抜きには語れません。本講義の締めくくりとして、最も巨視的な視点である国際関係の観点から、サイバー空間上の脅威をどのように捉えるべきかについて、小宮山先生にご講義いただきます。

コース設計の３種類のこだわり

今回の「脅威クラス」は、上述した設計思想をもとに構成しています。初めての試みであり、現在も細部を詰めている段階ではありますが、「脅威」を包括的に理解する講座として、できる限りの要素を盛り込みました。

特に、以下の3点にこだわって設計しています。

こだわり①：複眼的思考を身につける

本講座では、脅威を単一の視点で捉えるのではなく、

• マクロな視点で全体像を見る「鳥の目」
• ミクロな視点で詳細を見る「虫の目」
• 時代や国際情勢の流れを捉える「魚の目」

これらを行き来できる複眼的思考を養うことを重視しており、講師の方々にも、複数の視点や分析手法を意識した講義をお願いしています。

こだわり②：ハンズオンで学ぶ

学んだ内容が「机上の空論」で終わらないよう、演習（ハンズオン）にも力を入れています。実際に手を動かして分析することで、理論の難しさや面白さ、そして脅威分析のリアルを体感してもらうことを狙いとしています。

こだわり③：ゼミ形式で学ぶ

本クラスは、講義を一方的に聞くだけではなく、ゼミ形式を意識しています。講義やハンズオンで得た知見をもとに、講師・参加者同士で議論し、理解を深めることを重視しています。

脅威分析には「唯一の正解」が存在しない側面もあります。だからこそ、新たな問いや課題を見つけ、講師・参加者とともに考えていく場にしたいと考えています。

お願い - ぜひ応募ください！

本クラスは、応募要件を満たす主に学生の方を対象に、無料で受講できる貴重な機会ですので、ぜひ積極的にご参加ください（応募要件や締切については、必ず公式サイトの情報をご確認ください）。

• エントリー締切：1月6日（火）
• 応募課題提出締切：1月13日（火）

「セキュリティ・キャンプ2026コネクト 脅威クラス」という名称かつ、応募要件にある通り、一定のセキュリティ学習経験や興味は前提となりますが、政治学や国際関係、心理学など、セキュリティ以外を主専攻とする学生の方にも広く参加いただきたいクラスです。少しでも興味を持っていただけた方は、まずはエントリーをお願いします。

また、残念ながら応募要件を満たさない方、特に社会人の方々には、本エントリーやブログ投稿をぜひ共有いただき、より多くの方に届くようご協力いただければ幸いです。

2025年度版：脅威ハンティング再考

最近、様々な企業・組織から「脅威ハンティング」について聞かれるケースが増えてきました。国家サイバー統括室（NCO）が発表した「サイバーセキュリティ 2025」でも「脅威ハンティングの実施拡大に向けた行動計画の基本方針の策定」と記載されており、民間企業でも大企業を中心に検討が進んでいる印象です。

その中で、少し自分の考え方を整理したので、その考え方をお話したいと思います。

脅威ハンティングとは？

脅威ハンティングの定義は様々ですが、個人的には良くSecureWorks社の定義を紹介しています（昔は、Sqrrl社の定義を紹介していたのですが、Amazonに買収されて以降アップデートも少ないのでこちらを紹介しています）。

To proactively and iteratively discover current or historical threats that evade existing security mechanisms, and to use that information to improve cyber resilience.

（日本語訳）

既存のセキュリティ対策を回避する現在/過去の脅威を能動的・再帰的に調査し、その情報を利用してサイバーレジリエンスを向上させること

この定義のポイントは、未知の脅威（＝既存のセキュリティ対策を回避する現在/過去の脅威）を探すという点です。

プロセスモデルと仮説構築の重要性

未知の脅威を見つけることは非常に難しいため、様々なプロセスモデルが用意されています。

• Sqrrl社 ：Hunting Loop
• CyberReason社 ：Threat Hunting 8 Steps
• SANS Institute ：SANS Threat Hunting Model
• SANS Institute ：Intelligence Driven Threat Hunting
• FI-ISAC NL ：TaHiTI（Targeted Hunting integrating Threat Intelligence）
• Splunk社 ：PEAK（Prepare, Execute, Act with Knowledge）
• zScaler社 ：TRACER（Telemetry, Refine, Analyze, Context, Escalete, Revise）
• Intel471社 ：INTEL471 Framework

各モデルの共通エッセンスを抽出すると、基本的には①仮説構築、②仮説検証、③事後処理という流れになるかと思います。

仮説構築の重要性

この中で最も重要な要素が仮説構築であり、仮説の作り方には、H.O.P.Eフレームワークというアプローチが有効だと思います。また、未知の脅威を見つけるためには、「仮説 → 検証」の科学的アプローチを採用しないと以下の危険性が出てきてしまうといわれています。

• 仮説構築（Hypothesis）  
• 調査対象（Object of Investigation）
• 調査方法（Procedure）
• 判断基準（Evaluation Criteria）  

問題１：終わりなき作業になってしまう

未知の脅威を見つけ出す作業は、「干し草の山の中から針を探す」作業になる可能性があります。そのため、どこで切り上げるか終了条件を定める上で、「仮説」を作ることは重要になります。

問題２：再現性がない作業になってしまう

優れたセキュリティエンジニアによる直観は脅威を見つける上で大事な要素だと思いますが、組織的に脅威ハンティングをする場合、誰がやっても同じ結果を出せる必要があります。その際には、きちんと「仮説→検証」という流れが重要になります。

問題３：悪性か否かの判断がアナリストの主観的判断になってしまう

扱うものが「未知」の場合、悪性か否かの判断が分かれる場合があります。もし「仮説構築」をしなければ、アナリストの主観的判断に大きく依存してしまう可能性があり、人により判断が揺らいでしまいます。その意味で判断をそろえる意味でも、仮説は重要な意味を持ちます。

更なる参考文献について

ここまでがこの話の前提でした。より詳しく脅威ハンティングを知りたい方は、以下の資料を参考にしてください。特に私の著作・資料では、脅威ハンティングの４種類のアプローチ（ABH、DBH、EBH、IBH）など複数のアプローチがあることなどを説明しています。

• 『脅威インテリジェンスの教科書』
• 『Handling Threat Intelligence』（JSAC講演資料）
• 『脅威ハンティング実践のすゝめ』

３種類に分類される脅威ハンティング

最近色々な方と話すと、脅威ハンティングの実践方法、捉え方は組織によって異なり、組織ごとに大きく３種類あるのではないか？と考えるようになりました。

1. ユーザ企業：「既知の未知」に対する脅威ハンティング
2. ベンダー企業：「未知の未知」に対するの脅威ハンティング
3. 国家機関：「意図」に注目した脅威ハンティング

ラムズフェルドのフレームワーク

まず、この「既知の既知」、「既知の未知」と「未知の未知」という考え方ですが、これはラムズフェルドのフレームワークとして知られるものです。

Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know.

（日本語訳）

何かが起こっていないと報告される事柄は、常に私の興味を引きます。ご存知のように、既知の既知、すなわち私たちが知っていると自覚している事柄が存在します。また既知の未知、つまり私たちが知らない事柄があることを認識していることも知っています。しかし未知の未知、すなわち私たちが知らないと自覚していない事柄も存在するのです。

端的にいえば、物事は、３種類に分類できるといっています。

• 既知の既知（Known Known）
• 既知の未知（Known Unknown）
• 未知の未知（Unknown Unknown）

「既知の既知」とは？

セキュリティの文脈で、セキュリティ監視が「既知の既知」に該当します。既に判明している既知の攻撃手法について監視しており、また「何を監視しているか？」については各組織は理解しています。

「未知の未知」に対する脅威ハンティング

まず、「未知の未知」に対する脅威ハンティングから解説していきましょう。

現時点では報告されていない「未知の未知」の脅威を検出するためのハンティングは、多くの場合セキュリティベンダー企業によって行われ、様々な攻撃手法（Capability）、脅威グループ（Threat Actor）が報告されています。一般的な仮説ベース（Hypothesis-Based）の脅威ハンティングのイメージはこれであり、「仮説構築」が有効なのもこのケースです。

「既知の未知」に対する脅威ハンティング

一方、「脅威ハンティング」はユーザ企業でも実施されています。一方、ユーザ企業側の脅威ハンティングの目的として、「未知の未知」の脅威を見つけたいのか？といわれるとそれは原則セキュリティベンダーに任せたいと考えているはずですし、セキュリティベンダーも脅威ハンティングサービスは提供しています。

一方、なぜ「脅威ハンティング」プログラムを実施するかというと、「既知の未知」を検出したい、言い換えれば自社のセキュリティ監視メカニズムでは検知できないが、世の中では知られている脅威を見つけ出したいという方針だと思います。そのため、仮説ベースの脅威ハンティングというより、入手した脅威インテリジェンスに基づいて実施する脅威ハンティングに相当します。

そのため、多くの場合TLPT（Threat Lead Penetration Test）やPurple Teamingとセットでこの活動が行われ、実施された疑似攻撃をもとに、実施された結果が検知可能か否か検証していくやり方をしているのが一般的です*1。そのため、Detection Engineeringに近い部分もあります。

「意図」に注目した脅威ハンティング

ここまで、「ラムズフェルドのフレームワーク」をもとに、ベンダー系企業、ユーザ系企業それぞれで実施された脅威ハンティングを説明してきました。ここまで説明してきた内容は、いずれも未知の攻撃手法を洗い出したい、自組織では検知できない攻撃手法を見つけ出したいといった攻撃能力（Capability）に注目したアプローチでした。

一方、現在議論されている能動的サイバー防御（ACD）を含め、政府機関では、別に攻撃手法を洗い出したいわけではなく、「重要なサイバー攻撃被害を未然に防ぐため、脅威を無害化する活動」を目的としているため、攻撃手法だけでなく、脅威の「意図」に注目し、分析する必要があります（Intent-Driven Approach）。そのため、利用する技術的アプローチに違いはありませんが、実施目的が異なるといえるでしょう。

まとめ

今回は、2025年度の状況を鑑み、脅威ハンティングが実運用上３種類の異なる考え方、目的で実施されていることについて検討してみました。脅威ハンティングを組織的に運用することは難しいですが、ぜひこうした考え方が参考になれば幸いです。

*1:もちろん、「既知の未知」を検知するため、自分でハンティングクエリを書くことも可能です。ただ、自分で書いたハンティングクエリが正しく正しく検知できるか検証するためには、検証環境を準備する必要があるため、手間がかかります。そのため、TLPTやPurple Teamingで実際に攻撃を試行し、それを正しく検知できるか検証する手法が最も合理的なアプローチになるといえるでしょう。

2025年度版：Strategic Intelligenceの取り扱いについて

最近、様々な場所で脅威インテリジェンスやそれに関する講演、議論をさせていただく機会を頂戴するのですが、その中の一つで、「Strategic Intelligenceをどのように実現すべきか？」という議論がよく持ち上がります。

中でも、よくある相談事項として、「Strategic Intellignece＝セキュリティニュース報告」になっており、本来報告すべき内容が報告できていないのではないか？という相談です。

実は『脅威インテリジェンスの教科書』を書いた際、この部分はかなり悩んでいました。

gihyo.jp

出版から３年以上たった現在でも、明確な解決策・指針があるわけではありません。

しかし、色々試行錯誤した結果、「セキュリティニュース報告でもやった方がStrategic Intelligenceとしての意味がある」と考えるようになりましたので、今回はその考えを書いてみたいと思います。

Strategic Intelligenceとは？

今回は、Strategic Intelligenceとインテリジェンスの基礎概念を振り返りながら、なぜ「セキュリティニュース報告」でも問題ないのか、考えを話してみたいと思います。

脅威インテリジェンスには、Tactical、Operational、Strategicと３種類に分類されます。

中でもStrategic Intelligenceは、「経営層向け」のインテリジェンスであり、「リスク変化に対するハイレベルな情報を提供することで、セキュリティに関する適切な意思決定・投資判断のインプット」を提供することを目的としています。

執筆当時は存在しなかったChatGPTに聞いても、以下のように答えてくれおり、おおむね理解としては間違っていないでしょう。

脅威インテリジェンスにおけるStrategic Intelligence（戦略的インテリジェンス）は、経営層や意思決定者が、組織のリスク管理・予算配分・セキュリティ戦略策定を行うために必要な長期的・高レベルの情報を提供するものです。

報告すべき項目は、以下のようにまとめられます：

• 1. 脅威のマクロトレンドと情勢
  • 国家支援型攻撃の増加傾向
  • 特定業界（例：金融、医療）に対する標的型攻撃の動向
  • 地政学的情勢がもたらすリスク（例：中国・ロシアの動き、中東情勢）
  • 先進的なTTP（戦術・技術・手順）の出現と拡散
• 2. 業界・地域別の脅威ランドスケープ
  • 同業他社における重大インシデントの概要と教訓
  • 業界団体やISACなどのレポートに基づく業界リスク
  • 日本国内／アジア地域における独自の脅威傾向
• 3. 攻撃者の動機と能力（Adversary Intent & Capability）
  • 攻撃者グループの目的（金融利益、諜報、破壊活動）
  • APTグループの関心領域と対象変化（例：防衛→保険）
  • 攻撃手法の高度化、例：サプライチェーン攻撃、AI活用型マルウェア
• 4. セキュリティ戦略に対する影響評価
  • 今後必要な投資領域（例：クラウドセキュリティ、ゼロトラスト）
  • 組織の脅威プロファイルに照らしたギャップ分析（例：重要資産が未保護）
  • 新たなレギュレーション（例：NIS2、DORA、SEC開示規則）への準拠課題
• 5. 将来予測と意思決定支援
  • 「今後1～3年でどのような脅威が顕在化するか」
  • 組織のレジリエンスを高めるための戦略的アクション案
  • 投資対効果（ROI）や優先順位づけの提案
• 6. サマリーとレコメンデーション

良い脅威インテリジェンスの条件（4A条件）

一方、良い脅威インテリジェンスの条件として、4A条件が挙げられます。これは、以下の４種類の条件の頭文字を取ったものです。

• Accurate（正確性）
• Audienced Focused（利用者目線である）
• Actionable（アクショナブル）
• Adequate Timing（適切なタイミング）

この時、Strategic Intelligenceで問題になってくるのが、Audienced Focused（利用者目線である）とActionable（アクショナブル）という2種類の条件です。

それぞれ具体的に見ていきましょう。

論点#1：Strategic IntelligenceのAudienceは誰なのか？

第一の論点は、Audienced Focused、つまり「経営層に何を伝えれば、（利用者にとして）有益なのか？」という点です。セキュリティニュースを数枚のBriefing Paperにまとめている人は、「経営層目線でに役立つ情報を渡せているのか？」という点で疑問を感じているため、この議論が出ると考えています。

この議論で重要となるのは、「Strategic IntelligenceのAudience（利用者）って誰なのか？」を明確化する必要がある点です。ご存じの通り、経営層といっても色々な種類の人がおり、報告内容が異なります。

ここでは、２×２のマトリックスで整理をしておきましょう。

上記のマトリックスが示す通り、一般的な経営層は大きく４種類に分類されます。当然、それぞれの役職により詳しさが異なります。

• CISO（Chief Information Security Officer）：
  • IT・セキュリティに詳しい人
• CIO/CTO（Chief Information/Technology Officer）：
  • ITに詳しい人（セキュリティへの理解度は人による）
• CRO/CCO（Chief Risk/Compliance Officer）：
  • （法律面・規定類などの意味で）セキュリティに詳しい人
• その他の経営層（CEO）：
  • IT・セキュリティともに詳しくない人

CISOに対しては、当然の攻撃手法や現在のセキュリティ態勢状況など詳しく説明すべき一方、その他の経営層に対しては、それぞれが持ち合わせる知識レベルに対し、報告していく必要があります。

以後の論点では、基本的にCISO以外への報告を前提にお話をしていきますが、その意味でその多くはセキュリティに詳しくない人を対象にしていく形となります（CROは、リスク管理や規定類、法律などの観点でセキュリティに詳しい人ですが、技術的に詳しい人ではありません）。

論点#2：Strategic Intelligenceは「Actionable」であるべきか？

第２の論点はActionable、「経営層の意思決定に役立つ情報を提供できているのか？」という点です。確かにセキュリティニュースを提供しても約90%の場合、何か意思決定につながることは少なく、果たしてStrategic Intelligenceとして価値があるのかという疑問が出るのは当然かと思います。

「Actionable = Wartime」という前提条件

個人的に試行錯誤した結果、提唱する4A条件と矛盾しますが、個人的には「Strategic Intelligenceは一定の条件を満たす限り、Actionableでなくて良い」と考えています。言い換えれば、セキュリティニュース報告でも十分に意味を持つと考えています。ここでいう「一定の条件」とは、報告している状況が「平時（Peacetime）」であるという点です。

基本的に、脅威の攻撃手法などは日々変化していますが、（CISO）を除いた経営層やシニアリーダーシップ層に何か予算・全体の変更など何か決断してもらうような「Actionable」な状況は、一般的に「有事（Wartime）」だと言えるでしょう。例えば、「コロナ禍におけるリモートワーク実施やリスク受容判断」、「特定の脆弱性の悪用を防ぐため、システムの一次停止の判断」などは、基本的に有事なので経営層に意思決定（決済・決定）を求める必要があります。

言い換えれば、Actionableな報告がないことは、それは「平時」ということであり、その意味で普段はActionableである必要がないと思います。

セキュリティニュースを提供するメリット：

また、上記を踏まえた上で、平時でもセキュリティニュースを定期的に報告することには大きく３種類ぐらいのメリットがあるといえます。

メリット#1：Situational Awarenessの構築

Situational Awareness（状況認識）といえばかっこいいですが、要は「サイバーセキュリティに対する健全な危機感の醸成」です。CISO以外の経営層にとって、セキュリティは数ある経営課題の一つにすぎず、常に考えているトピックではありません。気づけば、忘れられたり、ニュースをきっかけに急に温度感が挙がることもあるでしょう。

その際、定期的なセキュリティニュース報告は、温泉を42度に保つのと同様、「セキュリティの温度感を適温にしておく」上で非常に重要な活動になります。常日頃からこうしたニュースに接していれば、温度感が急上昇・急降下避けやすくなります。

また、人間は「変化に適応するのが得意」なわけではなく、それは経営層も同じです。そんな中、いきなり有事に大きな変化を報告すれば、「なんでそんなことになっているんだ？」という反応になるケースもあるでしょう。こうした拒否反応にならないよう、日頃からサイバーセキュリティに対する適切なメンタルモデルを構築する上でも、こうした定常報告は意味を持ちます。

メリット#2：教育的意義

教育的意義というとおこがましいですが、こうした定期報告は、セキュリティを知る上で必要な情報（例えば、二要素認証）をインプットするきっかけとしてもいいきっかけです。某インシデントの際、経営陣が「二段階認証」を知らないことで話題となりましたが、こうしたセキュリティの重要キーワードについて説明する上でも非常に良い機会になると思います。

メリット#3：関係性の構築

定期的な報告は、役員への関係性の構築にも役立ちます。CISO Mindmapの一つにも挙がっていますが、Security Team Brandingはセキュリティチームがやるべき仕事の一つです。

rafeeqrehman.com

具体的には、セキュリティが組織の目標に合致しているかどうか、セキュリティチームがどのような付加価値を組織にもたらしているか、説明する義務があります（一般にセキュリティはコストセンターなので、こうした付加価値を示さないと予算・採用などにも影響します。そのため、こうした定常的にセキュリティニュースを報告し、また可能であれば内部のセキュリティ態勢をKPIなどを用いて報告することで、存在意義や活動状況を示すことが可能です。

また、関係性の構築が進めば、急な質問が飛んでくることも減らすことができるケースも存在します。たとえば、某新聞が、「APT XXXにより...」と報じた際には、経営層から質問が飛んであたふたすることになるでしょう。しかし、定期的に報告をするスキームを構築しておけば、せっつかれなくなったケースもあるもあるでしょう*1。

まとめ

今回は、Strategic Intelligenceでよくある課題に対し、一つの考え方を示しました。Strategic IntelligenceはまだBest Practiceが定まっていない分野の一つであり、各社そのやり方に悩んでいる方も多いと思います。ここで示した考え方が参考になれば幸いです。

*1:せっかちな経営層はどこにでもいるので、理屈通りにいかないケースも多分にあります

『基礎からわかるDetection Engineering』の連載が終わりました！

先日発売された『Software Design 2025年3月号』をもって、全８回構成の『基礎からわかるDetection Engineering』の連載が終了しました。

本日（2月18日）は、『Software Design 2025年3月号』の発売日です。
先日よりお伝えしていた、「コードエディタ大研究」を総力特集でお送りします。

・拡大版大特集「コードエディタ大研究」
　［Part1］人気のエディタの魅力を深掘り
　［Part2］エディタを極める理由

・特別企画「containerd… pic.twitter.com/0TAbKJvFA9

— SoftwareDesign (@gihyosd) 2025年2月18日

2024年8月号から連載を開始したのですが、あっという間に駆け抜けた８か月＋αでした。

本ブログでは、簡単に振り返り（　をしたいと思います。

どんな連載をしたの？

連載の概要は、以下の通りです。

Detection Engineeringの定義やプロセス、「Detection as Code」の具体的な実装方法、検知ルールの評価技法、CI/CDへの統合などDetection Engineeringを考える上で必要な要素を解説できたと感じています。

第１回	Detection Engineering の理論と概論	Detection Engineeringの定義、必要性、特徴を説明するとともに、脅威インテリジェンス、パープルチームなど、関連する概念と比較してDetection Engineeringの位置づけを説明しました。
第２回	Detection Engineeringプロセス	Detection EngineeringプロセスであるDR-DLCプロセス（特定、方針策定、作成、テスト、リリース、展開、実行、モニタリング）の各フェーズを紹介しました。
第３回	Detection as Code――YARA	YARAの文法・応用手法について、具体例を使いながら説明しました。
第４回	Detection as Code――SIGMA	SIGMAの文法、応用手法について、具体例を使いながら説明しました。
第５回	検知ルールの評価と Detection Engineering Program①	良いDetection Engineering Programを示す３種類の指標を示すとともに、「検知」に関連する各種概念（検知スペクトラム、検知ドリフト）、検知ルールの3種類の拡張技法について説明しました。 また、3M+Cフレームワークとその特徴について説明し、メトリクスとモニタリングについて解説を行いました。
第６回	検知ルールの評価と Detection Engineering Program②	TTPsとMITRE ATT&CKフレームワークを説明するとともに、メンテナンス、継続的検証について解説しました。また、Detection Engineering Programを改善するための成熟度メトリクスの紹介を行いました。
第７回	CI/CDパイプラインによる自動化	Detection EngineeringでCI/CDパイプラインが必要になる理由を示すとともに、具体的な実装手法やハンズオン事例を示しました。
第８回	Detection Engineeringのまとめと補論	Detection Engineeringの理論を総括するとともに、MITREが発表した「Summiting the Pyramid」理論について説明しました。

執筆のきっかけは？

もともと、Detection Engineeringについて興味があり、海外書籍や海外講演を中心に研究を進めていたところ、Software Designの編集者の方より、連載の機会をいただき、執筆することができました。

研究をしていく中で、「この本/講演のこの部分は重要だな（あるいは、納得できないな）」とか「この考え方Ａと考え方Ｂは一緒に整理したほうがわかりやすそうだな」とか色々と整理できたため、試行錯誤しながらDetection Engineeringについて体系的に言語化できたことは非常にありがたい機会でした。

執筆の大変さは？

雑誌連載は今回初めてだったこともあり、実際の執筆の大変さは想像以上でした。

NFLabs.のブログと同じように、筆者も「まぁ連載といっても1ヵ月スパンだし全然余裕あるでしょう」と高を括っていましたが、本当に大変でした（このブログを事前に読んでもなお、高をくくっていました。締切ギリギリになり、関係者の皆様本当にすいませんでした）。

blog.nflabs.jp

大変だった理由は、個人的には大きく３つあります。

（１）限られた執筆時間

第一に書籍などと比較して執筆時間が短いことが挙げられます。改めて本・論文・講演などを見直しながら記載したため、締切を踏まえると執筆に充てられる時間はどうしても限られてしまいます。また、上記のNFLabsのブログでも詳しく解説されていますが、基本的に記事が書き終わると次の記事の準備を始めないといけないので、学生の実験レポート提出モードになっていました*1（小学生みたいな感想ですが、「週刊連載を持つ漫画家・小説家って本当にすごいんだな」と改めて思いました）。

（２）限られた紙面

第二に、8~10ページの紙面に一つのテーマについて過不足なく盛り込むことの難しさです。雑誌の特徴として、紙面が限られている、図・表を挿入できるスペースも限られたという制約がある中で、テーマを正確に伝えるのは特に難しい作業でした。特に仕事が落ちついて余裕があるときほど、色々盛り込みたい内容がでてきてしまい、大量に書きすぎて、後々整合性を担保しながら泣く泣く削る、何が伝えたいかぼやけた文章が多いなど、校正作業が大変でした。

（３）世間の関心度?

「記事を書くからには、読んでもらいたい」というのが執筆者全員の本音だと思うのですが、Detection Engineeringという分野にどこまで世間で関心を持たれているのか著者自身もわかっていない部分があり、ぼっち・ざ・ろっく！のワンシーンにもあるように「雑誌の読者に不快感を与えたで賞」*2をいただかないか正直不安でしたが、雑誌の最後にある「Reader's Link」（感想・お便りコーナー）で「おもしろい」といった反応をいただけたことは筆者としては非常にうれしい限りでした。改めて、感想寄せていただいた皆様、ありがとうございます。

おわりに

今回初めて連載記事に取り組んでみましたが、あっという間の８か月でした。Detection Engineeringはこれからも関心がもたれる分野だと思いますので、ぜひこの記事が皆様の参考になれば幸いです。

また、Detection Engineeringの概要については、『2025年 TMCIT × 大和セキュリティ DFIR忍者チャレンジ 開催』で講演した資料を公開しておりますので、興味がある方はこちらもご覧ください（そして、更に深く知りたいことはぜひ記事を読んでください！）

speakerdeck.com

また、最後に、本連載の執筆にあたり編集、デザイン、校正など、様々なサポートをしていただいた技術評論社様にはたいへんお世話になりました。この場を借りてお礼申し上げます。

*1:毎回かなりドタバタだったので、改めて松尾先生が書かれた論文『なぜ私たちはいつも締め切りに追われるのか』を読み直そうと思います。

*2:元ネタ：https://x.com/mangatimekirara/status/1582206339102650368

10/19に翻訳書『マスタリングAPIアーキテクチャ』が発売されます。

10/19に翻訳本『マスタリングAPIアーキテクチャ モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法』（オライリージャパン）が発売されます。

www.oreilly.co.jp

筆者の手元には、見本も届きました。

本書は、James Gough氏、Daniel Bryant氏、Matthew Auburn氏が執筆した『Mastering API Architecture: Design, Operate, and Evolve Api-Based Systems』の翻訳本です。本書は、APIアーキテクチャに関する考え方を実例を踏まえながら、網羅的かつ簡潔に解説しており、APIアーキテクチャにこれから携わる方にはおすすめの一冊です。

以下、筆者のオススメポイントを解説させていただきます。

ポイント#1：実例を通して網羅的に学ぶことができる

APIアーキテクチャ技法を学ぶためには、理論を理解しつつ、それを実務に応用しなければなりません。実際、APIアーキテクチャや設計については、筆者が知る限りでも様々な良書があります。

• マイクロサービスアーキテクチャ 第2版

• モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

• 進化的アーキテクチャ ―絶え間ない変化を支える

• 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発

• Web APIの設計

• Web APIテスト技法

• 実践マイクロサービスAPI

• Web API設計実践入門──API仕様ファーストによるテスト駆動開発 Web＋DB PRESS plusシリーズ

本書の特徴は、カンファレンスシステムという具体的なシステムを軸として、サービス指向アーキテクチャ、マイクロサービス、進化的アーキテクチャ、アジャイルテストの４象限、テストピラミッド、ADR、C4、REDメソッド、6Rなど様々な理論・概念をどのように応用すべきか実際のユースケースとともに明確な指針を示してくれます。

読者が扱うシステムの要件や内容はこの例とは異なるかもしれませんが、本書で紹介されているアーキテクトとしての思考プロセスやマインドセットは、どのようなシステムにも応用できるものです。そのため、アーキテクトとして活躍する読者には最適な1 冊になると考えています。

本書の目次を以下に示します。この目次とともに、各章からどんなことが学べるか紹介します。

• イントロダクション
• 第1部　APIの設計・構築・テスト
  • 1章　APIの設計・構築・仕様化
  • 2章　APIのテスト
• 第2部　APIトラフィック管理
  • 3章　APIゲートウェイ：外部トラフィック管理
  • 4章　サービスメッシュ：サービス間トラフィック管理
• 第3部　APIの運用とセキュリティ
  
  • 5章　APIの展開とリリース
  • 6章　セキュリティ運用：脅威モデリング
  • 7章　APIの認証と認可
• 第4部　APIを利用した進化的アーキテクチャ
  
  • 8章　API駆動アーキテクチャへのアプリケーションの再設計
  • 9章　クラウド環境への移行
  • 10章　総括

各章について、何が学べるかは以下の通りです。

• イントロダクションでは、本書を通じて説明に使う「カンファレンスシステム」についての概況を示します。
• 第１部では、カンファレンスシステムを軸として、元のレガシーシステムから、APIとしてサービスを抽出し、設計、構築、テスト技法について学びます。
• APIはマイクロサービス化されるため、通信管理が重要となります。そのため、第２部では、外部トラフィック管理、サービス間トラフィック管理という２種類の管理手法について、具体的に詳しく学びます。特に、元のレガシーシステムから、どのようにトラフィックを分離していくか、既存システムへの影響を回避しながらAPIとして管理していくか、その技法を紹介しています。
• 第３部では、APIのリリース技法（APIライフサイクル、カナリアリリース、ブルーグリーン戦略）やリリースを評価するメトリクス、脅威モデリングやOAuth2などの各種セキュリティ技法を学びます。
• 第４章では、クラウド環境への移行に関する検討方法、API駆動開発について学びます。特に、API化とともにクラウドへの移行を考えることも多々あると思いますが、その際の考え方、評価基準などがわかりやすく解説されています。

ポイント#2：モノリスからの移行方法を実例を通して学ぶことができる

今回の題材が、カンファレンスシステムであることは既に述べた通りですが、より厳密にはレガシーシステム（モノリス環境）から、APIアーキテクチャ（マイクロサービス）へ移行していくことを題材としています。最初からAPIを構築できるケースもありますが、多くの場合、既存システムの拡張の中で、モノリスからマイクロサービスへ移行していくケースが挙げられます。実際、著者の２名がMorgan Stanley社のアーキテクトということで、24時間安定稼働を求められるシステムにおいて、レガシーシステムあからAPIへ移行していく開発実務経験が非常に良く盛り込まれていると感じています。

ポイント#3：アーキテクトの思考法に特化している

翻訳して本書が良いと感じたもう一つの点が、アーキテクトが持つべき思考法・マインドセットにフォーカスしている点で、可能な限り特定の言語・環境に依存しないような形で議論が進んで行きます。私は普段セキュリティアーキテクトという仕事をしており、開発プロジェクトのレビューや相談に対応することが多いのですが、どうしても環境はバラバラであり、アーキテクチャに共通する事象と開発固有の事象を分けてかんがえなければいけません。

本書では、その点もかなり意識して書かれており、技術的な議論をしっかりしつつ、アーキテクトが考えるべき観点をうまく抽出していることが本書の非常に良い点だと考えています。

非常に良い書籍なので、ぜひ書店やAmazonで手に取っていただけると嬉しいです！

マスタリングAPIアーキテクチャ ―モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法