Describe the bug

"the Contributing page." links to https://github.com/usnistgov/vulntology/blob/master/Contributing.md should be https://github.com/usnistgov/vulntology/blob/master/CONTRIBUTING.md

User Story:

Currently there are no assignable values to assist with establishing current threat levels of a given vulnerability. What can we capture within the Vulntology to better represent these data points?

Possible Data of interest:

• Temporal concepts
  • Patches available
  • Exploits available
• Exposure mechanisms
  • Count within environment/world
  • Usage of platform within environment/world
• Recovery effort if exploited

Goals:

Establish consistent location for threat information within the model
Consider previous and currently discussed Temporal/Threat concepts from CVSS SIG and other organizations and include as objects or properties to existing objects.

Dependencies:

N/A

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.
• All current graphs, visuals and figures updated to reflect new objects/properties

User Story:

We have a few goals of the Vulntology that are listed on the current readme. However, these use cases don't really work for all users that may be encouraged to adopt the methodology. We should establish clear business cases for each usergroup we believe would benefit from use of the Vulntology.

Some Usergroups:
CNAs
Vulnerability Coordinators
Vulnerability Databases
Vulnerability Researchers
Consumers

The Product object does not follow the normal Object description pattern which includes a list of properties and relationships. This object should document the properties needed to provide the product, which includes the identification scheme and identifier properties.

User Story:

While developing the initial UI for creating Vulntology based representations we realized that it would be quite useful to be able to give each Scenario a text label. This will assist in organizing thoughts if a user is populating more than one of these objects (expected to be quite typical, especially with Actions).

Goals:

Create a new property that allows the addition of a free text shortname.
Limit the length of this label to avoid misuse. (15-20 chars?) The limit will likely be derived from the UI.

Dependencies:

The first draft of the UI should be finalized in a functional PoC so we can see how the size limit should be applied

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

The vulnerability object needs a property that is used to identify it. This will typically be a CVE ID, but may be an identifier from another identification scheme.

1. A new object is needed that allows an identification scheme and identifier value to be provided.
2. A means to link to such an object is needed on the vulnerability, perhaps using a relationship (e.g. identifiedBy).
3. It may be desirable to allow linkage to multiple identifiers to allow multiple identification schemes to be used. The semantics of such a relationship needs to be clear. Do both identifiers identify the same vulnerability? Is there a difference in vulnerability scope that makes both not the same?

In the vulnerability object, the text starting with "An identifier" and ending with "many organizations" needs to be removed and transitioned to this new linkage. This will probably eliminate the need for "KnownChains".

Most of the values end with "-type" while others do not. Is this intentional? Necessary? To me it just makes the documents and graph) more verbose. For example, instead of "Attack Theater Type", why not "Attack Theater"?

Values with Type: attack-theater-type, context-type, engineering-method-type, entity-role-type, impact-method-type, location-type, logical-impact-type, physical-impact-type, privilege-level-type, race-condition-type, sector-of-interest-type, vulnerability-type

Values without Type: criticality, known-chain, scope

If we keep the "-type" suffix, then maybe the folder should be renamed to "types".

In criticality.md, the heading is "Criticality Type Values".

In known-chain.md, the heading is "Known Chain Value".

In scope.md, the heading is actually "Scope Type Values".

The property between scenario and Provenance should be renamed to evidencedBy to avoid assertion of truth when reports could be faulty.

The product object is defined as:

The software and/or hardware configurations that are known to be vulnerable to exploitation

Is it possible to differentiate when product X is vulnerable only when running on product Y? E.g., an application running on a certain OS.

The key in the upper left corner of vulntology-graph.pdf has four (4) lines labeled "Property". In reality they represent relationships, not properties, and should be differentiated as zero to many, one and only one, one or many, and many.

In explanation.md:

1. Why is Object defined twice? Once under the heading Components, then once after Components.
2. Why is Values defined twice?
3. Why are there separate definitions for "Types/Subtypes" and "Values" when the vulntology only has a values folder that contains -type.md documents. See Issue #10 regarding -types in values folder.

This granularity will allow for a scenario to establish if they are the origin platform for a vulnerability or of they are inheriting the vulnerability based on a dependency.

Origin would be a mandatory property
Dependent would be optional

Ex: OpenSSL vulnerability. Origin=OpenSSL, Dependent=RHEL

