Domain-Specific Language Simulant for Adversary Emulation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing computer security systems lack a formal language for threat models and methodologies to effectively simulate and defend against threat-actor activities, and are often not domain-specific, making them vulnerable to infiltration and reverse-engineering.

Innovation Solution

A method for generating a Domain-Specific Language (DSL) simulant that simulates threat-actor activities by determining a framework based on an attack repository, creating primitives that define attack execution operations, and combining these primitives into a DSL simulant that can be executed within a specific computer security environment.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a general-purpose security system is used, then it can handle multiple types of attacks, but it becomes vulnerable to infiltration and reverse-engineering by threat-actors

Engineering Contradiction:
Improvecapability to handle multiple attack typesVSAvoidvulnerability to infiltration and reverse-engineering
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent applies local quality by creating domain-specific language simulants that are tailored to specific attack domains (e.g., mobile, enterprise, cloud). Each DSL simulant is customized with domain-specific primitives, tactics, techniques, and procedures that match the characteristics of that particular domain, making the simulation both specialized and secure while maintaining versatility through multiple domain-specific implementations

Inventive Principle:
Principle #3Local quality

2Ease of operation

If existing adversary emulation platforms are used, then they can simulate threat-actor activities, but they lack domain-specific configuration making them easy to compromise

Engineering Contradiction:
Improvecapability to simulate threat-actor activitiesVSAvoidsusceptibility to compromise due to lack of domain-specific configuration
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent segments the adversary emulation functionality into separate domain-specific DSL simulants (mobile-DSL, enterprise-DSL, cloud-DSL). Each segment is independently configured with domain-specific primitives and procedures, allowing secure simulation in each domain while maintaining overall system flexibility and ease of operation through modular deployment

Inventive Principle:
Principle #1Segmentation

3Reliability

If a formal language for threat models is created, then it can provide structured methodology for defense, but it increases system complexity

Engineering Contradiction:
Improvestructured methodology for defenseVSAvoidcomplexity of DSL simulant structure
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent manages complexity by parameterizing the DSL simulant structure with configurable elements such as domain-specific primitives, tactics, techniques, and procedures. The formal language framework accepts various parameters (domain type, attack vectors, defensive measures) that can be adjusted without changing the core structure, enabling structured defense methodology while maintaining manageable complexity through parameter-driven configuration

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS12301612B2Domain-specific language simulant for simulating a threat-actor and adversarial tactics, techniques, and procedures
Publication Date: 2025.05.13 QUALYS
  • US12301612B2 patent drawing
  • US12301612B2 patent drawing
  • US12301612B2 patent drawing

AI summary

The present describes simulating a threat-actor executing an attack execution operation. According to one aspect of the subject matter described in this disclosure, a method for generating a domain-specific language (DSL) simulant is disclosed. The method may comprise determining, a framework based on an attack repository, determining a first primitive based on the framework, and determining a second primitive based on the framework. In one implementation, the first primitive and the second primitive are fundamental structures or constructs within a DSL. The method further comprises combining the first primitive and the second primitive into a DSL simulant. In one implementation, the DSL simulant is executed to simulate a threat-actor executing an attack execution operation.