Add uco-action:Technique class and associated properties to enhance UCO's ability to better represent technique-oriented community efforts

[vulnmaster]

Change proposal written with the assistance of AI

This is the first draft. @vulnmaster is still working on shacl validation of examples and will update this proposal once that is done.

Background

In the discussion during the CDO Ontology Committee meeting on October 21, 2025, committee members identified the need for enhanced support for technique-oriented frameworks within the Unified Cyber Ontology (UCO). Currently, UCO provides comprehensive coverage of actions, observables, and roles, but lacks explicit representation for techniques as defined by various cybersecurity frameworks. This gap limits UCO's ability to effectively support communities that organize knowledge around techniques, such as MITRE ATT&CK, MITRE Engage, and SOLVE-IT.

A technique represents a specific method or approach used to accomplish a particular objective or goal. In cybersecurity contexts, techniques are often organized into frameworks that provide structured knowledge about adversary behaviors, defensive strategies, and investigative methodologies. Adding a uco-action:Technique class and associated properties will enhance UCO's ability to represent and integrate with these technique-oriented communities, improving interoperability and standardized information representation across the cybersecurity domain.

The technique concept bridges the gap between high-level tactics/objectives and specific actions, providing a middle layer of abstraction that is essential for framework alignment and knowledge organization. This addition will further align the Adversary Engagement Ontology (adversaryengagementontology.org) and support the broader cybersecurity community's need for standardized technique representation.

Requirements

Requirement 1

Create a new class uco-action:Technique as a direct rdfs:subClassOf uco-action:ActionPattern, following the established pattern used by other action pattern classes in the ontology. This positioning recognizes that techniques represent patterns of actions used to accomplish specific objectives.

Requirement 2

Define the uco-action:Technique class with appropriate rdfs:label and rdfs:comment properties that accurately describe techniques as structured methods for accomplishing objectives, including their relationship to tactics, procedures, and actions.

Requirement 3

Add properties to support technique metadata commonly used by technique-oriented frameworks, including technique identifiers, descriptions, and relationships to tactics or objectives.

Risk / Benefit analysis

Benefits

• Framework interoperability – enables seamless integration with MITRE ATT&CK, MITRE Engage, SOLVE-IT, and other technique-oriented frameworks
• Enhanced knowledge organization – provides a standardized way to represent techniques as patterns of actions, improving semantic clarity
• Community alignment – supports the broader cybersecurity community's need for technique representation and framework integration
• Adversary engagement support – facilitates representation of engagement techniques and defensive strategies as outlined in MITRE Engage
• Digital forensics integration – enables SOLVE-IT and similar initiatives to represent investigative techniques using standardized UCO constructs
• Improved analytics – supports technique-based queries for threat intelligence, defensive planning, and investigation workflows
• Ontology evolution – positions UCO to better support emerging technique-oriented communities and frameworks

Risks

Technical risks:

• Version skew – Fast-moving frameworks like MITRE ATT&CK update frequently, requiring ongoing curation and synchronization
• Vocabulary drift – Unconstrained literal strings for tactics/platforms may fragment across implementations without proper governance
• Duplication – Different publishers may mint the same technique differently, leading to data inconsistency
• Cross-module coupling – Integration with CASE, Engage, and SOLVE-IT introduces cross-release dependencies

Mitigation strategies:

• Publish a registry document with recommended values and pattern examples
• Add SHACL publish-time validation profiles for technique metadata
• Recommend skos:exactMatch / skos:closeMatch to upstream technique URIs when available
• Establish governance processes for technique vocabulary maintenance
• Provide migration guidance for framework updates

Implementation risks:

• Routine ontology-maintenance overhead (documentation updates, SHACL test additions)
• No existing UCO instances break, as this is purely additive
• The class is positioned as a subclass of ActionPattern, maintaining consistency with existing UCO architecture

Design Considerations

Datatype vs. Object Properties Trade-off

This proposal defines techniqueTactic and techniquePlatform as owl:DatatypeProperty (literal strings like "Defense Evasion"). This approach is intentionally lightweight and pragmatic, avoiding scope creep by not requiring the definition of new Tactic or Platform classes. It perfectly fulfills the stated requirements for technique-oriented framework support.

Alternative approach for future consideration: The committee might consider if these should eventually be owl:ObjectProperty properties that link to dedicated classes (e.g., kb:technique-t1055-a1b2c3d4-e5f6-4a8b-9c0d-1e2f3a4b5c6d uco-action:hasTactic kb:tactic-defense-evasion). This would be semantically richer, allowing tactics to have their own definitions, hierarchies, and relationships, but would constitute a much larger proposal requiring additional ontology modules.

Recommendation: The current datatype approach is appropriate for this change proposal, as it provides immediate value while maintaining simplicity and avoiding unnecessary complexity.

Competencies demonstrated

Competency 1 – MITRE ATT&CK technique representation

Scenario

A cybersecurity analyst needs to represent ATT&CK technique T1055 (Process Injection) in a UCO-based knowledge base. The technique represents a pattern of actions where adversaries inject code into running processes to evade detection and maintain persistence. Using the uco-action:Technique class, the analyst can represent this technique with its associated metadata, procedures, and relationships to tactics.

Example representation:

@prefix kb: <http://example.org/kb/> .
@prefix uco-action: <https://ontology.unifiedcyberontology.org/uco/action/> .
@prefix uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix uco-observable: <https://ontology.unifiedcyberontology.org/uco/observable/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# ATT&CK Technique T1055: Process Injection
kb:technique-t1055-a1b2c3d4-e5f6-4a8b-9c0d-1e2f3a4b5c6d
    a uco-action:Technique ;
    uco-core:name "Process Injection"@en ;
    uco-core:description "Adversaries may inject code into processes in order to evade process-based defenses as well as possibly elevate privileges. Process injection is a method of executing arbitrary code in the address space of a separate live process."@en ;
    uco-action:techniqueId "T1055" ;
    uco-action:techniqueFramework "mitre-attack" ;
    uco-action:techniqueTactic "Defense Evasion"@en ;
    uco-action:techniqueTactic "Privilege Escalation"@en ;
    uco-action:techniquePlatform "Windows"@en ;
    uco-action:techniquePlatform "Linux"@en ;
    uco-action:techniquePlatform "macOS"@en .