This is a possible way to identify where an attack originates from instead of using CVSS specific terminology for Scope

The last paragraph in 02-introduction.md explains the use of colors in high-level-model.pdf:

Green represents new data points typically not captured.

Might it be useful to provide a key to all the colors and their meanings?

There are random extra lines (relationships?) on the graph:

1. sticking out of left side of Action
2. two lines sticking out of right side of ScopeType
3. one above EngineeringMethodType
4. one hanging down from Barrier SubType

These should be removed.

User Story:

Throughout the Vulnerability life cycle there are a series of events that would be valuable to track for historical, maintenance and academic purposes. Should we consider adding these types of information?

Ex:
ID Date
Public Disclosure Date
Patched Date
etc.

Many examples of this can be found within the CVRF documentation

Goals:

Review important data types that are useful for historical, academic and program maintenance. Provide either a new object and properties or series of properties that should be associated to an existing object.
Update all documentation to reflect the additional data types.

Dependencies:

N/A

Acceptance Criteria

• Identify all desired data types for tracking of each use case
• Creation of appropriate Object/s, Properties and Relationships
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.
• All graphs, visuals and figures updated to reflect changes

A README.md is needed in the specification folder to document the organization of the Vulntology specification and the corresponding sub directory structure. This readme should:

1. Describe the overall organization of the specification.
2. Point to the vulnerability.md as the top-level object.
3. It might be useful for the readme to include an image of the Vulntology chart, with image-map links to corresponding definitions under objects and values.

There appears to be a possible misuse of the terms "Properties" and "Relationships" throughout the vulntology. Consider Vulnerability has a vulnerability-identifier, but in vulnerability.md, the identifier is not listed under the Properties heading. Instead, each of the so called Properties is actually a relationship (line) on the graph.

Note also in explanation.md the term Properties is defined in terms of a relationship:

Properties: A connection relating a Type to a SubType or an Object to a Type.

See also Issue 9 in which lines on the graph are mislabeled "Property".

User Story:

As a Vulntology consumer, I need to understand how releases of the Vultology will be made, and how these releases affect my use of the Vulntology.

Goals:

• Define a versioning strategy (i.e. SEMVER)
• Document how the project will manage releases

Dependencies:

None.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.

Post issues capturing all feedback received during the VRDX Summit.

Based on the structure of Impact Methods, logical impacts and the definition it seems that Privilege Escalation is more appropriately placed as an Impact Method. This would clearly imply that privilege escalation is a higher level concept than the impacts themselves and could then be clarified via impacts.

Question

Which is the relation of this ontology with MITRE/NSA d3fend?

d3fend is defined using Resource Description Format which is the standard for ontologies. Are thereRDF files for this ontology?

The Provenance object does not follow the normal Object description pattern which includes a list of properties and relationships. This object should document the properties needed to provide the provenance, which includes a reference property. It may include other properties, but we can get to that later,

The front page should address:

• What we are trying to accomplish?
• Near-term/long-term goals of the project
• Provide an overview of resources in the repo.
• Discuss where others can help.

We have struggled with a proper way to handle the Barrier object and its subtypes in the past. It seems we may have developed a solution for Impact that we can leverage. We should refactor the Barrier section (schema/object listing) to align with this new approach.

User Story:

Mermaid is a tool that can be used to visualize the Vulntology Graphs using text representations within GitHub. We may be able to leverage this tool to allow easier tracking of changing to any graphs and to easily reference portions of the graphs within other sections of the Vulntology documentation.

Goals:

Review Mermaid and determine whether or not this is a good direction to go.
Redo the Vulntology Graph within mermaid to ensure we can retain all the current complexity we feel is important to convey.

Dependencies:

N/A

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.
• All current graphs are updated using Mermaid and all informational items within specification section are updated to reflect the appropriate graph portion

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

The semantics are fuzzy around Scenario vulnerability type with it being a type, category, or weakness. This is further compounded by vulnerability type being a compound value of scheme (e.g., OWASP, CWE) and identifier value, which would require an object relationship instead.

Recommend changing this property to "exploited weakness" or something similar, and focusing it on CWE. We also need to consider how other categorizations can be added. Maybe an OWASP Vulnerability Category property, or a more generalized category relationship might be also needed.

