Need ability to represent concept of a Datasource

[Bradichus]

Background

UCO currently has no ability to express or characterize the concept of a datasource where some sort of data may be available.
This is a key requirement for the risk application domain ontology, is already part of the Adversary Engagement Ontology (AEO), and will almost certainly be equally important to the cyber threat intel (CTI) application domain ontology.
The risk application domain ontology that is being prepared for formal submission under CDO currently models this concept and is using it extensively in an operational sense.

Such a datasource concept is useful within CDO to characterize relevant details of the datasource as well as relate it to other concepts such as what sorts of data may be available from the datasource (e.g., employees of an organization, locations of equipment, cyber incidents within an industry sector, etc.).
To support modeling of data flows it would also be useful to have the ability to express of characterize the concept of a data target where data could transferred to.

Requirements

Requirement 1

Ability to express the name and description of a datasource

Requirement 2

Ability to express what type (e.g., person, document, database, service, etc.) of datasource it is

Requirement 3

Ability to express the scope of availability of the datasource

Requirement 4

Ability to express available mechanisms (e.g., manual, API, structured query, etc.) for accessing the datasource

Requirement 5

Ability to describe the location of the datasource

Requirement 6

Ability to express the cost of accessing the datasource

Requirement 7

Ability to specify relationships between datasources and other CDO domain concepts (UcoObjects)

Requirement 8

Ability to express the name and description of a data target

Requirement 9

Ability to describe the location of the data target

Risk / Benefit analysis

Benefits

• Ability to identify and provide details of various sources of data
• Ability to identify and provide details of various targets of data flow
• Ability to describe flows of data between various datasources and data targets
• Ability to relate particular sources or targets of data to other CDO domain concepts (UcoObjects)
• Increase the operational practicality of leveraging CDO-based data for real-world use cases
• Basis of support for automation of datasource access as part of an overall CDO ecosystem

Risks

None

Solution suggestion

• add new core:DataSource class:
• add new core:DataTarget class:
• add new vocabulary:DataSourceTypeVocab vocabulary;
• add new vocabulary:AvailabilityScopeVocab vocabulary;
• add new vocabulary:AccessMethodVocab vocabulary;
• add new core:accessMethod property;
• add new core:availabilityScope property;
• add new core:dataSourceCost property;
• add new core:dataSourceType property;
• add new core:dataSourceLocationDescription property;
• add new core:dataTargetLocationDescription property;
• add new associated property shapes on core:DataSource
• add new associated property shapes on core:DataTarget

Solution discussion

Simple example diagram showing Datasource (bolded outline) use by Adversary Engagement Ontology (AEO):

Simple example diagram showing Datasource (bolded outline) use by Risk application domain ontology:

Simple example diagram showing Datasource (bolded outline) use by Cyber Threat Intelligence (CTI) application domain ontology:

Coordination

• Tracking in Jira ticket OCUCO-309

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2024-02-15
• Requirements to be discussed in OC meeting, 2024-05-30 (rescheduled from Mar. 14)
• Requirements to be discussed in OC meeting, date TBD

• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solution announced to OCs on TODO-date
• Solutions Approval to be discussed in OC meeting, date TBD
• Solutions Approval vote has not occurred

• Solutions development phase completed.
• Backwards-compatible implementation merged into develop for the next release
• develop state with backwards-compatible implementation merged into develop-2.0.0
• Backwards-incompatible implementation merged into develop-2.0.0 (or N/A)
• Milestone linked
• Documentation logged in pending release page
• Prerelease publication: CASE develop branch updated to track UCO's updated develop branch
• Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch

[ajnelson-nist]

@Bradichus : FYI, I get emails on this repository. I've agreed with @sbarnum to mostly ignore them. However, I might "butt in" from time to time to suggest additions that could make the public discussion have less round-trips.

If you need a living public-resource example, you could use the National Vulnerability Database's feed:

https://nvd.nist.gov/general/news/api-20-announcements

(EDITED TO ADD 2023-08-18: This comment was posted on this Issue when it was in a private drafting/tech-check repository. It was apparently transferred from there.)

[Bradichus]

@ajnelson-nist I appreciate the resources and the feedback you have been sending in! Been a little chaotic on my side so I usually read the comments and forget to respond or thumbs up it.

[ajnelson-nist]

I think it will be important to see at least one of those figures rendered as instance data (JSON-LD or Turtle). I don't doubt the feasibility of this proposal, but I don't understand some of the proposal's interlocking pieces from those diagrams. I'll suggest again that the NVD data feed is an available demonstration subject.

I'm also aware that we have lamented the overload occurring in the Observable namespace, but, @sbarnum or @Bradichus , can you explain why the majority of this proposal is going into Core instead of Observable or another namespace? One technical matter to consider is that this proposal's current state suggests adding some new vocabularies that would tie to new classes in Core, and that would introduce a first dependency from Core onto the Vocabulary namespace.

[ajnelson-nist]

In last week's call, some questions came up on specific representation details suggested by one of the diagrams. The "CanaryTokenAlertLog" green node in the first diagram, and whether that node would be typed as a File and a DataSource, was a specific interest point. This proposal is awaiting a data sketch in Turtle or JSON-LD before we consider whether the requirements are sufficiently specified.

[ajnelson-nist]

Some committee members, me among them, also raised the question of whether DataSource is a specialization of Role.

[ajnelson-nist]

@sbarnum - If you don't have the cycles to flesh out the rest of that diagram as instance data, we might be able to make progress on this proposal if we get a specific representation from you on how "CanaryTokenAlertLog" is represented. Is it both a File and DataSource?

[sbarnum]

@sbarnum - If you don't have the cycles to flesh out the rest of that diagram as instance data, we might be able to make progress on this proposal if we get a specific representation from you on how "CanaryTokenAlertLog" is represented. Is it both a File and DataSource?

Sorry for the continued delays. Too many knives to juggle.
Yeah, that is a dense diagram to try to create full instance data for. I think we should definitely get there eventually but agree with you that it would likely be useful to start with a few smaller pieces of it.
Let me reach out to the folks leading the Adversary Engagement Ontology work to hopefully get some practically accurate instance content for some of the AEO pieces of that diagram including CanaryTokenAlertLog.