Traffic Light Protocol 2.0

[vulnmaster]

Background

The Traffic Light Protocol (TLP) 2.0 is a widely used information sharing standard that indicates how and with whom information can be shared. Currently, the Unified Cyber Ontology's marking vocabulary lacks support for TLP 2.0 markings. Adding a TrafficLightProtocol_2_0 class as a subclass of marking:ReleaseToMarking will enable proper classification and handling of information according to TLP 2.0 standards.

Change Proposal Created by @vulnmaster with the Assistance of AI LLM Services: Claude Sonnet 3.5, GPT 4o1

Sources

• TLP FIRST Standards Definitions and usage Guidance - Version 2.0
• TLP 2.0 Use Cases
• TPL 2.0 Definitions and Usage from DHS CISA
• CASE Ontology
• Unified Cyber Ontology
• National Council of ISACs

Extensions Beyond TLP Standard

This proposal includes two extensions beyond the official TLP 2.0 specification:

1. validUntil Property: Enables time-bound access control

   • Optional extension for automated handling
   • Not part of official TLP specification
   • Can be omitted for strict TLP compliance

2. Community Restrictions: Formalizes sharing boundaries

   • Extends TLP:GREEN semantics
   • Optional enhancement for precise control
   • Can be omitted for strict TLP compliance

External Namespace Dependencies

This proposal relies on several external ontologies:

1. Unified Cyber Ontology (UCO)

   • uco-core: Core objects and properties (e.g., objectMarking, createdTime)
   • uco-observable: Cyber observable objects for threat detection
   • uco-types: Common data types and structures
     Source: UCO GitHub

2. CASE

   • case-investigation: Investigation records and provenance
   • relationship: Entity relationships and sharing agreements
     Source: CASE GitHub

3. Dublin Core Terms

   • dcterms: Metadata properties for versioning and dates
     Source: DCMI Namespace

4. SKOS

   • skos: Semantic concept definitions and documentation
     Source: SKOS Reference

Legacy TLP 1.0 Definition

Traffic Light Protocol 1.0 (TLP 1.0) is a legacy marking scheme that is no longer supported (deprecated). There is a large volume of cyber domain data marked with TLP 1.0. For migration support, we define the TLP 1.0 class and its usage but mostlyfocus on the TLP 2.0 class and its usage in this change proposal.

We can chose to define the TLP 1.0 class and its usage as a subclass of marking:ReleaseToMarking or as a separate class. The choice is made to define the TLP 1.0 class as a subclass of marking:ReleaseToMarking.

# TLP 1.0 Class Definition
marking:TrafficLightProtocol_1_0
    a owl:Class ;
    rdfs:subClassOf marking:ReleaseToMarking ;
    rdfs:label "Traffic Light Protocol 1.0 Marking"@en ;
    rdfs:comment "Legacy TLP 1.0 marking class, maintained for migration support."@en ;
    owl:versionInfo "1.0" ;
    owl:deprecated true .

# TLP 1.0 Property Definition (using string literals)
marking:tlpLevel_1_0
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_1_0 ;
    rdfs:range xsd:string ;
    rdfs:comment "Legacy string-based TLP level property."@en ;
    owl:deprecated true .

# Example TLP 1.0 Usage
_:example1
    a marking:TrafficLightProtocol_1_0 ;
    marking:tlpLevel_1_0 "WHITE" .

_:example2
    a marking:TrafficLightProtocol_1_0 ;
    marking:tlpLevel_1_0 "AMBER" .

Requirements

Requirement 1

Create a new class marking:TrafficLightProtocol_2_0 as a subclass of marking:ReleaseToMarking to represent TLP 2.0 marking classifications.

Requirement 2

Define the four TLP 2.0 marking values (RED, AMBER, GREEN, CLEAR) as individuals of the TrafficLightProtocol_2_0 class, including their definitions and sharing restrictions as specified in the TLP 2.0 standard.

Requirement 3

Define advanced properties for marking:TrafficLightProtocol_2_0 to support additional TLP 2.0 features, such as community restrictions and validUntil dates.

Requirement 4

Consider proposing a new class marking:TrafficLightProtocol_1_0 as a subclass of marking:ReleaseToMarking to represent TLP 1.0 marking classifications.

Risk / Benefit analysis

Benefits

1. Enables standardized representation of TLP 2.0 markings in CASE-based systems
2. Improves interoperability with organizations using TLP 2.0 for information sharing
3. Provides clear semantics for handling sensitive information in cyber investigations

Risks

The submitter is unaware of significant risks associated with this change. Minor consideration should be given to:

• Ensuring backward compatibility with any existing TLP marking implementations
• Clear documentation to prevent confusion between TLP 1.0 and 2.0 markings

Competencies demonstrated

Competency 1

Scenario: An investigator needs to share technical investigation findings with different stakeholders while maintaining appropriate access controls based on TLP 2.0 markings.

