ajnelson-nist
commented
2 years ago @sbarnum , this proposal complicates the review process. You were not the one who filed Issue 405, and this issue performs a few expansions - one to "union-expand" the applicability of the configuration from 405, from Tool to Tool or Software (which I'm pretty much fine with), but then also create an entire namespace devoted to effectively one object. I haven't gone through and parsed your semi-formal language description and I am still addressing other filed proposals, so I don't entirely know the extent of what your sketched solution entails.
Unless the proposer for 405 agrees to withdraw that proposal and let this supersede, we will continue with reviewing 405, and treat 432 as an independent follow-on proposal.
Rather than ask us to mentally parse your language into mental UML models, I encourage you to draft your proposal in a file drafting.ttl in this directory, to demonstrate its feasibility:
https://github.com/casework/CASE-Examples/tree/master/examples/illustrations/configured_tool
That directory contains a tested transcription of the example in your last comment from 405. If you run make after writing drafting.ttl and revising configured_tool.json, you'll see how well the draft implementation works out.
sbarnum
plbt5
eoghanscasey
Background
This change proposal is an extended revision to CP-405 and should completely replace it.
Need to represent multiple different configurations of the same tool, each referencing the same Tool object. Knowing what tool was run for each different configuration should be represented as a link in the graph, and not rely on the string name value. In addition, tool configuration needs an added property to reference an object that was provided as an argument/input to the Tool (e.g. so you could have a graph-object for NSRL-as-of-March-2022 or ClamAV signature-database version X, and show where in the graph that object had been involved in decision processes).
The need to express configuration details is not unique to Tool. It is equally relevant to observable:Software.
A flexible and consistent approach is needed to specify configuration details (including literal key/value pair settings as well as more complex object values) in a way that supports both tool and software user cases. Such an approach should seek to maximize brevity, consistency, and flexiblity while minimizing duplication throughout the UCO ontology.
Requirements
Requirement 1
UCO must be able to represent how a tool or software was configured at the time of its invocation.
Requirement 2
A tool or software configuration that uses an object (such as a file or service endpoint) must be representable similar to the literal-valued tool:itemValue.
Requirement 3
UCO must be able to represent that one too or softwarel was used under multiple configurations.
Requirement 4
UCO must be able to use one tool or software configuration in multiple invocations. E.g. if a tool analyzer_engine has a configuration involving calling it on the command line with the flag --auto-detect-content-type, and the tool is called once per input file for two input files, those two tool invocations should have their action:instrument objects use the same ConfiguredTool.
Requirement 5
UCO must support looking up when a tool or software is used with a certain flag. E.g. if a tool analyzer_engine can take the unparameterized (0-argument) command-line flag --auto-detect-content-type, a UCO graph should be reviewable for when analyzer_engine is configured to use that flag, and in what action:Actions that configuration was used.
Requirement 6
UCO must support looking up when a tool or software is used with a certain flag-value. This applies to object-values (such as a file or service end-point reference), and literal-values (such as a string). E.g. if a tool analyzer_engine can take the parameterized (1-argument) command-line flag --assume-content-type, a UCO graph should be reviewable for when analyzer_engine is configured to use that flag, and in what action:Actions that configuration was used.
Requirement 7
One tool used in multiple configurations should be linkable between those configurations and the actions using those configurations.
Risk / Benefit analysis
Benefits
Permit flexible representation of various configurations of tools and software. Permit representation of multiple different configurations of the same tool or software, while maintaining link to the same Tool or Software
Risks
The submitter is unaware of risks associated with this change.
Competencies demonstrated
Competency 1
When a single tool or software is used in a workflow with multiple configuration sections, determine which Tool was used to obtain all observables, independent of all different tool configurations used.
Competency Question 1.1
What Tool or Software was used to obtain all observables?
Result 1.1
Query returns a single result Tool or Software.
Competency 2
A version of a tool or software known to contain a defect or vulnerability should be locatable within a graph, to understand the impact of results.
Competency Question 2.1
What Tool or Software was used to obtain all observables?
Result 2.1
Query returns all results affected by the defect or vulnerability.
Competency Question 2.2
A Software version 1.0 is known to have a vulnerability. What related devices or systems may be vulnerable do to the Software under any configuration.
Result 2.2
Query returns all related objects that may be vulnerable due to their relationship with the affected Software.
Competency 3
When different versions of a resource (e.g., NSRL hashset, AntiVirus database) were provided in various Tool Configuration objects, determine which resource was provided as an argument to a given Tool Configuration object.
Competency Question 3.1
What resource was referenced in the itemObject property of a given Tool Configuration object?
Result 3.1
Query returns a single object that was referenced in the itemObject of the given Tool Configuration object.
Solution suggestion
Additions
Modifcations
Deletions
Examples
Example of an Action using a Tool with a Configuration
Example of Multiple Actions each using a Tool with different Configurations
Example of a Software with a Configuration
Coordination
develop