Proposal: Custom Asset Type Support in SecOpsTM (DSL extension for user-defined asset types)

[zhangtianqi-james]

Hi @ellipse2v ,

I've been exploring SecOpsTM for modeling some specialized systems (IoT devices and SCADA equipment) and encountered a limitation: the current asset type mappings are hardcoded in asset_technique_mapper.py, which means custom asset types fall back to "default" and lose precise MITRE ATT&CK correlation.

I'd like to propose a Custom Asset Type feature that allows users to define their own asset types directly in the DSL markdown, without modifying source code. This would enable modeling of specialized systems while maintaining full compatibility with existing threat analysis and GDAF workflows.

Below is a detailed proposal. I'd really appreciate your feedback on:

• Whether this aligns with the project's direction
• The DSL syntax design
• Any concerns or suggestions before implementation

Thanks for building such a powerful framework! 🙏

---

Proposal: Custom Asset Type Support in SecOpsTM

Executive Summary

This proposal adds support for user-defined asset types in SecOpsTM, enabling users to extend the built-in MITRE ATT&CK mapping without modifying source code. This is essential for modeling specialized systems (IoT, SCADA, legacy equipment) that fall outside the 31 pre-defined asset types.

Business Value

Problem Statement

Currently, SecOpsTM hardcodes asset type mappings in asset_technique_mapper.py:

• ASSET_TYPE_TO_PLATFORMS — 31 pre-defined types
• ASSET_TYPE_TO_TACTICS — 31 pre-defined types
• ASSET_TYPE_KEY_TECHNIQUES — 21 pre-defined types

Limitation: Users modeling IoT cameras, SCADA PLCs, medical devices, or other specialized assets cannot define custom type mappings. Unknown types fall back to "default", losing precise MITRE ATT&CK correlation.

Use Cases

1. IoT Security: iot-camera, iot-sensor, smart-hvac
2. Industrial Control Systems: scada-plc, rtu-controller, safety-instrumented-system
3. Medical Devices: infusion-pump, patient-monitor, pacemaker-programmer
4. Legacy Systems: mainframe-lpar, as400-system, proprietary-dcs
5. Cloud-Native: serverless-function, container-orchestrator, service-mesh-control-plane

Benefits

• ✅ No code changes required — Define types in DSL alongside threat model
• ✅ Project isolation — Each model can have its own custom types
• ✅ Version control friendly — Types tracked with model in same file
• ✅ Full GDAF support — Custom types work in Goal-Driven Attack Flow analysis
• ✅ Backward compatible — Existing models unchanged, built-in types preserved

Technical Solution

DSL Syntax

Add new ## Custom Asset Types section to threat model markdown:

## Custom Asset Types
- **iot-camera**: platforms=["Linux", "Network Devices"], tactics=["initial-access", "collection", "impact"], key_techniques=["T1190", "T1059", "T1498"], fuzzy_matches=["camera", "surveillance"]
- **scada-plc**: platforms=["Embedded", "Windows"], tactics=["impact", "execution"], key_techniques=["T1498", "T1565.001"]
Servers

Camera-Main: type="iot-camera", boundary="Perimeter"
PLC-1: type="scada-plc", boundary="OT"

Required Parameters

• platforms (required): MITRE ATT&CK platform tags for technique matching
• tactics (required): Primary tactics for this asset type (affects GDAF scoring priority)

Optional Parameters

• key_techniques: High-value technique IDs to boost in scoring
• fuzzy_matches: String patterns for automatic type normalization (e.g., "camera" → "iot-camera")

Code Changes Summary

Files Modified (5 files)

File	Changes
threat_analysis/core/model_parser.py	Add _parse_custom_asset_type() method, register in section_parsers
threat_analysis/core/models_module.py	Add custom_asset_types dict, register_custom_asset_type() method
threat_analysis/core/asset_technique_mapper.py	Extend get_techniques() to accept custom types, enhance _normalize_type() with custom fuzzy matching
threat_analysis/core/gdaf_engine.py	Pass custom types to AssetTechniqueMapper, support custom type in target matching
threat_analysis/generation/report_generator.py	Ensure custom types serialized in JSON/HTML reports

Hope for Feedback

I seek your input on:

1. DSL syntax: Is the proposed syntax clear and consistent with existing DSL style?
2. Parameter names: Are platforms, tactics, key_techniques, fuzzy_matches intuitive?
3. Priority resolution: Should custom types override built-in types, or should there be a merge strategy?
4. Additional use cases: Are there other scenarios we should consider?
5. Documentation: Should this feature have a separate guide or be integrated into existing docs?