Competency Question 1.1

Which pieces of evidence can be shared with first responders outside the organization?

Result 1.1

Evidence marked with TLP:AMBER can be shared with first responders who need to know, while TLP:RED items must remain within the organization.

Competency Question 1.2

What digital artifacts can be shared publicly from the investigation?

Result 1.2

Only artifacts marked as TLP:CLEAR can be shared publicly without restrictions.

Competency Question 1.3

Can Company A share TLP:AMBER threat intelligence with their contracted incident response provider?

Result 1.3

No, unless explicitly authorized by the originator through:

• A standing agreement
• A specific request
• Instructions accompanying the intelligence

Competency Question 1.4

Can Company A share TLP:GREEN sector-specific threat intelligence with Company B?

Result 1.4

Yes, if both companies are part of the defined sector community. No, if either company is outside the specified sector.

Solution suggestion

Design Decisions and Rationale

1. Modeling Approach

We use a hybrid approach combining OWL and SKOS for different aspects of TLP 2.0:

1. OWL Classes and Properties (marking: namespace)

   • Used for the structural aspects of TLP markings
   • Defines how markings attach to objects
   • Handles validation and constraints
   • Example: marking:TrafficLightProtocol_2_0 class

   Usage scenarios:

   • When creating or updating TLP markings
   • When validating marking constraints
   • When querying for marked objects

2. SKOS Concepts (vocabulary: namespace)

   • Contains the official FIRST TLP 2.0 definitions
   • Provides human-readable documentation
   • Enables semantic relationships between concepts
   • Example: vocabulary:TLPRed concept

   Usage scenarios:

   • When displaying TLP definitions to users
   • When documenting marking usage
   • When mapping between different marking schemes

2. TLP Level Stability

The TLP 2.0 specification defines exactly four levels (RED, AMBER, GREEN, CLEAR) as a stable enumeration. This stability is reflected in our modeling:

1. Fixed Enumeration

   • The four levels are modeled as OWL individuals
   • SHACL constraints enforce this fixed set
   • Future TLP versions would be separate classes
   • IMPORTANT: These four individuals form a closed enumeration and MUST NOT be extended by third parties

2. Version Control

   • TLP 2.0 is a distinct class from TLP 1.0
   • Migration paths are explicitly defined
   • No dynamic level addition is supported

Data Migration Considerations

1. String to Individual Conversion
   TLP 1.0 used string literals for levels:

   # TLP 1.0 style
   ?marking marking:tlpLevel_1_0 "WHITE" .

   TLP 2.0 uses typed individuals:

   # TLP 2.0 style
   ?marking marking:tlpLevel marking:CLEAR .

2. Level Mapping

   # Helper function to map old string levels to new individuals
   BIND(
       CASE ?oldLevel 
           WHEN "WHITE" THEN marking:CLEAR
           WHEN "RED" THEN marking:RED
           WHEN "AMBER" THEN marking:AMBER
           WHEN "GREEN" THEN marking:GREEN
           ELSE marking:CLEAR  # Default case
       END AS ?newLevel
   )

3. Validation Steps

   # Verify no invalid levels exist
   SELECT ?marking ?invalidLevel
   WHERE {
       ?marking a marking:TrafficLightProtocol_2_0 ;
                marking:tlpLevel ?invalidLevel .
       FILTER(?invalidLevel NOT IN (
           marking:RED, marking:AMBER, 
           marking:GREEN, marking:CLEAR
       ))
   }

3. Community Restrictions

The marking:communityRestriction property is formally defined as:

# Note: This is an extension beyond the official TLP specification
marking:communityRestriction
    a owl:ObjectProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:CommunityRestriction ;
    rdfs:label "community restriction"@en ;
    rdfs:comment "Specifies sharing restrictions for TLP:GREEN markings based on community membership."@en .

Usage patterns:

1. Sector Restrictions (using IRIs instead of strings)

   ?marking marking:communityRestriction marking:FinancialSector .

2. Geographic Restrictions (using IRIs instead of strings)

   ?marking marking:communityRestriction marking:EuropeanRegion .

2. TLP 1.0 to 2.0 Migration

Key changes from TLP 1.0 to 2.0:

TLP 1.0	TLP 2.0	Changes
WHITE	CLEAR	- Name change - Updated sharing semantics - Clearer public release criteria
GREEN	GREEN	- Enhanced community definition - Clarified sector boundaries
AMBER	AMBER	- Strengthened need-to-know requirements - Organization scope clarification
RED	RED	- Tightened disclosure restrictions - Added impact criteria

3. Property Justification

The validUntil property is introduced to support:

• Time-bound information sharing agreements
• Automatic declassification workflows
• Incident response phase transitions
• Compliance with data retention policies

While not part of the core TLP standard, this extension enables automated handling of temporal access controls.

Implementation steps:

1. Create new class marking:TrafficLightProtocol_2_0 as subclass of marking:ReleaseToMarking

