Skip to content

external-frameworks.md

Latest commit

 

History

History
173 lines (120 loc) · 7.66 KB

external-frameworks.md

File metadata and controls

173 lines (120 loc) · 7.66 KB

External Threat Frameworks

Documentation → More

This document explains how MCTS relates to industry MCP threat frameworks and Sigma rule corpora. MCTS uses its own first-party taxonomy but learns detection patterns from external research.

Looking for MCTS technique IDs? See Threat Taxonomy. Contributing detection rules? See Extension points.

In plain English

Several organizations publish catalogs of MCP-specific attack techniques (description poisoning, tool shadowing, rug pulls, etc.) with detection rules and mitigation guidance. MCTS:

  • Uses its own taxonomy (MCTS-T-* / MCTS-M-*) on all findings — not third-party IDs
  • Learns from external frameworks when designing new analyzers and detection patterns
  • Does not vend external rule corpora — they inform the roadmap, not the runtime

Think of external frameworks as the "textbook" and MCTS as the "exam" — frameworks describe what attacks exist; MCTS checks whether your server is vulnerable.

Framework vs scanner

Dimension External threat framework MCTS
What it is Threat intelligence catalog Automated MCP security scanner
Primary output Technique dossiers, Sigma YAML, mitigations Findings, scores, JSON/SARIF/HTML
Execution Reference artifacts and documentation CLI: mcts scan, inventory, fuzz
Answers "What attacks exist and how do they work?" "Does my server/config exhibit this risk?"

They are complementary: frameworks describe the threat space; MCTS operationalizes detection for MCP server authors at build and deploy time.

   Industry threat taxonomy
   (techniques, Sigma rules, mitigations)
              │
    patterns adapted into MCTS modules
              │
              ▼
         MCTS scan pipeline
              │
              ▼
   Findings with MCTS-T-* / MCTS-M-* IDs

MCTS reports use native IDs only

Scan output emits:

Field Format
technique_id MCTS-T-*
mitigation_ids MCTS-M-* list
cwe_id CWE when mapped in catalog

External technique IDs (from third-party corpora) are never written to findings. Maintainers may use informal crosswalks internally during gap analysis — those crosswalks are not part of the public report schema.

Pattern adoption in MCTS

Detection patterns from industry reference corpora were adapted into MCTS-owned modules:

Threat area MCTS modules Status
TPA / metadata poisoning tpa_patterns.py, prompt_injection, metadata_integrity, sigma_metadata Shipped
Homoglyph, Unicode tag block, mixed-script tpa_patterns.py Shipped
Recursive schema / FSP schema_fsp.py, schema_surface.py Shipped
Credential regex + semantic secrets data_leakage.py, embedding_secrets.py Shipped
Path traversal encodings path_traversal.py, fuzz payloads Shipped
Sigma metadata rules taxonomy/sigma/metadata_rules.json, --sigma-rules-path Shipped
OAuth misconfiguration oauth_config.py, runtime OAuth cluster Shipped
Rug pull / redefinition metadata_diff.py, tool_redefinition.py, --baseline Shipped
Supply chain signals supply_chain.py Partial
Cross-server escalation cross_server.py Shipped
Protocol robustness fuzz/, MCTS-T-1009 Shipped
Regression fixtures tests/fixtures/regression/MCTS-T-*/ Shipped (79 IDs)

When adapting external Sigma rules:

  1. Attribute upstream per license terms in commit messages or rule metadata
  2. Ship compiled rules under MCTS-owned paths only (taxonomy/sigma/, custom --sigma-rules-path)
  3. Map to MCTS-T ID before exposing in reports

Static vs runtime detection

Layer MCTS capability Typical external rule type
Static Source + tool metadata at scan time Metadata poisoning, schema rules
Live probe Runtime listings via stdio Tool manifest verification
Fuzz telemetry Protocol response analysis Error handling, crash detection
Runtime events file Imported probe logs OAuth, rug-pull, behavioral

Many industry Sigma rules assume runtime telemetry (tool_description, path, oauth_token, invocation logs). MCTS primarily performs pre-deployment static analysis plus optional live/fuzz layers.

Both are valid; they are not drop-in substitutes. Runtime rules must be adapted to metadata and source context when porting patterns into MCTS analyzers.

Gap analysis workflow for maintainers

When evaluating a new external technique dossier:

  1. Identify MCP boundary relevance — does it affect tool metadata, schemas, handlers, or protocol?
  2. Classify detection layer — static, live, fuzz, or runtime events?
  3. Assign or create MCTS-T ID — update techniques.json
  4. Implement analyzer or extend existing — register in core/scanner.py
  5. Add regression fixture — tests/fixtures/regression/MCTS-T-<id>/
  6. Document — update Threat Taxonomy

Roadmap priorities from threat density

Technique density in industry catalogs suggests MCTS expansion order:

Priority cluster MCTS modules / plans
Initial Access + Execution TPA, prompt injection, OAuth, command execution
Privilege Escalation Permissions, attack chains, cross-server
Persistence Rug-pull, metadata diff, baseline workflows
Exfiltration Data leakage, attack chains read→egress
Advanced runtime Behavioral probe, deeper fuzz, SSE/HTTP transports

See Feature Expansion Plan Part 4 for phased delivery.

Maintainer gap review (local only)

When evaluating new MCP security capabilities, maintainers run a structured gap review against the Feature Expansion Plan backlog. Detailed cross-tool file mappings and ecosystem matrices stay in a local-only audit — not published in this repository.

Workflow:

  1. Map capability → MCTS module or GAP theme
  2. Assign priority (P0–P3) using Part 11
  3. Implement with MCTS-T IDs — never vendor third-party IDs in SARIF
  4. Add regression fixture when detection lands

Do not copy external rule corpora or cloud-only flows into core OSS. Prefer SARIF/event export for runtime gateway partners.

What not to port blindly

External artifact Why caution
Runtime Sigma rules on static-only repos Log field names do not exist in source scans
Behavioral demo thresholds Tuned for conversation logs, not tool manifests
Attack PoC scripts Use as test vectors only — do not bundle into scanner
Immature technique drafts Wait for stable definitions before MCTS-T promotion
Vendor-specific IDs in SARIF Use MCTS-T only for consistent CI aggregation

Licensing and attribution

External Sigma rules and technique text may carry distinct licenses (e.g. Detection Copyright, CC BY-SA). MCTS ships adapted detection logic under the project Apache 2.0 license where original expression is not copied verbatim. When importing rule YAML, preserve required attribution comments in the rule file header.

Related