# Specific procedure: DLL Injection
kb:pattern-dll-injection-b2c3d4e5-f6a7-4b9c-8d1e-2f3a4b5c6d7e
    a uco-action:ActionPattern ;
    uco-core:name "DLL Injection (procedure)"@en ;
    uco-core:description "Adversaries may inject a DLL into a running process to execute arbitrary code."@en ;
    uco-action:implementsTechnique kb:technique-t1055-a1b2c3d4-e5f6-4a8b-9c0d-1e2f3a4b5c6d ;
    uco-action:hasPhase [
        a uco-action:ActionSpecification ;
        uco-core:name "Allocate memory in target process" ;
        uco-core:ordinalPosition "1"^^xsd:integer ;
        uco-action:object kb:process-c3d4e5f6-a7b8-4c0d-9e2f-3a4b5c6d7e8f ;
        uco-action:result kb:memory-d4e5f6a7-b8c9-4d1e-8f3a-4b5c6d7e8f9a
    ] ;
    uco-action:hasPhase [
        a uco-action:ActionSpecification ;
        uco-core:name "Write malicious DLL to allocated memory" ;
        uco-core:ordinalPosition "2"^^xsd:integer ;
        uco-action:object kb:file-e5f6a7b8-c9d0-4e2f-9a4b-5c6d7e8f9a0b ;
        uco-action:instrument kb:memory-d4e5f6a7-b8c9-4d1e-8f3a-4b5c6d7e8f9a
    ] ;
    uco-action:hasPhase [
        a uco-action:ActionSpecification ;
        uco-core:name "Create remote thread to execute DLL" ;
        uco-core:ordinalPosition "3"^^xsd:integer ;
        uco-action:object kb:process-c3d4e5f6-a7b8-4c0d-9e2f-3a4b5c6d7e8f ;
        uco-action:instrument kb:file-e5f6a7b8-c9d0-4e2f-9a4b-5c6d7e8f9a0b
    ] .

# Observable objects
kb:process-c3d4e5f6-a7b8-4c0d-9e2f-3a4b5c6d7e8f
    a uco-observable:Process ;
    uco-core:description "Target process for injection" .

kb:file-e5f6a7b8-c9d0-4e2f-9a4b-5c6d7e8f9a0b
    a uco-observable:File ;
    uco-core:description "Malicious DLL to be injected" ;
    uco-core:hasFacet [
        a uco-observable:FileFacet , uco-core:Facet ;
        uco-observable:fileName "malicious.dll" ;
        uco-observable:fileExtension "dll"
    ] .

kb:memory-d4e5f6a7-b8c9-4d1e-8f3a-4b5c6d7e8f9a
    a uco-observable:Memory ;
    uco-core:description "Memory region allocated in target process" .

Competency Question 1.1

Which ATT&CK techniques are associated with the Defense Evasion tactic, and what are their descriptions?

PREFIX uco-action: <https://ontology.unifiedcyberontology.org/uco/action/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>

SELECT ?technique ?techniqueId ?techniqueName ?description
WHERE {
  ?technique a uco-action:Technique ;
             uco-action:techniqueFramework "mitre-attack" ;
             uco-action:techniqueId ?techniqueId ;
             uco-core:name ?techniqueName ;
             uco-core:description ?description ;
             uco-action:techniqueTactic ?tactic .
  FILTER(LCASE(STR(?tactic)) = "defense evasion" || LCASE(?tactic) = "defense evasion"@en)
}
ORDER BY ?techniqueId

Result 1.1

Returns all techniques associated with the Defense Evasion tactic, enabling threat analysts to query technique databases, build defensive strategies, and correlate adversary behaviors with specific techniques. This supports threat intelligence workflows, defensive planning, and adversary behavior analysis.

Competency 2 – MITRE Engage technique integration

Scenario

A cybersecurity team is planning adversary engagement operations using MITRE Engage framework techniques. They need to represent engagement techniques such as "Honeypot" and "Decoy" in their UCO-based knowledge base to track engagement activities and measure effectiveness. The uco-action:Technique class enables representation of these engagement techniques with their associated actions and observables.

Example representation:

@prefix kb: <http://example.org/kb/> .
@prefix uco-action: <https://ontology.unifiedcyberontology.org/uco/action/> .
@prefix uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix uco-observable: <https://ontology.unifiedcyberontology.org/uco/observable/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# MITRE Engage Technique: Honeypot
kb:technique-honeypot-f6a7b8c9-d0e1-4f3a-8b5c-6d7e8f9a0b1c
    a uco-action:Technique ;
    uco-core:name "Honeypot"@en ;
    uco-core:description "A honeypot is a system designed to attract and detect unauthorized access attempts, providing insight into adversary behavior and capabilities."@en ;
    uco-action:techniqueId "Honeypot" ;
    uco-action:techniqueFramework "mitre-engage" ;
    uco-action:techniqueTactic "Expose"@en ;
    uco-action:techniquePlatform "Network"@en ;
    uco-action:techniquePlatform "System"@en .

# Honeypot deployment action
kb:action-g7b8c9d0-e1f2-4a4b-9c6d-7e8f9a0b1c2d
    a uco-action:Action ;
    uco-core:name "Deploy SSH honeypot on network segment" ;
    uco-action:performer kb:role-h8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e ;
    uco-action:object kb:computer-i9d0e1f2-a3b4-4c6d-9e8f-9a0b1c2d3e4f ;
    uco-action:result kb:computer-j0e1f2a3-b4c5-4d7e-8f9a-0b1c2d3e4f5a ;
    uco-action:implementsTechnique kb:technique-honeypot-f6a7b8c9-d0e1-4f3a-8b5c-6d7e8f9a0b1c ;
    uco-core:startTime "2024-03-15T10:00:00Z"^^xsd:dateTime .

# Honeypot system
kb:computer-i9d0e1f2-a3b4-4c6d-9e8f-9a0b1c2d3e4f
    a uco-observable:Computer ;
    uco-core:description "Dedicated honeypot system configured to attract adversaries" ;
    uco-core:hasFacet [
        a uco-observable:ComputerFacet , uco-core:Facet ;
        uco-observable:hostname "honeypot-ssh-001" ;
        uco-observable:operatingSystem "Ubuntu 20.04" ;
        uco-observable:ipAddress "192.168.100.50"
    ] .

# Adversary interaction with honeypot
kb:action-k1f2a3b4-c5d6-4e8f-9a0b-1c2d3e4f5a6b
    a uco-action:Action ;
    uco-core:name "SSH login attempt on honeypot" ;
    uco-action:performer kb:identity-l2a3b4c5-d6e7-4f9a-8b1c-2d3e4f5a6b7c ;
    uco-action:object kb:computer-j0e1f2a3-b4c5-4d7e-8f9a-0b1c2d3e4f5a ;
    uco-action:result kb:attempt-m3b4c5d6-e7f8-4a0b-9c2d-3e4f5a6b7c8d ;
    uco-core:startTime "2024-03-15T14:30:00Z"^^xsd:dateTime .

# Engagement intelligence gathered
kb:file-n4c5d6e7-f8a9-4b1c-8d3e-4f5a6b7c8d9e
    a uco-observable:File ;
    uco-core:description "Intelligence gathered from honeypot interaction" ;
    uco-core:hasFacet [
        a uco-observable:FileFacet , uco-core:Facet ;
        uco-observable:fileName "honeypot-intel-2024-03-15.json" ;
        uco-observable:fileExtension "json"
    ] .

# Role and identity resources
kb:role-h8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e
    a uco-role:Role ;
    uco-core:description "Cybersecurity defender role" .