2. Define four individuals representing TLP levels:

   • TLP:RED - Recipients may not share information with any parties outside of the specific exchange
   • TLP:AMBER - Recipients may only share information with members of their own organization who need to know
   • TLP:GREEN - Recipients may share information with peers and partner organizations within their sector or community
   • TLP:CLEAR - Information may be shared publicly without restrictions

3. Add appropriate documentation and examples

4. Create unit tests to validate proper usage of TLP 2.0 markings

The implementation will include proper rdfs:label and rdfs:comment annotations to document the meaning and usage of each marking level according to the official TLP 2.0 specifications.

Class Architecture Graph

graph TD
    A[marking:ReleaseToMarking] --> B[marking:TrafficLightProtocol_2_0]
    B --> C[marking:TLPLevel]
    C --> D[marking:RED]
    C --> E[marking:AMBER]
    C --> F[marking:GREEN]
    C --> G[marking:CLEAR]
    
    B -- marking:tlpLevel --> C
    B -- marking:validUntil --> H[xsd:dateTime]

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px
    style C fill:#dfd,stroke:#333,stroke-width:2px
    style D fill:#fdd,stroke:#333,stroke-width:2px
    style E fill:#fed,stroke:#333,stroke-width:2px
    style F fill:#dfd,stroke:#333,stroke-width:2px
    style G fill:#dff,stroke:#333,stroke-width:2px

Loading

SPARQL Query Examples

Competency Question 1.1: Evidence Shareable with First Responders

Find evidence that can be shared with first responders outside the organization:

PREFIX marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX case-investigation: <https://ontology.caseontology.org/case/investigation/>

SELECT DISTINCT ?evidence ?evidenceType ?createdTime
WHERE {
    # Get evidence items with their markings
    ?evidence a case-investigation:ProvenanceRecord ;
             uco-core:objectMarking ?marking ;
             a ?evidenceType ;
             uco-core:createdTime ?createdTime .
    
    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel ?level .
    
    # Filter for AMBER level (shareable with first responders who need to know)
    FILTER(?level = marking:AMBER)
    
    # Optional: Add temporal filter if needed
    # FILTER(?createdTime >= "2024-01-01T00:00:00"^^xsd:dateTime)
}
ORDER BY ?createdTime

Competency Question 1.2: Publicly Shareable Artifacts

Find digital artifacts that can be shared publicly:

PREFIX marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX case-investigation: <https://ontology.caseontology.org/case/investigation/>

SELECT DISTINCT ?artifact ?artifactType
WHERE {
    ?artifact uco-core:hasMarking ?marking ;
             a ?artifactType .
    
    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel marking:CLEAR .
    
    # Optional: Filter out specific artifact types if needed
    FILTER NOT EXISTS {
        ?artifact a case-investigation:PersonalData .
    }
}

Competency Question 1.3: AMBER Sharing with Contractors

Check if TLP:AMBER intelligence can be shared with a contracted provider:

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

SELECT DISTINCT ?intelligence ?provider ?agreement
WHERE {
    # Get AMBER marked intelligence
    ?intelligence uco-core:objectMarking ?marking .
    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel marking:AMBER .
    
    # Check for explicit sharing agreements
    ?agreement a relationship:SharingAgreement ;
              relationship:source ?originator ;
              relationship:target ?provider ;
              relationship:permission "AUTHORIZED" .
    
    # Provider must be a contracted entity
    ?provider a relationship:ContractedService .
    
    # Optional: Check if agreement is still valid
    OPTIONAL {
        ?agreement uco-core:endTime ?endTime .
        FILTER(!BOUND(?endTime) || ?endTime > NOW())
    }
}

Competency Question 1.4: GREEN Sharing within Sector

Determine if TLP:GREEN intelligence can be shared between companies in the same sector:

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

SELECT DISTINCT ?intelligence ?companyA ?companyB
WHERE {
    # Get GREEN marked intelligence with sector restriction
    ?intelligence uco-core:objectMarking ?marking .
    ?marking a uco-marking:TrafficLightProtocol_2_0 ;
             uco-marking:tlpLevel uco-marking:GREEN ;
             uco-marking:communityRestriction uco-marking:FinancialSector .
    
    # Check if both companies are in the financial sector
    ?companyA relationship:memberOf uco-marking:FinancialSector .
    ?companyB relationship:memberOf uco-marking:FinancialSector .
    
    # Ensure we're looking at different companies
    FILTER(?companyA != ?companyB)
}

These queries demonstrate how to:

1. Find AMBER-marked evidence shareable with first responders
2. Identify CLEAR-marked artifacts for public sharing
3. Verify sharing permissions for AMBER intelligence with contractors
4. Check sector-based sharing rules for GREEN intelligence

Solution suggestion (expanded)

Class Definition

URI