---

[ellipse2v]

Hi @zhangtianqi-james, this is a really great idea.

You've identified a real limitation in the current design. Hardcoding asset types in asset_technique_mapper.py is exactly the kind of friction that slows down adoption for specialized domains like OT/ICS, IoT, and medical devices. This needs to be fixed.

Rather than DSL-level per-project definitions, I'd like to go one step further and build a shared community dictionary that benefits everyone. Here are my thoughts on each of your questions:

---

1. DSL syntax

Instead of embedding custom types in the threat model markdown, I'd propose a dedicated asset_types_community.yaml file versioned in the repository. This keeps the DSL clean and focused on the threat model itself, while the YAML becomes the single shared reference for all asset type definitions — both existing built-in types and new community contributions. It's also more accessible to contributors who aren't writing threat models.

2. Parameter names

Your naming is intuitive and I'd keep it as-is: platforms, tactics, key_techniques, fuzzy_matches. I'd add two fields:

• category — for grouping (endpoint, network, ot, iot, cloud) useful for filtering and documentation
• icon_url — a URL to a PNG icon (64x64, hosted in assets/icons/) for future report rendering and UI display

3. Priority resolution: override vs merge?

The single YAML approach eliminates this question entirely. With one file as the source of truth, there's only one definition per type — collaboratively maintained. If a contributor wants to enrich an existing type (add a fuzzy_match, a new key_technique), they simply open a PR on that entry. No override logic needed.

4. Additional use cases

Your 5 categories are a great starting point. The category field naturally supports expansion to cloud (serverless, containers), medical, legacy, and beyond. I'd also flag one important consideration: pytm compatibility. SecOpsTM has existing mappings with pytm element types, so new asset types should be cross-checked to ensure they align or extend those mappings without breaking existing workflows.

5. Documentation

A dedicated CONTRIBUTING.md will be added alongside the YAML file, covering the schema, validation rules (MITRE ATT&CK platform names, tactic IDs in kebab-case), and the PR process for new types.

---

Proposed structure

asset_types:

  workstation:
    description: "Standard end-user workstation"
    category: endpoint
    platforms: [Windows, Linux, macOS]
    tactics: [initial-access, execution, persistence]
    key_techniques: [T1566, T1059, T1078]
    fuzzy_matches: [workstation, desktop, laptop]
    icon_url:"/icons/workstation.png"

  iot-camera:
    description: "IP-connected surveillance camera"
    category: iot
    platforms: [Linux, Network Devices]
    tactics: [initial-access, collection, impact]
    key_techniques: [T1190, T1059, T1498]
    fuzzy_matches: [camera, ipcam, cctv]
    icon_url: "/icons/iot-camera.png"

  scada-plc:
    description: "Programmable Logic Controller in SCADA/ICS"
    category: ot
    platforms: [Embedded, Windows]
    tactics: [impact, execution, lateral-movement]
    key_techniques: [T1498, T1565.001, T1059]
    fuzzy_matches: [plc, scada, rtu]
    icon_url: "/icons/scada-plc.png"

---

What do you think about that?

[zhangtianqi-james]

Hi @ellipse2v,

Thanks for the thoughtful feedback! I love the idea of a shared community dictionary — that's definitely better than my original per-project approach.

The YAML structure looks great, and I agree that keeping the DSL focused on the threat model itself is the right design choice. The category and icon_url fields are excellent additions too.

One question: should the built-in types from asset_technique_mapper.py be migrated into the YAML as the initial content, or should the YAML start with just the new community-contributed types?

This would be a valuable addition to SecOpsTM. Happy to see where you'd like to take it!

[ellipse2v]

Hi @zhangtianqi-james

I think you can start with the new additions and then migrate the existing content later. Do you want to kick things off with your new types? I’ll handle the migration of the existing ones afterward. I’m actually on leave right now and should be back in early May

[zhangtianqi-james]

Hi @ellipse2v,

Sounds good! I'll wait for you to set up the framework when you're back.

Enjoy your time off! 🏖️

[ellipse2v]

Hi @zhangtianqi-james. My time off is over :) and I'm back on it. I’ll provide a test version in the next few days with the hardcoded data migrated. Once that's done, you can give me your feedback and start adding new types. Thanks! Best regards.

[ellipse2v]

hi @zhangtianqi-james please find here a first draft https://github.com/ellipse2v/SecOpsTM/tree/custom_asset_type , what do you think ?