dobybaxter127/nimbus-vestigeクラウドおよびアイデンティティインシデントレスポンスのためのフォレンジック再構築エンジン。
クラウドおよびアイデンティティのインシデント対応のためのフォレンジック再構築エンジン。
断片化されたクラウド、SaaS、アイデンティティのテレメトリ — コントロールプレーンログ、サインインイベント、トークンおよび同意アクティビティ — が与えられると、NV は侵入がアカウントやサービスをまたいでどのように移動した可能性が最も高いかを再構築し、取り得た他の最も可能性の高い経路を列挙し、すべてのステップを較正された説明可能な信頼度とともに報告します。証拠が裏付けられない事柄については断言を拒否します。
検出は何かが起きたことを教えてくれます。Nimbus Vestige はどのように — そして他に何が — を教えてくれます。
現代の侵入は「押し入る」ものではありません。ログインするのです。アイデンティティは今や主要な攻撃手段であり、クラウド IR 調査の大多数に関与しており、ほとんどの侵入は複数のサーフェス — アイデンティティ、クラウド、SaaS、エンドポイント — にまたがります。それらを記録するテレメトリは断片化され一貫性がないため、対応者は不完全なデータから手作業でストーリーを再構築することを余儀なくされています。
その手作業の再構築は遅く、予測可能な形で失敗します。対応者は最初のもっともらしい筋書きに固執し、本当の筋書きを見逃してしまうのです。NV は再構築を自動化し、単一のストーリーではなく、もっともらしい経路のランク付けされた空間を常に提示することで、その失敗モードに直接対処します。
重要なのは、NV がこれを誠実さそのものを製品として行うことです。市場が掲げる敵はブラックボックスの信頼度 — 作業内容を示さずに結論を断言するツールです。NV が生成するすべての数値は、それを獲得した特定の証拠まで追跡可能であり、裏付けられないものは推測するのではなく差し控えられます。
NV は検出器でも、スキャナでも、監査ツールでも、攻撃実行ツールでもありません。それらのツールは何かが起きたことを教え、それを測定します。NV は逆向きに動作します — 断片化されたアイデンティティ資産全体にわたり、パターンからメカニズムをアブダクティブに再構築するのです。
ブルーチームは再生し、レッドチームはコモディティ化する。 攻撃的ツールは有限でパッチ可能な穴の集合を見つけ出し、自動化された CI/CD 安全パイプラインへと吸収されつつあります。侵入がどのように起きたかを再構築することは決して解決しません — 攻撃者は発明を続けるため、その必要性は永続的かつ自己再生産的です。
エンジンは基盤に依存しない。 コアロジック — 較正された信頼度と停止レールを伴い、パターンからメカニズムを再構築する — はまずクラウド/アイデンティティにコミットされていますが、後にネットワーク、エンドポイント、OT へ移植されます。テーゼを書き換えることなく対象を変更できます。
再構築はハードニングを可能にする。 彼らがどのように侵入したか — そして他にどの扉が開いていたか — を知れば、防御を構築できます。取られなかったがもっともらしい経路はハードニングのバックログであり、多くの場合再構築そのものよりも価値があります。なぜならほとんどの侵害は目新しい手口ではなく、予防可能な露出を悪用するからです。
新規の侵入 — 最も重要なまさにそのインシデント — に対して優雅に縮退する。 シグネチャ/ルールエンジンはゼロデイで見えなくなりますが、NV のアブダクティブコアは依然として最も可能性の高い経路を生成し、より低い信頼度として誠実にフラグを立てます。
誠実さは堀である。 ランク付けされた代替案を伴う較正されたケースベースの信頼度は、まさに市場が求めていると述べているものであり、ブラックボックスの競合他社が再設計なしには構造的に提供できないものです。
生のプロバイダログ → 正規化されたイベント/エンティティグラフ → 再構築エンジン → JSON → GUI。
O365 / Entra audit logs nv_extract_identity_events.py
AWS CloudTrail (IAM/STS/S3) nv_extract_cloudtrail_events.py (ingest + normalize)
▼
normalized identity events (JSONL) ← one event model, any substrate
│ nv/graph.py (typed per-actor timelines)
▼
reconstruction engine
├─ nv/patterns.py known layer: ATT&CK identity pattern library
├─ nv/providers.py provider packs: per-substrate op→ATT&CK vocab (Entra + AWS)
├─ nv/validation.py Phase 3: provenance + integrity gate on every pattern
├─ nv/feeds.py live ATT&CK STIX / TAXII / Sigma clients + scheduler
├─ nv/confidence.py evidence-corroboration scorer (calibratable weights)
├─ nv/calibration.py fit + measure confidence against labeled ground truth
├─ nv/reconstruct.py most-likely chain + ranked competing paths + trust floor
└─ nv/scope.py authorized-scope gate (refuses unauthorized tenants/accounts)
│ run_nv.py
▼
reconstruction.json ──► nv_gui.html (embedding canvas + two-column view + trust slider)
GUI は純粋なビュー層であり、エンジンの出力を描画し、アナリストが信頼の下限を移動できるようにするだけです。それ自体には再構築ロジックは一切含まれていません。
すべてのステップは [0, 1] の範囲の信頼度を持ち、証拠の裏付けによって構築されます:
confidence = per-technique base rate
+ bonus for each independent corroborating signal
(source IP, device, successful outcome, temporal adjacency, broad-consent flags)
− penalty for missing signals (e.g. no source IP to corroborate origin)
パスのスコアはリンクを幾何平均で合成するため、1つの弱いリンクが平均化されて消えるのではなく、正直にパス全体を引き下げる。
上記のすべての重み — テクニックごとの基準率、シグナルごとのボーナス、欠落ペナルティ — は nv/confidence.py 内の単一の PARAMS テーブルに存在する。これらはNVのv1事前分布であり、キャリブレーション可能である。nv/calibration.py はラベル付きの正解データに対してそれらを再フィットでき、エンジンはその結果を読み込む。キャリブレーションが提供されない場合はv1事前分布にフォールバックする（以下を参照）。
withholdルールは、UIだけでなく、エンジンの出力契約に組み込まれている。下限を下回るステップはwithheldとなる。下限を動かすことは、誠実さとカバレッジのトレードオフを物理的に体現することである。厳格／高信頼には上げ、寛容／高カバレッジには下げる。デフォルトの下限は、アナリストが触れる前にNVがどこに位置するかについての編集上の決定である。
v1の重みは擁護可能ではあるが、事前分布にすぎない。nv/calibration.py はそれらをラベル付きの正解データ — どのイベントが侵入の一部で、どれが良性であったかを把握しているイベント — に対して調整し、さらに重要なことに、調整が実際に役立ったかどうかを測定する。したがってキャリブレーションは、単に数値を動かすのではなくキャリブレーション誤差を下げる場合にのみ採用される。
キャリブレーションされた信頼度が意味するのは1つのことである。あるステップに対するNVの信頼度は、そのステップが実際に攻撃パス上にあった確率に等しいべきである。そこで、各ラベル付きイベントの信頼度を予測確率として扱い、ハーネスは以下をフィットする：
verified/withheldのしきい値はポリシーでありキャリブレーションではないため、変更されない。
これはBrierスコア、log-loss、ECE、AUC、信頼性テーブル、そして信頼下限スイープ（各下限における真のステップの再現率と良性の偽陽性率）を、前後で報告する。これにより、誠実さとカバレッジのトレードオフが単一の数値ではなく読み取れるものになる。
# calibrate against a real, labeled BadZure / MAAD-AF run
python3 calibrate.py --labeled run_labeled.jsonl --origin live \
--run-label "badzure-2026-07 tenant-x" --out calibration.json
# demonstrate on the bundled documented-shape proxy corpus
python3 calibrate.py --out calibration.json
# run the engine on calibrated weights (opt-in; v1 priors are the default)
python3 run_nv.py events.jsonl out.json --authorize t.onmicrosoft.com \
--calibration calibration.json
グラウンドトゥルースのソース。 正直な入力とは、実際のテナントで BadZure / MAAD-AF を実行した際のテレメトリであり、統合監査ログを攻撃ツール自身のアクティビティ記録と突き合わせることでラベル付けされる（ツールが引き起こしたすべてのイベントはオンチェーンにあり、それ以外はすべて良性である — nv/calibration.py の LABELED_SCHEMA を参照）。実際の実行を指定するまでは、eval/calibration_cases.py が文書化された形状のプロキシコーパスを提供し、そこから適合されたすべての成果物はその来歴に source="proxy" と刻印されるため、プロキシによる適合がライブの適合と取り違えられることは決してない。calibration.proxy.json がその同梱のプロキシ成果物である。
同梱のプロキシコーパスでは、適合は明らかな改善を示す — Brier 0.398 → 0.045、ECE 0.576 → 0.081、AUC 0.81 → 0.91、そして 0.60 の下限における良性の偽陽性率は 0.69 から 0.00 へと激減する（v1 の事前分布は良性アクティビティに対してひどく過信していた）。プロキシは意図的に保守的であり、実際にデプロイすべき重みを生み出すのはライブテナントでの実行である。
2 つの第一級の制御が、再構築を不正な入力から保護する：
認可スコープゲート（nv/scope.py） — NV は認可リストにないエステートでは実行を拒否する。調査を許可されているエステートごとに --authorize <tenant-domain> を付けて実行すること。ゲートがどのエステートにも配置できない行（ドメインもテナントもアカウントも持たないアクター）も、スコープ内にあることを示せないため拒否される。それらの行の調査が許可されている場合に限り --allow-unscoped を渡すこと。それらは依然として出力に計上される。
パターンソースの検証（nv/validation.py） — いかなるパターンも以下を通過しなければライブラリに入らない：(1) 信頼済みソースの許可リスト、(2) 必須のコンテンツチェックサム、(3) スキーマの整形性、(4) 有効な ATT&CK 形式のテクニック ID。受け入れられたすべてのパターンは監査記録を保持し、拒否は理由とともにログに記録される。不正な、あるいはポリシー外のフィードエントリは、偽の再構築を捏造する前に上流で阻止される。これはエンジンが証拠に適用するのと同じ懐疑心を、パターン自体に移したものである。
チェックサムは整合性チェックである：パターンが構築されるときにそのパターン自身の内容から計算されるため、後から変更された内容（編集されたキャッシュやコミットされたライブラリファイル）を検出できる。ソースで汚染されたフィードを検出することはできない。そのためには、信頼するフィードペイロードの生の sha256 を update_feeds.py --pin URL=SHA256 で固定すれば、その URL にある他のペイロードは検証前に拒否される。
再構築エンジンは、そのパターンライブラリと、ライブラリが一度も見たことのないものを扱う能力の分だけしか最新でありえない。NV は設計上、2 つの独立した側面で陳腐化に対処する：
ライブラリはハードコードされていない — nv/patterns.py は（組み込みセットを含む）すべてのパターンを nv/validation.py を通じて読み込むため、外部フィードも同じ信頼済みの経路で入ってくる。これらのフィードをスケジュールに従って取得するライブネットワーククライアントは nv/feeds.py に実装され、update_feeds.py によって駆動される。ソースは信頼階層別に以下のとおり：