kb:identity-l2a3b4c5-d6e7-4f9a-8b1c-2d3e4f5a6b7c
    a uco-core:Identity ;
    uco-core:description "Adversary identity observed in honeypot interaction" .

kb:attempt-m3b4c5d6-e7f8-4a0b-9c2d-3e4f5a6b7c8d
    a uco-observable:ObservableObject ;
    uco-core:description "Failed SSH login attempt" .

Competency Question 2.1

What engagement techniques were deployed in the last month, and what intelligence was gathered from adversary interactions?

PREFIX uco-action: <https://ontology.unifiedcyberontology.org/uco/action/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX uco-observable: <https://ontology.unifiedcyberontology.org/uco/observable/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?technique ?techniqueName ?deploymentAction ?intelligence ?timestamp
WHERE {
  ?technique a uco-action:Technique ;
             uco-action:techniqueFramework "mitre-engage" ;
             uco-core:name ?techniqueName .
  ?deploymentAction a uco-action:Action ;
                    uco-action:implementsTechnique ?technique ;
                    uco-core:startTime ?timestamp .
  OPTIONAL {
    ?deploymentAction uco-action:result ?intelligence .
    ?intelligence a uco-observable:File .
  }
  FILTER(?timestamp > "2024-02-15T00:00:00Z"^^xsd:dateTime)
}
ORDER BY ?timestamp DESC

Result 2.1

Returns engagement techniques deployed in the specified timeframe, along with adversary interactions and intelligence gathered. This enables measurement of engagement effectiveness, adversary behavior analysis, and intelligence collection assessment, supporting adversary engagement operations and defensive strategy refinement.

Competency 3 – SOLVE-IT digital forensics technique representation

Scenario

A digital forensics examiner needs to represent SOLVE-IT technique T1002 (Disk Imaging) in a UCO-based case management system. This technique involves creating a forensic image of a storage device for analysis. The uco-action:Technique class enables representation of this investigative technique with its associated actions, tools, and results.

Example representation:

@prefix kb: <http://example.org/kb/> .
@prefix case-investigation: <https://ontology.caseontology.org/case/investigation/> .
@prefix uco-action: <https://ontology.unifiedcyberontology.org/uco/action/> .
@prefix uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix uco-observable: <https://ontology.unifiedcyberontology.org/uco/observable/> .
@prefix uco-tool: <https://ontology.unifiedcyberontology.org/uco/tool/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# SOLVE-IT Technique T1002: Disk Imaging
kb:technique-t1002-o5d6e7f8-a9b0-4c2d-8e4f-5a6b7c8d9e0f
    a uco-action:Technique ;
    uco-core:name "Disk Imaging"@en ;
    uco-core:description "The creation of a forensic image of a storage device for analysis. This technique involves creating a bit-for-bit copy of the original storage media."@en ;
    uco-action:techniqueId "T1002" ;
    uco-action:techniqueFramework "solve-it" ;
    uco-action:techniqueTactic "Acquire Data"@en ;
    uco-action:techniquePlatform "Storage Device"@en .

# Disk imaging action performed by technician
kb:action-p6e7f8a9-b0c1-4d3e-9f5a-6b7c8d9e0f1a
    a case-investigation:InvestigativeAction ;
    uco-core:name "Forensic imaging of suspect hard drive" ;
    uco-action:performer kb:role-q7f8a9b0-c1d2-4e4f-0a6b-7c8d9e0f1a2b ;
    uco-action:object kb:drive-r8a9b0c1-d2e3-4f5a-1b7c-8d9e0f1a2b3c ;
    uco-action:instrument kb:tool-s9b0c1d2-e3f4-4a6b-2c8d-9e0f1a2b3c4d ;
    uco-action:result kb:file-t0c1d2e3-f4a5-4b6c-3d9e-0f1a2b3c4d5e ;
    uco-action:implementsTechnique kb:technique-t1002-o5d6e7f8-a9b0-4c2d-8e4f-5a6b7c8d9e0f ;
    uco-core:startTime "2024-03-10T09:00:00Z"^^xsd:dateTime ;
    uco-core:endTime "2024-03-10T11:30:00Z"^^xsd:dateTime .

# Imaging tool used
kb:tool-s9b0c1d2-e3f4-4a6b-2c8d-9e0f1a2b3c4d
    a uco-tool:Tool ;
    uco-core:name "FTK Imager" ;
    uco-core:description "Forensic imaging tool used to create disk images" ;
    uco-core:hasFacet [
        a uco-tool:ToolFacet , uco-core:Facet ;
        uco-tool:toolName "FTK Imager" ;
        uco-tool:toolVersion "4.7.1"
    ] .

# Source storage device
kb:drive-r8a9b0c1-d2e3-4f5a-1b7c-8d9e0f1a2b3c
    a uco-observable:HardDrive ;
    uco-core:description "Suspect's hard drive requiring forensic imaging" ;
    uco-core:hasFacet [
        a uco-observable:HardDriveFacet , uco-core:Facet ;
        uco-observable:manufacturer "Seagate" ;
        uco-observable:model "ST1000DM010" ;
        uco-observable:capacity "1000 GB"
    ] .

# Resulting forensic image
kb:file-t0c1d2e3-f4a5-4b6c-3d9e-0f1a2b3c4d5e
    a uco-observable:File ;
    uco-core:description "Forensic image of suspect hard drive" ;
    uco-core:hasFacet [
        a uco-observable:FileFacet , uco-core:Facet ;
        uco-observable:fileName "suspect-drive-001.dd" ;
        uco-observable:fileExtension "dd" ;
        uco-observable:sizeInBytes 1000000000000^^xsd:integer
    ] .

# Technician role (using the existing CASE investigation:Technician class)
kb:role-q7f8a9b0-c1d2-4e4f-0a6b-7c8d9e0f1a2b
    a case-investigation:Technician ;
    uco-core:startTime "2024-03-10T08:00:00Z"^^xsd:dateTime .

Competency Question 3.1

What digital forensics techniques were used in investigations this month, and what tools were employed for each technique?

PREFIX case-investigation: <https://ontology.caseontology.org/case/investigation/>
PREFIX uco-action: <https://ontology.unifiedcyberontology.org/uco/action/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX uco-tool: <https://ontology.unifiedcyberontology.org/uco/tool/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?techniqueId ?techniqueName ?action ?toolName ?performerRole ?timestamp
WHERE {
  ?technique a uco-action:Technique ;
             uco-action:techniqueFramework "solve-it" ;
             uco-action:techniqueId ?techniqueId ;
             uco-core:name ?techniqueName .
  ?action a case-investigation:InvestigativeAction ;
          uco-action:implementsTechnique ?technique ;
          uco-action:instrument ?tool ;
          uco-action:performer ?performerRole ;
          uco-core:startTime ?timestamp .
  ?tool uco-core:name ?toolName .
  FILTER(?timestamp > "2024-02-01T00:00:00Z"^^xsd:dateTime)
}
ORDER BY ?timestamp DESC

