Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
sbarnum opened this issue Jan 29, 2024 · 11 comments · May be fixed by #589
Open

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

sbarnum opened this issue Jan 29, 2024 · 11 comments · May be fixed by #589
Labels
Change Proposal
Milestone
UCO 2.0.0

Comments

@sbarnum
Copy link
Contributor

sbarnum commented Jan 29, 2024 •
edited
Loading

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

.
.
.
.

Software Deployment Overview-Software operational lifecycle - simple drawio

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

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

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

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

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

Requirement 6.1.1

Ability to characterize action of reconfiguring deployed Software

Software Deployment Overview-6 1 1 - Reconfigure Deployed Software drawio

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

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

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

Requirement 10

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

Software Deployment Overview-10 - Infrastructure Management drawio

Requirement 11

Ability to characterize the action of deploying an ObservableObject

Software Deployment Overview-11 - Deploy drawio

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

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

Requirement 12

Ability to characterize a specific deployment

Software Deployment Overview-12 - Deployment drawio

Requirement 13

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

Software Deployment Overview-13 - Simple Overview of Software Tool drawio

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
Copy link
Contributor

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 ajnelson-nist added this to the UCO 2.0.0 milestone Jan 29, 2024
@ajnelson-nist
Copy link
Contributor

@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
Copy link

packet-rat commented Jan 30, 2024 via email

@sbarnum
Copy link
Contributor Author

sbarnum commented Jan 30, 2024

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
Copy link

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 pushed a commit that referenced this issue Feb 5, 2024
@ajnelson-nist
Add initial draft of Software overhaul
528b5dc 
AJN: This is a transcription of Sean's suggested specific changes to
UCO, and will serve as a starting point for discussion markup.  I've
denoted Sean the patch-author because these changes were his suggestion
initially.

I enacted a few revisions in this patch that are either deviations are
additions to Sean's notes, and seemed necessary for the first patch:

* Concepts marked for removal, migration, and/or deletion are instead
  marked deprecated.  A follow-on patch will implement shapes for
  deprecation.
* I guessed on where the property `hasCharacterization` should be
  defined.
* Another revision is I guessed on how some of the new namespaces'
  direct-imports directions would have to be.
* The tool namesapce needed to pick up a stub reference to
  `ObservableObject`.

A follow-on patch will regenerate Make-managed files.

References:
* #583

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist ajnelson-nist linked a pull request Feb 5, 2024 that will close this issue
Draft
@ajnelson-nist ajnelson-nist linked a pull request Feb 5, 2024 that will close this issue
Issue 583: Overhaul Software, Configuration, and Tool #589
Draft
ajnelson-nist added a commit that referenced this issue Feb 5, 2024
@ajnelson-nist
Add deprecation shapes
623c5f4 
No effects were observed on Make-managed files.

References:
* #583

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist
Copy link
Contributor

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
Copy link
Contributor

@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.

@sbarnum sbarnum mentioned this issue Feb 14, 2024
Open
15 tasks
@ajnelson-nist
Copy link
Contributor

@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
Copy link
Contributor

@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 Bash1 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?

Footnotes

  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
Copy link
Contributor

@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
Copy link
Contributor

@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.

@ajnelson-nist ajnelson-nist mentioned this issue Mar 6, 2024
Open
16 tasks
@ajnelson-nist ajnelson-nist mentioned this issue Sep 13, 2024
Open
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Change Proposal
Projects
None yet
Milestone
UCO 2.0.0
Development

Successfully merging a pull request may close this issue.

Issue 583: Overhaul Software, Configuration, and Tool ucoProject/UCO
4 participants
@sbarnum @packet-rat @ajnelson-nist @aj-stein-nist