casework
Add Analyst Role to CASE
This change proposal written with the assistance of AI. Turtle representations are CASE SHACL validated.
Background
In the discussion during the CDO Ontology Committee meeting on October 21, 2025, all committee members present identified and concurred on the need to add an Analyst role to CASE investigation:Investigation. Currently, the CASE investigation ontology defines several role classes (Attorney, Examiner, Investigator, Subject, and the proposed Technician role in the CASE PR) but lacks explicit representation for the Analyst role, which plays a distinct role in digital forensics and cyber investigations.
This role is distinct from Examiners (who are involved in providing scientific evaluations of evidence that are used to aid law enforcement investigations and court cases) and Technicians (who focus on evidence handling and processing, etc). Adding an Analyst class will enhance the ontology's ability to accurately represent more key participants in investigative workflows, improving provenance tracking and role-based analytics.
Definition: An Analyst is fundamentally a role practiced by a subject matter expert where they research and review data, artifacts, processes, patterns, relationships, strengths, weaknesses, opportunities, threats, and then produce analytic reports with assessments, interpretations and recommendations for decision makers. In the realm of cyber investigation, Analysts are often consulted by Attorneys, Examiners, Investigators, and Technicians for advice based on their specific area of expertise.
Note: @vulnmaster combined several other definitions of analyst as other sources tend to define specific subclasses of analyst as established work roles and do not define a general analyst well. For example, dictionary.com defines analyst as "a person who analyzes or who is skilled in analysis".
The analyst role can branch into many sub-roles based on discipline (e.g.; crime analyst, cyber threat analyst).
Requirements
Requirement 1
Create a new class investigation:Analyst as a direct rdfs:subClassOf uco-role:Role, following the established pattern used by other role classes in the ontology (Attorney, Examiner, Investigator, Subject, Technician).
Requirement 2
Define the investigation:Analyst class with appropriate rdfs:label and rdfs:comment properties that accurately describe the analyst's role in investigative processes, including their analytical responsibilities and typical scope of work.
Risk / Benefit analysis
Benefits
- Semantic completeness – enables accurate representation of all personnel involved in investigations, including analytical staff who perform specialized data analysis
- Enhanced provenance tracking – allows systems to distinguish between evidence collection (by technicians), analytical interpretation (by analysts), and formal examination (by examiners)
- Improved interoperability – aligns with standard forensic and intelligence community terminology and facilitates data exchange between organizations
- Better analytics – supports role-based queries for workforce planning, training needs, analytical quality assurance, and investigation efficiency metrics
- Intelligence integration – facilitates representation of cyber threat intelligence workflows and threat hunting activities
Risks
The submitter is unaware of risks beyond routine ontology-maintenance overhead (documentation updates, potential SHACL test additions). No existing CASE instances break, as this is purely additive.
Competencies demonstrated
Competency 1 – Digital forensics analytical workflow
Scenario
A cyber investigation involves analysts performing detailed analysis of digital evidence, identifying patterns across multiple data sources, correlating events to establish timelines, and producing analytical reports. The investigation:Analyst role class enables accurate representation of these personnel in investigative workflows, including tracking role assignments with temporal information (appointment dates) and linking analytical actions to their roles.
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 xsd: <http://www.w3.org/2001/XMLSchema#> .
# The investigation
kb:investigation-a1b2c3d4-e5f6-4a8b-9c0d-1e2f3a4b5c6d
a case-investigation:Investigation ;
uco-core:name "Network Intrusion Analysis - Case 2024-002" ;
case-investigation:investigationForm "case" ;
case-investigation:investigationStatus "open" ;
case-investigation:focus "Cyber intrusion analysis and threat attribution" ;
uco-core:object kb:disk-imaging-action-b2c3d4e5-f6a7-4b9c-8d1e-2f3a4b5c6d7e ,
kb:examination-action-c3d4e5f6-a7b8-4c0d-9e2f-3a4b5c6d7e8f ,
kb:analysis-action-d4e5f6a7-b8c9-4d1e-8f3a-4b5c6d7e8f9a .
# Technician identity and role
kb:technician-identity-e5f6a7b8-c9d0-4e2f-9a4b-5c6d7e8f9a0b
a uco-core:Identity ;
uco-core:name "Forensic Technician Smith" ;
uco-core:role kb:technician-role-f6a7b8c9-d0e1-4f3a-8b5c-6d7e8f9a0b1c .
kb:technician-role-f6a7b8c9-d0e1-4f3a-8b5c-6d7e8f9a0b1c
a case-investigation:Technician ;
uco-core:startTime "2024-03-08T09:00:00Z"^^xsd:dateTime .
# Examiner identity and role
kb:examiner-identity-a7b8c9d0-e1f2-4a4b-9c6d-7e8f9a0b1c2d
a uco-core:Identity ;
uco-core:name "Digital Forensics Examiner Davis" ;
uco-core:role kb:examiner-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e .
kb:examiner-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e
a case-investigation:Examiner ;
uco-core:startTime "2024-03-09T10:00:00Z"^^xsd:dateTime .
# Analyst identity and role
kb:analyst-identity-c9d0e1f2-a3b4-4c6d-9e8f-9a0b1c2d3e4f
a uco-core:Identity ;
uco-core:name "Cyber Analyst Johnson" ;
uco-core:role kb:analyst-role-d0e1f2a3-b4c5-4d7e-8f9a-0b1c2d3e4f5a .
kb:analyst-role-d0e1f2a3-b4c5-4d7e-8f9a-0b1c2d3e4f5a
a case-investigation:Analyst ;
uco-core:startTime "2024-03-10T08:00:00Z"^^xsd:dateTime .
# Technician's disk imaging action
kb:disk-imaging-action-b2c3d4e5-f6a7-4b9c-8d1e-2f3a4b5c6d7e
a case-investigation:InvestigativeAction ;
uco-core:name "Disk imaging of compromised workstation" ;
uco-action:performer kb:technician-role-f6a7b8c9-d0e1-4f3a-8b5c-6d7e8f9a0b1c ;
uco-action:object kb:workstation-e1f2a3b4-c5d6-4e8f-9a0b-1c2d3e4f5a6b ;
uco-action:result kb:disk-image-f2a3b4c5-d6e7-4f9a-8b1c-2d3e4f5a6b7c ;
uco-core:startTime "2024-03-08T09:30:00Z"^^xsd:dateTime .
# Examiner's systematic examination action
kb:examination-action-c3d4e5f6-a7b8-4c0d-9e2f-3a4b5c6d7e8f
a case-investigation:InvestigativeAction ;
uco-core:name "Systematic examination using scientific method" ;
uco-action:performer kb:examiner-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e ;
uco-action:object kb:disk-image-f2a3b4c5-d6e7-4f9a-8b1c-2d3e4f5a6b7c ;
uco-action:result kb:findings-a3b4c5d6-e7f8-4a0b-9c2d-3e4f5a6b7c8d ;
uco-core:startTime "2024-03-09T10:15:00Z"^^xsd:dateTime .
# Analyst's malware analysis action
kb:analysis-action-d4e5f6a7-b8c9-4d1e-8f3a-4b5c6d7e8f9a
a case-investigation:InvestigativeAction ;
uco-core:name "Malware behavioral analysis" ;
uco-action:performer kb:analyst-role-d0e1f2a3-b4c5-4d7e-8f9a-0b1c2d3e4f5a ;
uco-action:object kb:malware-sample-b4c5d6e7-f8a9-4b1c-8d3e-4f5a6b7c8d9e ;
uco-action:result kb:report-c5d6e7f8-a9b0-4c2d-8e4f-5a6b7c8d9e0f ;
uco-core:startTime "2024-03-10T08:30:00Z"^^xsd:dateTime .
# Evidence objects
kb:workstation-e1f2a3b4-c5d6-4e8f-9a0b-1c2d3e4f5a6b
a uco-observable:Computer ;
uco-core:description "Compromised workstation from network intrusion" ;
uco-core:hasFacet [
a uco-observable:ComputerFacet , uco-core:Facet ;
uco-observable:hostname "workstation-001" ;
uco-observable:manufacturer "Dell" ;
uco-observable:model "OptiPlex 7090"
] .
kb:disk-image-f2a3b4c5-d6e7-4f9a-8b1c-2d3e4f5a6b7c
a uco-observable:File ;
uco-core:description "Forensic disk image of compromised workstation" ;
uco-core:hasFacet [
a uco-observable:FileFacet , uco-core:Facet ;
uco-observable:fileName "workstation-001-forensic-image.dd" ;
uco-observable:sizeInBytes 500107862016
] .
kb:malware-sample-b4c5d6e7-f8a9-4b1c-8d3e-4f5a6b7c8d9e
a uco-observable:File ;
uco-core:description "Suspected malware executable discovered during examination" ;
uco-core:hasFacet [
a uco-observable:FileFacet , uco-core:Facet ;
uco-observable:fileName "suspicious.exe" ;
uco-observable:sizeInBytes 2048576
] .
# Results/reports
kb:findings-a3b4c5d6-e7f8-4a0b-9c2d-3e4f5a6b7c8d
a uco-observable:File ;
uco-core:description "Systematic examination findings identifying suspicious files" ;
uco-core:hasFacet [
a uco-observable:FileFacet , uco-core:Facet ;
uco-observable:fileName "examination-findings-2024-002.pdf" ;
uco-observable:sizeInBytes 2048000
] .
kb:report-c5d6e7f8-a9b0-4c2d-8e4f-5a6b7c8d9e0f
a uco-observable:File ;
uco-core:description "Malware analysis report identifying trojan behavior and C2 infrastructure" ;
uco-core:hasFacet [
a uco-observable:FileFacet , uco-core:Facet ;
uco-observable:fileName "malware-analysis-report-2024-002.pdf" ;
uco-observable:sizeInBytes 1536000
] .
Competency Question 1.1
Which investigative actions were performed by analysts, and which personnel hold those analyst roles?
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/>
SELECT ?action ?actionName ?identity ?analystName
WHERE {
?analystRole a case-investigation:Analyst .
?action a case-investigation:InvestigativeAction ;
uco-core:name ?actionName ;
uco-action:performer ?analystRole .
OPTIONAL {
?identity uco-core:role ?analystRole ;
uco-core:name ?analystName .
}
}
Result 1.1
Returns investigative actions performed by analysts, along with the personnel identities holding those roles. This enables tracking of analytical tasks (e.g., malware analysis, threat intelligence correlation, timeline analysis, data pattern identification) performed by analysts, supporting proper attribution, analytical quality assurance, and role-based analytics for workforce planning and investigation efficiency metrics.
Competency 2 – Multi-role investigation workflow
Scenario
A complex investigation involves multiple roles working collaboratively: a Technician performs disk imaging and sends the disk image to an Examiner, who then uses the scientific method to examine the evidence systematically. During this examination, the Examiner discovers a suspicious file and sends it to an Analyst who specializes in malware analysis. The Analyst analyzes the suspicious file to determine it is malware and publishes a comprehensive report with indicators of compromise. This demonstrates how different roles contribute to the investigative workflow, with clear separation between examination (Examiner) and analysis (Analyst) functions.
Competency Question 2.1
What is the sequence of actions across different roles in an investigation, ordered by time, and what evidence was discovered and analyzed?
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/>
SELECT ?action ?actionName ?roleType ?performer ?startTime ?evidence ?evidenceType ?report
WHERE {
?investigation a case-investigation:Investigation ;
uco-core:object ?action .
?action a case-investigation:InvestigativeAction ;
uco-core:name ?actionName ;
uco-action:performer ?performer ;
uco-action:object ?evidence ;
uco-action:result ?report .
?performer a ?roleType ;
uco-core:startTime ?startTime .
?evidence a ?evidenceType .
?report a uco-observable:File .
FILTER(?roleType IN (case-investigation:Technician, case-investigation:Examiner, case-investigation:Analyst))
}
ORDER BY ?startTime
Result 2.1
Returns the chronological sequence of investigative actions performed by different roles, showing how a Technician's disk imaging leads to an Examiner's systematic examination using the scientific method and discovery of suspicious files, followed by an Analyst's malware analysis and production of indicators of compromise reports. This enables workflow analysis, identification of evidence handoffs between roles, and understanding of the investigation's progression through different phases (evidence collection → systematic examination → malware analysis → reporting), demonstrating clear role separation between examination and analysis functions.
Solution suggestion
-
Ontology edits
- Add the
case-investigation:Analystclass definition in the Investigation ontology module following the established pattern:
case-investigation:Analyst a owl:Class , sh:NodeShape ; rdfs:subClassOf uco-role:Role ; rdfs:label "Analyst"@en ; rdfs:comment "An Analyst is fundamentally a role practiced by a subject matter expert where they research and review data, artifacts, processes, patterns, relationships, strengths, weaknesses, opportunities, threats, and then produce analytic reports with assessments, interpretations and recommendations for decision makers. In the realm of cyber investigation, Analysts are often consulted by Attorneys, Examiners, Investigators, and Technicians for advice based on their specific area of expertise."@en ; sh:targetClass case-investigation:Analyst ; . - Add the
-
Documentation
- Update the CASE documentation to include the Analyst role in role descriptions and examples
- Add usage examples showing Analyst interactions with other roles (Technician, Examiner, Investigator) in investigative workflows
- Document the distinction between Analyst, Technician, and Examiner roles to clarify when each should be used
-
Testing
- Add validation tests to ensure proper integration with existing role classes
- Create example instances demonstrating Analyst role usage in investigative scenarios
- Include examples of multi-role workflows showing collaboration between Technicians, Analysts, and Examiners
This implementation maintains backward compatibility while enhancing the ontology's ability to represent the full spectrum of investigative personnel roles, particularly in cyber investigations and threat intelligence contexts.
@ajnelson-nist @plbt5 @sbarnum this is ready for your initial review so we can get it scheduled for the next CDO OC's requirements review.
I like the example and it's very clear.
This might take this a bit sideways, but I'm stating to see more complexity with this refinement of roles as the examples progress, so the comments below are really just more discussion points on the topic.
As more roles get added and start to have terms that align with job roles it's going to be hard to not think of these as job titles, rather than collections of activities that are usually undertaken by a person, which seems to be the intent? How can we make clear this isn't just a job title?
I guess at a high level is the approach here to use the literature, make a best effort at defining these terms (examiner, analyst etc) and show how they are, or can be considered to be different roles.
I think if that happens to get anywhere close to universal happiness with these definitions, it might need to incorporate some element of uncertainty/imprecision: e.g. include in the definition that "exact activities carried out by this role vary, but it typically involves...." - but does that essentially make a definition meaningless?
On the other hand, given the challenges of different organisations/countries calling roles different things, and they potentially undertake different activities, does this point to a route of needing to define organisational context to be able to apply a meaningful role (see example below).
(I've picked a deliberately simple set of activities here to keep the example short)
activity_set = {survey, acquire, examine, analyse, reporting}
Organisation A csi -> {survey} technician -> {acquire} analyst -> {examine, analyse, reporting}
Organisation B forensic analyst -> {acquire, examine, analyse, reporting}
Organisation C examiner -> {examine, analyse, reporting}
This does lets you see a few things which are interesting: Organisation A has different people doing acquistion (technicians) to examination and analysis (analyst) Organisation B uses 'forensic analyst' to do all roles from acquisition to analyst to reporting. Organisation C has the role called 'examiner' which is (at this granularity) functionally equivalent to analyst in organisation A.
As an aside, this activity mapping could actually be done at the SOLVE-IT objective, or even technique level and used to precisely define the roles that people have on a functional basis.
@chrishargreaves thanks for the feedback. Having been a hiring manager across several companies, I can tell you that job titles oftentimes have little to do with the actual roles that people perform each day. For example, my current job title is "Chief Technology Officer" because I am responsible for all of the technology development and strategy, but I fulfill all kinds of roles within my position. Sometimes I am doing programming tasks, sometimes I am doing analysis tasks, sometimes I am negotiating agreements, and sometimes I am doing marketing tasks among several other roles required to run a small business. In my years working inside large corportions, I found that job titles are created by the human resources office to align pay bands and performance criteria. In my previous job, my job title was "Principle Cybersecurity Engineer" while my day-to-day role was "Project Leader" where I performed several sub roles depending on the task I was working on.
Below, I have included a SHACL validated example where my title is Chief Technology Officer, and where I am performing three different analyst roles in one investigation. In a large organization, the CTO might never perform these roles, but in a small cyber threat intelligence business it is likely that the CTO might perform these roles across different subtasks. We are never going to have a global standard for job titles (aka observable:organizationPosition in UCO) but I think that roles can be well defined and subclassed, and we can assume that most people perform more than one role in their job. My main argument is that job titles and roles should remain seperate and it is perfectly normal to present both to provide semantic context.
{
"@context": {
"kb": "http://example.org/kb/",
"case-investigation": "https://ontology.caseontology.org/case/investigation/",
"uco-action": "https://ontology.unifiedcyberontology.org/uco/action/",
"uco-core": "https://ontology.unifiedcyberontology.org/uco/core/",
"uco-identity": "https://ontology.unifiedcyberontology.org/uco/identity/",
"uco-observable": "https://ontology.unifiedcyberontology.org/uco/observable/",
"xsd": "http://www.w3.org/2001/XMLSchema#"
},
"@graph": [
{
"@id": "kb:investigation-multi-org-analysis-a1b2c3d4-e5f6-4a8b-9c0d-1e2f3a4b5c6d",
"@type": "case-investigation:Investigation",
"uco-core:name": "Cross-Organization Cyber Threat Analysis - Case 2024-003",
"case-investigation:investigationForm": "case",
"case-investigation:investigationStatus": "active",
"case-investigation:focus": "Coordinated analysis of malware campaign across multiple organizations",
"uco-core:object": [
{
"@id": "kb:malware-analysis-action-1-b2c3d4e5-f6a7-4b9c-8d1e-2f3a4b5c6d7e"
},
{
"@id": "kb:threat-intel-analysis-action-2-c3d4e5f6-a7b8-4c0d-9e2f-3a4b5c6d7e8f"
},
{
"@id": "kb:pattern-analysis-action-3-d4e5f6a7-b8c9-4d1e-8f3a-4b5c6d7e8f9a"
}
]
},
{
"@id": "kb:cory-hall-identity-e5f6a7b8-c9d0-4e2f-9a4b-5c6d7e8f9a0b",
"@type": "uco-identity:Person",
"uco-core:name": "Cory Hall",
"uco-core:hasFacet": [
{
"@id": "kb:cory-personal-details-f6a7b8c9-d0e1-4f3a-8b5c-6d7e8f9a0b1c",
"@type": ["uco-identity:PersonalDetailsFacet", "uco-core:Facet"],
"uco-identity:familyName": "Hall",
"uco-identity:givenName": "Cory"
},
{
"@id": "kb:cory-occupation-facet-a7b8c9d0-e1f2-4a4b-9c6d-7e8f9a0b1c2d",
"@type": ["uco-identity:OccupationFacet", "uco-core:Facet"],
"uco-observable:organizationPosition": "Chief Technology Officer",
"uco-observable:organizationDepartment": "Office of the CTO"
}
],
"uco-core:role": [
{
"@id": "kb:cory-analyst-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e"
}
]
},
{
"@id": "kb:cory-analyst-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e",
"@type": "case-investigation:Analyst",
"uco-core:description": "Functional analyst role performing malware behavioral analysis, threat intelligence correlation, and pattern identification",
"uco-core:startTime": {
"@type": "xsd:dateTime",
"@value": "2024-03-15T09:00:00Z"
}
},
{
"@id": "kb:malware-analysis-action-1-b2c3d4e5-f6a7-4b9c-8d1e-2f3a4b5c6d7e",
"@type": "case-investigation:InvestigativeAction",
"uco-core:name": "Malware reverse engineering and behavioral analysis",
"uco-action:performer": {
"@id": "kb:cory-analyst-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e"
},
"uco-action:object": {
"@id": "kb:malware-sample-1-c9d0e1f2-a3b4-4c6d-9e8f-9a0b1c2d3e4f"
},
"uco-action:result": {
"@id": "kb:malware-analysis-report-1-d0e1f2a3-b4c5-4d7e-8f9a-0b1c2d3e4f5a"
},
"uco-core:startTime": {
"@type": "xsd:dateTime",
"@value": "2024-03-15T09:30:00Z"
}
},
{
"@id": "kb:threat-intel-analysis-action-2-c3d4e5f6-a7b8-4c0d-9e2f-3a4b5c6d7e8f",
"@type": "case-investigation:InvestigativeAction",
"uco-core:name": "Threat intelligence correlation and attribution analysis",
"uco-action:performer": {
"@id": "kb:cory-analyst-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e"
},
"uco-action:object": {
"@id": "kb:threat-intel-data-e1f2a3b4-c5d6-4e8f-9a0b-1c2d3e4f5a6b"
},
"uco-action:result": {
"@id": "kb:threat-intel-report-f2a3b4c5-d6e7-4f9a-8b1c-2d3e4f5a6b7c"
},
"uco-core:startTime": {
"@type": "xsd:dateTime",
"@value": "2024-03-15T14:00:00Z"
}
},
{
"@id": "kb:pattern-analysis-action-3-d4e5f6a7-b8c9-4d1e-8f3a-4b5c6d7e8f9a",
"@type": "case-investigation:InvestigativeAction",
"uco-core:name": "Cross-organizational attack pattern identification",
"uco-action:performer": {
"@id": "kb:cory-analyst-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e"
},
"uco-action:object": {
"@id": "kb:multi-org-attack-data-a3b4c5d6-e7f8-4a0b-9c2d-3e4f5a6b7c8d"
},
"uco-action:result": {
"@id": "kb:pattern-analysis-report-b4c5d6e7-f8a9-4b1c-8d3e-4f5a6b7c8d9e"
},
"uco-core:startTime": {
"@type": "xsd:dateTime",
"@value": "2024-03-16T10:00:00Z"
}
},
{
"@id": "kb:malware-sample-1-c9d0e1f2-a3b4-4c6d-9e8f-9a0b1c2d3e4f",
"@type": "uco-observable:File",
"uco-core:description": "Suspicious executable from targeted phishing campaign",
"uco-core:hasFacet": {
"@id": "kb:malware-facet-e9f0a1b2-c3d4-4e5f-9a0b-1c2d3e4f5a6b7",
"@type": ["uco-observable:FileFacet", "uco-core:Facet"],
"uco-observable:fileName": "update.exe",
"uco-observable:sizeInBytes": 2048576,
"uco-observable:sha256": "a1b2c3d4e5f6789012345678901234567890123456789012345678901234567890"
}
},
{
"@id": "kb:malware-analysis-report-1-d0e1f2a3-b4c5-4d7e-8f9a-0b1c2d3e4f5a",
"@type": "uco-observable:File",
"uco-core:description": "Detailed malware analysis identifying trojan behavior and C2 infrastructure",
"uco-core:hasFacet": {
"@id": "kb:analysis-report-facet-f0a1b2c3-d4e5-4f6a-9b0c-1d2e3f4a5b6c7",
"@type": ["uco-observable:FileFacet", "uco-core:Facet"],
"uco-observable:fileName": "malware-analysis-report-2024-003.pdf",
"uco-observable:sizeInBytes": 2048000
}
},
{
"@id": "kb:threat-intel-data-e1f2a3b4-c5d6-4e8f-9a0b-1c2d3e4f5a6b",
"@type": "uco-observable:File",
"uco-core:description": "Threat intelligence feeds and indicators of compromise from multiple sources",
"uco-core:hasFacet": {
"@id": "kb:threat-intel-facet-e1f2a3b4-c5d6-4e8f-9a0b-1c2d3e4f5a6b",
"@type": ["uco-observable:FileFacet", "uco-core:Facet"],
"uco-observable:fileName": "threat-intel-feed-2024-003.json",
"uco-observable:sizeInBytes": 1024000
}
},
{
"@id": "kb:threat-intel-report-f2a3b4c5-d6e7-4f9a-8b1c-2d3e4f5a6b7c",
"@type": "uco-observable:File",
"uco-core:description": "Correlated threat intelligence assessment with attribution analysis",
"uco-core:hasFacet": {
"@id": "kb:threat-intel-report-facet-f2a3b4c5-d6e7-4f9a-8b1c-2d3e4f5a6b7c",
"@type": ["uco-observable:FileFacet", "uco-core:Facet"],
"uco-observable:fileName": "threat-intel-report-2024-003.pdf",
"uco-observable:sizeInBytes": 1536000
}
},
{
"@id": "kb:multi-org-attack-data-a3b4c5d6-e7f8-4a0b-9c2d-3e4f5a6b7c8d",
"@type": "uco-observable:File",
"uco-core:description": "Attack data from multiple organizations showing coordinated campaign patterns",
"uco-core:hasFacet": {
"@id": "kb:multi-org-facet-a3b4c5d6-e7f8-4a0b-9c2d-3e4f5a6b7c8d",
"@type": ["uco-observable:FileFacet", "uco-core:Facet"],
"uco-observable:fileName": "attack-data-2024-003.csv",
"uco-observable:sizeInBytes": 2048000
}
},
{
"@id": "kb:pattern-analysis-report-b4c5d6e7-f8a9-4b1c-8d3e-4f5a6b7c8d9e",
"@type": "uco-observable:File",
"uco-core:description": "Cross-organizational pattern analysis identifying coordinated attack campaign",
"uco-core:hasFacet": {
"@id": "kb:pattern-report-facet-b4c5d6e7-f8a9-4b1c-8d3e-4f5a6b7c8d9e",
"@type": ["uco-observable:FileFacet", "uco-core:Facet"],
"uco-observable:fileName": "pattern-analysis-report-2024-003.pdf",
"uco-observable:sizeInBytes": 3072000
}
}
]
}
Yes I agree job titles and activities undertaken may very well not align.
So, sorry if these are naive questions:
So from this example, and thinking in RBAC terms (if that's appropriate), a person activates a role, and that role (e.g. kb:cory-analyst-role-b8c9d0e1-f2a3-4b5c-8d7e-8f9a0b1c2d3e) is the entity performing the investigative action?
So can a person directly be the performer of an investigative action, or is a role always required?
If I do some imaging, do I need to take on a 'technician' role to undertake that action, or does 'chris' just perform the imaging?
Also these roles have start times but none have end times, should they? and if so should an example also include that? e.g. imaging finishes and the technician role ends too?
@chrishargreaves yes a person can be a direct performer of an action. A role is not required to be assigned. Adding roles to performers just adds additional context. The roles could have end times too. I just did not add one.