Result 3.1

Returns digital forensics techniques used in recent investigations, along with the tools employed and personnel performing the actions. This enables tracking of technique usage, tool effectiveness, and workflow optimization for digital forensics operations, supporting case management and investigative process improvement.

Solution suggestion

1. Ontology edits

   • Add the uco-action:Technique class definition in the UCO Action ontology module following the established pattern:

   uco-action:Technique
       a
           owl:Class ,
           sh:NodeShape
           ;
       rdfs:subClassOf uco-action:ActionPattern ;
       rdfs:label "Technique"@en ;
       rdfs:comment "A conceptual pattern of actions used to accomplish a specific objective within a framework (e.g., ATT&CK). Techniques mediate between higher-level tactics and concrete procedures/actions."@en ;
       sh:targetClass uco-action:Technique ;
       sh:property
           [
               sh:datatype xsd:string ;
               sh:maxCount "1"^^xsd:integer ;
               sh:minCount "1"^^xsd:integer ;
               sh:nodeKind sh:Literal ;
               sh:path uco-action:techniqueId ;
           ] ,
           [
               sh:datatype xsd:string ;
               sh:maxCount "1"^^xsd:integer ;
               sh:minCount "1"^^xsd:integer ;
               sh:nodeKind sh:Literal ;
               sh:path uco-action:techniqueFramework ;
           ] ,
           [
               sh:or (
                   [ sh:datatype xsd:string ]
                   [ sh:datatype rdf:langString ]
               ) ;
               sh:nodeKind sh:Literal ;
               sh:path uco-action:techniqueTactic ;
           ] ,
           [
               sh:or (
                   [ sh:datatype xsd:string ]
                   [ sh:datatype rdf:langString ]
               ) ;
               sh:nodeKind sh:Literal ;
               sh:path uco-action:techniquePlatform ;
           ]
           ;
       .

2. Property additions

   • Add new properties to support technique metadata and relationships:

   uco-action:techniqueId
       a owl:DatatypeProperty ;
       rdfs:label "techniqueId"@en ;
       rdfs:comment "A unique identifier for a technique within a framework (e.g., T1055 for ATT&CK, T1002 for SOLVE-IT)."@en ;
       rdfs:range xsd:string ;
       .
   
   uco-action:techniqueFramework
       a owl:DatatypeProperty ;
       rdfs:label "techniqueFramework"@en ;
       rdfs:comment "Short code/name of the framework the techniqueId belongs to (e.g., 'mitre-attack', 'mitre-engage', 'solve-it')."@en ;
       rdfs:range xsd:string ;
       .
   
   uco-action:techniqueTactic
       a owl:DatatypeProperty ;
       rdfs:label "techniqueTactic"@en ;
       rdfs:comment "A tactic or objective that this technique supports (e.g., Defense Evasion, Acquire Data)."@en ;
       rdfs:range xsd:string ;
       .
   
   uco-action:techniquePlatform
       a owl:DatatypeProperty ;
       rdfs:label "techniquePlatform"@en ;
       rdfs:comment "A platform or environment where this technique is applicable (e.g., Windows, Linux, Network)."@en ;
       rdfs:range xsd:string ;
       .
   
   uco-action:hasSubTechnique
       a owl:ObjectProperty ;
       rdfs:label "hasSubTechnique"@en ;
       rdfs:comment "Hierarchical relation from a technique to one of its sub-techniques."@en ;
       # Note: No rdfs:domain/rdfs:range to avoid unwanted RDFS entailment
       # Constraints enforced via SHACL instead
       owl:inverseOf uco-action:isSubTechniqueOf ;
       .
   
   uco-action:isSubTechniqueOf
       a owl:ObjectProperty ;
       rdfs:label "isSubTechniqueOf"@en ;
       rdfs:comment "Inverse hierarchical relation indicating that this technique is a sub-technique of another technique."@en ;
       # Note: No rdfs:domain/rdfs:range to avoid unwanted RDFS entailment
       # Constraints enforced via SHACL instead
       .
   
   uco-action:implementsTechnique
       a owl:ObjectProperty ;
       rdfs:label "implementsTechnique"@en ;
       rdfs:comment "Used by an ActionPattern or an Action to indicate the Technique it operationalizes."@en ;
       # Note: No rdfs:domain/rdfs:range to avoid unwanted RDFS entailment in open RDF graphs
       # Constraints enforced via SHACL instead
       .
   
   uco-action:implementedBy
       a owl:ObjectProperty ;
       rdfs:label "implementedBy"@en ;
       rdfs:comment "Inverse: techniques back to Actions or ActionPatterns that implement them."@en ;
       owl:inverseOf uco-action:implementsTechnique ;
       .
   
   uco-action:hasPhase
       a owl:ObjectProperty ;
       rdfs:label "hasPhase"@en ;
       rdfs:comment "A step action that composes this pattern; use uco-core:ordinalPosition to order."@en ;
       # Note: No rdfs:domain/rdfs:range to avoid unwanted RDFS entailment
       # Constraints enforced via SHACL instead
       .
   
   uco-action:ActionSpecification
       a owl:Class ;
       rdfs:subClassOf uco-action:Action ;
       rdfs:label "ActionSpecification"@en ;
       rdfs:comment "An action template/step within an ActionPattern; not an executed event."@en ;
       .

3. Documentation

   • Update UCO documentation to include the Technique class in action descriptions and examples
   • Add usage examples showing technique representation for ATT&CK, Engage, and SOLVE-IT frameworks
   • Document the relationship between techniques, tactics, and actions to clarify the abstraction hierarchy
   • Provide guidance on mapping framework-specific techniques to UCO constructs
   • Include a Do/Don't table for common implementation patterns
   • Document URI stability requirements and dereferenceability best practices
   • Provide normalization guidance for language tags and numeric datatypes

Implementation Do/Don't Guidelines:

Do	Don't
✅ Use stable URIs like .../technique/mitre-attack/T1055	❌ Use temporary or auto-generated identifiers
✅ Set both techniqueFramework and techniqueId	❌ Mix tactics from different frameworks
✅ Link rdfs:seeAlso to canonical framework pages	❌ Hang uco-action:Action instances off hasPhase
✅ Type phase steps as ActionSpecification	❌ Use plain Action for procedure templates
✅ Use @en language tags consistently	❌ Publish duplicate (framework, id) combinations
✅ Scope SPARQL queries by framework	❌ Assume tactic names are unique across frameworks
✅ Include skos:Concept dual-typing for SKOS interoperability	❌ Use transitive sub-technique chains in OWL
✅ Use case normalization in SPARQL filters	❌ Embed labels in stable IRIs
✅ Add execution-time property guards to ActionSpecification	❌ Use Action instances for procedure steps

4. Testing

   • Add validation tests to ensure proper integration with existing ActionPattern classes
   • Create example instances demonstrating technique usage across different frameworks
   • Include examples of technique-based queries for threat intelligence and investigation workflows
   • Test interoperability with existing UCO action and observable classes

