Vulnerability Indicates weakness or flaw in the system that can be exploited by an attacker to gain unauthorized access or cause harm to the system. Vulnerabilities can exist in various components of the system, such as the operating system, applications, network devices, and databases.
Property | Type | Description | Required? |
---|---|---|---|
description | MarkdownString | Various sources of vulnerability information can be used, including third-party resources like the National Vulnerability Database (NVD) and the Common Vulnerabilities and Exposures (CVE) database. The platform then analyzes this data and provides the user with relevant details such as the severity of the vulnerability, the affected systems, and remediation recommendations. Based on this information, the user can prioritize patching and other mitigation strategies to reduce the risk of potential attacks. | ✓ |
id | String | Globally unique URI identifying this object. | ✓ |
schema_version | String | CTIM schema version for this entity. | ✓ |
type | VulnerabilityTypeIdentifierString | The fixed value vulnerability | ✓ |
configurations | Configurations Object | Represents a list of affected versions or configurations of a software component that is impacted by a vulnerability. By tracking the affected software components and versions, defenders can identify which systems are potentially exposed to an attack, and apply appropriate mitigations. | |
cve | CVE Object | ||
external_ids | String List | It is used to store a list of external identifiers that can be linked to the incident, providing a reliable and manageable way to correlate and group related events across multiple data sources. It is especially useful in larger organizations that rely on multiple security information and event management (SIEM) systems to detect security incidents. For instance, it can be used to track events across different network sensors, intrusion detection and prevention systems (IDPS), or log management platforms. The field can also be used to facilitate automation and orchestration workflows, where additional information can be shared among incident management systems. It can be used to cross-reference with other external tools such as threat intelligence feeds and vulnerability scanners. | |
external_references | ExternalReference Object List | Specifies a list of external references which refers to non-CTIM information. Similar to external_ids field with major differences: - external_ids field is used to store a list of external identifiers that can be used to link entities across different data sources. These identifiers are typically standardized and well-known, such as CVE IDs, US-CERT advisories, or other industry-standard threat intelligence feeds. The external_ids field can be used to facilitate automation and orchestration workflows, where additional information can be shared among incident management systems. - external_references field, on the other hand, is used to provide a more general mechanism for linking entities to external sources of information. The external_references field can include references to blog posts, articles, external documents, threat intelligence reports, and other sources of information that may not have a standardized format or identifier. |
|
impact | VulnerabilityImpact Object | Describes the potential impact of a vulnerability that is being tracked in the system. Provides information on the extent of damage that a vulnerability can cause and how serious the consequences could be if it is exploited. May contain granular information about the vulnerability severity using the CVSS system, versions 2 and 3. CVSSv2 and CVSSv3 have different methods of calculating base scores, but both are designed to provide an indication of the level of risk that a vulnerability poses. The base score ranges from 0 to 10, with 10 being the most severe. Additionally, both CVSSv2 and CVSSv3 define severity levels, such as low, medium, high, and critical, based on the base score. | |
language | ShortStringString | The language field is used to specify the primary language of the affected system or the target of an attack. It can be used to provide additional context and information about the entity. The primary purpose of this field is to help analysts filter and prioritize entities based on their knowledge and expertise of different languages. For example, if an incident involves an attack on a system in a country where a specific language is predominant, the language field can be used to indicate that language, which can help analysts to quickly identify and respond to incidents that may be geographically or culturally relevant. This information can be used to prioritize incidents based on their potential impact. The language field can also be used to help with correlation of incidents across different systems and regions, as well as to help with data analysis and reporting. |
|
last_modified_date | Inst (Date) | Represents the date when the vulnerability metadata was last updated in the internal database. It can be used to track the freshness of the vulnerability information. If the last_modified_date is more recent than the published_date , it can indicate that there has been some new information or updates related to the vulnerability, such as new patch releases or changes in the severity or impact rating. |
|
published_date | Inst (Date) | Represents the date when a vulnerability was publicly disclosed or made available to the general public. Important for tracking the age of a vulnerability, as well as for determining when a particular vulnerability was first introduced into a system. The published date can be used to identify the time window during which a system may have been vulnerable to a particular exploit. For example, if an organization discovers that a vulnerability was published before their system's installation date, but they did not apply the necessary security updates in a timely manner, it can be concluded that their system was vulnerable for the period between the installation date and the date when the necessary security updates were applied. | |
revision | Integer | A monotonically increasing revision, incremented each time the object is changed. | |
short_description | MedStringString | A single line, short summary of the object. | |
source | MedStringString | Represents the source of the intelligence that led to the creation of the entity. | |
source_uri | String | URI of the source of the intelligence that led to the creation of the entity. | |
timestamp | Inst (Date) | The time this object was created at, or last modified. | |
title | ShortStringString | A short title for this object, used as primary display and reference value. | |
tlp | TLPString | TLP stands for Traffic Light Protocol, which indicates precisely how a resource is intended to be shared, replicated, copied, etc. It is used to indicate the sensitivity of the information contained within the message. This allows recipients to determine the appropriate handling and dissemination of the information based on their clearance level and need-to-know. For example, an entity containing information about a critical vulnerability in a widely-used software might be marked as red , indicating that it should only be shared with a small group of highly trusted individuals who need to know in order to take appropriate action. On the other hand, a message containing more general information about security threats might be marked as amber or green , indicating that it can be shared more broadly within an organization. |
- Reference: Vulnerability
Represents a list of affected versions or configurations of a software component that is impacted by a vulnerability. By tracking the affected software components and versions, defenders can identify which systems are potentially exposed to an attack, and apply appropriate mitigations.
- This entry is optional
- Configurations Object Value
- Details: Configurations Object
- This entry is optional
- CVE Object Value
- Details: CVE Object
Various sources of vulnerability information can be used, including third-party resources like the National Vulnerability Database (NVD) and the Common Vulnerabilities and Exposures (CVE) database. The platform then analyzes this data and provides the user with relevant details such as the severity of the vulnerability, the affected systems, and remediation recommendations.
Based on this information, the user can prioritize patching and other mitigation strategies to reduce the risk of potential attacks.
-
This entry is required
- Markdown Markdown string with at most 5000 characters.
It is used to store a list of external identifiers that can be linked to the incident, providing a reliable and manageable way to correlate and group related events across multiple data sources. It is especially useful in larger organizations that rely on multiple security information and event management (SIEM) systems to detect security incidents. For instance, it can be used to track events across different network sensors, intrusion detection and prevention systems (IDPS), or log management platforms. The field can also be used to facilitate automation and orchestration workflows, where additional information can be shared among incident management systems. It can be used to cross-reference with other external tools such as threat intelligence feeds and vulnerability scanners.
- This entry is optional
- This entry's type is sequential (allows zero or more values)
Specifies a list of external references which refers to non-CTIM information.
Similar to external_ids
field with major differences:
-
external_ids
field is used to store a list of external identifiers that can be used to link entities across different data sources. These identifiers are typically standardized and well-known, such as CVE IDs, US-CERT advisories, or other industry-standard threat intelligence feeds. Theexternal_ids
field can be used to facilitate automation and orchestration workflows, where additional information can be shared among incident management systems. -
external_references
field, on the other hand, is used to provide a more general mechanism for linking entities to external sources of information. Theexternal_references
field can include references to blog posts, articles, external documents, threat intelligence reports, and other sources of information that may not have a standardized format or identifier.
- This entry is optional
- This entry's type is sequential (allows zero or more values)
- ExternalReference Object Value
- Details: ExternalReference Object
Globally unique URI identifying this object.
-
This entry is required
- IDs are URIs, for example
https://www.domain.com/ctia/judgement/judgement-de305d54-75b4-431b-adb2-eb6b9e546014
for a Judgement. This ID type compares to the STIX id field. The optional STIX idref field is not used.
- IDs are URIs, for example
Describes the potential impact of a vulnerability that is being tracked in the system. Provides information on the extent of damage that a vulnerability can cause and how serious the consequences could be if it is exploited.
May contain granular information about the vulnerability severity using the CVSS system, versions 2 and 3.
CVSSv2 and CVSSv3 have different methods of calculating base scores, but both are designed to provide an indication of the level of risk that a vulnerability poses. The base score ranges from 0 to 10, with 10 being the most severe. Additionally, both CVSSv2 and CVSSv3 define severity levels, such as low, medium, high, and critical, based on the base score.
- This entry is optional
- VulnerabilityImpact Object Value
- Details: VulnerabilityImpact Object
The language
field is used to specify the primary language of the affected system or the target of an attack. It can be used to provide additional context and information about the entity. The primary purpose of this field is to help analysts filter and prioritize entities based on their knowledge and expertise of different languages.
For example, if an incident involves an attack on a system in a country where a specific language is predominant, the language
field can be used to indicate that language, which can help analysts to quickly identify and respond to incidents that may be geographically or culturally relevant. This information can be used to prioritize incidents based on their potential impact. The language
field can also be used to help with correlation of incidents across different systems and regions, as well as to help with data analysis and reporting.
-
This entry is optional
- ShortString String with at most 1024 characters.
Represents the date when the vulnerability metadata was last updated in the internal database.
It can be used to track the freshness of the vulnerability information. If the last_modified_date
is more recent than the published_date
, it can indicate that there has been some new information or updates related to the vulnerability, such as new patch releases or changes in the severity or impact rating.
-
This entry is optional
- ISO8601 Timestamp Schema definition for all date or timestamp values. Serialized as a string, the field should follow the rules of the ISO8601 standard.
Represents the date when a vulnerability was publicly disclosed or made available to the general public.
Important for tracking the age of a vulnerability, as well as for determining when a particular vulnerability was first introduced into a system. The published date can be used to identify the time window during which a system may have been vulnerable to a particular exploit.
For example, if an organization discovers that a vulnerability was published before their system's installation date, but they did not apply the necessary security updates in a timely manner, it can be concluded that their system was vulnerable for the period between the installation date and the date when the necessary security updates were applied.
-
This entry is optional
- ISO8601 Timestamp Schema definition for all date or timestamp values. Serialized as a string, the field should follow the rules of the ISO8601 standard.
A monotonically increasing revision, incremented each time the object is changed.
-
This entry is optional
- Zero, or a positive integer.
CTIM schema version for this entity.
-
This entry is required
- A semantic version matching the CTIM version against which this object should be valid.
A single line, short summary of the object.
-
This entry is optional
- MedString String with at most 2048 characters.
Represents the source of the intelligence that led to the creation of the entity.
-
This entry is optional
- MedString String with at most 2048 characters.
URI of the source of the intelligence that led to the creation of the entity.
-
This entry is optional
- A URI
The time this object was created at, or last modified.
-
This entry is optional
- ISO8601 Timestamp Schema definition for all date or timestamp values. Serialized as a string, the field should follow the rules of the ISO8601 standard.
A short title for this object, used as primary display and reference value.
-
This entry is optional
- ShortString String with at most 1024 characters.
TLP stands for Traffic Light Protocol, which indicates precisely how a resource is intended to be shared, replicated, copied, etc.
It is used to indicate the sensitivity of the information contained within the message. This allows recipients to determine the appropriate handling and dissemination of the information based on their clearance level and need-to-know.
For example, an entity containing information about a critical vulnerability in a widely-used software might be marked as red
, indicating that it should only be shared with a small group of highly trusted individuals who need to know in order to take appropriate action. On the other hand, a message containing more general information about security threats might be marked as amber
or green
, indicating that it can be shared more broadly within an organization.
-
This entry is optional
- Allowed Values:
- amber
- green
- red
- white
- Allowed Values:
The fixed value vulnerability
-
This entry is required
- VulnerabilityTypeIdentifier The fixed value "vulnerability"
- Must equal: "vulnerability"
ExternalReference External references are used to describe pointers to information represented outside of CTIM. For example, a Malware object could use an external reference to indicate an ID for that malware in an external database or a report could use references to represent source material.
Property | Type | Description | Required? |
---|---|---|---|
source_name | MedStringString | The source within which the external-reference is defined (system, registry, organization, etc.) | ✓ |
description | MarkdownString | ||
external_id | String | An identifier for the external reference content. | |
hashes | String List | Specifies a dictionary of hashes for the contents of the url. | |
url | String | A URL reference to an external resource. |
- Reference: External Reference
-
This entry is optional
- Markdown Markdown string with at most 5000 characters.
An identifier for the external reference content.
- This entry is optional
Specifies a dictionary of hashes for the contents of the url.
- This entry is optional
- This entry's type is sequential (allows zero or more values)
The source within which the external-reference is defined (system, registry, organization, etc.)
-
This entry is required
- MedString String with at most 2048 characters.
A URL reference to an external resource.
-
This entry is optional
- A URI
Property | Type | Description | Required? |
---|---|---|---|
cve_data_meta | CVEDataMeta Object | ✓ |
- This entry is required
- CVEDataMeta Object Value
- Details: CVEDataMeta Object
Property | Type | Description | Required? |
---|---|---|---|
assigner | ShortStringString | ||
id | ShortStringString |
-
This entry is optional
- ShortString String with at most 1024 characters.
-
This entry is optional
- ShortString String with at most 1024 characters.
Property | Type | Description | Required? |
---|---|---|---|
cvss_v2 | CVSSv2 Object | ||
cvss_v3 | CVSSv3 Object |
- This entry is optional
- CVSSv2 Object Value
- Details: CVSSv2 Object
- This entry is optional
- CVSSv3 Object Value
- Details: CVSSv3 Object
Property | Type | Description | Required? |
---|---|---|---|
base_score | Number | The base score is a key metric in CVSS, which uses a scoring system to determine the level of severity of a vulnerability. see: https://www.first.org/cvss/v3-1 | ✓ |
base_severity | CVSSv3SeverityString | ✓ | |
vector_string | String | ✓ | |
attack_complexity | CVSSv3AttackComplexityString | describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability | |
attack_vector | CVSSv3AttackVectorString | Reflects the context by which vulnerability exploitation is possible | |
availability_impact | CVSSv3AvailabilityImpactString | measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability | |
availability_requirement | CVSSv3SecurityRequirementsString | ||
confidentiality_impact | CVSSv3ConfidentialityImpactString | measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability | |
confidentiality_requirement | CVSSv3SecurityRequirementsString | ||
environmental_score | Number | ||
environmental_severity | CVSSv3SeverityString | ||
exploit_code_maturity | CVSSv3ExploitCodeMaturityString | measures the likelihood of the vulnerability being attacked | |
exploitability_score | Number | ||
impact_score | Number | ||
integrity_impact | CVSSv3IntegrityImpactString | measures the impact to integrity of a successfully exploited vulnerability | |
integrity_requirement | CVSSv3SecurityRequirementsString | ||
modified_attack_complexity | CVSSv3ModifiedAttackComplexityString | modified attack complexity | |
modified_attack_vector | CVSSv3ModifiedAttackVectorString | modified attack vector | |
modified_availability_impact | CVSSv3ModifiedAvailabilityImpactString | modified availability impact | |
modified_confidentiality_impact | CVSSv3ModifiedConfidentialityImpactString | modified confidentiality impact | |
modified_integrity_impact | CVSSv3ModifiedIntegrityImpactString | modified integrity impact | |
modified_privileges_required | CVSSv3ModifiedPrivilegesRequiredString | modified privileges required | |
modified_scope | CVSSv3ModifiedScopeString | modified scope | |
modified_user_interaction | CVSSv3ModifiedUserInteractionString | modified user interaction | |
privileges_required | CVSSv3PrivilegesRequiredString | describes the level of privileges an attacker must possess before successfully exploiting the vulnerability | |
remediation_level | CVSSv3RemediationLevelString | Remediation Level of a vulnerability is an important factor for prioritization | |
report_confidence | CVSSv3ReportConfidenceString | measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details | |
scope | CVSSv3ScopeString | the ability for a vulnerability in one software component to impact resources beyond its means, or privileges | |
temporal_score | Number | Round up(CVSSv3BaseScore × CVSSv3ExploitCodeMaturity × CVSSv3RemediationLevel × CVSSv3ReportConfidence) | |
temporal_severity | CVSSv3SeverityString | temporal severity | |
user_interaction | CVSSv3UserInteractionString | captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component |
describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability
-
This entry is optional
- CVSSv3AttackComplexity Describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. As described below, such conditions may require the collection of more information about the target, the presence of certain system configuration settings, or computational exceptions. Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability (such conditions are captured in the User Interaction metric). this metric value is largest for the least complex attacks. The list of possible values are:
low
Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.high
A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may depend on an attacker overcoming any of the following conditions: - The attacker must conduct target-specific reconnaissance. For example, on target configuration settings, sequence numbers, shared secrets, etc. - The attacker must prepare the target environment to improve exploit reliability. For example, repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques. The attacker must inject herself into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g. man in the middle attack). - Allowed Values:
- high
- low
- Reference: Attack Complexity
- CVSSv3AttackComplexity Describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. As described below, such conditions may require the collection of more information about the target, the presence of certain system configuration settings, or computational exceptions. Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability (such conditions are captured in the User Interaction metric). this metric value is largest for the least complex attacks. The list of possible values are:
Reflects the context by which vulnerability exploitation is possible
-
This entry is optional
- CVSSv3AttackVector This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base score) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across the Internet is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater score. The list of possible values is:
network
A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termedremotely exploitable
and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers). An example of a network attack is an attacker causing a denial of service (DoS) by sending a specially crafted TCP packet from across the public Internet (e.g. CVE 2004 0230).adjacent_network
A vulnerability exploitable with adjacent network access means the vulnerable component is bound to the network stack, however the attack is limited to the same shared physical (e.g. Bluetooth, IEEE 802.11) or logical (e.g. local IP subnet) network, and cannot be performed across an OSI layer 3 boundary (e.g. a router). An example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment. See also CVE 2013 6014.local
A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file.physical
A vulnerability exploitable with Physical access requires the attacker to physically touch or manipulate the vulnerable component. Physical interaction may be brief (e.g. evil maid attack) or persistent. An example of such an attack is a cold boot attack which allows an attacker to access to disk encryption keys after gaining physical access to the system, or peripheral attacks such as Firewire/USB Direct Memory Access attacks. - Allowed Values:
- adjacent_network
- local
- network
- physical
- Reference: Attack Vector
- CVSSv3AttackVector This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base score) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across the Internet is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater score. The list of possible values is:
measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability
-
This entry is optional
- CVSSv3AvailabilityImpact This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component. The list of possible values is presented is:
high
: There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).low
: There is reduced performance or interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the impacted component are either partially available all of the time, or fully available only some of the time but overall there is no direct, serious consequence to the impacted component.none
: There is no impact to availability within the impacted component. This metric value increases with the consequence to the impacted component. - Allowed Values:
- high
- low
- none
- Reference: [Availability Impact] (https://www.first.org/cvss/specification-document#2-3-3-Availability-Impact-A)
- CVSSv3AvailabilityImpact This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component. The list of possible values is presented is:
-
This entry is optional
- CVSSv3SecurityRequirements These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user's organization, measured in terms of Confidentiality, Integrity, and Availability. That is, if an IT asset supports a business function for which Availability is most important, the analyst can assign a greater value to Availability relative to Confidentiality and Integrity. Each security requirement has three possible values: Low, Medium, or High. The full effect on the environmental score is determined by the corresponding Modified Base Impact metrics. That is, these metrics modify the environmental score by reweighting the Modified Confidentiality, Integrity, and Availability impact metrics. For example, the Modified Confidentialityimpact (MC) metric has increased weight if the Confidentiality Requirement (CR) is High. Likewise, the Modified Confidentiality impact metric has decreased weight if the Confidentiality Requirement is Low. The Modified Confidentiality impact metric weighting is neutral if the Confidentiality Requirement is Medium. This same process is applied to the Integrity and Availability requirements.Note that the Confidentiality Requirement will not affect the Environmental score if the (Modified Base) confidentiality impact is set to None. Also, increasing the Confidentiality Requirement from Medium to Highwill not change the Environmental score when the (Modified Base) impact metrics are set to High. This is because the modified impact sub score (part of the Modified Base score that calculates impact) is already at a maximum value of 10. The list of possible values is:
not_defined
: Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.high
: Loss of [Confidentiality / Integrity / Availability] is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).medium
: Loss of [Confidentiality / Integrity / Availability] is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).low
: Loss of [Confidentiality / Integrity / Availability] is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers). For brevity, the same table is used for all three metrics. The greater the Security Requirement, the higher the score (recall that Medium is considered the default). - Allowed Values:
- high
- low
- none
- not_defined
- Reference: [Security Requirements] (https://www.first.org/cvss/specification-document#4-1-Security-Requirements-CR-IR-AR)
- CVSSv3SecurityRequirements These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user's organization, measured in terms of Confidentiality, Integrity, and Availability. That is, if an IT asset supports a business function for which Availability is most important, the analyst can assign a greater value to Availability relative to Confidentiality and Integrity. Each security requirement has three possible values: Low, Medium, or High. The full effect on the environmental score is determined by the corresponding Modified Base Impact metrics. That is, these metrics modify the environmental score by reweighting the Modified Confidentiality, Integrity, and Availability impact metrics. For example, the Modified Confidentialityimpact (MC) metric has increased weight if the Confidentiality Requirement (CR) is High. Likewise, the Modified Confidentiality impact metric has decreased weight if the Confidentiality Requirement is Low. The Modified Confidentiality impact metric weighting is neutral if the Confidentiality Requirement is Medium. This same process is applied to the Integrity and Availability requirements.Note that the Confidentiality Requirement will not affect the Environmental score if the (Modified Base) confidentiality impact is set to None. Also, increasing the Confidentiality Requirement from Medium to Highwill not change the Environmental score when the (Modified Base) impact metrics are set to High. This is because the modified impact sub score (part of the Modified Base score that calculates impact) is already at a maximum value of 10. The list of possible values is:
The base score is a key metric in CVSS, which uses a scoring system to determine the level of severity of a vulnerability. see: https://www.first.org/cvss/v3-1
-
This entry is required
- a Score number from 0 to 10
-
This entry is required
- Allowed Values:
- critical
- high
- low
- medium
- none
- Allowed Values:
measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability
-
This entry is optional
- CVSSv3ConfidentialityImpact Measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. The list of possible values is:
high
: There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.low
: There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is constrained. The information disclosure does not cause a direct, serious loss to the impacted component.none
: There is no loss of confidentiality within the impacted component. This metric value increases with the degree of loss to the impacted component. - Allowed Values:
- high
- low
- none
- Reference: [Confientiality Impact] (https://www.first.org/cvss/specification-document#2-3-1-Confidentiality-Impact-C)
- CVSSv3ConfidentialityImpact Measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. The list of possible values is:
-
This entry is optional
- CVSSv3SecurityRequirements These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user's organization, measured in terms of Confidentiality, Integrity, and Availability. That is, if an IT asset supports a business function for which Availability is most important, the analyst can assign a greater value to Availability relative to Confidentiality and Integrity. Each security requirement has three possible values: Low, Medium, or High. The full effect on the environmental score is determined by the corresponding Modified Base Impact metrics. That is, these metrics modify the environmental score by reweighting the Modified Confidentiality, Integrity, and Availability impact metrics. For example, the Modified Confidentialityimpact (MC) metric has increased weight if the Confidentiality Requirement (CR) is High. Likewise, the Modified Confidentiality impact metric has decreased weight if the Confidentiality Requirement is Low. The Modified Confidentiality impact metric weighting is neutral if the Confidentiality Requirement is Medium. This same process is applied to the Integrity and Availability requirements.Note that the Confidentiality Requirement will not affect the Environmental score if the (Modified Base) confidentiality impact is set to None. Also, increasing the Confidentiality Requirement from Medium to Highwill not change the Environmental score when the (Modified Base) impact metrics are set to High. This is because the modified impact sub score (part of the Modified Base score that calculates impact) is already at a maximum value of 10. The list of possible values is:
not_defined
: Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.high
: Loss of [Confidentiality / Integrity / Availability] is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).medium
: Loss of [Confidentiality / Integrity / Availability] is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).low
: Loss of [Confidentiality / Integrity / Availability] is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers). For brevity, the same table is used for all three metrics. The greater the Security Requirement, the higher the score (recall that Medium is considered the default). - Allowed Values:
- high
- low
- none
- not_defined
- Reference: [Security Requirements] (https://www.first.org/cvss/specification-document#4-1-Security-Requirements-CR-IR-AR)
- CVSSv3SecurityRequirements These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user's organization, measured in terms of Confidentiality, Integrity, and Availability. That is, if an IT asset supports a business function for which Availability is most important, the analyst can assign a greater value to Availability relative to Confidentiality and Integrity. Each security requirement has three possible values: Low, Medium, or High. The full effect on the environmental score is determined by the corresponding Modified Base Impact metrics. That is, these metrics modify the environmental score by reweighting the Modified Confidentiality, Integrity, and Availability impact metrics. For example, the Modified Confidentialityimpact (MC) metric has increased weight if the Confidentiality Requirement (CR) is High. Likewise, the Modified Confidentiality impact metric has decreased weight if the Confidentiality Requirement is Low. The Modified Confidentiality impact metric weighting is neutral if the Confidentiality Requirement is Medium. This same process is applied to the Integrity and Availability requirements.Note that the Confidentiality Requirement will not affect the Environmental score if the (Modified Base) confidentiality impact is set to None. Also, increasing the Confidentiality Requirement from Medium to Highwill not change the Environmental score when the (Modified Base) impact metrics are set to High. This is because the modified impact sub score (part of the Modified Base score that calculates impact) is already at a maximum value of 10. The list of possible values is:
-
This entry is optional
- a Score number from 0 to 10
-
This entry is optional
- Allowed Values:
- critical
- high
- low
- medium
- none
- Allowed Values:
measures the likelihood of the vulnerability being attacked
-
This entry is optional
- CVSSv3ExploitCodeMaturity This metric measures the likelihood of the vulnerability being attacked, and is typically based on the current state of exploit techniques, exploit code availability, or active, 'in-the-wild' exploitation. Public availability of easy-to-use exploit code increases the number of potential attackers by including those who are unskilled, thereby increasing the severity of the vulnerability. Initially, real-world exploitation may only be theoretical. Publication of proof-of-concept code, functional exploit code, or sufficient technical details necessary to exploit the vulnerability may follow. Furthermore, the exploit code available may progress from a proof-of-concept demonstration to exploit code that is successful in exploiting the vulnerability consistently. In severe cases, it may be delivered as the payload of a network-based worm or virus or other automated attack tools. The list of possible values is:
not_defined
: Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.high
: Functional autonomous code exists, or no exploit is required (manual trigger) and details are widely available. Exploit code works in every situation, or is actively being delivered via an autonomous agent (such as a worm or virus). Network-connected systems are likely to encounter scanning or exploitation attempts. Exploit development has reached the level of reliable, widely-available, easy-to-use automated tools.functional
: Functional exploit code is available. The code works in most situations where the vulnerability exists.proof_of_concept
: Proof-of-concept exploit code is available, or an attack demonstration is not practical for most systems. The code or technique is not functional in all situations and may require substantial modification by a skilled attacker.unproven
: No exploit code is available, or an exploit is theoretical. - Allowed Values:
- functional
- high
- not_defined
- proof_of_concept
- unproven
- Reference: [Exploit Code Maturity] (https://www.first.org/cvss/specification-document#3-1-Exploit-Code-Maturity-E)
- CVSSv3ExploitCodeMaturity This metric measures the likelihood of the vulnerability being attacked, and is typically based on the current state of exploit techniques, exploit code availability, or active, 'in-the-wild' exploitation. Public availability of easy-to-use exploit code increases the number of potential attackers by including those who are unskilled, thereby increasing the severity of the vulnerability. Initially, real-world exploitation may only be theoretical. Publication of proof-of-concept code, functional exploit code, or sufficient technical details necessary to exploit the vulnerability may follow. Furthermore, the exploit code available may progress from a proof-of-concept demonstration to exploit code that is successful in exploiting the vulnerability consistently. In severe cases, it may be delivered as the payload of a network-based worm or virus or other automated attack tools. The list of possible values is:
-
This entry is optional
- a Score number from 0 to 10
-
This entry is optional
- a Score number from 0 to 10
measures the impact to integrity of a successfully exploited vulnerability
-
This entry is optional
- CVSSv3IntegrityImpact This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. The list of possible values is:
high
: There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.low
: Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is constrained. The data modification does not have a direct, serious impact on the impacted component.none
: There is no loss of integrity within the impacted component.this metric value increases with the consequence to the impacted component. - Allowed Values:
- high
- low
- none
- Reference: [Integrity Impact] (https://www.first.org/cvss/specification-document#2-3-2-Integrity-Impact-I)
- CVSSv3IntegrityImpact This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. The list of possible values is:
-
This entry is optional
- CVSSv3SecurityRequirements These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user's organization, measured in terms of Confidentiality, Integrity, and Availability. That is, if an IT asset supports a business function for which Availability is most important, the analyst can assign a greater value to Availability relative to Confidentiality and Integrity. Each security requirement has three possible values: Low, Medium, or High. The full effect on the environmental score is determined by the corresponding Modified Base Impact metrics. That is, these metrics modify the environmental score by reweighting the Modified Confidentiality, Integrity, and Availability impact metrics. For example, the Modified Confidentialityimpact (MC) metric has increased weight if the Confidentiality Requirement (CR) is High. Likewise, the Modified Confidentiality impact metric has decreased weight if the Confidentiality Requirement is Low. The Modified Confidentiality impact metric weighting is neutral if the Confidentiality Requirement is Medium. This same process is applied to the Integrity and Availability requirements.Note that the Confidentiality Requirement will not affect the Environmental score if the (Modified Base) confidentiality impact is set to None. Also, increasing the Confidentiality Requirement from Medium to Highwill not change the Environmental score when the (Modified Base) impact metrics are set to High. This is because the modified impact sub score (part of the Modified Base score that calculates impact) is already at a maximum value of 10. The list of possible values is:
not_defined
: Assigning this value to the metric will not influence the score. It is a signal to the equation to skip this metric.high
: Loss of [Confidentiality / Integrity / Availability] is likely to have a catastrophic adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).medium
: Loss of [Confidentiality / Integrity / Availability] is likely to have a serious adverse effect on the organization or individuals associated with the organization (e.g., employees, customers).low
: Loss of [Confidentiality / Integrity / Availability] is likely to have only a limited adverse effect on the organization or individuals associated with the organization (e.g., employees, customers). For brevity, the same table is used for all three metrics. The greater the Security Requirement, the higher the score (recall that Medium is considered the default). - Allowed Values:
- high
- low
- none
- not_defined
- Reference: [Security Requirements] (https://www.first.org/cvss/specification-document#4-1-Security-Requirements-CR-IR-AR)
- CVSSv3SecurityRequirements These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user's organization, measured in terms of Confidentiality, Integrity, and Availability. That is, if an IT asset supports a business function for which Availability is most important, the analyst can assign a greater value to Availability relative to Confidentiality and Integrity. Each security requirement has three possible values: Low, Medium, or High. The full effect on the environmental score is determined by the corresponding Modified Base Impact metrics. That is, these metrics modify the environmental score by reweighting the Modified Confidentiality, Integrity, and Availability impact metrics. For example, the Modified Confidentialityimpact (MC) metric has increased weight if the Confidentiality Requirement (CR) is High. Likewise, the Modified Confidentiality impact metric has decreased weight if the Confidentiality Requirement is Low. The Modified Confidentiality impact metric weighting is neutral if the Confidentiality Requirement is Medium. This same process is applied to the Integrity and Availability requirements.Note that the Confidentiality Requirement will not affect the Environmental score if the (Modified Base) confidentiality impact is set to None. Also, increasing the Confidentiality Requirement from Medium to Highwill not change the Environmental score when the (Modified Base) impact metrics are set to High. This is because the modified impact sub score (part of the Modified Base score that calculates impact) is already at a maximum value of 10. The list of possible values is:
modified attack complexity
-
This entry is optional
- CVSSv3ModifiedAttackComplexity The same values as Attack Complexity, as well as not_defined (the default)
- Allowed Values:
- high
- low
- not_defined
- Reference: [Modified Base Metrics] (https://www.first.org/cvss/specification-document#4-2-Modified-Base-Metrics)
modified attack vector
-
This entry is optional
- CVSSv3ModifiedAttackVector The same values as Attack Vector, as well as not_defined (the default)
- Allowed Values:
- adjacent_network
- local
- network
- not_defined
- physical
- Reference: [Modified Base Metrics] (https://www.first.org/cvss/specification-document#4-2-Modified-Base-Metrics)
modified availability impact
-
This entry is optional
- CVSSv3ModifiedAvailabilityImpact The same values as Availability Impact, as well as not_defined (the default)
- Allowed Values:
- high
- low
- none
- not_defined
- Reference: [Modified Base Metrics] (https://www.first.org/cvss/specification-document#4-2-Modified-Base-Metrics)
modified confidentiality impact
-
This entry is optional
- CVSSv3ModifiedConfidentialityImpact The same values as Confidentiality Impact, as well as not_defined (the default)
- Allowed Values:
- high
- low
- none
- not_defined
- Reference: [Modified Base Metrics] (https://www.first.org/cvss/specification-document#4-2-Modified-Base-Metrics)
modified integrity impact
-
This entry is optional
- CVSSv3ModifiedIntegrityImpact The same values as Integrity Impact, as well as not_defined (the default)
- Allowed Values:
- high
- low
- none
- not_defined
- Reference: [Modified Base Metrics] (https://www.first.org/cvss/specification-document#4-2-Modified-Base-Metrics)
modified privileges required
-
This entry is optional
- CVSSv3ModifiedPrivilegesRequired The same values as Privileges Required, as well as not_defined (the default)
- Allowed Values:
- high
- low
- none
- not_defined
- Reference: [Modified Base Metrics] (https://www.first.org/cvss/specification-document#4-2-Modified-Base-Metrics)
modified scope
-
This entry is optional
- CVSSv3ModifiedScope The same values as Scope, as well as not_defined (the default)
- Allowed Values:
- changed
- not_defined
- unchanged
- Reference: [Modified Base Metrics] (https://www.first.org/cvss/specification-document#4-2-Modified-Base-Metrics)
modified user interaction
-
This entry is optional
- CVSSv3ModifiedUserInteraction The same values as User Interaction, as well as not_defined (the default)
- Allowed Values:
- none
- not_defined
- required
- Reference: [Modified Base Metrics] (https://www.first.org/cvss/specification-document#4-2-Modified-Base-Metrics)
describes the level of privileges an attacker must possess before successfully exploiting the vulnerability
-
This entry is optional
- CVSSv3PrivilegesRequired This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. This metric is greatest if no privileges are required. The list of possible values is:
none
: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.low
: The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.high
: The attacker is authorized with (i.e. requires) privileges that provide significant (e.g. administrative) control over the vulnerable component that could affect component-wide settings and files. - Allowed Values:
- high
- low
- none
- Reference: [Privileges Required] (https://www.first.org/cvss/specification-document#2-1-3-Privileges-Required-PR)
- CVSSv3PrivilegesRequired This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. This metric is greatest if no privileges are required. The list of possible values is:
Remediation Level of a vulnerability is an important factor for prioritization
-
This entry is optional
- CVSSv3RemediationLevel The Remediation Level of a vulnerability is an important factor for prioritization. The typical vulnerability is unpatched when initially published. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued. Each of these respective stages adjusts the temporal score downwards, reflecting the decreasing urgency as remediation becomes final. The list of possible values is:
not_defined
: Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.unavailable
: There is either no solution available or it is impossible to apply.workaround
: There is an unofficial, non-vendor solution available. In some cases, users of the affected technology will create a patch of their own or provide steps to work around or otherwise mitigate the vulnerability.temporary_fix
: There is an official but temporary fix available. This includes instances where the vendor issues a temporary hotfix, tool, or workaround.official_fix
: A complete vendor solution is available. Either the vendor has issued an official patch, or an upgrade is available. The less official and permanent a fix, the higher the vulnerability score. - Allowed Values:
- high
- not_defined
- offical_fix
- temporary_fix
- unavailable
- workaround
- Reference: [Remediation Level] (https://www.first.org/cvss/specification-document#3-2-Remediation-Level-RL)
- CVSSv3RemediationLevel The Remediation Level of a vulnerability is an important factor for prioritization. The typical vulnerability is unpatched when initially published. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued. Each of these respective stages adjusts the temporal score downwards, reflecting the decreasing urgency as remediation becomes final. The list of possible values is:
measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details
-
This entry is optional
- CVSSv3ReportConfidence Measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details. Sometimes only the existence of vulnerabilities are publicized, but without specific details. For example, an impact may be recognized as undesirable, but the root cause may not be known. The vulnerability may later be corroborated by research which suggests where the vulnerability may lie, though the research may not be certain. Finally, a vulnerability may be confirmed through acknowledgement by the author or vendor of the affected technology. The urgency of a vulnerability is higher when a vulnerability is known to exist with certainty. This metric also suggests the level of technical knowledge available to would-be attackers. The list of possible values is:
not_defined
: Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.confirmed
: Detailed reports exist, or functional reproduction is possible (functional exploits may provide this). Source code is available to independently verify theassertions of the research, or the author or vendor of the affected code has confirmed the presence of the vulnerability.reasonable
: Significant details are published, but researchers either do not have full confidence in the root cause, or do not have access to source code to fully confirm all of the interactions that may lead to the result. Reasonable confidence exists, however, that the bug is reproducible and at least one impact is able to be verified (proof-of-concept exploits may provide this). An example is a detailed write-up of research into a vulnerability with an explanation (possibly obfuscated or 'left as an exercise to the reader') that gives assurances on how to reproduce the results.unknown
: There are reports of impacts that indicate a vulnerability is present. The reports indicate that the cause of the vulnerability is unknown, or reports may differ on the cause or impacts of the vulnerability. Reporters are uncertain of the true nature of the vulnerability, and there is little confidence in the validity of the reports or whether a static Base score can be applied given the differences described. An example is a bug report which notes that an intermittent but non-reproducible crash occurs, with evidence of memory corruption suggesting that denial of service, or possible more serious impacts, may result. The more a vulnerability is validated by the vendor or other reputable sources, the higher the score. - Allowed Values:
- confirmed
- reasonable
- unknown
- Reference: [Report Confidence] (https://www.first.org/cvss/specification-document#3-3-Report-Confidence-RC)
- CVSSv3ReportConfidence Measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details. Sometimes only the existence of vulnerabilities are publicized, but without specific details. For example, an impact may be recognized as undesirable, but the root cause may not be known. The vulnerability may later be corroborated by research which suggests where the vulnerability may lie, though the research may not be certain. Finally, a vulnerability may be confirmed through acknowledgement by the author or vendor of the affected technology. The urgency of a vulnerability is higher when a vulnerability is known to exist with certainty. This metric also suggests the level of technical knowledge available to would-be attackers. The list of possible values is:
the ability for a vulnerability in one software component to impact resources beyond its means, or privileges
-
This entry is optional
- CVSSv3Scope An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges. This consequence is represented by the metric Authorization Scope, or simply Scope. Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports. When the vulnerability of a software component governed by one authorization scope is able to affect resources governed by another authorization scope, a Scope change has occurred. Intuitively, one may think of a scope change as breaking out of a sandbox, and an example would be a vulnerability in a virtual machine that enables an attacker to delete files on the host OS (perhaps even its own VM). In this example, there are two separate authorization authorities: one that defines and enforces privileges for the virtual machine and its users, and one that defines and enforces privileges for the host system within which the virtual machine runs. a scope change would not occur, for example, with a vulnerability in Microsoft Word that allows an attacker to compromise all system files of the host OS, because the same authority enforces privileges of the user's instance of Word, and the host's system files. The Base score is greater when a scope change has occurred. The list of possible values is:
unchanged
: An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same.changed
: An exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. In this case the vulnerable component and the impacted component are different. - Allowed Values:
- changed
- unchanged
- Reference: [Scope] (https://www.first.org/cvss/specification-document#2-2-Scope-S)
- CVSSv3Scope An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges. This consequence is represented by the metric Authorization Scope, or simply Scope. Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports. When the vulnerability of a software component governed by one authorization scope is able to affect resources governed by another authorization scope, a Scope change has occurred. Intuitively, one may think of a scope change as breaking out of a sandbox, and an example would be a vulnerability in a virtual machine that enables an attacker to delete files on the host OS (perhaps even its own VM). In this example, there are two separate authorization authorities: one that defines and enforces privileges for the virtual machine and its users, and one that defines and enforces privileges for the host system within which the virtual machine runs. a scope change would not occur, for example, with a vulnerability in Microsoft Word that allows an attacker to compromise all system files of the host OS, because the same authority enforces privileges of the user's instance of Word, and the host's system files. The Base score is greater when a scope change has occurred. The list of possible values is:
Round up(CVSSv3BaseScore × CVSSv3ExploitCodeMaturity × CVSSv3RemediationLevel × CVSSv3ReportConfidence)
-
This entry is optional
- a Score number from 0 to 10
temporal severity
-
This entry is optional
- Allowed Values:
- critical
- high
- low
- medium
- none
- Allowed Values:
captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component
-
This entry is optional
- CVSSv3UserInteraction Captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner. This metric value is greatest when no user interaction is required. The list of possible values is:
none
: The vulnerable system can be exploited without interaction from any user.required
: Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator. - Allowed Values:
- none
- required
- Reference: [User Interaction] (https://www.first.org/cvss/specification-document#2-1-4-User-Interaction-UI)
- CVSSv3UserInteraction Captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner. This metric value is greatest when no user interaction is required. The list of possible values is:
-
This entry is required
- a text representation of a set of CVSSv3 metrics. It is commonly used to record or transfer CVSSv3 metric information in a concise form
Property | Type | Description | Required? |
---|---|---|---|
base_score | Number | The base score is a key metric in CVSS, which uses a scoring system to determine the level of severity of a vulnerability. see: https://www.first.org/cvss/v2/guide | ✓ |
base_severity | HighMedLowString | ✓ | |
vector_string | String | ✓ | |
access_complexity | CVSSv2AccessComplexityString | ||
access_vector | CVSSv2AccessVectorString | ||
authentication | CVSSv2AuthenticationString | ||
availability_impact | CVSSv2AvailabilityImpactString | ||
availability_requirement | CVSSv2SecurityRequirementString | ||
collateral_damage_potential | CVSSv2CollateralDamagePotentialString | ||
confidentiality_impact | CVSSv2ConfidentialityImpactString | ||
confidentiality_requirement | CVSSv2SecurityRequirementString | ||
environmental_vector_string | String | ||
exploitability | CVSSv2ExploitabilityString | ||
exploitability_score | Number | ||
impact_score | Number | ||
integrity_impact | CVSSv2IntegrityImpactString | ||
integrity_requirement | CVSSv2SecurityRequirementString | ||
obtain_all_privilege | Boolean | ||
obtain_other_privilege | Boolean | ||
obtain_user_privilege | Boolean | ||
remediation_level | CVSSv2RemediationLevelString | ||
report_confidence | CVSSv2ReportConfidenceString | ||
target_distribution | CVSSv2TargetDistributionString | ||
temporal_vector_string | String | ||
user_interaction_required | Boolean |
-
This entry is optional
- CVSSv2AccessComplexity This metric measures the complexity of the attack required to exploit the vulnerability once an attacker has gained access to the target system. For example, consider a buffer overflow in an Internet service: once the target system is located, the attacker can launch an exploit at will.
- Allowed Values:
- high
- low
- medium
- Reference: https://www.first.org/cvss/v2/guide#2-1-2-Access-Complexity-AC
-
This entry is optional
- CVSSv2AccessVector This metric reflects how the vulnerability is exploited.The more remote an attacker can be to attack a host, the greater the vulnerability score.
- Allowed Values:
- adjacent network
- local
- network
- Reference: https://www.first.org/cvss/v2/guide#2-1-1-Access-Vector-AV
-
This entry is optional
- CVSSv2Authentication This metric measures the number of times an attacker must authenticate to a target in order to exploit a vulnerability. This metric does not gauge the strength or complexity of the authentication process, only that an attacker is required to provide credentials before an exploit may occur. The fewer authentication instances that are required, the higher the vulnerability score.
- Allowed Values:
- multiple
- none
- single
- Reference: https://www.first.org/cvss/v2/guide#2-1-3-Authentication-Au
-
This entry is optional
- CVSSv2AvailabilityImpact This metric measures the impact to availability of a successfully exploited vulnerability. Availability refers to the accessibility of information resources. Attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system. Increased availability impact increases the vulnerability score.
- Allowed Values:
- complete
- none
- partial
- Reference: https://www.first.org/cvss/v2/guide#2-1-6-Availability-Impact-A
-
This entry is optional
- CVSSv2SecurityRequirement These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a users organization, measured in terms of confidentiality, integrity, and availability, That is, if an IT asset supports a business function for which availability is most important, the analyst can assign a greater value to availability, relative to confidentiality and integrity. Each security requirement has three possible values: low, medium, or high.
- Allowed Values:
- high
- low
- medium
- not_defined
- Reference: https://www.first.org/cvss/v2/guide#2-3-3-Security-Requirements-CR-IR-AR
The base score is a key metric in CVSS, which uses a scoring system to determine the level of severity of a vulnerability. see: https://www.first.org/cvss/v2/guide
-
This entry is required
- a Score number from 0 to 10
-
This entry is required
- Allowed Values:
- High
- Info
- Low
- Medium
- None
- Unknown
- Reference: HighMedLowVocab
- Allowed Values:
-
This entry is optional
- CVSSv2CollateralDamagePotential This metric measures the potential for loss of life or physical assets through damage or theft of property or equipment. The metric may also measure economic loss of productivity or revenue. Naturally, the greater the damage potential, the higher the vulnerability score.
- Allowed Values:
- high
- low
- low_medium
- medium_high
- none
- not_defined
- Reference: https://www.first.org/cvss/v2/guide#2-3-1-Collateral-Damage-Potential-CDP
-
This entry is optional
- CVSSv2ConfidentialityImpact This metric measures the impact on confidentiality of a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. Increasedconfidentiality impact increases the vulnerability score.
- Allowed Values:
- complete
- none
- partial
- Reference: https://www.first.org/cvss/v2/guide#2-1-4-Confidentiality-Impact-C
-
This entry is optional
- CVSSv2SecurityRequirement These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a users organization, measured in terms of confidentiality, integrity, and availability, That is, if an IT asset supports a business function for which availability is most important, the analyst can assign a greater value to availability, relative to confidentiality and integrity. Each security requirement has three possible values: low, medium, or high.
- Allowed Values:
- high
- low
- medium
- not_defined
- Reference: https://www.first.org/cvss/v2/guide#2-3-3-Security-Requirements-CR-IR-AR
-
This entry is optional
- A text representation of a set of CVSSv2 environmental metrics. Environmental metrics allow analysists to calculate threat scores in relation to environmental security requirements, collateral damage potential, and target availability. It is commonly used to record or transfer CVSSv2 metric information in a concise form
-
This entry is optional
- CVSSv2Exploitability This metric measures the current state of exploit techniques or code availability. Public availability of easy-to-use exploit code increases the number of potential attackers by including those who are unskilled thereby increasing the severity of the vulnerability.
- Allowed Values:
- functional
- high
- not_defined
- proof_of_concept
- unproven
- Reference: https://www.first.org/cvss/v2/guide#2-2-1-Exploitability-E
-
This entry is optional
- a Score number from 0 to 10
-
This entry is optional
- a Score number from 0 to 10
-
This entry is optional
- CVSSv2IntegrityImpact This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and guaranteed veracity of information. Increased integrity impact increases the vulnerability score.
- Allowed Values:
- complete
- none
- partial
- Reference: https://www.first.org/cvss/v2/guide#2-1-5-Integrity-Impact-I
-
This entry is optional
- CVSSv2SecurityRequirement These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a users organization, measured in terms of confidentiality, integrity, and availability, That is, if an IT asset supports a business function for which availability is most important, the analyst can assign a greater value to availability, relative to confidentiality and integrity. Each security requirement has three possible values: low, medium, or high.
- Allowed Values:
- high
- low
- medium
- not_defined
- Reference: https://www.first.org/cvss/v2/guide#2-3-3-Security-Requirements-CR-IR-AR
- This entry is optional
- This entry is optional
- This entry is optional
-
This entry is optional
- CVSSv2RemediationLevel The remediation level of a vulnerability is an important factor for prioritization. The typical vulnerability is unpatched when initially published. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued. Each of these respective stages adjusts the temporal score downwards, reflecting the decreasing urgency as remediation becomes final. The less official and permanent a fix, the higher the vulnerability score is.
- Allowed Values:
- not_defined
- official_fix
- temporary_fix
- unavailable
- workaround
- Reference: https://www.first.org/cvss/v2/guide#2-2-2-Remediation-Level-RL
-
This entry is optional
- CVSSv2ReportConfidence This metric measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details. Sometimes, only the existence of vulnerabilities are publicized, but without specific details. The vulnerability may later be corroborated and then confirmed through acknowledgement by the author or vendor of the affected technology. The urgency of a vulnerability is higher when a vulnerability is known to exist with certainty. This metric also suggests the level of technical knowledge available to would-be attackers. The more a vulnerability is validated by the vendor or other reputable sources, the higher the score.
- Allowed Values:
- confirmed
- not_defined
- unconfirmed
- uncorroborated
- Reference: https://www.first.org/cvss/v2/guide#2-2-3-Report-Confidence-RC
-
This entry is optional
- CVSSv2TargetDistribution This metric measures the proportion of vulnerable systems. It is meant as an environment-specific indicator in order to approximate the percentage of systems that could be affected by the vulnerability. The greater the proportion of vulnerable systems, the higher the score.
- Allowed Values:
- high
- low
- medium
- none
- not_defined
- Reference: https://www.first.org/cvss/v2/guide#2-3-2-Target-Distribution-TD
-
This entry is optional
- A text representation of a set of CVSSv2 temporal metrics. Temporal metrics allow analysists to calculate threat severity based on temporal factors such as reliability of vulnerability reports, availability of mitigations, and the ease or difficulty of conducting the exploit. It is commonly used to record or transfer CVSSv2 metric information in a concise form
- This entry is optional
-
This entry is required
- a text representation of a set of CVSSv2 metrics. It is commonly used to record or transfer CVSSv2 metric information in a concise form
Property | Type | Description | Required? |
---|---|---|---|
CVE_data_version | ShortStringString | Specifies the version of the CVE (Common Vulnerabilities and Exposures) dictionary used by the vulnerability information provider. | ✓ |
nodes | CPENode Object List | Each node in the CTIM standard configuration includes information such as the operator (such as "less than", or "greater than or equal to"), and the cpe (Common Platform Enumeration) string which identifies the specific software, CPE is a structured naming scheme for IT systems, platforms, and software packages, and it is instrumental in enabling data exchange between different systems. |
✓ |
Specifies the version of the CVE (Common Vulnerabilities and Exposures) dictionary used by the vulnerability information provider.
-
This entry is required
- ShortString String with at most 1024 characters.
Each node
in the CTIM standard configuration includes information such as the operator
(such as "less than", or "greater than or equal to"), and the cpe
(Common Platform Enumeration) string which identifies the specific software, CPE
is a structured naming scheme for IT systems, platforms, and software packages, and it is instrumental in enabling data exchange between different systems.
- This entry is required
- This entry's type is sequential (allows zero or more values)
- CPENode Object Value
- Details: CPENode Object
Property | Type | Description | Required? |
---|---|---|---|
operator | cpe-node-operator-stringString | ✓ | |
children | CPELeafNode Object List | ||
cpe_match | CPEMatch Object List | ||
negate | Boolean | Negates operator when true. |
- This entry is optional
- This entry's type is sequential (allows zero or more values)
- CPELeafNode Object Value
- Details: CPELeafNode Object
- This entry is optional
- This entry's type is sequential (allows zero or more values)
- CPEMatch Object Value
- Details: CPEMatch Object
Negates operator when true.
- This entry is optional
-
This entry is required
- cpe-node-operator-string The operator string influences how seqs of cpe matches are related to one another.
- Allowed Values:
- AND
- OR
Property | Type | Description | Required? |
---|---|---|---|
cpe_match | CPEMatch Object List | ✓ | |
operator | cpe-node-operator-stringString | ✓ | |
negate | Boolean | Negates operator when true. |
- This entry is required
- This entry's type is sequential (allows zero or more values)
- CPEMatch Object Value
- Details: CPEMatch Object
Negates operator when true.
- This entry is optional
-
This entry is required
- cpe-node-operator-string The operator string influences how seqs of cpe matches are related to one another.
- Allowed Values:
- AND
- OR
Property | Type | Description | Required? |
---|---|---|---|
cpe23Uri | String | ✓ | |
vulnerable | Boolean | ✓ | |
versionEndExcluding | String | A string representing the upper bound(exclusive) of version in the CPE. | |
versionEndIncluding | String | A string representing the upper bound(inclusive) of version in the CPE. | |
versionStartExcluding | String | A string representing the lower bound(exclusive) of version in the CPE. | |
versionStartIncluding | String | A string representing the lower bound(inclusive) of version in the CPE. |
-
This entry is required
- A text representation of a software or hardware platform.
A string representing the upper bound(exclusive) of version in the CPE.
-
This entry is optional
- A string representing a bound of a version in the CPE.
A string representing the upper bound(inclusive) of version in the CPE.
-
This entry is optional
- A string representing a bound of a version in the CPE.
A string representing the lower bound(exclusive) of version in the CPE.
-
This entry is optional
- A string representing a bound of a version in the CPE.
A string representing the lower bound(inclusive) of version in the CPE.
-
This entry is optional
- A string representing a bound of a version in the CPE.
- This entry is required
Property | Type | Description | Required? |
---|---|---|---|
cpe23Uri | String | ✓ | |
vulnerable | Boolean | ✓ | |
versionEndExcluding | String | A string representing the upper bound(exclusive) of version in the CPE. | |
versionEndIncluding | String | A string representing the upper bound(inclusive) of version in the CPE. | |
versionStartExcluding | String | A string representing the lower bound(exclusive) of version in the CPE. | |
versionStartIncluding | String | A string representing the lower bound(inclusive) of version in the CPE. |
-
This entry is required
- A text representation of a software or hardware platform.
A string representing the upper bound(exclusive) of version in the CPE.
-
This entry is optional
- A string representing a bound of a version in the CPE.
A string representing the upper bound(inclusive) of version in the CPE.
-
This entry is optional
- A string representing a bound of a version in the CPE.
A string representing the lower bound(exclusive) of version in the CPE.
-
This entry is optional
- A string representing a bound of a version in the CPE.
A string representing the lower bound(inclusive) of version in the CPE.
-
This entry is optional
- A string representing a bound of a version in the CPE.
- This entry is required