: Public Class
Created: 08.06.2017 15:34:38
Modified: 10.03.2020 14:14:49
Project:
Advanced:
Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. (Source: NIST)<br/><br/>Semantics:<br/><br/>In order to represent the weak spots in the system architecture, a vulnerability describes the weakness and affiliation to one or more Items. Vulnerabilites are concrete definitions of faulty software or configurations and requirements must be derived from them. Vulnerabilites have a scope. The scope of a vulnerability is changed, if a successful attack affects more security goals and vulnerabilities, i.e., enabling follow-up attacks.<br/><br/>Constraints:<br/><br/>[1] Items must have at least one Vulnerability in a SAM model.<br/><br/>Optional:<br/>[2] Vulnerabilities should have a score<br/><br/>Notation:<br/><br/>The Vulnerability is shown as a solid-outline rectangle with a warning icon containing the name and its properties.<br/><br/>Extension: UML::Class<br/><br/>
Attribute
Public String
  exploitCodeMaturity (E)
Details:
Notes: 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.<br/><br/>Not Defined (X) Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.<br/><br/>High (H) 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.<br/><br/>Functional (F) Functional exploit code is available. The code works in most situations where the vulnerability exists.<br/><br/>Proof-of-Concept (P) 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.<br/><br/>Unproven (U) No exploit code is available, or an exploit is theoretical.<br/><br/>This metric is not limited to pure attack models based on software and systems, but can also be related to methods and processes for the application of social engineering attacks.<br/>
Public String
  remediationLevel (RL)
Details:
Notes: 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, upgrade or a counter measure is issued. Each of these respective stages adjusts the temporal score downwards, reflecting the decreasing urgency as remediation becomes final.<br/><br/>Not Defined (X) Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.<br/><br/>Unavailable (U) There is either no solution available or it is impossible to apply.<br/><br/>Workaround (W) 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.<br/><br/>Temporary Fix (T) There is an official but temporary fix available. This includes instances where the vendor issues a temporary hotfix, tool, or workaround.<br/><br/>Official Fix (O) A complete vendor solution is available. Either the vendor has issued an official patch, or an upgrade is available.<br/>
Public String
  reportConfidence (RC)
Details:
Notes: 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. 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.<br/><br/>Not Defined (X) Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.<br/><br/>Confirmed (C) Detailed reports exist, or functional reproduction is possible (functional exploits may provide this). Source code is available to independently verify the assertions of the research, or the author or vendor of the affected code has confirmed the presence of the vulnerability.<br/><br/>Reasonable (R) 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.<br/><br/>Unknown (U) 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.<br/>
Public String
  scope (S)
Details:
Notes: 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.<br/><br/>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.<br/><br/>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.<br/><br/>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.<br/><br/>The Base score is greater when a scope change has occurred.<br/><br/>Unchanged (U) 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.<br/><br/>Changed (C) 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.<br/>
Public String
  security procedure concept
Details:
Notes: A security procedure concept can also be decisive for a weak point if it has deficiencies. Especially when the security procedure concept is incomplete or compliance with it cannot be guaranteed. For example, when an employee leaves, they can forget to deactivate their access account or the authorization to use the company credit card. As a result, damage is caused unconsciously by the employee or by an attacker who knows about it.<br/><br/><br/>
Element Source Role Target Role
VulnerabilityScore
Class   		Name:  
  		Name: score
 
Details:
 
Target
Class   		Name:  
  		Name:  
 
Details:
An attacker might attack an ItemCharacteristic without there being an Item to actually provide that specific property or characteristic<br/>
Requirement
Class   		Name:  
  		Name: nonFullfilledRequirement
 
Details:
 
Element Source Role Target Role
ThreatScenario
Class   		Name:  
  		Name:  
 
Details:
 
Object Type Connection Direction Notes
TraceableSpecification Class Generalization To