5. Community integration

   • Coordinate with MITRE ATT&CK, MITRE Engage, and SOLVE-IT communities to ensure proper alignment
   • Provide migration guidance for existing technique representations
   • Support framework-specific extensions while maintaining UCO compatibility

Additional Implementation Notes

SHACL Constraints for Literal Values

To prevent vocabulary drift, the implementation should include SHACL constraints for tactic and platform literals. Note that framework-specific vocabularies should be used - the global lists below are for guidance and may be scoped per framework in practice:

uco-action:Technique-techniqueTactic-in-shape
    a sh:PropertyShape ;
    sh:targetClass uco-action:Technique ;
    sh:in (
        "Defense Evasion"@en
        "Privilege Escalation"@en
        "Persistence"@en
        "Discovery"@en
        "Lateral Movement"@en
        "Collection"@en
        "Command and Control"@en
        "Exfiltration"@en
        "Impact"@en
        "Initial Access"@en
        "Execution"@en
        "Expose"@en
        "Affect"@en
        "Acquire Data"@en
        "Extract Information"@en
    ) ;
    sh:message "Value is not member of the recommended tactic vocabulary." ;
    sh:path uco-action:techniqueTactic ;
    sh:severity sh:Warning ;
    .

uco-action:Technique-techniquePlatform-in-shape
    a sh:PropertyShape ;
    sh:targetClass uco-action:Technique ;
    sh:in (
        "Windows"@en
        "Linux"@en
        "macOS"@en
        "Network"@en
        "System"@en
        "Storage Device"@en
        "Mobile"@en
        "Cloud"@en
    ) ;
    sh:message "Value is not member of the recommended platform vocabulary." ;
    sh:path uco-action:techniquePlatform ;
    sh:severity sh:Warning ;
    .

Framework Registry

A registry document should be published with:

• Recommended framework codes (mitre-attack, mitre-engage, solve-it)
• Framework-specific tactic and platform vocabularies
• Pattern examples for each supported framework
• Migration guidance for framework updates

Framework-Specific Vocabulary Constraints

To avoid cross-contamination between frameworks, implement framework-scoped constraints:

# MITRE ATT&CK tactics (SHACL-Core compatible)
uco-action:Technique-mitre-attack-tactic-shape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:sparql [
        sh:message "ATT&CK tactic must be one of the ATT&CK set." ;
        sh:select """
            SELECT $this
            WHERE {
                $this uco-action:techniqueFramework ?fw .
                FILTER(STR(?fw) = "mitre-attack")
                $this uco-action:techniqueTactic ?tac .
                FILTER( LANG(?tac) IN ("", "en") )
                FILTER( STR(?tac) NOT IN (
                    "Defense Evasion","Privilege Escalation","Persistence","Discovery",
                    "Lateral Movement","Collection","Command and Control","Exfiltration",
                    "Impact","Initial Access","Execution"
                ))
            }
        """ ;
        sh:severity sh:Warning ;
    ] .

# MITRE Engage tactics (SHACL-Core compatible)
uco-action:Technique-mitre-engage-tactic-shape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:sparql [
        sh:message "Engage tactic must be one of the Engage set." ;
        sh:select """
            SELECT $this
            WHERE {
                $this uco-action:techniqueFramework ?fw .
                FILTER(STR(?fw) = "mitre-engage")
                $this uco-action:techniqueTactic ?tac .
                FILTER( LANG(?tac) IN ("", "en") )
                FILTER( STR(?tac) NOT IN ("Expose","Affect") )
            }
        """ ;
        sh:severity sh:Warning ;
    ] .

# SOLVE-IT tactics (SHACL-Core compatible)
uco-action:Technique-solve-it-tactic-shape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:sparql [
        sh:message "SOLVE-IT tactic must be one of the SOLVE-IT set." ;
        sh:select """
            SELECT $this
            WHERE {
                $this uco-action:techniqueFramework ?fw .
                FILTER(STR(?fw) = "solve-it")
                $this uco-action:techniqueTactic ?tac .
                FILTER( LANG(?tac) IN ("", "en") )
                FILTER( STR(?tac) NOT IN ("Acquire Data","Extract Information") )
            }
        """ ;
        sh:severity sh:Warning ;
    ] .

Closed Shape Profile for CI/CD

For stricter validation in continuous integration:

uco-action:TechniqueClosedShape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:closed true ;
    sh:ignoredProperties (rdf:type) ;
    sh:property [
        sh:path uco-action:techniqueId ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:datatype xsd:string
    ] ;
    sh:property [
        sh:path uco-action:techniqueFramework ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:datatype xsd:string
    ] ;
    sh:property [
        sh:path uco-core:name ;
        sh:minCount 1 ;
        sh:datatype xsd:string
    ] ;
    sh:property [
        sh:path uco-core:description ;
        sh:datatype xsd:string
    ] ;
    sh:property [
        sh:path uco-action:techniqueTactic ;
        sh:or ([sh:datatype xsd:string] [sh:datatype rdf:langString])
    ] ;
    sh:property [
        sh:path uco-action:techniquePlatform ;
        sh:or ([sh:datatype xsd:string] [sh:datatype rdf:langString])
    ] .

# Additional validation rules
uco-action:Technique-direct-self-edge-shape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:sparql [
        sh:message "Technique cannot directly reference itself as a sub-technique." ;
        sh:select "SELECT $this WHERE { $this uco-action:isSubTechniqueOf $this . }"
    ] .

SKOS Dual-Typing (Normative)

Instances of uco-action:Technique SHOULD additionally be typed as skos:Concept. When present:

• skos:notation SHOULD carry the framework-local techniqueId
• skos:inScheme SHOULD reference the framework's concept scheme
• skos:prefLabel SHOULD use the same value as uco-core:name
• skos:definition SHOULD use the same value as uco-core:description

kb:technique-t1055-a1b2c3d4-e5f6-4a8b-9c0d-1e2f3a4b5c6d
    a uco-action:Technique , skos:Concept ;
    skos:inScheme <https://attack.mitre.org/> ;
    skos:notation "T1055" ;
    skos:prefLabel "Process Injection"@en ;
    skos:definition "Adversaries may inject code into processes in order to evade process-based defenses as well as possibly elevate privileges. Process injection is a method of executing arbitrary code in the address space of a separate live process."@en .

This enables use of SKOS mapping properties (skos:exactMatch, skos:closeMatch) for cross-framework alignment and enhanced semantic interoperability.

ActionSpecification Guards

To prevent accidentally treating specification steps as executed actions:

uco-action:ActionSpecificationShape
    a sh:NodeShape ;
    sh:targetClass uco-action:ActionSpecification ;
    sh:closed false ;
    sh:sparql [
        sh:message "ActionSpecification must not have execution-time properties (start/end/performer/result/object/instrument)." ;
        sh:select """
            SELECT $this
            WHERE {
                VALUES ?p {
                    uco-core:startTime uco-core:endTime
                    uco-action:performer uco-action:result
                    uco-action:object uco-action:instrument
                }
                $this ?p ?any .
            }
        """ ;
        sh:severity sh:Warning ;
    ] .

