Weakness A mistake or condition that, if left unaddressed, could under the proper conditions contribute to a cyber-enabled capability being vulnerable to attack, allowing an adversary to make items function in unintended ways.
Property | Type | Description | Required? |
---|---|---|---|
description | MarkdownString | Should be short and limited to the key points that define this weakness. | ✓ |
id | String | Globally unique URI identifying this object. | ✓ |
schema_version | String | CTIM schema version for this entity. | ✓ |
type | WeaknessTypeIdentifierString | The fixed value weakness | ✓ |
abstraction_level | WeaknessAbstractionLevelString | Refers to the level of abstraction or granularity used to describe the weakness. It helps to categorize the vulnerability based on the level of detail provided. | |
affected_resources | SystemResourceString List | Identifies system resources that can be affected by an exploit of this weakness. | |
alternate_terms | AlternateTerm Object List | Indicates one or more other names used to describe this weakness. | |
architectures | Architecture Object List | Applicable architectures. | |
background_details | MarkdownString | Information that is relevant but not related to the nature of the weakness itself. | |
common_consequences | Consequence Object List | Refers to the typical or expected negative effects that can result from exploiting the weakness. This could include anything from unauthorized access to data, denial of service, system crashes or other things. | |
detection_methods | DetectionMethod Object List | Identifies methods that may be employed to detect this weakness, including their strengths and limitations. | |
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. | |
functional_areas | FunctionalAreaString List | Identifies the functional area of the software in which the weakness is most likely to occur. | |
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. | |
languages | Language Object List | Applicable Languages. | |
likelihood | HighMedLowString | Likelihood of exploit. | |
modes_of_introduction | ModeOfIntroduction Object List | Information about how and when a given weakness may be introduced. | |
notes | Note Object List | Provides any additional comments about the weakness. | |
operating_systems | OperatingSystem Object List | Applicable operating systems. | |
paradigms | Paradigm Object List | Applicable paradigms. | |
potential_mitigations | Mitigation Object List | Describes potential mitigations associated with a weakness. | |
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. | |
structure | WeaknessStructureString | Defines the structural nature of the weakness. | |
technologies | Technology Object List | Applicable technologies. | |
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. |
Refers to the level of abstraction or granularity used to describe the weakness. It helps to categorize the vulnerability based on the level of detail provided.
This entry is optional
Class: is the highest level of abstraction and describes a general category of weaknesses. Examples of Classes include :"Buffer Errors", "Input Validation", or "Authentication Issues".
Base: More specific category than Class. A Base weakness is a concrete form of a Class weakness. An example of a Base weakness could be "SQL Injection".
Variant: Describes one specific type of Base weakness that is defined by alterations or extensions to the Base description. For example, "Blind SQL Injection" can be considered a Variant of the Base weakness "SQL Injection".
Compound: A Compound Weakness describes a weakness that combines two or more Base weaknesses to exploit a system. For example, a "Buffer-Overflow with Format-String Exploit" combines the Base weaknesses of "Buffer-Overflow" and "Format-String Vulnerability".
By specifying the abstraction level, cybersec professionals can more easily identify weaknesses that are related and prioritize their response efforts based on the potential impact of the vulnerability.
Identifies system resources that can be affected by an exploit of this weakness.
This entry is optional
This entry's type is sequential (allows zero or more values)
Indicates one or more other names used to describe this weakness.
Applicable architectures.
Information that is relevant but not related to the nature of the weakness itself.
This entry is optional
Refers to the typical or expected negative effects that can result from exploiting the weakness. This could include anything from unauthorized access to data, denial of service, system crashes or other things.
Should be short and limited to the key points that define this weakness.
This entry is required
Identifies methods that may be employed to detect this weakness, including their strengths and limitations.
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.
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.
Identifies the functional area of the software in which the weakness is most likely to occur.
This entry is optional
This entry's type is sequential (allows zero or more values)
Globally unique URI identifying this object.
This entry is required
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.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
Applicable Languages.
Likelihood of exploit.
This entry is optional
Information about how and when a given weakness may be introduced.
Provides any additional comments about the weakness.
Applicable operating systems.
Applicable paradigms.
Describes potential mitigations associated with a weakness.
A monotonically increasing revision, incremented each time the object is changed.
This entry is optional
CTIM schema version for this entity.
This entry is required
A single line, short summary of the object.
This entry is optional
Represents the source of the intelligence that led to the creation of the entity.
This entry is optional
URI of the source of the intelligence that led to the creation of the entity.
This entry is optional
Defines the structural nature of the weakness.
This entry is optional
Chain: A chain weakness might involve an attacker chaining together multiple vulnerabilities and exploits in order to achieve their end goal. For example, an attacker might use a phishing attack to gain access to a user's email account, then use information from that account to socially engineer their way through additional systems until they gain access to an internal network. In this case, the attacker is chaining multiple weaknesses together in order to achieve their ultimate objective.
Composite: A composite weakness might involve multiple vulnerabilities that exist in different layers or components of a system. For example, a composite weakness in a web application might involve both an injection vulnerability and a cross-site scripting vulnerability. An attacker could use these weaknesses in tandem to steal data or take over the system.
Simple: A simple weakness might involve a single vulnerability or exploit that can be used to achieve a specific objective. An example of a simple weakness might be a buffer overflow vulnerability in a software application. If an attacker can exploit this vulnerability, they may be able to execute arbitrary code on the system.
Applicable technologies.
The time this object was created at, or last modified.
This entry is optional
A short title for this object, used as primary display and reference value.
This entry is optional
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
The fixed value weakness
This entry is required
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. |
This entry is optional
An identifier for the external reference content.
Specifies a dictionary of hashes for the contents of the url.
The source within which the external-reference is defined (system, registry, organization, etc.)
This entry is required
A URL reference to an external resource.
This entry is optional
Property | Type | Description | Required? |
---|---|---|---|
prevalence | PrevalenceString | Defines the different regularities that guide the applicability of platforms. | ✓ |
class | LanguageClassString | Class of language. | |
name | ShortStringString | Language name (Clojure, Java, ...) |
Class of language.
This entry is optional
Language name (Clojure, Java, ...)
This entry is optional
Defines the different regularities that guide the applicability of platforms.
This entry is required
Property | Type | Description | Required? |
---|---|---|---|
prevalence | PrevalenceString | Defines the different regularities that guide the applicability of platforms. | ✓ |
class | OperatingSystemClassString | ||
cpe_id | ShortStringString | ||
name | ShortStringString | ||
version | ShortStringString |
This entry is optional
This entry is optional
This entry is optional
Defines the different regularities that guide the applicability of platforms.
This entry is required
This entry is optional
Property | Type | Description | Required? |
---|---|---|---|
prevalence | PrevalenceString | Defines the different regularities that guide the applicability of platforms. | ✓ |
class | ArchitectureClassString | Class of architecture | |
name | ShortStringString | Architecture name (ARM, x86, ...) |
Class of architecture
This entry is optional
Architecture name (ARM, x86, ...)
This entry is optional
Defines the different regularities that guide the applicability of platforms.
This entry is required
Property | Type | Description | Required? |
---|---|---|---|
prevalence | PrevalenceString | Defines the different regularities that guide the applicability of platforms. | ✓ |
name | ShortStringString | Paradigm name (Client Server, Mainframe) |
Paradigm name (Client Server, Mainframe)
This entry is optional
Defines the different regularities that guide the applicability of platforms.
This entry is required
Property | Type | Description | Required? |
---|---|---|---|
prevalence | PrevalenceString | Defines the different regularities that guide the applicability of platforms. | ✓ |
name | ShortStringString | Technology name (Web Server, Web Client) |
Technology name (Web Server, Web Client)
This entry is optional
Defines the different regularities that guide the applicability of platforms.
This entry is required
Property | Type | Description | Required? |
---|---|---|---|
term | ShortStringString | The actual alternate term. | ✓ |
description | MarkdownString | Provides context for the alternate term by which this weakness may be known. |
Provides context for the alternate term by which this weakness may be known.
This entry is optional
The actual alternate term.
This entry is required
Property | Type | Description | Required? |
---|---|---|---|
phase | SoftwarePhaseString | Identifies the point in the software life cycle at which the weakness may be introduced. | ✓ |
note | MarkdownString | Provides a typical scenario related to introduction during the given phase. |
Provides a typical scenario related to introduction during the given phase.
This entry is optional
Identifies the point in the software life cycle at which the weakness may be introduced.
This entry is required
Property | Type | Description | Required? |
---|---|---|---|
scopes | ConsequenceScopeString List | Identifies the security property that is violated. | ✓ |
impacts | TechnicalImpactString List | Describes the technical impact that arises if an adversary succeeds in exploiting this weakness. | |
likelihood | HighMedLowString | How likely the specific consequence is expected to be seen relative to the other consequences. | |
note | MarkdownString | Additional commentary about a consequence. |
Describes the technical impact that arises if an adversary succeeds in exploiting this weakness.
This entry is optional
This entry's type is sequential (allows zero or more values)
How likely the specific consequence is expected to be seen relative to the other consequences.
This entry is optional
Additional commentary about a consequence.
This entry is optional
Identifies the security property that is violated.
This entry is required
This entry's type is sequential (allows zero or more values)
Property | Type | Description | Required? |
---|---|---|---|
description | MarkdownString | Provides some context of how this method can be applied to a specific weakness. | ✓ |
method | DetectionMethodString | Identifies the particular detection method being described. | ✓ |
effectiveness | DetectionEffectivenessString | How effective the detection method may be in detecting the associated weakness. | |
effectiveness_notes | MarkdownString | Provides additional discussion of the strengths and shortcomings of this detection method. |
Provides some context of how this method can be applied to a specific weakness.
This entry is required
How effective the detection method may be in detecting the associated weakness.
This entry is optional
Provides additional discussion of the strengths and shortcomings of this detection method.
This entry is optional
Identifies the particular detection method being described.
This entry is required
Property | Type | Description | Required? |
---|---|---|---|
description | MarkdownString | A description of this individual mitigation including any strengths and shortcomings of this mitigation for the weakness. | ✓ |
effectiveness | EffectivenessString | Summarizes how effective the mitigation may be in preventing the weakness. | |
effectiveness_notes | MarkdownString | ||
phases | SoftwarePhaseString List | Indicates the development life cycle phase during which this particular mitigation may be applied. | |
strategy | MitigationStrategyString | A general strategy for protecting a system to which this mitigation contributes. |
A description of this individual mitigation including any strengths and shortcomings of this mitigation for the weakness.
This entry is required
Summarizes how effective the mitigation may be in preventing the weakness.
This entry is optional
This entry is optional
Indicates the development life cycle phase during which this particular mitigation may be applied.
This entry is optional
This entry's type is sequential (allows zero or more values)
A general strategy for protecting a system to which this mitigation contributes.
This entry is optional
Property | Type | Description | Required? |
---|---|---|---|
note | MarkdownString | ✓ | |
type | NoteTypeString | ✓ |
This entry is required
This entry is required
Can you improve this documentation? These fine people already did:
Ag Ibragimov, Guillaume Buisson, Ambrose Bonnaire-Sergeant, Guillaume Erétéo & Matthieu SprunckEdit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close