Skip to content

🌐 Introducing Threat Surface

Choose a tag to compare

@behemothsecurity behemothsecurity released this 09 Mar 19:38
· 64 commits to development since this release
8b706ec

A unified vocabulary to describe where threats land β€” replacing three legacy fields with a single, hierarchical, 900-entry taxonomy that connects Threat Vectors to organisational visibility.

The Problem

Threat Vector Models previously used three overlapping fields β€” platforms, targets, and domains β€” each with a flat vocabulary list and no structural relationship between them. This made it difficult to:

  • Precisely scope where a threat applies across OS, cloud, identity, protocol, and IoT boundaries
  • Automatically link threats to the assets an organisation actually operates
  • Identify detection blind spots when a threat targets infrastructure with no log source coverage

The Surface

The new surface field replaces all three with a single hierarchical taxonomy using :: scoped notation:

surface:
  - OS::Windows::Server 2022
  - Cloud::AWS::Compute::EC2
  - Authentication::Entra ID
  - Protocol::Application Layer::SMB

8 stages structure the entire attack surface:

Stage Entries Covers
Cloud 211 AWS, Azure, GCP, OCI, Alibaba Cloud, IBM Cloud, DigitalOcean
Application 155 Enterprise apps, browsers, CMS, file transfer, runtime environments, dev tools
Infrastructure 129 Firewalls, VPN, VMware, NAC, SD-WAN, remote access, monitoring, CDN, ICS/SCADA
Security 97 EDR/XDR, SIEM, NDR, ZTNA, SWG, SOAR, CASB, forensics
Protocol 95 Application, transport, routing, data link, wireless, industrial, auth, cellular
OS 87 Windows, macOS, Linux (20+ distros), BSD, container runtimes, RTOS
Authentication 63 Entra ID, Okta, CyberArk, SailPoint, Keycloak, FreeIPA, Duo
IoT 63 NAS, VoIP, UPS, smart home/building/grid, wearables, medical, automotive
Total 900

How it connects

                        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                        β”‚  🟠 Threat Surface       β”‚
                        β”‚     (vocabulary)         β”‚
                        β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                 references      β”‚       β”‚      references
               β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜       └─────────────────┐
               β–Ό                                           β–Ό
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”   surface overlap   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  πŸ”΄ Threat Vector      β”‚ ==================> β”‚  πŸ”΅ Asset              β”‚
  β”‚     threat.surface[]   β”‚   β†’ targeted asset  β”‚     asset.surface[]    β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                                             β”‚ monitors
                                                             β–Ό
                                                 β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                                                 β”‚  🟒 Log Source         β”‚
                                                 β”‚     logsource.system   β”‚
                                                 β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

A TVM targets surface entries; an Asset exposes surface entries. When they overlap (hierarchical prefix match), the asset is a targeted asset β€” tracing its log sources reveals detection visibility and blind spots.

Vocabulary Extensions

Instance-specific surface entries can be injected via schema.toml without modifying the core vocabulary:

[[vocabulary.surface]]
id = "03773d86-..."
name = "Authentication Provider ABC"
description = "Internal, Custom SSO"
"tide.vocab.stages" = "Authentication"

These appear in JSON Schema enums and IDE autocomplete alongside the 900 core entries.

Documentation

TVM documentation now includes a dedicated Threat Surface section:

  1. Surface entries β€” enriched display with vocabulary descriptions
  2. 🎯 Targeted Assets β€” intersects TVM surface with Asset surface using hierarchical prefix matching
  3. πŸ‘οΈ Detection Visibility β€” traces matched assets β†’ log sources and detectors; reports blind spots

Engine Improvements

EnumResolver refactor

The JSON Schema generation pipeline was restructured into a unified EnumResolver class with nested Fetch and Resolve inner classes, replacing the previous scattered FetchEnums and gen_lib_schema functions. This also enables tide.vocab resolution in configuration meta schemas β€” powering the visibility asset surface field auto-enum.

Config Schema Automation

Configuration meta schemas (visibility, deployment, etc.) now support automated JSON Schema generation with vocabulary resolution:

[config_metaschemas]
visibility = "Configurations/visibility.meta.yaml"

[config_json_schemas]
visibility = "Configurations/visibility.schema.json"

Deprecation

The targets, platforms, and domains fields are deprecated and hidden from templates (tide.template.hide: true). They remain in the schema for backward compatibility with existing TVM files pending the surface remapping migration.

What's Next

With the vocabulary and schema in place, the next step is the surface remapping β€” migrating all existing TVMs from the legacy fields to the new surface array. A pre-computed mapping file with enriched proposals for all 485 TVMs is ready for execution.