User Story:

Organizations may care about impacts a vulnerability could cause that are not simply related to human injury or property destruction. A small list of possible categories was provided regarding the types of other impacts or the perspective of impacts that could be included as a direct impact from a vulnerability being exploited.

Financial
Government
Catastrophe level events
FDA
NRC

Goals:

Determine if any of these or similar items that come out of research would work with the Vulntology model. Impacts would need to be specific to the vulnerability.

Dependencies:

N/A

Acceptance Criteria

[ ] Research completed into other areas of non-logical impacts
[ ] Determinations clearly defined regarding types that should be considered for inclusion into Vulntology and where they would best fit

I've compiled a list of tasks that should be taken care of as a cleanup/consistency effort regarding how we reference items in the JSON Schema

• Enum list for Theatre should follow format like Remote, Remote::Internet...etc.
  

  vulntology/schema/vulntology-json-schema-1.0-draft.json

  Lines 304 to 318 in 358976a

  	"enum": [
  	"Remote",
  	"Internet",
  	"Intranet",
  	"Local Network",
  	"Limited Remote",
  	"Bluetooth",
  	"Cellular",
  	"Infrared",
  	"Line of Sight",
  	"Satellite",
  	"Wireless",
  	"Local",
  	"Physical"
  	]

• hasLocation should be broken into its own definition. See #72.
  

  vulntology/schema/vulntology-json-schema-1.0-draft.json

  Lines 211 to 218 in 358976a

  	"hasLocation": {
  	"type": "string",
  	"enum": [
  	"File System",
  	"Memory",
  	"Network Traffic"
  	]
  	},

• Strip the "Logical Impact::" and "Physical Impact::" from enum lists of Logical and Physical Impacts
  

  vulntology/schema/vulntology-json-schema-1.0-draft.json

  Lines 147 to 163 in 358976a

  	"LogicalImpact": {
  	"$comment": "Why is this not a standalone type definition?",
  	"type": "string",
  	"enum": [
  	"Logical Impact::Write-Direct",
  	"Logical Impact::Read-Direct",
  	"Logical Impact::Resource Removal",
  	"Logical Impact::Service Interrupt",
  	"Logical Impact::Service Interrupt::Shutdown",
  	"Logical Impact::Service Interrupt::Reboot",
  	"Logical Impact::Service Interrupt::Hang",
  	"Logical Impact::Service Interrupt::Panic",
  	"Logical Impact::Service Interrupt::Unrecoverable",
  	"Logical Impact::Indirect Discloure",
  	"Logical Impact::Privilege Escalation"
  	]
  	},

  
  

  vulntology/schema/vulntology-json-schema-1.0-draft.json

  Lines 164 to 179 in 358976a

  	"PhysicalImpact": {
  	"type": "string",
  	"enum": [
  	"Physical Impact::Physical Resource Consumption",
  	"Physical Impact::Physical Resource Consumption::Electricity",
  	"Physical Impact::Physical Resource Consumption::Water",
  	"Physical Impact::Physical Resource Consumption::Assets",
  	"Physical Impact::Property Damage",
  	"Physical Impact::Human Injury",
  	"Physical Impact::Human Injury::Negligible",
  	"Physical Impact::Human Injury::Minor",
  	"Physical Impact::Human Injury::Serious",
  	"Physical Impact::Human Injury::Critical",
  	"Physical Impact::Human Injury::Catastrophic"
  	]
  	},

• $Comment of "missing WebServer" for Application Type can be removed
  

  vulntology/schema/vulntology-json-schema-1.0-draft.json

  Line 96 in 358976a

  "$comment": "Missing 'WebServer'",

• "scheme": {"$ref": "#/definitions/SimpleScheme"}, can be removed from Product Object since it is extraneous
  

  vulntology/schema/vulntology-json-schema-1.0-draft.json

  Line 45 in 358976a

  "scheme": {"$ref": "#/definitions/SimpleScheme"},

• hasCPEApplicabilityStatement should be broken into its own definition "CPEApplicabilityStatement"
  

  vulntology/schema/vulntology-json-schema-1.0-draft.json

  Lines 47 to 53 in 358976a

  	"hasCPEApplicabilityStatement": {
  	"type": "array",
  	"items": {
  	"$comment": "This is to reference the NVD configurations section, which requires much more complext JSON than simple strings. We could expand to other references or a broader structure to allow other schemas to be referenced in a generally applicable way.",
  	"$ref": "https://scap.nist.gov/schema/nvd/feed/1.1/nvd_cve_feed_json_1.1.schema#/definitions/def_node"
  	}
  	}