Navigation and Query Patterns

For bidirectional navigation between techniques and their implementations:

# Find all implementations of a specific technique
SELECT ?pattern ?patternName ?action ?timestamp
WHERE {
  ?technique a uco-action:Technique ;
             uco-action:techniqueId "T1055" ;
             uco-action:techniqueFramework "mitre-attack" .
  ?pattern uco-action:implementsTechnique ?technique ;
           uco-core:name ?patternName .
  OPTIONAL {
    ?action uco-action:implementsTechnique ?technique ;
            uco-core:startTime ?timestamp .
  }
}
ORDER BY ?timestamp DESC

# Find techniques implemented by specific patterns (using inverse)
SELECT ?technique ?techniqueName
WHERE {
  ?pattern a uco-action:ActionPattern ;
           uco-core:name "DLL Injection (procedure)" .
  ?technique uco-action:implementedBy ?pattern ;
             uco-core:name ?techniqueName .
}

Optional Inference Rule for Enhanced Discoverability:

When publishers only link Action → ActionPattern and ActionPattern → Technique, but consumers need direct Action → Technique relationships, implementers may add this lightweight materialization rule:

# Advisory inference rule (implement in ETL/processing pipeline):
# If ?action conformsTo ?pattern AND ?pattern implementsTechnique ?technique
# Then assert: ?action implementsTechnique ?technique

This rule enables queries like "find all executed actions implementing technique T1055" without requiring publishers to assert both the pattern-level and instance-level relationships.

Uniqueness Constraints

To prevent duplicate techniques across feeds:

uco-action:Technique-unique-key-shape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:sparql [
        sh:message "Technique (techniqueFramework, techniqueId) must be unique." ;
        sh:select """
            SELECT ?this
            WHERE {
                ?this uco-action:techniqueFramework ?fw ;
                      uco-action:techniqueId ?id .
                FILTER EXISTS {
                    ?other a uco-action:Technique ;
                           uco-action:techniqueFramework ?fw ;
                           uco-action:techniqueId ?id .
                    FILTER(?other != ?this)
                }
            }
        """ ;
    ] .

# Alternative GROUP BY approach for better query planner performance (optional):
uco-action:Technique-unique-key-grouped-shape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:sparql [
        sh:message "Technique (techniqueFramework, techniqueId) must be unique (grouped)." ;
        sh:select """
            SELECT ?fw ?id
            WHERE {
                ?this a uco-action:Technique ;
                      uco-action:techniqueFramework ?fw ;
                      uco-action:techniqueId ?id .
            }
            GROUP BY ?fw ?id
            HAVING (COUNT(?this) > 1)
        """ ;
    ] .

SHACL Constraints for Property Usage

To replace RDFS domain/range constraints and avoid unwanted entailment in open RDF graphs:

uco-action:TechniqueShape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:property [
        sh:path uco-action:hasSubTechnique ;
        sh:class uco-action:Technique
    ] ;
    sh:property [
        sh:path uco-action:isSubTechniqueOf ;
        sh:class uco-action:Technique
    ] .

uco-action:ActionPatternShape
    a sh:NodeShape ;
    sh:targetClass uco-action:ActionPattern ;
    sh:property [
        sh:path uco-action:implementsTechnique ;
        sh:class uco-action:Technique
    ] ;
    sh:property [
        sh:path uco-action:hasPhase ;
        sh:class uco-action:ActionSpecification
    ] .

uco-action:ActionShape
    a sh:NodeShape ;
    sh:targetClass uco-action:Action ;
    sh:property [
        sh:path uco-action:implementsTechnique ;
        sh:class uco-action:Technique
    ] .

URI Strategy and Dereferenceability

Techniques MUST use stable, dereferenceable URIs to support proper linking and 303 redirects when frameworks move or update their documentation:

kb:technique-t1055-a1b2c3d4-e5f6-4a8b-9c0d-1e2f3a4b5c6d
    a uco-action:Technique ;
    rdfs:seeAlso <https://attack.mitre.org/techniques/T1055/> ;
    # Use stable URIs like .../technique/{framework}/{id}
    # e.g., https://ontology.caseontology.org/technique/mitre-attack/T1055
    # Publisher IRIs MUST be stable across releases
    .

URI Stability Requirements:

• Publisher IRIs MUST remain stable across data releases
• Support HTTP 303 redirects when framework pages move
• Use opaque, non-semantic identifiers when possible
• Include framework and ID in URI path for clarity
• Avoid embedding labels in IRIs; labels change more often than IDs

Self-Cycle Prevention

To prevent self-referential sub-technique relationships (both direct and indirect):

uco-action:Technique-self-cycle-shape
    a sh:NodeShape ;
    sh:targetClass uco-action:Technique ;
    sh:sparql [
        sh:message "Technique cannot be a sub-technique of itself (direct)" ;
        sh:select "SELECT $this WHERE { $this uco-action:isSubTechniqueOf $this . }"
    ] ;
    sh:sparql [
        sh:message "Technique cannot be a sub-technique of itself (indirect cycle)." ;
        sh:select """
            SELECT $this
            WHERE {
                $this uco-action:isSubTechniqueOf+ $this .
                FILTER NOT EXISTS { $this uco-action:isSubTechniqueOf $this }  # direct handled elsewhere
            }
        """ ;
    ] .

Note on Sub-Technique Transitivity:

• Sub-technique relationships are intentionally non-transitive in OWL to avoid unexpected inference chains
• Consumers may compute transitive closure for navigation using uco-action:isSubTechniqueOf+
• Publishers should avoid redundant deep chains unless they want materialized inferences

Internationalization and Normalization

Tactic and platform literals SHOULD include language tags for consistency and proper matching:

Recommended patterns:

• ✅ "Defense Evasion"@en (language-tagged)
• ✅ "Windows"@en (language-tagged)
• ⚠️ "Defense Evasion" (untagged, may cause matching issues in some triple stores)

Normalization guidance:

• Use @en consistently unless targeting a specific locale
• Publish untagged strings if your pipeline adds language tags during localization
• Ensure SPARQL filters handle both patterns: FILTER(STR(?tactic) = "Defense Evasion" || ?tactic = "Defense Evasion"@en)
• Consider case normalization: FILTER(LCASE(STR(?tactic)) = "defense evasion") for robustness
• Framework-scoped vocabulary constraints take precedence over global guidance lists

Enhanced SHACL messaging:

# Update vocabulary constraint shapes with better messages
uco-action:Technique-tactic-message-shape
    a sh:PropertyShape ;
    sh:targetClass uco-action:Technique ;
    sh:path uco-action:techniqueTactic ;
    sh:or (
        [ sh:datatype xsd:string ]
        [ sh:datatype rdf:langString ]
    ) ;
    sh:message "Tactic value must be an untagged xsd:string or a language-tagged string (rdf:langString). Use @en tags for English terms like 'Defense Evasion'@en." ;
    sh:severity sh:Warning .

