Need improved and extended abilities to express contextual details around software such as its build, configuration, and deployment

[sbarnum]

Background

UCO currently has very limited expressive capabilities for characterizing information around software. There is a need for some basic capabilities around software contextualization.

There are currently 10 observable object classes (Software, Application, Library, OperatingSystem, Process, ProcessThread, WindowsThread, WindowsTask, Service, WindowsService) defined for characterizing various types of software independent of any context. These are also currently just peers without any explicit semantic hierarchy identifying them as software. These existing software classes should be normalized as subclasses of Software and a small number added relevant to software contextualization.

There is also a very limited expressive capability defined within the Tool namespace to characterize limited information about the build of a software tool. Several of these structures within the Tool namespace duplicate structures already defined elsewhere.
This significant overlap in the Tool namespace has been an issue needing resolution for a long time. This seems like an opportune time to address it as part of cleaning up and extending UCO capabilities for characterizing contextual details around software.

UCO does not currently contain any action subclasses relevant to software contextualization beyond the general Action class. There is a need for at least of basic set of common action subclasses in support of clear and consistent software contextualization.

UCO does not currently provide expressive capability for characterizing details of software build activities or results. There is a need for at least an initial basic set of capabilities in this area to express software build actions and to express details of an actual software build.

UCO does not currently provide expressive capability for characterizing details of software configuration activities or results (or the configuration of other relevant concepts as described below) beyond the general Configuration class. There is a need for at least an initial basic set of capabilities in this area to explicitly express software configuration actions and to express details of an actual software configuration.

UCO does not currently provide expressive capability for characterizing details of software environments where software can contextually exist and operate. There is a need for at least an initial basic set of capabilities in this area to explicitly express environments, their characterization, and their configuration.

UCO does not currently provide expressive capability for characterizing details of cyber infrastructures that can support deployment and operation of software environments where software can contextually exist and operate. There is a need for at least an initial basic set of capabilities in this area to explicitly express infrastructures, their characterization, their configuration, and their management. There is a need within at least the adversary engagement, the cyber threat intelligence, supply chain modeling, and the security operations application domains for the ability to express details about cyber infrastructures and physical infrastructures.

UCO does not currently provide expressive capability for characterizing details of software deployment activities and results. This is also true of deployment at a more general level of ObservableObjects. There is a need for at least an initial basic set of capabilities in this area to express software deployment actions and to express details of an actual software deployment.

The addition of these expressive capabilities for environments, infrastructures, build, configuration, deployment as well as explicit clarity and consistency on software contextualization actions and objects are necessary for a wide range of software related use cases for a wide range of application domains including security operations, cyber investigation, cyber threat intelligence, adversary engagement, security assurance, supply chain modeling, bills of material, etc.

In the diagrams throughout this Change Proposal blue colored bubbles are new classes, solid arrow connectors are properties, and dashed arrow connectors are simple proxies for Relationship objects.

An extremely simple overview of how adding basic support for software build, configuration, deployment, environment, and infrastructure could hang together is provided here. Further detail for each of these areas will be provided in the Solution suggestion areas below.

. . .

. . . .

Requirements

Requirement 1

Ability to characterize common actions related to software At a minimum this should include Alert, Beacon, Build, Configure, Deploy, Evaluate, Execute, Manage, Plan, Implement, Respond, and Obfuscate.

Requirement 2

Ability to characterize different types of software objects At a minimum this should include Software, Code, Application, Script, Library, Package, Process, Compiler, BuildUtility, SoftwareBuild, OperatingSystem, and ServicePack.

Requirement 3

Ability to characterize action of building software

Requirement 4

Ability to characterize a specific software build

Requirement 5

Ability to characterize common types of configurations. At a minimum this should include ObservableObjectConfiguration, SoftwareConfiguration, EnvironmentConfiguration, SoftwareEnvironmentConfiguration, InfrastructureConfiguration, CyberInfrastructureConfiguration, and DeploymentConfiguration.

Requirement 6

Ability to characterize action of configuring an ObservableObject

Requirement 6.1

Ability to characterize action of configuring Software

Requirement 6.1.1

Ability to characterize action of reconfiguring deployed Software

Requirement 7

Ability to to characterize that an ObservableObject has a particular configuration

Requirement 7.1

Ability to characterize that a Software has a particular configuration

Requirement 8

Ability to characterize an environment where something exists or operates

Requirement 8.1

Ability to characterize an environment where a Software exists or operates

Requirement 8.2

Ability to characterize environment prerequisites for a Software to exist or operate

Requirement 9

Ability to characterize an infrastructure that supports something existing or operating

Requirement 9.1

Ability to characterize a physical infrastructure that supports something existing or operating

Requirement 9.2

Ability to characterize an cyber infrastructure that supports something existing or operating

Requirement 9.3

Ability to characterize infrastructure prerequisites for supporting something to exist or operate

Requirement 10

Ability to characterize common infrastructure management actions (deploy, configure, start, stop, etc.)

Requirement 11

Ability to characterize the action of deploying an ObservableObject

Requirement 11.1

Ability to characterize the action of deploying a Software

Requirement 11.1.1

Ability to characterize the action of deploying a Software with a particular configuration

Requirement 11.1.2

Ability to characterize the action of deploying a Software to a software environment

Requirement 11.1.3

Ability to characterize the action of deploying a Software on a cyber infrastructure

Requirement 11.1.4

Ability to characterize the action of deploying a Software using particular instruments

Requirement 11.2

Ability to characterize the action of deploying an observable object. This is indirectly related to software contextualization but is needed by applications domains including adversary engagement, security operations, and cyber threat intelligence. It leverages the same fundamental concepts and mechanisms covered here for software contextualization and so should be addressed as part of the same overall CP.

Requirement 12

Ability to characterize a specific deployment

Requirement 13

Ability to characterize tools in a consistent and non-duplicative manner

Risk / Benefit analysis

Benefits

• Clarity and consistency of different forms of software observable objects
• Clarity and consistency of different types of software contextualization actions
• Cleanup of duplicative and confusing Tool namespace
• Ability to characterize software within its broader context
  • How it was/is/could be built
  • How it was/is/could be configured
  • How and where it was/is/could be deployed including relevant environments and infrastructures
• Very significantly enriches the ability to express details around software

Risks

• Any implementations currently leveraing the Tool class will need to be updated

Solution suggestion

Addressing requirements (illustrations)

Requirement 1

Ability to characterize common actions related to software

At a minimum this should include Alert, Beacon, Build, Configure, Deploy, Evaluate, Execute, Manage, Plan, Implement, Respond, and Obfuscate.

Optimally, it should include the set of specific actions in blue in the below diagram.

Requirement 2

Ability to characterize different types of software objects

At a minimum this should include Software, Code, Application, Script, Library, Package, Process, Compiler, BuildUtility, SoftwareBuild, OperatingSystem, and ServicePack.

Requirement 3 and Requirement 4

Ability to characterize action of building software

Ability to characterize a specific software build

Requirement 5

Ability to characterize common types of configurations.

At a minimum this should include ObservableObjectConfiguration, SoftwareConfiguration, EnvironmentConfiguration, SoftwareEnvironmentConfiguration, InfrastructureConfiguration, CyberInfrastructureConfiguration, and DeploymentConfiguration.