https://ontology.unifiedcyberontology.org/uco/marking/ReleaseToMarking/TrafficLightProtocol_2_0

Superclass

marking:ReleaseToMarking

Label

"Traffic Light Protocol 2.0 Marking"@en

Description

"A marking that indicates how and with whom information can be shared according to the Traffic Light Protocol version 2.0 standard."@en

Superclasses

• marking:ReleaseToMarking

SHACL Shape Definition

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix marking: <https://ontology.unifiedcyberontology.org/uco/marking/> .
@prefix vocabulary: <https://ontology.unifiedcyberontology.org/uco/vocabulary/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# Base shape for TLP 2.0 markings
marking:TrafficLightProtocol_2_0Shape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:tlpLevel ;
        sh:datatype vocabulary:TLPLevelVocab ;
        sh:minCount 1 ;
        sh:maxCount 1
    ] ;
    sh:property [
        sh:path marking:tlpDefinition ;
        sh:datatype vocabulary:TLPDefinitionVocab ;
        sh:maxCount 1
    ] .

# Shape for validating community restrictions
marking:CommunityRestrictionShape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:communityType ;
        sh:datatype vocabulary:CommunityTypeVocab ;
        sh:maxCount 1
    ] ;
    # Only allow community restrictions for TLP:GREEN
    sh:sparql [
        sh:message "Community restrictions can only be applied to TLP:GREEN markings"@en ;
        sh:select """
            PREFIX marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
            PREFIX vocabulary: <https://ontology.unifiedcyberontology.org/uco/vocabulary/>
            SELECT $this ?level
            WHERE {
                $this marking:communityType ?type .
                $this marking:tlpLevel ?level .
                FILTER(?level != "GREEN"^^vocabulary:TLPLevelVocab)
            }
        """
    ] .

# Shape for sector restrictions
marking:SectorRestrictionShape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:sector ;
        sh:datatype vocabulary:SectorVocab ;
        sh:maxCount 1 ;
        # Only allow sector if communityType is SECTOR
        sh:qualifiedValueShape [
            sh:path marking:communityType ;
            sh:hasValue "SECTOR"^^vocabulary:CommunityTypeVocab
        ]
    ] .

# Shape for geographic restrictions
marking:GeographicRestrictionShape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:geographicRegion ;
        sh:datatype vocabulary:GeographicRegionVocab ;
        sh:maxCount 1 ;
        # Only allow region if communityType is GEOGRAPHIC
        sh:qualifiedValueShape [
            sh:path marking:communityType ;
            sh:hasValue "GEOGRAPHIC"^^vocabulary:CommunityTypeVocab
        ]
    ] .

# Note: validUntil is an extension beyond the official TLP specification
marking:ValidUntilShape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:validUntil ;
        sh:datatype xsd:dateTime ;
        sh:maxCount 1
    ] .

Properties Table

Property	Type	Description	Range
marking:tlpLevel	ObjectProperty	The specific TLP 2.0 classification level	marking:TLPLevel
marking:validUntil	DatatypeProperty	Optional expiration date of the marking	xsd:dateTime

Property Shapes

marking:tlpLevel

• Property Name: tlpLevel
• Property Type: ObjectProperty
• Description: "Specifies the TLP 2.0 classification level for information sharing"
• Minimum Count: 1
• Maximum Count: 1
• Local Range: marking:TLPLevel
• Global Range: marking:TLPLevel

marking:validUntil

• Property Name: validUntil
• Property Type: DatatypeProperty
• Description: "Specifies the datetime until which this TLP marking is valid"
• Minimum Count: 0
• Maximum Count: 1
• Local Range: xsd:dateTime
• Global Range: xsd:dateTime

Vocabulary Definition

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vocabulary: <https://ontology.unifiedcyberontology.org/uco/vocabulary/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<https://ontology.unifiedcyberontology.org/uco/vocabulary/tlp>
    a owl:Ontology ;
    rdfs:label "TLP Vocabulary"@en ;
    owl:versionIRI vocabulary:2.0.0 ;
    dcterms:title "Traffic Light Protocol (TLP) Vocabulary"@en ;
    dcterms:description "Controlled vocabulary for Traffic Light Protocol (TLP) version 2.0 marking definitions and restrictions."@en .

vocabulary:TLPLevelVocab
    a rdfs:Datatype ;
    rdfs:label "TLP Level Vocabulary"@en ;
    rdfs:comment "Enumerated values for TLP 2.0 levels with their official definitions from FIRST."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "RED"^^vocabulary:TLPLevelVocab
            "AMBER"^^vocabulary:TLPLevelVocab
            "GREEN"^^vocabulary:TLPLevelVocab
            "CLEAR"^^vocabulary:TLPLevelVocab
        )
    ] .