This implementation maintains backward compatibility while enhancing UCO's ability to represent techniques from various cybersecurity frameworks, supporting improved interoperability and standardized information representation across the cybersecurity domain.

[chrishargreaves]

Minor note, do you think a generic term could be used in this top level description instead of tactic?

techniqueTactic -> could techniqueCategory be a more general term, covering tactics, objectives etc.

[chrishargreaves]

As an update the SOLVE-IT experimental ontology is here:

https://github.com/SOLVE-IT-DF/solve-it-ontology/tree/main

With the classes added for:
Technique
Weakness
Mitigation
PerformedTechnique

all in here: https://github.com/SOLVE-IT-DF/solve-it-ontology/blob/main/solve_it_core.ttl

The main SOLVE-IT knoweldge base from https://github.com/SOLVE-IT-DF/solve-it is then transformed into TTL and JSON-LD using the Technique, Weakness and Mitigation classes and made available here:
https://github.com/SOLVE-IT-DF/solve-it-ontology/tree/main/docs/data

Examples are here:
https://github.com/SOLVE-IT-DF/solve-it-ontology/tree/main/solve_it_examples
specifically line 152 shows the use of PerformedTechnique to make use of T1002: Disk imaging (on line 42 )

[ajnelson-nist]

One warning in response to the suggested approach: To my knowledge, uco-action:ActionPattern has never been demonstrated publicly. I note this in light of it not appearing in this list of concepts that have been exercised across CASE-Corpora, CASE-Examples, the CASE website, and the various CASE and UCO profile ontologies' minimal-example individuals.

I've further long suspected that instances of ActionPattern, and in some but not all cases of the more general Pattern, would look a lot like OWL classes, and hence that ActionPattern might actually be a meta-class. (Exceptions to this statement include encodable queries or regular expressions.) Describe to me what an instance of an action pattern is? And then, describe to me what an instance of an instance of an action pattern is [sic.]?

Action pattern: "Polite opening of door"
Action-sequence conforming to the action pattern: (1) Knock, (2) Open.

action.ttl defines ActionPattern, but it's only a standalone definition, and no subclasses exist across CASE or UCO. We might be better off discussing ActionLifecycle instead, though I'm not seeing more than a subtle difference between the two. Perhaps there's a subclass alignment between the two that was forgotten back when they were written?

This was written before being able to look through the generated competencies in detail. One last note from skimming the competencies, though: I am concerned with some of the suggested usages pertaining to what look like semi-open vocabularies, e.g.:

kb:technique-t1055-a1b2c3d4-e5f6-4a8b-9c0d-1e2f3a4b5c6d
    a uco-action:Technique ;
    uco-core:name "Process Injection"@en ;
    uco-core:description "Adversaries may inject code into processes in order to evade process-based defenses as well as possibly elevate privileges. Process injection is a method of executing arbitrary code in the address space of a separate live process."@en ;
    # ...
    uco-action:techniquePlatform "Windows"@en ;
    uco-action:techniquePlatform "Linux"@en ;
    uco-action:techniquePlatform "macOS"@en .

Technique platforms will likely be much more targeted in many cases, like "Linux running kernel <5.0.0". This gets into vulnerability management topics, which has heavy search-design needs.

[vulnmaster]

Thanks @ajnelson-nist for your comments. I've spent some time thinking about this alongside AI (GPT 5.2 and Grok 4.1) and reviewing the existing UCO and SOLVE-IT efforts with respect to creating ActionPatterns and then implementing them via ActionLifecycle. The bottom line is that I think we need to maintain both uco-action:ActionPattern and uco-action:ActionLifecycle classes as they can work together.

As of UCO 1.4.0, uco-action:ActionPattern is defined but hasn’t been widely demonstrated in public CASE/UCO examples or profile ontologies’ minimal-example individuals, so #666 should include a minimal “here is what an instance looks like” demonstration.

ActionPattern vs ActionLifecycle (what UCO 1.4.0 actually says)

• uco-action:ActionPattern is defined as both an uco-action:Action and a uco-pattern:Pattern, with the comment framing it as a “grouping of characteristics… forming a consistent or characteristic arrangement” (see ontology/uco/action/action.ttl).
• uco-action:ActionLifecycle is described as “an action pattern consisting of an ordered set…”, and its SHACL shape requires uco-action:phase pointing to uco-action:ArrayOfAction, while forbidding occurrence-time fields (startTime, endTime, actionStatus, actionCount all with sh:maxCount 0). That constraint pattern reads as “procedure/template” rather than a performed occurrence (same file: ontology/uco/action/action.ttl).

I’m not claiming ActionPattern itself encodes “performed vs template” semantics via SHACL today — it’s mostly subclass axioms + sh:targetClass — but ActionLifecycle clearly does.

“Is this a metaclass?” / “instance of an instance” (staying first-order)