Requirement 6 and Requirement 7

Ability to characterize action of configuring an ObservableObject

Ability to characterize action of configuring Software

Ability to to characterize that an ObservableObject has a particular configuration

Ability to characterize that a Software has a particular configuration

Requirement 6.1.1

Ability to characterize action of reconfiguring deployed Software

Requirement 8

Ability to characterize an environment where something exists or operates

Ability to characterize an environment where a Software exists or operates

Requirement 8.2 and Requirement 9.3

Ability to characterize environment prerequisites for a Software to exist or operate

Ability to characterize infrastructure prerequisites for supporting something to exist or operate

Requirement 9

Ability to characterize an infrastructure that supports something existing or operating

Ability to characterize a physical infrastructure that supports something existing or operating

Ability to characterize an cyber infrastructure that supports something existing or operating

Requirement 10

Ability to characterize common infrastructure management actions (deploy, configure, start, stop, etc.)

Requirement 11

Ability to characterize the action of deploying an ObservableObject

Requirement 11.1

Ability to characterize the action of deploying a Software

Ability to characterize the action of deploying a Software with a particular configuration

Ability to characterize the action of deploying a Software to a software environment

Ability to characterize the action of deploying a Software on a cyber infrastructure

Ability to characterize the action of deploying a Software using particular instruments

Requirement 11.2

Ability to characterize the action of deploying an observable object.

This is indirectly related to software contextualization but is needed by applications domains including adversary engagement, security operations, and cyber threat intelligence. It leverages the same fundamental concepts and mechanisms covered here for software contextualization and so should be addressed as part of the same overall CP.

The orange bubbles in the below diagram are classes defined within the Adversary Engagement Ontology.

Requirement 12

Ability to characterize a specific deployment

Requirement 13

Ability to characterize tools in a consistent and non-duplicative manner

Explicit proposed changes

Action namespace

• Add subclasses of Action for the following
  • Plan
  • Implement
  • Respond
  • Obfuscate

Observable namespace

• Add subclasses of ObservableAction for the following
  • Alert
  • Beacon
  • Build
  • Configure
    • ConfigureSoftware
    • ConfigureEnvironment
    • ConfigureInfrastructure
      • ConifgureCyberInfrastructure
  • SetConfigurationEntry
    • SetEnvironmentConfigurationEntry
    • SetCyberEnvironmentConfigurationEntry
  • Deploy
    • DeploySoftware
    • RollbackSoftwareDeployment
    • DeployInfrasctucture
      • DeployCyberInfrastructure
    • DeployArtifact
  • Evaluate
    • VerifySoftwareDeployment
  • Execute
    • ExecuteSoftware
      • ExecuteScript
        • ExecuteSoftwareDeploymentScript
  • Manage
    • ManageSoftware
    • ManageEnvironment
    • ManageInfrastructure
      • StartCyberInfrastructure
      • StopCyberInfrastructure
• Add the following properties with relevant property shapes on Configure
  • toConfiguration: Configuration (0..many)
• Add the following properties with relevant property shapes on Deploy
  • targetEnvironment: Environment (0..many)
  • targetInfrastructure: Infrastructure (0..many)
• Add subclasses of Software for the following
  • Script
    • DeploymentScript
  • Package
  • Compiler
  • BuildUtility
  • SoftwareBuild
  • ServicePack
• Add subclass of Process for the following
  • Task
    • LinuxTask
  • Service
• Modify WindowsTask to be a subclass of Task rather than ObservableObject
• Modify WindowsService to be a subclass of Service rather than ObservableObject
• Modify the following to be subclasses of Software ratherthan ObservableObject
  • Code
  • Application
  • Library
  • Process
  • OperatingSystem
• Modify ProcessThread to be a subclass of Process rather than ObservableObject
• Modify WindowsService to be a subclass of Service rather than ObservableObject
• Add property shape for 'version' to DeviceFacet
• Add SoftwareBuildFacet
• Add the following properties with relevant property shapes on SoftwareBuildFacet
  • buildOutputLog: String (0..1)
  • buildProject: String (0..1)
  • compilationDate: DateTime (0..1)
  • buildScript: Script (0..1)
  • buildUtility: BuildUtility (0..many)
  • compiler: Compiler (0..many)
  • library: Library (0..many)
  • package: Package (0..many)

Configuration namespace

• Add subclasses of Conifguration for the following
  • ObservableObjectConfiguration
    • SoftwareConfiguration
    • ServiceConfiguration
  • EnvironmentConfiguration
    • SoftwareEnvironmentConfiguration
  • InfrastructureConfiguration
    • CyberInfrastructureConfiguration
  • DeploymentConfiguration

Environment namespace

• Add new Environment namespace
• Add new Environment class as subclass of UcoObject
• Add new SoftwareEnvironment subclass of Environment
• Add the following properties with relevant property shapes on Environment
  • hasCharacterization: UcoObject (0..many)

Infrastructure namespace

• Add new Infrastructure namespace
• Add new Infrastructure class as subclass of UcoObject
• Add new CyberInfrastructure subclass of Infrastructure
• Add new PhysicalInfrastructure subclass of Infrastructure

Deployment namespace

• Add new Deployment namespace
• Add new Deployment class as subclass of UcoObject
• Add new SoftwareDeployment subclass of Deployment
• Add new ArtifactDeployment as subclass of Deployment
• Add the following properties with relevant property shapes on Deployment
  • deploymentAction: Deploy (0..1)
  • deploymentObject: ObservableObject (0..many)
  • deploymentContext: UcoObject (0..many)

Tool namespace

• Add the following properties with relevant property shapes on Tool
  • hasCharacterization: ObservableObject (0..many)
• Remove the following properties and their related property shapes
  • creator
  • references
  • servicePack
  • version
  • buildID
  • buildLabel
• Remove property shapes for the following properties from BuildInformationType and add relevant property shapes to SofwareBuildFacet
  • buildOutputLog: String (0..many)
  • buildProject: String (0..1)
  • buildScript: Script (0..1)
  • buildUtility: BuildUtility (0..many)
  • buildVersion: String (0..1)
  • compilationDate: DateTime (0..1)
  • compilers: Compiler (0..many)
  • libraries: Library (0..many)
• Add the following properties with relevant property shapes on SoftwareBuildFacet
  • package: Package (0..many)
• Remove BuildInformationType
• Remove the following properties and their related property shapes
  • buildUtilityName
  • cpeid
  • swid
  • compilerInformalDescription
  • libraryName
  • libraryVersion
• Remove BuildUtilityType class
• Remove CompilerType class
• Remove LibraryType class

Proposed changes to the Tool namespace are outlined in the below mapping table

Old Tool content	New Form
Tool class	Unchanged except 4 properties removed and 1 property added
- creator	REMOVED - Now represented using DeviceFacet/manufacturer or SoftwareFacet/
- references	REMOVED - Now represented using UcoObject/externalReference
- servicePack	REMOVED - Now represented using SoftwareFacet/version
- toolType	UNCHANGED
- version	REMOVED - Now represented using DeviceFacet/model or SoftwareFacet/version
	(NEW) - hasCharacterization (references the Software or Device that make up the actual tool)