vocabulary:TLPDefinitionVocab
    a rdfs:Datatype ;
    rdfs:label "TLP Definition Vocabulary"@en ;
    rdfs:comment "Official FIRST definitions for each TLP level."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "Not for disclosure, restricted to participants only. Sources may use TLP:RED when information cannot be effectively acted upon by additional parties, and could lead to impacts on a party's privacy, reputation, or operations if misused."^^vocabulary:TLPDefinitionVocab
            "Limited disclosure, restricted to participants' organizations. Sources may use TLP:AMBER when information requires support to be effectively acted upon, yet carries risks to privacy, reputation, or operations if shared outside of the organizations involved."^^vocabulary:TLPDefinitionVocab
            "Limited disclosure, restricted to the community. Sources may use TLP:GREEN when information is useful for the awareness of all participating organizations as well as with peers within the broader community or sector."^^vocabulary:TLPDefinitionVocab
            "Disclosure is not limited. Sources may use TLP:CLEAR when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release."^^vocabulary:TLPDefinitionVocab
        )
    ] .

vocabulary:CommunityTypeVocab
    a rdfs:Datatype ;
    rdfs:label "Community Type Vocabulary"@en ;
    rdfs:comment "Types of community restrictions that can be applied to TLP:GREEN markings."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "SECTOR"^^vocabulary:CommunityTypeVocab
            "GEOGRAPHIC"^^vocabulary:CommunityTypeVocab
            "ORGANIZATION"^^vocabulary:CommunityTypeVocab
        )
    ] .

vocabulary:SectorVocab
    a rdfs:Datatype ;
    rdfs:label "Sector Vocabulary"@en ;
    rdfs:comment "Enumerated values for sector-based community restrictions, aligned with critical infrastructure sectors."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "AUTOMOTIVE"^^vocabulary:SectorVocab
            "AVIATION"^^vocabulary:SectorVocab
            "CHEMICAL"^^vocabulary:SectorVocab
            "COMMUNICATIONS"^^vocabulary:SectorVocab
            "DEFENSE_INDUSTRIAL_BASE"^^vocabulary:SectorVocab
            "DOWNSTREAM_NATURAL_GAS"^^vocabulary:SectorVocab
            "ELECTIONS_INFRASTRUCTURE"^^vocabulary:SectorVocab
            "EMERGENCY_MANAGEMENT_AND_RESPONSE"^^vocabulary:SectorVocab
            "ELECTRICITY"^^vocabulary:SectorVocab
            "FINANCIAL_SERVICES"^^vocabulary:SectorVocab
            "FOOD_AND_AGRICULTURE"^^vocabulary:SectorVocab
            "HEALTHCARE"^^vocabulary:SectorVocab
            "INFORMATION_TECHNOLOGY"^^vocabulary:SectorVocab
            "MARITIME"^^vocabulary:SectorVocab
            "MARITIME_TRANSPORTATION_SYSTEM"^^vocabulary:SectorVocab
            "MULTI_STATE_GOVERNMENT"^^vocabulary:SectorVocab  # State, Local, Tribal, and Territorial Governments
            "NUCLEAR"^^vocabulary:SectorVocab
            "OIL_AND_NATURAL_GAS"^^vocabulary:SectorVocab
            "PUBLIC_TRANSIT"^^vocabulary:SectorVocab
            "REAL_ESTATE"^^vocabulary:SectorVocab
            "RESEARCH_AND_EDUCATION"^^vocabulary:SectorVocab
            "RETAIL_AND_HOSPITALITY"^^vocabulary:SectorVocab
            "SPACE"^^vocabulary:SectorVocab
            "SUPPLY_CHAIN"^^vocabulary:SectorVocab
            "SURFACE_TRANSPORTATION"^^vocabulary:SectorVocab
            "WATER"^^vocabulary:SectorVocab
        )
    ] .

vocabulary:GeographicRegionVocab
    a rdfs:Datatype ;
    rdfs:label "Geographic Region Vocabulary"@en ;
    rdfs:comment "Enumerated values for geographic-based community restrictions."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "NORTH_AMERICA"^^vocabulary:GeographicRegionVocab
            "SOUTH_AMERICA"^^vocabulary:GeographicRegionVocab
            "EUROPE"^^vocabulary:GeographicRegionVocab
            "ASIA"^^vocabulary:GeographicRegionVocab
            "AFRICA"^^vocabulary:GeographicRegionVocab
            "OCEANIA"^^vocabulary:GeographicRegionVocab
        )
    ] .

This vocabulary definition:

1. Follows UCO's pattern for controlled vocabularies
2. Uses rdfs:Datatype with owl:oneOf for enumerated values
3. Provides separate vocabularies for levels, definitions, and restrictions
4. Aligns sector vocabulary with established ISAC sectors
5. Includes geographic regions for regional sharing restrictions

RDF Implementation

@prefix marking: <https://ontology.caseontology.org/case/marking/> .
@prefix vocabulary: <https://ontology.unifiedcyberontology.org/uco/vocabulary/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