To avoid metamodeling, we can keep this as first-order OWL by treating techniques/patterns as named individuals and linking concrete actions to them via an explicit object property (as #666 already sketches with implementsTechnique), rather than by typing actions as the pattern.

A minimal example using your door analogy:

@prefix action: <https://ontology.unifiedcyberontology.org/uco/action/> .
@prefix core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix : <http://example.org/kb/> .

# Instance of ActionPattern: the reusable pattern/definition
:politeOpening a action:ActionPattern ;
  core:name "Polite opening of door"@en ;
  core:description "Knock, then open."@en .

# Optional: capture one ordered procedure as an ActionLifecycle (template-like)
# (And optionally link the procedure back to the pattern using the same proposed property.)
:politeOpeningProcedure a action:ActionLifecycle ;
  action:phase [ a action:ArrayOfAction ; action:action :knock1 ; action:action :open1 ] ;
  action:implementsTechnique :politeOpening .

# Instances “of the pattern”: concrete actions linked by an object property (not rdf:type)
:knock1 a action:Action ; core:name "knock" ; action:implementsTechnique :politeOpening .
:open1  a action:Action ; core:name "open" ; action:implementsTechnique :politeOpening .

This directly answers “what is an instance?” (the pattern individual) and “what is an instance of that?” (the concrete actions that implement it).

Possible missing axiom (framed cautiously)

Given ActionLifecycle’s natural-language definition literally calls it an “action pattern”, it might be worth discussing whether there should be an explicit axiom uco-action:ActionLifecycle rdfs:subClassOf uco-action:ActionPattern. I’m not asserting intent/history — just noting the text suggests that alignment.

Public demonstration exists today: SOLVE-IT

There is a public, interoperable example of “Technique definition” vs “performed occurrence” already, from SOLVE-IT (which is explicitly extending/aligning with CASE/UCO):

• In SOLVE-IT core, the class solveit-core:Technique is declared rdfs:subClassOf uco-core:UcoObject, and solveit-core:PerformedTechnique is declared rdfs:subClassOf case-investigation:InvestigativeAction, linked via the object property solveit-core:usesTechnique (see solve_it_core.ttl).
• Their published example shows both the solveit-core:Technique instance T1002: Disk imaging and a solveit-core:PerformedTechnique instance that uses it (including start/end/instrument/object/result) in solve_it_examples/core_classes_examples.ttl.

That SOLVE-IT pattern is essentially the “instance / instance-of-instance” story in working form, without OWL metamodeling.

For #666, one pragmatic interoperability path would be to make uco-action:Technique ⊑ uco-action:ActionPattern (as proposed), then allow projects like SOLVE-IT to align via subclassing (solveit-core:Technique ⊑ uco-action:Technique) and optionally bridge properties (solveit-core:usesTechnique ⊑ uco-action:implementsTechnique) so existing SOLVE-IT data can be queried as UCO Techniques.

Semi-open vocabularies (platform/tactic)

I share the concern that platform strings can drift into highly specific expressions (e.g., kernel ranges) that are hard to normalize/search. UCO already uses many open-vocabulary constructs (see repeated comments like “Defines an open-vocabulary…” in ontology/uco/vocabulary/vocabulary.ttl) and also explicitly allows a “vocabulary-or-string” pattern in ranges (e.g., action:actionStatus has range owl:unionOf ( vocabulary:ActionStatusTypeVocab xsd:string ) in ontology/uco/action/action.ttl). So a balanced approach for #666 could be:

• keep techniquePlatform as a lightweight interoperability label, and
• optionally add a structured “platform constraint/expression” hook (e.g., CPE or a query/pattern expression) for cases that need vulnerability-management-grade precision.

If this direction seems acceptable, I can update #666’s proposal text to include (1) the minimal “door” demonstration above and (2) a SOLVE-IT-based demonstration (T1002 + PerformedTechnique) explicitly as evidence that the pattern works in practice.

[eoghanscasey]

Here we need to be careful about using an existing concept in a new context.

My recollection is that UCO ActionPattern maps to STIX AttackPattern (@sbarnum fact check). A STIX AttackPattern commonly references MITRE ATT&CK techniques and CAPEC (Common Attack Pattern Enumeration and Classification) using the external_references property:

https://github.com/mitre-attack/attack-stix-data/tree/master
https://github.com/mitre/cti/tree/master/capec/2.1/attack-pattern

STIX AttackPattern is higher level generalization that can reference techniques and vulnerabilities; it does not implement a technique.

UCO ActionPattern can be used today to reference MITRE ATT&CK and MITRE Engage but does not fit the use case of the UCO Technique proposal (#666).

Let's clarify concepts in relation to SOLVE-IT:

• A SOLVE-IT Technique represents how to achieve an objective by performing an action (e.g., 'Read bitstream data from storage medium')
• A CASE/UCO InvestigativeAction represents an action performed on an ObservableObject to accomplish an objective (e.g., Use tool 'DCCIDD' to 'Read bitstream data from storage medium' to accomplish the objective of creating a forensic image.)

InvestigativeAction properties are optional, so it could be used without specifying the tool (instrument) to be general enough to represent a general technique.

In short, we need to clarify how a SOLVE-IT Technique relates to CASE/UCO InvestigativeAction. To keep it simple, we could map them directly. The CASE/UCO InvestigativeAction has an “objective” property that relates nicely to SOLVE-IT.

Question: Are there specific use cases that InvestigativeAction does not solve, requiring a new Technique concept?

It is important not to confuse a Technique with a Standard Operating Procedure. An ActionLifeCycle represents a sequence of InvestigativeActions (e.g., For Disk Imaging: 1) 'Connect storage media to hardware Write Blocker', 2) 'Read bitstream data from storage medium', 3) 'Verify hash value of acquired data', etc.). To allow for representation of broader SOPs, a phase in an ActionLifeCycle can reference another ActionLifeCycle. For instance, the SOP could be represented as an ActionLifecycle with phases: 1) Document, 2) Preserve, 3) Examine, 4) Analyze and the Preserve phase could reference a Disk Imaging ActionLifeCycle.

For SOLVE-IT, I'm not sure there is a benefit to using ActionPattern to represent an unordered collection of InvestigativeActions.

[chrishargreaves]

Are there specific use cases that InvestigativeAction does not solve, requiring a new Technique concept?

The original issue for me was the conceptual difference between a description of a technique that could be performed e.g. the SOLVE-IT content, and a record of someone executing an instance of it.

I thought there was no simplistic separation between these two very different things other than making assumptions that if there is no instrument, no performed then its a conceptual technique not an executed. But I do notice that there are properties such as actionCount and actionStatus, so it could be populated with something like these:

actionCount=0
actionStatus="Conceptual??"

So in that case I could just subclass InvestigativeAction for both solveit-core:Technique and solveit-core:PerformedTechnique but it feels a bit off from a conceptual point of view. It also doesn't work for other 'techniques' used by other people that aren't for investigations e.g. an attacker uses an ATT&CK technique, but I guess that could be fixed by using action:Action instead, which has those same properties.

If Action is used for the conceptual and the specific, I suppose creating TechniqueCollection would be another option. I guess that means that any Action/Investigative action in a TechniqueCollection wasn't ever performed, it just is an action that could be done.

The SOLVE-IT knowledge base would then be modelled as a TechniqueCollection containing solveit-core:Technique (extends InvestigativeAction), but if someone uses the technique it is recorded as solveit-core:PerformedTechnique (extends InvestigativeAction) but is situated in a different context, maybe action:ActionLifecycle?

[eoghanscasey]

Talking through this with @chrishargreaves now I see the need for defining a general Technique as type of Action that could be perform, potentially using different tools/methods.

An instance of a Technique being performed using a specific tool/method is close to InvestigativeAction with the additional properties referencing a framework of techniques (e.g., SOLVE-IT, MITRE ATT&CK). SOLVE-IT represents this as PerformedTechique.

This raises the question of whether there is benefit to add properties to InvestigativeAction for referencing a framework of techniques, effectively making CASE InvestigativeTechnique = SOLVE-IT PerformedTechique.

[plbt5]

I'm triggered by @eoghanscasey's remark:

My recollection is that UCO ActionPattern maps to STIX AttackPattern (@sbarnum fact check).

Checking the documentation, uni:ActionPattern is being described as:

An action pattern is a grouping of characteristics unique to a combination of actions forming a consistent or characteristic arrangement.

No reference to STIX though. Which implies its use should not be scoped to or specifically founded on STIX' AttackPattern.

However, I trust Eoghan's memory that such a relationship does exist. Which thus identifies a very inconvenient hole in the documentation. I think that we need to improve on our definitions and include scope notes as additional property to the ontological elements.

This is not an impediment to this CP, but something that requires a discussion whether we need to start a review/polishing process over the documentation or that we find another solution.