BuildInformationType class	REMOVED
- buildConfiguration	REMOVED - Now represented using BuildUtility -> hasConfiguration -> Configuration
- buildID	REMOVED - Now represented using SoftwareBuildFacet/externalReference/externalIdentifier
- buildLabel	REMOVED - Now represented using SoftwareBuildFacet/tag
- buildOutputLog	MOVED - Now represented using SoftwareBuildFacet/buildOutputLog
- buildProject	MOVED - Now represented using SoftwareBuildFacet/buildProject
- buildScript	MOVED - Now represented using SoftwareBuildFacet/buildScript
- buildUtility	MOVED - Now represented using SoftwareBuildFacet/buildUtility
- buildVersion	MOVED - Now represented using SoftwareBuildFacet/version
- compilationDate	MOVED - Now represented using SoftwareBuildFacet/compilationDate
- compilers	MOVED - Now represented using SoftwareBuildFacet/compiler
- libraries	MOVED - Now represented using SoftwareBuildFacet/library
	(NEW) - SoftwareBuildFacet/package
BuildUtilityType class	REMOVED
- buildUtilityName	REMOVED - Now represented using BuildUtilityFacet/name
- cpeid	REMOVED - Now represented using BuildUtilityFacet/cpeid
- swid	REMOVED - Now represented using BuildUtilityFacet/swid
CompilerType class	REMOVED
- compilerInformalDescription	REMOVED - Now represented using CompilerFacet/description
- cpeid	REMOVED - Now represented using CompilerFacet/cpeid
- swid	REMOVED - Now represented using CompilerFacet/swid
LibraryType class	REMOVED
- libraryName	REMOVED - Now represented using LibraryFacet/name
- libraryVersion	REMOVED - Now represented using LibraryFacet/version

[ajnelson-nist]

From prior discussion in Ontology Committee calls, we had been informed that this proposal was coming, and was also going to be a substantial one, likely in need to break out into smaller proposals.

Having seen it, I agree.

@sbarnum , thank you for the extensive detail. I will turn the explicit proposed changes into a checklist, rather than give this the usual issue progress checklist.

[ajnelson-nist]

@sbarnum One thing I didn't see among the figures is how a software update is represented. Was that meant to be covered, or meant to be deferred, or actually covered but not through using the word "update" in the given terminology?

[packet-rat]

Has there been any considering of utilizing/subsuming/ SBOM as a foundational element for this requirement?

If there’s a practical path to subsume/extend SBOM, we should give it consideration.

[A blue circle with text Description automatically generated] Patrick Maroney | Principal – Cybersecurity | AT&T Services, Inc. Threat Analytics [Image]