marking:TrafficLightProtocol_2_0 
    a owl:Class ;
    rdfs:subClassOf marking:ReleaseToMarking ;
    rdfs:label "Traffic Light Protocol 2.0 Marking"@en ;
    rdfs:comment "A marking that indicates how and with whom information can be shared according to the Traffic Light Protocol version 2.0 standard."@en ;
    owl:imports <https://ontology.unifiedcyberontology.org/uco/vocabulary/tlp> ;
    owl:versionInfo "2.0.0" ;
    dcterms:issued "2024-03-20"^^xsd:date ;
    dcterms:replaces marking:TrafficLightProtocol_1_0 .

marking:tlpLevel 
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:TLPLevelVocab ;
    rdfs:label "TLP level"@en ;
    rdfs:comment "Specifies the TLP 2.0 classification level for information sharing"@en .

marking:tlpDefinition
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:TLPDefinitionVocab ;
    rdfs:label "TLP definition"@en ;
    rdfs:comment "The official FIRST definition for this TLP level"@en .

marking:communityType
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:CommunityTypeVocab ;
    rdfs:label "community type"@en ;
    rdfs:comment "The type of community restriction (sector, geographic, or organization)"@en .

marking:sector
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:SectorVocab ;
    rdfs:label "sector"@en ;
    rdfs:comment "The specific sector for sector-based community restrictions"@en .

marking:geographicRegion
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:GeographicRegionVocab ;
    rdfs:label "geographic region"@en ;
    rdfs:comment "The specific geographic region for region-based community restrictions"@en .

marking:validUntil 
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range xsd:dateTime ;
    rdfs:label "valid until"@en ;
    rdfs:comment "Specifies the datetime until which this TLP marking is valid"@en .

# Example Usage
_:example1
    a marking:TrafficLightProtocol_2_0 ;
    marking:tlpLevel "RED"^^vocabulary:TLPLevelVocab ;
    marking:tlpDefinition "Not for disclosure, restricted to participants only. Sources may use TLP:RED when information cannot be effectively acted upon by additional parties, and could lead to impacts on a party's privacy, reputation, or operations if misused."^^vocabulary:TLPDefinitionVocab .

_:example2
    a marking:TrafficLightProtocol_2_0 ;
    marking:tlpLevel "GREEN"^^vocabulary:TLPLevelVocab ;
    marking:communityType "SECTOR"^^vocabulary:CommunityTypeVocab ;
    marking:sector "FINANCIAL"^^vocabulary:SectorVocab .

Backward Compatibility

To ensure backward compatibility with existing TLP implementations, this proposal includes the following measures:

1. Version Identification

   • The class and vocabulary explicitly declare their version using owl:versionInfo
   • Both include dcterms:issued and dcterms:replaces to track versioning lineage
   • The vocabulary uses vann:preferredNamespacePrefix for consistent namespace handling

2. Migration Support

   • Systems can identify TLP version through the class URI and version info
   • Existing TLP 1.0 markings remain valid and can coexist with TLP 2.0
   • Automated migration tools can use dcterms:replaces relationships to update markings

3. Data Handling

   • TLP 1.0 markings are treated as valid but deprecated
   • Systems should prefer TLP 2.0 for new markings
   • Existing queries can be updated to handle both versions using UNION patterns

Example migration query:

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

# Update TLP 1.0 RED to TLP 2.0 RED
INSERT {
    ?observable uco-core:hasMarking [
        a uco-marking:TrafficLightProtocol_2_0 ;
        uco-marking:tlpLevel uco-marking:RED ;
        dcterms:created ?now
    ] .
}
WHERE {
    ?observable uco-core:hasMarking ?oldMarking .
    ?oldMarking a uco-marking:TrafficLightProtocol_1_0 ;
               uco-marking:tlpLevel "RED" .
    BIND(NOW() as ?now)
}

Community Engagement

This proposal will benefit from review and feedback from:

1. CASE Community

   • CASE Working Group members
   • Implementers of CASE-based systems
   • Digital forensics tool developers

2. TLP Stakeholders

   • FIRST (Forum of Incident Response and Security Teams)
   • CISA and other government cybersecurity organizations
   • Information sharing communities using TLP

3. Standards Bodies

   • OASIS CTI Technical Committee
   • STIX/TAXII community
   • Cyber threat intelligence platforms

[vulnmaster]

@ajnelson-nist @sbarnum @eoghanscasey and @kchason here is a new proposal that I worked on to help us implement Traffic Light Protocol v2.0 as a subclass of UCO-marking:ReleaseToMarking. Appreciate any feedback you can provide.

[vulnmaster]

@eoghanscasey

[ajnelson-nist]

One remark, though I have not yet had time to go deeply through the proposal's details:

The Marking namespace has never had its concepts demonstrated in an example. This file lists the IRIs of all concepts ever exercised in a CASE example to date, and the marking namespace does not appear within it.

I am reluctant to advance this proposal for a vote without a demonstration on instance data.