Who is the bug affecting?

Anyone leveraging the JSON or trying to make sense of the Vulntology when comparing the JSON and the other supporting information.

Describe the Chore

Revamp all current open tickets that are open for discussion to clearly identify the concern, the impacted area of the Vulntology (with link via GitHub) any possible directions and where solicited information would be useful.

Describe the Chore

https://github.com/usnistgov/vulntology/blob/master/specification/objects/barrier.md
Many values within this object are still missing appropriate descriptions to best explain their usage. These should be added to complete the initial drafting of the Vulntology values.

Targets for Resolution

The following items all need an appropriate description

• Encryption
• Obfuscation
• Dynamic Compilation
• Boundary Protections

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.

User Story:

As a Vulntology user, I need to understand how to properly use the barrier object and its sub-types. Currently, these concepts are a bit confusing.

Goals:

• Reorganize the barrier object into a hierarchy of child objects that represent the specialized properties for the sub-types (#88)
• Provide some examples of how the sub-types can be used. #91

Dependencies:

None.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.

User Story:

As a Vulntology JSON content creator, I need a way to enforce specific co-constraints.

Goals:

Implement the following co-constraints in the JSON schema if possible.

• For impacts, gainedPrivileges should only be allowed when the property hasLogicalImpact is Logical Impact::Privilege Escalation. See #72.
• Has hasLocation should only be optionally allowed when a hasLogicalImpact is defined. See #72.
• For barriers, neededPrivileges must be provided when blockedByBarrier is Authentication/Authorization::Privileges Required. See #85.

Dependencies:

None.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.

It appears that all objects have identifiers. For some objects, the meaning of identifier is clear. For example Vulnerability and Known Chain use CVE ID, Product uses CPE, Provenance uses URL, etc.

However, for other objects it is unclear what the identifier would be: Scenario, Action, Impact, Barrier.

Are these identified by ordinal/sequence (1, 2, 3, etc.) within the parent object? E.g., Action 2 within Scenario 3

Maybe this should be treated in explanation.md.

In the action object, the property "Affects Context" says:

Affects Context: The type, category, or weakness of the Vulnerability.

1. I question whether that is the correct definition here based on the definition of Context Type. Looks like it was copy-pasted by mistake from the Scenario property, Vulnerability Type.
2. The cardinality goes on to say

Each Action has one Affected Context

I think the property should be recast to Affected Context, or at least the terms should be made consistent.

User Story:

How can we handle identifying that something is NOT an impact within the scenario?

Ex:
Scenario 1 is crash and NOT Read or Write
Scenario 2 is Read but NOT crash

Being able to clearly assert something is not an impact for the scenario is valuable syntax that participants may want to leverage for clarity's sake.

This can be done through sibling relationships (where appropriate).
Ex: hasLogicalImpact//lackLogicalImpact

Goals:

Identify clean and scalable way to establish a negative relationship within the model.
Supporting this would force a few other rules to need making.

• What is asserted is known vs what is not asserted is unknown.
• Certain Objects would need additional rules around them to enforce whether or not a positive assertion vs a negative assertion is mandatory.

Dependencies:

N/A

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.
• All current graphs, visuals and figures are updated to reflect changes to objects, properties and relationships.

Ad a contributor.md and make the repository publicly viewable.

Describe the bug

The "Vulnerabiltiy Identifier" link on the vulnerability object page has a broken link.

Who is the bug affecting?

Users of the website.

For objects I would prefer a more compact cardinality representation. Something like:

• Known Chain (zero or many): Supplemental...

It may also be useful to create a readme in the objects subdirectory that explains the presentation form of an object in general.

Describe the bug

In development of the JSON schema (PR #56), some objects and relationship terms have been updated in the schema, but not in the specification section of this repository.

Who is the bug affecting?

This may confuse users of the JSON schema.

Expected behavior (i.e. solution)

The specification and figures should be updated to bring them in line with the JSON schema changes, since the JSON schema represents the best current thinking on the Vulntology.

User Story:

As a Vulntology application developer or content creator, I need a JSON-based data format to express vulntology-based data for a vulnerability. This schema will allow me to validate vulntology data for correct syntax and completeness.

Goals:

Towards creating a Vulntology JSON Schema, there is a need to:

• Better understand the syntax of JSON Schema
• Select a JSON Schema version
• Develop requirements for building a JSON schema for the Vulntology. This should include a rough sketch of the Schema organization, and a strategy for managing valid values lists.

Dependencies:

None.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.

User Story:

The vulntology could possibly be used to describe vulnerabilities that might fall outside the qualifications established by common systems such as CVE. This could result in Vulntology representations of theoretical issues, non-exploited issues, vulnerabilities that occur over time, issues that are near impossible to exploit in practice etc. IT would be useful to classify Vulntology representations.

A system needs to be established and defined to represent this classification system.

General Idea:

Theoretical vs Confirmed (ties into likelyhood, but could be a pre-designation)
Likelyhood of exploitation (similar to threat)
Common vs uncommon scenario (such as commonly crashes, but could result in uncommon disclosure)

This should be outside the scope of barrier, this is not intended to imply the conditions of success, but more the conditions of being a real world scenario.

Goals:

Research into each General Idea described in the user story and determine which types of classification would be useful and where they would apply within the model. (Some of these seem to be vulnerability level where others are possibly scenario level)

Dependencies:

N/A

Acceptance Criteria

[ ] Research completed into other areas of classification
[ ] Determinations clearly defined regarding types that should be considered for inclusion into Vulntology and where they would best fit

Describe the bug

As displayed below the relationship is shown as being with the action object, but this should only be required when the "Context Escape" value has been selected as an Impact Method. (

What is affected by this bug?

The schema cannot validate properly and a GUI would require special rulesets to handle this case

Expected behavior (i.e. solution)

We need to re-evaluate the schema to support the intended application of hasEscapeContext

The existing specification value for physical impact includes a reference to ISO/IEC 14971:2007 under "Human Injury".

This issue is to track and add other references to impact classifications that exists in the industry (i.e., FDA has adverse event codes, etc.).

User Story:

Reading through the Objects and Values it is sometimes difficult to mentally digest the information. It would be much easier for newer people or folks requiring a refresh to visually see what is being discussed int he text.

Goals:

Create sub-graphs for each object's markdown to provide a nice visual. Similar to the Powerpoint created for the VRDX Summit.

Dependencies:

N/A

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.
• Each smaller graph will have a figure in a new subgraph folder that is referenced inline for the values or objects page.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

See Title

What about services? business processes? Is this supposed to strictly be limited to on premises hardware and software?

User Story:

When using the Vulntology to describe a vulnerability I may desire the ability to communicate the order that certain things occur within a scenario. Specifically this is applicable to communicating CWEs and Actions. If there were properties that allowed me to establish a chain of events within these properties I could better represent a given scenario.

Goals:

Add properties to

Exploited Weakness (https://github.com/usnistgov/vulntology/blob/master/specification/values/exploited-weakness.md)
Actions (https://github.com/usnistgov/vulntology/blob/master/specification/objects/action.md)
Barriers (https://github.com/usnistgov/vulntology/blob/master/specification/objects/barrier.md)
Known Chains (https://github.com/usnistgov/vulntology/blob/master/specification/objects/vulnerability.md)
That communicates a sequence of events (precedes/follows) between sister objects.

Dependencies:

both of these reference the same concept so a unified approach would be mandatory

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.
• Properties are optional once more than one of the parent object exist (multiple CWEs and/or multiple Actions) within a single scenario
• Add example use of this to the JSON and Human Readable examples

The initial Sector of Interest list is less than complete. Does it make sense to use the Critical Infrastructure Sectors defined by Presidential Policy Directive 21 (PPD-21)?

User Story:

As a user of the Vulntology model, I may want to use one or more different methods to identify the vulnerable product (e.g., CPE, CPE Applicability Laguage, SWID tags, etc.). In the JSON binding I might have a specific model I could reference. At the moment, the Vultology model expects the expression value to be a string, but it could be useful to allow the value to be an object in JSON.

Goals:

Design an extensible approach that allows for more natural use of structured data in JSON as an object value.

Dependencies:

None.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}