From: Sean Barnum @.> Date: Monday, January 29, 2024 at 10:53 AM To: ucoProject/UCO @.> Cc: Subscribed @.***> Subject: [ucoProject/UCO] Need improved and extended abilities to express contextual details around software such as its build, configuration, and deployment (Issue #583) Background UCO currently has very limited expressive capabilities for characterizing information around software. There is a need for some basic capabilities around software contextualization. There are currently 10 observable object classes

Background

UCO currently has very limited expressive capabilities for characterizing information around software. There is a need for some basic capabilities around software contextualization.

There are currently 10 observable object classes (Software, Application, Library, OperatingSystem, Process, ProcessThread, WindowsThread, WindowsTask, Service, WindowsService) defined for characterizing various types of software independent of any context. These are also currently just peers without any explicit semantic hierarchy identifying them as software. These existing software classes should be normalized as subclasses of Software and a small number added relevant to software contextualization.

There is also a very limited expressive capability defined within the Tool namespace to characterize limited information about the build of a software tool. Several of these structures within the Tool namespace duplicate structures already defined elsewhere. This significant overlap in the Tool namespace has been an issue needing resolution for a long time. This seems like an opportune time to address it as part of cleaning up and extending UCO capabilities for characterizing contextual details around software.

UCO does not currently contain any action subclasses relevant to software contextualization beyond the general Action class. There is a need for at least of basic set of common action subclasses in support of clear and consistent software contextualization.

UCO does not currently provide expressive capability for characterizing details of software build activities or results. There is a need for at least an initial basic set of capabilities in this area to express software build actions and to express details of an actual software build.

UCO does not currently provide expressive capability for characterizing details of software configuration activities or results (or the configuration of other relevant concepts as described below) beyond the general Configuration class. There is a need for at least an initial basic set of capabilities in this area to explicitly express software configuration actions and to express details of an actual software configuration.

UCO does not currently provide expressive capability for characterizing details of software environments where software can contextually exist and operate. There is a need for at least an initial basic set of capabilities in this area to explicitly express environments, their characterization, and their configuration.

UCO does not currently provide expressive capability for characterizing details of cyber infrastructures that can support deployment and operation of software environments where software can contextually exist and operate. There is a need for at least an initial basic set of capabilities in this area to explicitly express infrastructures, their characterization, their configuration, and their management. There is a need within at least the adversary engagement, the cyber threat intelligence, supply chain modeling, and the security operations application domains for the ability to express details about cyber infrastructures and physical infrastructures.

UCO does not currently provide expressive capability for characterizing details of software deployment activities and results. This is also true of deployment at a more general level of ObservableObjects. There is a need for at least an initial basic set of capabilities in this area to express software deployment actions and to express details of an actual software deployment.

The addition of these expressive capabilities for environments, infrastructures, build, configuration, deployment as well as explicit clarity and consistency on software contextualization actions and objects are necessary for a wide range of software related use cases for a wide range of application domains including security operations, cyber investigation, cyber threat intelligence, adversary engagement, security assurance, supply chain modeling, bills of material, etc.

In the diagrams throughout this Change Proposal blue colored bubbles are new classes, solid arrow connectors are properties, and dashed arrow connectors are simple proxies for Relationship objects.

An extremely simple overview of how adding basic support for software build, configuration, deployment, environment, and infrastructure could hang together is provided here. Further detail for each of these areas will be provided in the Solution suggestion areas below.

. . .

Software.Deployment.Overview-Software.composition.configuration.environment.infrastructure.simple.overview.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/212f05db-21fd-4bab-8f94-60d8ba1cba60__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8BL06vAo$

. . . .

Software.Deployment.Overview-Software.operational.lifecycle.-.simple.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/e6dfe714-f136-4821-8202-b3a2569edd61__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8dU_Rnwg$

Requirements Requirement 1

Ability to characterize common actions related to software At a minimum this should include Alert, Beacon, Build, Configure, Deploy, Evaluate, Execute, Manage, Plan, Implement, Respond, and Obfuscate.

Requirement 2

Ability to characterize different types of software objects At a minimum this should include Software, Code, Application, Script, Library, Package, Process, Compiler, BuildUtility, SoftwareBuild, OperatingSystem, and ServicePack.

Requirement 3

Ability to characterize action of building software

Requirement 4

Ability to characterize a specific software build

Requirement 5

Ability to characterize common types of configurations. At a minimum this should include ObservableObjectConfiguration, SoftwareConfiguration, EnvironmentConfiguration, SoftwareEnvironmentConfiguration, InfrastructureConfiguration, CyberInfrastructureConfiguration, and DeploymentConfiguration.

Requirement 6

Ability to characterize action of configuring an ObservableObject

Requirement 6.1

Ability to characterize action of configuring Software

Requirement 6.1.1

Ability to characterize action of reconfiguring deployed Software

Requirement 7

Ability to to characterize that an ObservableObject has a particular configuration

Requirement 7.1

Ability to characterize that a Software has a particular configuration

Requirement 8

Ability to characterize an environment where something exists or operates

Requirement 8.1

Ability to characterize an environment where a Software exists or operates

Requirement 8.2

Ability to characterize environment prerequisites for a Software to exist or operate

Requirement 9

Ability to characterize an infrastructure that supports something existing or operating

Requirement 9.1

Ability to characterize a physical infrastructure that supports something existing or operating

Requirement 9.2

Ability to characterize an cyber infrastructure that supports something existing or operating

Requirement 9.3

Ability to characterize infrastructure prerequisites for supporting something to exist or operate

Requirement 10

Ability to characterize common infrastructure management actions (deploy, configure, start, stop, etc.)

Requirement 11

Ability to characterize the action of deploying an ObservableObject

Requirement 11.1

Ability to characterize the action of deploying a Software

Requirement 11.1.1

Ability to characterize the action of deploying a Software with a particular configuration

Requirement 11.1.2

Ability to characterize the action of deploying a Software to a software environment

Requirement 11.1.3

Ability to characterize the action of deploying a Software on a cyber infrastructure

Requirement 11.1.4

Ability to characterize the action of deploying a Software using particular instruments

Requirement 11.2

Ability to characterize the action of deploying an observable object. This is indirectly related to software contextualization but is needed by applications domains including adversary engagement, security operations, and cyber threat intelligence. It leverages the same fundamental concepts and mechanisms covered here for software contextualization and so should be addressed as part of the same overall CP.

Requirement 12

Ability to characterize a specific deployment

Requirement 13

Ability to characterize tools in a consistent and non-duplicative manner

Risk / Benefit analysis Benefits

• Clarity and consistency of different forms of software observable objects

• Clarity and consistency of different types of software contextualization actions

• Cleanup of duplicative and confusing Tool namespace

• Ability to characterize software within its broader context

  • How it was/is/could be built
  • How it was/is/could be configured
  • How and where it was/is/could be deployed including relevant environments and infrastructures

• Very significantly enriches the ability to express details around software

Risks

• Any implementations currently leveraing the Tool class will need to be updated

Solution suggestion Addressing requirements (illustrations) Requirement 1

Ability to characterize common actions related to software

At a minimum this should include Alert, Beacon, Build, Configure, Deploy, Evaluate, Execute, Manage, Plan, Implement, Respond, and Obfuscate.

Optimally, it should include the set of specific actions in blue in the below diagram.

Software.Deployment.Overview-1.-.Actions.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/11eca0a4-d6b9-46ca-948b-11cf725f356d__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8344a5-Q$

Requirement 2

Ability to characterize different types of software objects

At a minimum this should include Software, Code, Application, Script, Library, Package, Process, Compiler, BuildUtility, SoftwareBuild, OperatingSystem, and ServicePack.

Software.Deployment.Overview-2.-.ObservableObjects.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/0a656890-c19d-4b1a-a132-d9b766cdf131__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN88C7RDjE$

Requirement 3 and Requirement 4

Ability to characterize action of building software

Ability to characterize a specific software build

Software.Deployment.Overview-3.4.-.Build.Software.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/32bcde73-8360-4088-89d0-9825f76a907e__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8W24138I$

Requirement 5

Ability to characterize common types of configurations.

At a minimum this should include ObservableObjectConfiguration, SoftwareConfiguration, EnvironmentConfiguration, SoftwareEnvironmentConfiguration, InfrastructureConfiguration, CyberInfrastructureConfiguration, and DeploymentConfiguration.

Software.Deployment.Overview-5.-.Configuration.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/9596987f-288f-477c-9e74-6fa31380fca4__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8-Su6OL4$

Requirement 6 and Requirement 7

Ability to characterize action of configuring an ObservableObject

Ability to characterize action of configuring Software

Ability to to characterize that an ObservableObject has a particular configuration

Ability to characterize that a Software has a particular configuration

Software.Deployment.Overview-6.7.-.Configure.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/686cbb62-3e31-49da-b685-dad607f44b13__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8PK-QzPY$

Requirement 6.1.1

Ability to characterize action of reconfiguring deployed Software

Software.Deployment.Overview-6.1.1.-.Reconfigure.Deployed.Software.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/286ee2ff-6845-42b0-991a-403b41972759__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8EpcPI1Y$

Requirement 8

Ability to characterize an environment where something exists or operates

Ability to characterize an environment where a Software exists or operates

Software.Deployment.Overview-8.-.Environment.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/2ef58683-98be-4085-a6c2-8f13c8de4ba1__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN80bEDstc$

Requirement 8.2 and Requirement 9.3

Ability to characterize environment prerequisites for a Software to exist or operate

Ability to characterize infrastructure prerequisites for supporting something to exist or operate

Software.Deployment.Overview-8.2.9.3.-.Software.Prerequisites.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/20d18810-d9cf-45ed-a93b-c602498118ee__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8eCe_o_0$

Requirement 9

Ability to characterize an infrastructure that supports something existing or operating

Ability to characterize a physical infrastructure that supports something existing or operating

Ability to characterize an cyber infrastructure that supports something existing or operating

Software.Deployment.Overview-9.-.Infrastructure.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/fe146277-f10f-4856-8371-f109faefff39__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN86_Iaqks$

Requirement 10

Ability to characterize common infrastructure management actions (deploy, configure, start, stop, etc.)

Software.Deployment.Overview-10.-.Infrastructure.Management.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/b99ecf90-edef-4c2b-9b1a-0027b58412a9__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN84Yz5W6I$

Requirement 11

Ability to characterize the action of deploying an ObservableObject

Software.Deployment.Overview-11.-.Deploy.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/71ed33f8-5362-457d-a406-4525444d4e0d__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8WMuUkYw$

Requirement 11.1

Ability to characterize the action of deploying a Software

Ability to characterize the action of deploying a Software with a particular configuration

Ability to characterize the action of deploying a Software to a software environment

Ability to characterize the action of deploying a Software on a cyber infrastructure

Ability to characterize the action of deploying a Software using particular instruments

Software.Deployment.Overview-11.1.-.Software.Deployment.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/dc7333f6-d89b-4ca1-8d56-c15ef0c1021d__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8F8ps1LE$

Requirement 11.2

Ability to characterize the action of deploying an observable object.

This is indirectly related to software contextualization but is needed by applications domains including adversary engagement, security operations, and cyber threat intelligence. It leverages the same fundamental concepts and mechanisms covered here for software contextualization and so should be addressed as part of the same overall CP.

The orange bubbles in the below diagram are classes defined within the Adversary Engagement Ontology.

Software.Deployment.Overview-11.2.-.Deploy.Artifact.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/af96c45f-16b1-440d-a52c-0a2fd8471e4c__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8i1uphLE$

Requirement 12

Ability to characterize a specific deployment

Software.Deployment.Overview-12.-.Deployment.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/5e4b571c-0f10-4190-a9b6-b61343bca66c__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8Jr5YD8w$

Requirement 13

Ability to characterize tools in a consistent and non-duplicative manner

Software.Deployment.Overview-13.-.Simple.Overview.of.Tool.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/984b8f95-595a-41df-a043-5cca1a191785__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN82pVxmQo$

Explicit proposed changes Action namespace

• Add subclasses of Action for the following

  • Plan
  • Implement
  • Respond
  • Obfuscate

Observable namespace

• Add subclasses of ObservableAction for the following

  • Alert

  • Beacon

  • Build

  • Configure

    • ConfigureSoftware
    • ConfigureEnvironment

    • ConfigureInfrastructure

      • ConifgureCyberInfrastructure

  • SetConfigurationEntry

    • SetEnvironmentConfigurationEntry
    • SetCyberEnvironmentConfigurationEntry

  • Deploy

    • DeploySoftware

    • RollbackSoftwareDeployment

    • DeployInfrasctucture

      • DeployCyberInfrastructure

    • DeployArtifact

  • Evaluate

    • VerifySoftwareDeployment

  • Execute

    • ExecuteSoftware

      • ExecuteScript

        • ExecuteSoftwareDeploymentScript

  • Manage

    • ManageSoftware
    • ManageEnvironment

    • ManageInfrastructure

      • StartCyberInfrastructure
      • StopCyberInfrastructure

• Add the following properties with relevant property shapes on Configure

  • toConfiguration: Configuration (0..many)

• Add the following properties with relevant property shapes on Deploy

  • targetEnvironment: Environment (0..many)
  • targetInfrastructure: Infrastructure (0..many)

• Add subclasses of Software for the following

  • Script

    • DeploymentScript

  • Package

  • Compiler

  • BuildUtility

  • SoftwareBuild

  • ServicePack

• Add subclass of Process for the following

  • Task

    • LinuxTask

  • Service

• Modify WindowsTask to be a subclass of Task rather than ObservableObject

• Modify WindowsService to be a subclass of Service rather than ObservableObject

• Modify the following to be subclasses of Software ratherthan ObservableObject

  • Code
  • Application
  • Library
  • Process
  • OperatingSystem

• Modify ProcessThread to be a subclass of Process rather than ObservableObject

• Modify WindowsService to be a subclass of Service rather than ObservableObject

• Add property shape for 'version' to DeviceFacet

• Add SoftwareBuildFacet

• Add the following properties with relevant property shapes on SoftwareBuildFacet

  • buildOutputLog: String (0..1)
  • buildProject: String (0..1)
  • compilationDate: DateTime (0..1)
  • buildScript: Script (0..1)
  • buildUtility: BuildUtility (0..many)
  • compiler: Compiler (0..many)
  • library: Library (0..many)
  • package: Package (0..many)

Configuration namespace

• Add subclasses of Conifguration for the following

  • ObservableObjectConfiguration

    • SoftwareConfiguration
    • ServiceConfiguration

  • EnvironmentConfiguration

    • SoftwareEnvironmentConfiguration

  • InfrastructureConfiguration

    • CyberInfrastructureConfiguration

  • DeploymentConfiguration

Environment namespace

• Add new Environment namespace
• Add new Environment class as subclass of UcoObject
• Add new SoftwareEnvironment subclass of Environment

• Add the following properties with relevant property shapes on Environment

  • hasCharacterization: UcoObject (0..many)

Infrastructure namespace

• Add new Infrastructure namespace
• Add new Infrastructure class as subclass of UcoObject
• Add new CyberInfrastructure subclass of Infrastructure
• Add new PhysicalInfrastructure subclass of Infrastructure

Deployment namespace

• Add new Deployment namespace
• Add new Deployment class as subclass of UcoObject
• Add new SoftwareDeployment subclass of Deployment
• Add new ArtifactDeployment as subclass of Deployment

• Add the following properties with relevant property shapes on Deployment

  • deploymentAction: Deploy (0..1)
  • deploymentObject: ObservableObject (0..many)
  • deploymentContext: UcoObject (0..many)

Tool namespace

• Add the following properties with relevant property shapes on Tool

  • hasCharacterization: ObservableObject (0..many)

• Remove the following properties and their related property shapes

  • creator
  • references
  • servicePack
  • version
  • buildID
  • buildLabel

• Remove property shapes for the following properties from BuildInformationType and add relevant property shapes to SofwareBuildFacet

  • buildOutputLog: String (0..many)
  • buildProject: String (0..1)
  • buildScript: Script (0..1)
  • buildUtility: BuildUtility (0..many)
  • buildVersion: String (0..1)
  • compilationDate: DateTime (0..1)
  • compilers: Compiler (0..many)
  • libraries: Library (0..many)

• Add the following properties with relevant property shapes on SoftwareBuildFacet

  • package: Package (0..many)

• Remove BuildInformationType

• Remove the following properties and their related property shapes

  • buildUtilityName
  • cpeid
  • swid
  • compilerInformalDescription
  • libraryName
  • libraryVersion

• Remove BuildUtilityType class

• Remove CompilerType class

• Remove LibraryType class

Proposed changes to the Tool namespace are outlined in the below mapping table Old Tool content New Form Tool class Unchanged except 4 properties removed and 1 property added

• creator REMOVED - Now represented using DeviceFacet/manufacturer or SoftwareFacet/
• references REMOVED - Now represented using UcoObject/externalReference
• servicePack REMOVED - Now represented using SoftwareFacet/version
• toolType UNCHANGED
• version REMOVED - Now represented using DeviceFacet/model or SoftwareFacet/version (NEW) - hasCharacterization (references the Software or Device that make up the actual tool) BuildInformationType class REMOVED
• buildConfiguration REMOVED - Now represented using BuildUtility -> hasConfiguration -> Configuration
• buildID REMOVED - Now represented using SoftwareBuildFacet/externalReference/externalIdentifier
• buildLabel REMOVED - Now represented using SoftwareBuildFacet/tag
• buildOutputLog MOVED - Now represented using SoftwareBuildFacet/buildOutputLog
• buildProject MOVED - Now represented using SoftwareBuildFacet/buildProject
• buildScript MOVED - Now represented using SoftwareBuildFacet/buildScript
• buildUtility MOVED - Now represented using SoftwareBuildFacet/buildUtility
• buildVersion MOVED - Now represented using SoftwareBuildFacet/version
• compilationDate MOVED - Now represented using SoftwareBuildFacet/compilationDate
• compilers MOVED - Now represented using SoftwareBuildFacet/compiler
• libraries MOVED - Now represented using SoftwareBuildFacet/library (NEW) - SoftwareBuildFacet/package BuildUtilityType class REMOVED
• buildUtilityName REMOVED - Now represented using BuildUtilityFacet/name
• cpeid REMOVED - Now represented using BuildUtilityFacet/cpeid
• swid REMOVED - Now represented using BuildUtilityFacet/swid CompilerType class REMOVED
• compilerInformalDescription REMOVED - Now represented using CompilerFacet/description
• cpeid REMOVED - Now represented using CompilerFacet/cpeid
• swid REMOVED - Now represented using CompilerFacet/swid LibraryType class REMOVED
• libraryName REMOVED - Now represented using LibraryFacet/name
• libraryVersion REMOVED - Now represented using LibraryFacet/version

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/583__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8DQw5_3w$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AAYSFYIPYC4AQJLWUP3SPDLYQ7AU3AVCNFSM6AAAAABCPVXFCSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEYDKOBQHAZTCOA__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8KGgORDQ$. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[sbarnum]

Has there been any considering of utilizing/subsuming/ SBOM as a foundational element for this requirement? If there’s a practical path to subsume/extend SBOM, we should give it consideration. [A blue circle with text Description automatically generated] Patrick Maroney | Principal – Cybersecurity | AT&T Services, Inc. Threat Analytics [Image] From: Sean Barnum @.> Date: Monday, January 29, 2024 at 10:53 AM To: ucoProject/UCO @.> Cc: Subscribed @.***> Subject: [ucoProject/UCO] Need improved and extended abilities to express contextual details around software such as its build, configuration, and deployment (Issue #583) Background UCO currently has very limited expressive capabilities for characterizing information around software. There is a need for some basic capabilities around software contextualization. There are currently 10 observable object classes Background UCO currently has very limited expressive capabilities for characterizing information around software. There is a need for some basic capabilities around software contextualization. There are currently 10 observable object classes (Software, Application, Library, OperatingSystem, Process, ProcessThread, WindowsThread, WindowsTask, Service, WindowsService) defined for characterizing various types of software independent of any context. These are also currently just peers without any explicit semantic hierarchy identifying them as software. These existing software classes should be normalized as subclasses of Software and a small number added relevant to software contextualization. There is also a very limited expressive capability defined within the Tool namespace to characterize limited information about the build of a software tool. Several of these structures within the Tool namespace duplicate structures already defined elsewhere. This significant overlap in the Tool namespace has been an issue needing resolution for a long time. This seems like an opportune time to address it as part of cleaning up and extending UCO capabilities for characterizing contextual details around software. UCO does not currently contain any action subclasses relevant to software contextualization beyond the general Action class. There is a need for at least of basic set of common action subclasses in support of clear and consistent software contextualization. UCO does not currently provide expressive capability for characterizing details of software build activities or results. There is a need for at least an initial basic set of capabilities in this area to express software build actions and to express details of an actual software build. UCO does not currently provide expressive capability for characterizing details of software configuration activities or results (or the configuration of other relevant concepts as described below) beyond the general Configuration class. There is a need for at least an initial basic set of capabilities in this area to explicitly express software configuration actions and to express details of an actual software configuration. UCO does not currently provide expressive capability for characterizing details of software environments where software can contextually exist and operate. There is a need for at least an initial basic set of capabilities in this area to explicitly express environments, their characterization, and their configuration. UCO does not currently provide expressive capability for characterizing details of cyber infrastructures that can support deployment and operation of software environments where software can contextually exist and operate. There is a need for at least an initial basic set of capabilities in this area to explicitly express infrastructures, their characterization, their configuration, and their management. There is a need within at least the adversary engagement, the cyber threat intelligence, supply chain modeling, and the security operations application domains for the ability to express details about cyber infrastructures and physical infrastructures. UCO does not currently provide expressive capability for characterizing details of software deployment activities and results. This is also true of deployment at a more general level of ObservableObjects. There is a need for at least an initial basic set of capabilities in this area to express software deployment actions and to express details of an actual software deployment. The addition of these expressive capabilities for environments, infrastructures, build, configuration, deployment as well as explicit clarity and consistency on software contextualization actions and objects are necessary for a wide range of software related use cases for a wide range of application domains including security operations, cyber investigation, cyber threat intelligence, adversary engagement, security assurance, supply chain modeling, bills of material, etc. In the diagrams throughout this Change Proposal blue colored bubbles are new classes, solid arrow connectors are properties, and dashed arrow connectors are simple proxies for Relationship objects. An extremely simple overview of how adding basic support for software build, configuration, deployment, environment, and infrastructure could hang together is provided here. Further detail for each of these areas will be provided in the Solution suggestion areas below. . . . Software.Deployment.Overview-Software.composition.configuration.environment.infrastructure.simple.overview.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/212f05db-21fd-4bab-8f94-60d8ba1cba60__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8BL06vAo$ . . . . Software.Deployment.Overview-Software.operational.lifecycle.-.simple.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/e6dfe714-f136-4821-8202-b3a2569edd61__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8dU_Rnwg$ Requirements Requirement 1 Ability to characterize common actions related to software At a minimum this should include Alert, Beacon, Build, Configure, Deploy, Evaluate, Execute, Manage, Plan, Implement, Respond, and Obfuscate. Requirement 2 Ability to characterize different types of software objects At a minimum this should include Software, Code, Application, Script, Library, Package, Process, Compiler, BuildUtility, SoftwareBuild, OperatingSystem, and ServicePack. Requirement 3 Ability to characterize action of building software Requirement 4 Ability to characterize a specific software build Requirement 5 Ability to characterize common types of configurations. At a minimum this should include ObservableObjectConfiguration, SoftwareConfiguration, EnvironmentConfiguration, SoftwareEnvironmentConfiguration, InfrastructureConfiguration, CyberInfrastructureConfiguration, and DeploymentConfiguration. Requirement 6 Ability to characterize action of configuring an ObservableObject Requirement 6.1 Ability to characterize action of configuring Software Requirement 6.1.1 Ability to characterize action of reconfiguring deployed Software Requirement 7 Ability to to characterize that an ObservableObject has a particular configuration Requirement 7.1 Ability to characterize that a Software has a particular configuration Requirement 8 Ability to characterize an environment where something exists or operates Requirement 8.1 Ability to characterize an environment where a Software exists or operates Requirement 8.2 Ability to characterize environment prerequisites for a Software to exist or operate Requirement 9 Ability to characterize an infrastructure that supports something existing or operating Requirement 9.1 Ability to characterize a physical infrastructure that supports something existing or operating Requirement 9.2 Ability to characterize an cyber infrastructure that supports something existing or operating Requirement 9.3 Ability to characterize infrastructure prerequisites for supporting something to exist or operate Requirement 10 Ability to characterize common infrastructure management actions (deploy, configure, start, stop, etc.) Requirement 11 Ability to characterize the action of deploying an ObservableObject Requirement 11.1 Ability to characterize the action of deploying a Software Requirement 11.1.1 Ability to characterize the action of deploying a Software with a particular configuration Requirement 11.1.2 Ability to characterize the action of deploying a Software to a software environment Requirement 11.1.3 Ability to characterize the action of deploying a Software on a cyber infrastructure Requirement 11.1.4 Ability to characterize the action of deploying a Software using particular instruments Requirement 11.2 Ability to characterize the action of deploying an observable object. This is indirectly related to software contextualization but is needed by applications domains including adversary engagement, security operations, and cyber threat intelligence. It leverages the same fundamental concepts and mechanisms covered here for software contextualization and so should be addressed as part of the same overall CP. Requirement 12 Ability to characterize a specific deployment Requirement 13 Ability to characterize tools in a consistent and non-duplicative manner Risk / Benefit analysis Benefits Clarity and consistency of different forms of software observable objects Clarity and consistency of different types of software contextualization actions Cleanup of duplicative and confusing Tool namespace Ability to characterize software within its broader context How it was/is/could be built How it was/is/could be configured How and where it was/is/could be deployed including relevant environments and infrastructures Very significantly enriches the ability to express details around software Risks Any implementations currently leveraing the Tool class will need to be updated Solution suggestion Addressing requirements (illustrations) Requirement 1 Ability to characterize common actions related to software At a minimum this should include Alert, Beacon, Build, Configure, Deploy, Evaluate, Execute, Manage, Plan, Implement, Respond, and Obfuscate. Optimally, it should include the set of specific actions in blue in the below diagram. Software.Deployment.Overview-1.-.Actions.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/11eca0a4-d6b9-46ca-948b-11cf725f356d__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8344a5-Q$ Requirement 2 Ability to characterize different types of software objects At a minimum this should include Software, Code, Application, Script, Library, Package, Process, Compiler, BuildUtility, SoftwareBuild, OperatingSystem, and ServicePack. Software.Deployment.Overview-2.-.ObservableObjects.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/0a656890-c19d-4b1a-a132-d9b766cdf131__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN88C7RDjE$ Requirement 3 and Requirement 4 Ability to characterize action of building software Ability to characterize a specific software build Software.Deployment.Overview-3.4.-.Build.Software.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/32bcde73-8360-4088-89d0-9825f76a907e__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8W24138I$ Requirement 5 Ability to characterize common types of configurations. At a minimum this should include ObservableObjectConfiguration, SoftwareConfiguration, EnvironmentConfiguration, SoftwareEnvironmentConfiguration, InfrastructureConfiguration, CyberInfrastructureConfiguration, and DeploymentConfiguration. Software.Deployment.Overview-5.-.Configuration.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/9596987f-288f-477c-9e74-6fa31380fca4__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8-Su6OL4$ Requirement 6 and Requirement 7 Ability to characterize action of configuring an ObservableObject Ability to characterize action of configuring Software Ability to to characterize that an ObservableObject has a particular configuration Ability to characterize that a Software has a particular configuration Software.Deployment.Overview-6.7.-.Configure.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/686cbb62-3e31-49da-b685-dad607f44b13__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8PK-QzPY$ Requirement 6.1.1 Ability to characterize action of reconfiguring deployed Software Software.Deployment.Overview-6.1.1.-.Reconfigure.Deployed.Software.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/286ee2ff-6845-42b0-991a-403b41972759__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8EpcPI1Y$ Requirement 8 Ability to characterize an environment where something exists or operates Ability to characterize an environment where a Software exists or operates Software.Deployment.Overview-8.-.Environment.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/2ef58683-98be-4085-a6c2-8f13c8de4ba1__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN80bEDstc$ Requirement 8.2 and Requirement 9.3 Ability to characterize environment prerequisites for a Software to exist or operate Ability to characterize infrastructure prerequisites for supporting something to exist or operate Software.Deployment.Overview-8.2.9.3.-.Software.Prerequisites.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/20d18810-d9cf-45ed-a93b-c602498118ee__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8eCe_o_0$ Requirement 9 Ability to characterize an infrastructure that supports something existing or operating Ability to characterize a physical infrastructure that supports something existing or operating Ability to characterize an cyber infrastructure that supports something existing or operating Software.Deployment.Overview-9.-.Infrastructure.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/fe146277-f10f-4856-8371-f109faefff39__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN86_Iaqks$ Requirement 10 Ability to characterize common infrastructure management actions (deploy, configure, start, stop, etc.) Software.Deployment.Overview-10.-.Infrastructure.Management.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/b99ecf90-edef-4c2b-9b1a-0027b58412a9__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN84Yz5W6I$ Requirement 11 Ability to characterize the action of deploying an ObservableObject Software.Deployment.Overview-11.-.Deploy.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/71ed33f8-5362-457d-a406-4525444d4e0d__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8WMuUkYw$ Requirement 11.1 Ability to characterize the action of deploying a Software Ability to characterize the action of deploying a Software with a particular configuration Ability to characterize the action of deploying a Software to a software environment Ability to characterize the action of deploying a Software on a cyber infrastructure Ability to characterize the action of deploying a Software using particular instruments Software.Deployment.Overview-11.1.-.Software.Deployment.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/dc7333f6-d89b-4ca1-8d56-c15ef0c1021d__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8F8ps1LE$ Requirement 11.2 Ability to characterize the action of deploying an observable object. This is indirectly related to software contextualization but is needed by applications domains including adversary engagement, security operations, and cyber threat intelligence. It leverages the same fundamental concepts and mechanisms covered here for software contextualization and so should be addressed as part of the same overall CP. The orange bubbles in the below diagram are classes defined within the Adversary Engagement Ontology. Software.Deployment.Overview-11.2.-.Deploy.Artifact.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/af96c45f-16b1-440d-a52c-0a2fd8471e4c__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8i1uphLE$ Requirement 12 Ability to characterize a specific deployment Software.Deployment.Overview-12.-.Deployment.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/5e4b571c-0f10-4190-a9b6-b61343bca66c__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8Jr5YD8w$ Requirement 13 Ability to characterize tools in a consistent and non-duplicative manner Software.Deployment.Overview-13.-.Simple.Overview.of.Tool.drawio.png (view on web)https://urldefense.com/v3/__https:/github.com/ucoProject/UCO-Incubator/assets/2760288/984b8f95-595a-41df-a043-5cca1a191785__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN82pVxmQo$ Explicit proposed changes Action namespace Add subclasses of Action for the following Plan Implement Respond Obfuscate Observable namespace Add subclasses of ObservableAction for the following Alert Beacon Build Configure ConfigureSoftware ConfigureEnvironment ConfigureInfrastructure ConifgureCyberInfrastructure SetConfigurationEntry SetEnvironmentConfigurationEntry SetCyberEnvironmentConfigurationEntry Deploy DeploySoftware RollbackSoftwareDeployment DeployInfrasctucture DeployCyberInfrastructure DeployArtifact Evaluate VerifySoftwareDeployment Execute ExecuteSoftware ExecuteScript ExecuteSoftwareDeploymentScript Manage ManageSoftware ManageEnvironment ManageInfrastructure StartCyberInfrastructure StopCyberInfrastructure Add the following properties with relevant property shapes on Configure toConfiguration: Configuration (0..many) Add the following properties with relevant property shapes on Deploy targetEnvironment: Environment (0..many) targetInfrastructure: Infrastructure (0..many) Add subclasses of Software for the following Script DeploymentScript Package Compiler BuildUtility SoftwareBuild ServicePack Add subclass of Process for the following Task LinuxTask Service Modify WindowsTask to be a subclass of Task rather than ObservableObject Modify WindowsService to be a subclass of Service rather than ObservableObject Modify the following to be subclasses of Software ratherthan ObservableObject Code Application Library Process OperatingSystem Modify ProcessThread to be a subclass of Process rather than ObservableObject Modify WindowsService to be a subclass of Service rather than ObservableObject Add property shape for 'version' to DeviceFacet Add SoftwareBuildFacet Add the following properties with relevant property shapes on SoftwareBuildFacet buildOutputLog: String (0..1) buildProject: String (0..1) compilationDate: DateTime (0..1) buildScript: Script (0..1) buildUtility: BuildUtility (0..many) compiler: Compiler (0..many) library: Library (0..many) package: Package (0..many) Configuration namespace Add subclasses of Conifguration for the following ObservableObjectConfiguration SoftwareConfiguration ServiceConfiguration EnvironmentConfiguration SoftwareEnvironmentConfiguration InfrastructureConfiguration CyberInfrastructureConfiguration DeploymentConfiguration Environment namespace Add new Environment namespace Add new Environment class as subclass of UcoObject Add new SoftwareEnvironment subclass of Environment Add the following properties with relevant property shapes on Environment hasCharacterization: UcoObject (0..many) Infrastructure namespace Add new Infrastructure namespace Add new Infrastructure class as subclass of UcoObject Add new CyberInfrastructure subclass of Infrastructure Add new PhysicalInfrastructure subclass of Infrastructure Deployment namespace Add new Deployment namespace Add new Deployment class as subclass of UcoObject Add new SoftwareDeployment subclass of Deployment Add new ArtifactDeployment as subclass of Deployment Add the following properties with relevant property shapes on Deployment deploymentAction: Deploy (0..1) deploymentObject: ObservableObject (0..many) deploymentContext: UcoObject (0..many) Tool namespace Add the following properties with relevant property shapes on Tool hasCharacterization: ObservableObject (0..many) Remove the following properties and their related property shapes creator references servicePack version buildID buildLabel Remove property shapes for the following properties from BuildInformationType and add relevant property shapes to SofwareBuildFacet buildOutputLog: String (0..many) buildProject: String (0..1) buildScript: Script (0..1) buildUtility: BuildUtility (0..many) buildVersion: String (0..1) compilationDate: DateTime (0..1) compilers: Compiler (0..many) libraries: Library (0..many) Add the following properties with relevant property shapes on SoftwareBuildFacet package: Package (0..many) Remove BuildInformationType Remove the following properties and their related property shapes buildUtilityName cpeid swid compilerInformalDescription libraryName libraryVersion Remove BuildUtilityType class Remove CompilerType class * Remove LibraryType class Proposed changes to the Tool namespace are outlined in the below mapping table Old Tool content New Form Tool class Unchanged except 4 properties removed and 1 property added - creator REMOVED - Now represented using DeviceFacet/manufacturer or SoftwareFacet/ - references REMOVED - Now represented using UcoObject/externalReference - servicePack REMOVED - Now represented using SoftwareFacet/version - toolType UNCHANGED - version REMOVED - Now represented using DeviceFacet/model or SoftwareFacet/version (NEW) - hasCharacterization (references the Software or Device that make up the actual tool) BuildInformationType class REMOVED - buildConfiguration REMOVED - Now represented using BuildUtility -> hasConfiguration -> Configuration - buildID REMOVED - Now represented using SoftwareBuildFacet/externalReference/externalIdentifier - buildLabel REMOVED - Now represented using SoftwareBuildFacet/tag - buildOutputLog MOVED - Now represented using SoftwareBuildFacet/buildOutputLog - buildProject MOVED - Now represented using SoftwareBuildFacet/buildProject - buildScript MOVED - Now represented using SoftwareBuildFacet/buildScript - buildUtility MOVED - Now represented using SoftwareBuildFacet/buildUtility - buildVersion MOVED - Now represented using SoftwareBuildFacet/version - compilationDate MOVED - Now represented using SoftwareBuildFacet/compilationDate - compilers MOVED - Now represented using SoftwareBuildFacet/compiler - libraries MOVED - Now represented using SoftwareBuildFacet/library (NEW) - SoftwareBuildFacet/package BuildUtilityType class REMOVED - buildUtilityName REMOVED - Now represented using BuildUtilityFacet/name - cpeid REMOVED - Now represented using BuildUtilityFacet/cpeid - swid REMOVED - Now represented using BuildUtilityFacet/swid CompilerType class REMOVED - compilerInformalDescription REMOVED - Now represented using CompilerFacet/description - cpeid REMOVED - Now represented using CompilerFacet/cpeid - swid REMOVED - Now represented using CompilerFacet/swid LibraryType class REMOVED - libraryName REMOVED - Now represented using LibraryFacet/name - libraryVersion REMOVED - Now represented using LibraryFacet/version — Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/583__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8DQw5_3w$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AAYSFYIPYC4AQJLWUP3SPDLYQ7AU3AVCNFSM6AAAAABCPVXFCSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEYDKOBQHAZTCOA__;!!BhdT!hdihjd1BAuHIJs6yXkQBxTKUvDnsEy2cgRAQye5UjQesuwGD7iyOgg6XCUGr1B-qPBMNNkPpaJs2IdfcbVN8KGgORDQ$. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Yeah, Pat.

SBOM use cases were a key consideration for the approaches and content of this CP. It does not include everything needed but it should help significantly in representing the things needed for defining and using SBOMs.

A BOM application domain ontology is one of the items I am working on targeting some time this year to submit to CDO. Not sure when it will happen for sure as there are several others ahead of it in priority currently.

[aj-stein-nist]

A BOM application domain ontology is one of the items I am working on targeting some time this year to submit to CDO. Not sure when it will happen for sure as there are several others ahead of it in priority currently.

I would definitely be interested in this reviewing this work, and potentially helping pre-review with design and feedback, if you are up to it.

[ajnelson-nist]

PR 589 contains a rough draft of the entirety of this proposal's suggested changes, and some starts on secondary effects. I've also sketched a deprecation practice in the PR, using SHACL to flag when specific deprecated concepts are used.

I still don't think we can do this all as one proposal, but I think I see some parts that will break down cleanly into other proposals, including some for UCO 1.x.0.

[ajnelson-nist]

@sbarnum - The new subclasses of action:Action do not follow current practices on naming Action subclasses. For instance, ObservableAction has a subclass Observation, not Observe. You had the new class names use the infinitive or imperative form of the associated verb. They should use gerunds instead.

[ajnelson-nist]

@sbarnum - How do we represent a software update with the additions of this proposal? Say, in response to a CVE affecting an existing software deployment?

[ajnelson-nist]

@sbarnum : environment:Environment is added as a new class at the top of the UcoObject subclass hierarchy. Its name comes close to a property in another namespace, action:environment. From spelling alone, this could subtly encourage users to try to restrict usage of action:environment to environment:Environments, but I'm not sure that's the intended effect, especially considering the fairly unrestricted range action:environment currently has.

Is environment:Environment disjoint with anything?

Let's say a user has a terminal open, and a Bash[^1] prompt ready to run a command. The Bash shell has, is, or bestows an "Environment," in the sense that it has a set of environment variables populated that child processes mostly inherit. If the user runs a command (let's just say openssl dgst -sha3-256 received_image.dd) and wants to record the act of running the command as a uco-action:Action, what should be the value of uco-action:environment?

• The active shell as a uco-observable:Process seems like one option to me. Is it wrong to then also classify that uco-observable:Process object as an environment:Environment?
• How could the machine the terminal is running on relate to this action as an environment:Environment?

[^1]: Disclaimer: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.

[ajnelson-nist]

@sbarnum : How would a compiled .dll file be classified according to the figure suggesting the solution for Requirement 2? Could you please explain how these classes do or don't apply: ContentData; File; Code; Library; SoftwareBuild. If possible, please disregard all Facets for this discussion.

What I'm trying to determine with this question is: What subclasses of Software are disjoint with one another?

Is File disjoint with Library?

Is Code disjoint with ContentData?

[ajnelson-nist]

@sbarnum : Can you give some examples of inputs and results of VerifySoftwareDeployment?

As a reminder, all of the new Action subclasses should have their names changed to gerunds.