変更要約: 初版
1.3セキュリティ運用の中核用語
脅威インテリジェンス（threat intelligence）・脅威ハンティング（threat hunting）・マルウェア解析・脅威アクター（threat actor）・リスクベース分析（RBA）・リバースエンジニアリング・スライディングウィンドウ・脅威モデリング・DevSecOpsという運用の中核用語を、「この状況で使うべき考え方・活動はどれか」という判断として学びます。
SOCの会話は専門用語で成り立っていますが、暗記した定義を並べても現場では役に立ちません。大事なのは「今この状況ではどの活動・どの考え方が適切か」を選べることです。アラートを待つ受動的な検知と、仮説を立てて能動的に探しに行く脅威ハンティングは別物ですし、限られた人手をどこに割くかはリスクベース分析（RBA）が導きます。この節では中核用語を、定義ではなく使いどころで結び付けます。
1.3.1知る・探す・分析する
- 脅威インテリジェンス（threat intelligence）＝攻撃者の手口・IoC・キャンペーン情報などを収集・分析して行動可能な知見にしたもの。「どんな相手が何を狙うか」を先回りするための入力になる。単なる生データではなく、文脈化・評価された情報である点が肝。
- 脅威ハンティング（threat hunting）＝アラートを待たず「もし侵害されていたらこの痕跡が残るはず」という仮説を立てて能動的に探索する活動。既存の検知ルールをすり抜けた潜伏脅威を掘り出す。受動的なアラート監視の補完であって置き換えではない。
- マルウェア解析（malware analysis）＝疑わしい検体のふるまい/構造を調べること。実行して挙動を見る動的解析（サンドボックス/検知チャンバ）と、実行せずコードを読む静的解析があり、後者の深掘りにリバースエンジニアリング（逆アセンブル等でロジックを復元）を用いる。
1.3.2相手・優先度・時間窓
- 脅威アクター（threat actor）＝攻撃を行う主体。愉快犯/ハクティビスト/金銭目的のサイバー犯罪者/国家支援（APT）/内部関係者など、動機と能力が異なる。相手の想定（誰が何のために）が、守るべき資産と現実的な脅威シナリオを絞り込む。
- リスクベース分析（RBA / risk-based analysis）＝限られたリソースを、発生可能性×影響度が高いところへ優先配分する考え方。すべてを等しく守ろうとせず、重要資産と現実的脅威に人手と対策を集中する。トリアージやパッチ優先順位付けの土台。
- スライディングウィンドウ（sliding window）＝一定幅の時間窓を少しずつずらしながらイベントを評価する手法。「直近5分間に同一送信元から100回失敗」のような期間内の集計/相関に使い、瞬間値では見えない持続的・段階的な攻撃（総当たり/スロー攻撃）の傾向を捉える。
1.3.3設計に織り込む
- 脅威モデリング（threat modeling）＝システムの設計段階で「どこが狙われ、何が起こり得るか」を体系的に洗い出し対策を先に織り込む活動（STRIDE等の枠組み）。作ってから守るのではなく、攻撃者視点で設計を評価して弱点を潰す。
- DevSecOps＝開発（Dev）・セキュリティ（Sec）・運用（Ops）を統合し、セキュリティをパイプラインに早期かつ継続的に組み込む（shift-left）文化/実践。リリース後にまとめて検査するのでなく、コミット/ビルド時に自動で脆弱性を検査し続ける。
「脅威インテリジェンス＝行動可能な知見／脅威ハンティング＝仮説を立てて能動探索（アラート待ちの補完）」「マルウェア解析：動的＝サンドボックス実行・静的＝リバースエンジニアリング」「RBA＝可能性×影響で優先配分」「スライディングウィンドウ＝時間窓の集計」「脅威モデリング＝設計段階で先回り」「DevSecOps＝shift-leftで継続検査」が頻出です。活動の使いどころで選び分けましょう。
あなたのSOCは、業界向けの脅威インテリジェンスフィードで「同業他社が、正規のリモート管理ツールを悪用して侵入し、数週間潜伏してからデータを抜く手口の攻撃者に狙われている」という報告を受け取りました。ここで受動的にアラートを待つだけでは、その攻撃者は既存ルールをすり抜ける前提なので手遅れになりかねません。適切な次の一手は脅威ハンティングです——インテリジェンスから「もし自社も侵害されているなら、正規管理ツールが普段と違う端末/時間帯で起動し、外部へ定期通信している痕跡が残るはず」という仮説を立て、EDRとログを能動的に探索します。探索の集計にはスライディングウィンドウが効きます（「直近24時間に、通常は管理端末以外で動かないツールが複数ホストで起動」を窓でカウント）。疑わしい検体を見つけたら、まず動的解析（サンドボックス）でC2先や永続化の挙動を掴み、難読化が強ければリバースエンジニアリングで内部ロジックを詰める。ただし全社の全端末を一度に精査する人手はないので、RBAで「顧客データを持つ重要資産＋インテリジェンスが示す手口に一致する端末」に探索を優先配分します。相手が誰か（脅威アクターの動機＝金銭目的の潜伏型か国家支援か）で、想定する潜伏期間や横展開のシナリオも変わります。そして根本対策としては、こうした「正規ツール悪用」の攻撃面を脅威モデリングで設計に洗い出し、管理ツールの使用を検知・制限する仕組みをDevSecOpsのパイプラインやポリシーに継続的に織り込む。ここでの判断の連鎖——インテリジェンスで知り、ハンティングで探し、RBAで優先し、解析で正体を掴み、モデリングとDevSecOpsで先回りする——が、用語を「使える道具」に変えます。
| 用語 | 本質 | 使いどころ |
|---|---|---|
| 脅威インテリジェンス | 文脈化された行動可能な知見 | 攻撃を先回りする入力が欲しいとき |
| 脅威ハンティング | 仮説を立てた能動的探索 | 既存ルールをすり抜けた潜伏を掘るとき |
| マルウェア解析 | 動的（サンドボックス）/静的（リバース） | 検体の正体と挙動を掴むとき |
| RBA | 可能性×影響で優先配分 | 限られた人手をどこに割くか決めるとき |
| 脅威モデリング / DevSecOps | 設計段階の先回り / 継続的検査 | 作る前・パイプラインで弱点を潰すとき |
ひっかけ： 「脅威ハンティングはアラートが上がってから対応する活動だ」は誤りです——ハンティングはアラートを待たず仮説を立てて能動的に探す活動で、受動的なアラート監視の補完です。また「脅威インテリジェンスとは集めた生ログそのものだ」も誤り＝生データを文脈化・評価して行動可能にした知見がインテリジェンスであり、未加工のログはその素材にすぎません。
1.3.4この節のまとめ
- 脅威インテリジェンス（行動可能な知見）で知り、脅威ハンティング（仮説を立て能動探索）で潜伏を掘る。ハンティングはアラート待ちの補完
- マルウェア解析は動的（サンドボックス）と静的（リバースエンジニアリング）。人手配分はRBA（可能性×影響）、期間集計はスライディングウィンドウ
- 脅威モデリングは設計段階で攻撃面を先回りし、DevSecOpsはshift-leftでセキュリティをパイプラインに継続的に組み込む
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 脅威インテリジェンスから「正規のリモート管理ツールを悪用して数週間潜伏する攻撃者が同業を狙っている」との報告を受けた。この攻撃者は既存の検知ルールをすり抜ける前提である。自組織の侵害有無を確かめる次の一手として最も適切な活動はどれか。
Q2. SOCは人手が限られており、数千台の端末すべてを同じ深さで監視・調査することはできない。どの資産と脅威に人手と対策を集中するかを決める考え方として最も適切なものはどれか。
Q3. 新しい社内Webアプリの開発が始まる。セキュリティチームは「リリース後にまとめて脆弱性検査する従来のやり方をやめ、設計段階で攻撃面を洗い出し、開発パイプラインで継続的に検査したい」と考えている。この方針を最もよく表す用語の組み合わせはどれか。