Unfortunately, I am unsure how the concepts in the marking space are to be used. UCO avoiding rdfs:domain is detrimental here.

Committee discussions have touched on the marking namespace's concepts, but have left me thinking there is a significant variety of model structures that could be encompassed in "Markings" as intended by the original proposers (who predate my involvement in UCO):

1. The existence of an individual.
2. The identifier of an individual, but its existence may be releasable.
   1. Working with this mode is technically possible by owl:sameAs, but there are nontrivial technology issues to work through with that modeling property.
3. A single property-assignment on an individual (analogous to either rdf:Statement or owl:Axiom).
   1. This reduces to case 1 (existence of an individual) if UCO clarifies practices on reification of RDF properties by using core:Relationship.
4. A set of statements (analogous to a graph).
   1. In RDF, I think this is workable in a quads model, but UCO works based on triples. The transition between the two is non-trivial at least because SPARQL requires syntax adjustments to work in quads-based graphs.

I can think of a way to work around the "quads" need by heavy use of owl:Axiom. But, reifying triples is pretty intense on graph-weight. Any one (1) triple that needs to be annotated with a marking would induce a net five (5) triples.

# The statement to be marked.  (Original, 1 triple; net +0 triples.)
ex:A ex:b 1234 .

# The owl:Axiom.  (Induced, net +4 triples; fully automatically derivable.)
# (Note that OWL syntax rules require this to be a blank node.)
_:x
  a owl:Axiom ;
  owl:annotatedSource ex:a ;
  owl:annotatedProperty ex:b ;
  owl:annotatedTarget 1234
.

# The marking.  (Likely defined by user's organization or higher communal authority.)
kb:MarkingDefinition-da6afbcc-2475-4bc2-98f4-53cc847e2920
  a uco-marking:MarkingDefinition ;
  marking:definitionType "(example)" ;
  .

# The marking applied on the original statement.  (User-assigned, net +1 triple.)
_:x uco-marking:Marking kb:MarkingDefinition-da6afbcc-2475-4bc2-98f4-53cc847e2920 .

I fear without a demonstration of a marking showing the proposal's intent, and perhaps a demonstration of non-conformance with a marking scheme, this proposal is unlikely to be able to succeed.

I also suspect UCO's vocabularies will do sufficiently more harm than good in this case that they should be avoided. Use of markings needs careful encoding of set-membership, and those sets can at times cease to exist, e.g. due to changes in legal authorities. Using strings as a proxy for a class will fail to capture these details.

Any demonstration accompanying this proposal should have a small extension ontology that gets to a concrete sharing example. The properties you proposed ending with ...Type should become abstract OWL classes in the Marking ontology or example-extension ontology, and the vocabulary strings should become concrete classes (probably in the example-extension ontology). There is likely a superclass that could go into the UCO Marking ontology, e.g., marking:Community could be a parent class of this hierarchy:

uco-marking:Community
\
 ex:BusinessSector (subclass of uco-marking:Community)
  \
    ex:FinancialSector (subclass of ex:BusinessSector)

It's not clear to me whether these sets should be encoded as OWL classes, or as some subclass of core:ContextualCompilation.

It would be a good exercise of this proposal's corner cases (and more generally, the Marking namespace) to devise an example of a release to some class that, for whatever reason, ceases to exist. We should be able to identify that a release to that class is valid in a certain time period, but a release after the class ceases to exist is invalid.

For what it is worth, I do not believe I am introducing new fundamental complexity. Modeling information marking is, at its core, a challenging problem.

[vulnmaster]

Thanks for the feedback @ajnelson-nist.

Response created with the assistance of ChatGPT

Narrative Scenario

An investigator has a ProvenanceRecord (an investigative object as per CASE ontology references) that documents the acquisition of a data artifact from a disk image (https://digitalcorpora.org/corpora/disk-images/real-data-corpus). This artifact may contain sensitive threat intelligence. The investigator marks it TLP:GREEN, restricted to a certain business sector community (ex:FinancialSector). The marking allows sharing within that sector until a specified date, aligning with TLP 2.0 specifications.

I am happy to see your community subclassing idea above as we could us uco-marking:Community broadly to define various communities' marking standards and potentially let's us implement many different marking schemes. I chose TLP as it is broadly used in the cyber threat intelligence community. Building on your example:

uco-marking:Community
\
 ex:BusinessSector (subclass of uco-marking:Community)
  \
    ex:SectorOfInterest (subclass of ex:BusinessSector)

I am using "SectorOfInterest" rather than defining a specific sector. Sectors might be "Healthcare", "Academia", "State Department of Transportation", or many other business affiliations.

I created an example based on the scenario above:

`@prefix ex: <http://example.org/ontology#> .
@prefix marking: <https://ontology.unifiedcyberontology.org/uco/marking/> .
@prefix core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix case-investigation: <https://ontology.caseontology.org/case/investigation/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

#####################################################
# Community Modeling as Classes
#####################################################

ex:Community a owl:Class ;
    rdfs:label "Community"@en ;
    rdfs:comment "A grouping or set of entities that share some common interest."@en .

ex:BusinessSector a owl:Class ;
    rdfs:subClassOf ex:Community ;
    rdfs:label "Business Sector"@en ;
    rdfs:comment "A community defined by an industry sector."@en .

ex:SectorOfInterest a owl:Class ;
    rdfs:subClassOf ex:BusinessSector ;
    rdfs:label "Sector of Interest"@en ;
    rdfs:comment "Organizations in the ABC industry."@en .

#####################################################
# Example Marking Instance - TLP:GREEN
#####################################################

:greenMarkingForSectorOfInterest
    a marking:TrafficLightProtocol_2_0 ;
    marking:tlpLevel "GREEN"^^<https://ontology.unifiedcyberontology.org/uco/vocabulary/TLPLevelVocab> ;
    marking:communityRestriction ex:SectorOfInterest ;
    marking:validUntil "2025-01-01T00:00:00Z"^^xsd:dateTime ;
    rdfs:comment "TLP:GREEN data may be shared within the Sector of Interest community."@en .

Linking to a ProvenanceRecord from the References

From the references you provided in https://github.com/ajnelson-nist/CASE-Examples-QC/blob/2a521d863d943ceef7c3e4e1a7b63f0f786935d2/tests/used_concepts.txt , we have:

• https://ontology.caseontology.org/case/investigation/ProvenanceRecord
• https://digitalcorpora.org/corpora/disk-images/real-data-corpus (possible source artifact)
• https://ontology.caseontology.org/case/investigation/Investigation (potentially relevant class to show context)
• https://ontology.unifiedcyberontology.org/uco/core/objectMarking (core property to attach markings—if defined in UCO core or marking namespaces)
• We will assume core:objectMarking is the property used to link a marking to an object. (In UCO, the current property commonly used is uco-core:objectMarking. If needed, this might be adjusted to the correct namespace.)

@prefix ex: <http://example.org/ontology#> .
@prefix marking: <https://ontology.unifiedcyberontology.org/uco/marking/> .
@prefix core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix case-investigation: <https://ontology.caseontology.org/case/investigation/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

#####################################################
# Example Provenance Record
#####################################################

:provenanceRecord1
    a case-investigation:ProvenanceRecord ;
    core:objectMarking :greenMarkingForSectorOfInterest ;
    rdfs:label "Disk Image Provenance Record"@en ;
    rdfs:comment "Provenance record for an artifact derived from real-data-corpus disk images."@en ;
    dcterms:source <https://digitalcorpora.org/corpora/disk-images/real-data-corpus> ;
    dcterms:created "2024-06-15T12:00:00Z"^^xsd:dateTime .

• :provenanceRecord1 is an instance of case-investigation:ProvenanceRecord.
• It is linked to the :greenMarkingForSectorOfInterest marking via core:objectMarking.
• The source of this record is https://digitalcorpora.org/corpora/disk-images/real-data-corpus, which appears in the references from used_concepts.txt.
• This shows how the marking interacts with a real investigative object that references known datasets, aligning better with previously used concepts.

Query Demonstration

A SPARQL query to find all provenance records that can currently be shared with members of the financial sector (before the validUntil date):

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

SELECT ?record
WHERE {
    ?record a case-investigation:ProvenanceRecord ;
            core:objectMarking ?marking .
    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel "GREEN"^^<https://ontology.unifiedcyberontology.org/uco/vocabulary/TLPLevelVocab> ;
             marking:communityRestriction ex:SectorOfInterest ;
             marking:validUntil ?validUntil .

    FILTER(NOW() < ?validUntil)
}

This query ensures we only find records that are shareable under TLP:GREEN restrictions within the financial sector and before the validUntil date has passed.

Handling Community Deactivation

If, in the future, ex:SectorOfInterest ceases to exist or is deprecated:

ex:SectorOfInterest
    owl:deprecated true ;
    rdfs:comment "This sector is no longer recognized as a valid community."@en .

Then a reasoner or compliance checking script might determine that :greenMarkingForSectorOfInterest no longer references a valid current community. Administrators would have to update the marking or remove it. This demonstrates how modeling communities as classes allows the ontology to evolve over time and makes the validity of marks contingent on the ontology’s state.

Conclusion

This revised demonstration:

• Integrates references that appeared in the used_concepts.txt file, such as case-investigation:ProvenanceRecord and https://digitalcorpora.org/corpora/disk-images/real-data-corpus.
• Shows instance-level data using the core:objectMarking property to attach a TLP:GREEN marking to a real investigative record.
• Highlights how TLP 2.0 markings could be managed and queried in a realistic scenario, while still allowing the ontology to evolve (e.g., deprecating a community class).