5th Reduction

# ID PAPER TAXONOMY LEVEL 0 LEVEL 1 LEVEL 2 LEVEL 3 LEVEL 4 METRIC KEY WORD DEFINITION SCALE SCOPE AUTOMATION MEASUREMENT WHAT? USABLE EXECUTION TIME INFORMATION OBTAINED REASON      
5 2   YES Vulnerability metrics Measuring User Vulnerabilities Password Vulnerabilities - - Entropy PASSWORD     USER AUTOMATIC STATIC - YES     This could be used with keys instead of passwords to measure randomness   * This information was induced by me
8 2   YES Vulnerability metrics Measuring Interface-Induced Vulnerabilities - - - Attack surface SURFACE It aim to measure the ways by which an attacker can compromise a targeted software ABSOLUTE DEVICE   STATIC DEVICE YES            
9 2   YES Vulnerability metrics Measuring Software Vulnerabilities Temporal Attributes of Vulnerabilities Evolution of vulnerabilities - Historical vulnerability metric VULNERABILITY It measures the degree that a system is vulnerable (i.e., frequency of vulnerabilities) in the past RATIO BSOLUTE ISTRIBUTION DEVICE   STATIC   YES     This could be part of a checklist of task, to check if there is any vulnerability that affects the device      
10 2   YES Vulnerability metrics Measuring Software Vulnerabilities Temporal Attributes of Vulnerabilities Evolution of vulnerabilities - Historically exploited vulnerability metric VULNERABILITY It measures the number of vulnerabilities exploited in the past RATIO BSOLUTE ISTRIBUTION DEVICE   STATIC   YES     This could be part of a checklist of task, to check if there is any vulnerability that affects the device      
13 2   YES Vulnerability metrics Measuring Software Vulnerabilities Temporal Attributes of Vulnerabilities Evolution of vulnerabilities - Tendency-to-be-exploited metric   It measures the tendency that a vulnerability may be exploited, where the “tendency” may be derived from information sources such as posts on Twitter before vulnerability disclosures RATIO BSOLUTE ISTRIBUTION DEVICE   STATIC   ¿?     This research work might not be part of a security evaluation, but could be applied if so      
15 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base Exploitability Metrics Attack vector   Describes whether a vulnerability can be exploited remotely, adjacently, locally, or physically (i.e., attacker must have physical access to the computer) NOMINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
16 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base Exploitability Metrics Attack complexity   Describes the conditions that must hold before an attacker can exploit the vulnerability, such as low or high ORDINA SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
17 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base Exploitability Metrics Privilege required   Describes the level of privileges that an attacker must have in order to exploit a vulnerability, such as none, low, or high ORDINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
18 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base Exploitability Metrics User interaction   Describes whether the exploitation of a vulnerability requires the participation of a user (other than the attacker), such as none or required NOMINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
19 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base Exploitability Metrics Authorization scope   Describes whether or not a vulnerability has an impact on resources beyond its privileges (e.g., sandbox or virtual machine), such as unchanged or changed NOMINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
20 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base Impact Metrics Confidentiality impact CONFIDENTIALITY The impact of a successful exploitation of a vulnerability in terms of confidentiality such as none, low, high ORDINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
21 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base Impact Metrics Integrity impact   The impact of a successful exploitation of a vulnerability in terms of integrity such as none, low, high ORDINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
22 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base Impact Metrics Availability impact AVAILABILITY The impact of a successful exploitation of a vulnerability in terms of availability, such as none, low, high ORDINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
23 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base CVSS Temporal Metrics Exploit code maturity   The likelihood a vulnerability can be attacked based on the current exploitation techniques, such as undefined, unproven, proof-of-concept, functional, or high ORDINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
24 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base CVSS Temporal Metrics Remediation level   Describes whether or not a remediation method is available for a given vulnerability, such as undefined, unavailable, workaround, temporary fix, or official fix NOMINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
25 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base CVSS Temporal Metrics Report confidence   Measures the level of confidence for a given vulnerability as well as known technical details, such as unknown, reasonable, or confirmed NOMINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
26 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of Individual Software Vulnerabilities CVSS Base CVSS Environmental Metrics Security requirement   Describes environment-dependent security requirements in terms of confidentiality, integrity, and availability, such as not defined, low, medium, or high NOMINAL SOFTWARE   STATIC   YES     For calculating new vulnerabilities, or to know each dimension of known vulnerabilities      
29 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of a Collection of Vulnerabilities Deterministic Severity Metrics (attack graphs) Effort metrics Necessary defense metric   It estimates a minimal set of defense countermeasures necessary for thwarting a certain attack - DEVICE   STATIC   YES     This is related with the defenses that are necesary to implement so the system is secure for a certain vulnerability      
30 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of a Collection of Vulnerabilities Deterministic Severity Metrics (attack graphs) Effort metrics Effort-to-security-failure metric EFFORT It measures an attacker’s effort to reach its goal state - DEVICE   DYNAMIC*   YES     Although it might be difficult to estimate, this could be also included in the evaluation process      
31 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of a Collection of Vulnerabilities Deterministic Severity Metrics (attack graphs) Effort metrics Weakest adversary metric EFFORT It estimates minimum adversary capabilities required to achieve an attack goal - DEVICE   DYNAMIC*   ¿?     If the effort can be calculated in an objective manner, this could be used in embedded systems      
33 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of a Collection of Vulnerabilities Probabilistic Severity Metrics Metrics treating CVSS scores as atomic parameters Likelihood of exploitation   It measures the probability that an exploit will be executed by an attacker with certain capabilities - SOFTWARE   STATIC   ¿?     This is related with statistics and risk assessment. It could be applied      
34 2   YES Vulnerability metrics Measuring Software Vulnerabilities Severity of a Collection of Vulnerabilities Probabilistic Severity Metrics Metrics not treating CVSS scores as atomic parameters Effective base metric / scope   Given an attack graph and a subset of exploits, the effective base metric aims to adjust the CVSS base metric by taking the highest value of the ancestors of an exploit to reflect the worst-case scenario, while the effective base score metric is calculated based on the effective base metric - SOFTWARE   STATIC   -     -      
35 2   YES Defense metrics Strength of Preventive Defenses Metrics for Blacklisting - - Reaction time metric TIME It captures the delay between the observation of the malicious entity at time t and the blacklisting of the malicious entity at time t (i.e., t − t) ABSOLUTE DEVICE   DYNAMIC   YES     If the device has any kind of detection mechanism, this could be used. Detection and reaction might have different times      
36 2   YES Defense metrics Strength of Preventive Defenses Metrics for Blacklisting - - Coverage metric COVERAGE It estimates the portion of blacklisted malicious players ORDINAL DEVICE   STATIC   YES     This could be used, but the device has to have a blacklist      
37 2   YES Defense metrics Strength of Preventive Defenses Metrics for DEP - - NO METRIC IS DEFINED   No metrics have been defined to measure the effectiveness of DEP. The effectiveness of DEP can be measured based on the probability of being compromised by a certain attack A(t) over all possible classes of attacks - DEVICE   -   -     No metric is defined      
38 2   YES Defense metrics Strength of Preventive Defenses Metrics for CFI - - Average indirect target reduction   It counts the overall reduction of targets for any indirect control-flow transfer. It measures the overall reduction in terms of the number of targets exploitable by the attacker where smaller targets are more secure ABSOLUTE UNKNOWN   UNKNOWN   UNKNOWN     UNKNOWN      
39 2   YES Defense metrics Strength of Preventive Defenses Metrics for CFI - - Average target size   Ratio between the size of the largest target and the number of targets - UNKNOWN   UNKNOWN   UNKNOWN     UNKNOWN      
40 2   YES Defense metrics Strength of Preventive Defenses Metrics for CFI - - Evasion resistance   It is measured against control flow bending attacks, reflecting the effort (or premises) that an attacker must make (or satisfy) for evading the CFI scheme - UNKNOWN   UNKNOWN   UNKNOWN     UNKNOWN      
41 2   YES Defense metrics Measuring the Strength of Reactive Defenses Metrics for Monitoring - - Coverage metric COVERAGE It measures the fraction of events detectable by a specific sensor deployment, reflecting a defender’s need in monitoring events - DEVICE   DYNAMIC   UNKNOWN     UNKNOWN      
42 2   YES Defense metrics Measuring the Strength of Reactive Defenses Metrics for Monitoring - - Redundancy metric   It estimates the amount of evidence provided by a specific sensor deployment to detect an event - DEVICE   DYNAMIC   YES     This can be applied to devices as a whole, to check any mechanism of intrusion detection (mostly, tanti-tampering and software)      
43 2   YES Defense metrics Measuring the Strength of Reactive Defenses Metrics for Monitoring - - Confidence metric   It measures how well-deployed sensors detect an event in the presence of compromised sensors - DEVICE   DYNAMIC   YES     This can be applied to devices as a whole, to check any mechanism of intrusion detection (mostly, tanti-tampering and software)      
45 2   YES Defense metrics Measuring the Strength of Reactive Defenses Metrics for Detection Mechanisms Individual Strength of Defense Mechanisms - Detection time TIME For instrument-based attack detection, this metric is used to measure the delay between the time t0 at which a compromised computer sends its first scan packet and the time t that a scan packet is observed by the instrument - UNKNOWN   UNKNOWN   UNKNOWN     UNKNOWN      
57 2   YES Defense metrics Measuring the Strength of Proactive Defenses Address Space Layout Randomization (ASLR) - - ASLR-induced Effective entropy metric   Measure of entropy in user space memory which quantitatively considers an adversary’s ability to leverage low entropy regions of memory via absolute and dynamic inter-section connections - SOFTWARE   DYNAMIC OS YES     If the device runs an OS, this could be applied      
59 2   YES Defense metrics Measuring the Strength of Overall Defenses - - - Penetration resistance (PR)   Running a penetration test to estimate the level of effort (e.g., person-day or cost) required for a red team to penetrate into a system - DEVICE ETWORK   DYNAMIC   YES     Penetration testing is a really common way to test this kind of device      
82 2   YES Situation metrics Measuring Security State Model-Driven Metrics - - Probability a computer is compromised at time t   It quantifies the degree of security in enterprise systems by using modeling techniques based on a holistic perspective - DEVICE ETWORK   ¿?   ¿?     Although this is a network-oriented metric, this might be adapted to be used with an embedded system      
85 2   YES Situation metrics Measuring Security Incidents Frequency of Security Incidents - - Blocking rate   The rate an encountered attack is successfully defended by a deployed defense - NETWORK   DYNAMIC   ¿?     Although this is a network-oriented metric, this might be adapted to be used with an embedded system (maybe for a penetration test)      
89 2   YES Situation metrics Measuring Security Incidents Frequency of Security Incidents - - Time-to-first-compromise metric TIME Estimates the duration of time between when a computer starts to run and the first malware alarm is triggered on the computer where the alarm indicates detection rather than infection - DEVICE   DYNAMIC   YES     This can be used in embedded systems, but it might not be suitable for a security evaluation (maybe for a penetration test)      
96 10   YES Host-based Without Probability Values - - - Attack Impact   It is the quantitative measure of the potential harm caused by an attacker to exploit a vulnerability - NETWORK   STATIC                
97 10   YES Host-based Without Probability Values - - - Attack Cost COST It is the cost spent by an attacker to successfully exploit a vulnerability (i.e., security weakness) on a host - NETWORK   STATIC YNAMIC   YES     This is related to network, but this could be applicable to devices too      
100 10   YES Host-based Without Probability Values - - - Mean-time-to-compromise (MTTC) TIME It is used to measure how quickly a network can be penetrated - NETWORK   DYNAMIC   ¿?     This is no directly applicable, but its equivalent would be a penetration attack in an embedded system      
101 10   YES Host-based Without Probability Values - - - Mean-time-to-recovery (MTTR) TIME It is used to assess the effectiveness of a network to recovery from an attack incidents. It is defined as the average amount of time required to restore a system out of attack state - NETWORK   DYNAMIC   ¿?     Although this is developed for networks, the same concept can be translated into embeded systems      
105 10   YES Host-based Without Probability Values - - - Return on Attack   The gain the attacker expects from successful attack over the losses he sustains due to the countermeasure deployed by his target - NETWORK   ¿?   ¿?     Network-related, but it scent can be translated into embedded systems      
106 10   YES Host-based With Probability Values - - - Common Vulnerability Scoring System (CVSS) - Overall value VULNERABILITY The overall score is determined by generating a base score and modifying it through the temporal and environmental formulas - DEVICE   STATIC   YES     This could be used tohether with other metics to obtain a numeric value      
107 10   YES Host-based With Probability Values - - - Probability of Vulnerability Exploited VULNERABILITY It is used to assess the likelihood of an attacker exploiting a specific vulnerability on a host - SOFTWARE ARDWARE ETWORK   STATIC   ¿?     Network-related metric. This is also related to risk assessment. Can be traslated into embedded systems      
108 10   YES Host-based With Probability Values - - - Probability of attack detection   It is used to assess the likelihood of a countermeasure to successfully identify the event of an attack on a target - SOFTWARE ARDWARE ETWORK   DYNAMIC   ¿?     Network-related metric. This is also related to risk assessment. Can be traslated into embedded systems      
109 10   YES Host-based With Probability Values - - - Probability of host compromised   It is used to assess the likelihood of an attacker to successfully compromise a target - HARDWARE OFTWARE ETWORK   STATIC YNAMIC   ¿?     Network-related metric. This is also related to risk assessment. Can be traslated into embedded systems      
137 4   YES - - - - - Number of bits leaked (mean privacy) DATA     NETWORK SEMI-AUTOMATIC STATIC   ¿?     If adapted, this metric can be used to test memory related vulnerabilities      
139 5   NO - - - - - rav OPSEC It is a scale measurement of the attack surface, the amount of uncontrolled interactions with a target, which is calculated by the quantitative balance between operations, limitations, and controls -                      
141 11   YES Churn - - - - Churn CODE Count of Source Lines of Code that has been added or changed in a component since the previous revision of the software - SOFTWARE - -   -            
148 11   YES Churn - - - - Relative churn CODE Normalized by parameters such as lines of code, files counts - SOFTWARE AUTOMATIC* STATIC*                
149 11   YES Churn - - - - Repeat frequency CODE The number of consecutive edits that are performed on a binary - SOFTWARE AUTOMATIC* STATIC*                
150 11   YES Churn - - - - Total churn CODE The total added, modified, and deleted lines of code of a binary during the development - SOFTWARE AUTOMATIC* STATIC*                
155 11   YES Complexity* - - - - Cyclomatic number CODE M = E − N + P, where E = the number of edges of the graph. N = the number of nodes of the graph. P = the number of connected components.   SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
158 11   YES Complexity - - - - Fan in (FI) COUPLING Number of inputs a function uses. Inputs include parameters and global variables that are used (read) in the function / Number of functions calling a function - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
159 11   YES Complexity - - - - Fan out (FO) COUPLING Number of outputs that are set. The outputs can be parameters or global variables (modified) / Number of functions called by a function - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
162 11   YES Complexity - - - - Max fan in CODE The largest number of inputs to a function such as parameters and global variables - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
163 11   YES Complexity - - - - Max fan out CODE The largest number of assignment to the parameters to call a function or global variables - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
164 11   YES Complexity - - - - MaxMaxNesting CODE The maximum of MaxNesting in a file - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
165 11   YES Complexity - - - - MaxNesting CODE Maximum nesting level of control constructs such as if or while statements in a function - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
166 11   YES Complexity - - - - Nesting complexity CODE Maximum nesting level of control constructs (if, while, for, switch, etc.) in the function - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
167 11   YES Complexity - - - - Number of children (NOC) CODE Number of immediate sub-classes of a class or the count of derived classes. If class CA inherits class CB, then CB is the base class and CA is the derived class. In other words, CA is the children of class CB, and CB is the parent of class CB. - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
168 11   YES Complexity - - - - SumCyclomaticStrict CODE The sum of the strict cyclomatic complexity, where strict cyclomatic complexity is defined as the number of conditional statements in a function - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
169 11   YES Complexity - - - - SumEssential CODE The sum of essential complexity, where essential complexity is defined as the number of branches after reducing all the programming primitives such as a for loop in a function’s control flow graph into a node iteratively until the graph cannot be reduced any further. Completely well-structured code has essential complexity 1 - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
170 11   YES Complexity - - - - SumFanIn CODE The sum of FanIn, where FanIn is defined as the number of inputs to a function such as parameters and global variables - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
171 11   YES Complexity - - - - SumFanOut CODE The sum of FanOut, where FanOut is defined as the number of assignment to the parameters to call a function or global variables - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
172 11   YES Complexity - - - - SumMaxNesting CODE The sum of the MaxNesting in a file, where MaxNesting is defined as the maximum nesting level of control constructs such as if or while statements in a function - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
173 11   YES Complexity - - - - McCabe Cyclomatic Complexity CODE M = E − N + 2P, where E = the number of edges of the graph. N = the number of nodes of the graph. P = the number of connected components - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
174 11   YES Complexity - - - - Weighted methods per class (WMC) CODE Number of local methods defined in the class - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
181 11   YES Coverage - - - - Administrator and operator logs LOG Total number corrective actions taken after specific event is recorded in log / total number of events recorded in log * 100 -                      
187 11   YES Coverage - - - - Classified Accessor Attribute Interactions (CAAI) CODE The ratio of the sum of all interactions between accessors and classified attributes to the possible maximum number of interactions between accessors and classified attributes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
188 11   YES Coverage - - - - Classified Attributes Interaction Weight (CAIW) CODE The ratio of the number of all interactions with classified attributes to the total number of all interactions with all attributes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
189 11   YES Coverage - - - - Classified Class Data Accessibility (CCDA) CODE The ratio of the number of non-private classified class attributes to the number of classified attributes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
190 11   YES Coverage - - - - Classified Instance Data Accessibility (CIDA) CODE The ratio of the number of non-private classified instance attributes to the number of classified attributes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
191 11   YES Coverage - - - - Classified Method Extensibility (CME) CODE The ratio of the number of the non-finalised classified methods in program to the total number of classified methods in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
192 11   YES Coverage - - - - Classified Methods Weight (CMW) CODE The ratio of the number of classified methods to the total number of methods in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
193 11   YES Coverage - - - - Classified Mutator Attribute Interactions (CMAI) CODE The ratio of the sum of all interactions between mutators and classified attributes to the possible maximum number of interactions between mutators and classified attributes in the program. - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
194 11   YES Coverage - - - - Classified Operation Accessibility (COA) CODE The ratio of the number of non-private classified methods to the number of classified methods in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
195 11   YES Coverage - - - - Classified Writing Methods Proportion (CWMP) CODE The ratio of the number of methods which write classified attributes to the total number of classified methods in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
196 11   YES Coverage - - - - Composite-Part Critical Classes (CPCC) CODE The ratio of the number of critical composed-part classes to the total number of critical classes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
0 11   YES Coverage - - - - Classes Design Proportion (CDP) CODE Ratio of the number of critical classes to the total number of classes, from the group of Design Size Metrics. - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
201 11   YES Coverage - - - - Critical Class Extensibility (CCE) CODE The ratio of the number of the non-finalised critical classes in program to the total number of critical classes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
202 11   YES Coverage - - - - Critical Design Proportion (CDP) CODE The ratio of the number of critical classes to the total number of classes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
203 11   YES Coverage - - - - Critical Element Ratio CODE A process may not require all aspects of an object to be instantiated. Critical Elements Ratio = (Critical Data Elements in an Object) / (Total number of elements in the object) - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
204 11   YES Coverage - - - - Critical Serialized Classes Proportion (CSCP) CODE The ratio of the number of critical serialized classes to the total number of critical classes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
205 11   YES Coverage - - - - Critical Superclasses Inheritance (CSI) CODE The ratio of the sum of classes which may inherit from each critical superclass to the number of possible inheritances from all critical classes in the program’s inheritance hierarchy - SOFTWARE - -   ¿?            
206 11   YES Coverage - - - - Critical Superclasses Proportion (CSP) CODE The ratio of the number of critical superclasses to the total number of critical classes in the program’s inheritance hierarchy - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
212 11   YES Coverage - - - - Isolation (PI) CODE This assesses the level of security isolation between system components. This means getting privileges to a component does not imply accessibility of other co-located components. This metric can be assessed using system architecture and deployment models. Components marked as confidential should not be hosted with nonconfidential (public) components. Methods that are not marked as confidential should not have access to confidential attributes or methods - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     I am not sure if this metric can be applied to embedded software      
214 11   YES Coverage - - - - Number of Catch Blocks Per Class (NCBC) CODE It measures the exception handing factor (EHF) in some way. It is defined as the percentage of catch blocks in a class over the theoretical maximum number of catch blocks in the class - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
215 11   YES Coverage - - - - Percentage High-, medium- and moderate-Risk Software Hazards with Safety Requirements   It reveals whether all high-, medium- and moderate-risk software hazards have resulted in applicable safety requirements through hazard analysis - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     This is related to software and the design      
218 11   YES Coverage - - - - Percentage of Software Safety Requirements (PSSR)   How sufficient hazard analysis has been performed. (# Software Safety Requirements / # SoftwareRequirements) * 100 - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     This is related to software and the design      
219 11   YES Coverage - - - - Percentage of Software Safety Requirements Traceable to Hazards   Ensuring traceability to system hazards or System of Systems hazards increases the validation case. Percentage indicator of traceability of requirements. All derived software safety requirements must be traceable to system hazards or System of Systems hazards (# Traceable Software Safety Requirements / # Software Safety Requirements) * 100 - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     This is related to software and the design      
246 11 X YES Coverage - - - - PercentValidatedInput INPUTS To compute this metric, let T equal the count of the amount of input forms or interfaces the application exposes (the number of HTML form POSTs, GETs, and so on) and let V equal the number of these interfaces that use input validation mechanisms. The ratio V/T makes a strong statement about the Web application’s vulnerability to exploits from invalid input - SOFTWARE - -   YES     This could be adapted to other pieces of code, rather than just HTML      
247 11   YES Coverage - - - - Ratio of Design Decisions (RDD)   Ratio of the number of design decisions related to security to the total number of design decisions of the entire system. The objective is to assess the portion of design dedicated to security - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     This is related to design phase      
248 11   YES Coverage - - - - Ratio of Design Flaws Related to Security (RDF)   Ratio of design flaws related to security to the total number of design flaws applicable to the whole system - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     This is related to design phase      
250 11   YES Coverage - - - - Ratio of Implementation Errors That Have an Impact on Security (RSERR)   Ratio of the number of errors related to security to the total number of errors in the implementation of the system (i.e. NERR) - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     This is related to design phase      
253 11   YES Coverage - - - - Ratio of Patches Issued to Address Security Vulnerabilities (RP)   Ratio of the number of patches that are issued to address security vulnerabilities to the total number of patches of the system - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
254 11   YES Coverage - - - - Ratio of Security Requirements (RSR)   Ratio of the number of requirements that have direct impact on security to the total number of requirements of the system - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
255 11   YES Coverage - - - - Ratio of Security Test Cases (RTC)   Number of test cases designed to detect security issues to the total number of test cases of the entire system - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
256 11   YES Coverage - - - - Ratio of Security Test Cases that Fail (RTCP)   Number of test cases that detect implementation errors (i.e. the ones that fail) to the total number of test cases, designed specifically to target security issues - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
258 11   YES Coverage - - - - Ratio of Software Changes Due to Security Considerations (RSC)   Number of changes in the system triggered by a new set of security requirements. Software changes due to security considerations include patches that are released after a system is delivered, or any other security updates - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
261 11   YES Coverage - - - - Ratio of the Number of Omitted Exceptions (ROEX)   Ratio of the number of omitted exceptions (i.e. Noex) to the total number of exceptions that are related to security - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the software is available, it can be applied. It can be also applied to embedded software      
262 11   YES Coverage - - - - Ratio of the Number of Omitted Security Requirements (ROSR)   Ratio of the number of security requirements that have not been considered during the analysis phase (i.e. NOSR) to the total number of security requirements identified during the analysis phase (NSR) - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
269 11   YES Coverage - - - - Software Hazard Analysis Depth   Hazardous software, or safety-critical software, allocated as high- or medium-risk, according to the Software Hazard Criticality Matrix, requires analysis of second- and third-order causal factors (should they exist) - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     Hazard is similar to risk.      
273 11   YES Coverage - - - - Unaccessed Assigned Classified Attribute (UACA)   The ratio of the number of classified attributes that are assigned but never used to the total number of classified attributes in the program - SOFTWARE - -   -     Object-oriented programs      
274 11   YES Coverage - - - - Uncalled Classified Accessor Method (UCAM)   The ratio of the number of classified methods that access a classified attribute but are never called by other methods to the total number of classified methods in the program - SOFTWARE - -   -     Object-oriented programs      
275 11   YES Coverage - - - - Unused Critical Accessor Class (UCAC)   The ratio of the number of classes which contain classified methods that access classified attributes but are never used by other classes to the total number of critical classes in the program - SOFTWARE - -   -     Object-oriented programs      
284 11   YES Dependency - - - - Classified Attributes Inheritance (CAI) CODE The ratio of the number of classified attributes which can be inherited in a hierarchy to the total number of classified attributes in the program’s inheritance hierarchy - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
285 11   YES Dependency - - - - Classified Methods Inheritance (CMI) CODE The ratio of the number of classified methods which can be inherited in a hierarchy to the total number of classified methods in the program’s inheritance hierarchy - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
286 11   YES Dependency - - - - Coupling COUPLING Measures the following three coupling dimensions between modules: referential dependency, structural dependency, and data integrity dependency - SOFTWARE                    
288 11   YES Dependency - - - - Coupling Between Object classes (CBOC) COUPLING Number of other classes coupled to a class C - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
290 11   YES Dependency - - - - Coupling Corruption Propagation COUPLING Coupling corruption propagation is meant to measure the total number of methods that could be affected by erroneous originating method. Coupling Corruption Propagation = Number of child methods invoked with the parameter(s) based on the parameter(s) of the original invocation - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
291 11   YES Dependency - - - - Critical Classes Coupling (CCC) CODE The ratio of the number of all classes’ links with classified attributes to the total number of possible links with classified attributes in the program - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Object-oriented programs. If the software is available, it can be applied. It can be also applied to embedded software      
292 11   YES Dependency - - - - Depth of Inheritance Tree (DIT)   Maximum depth of the class in the inheritance tree - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
301 11   YES Dependency - - - - Lack of cohesion of methods (LCOM)   The LCOM value for a class C is defined as LCOM(C) = (1- \E(C)\ ÷ (\V(C)\ × \M(C)\)) × 100%, where V(C) is the set of instance variables, M(C) is the set of instance methods, and E(C) is the set of pairs (v,m) for each instance variable v in V(C) that is used by method m in M(C) - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
304 11   YES Dependency - - - - NumCalls   The number of calls to the functions defined in an entity - SOFTWARE       YES     If the software is available, it can be applied. It can be also applied to embedded software      
312 11   YES Dependency - - - - Reflection Package Boolean (RPB) CODE A boolean value representing whether the Java program imports the reflection package (1) or not (0) - SOFTWARE - -   -     Object-oriented programs      
0     YES Dependency - - - - Vulnerability Propagation (VP) CODE Vulnerability Propagation (VP) of a class C, denoted by VP(C), is the set containing classes in the hierarchy which directly or indirectly inherit class C. Cardinality of set VP(C) represents the number of classes which have become vulnerable due to class C. Alternatively, Vulnerability Propagation of a class C is the total number of classes which directly or indirectly inherit class C. - SOFTWARE AUTOMATIC* STATIC*   YES     This metric can be applied to embedded software      
315 11   YES Dependency - - - - Vulnerability Propagation Factor (VPF) CODE An Inheritance hierarchy may contain no class or one or more vulnerable classes. Also, there are more than one Inheritance hierarchies present in a design. So, calculation of Vulnerability Propagation Factor (VPF) of a design requires calculation of Vulnerability Propagation due to each vulnerable class in Inheritance hierarchies present in the design. Then, union of Vulnerability Propagation due to each vulnerable class will give overall Vulnerability Propagation in design. - SOFTWARE AUTOMATIC* STATIC*   YES     This metric can be applied to embedded software      
316 11   YES Effort - - - - Access Complexity (AC) ACCESS This metric measures the complexity of attacks exploiting the vulnerability. A vulnerability with low complexity can be for example a buffer overflow in a web server, the vulnerability can be exploited at will -                      
317 11   YES Effort - - - - Access Vector (AV) ACCESS This metric indicates from where an attacker can exploit the vulnerability -                      
320 11   YES Effort - - - - Authentication (AU) AUTHENTICATION This metric counts how often an attacker must authenticate before the vulnerability can be exploited -                      
322 11   YES Effort - - - - Damage potential-effort ratio   It indicates the level of damage an attacker can potentially cause to the system and the effort required for the attacker to cause such damage - DEVICE SEMI-AUTOMATIC* DYNAMIC*   YES     It seems that it can be applied to embeded systems, but I am not sure if it is applicable in the evaluation phase      
324 11   YES Effort - - - - ExclusiveExeTime   Execution time for the set of functions, S, defined in an entity excluding the execution time spent by the functions called by the functions in S -                      
327 11   YES Effort - - - - InclusiveExeTime   Execution time for the set of functions, S, defined in an entity including all the execution time spent by the functions called directly or indirectly by the functions in S -                      
332 11   YES Effort - - - - Protection Rate (PR)   It expresses the efficiency of security mechanisms. Percentage of the known vulnerabilities protected by a given security mechanism. It is based on the Attack Surface metric. PR = (1 - AttackSurfaceEvaluatedSystem / AttackSurfaceReferenceSystem) * 100 - SOFTWARE SEMI-AUTOMATIC* DYNAMIC*   ¿?     This metric was developed specificaly for OSGi platform, but I think it can be adapted to be applied to embedded systems      
334 11   YES Effort - - - - Side-channel Vulnerability Factor (SVF)   SVF quantifies patterns in attackers’ observations and measures their correlation to the victim’s actual execution patterns and in doing so captures systems’ vulnerability to side-channel attacks. we can measure information leakage by computing the correlation between ground-truth patterns and attacker observed patterns. We call this correlation Side-channel Vulnerability Factor (SVF). SVF measures the signal-to-noise ratio in an attacker’s observations. While any amount of leakage could compromise a system, a low signal-to-noise ratio means that the attacker must either make do with inaccurate results (and thus make many observations to create an accurate result) or become much more intelligent about recovering the original signal. We use phase detection techniques to find patterns in both sets of data then compute the correlation between actual patterns in the victim and observed patterns. - HARDWARE SEMI-AUTOMATIC* DYNAMIC*   YES     Embedded devices can be vulnerable to side-channel attacks and they can be tested      
336 11   YES Effort - - - - Structural severity RISK Measure that uses software attributes to evaluate the risk of an attacker reaching a vulnerability location from attack surface entry points. It is measured based on three values: high (reachable from an entry point), medium (reachable from an entry point with no dangerous system calls), low (not reachable from any entry points) - SOFTWARE SEMI-AUTOMATIC* DYNAMIC*   ¿?     I am not sure if this metric can be applied to embedded software      
0 11   YES Effort - - - - Vulnerability Index (VI)   Probability of a component’s vulnerability being exposed in a single execution - DEVICE MANUAL* DYNAMIC*   ¿?     It seems that it can be applied to embeded systems, but I am not sure if it is applicable in the evaluation phase      
0 11   YES Effort - - - - Effective Vulnerability Index (EVI)   Relative measure of the impact of a component on the system’s insecurity - DEVICE SEMI-AUTOMATIC* DYNAMIC*   ¿?     It seems that it can be applied to embeded systems, but I am not sure if it is applicable in the evaluation phase      
361 11   YES Size - - - - Classified Attributes Total (CAT)   The total number of classified attributes in the program - SOFTWARE - -   -     Object-oriented programs      
362 11   YES Size - - - - Classified Methods Total (CMT)   The total number of classified methods in the program - SOFTWARE - -   -     Object-oriented programs      
366 11   YES Size - - - - Count of Base Classes (CBC)   Number of base classes - SOFTWARE - -   -            
367 11   YES Size - - - - Critical Classes Total (CCT)   The total number of critical classes in the program - SOFTWARE - -   -     Object-oriented programs      
378 11   YES Size - - - - Number of Design Decisions Related to Security (NDD)   The proposed metric aims at assessing the number of design decisions that address the security requirements of the system. During the design phase, it is common to end up with multiple solutions to the same problem. Software engineers make many design decisions in order to choose among alternative design solutions. - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
383 11   YES Size - - - - Number of global variables *       SOFTWARE       YES     If the software is available, it can be applied. It can be also applied to embedded software      
390 11   YES Size - - - - Number of return points in the method       SOFTWARE       YES     If the software is available, it can be applied. It can be also applied to embedded software      
391 11   YES Size - - - - Number of Security Algorithms (NSA)   Number of security algorithms that are supported by the application - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied, but this metric can be used in finals stages of the development life-cycle      
393 11   YES Size - - - - Number of Security Requirements (NSR) *   Number of security requirements identified during the analysis phase of the application - SOFTWARE MANUAL STATIC*   ¿?     If the design is available, it can be applied      
394 11   YES Size - - - - Number of sub classes       SOFTWARE       YES     If the software is available, it can be applied. It can be also applied to embedded software      
395 11   YES Size - - - - NumFunctions       SOFTWARE       YES     If the software is available, it can be applied. It can be also applied to embedded software      
400 11   YES Size - - - - Response set for a Class (RFC)   Set of methods that can potentially be executed in response to a message received by an object of that class. RFC is simply the number of methods in the set, including inherited methods - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
402 11   YES Size - - - - Stall Ratio CODE Stall ratio is a measure of how much a program’s progress is impeded by frivolous activities. stall ratio = (lines of non-progressive statements in a loop) / (total lines in the loop) - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
409 11   YES Strength - - - - Comment ratio   Ratio of number of comment lines to number of code lines - SOFTWARE AUTOMATIC* STATIC*   YES     If the software is available, it can be applied. It can be also applied to embedded software      
410 11   YES Strength - - - - CommentDensity   The ratio of lines of comments to lines of code -                      
411 11   YES Strength - - - - Compartmentalization CODE Compartmentalization means that systems and their components run in different compartments, isolated from each other. Thus a compromise of any of them does not impact the others. This metric can be measured as the number of independent components that do not trust each other (performs authentication and authorization for requests/calls coming from other system components) that the system is based on to deliver its function. The higher the compartmentalization value, the more secure the system - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the software is available, it can be applied. It can be also applied to embedded software      
415 11   YES Strength - - - - Defense-In-Depth CODE This metric verifies that security controls are used at different points in the system chain including network security, host security, and application security. Components that have critical data should employ security controls in the network, host, and component layers. To assess this metric we need to capture system architecture and deployment models as well as the security architecture model. Then we can calculate the ratio of components with critical data that apply the layered security principle compared to number of critical components - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     I am not sure if this metric can be applied to embedded software, or at verification phases      
417 11   YES Strength - - - - Fail Securely CODE The system does not disclose any data that should not be disclosed ordinarily at system failure. This includes system data as well as data about the system in case of exceptions. This metric can be evaluated from the security control responses – i.e. how the control behaves in case it failed to operate. From the system architecture perspective, we can assess it as the number of critical attributes and methods that can be accessed in a given component. The smaller the metric value, the likely more secure the system in case of failure - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     This could be used in evaluation      
421 11   YES Strength - - - - Isolation (PI) CODE This assesses the level of security isolation between system components. This means getting privileges to a component does not imply accessibility of other co-located components. This metric can be assessed using system architecture and deployment models. Components marked as confidential should not be hosted with nonconfidential (public) components. Methods that are not marked as confidential should not have access to confidential attributes or methods - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     I am not sure if this metric can be applied to embedded software      
423 11   YES Strength - - - - Least Privilege CODE This metric states that each component and user should be granted the minimal privileges required to complete their tasks. This metric can be assessed from two perspectives: from the security controls perspective we can review users’ granted privileges. From the architectural analysis perspective this can be assessed as how the system is broken down to minimal possible actions i.e. the number of components that can access critical data. The smaller the value, the more secure the system - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the software is available, it can be applied. It can be also applied to embedded software      
431 11   YES Strength - - - - Trustworthiness   Trustworthiness of software means its worthy of being trusted to fulfill requirements which may be needed for a particular software component, application, system, or network. It involves attributes of stability, data security, quality, privacy, safety and so on. Software trustworthiness is interrelated with not only risk control in the software process, but also the quality management of the software development process. Furthermore, vision is needed to avoid excessive costs and schedule delays in development and risks management costs in operation; to improve development efforts; and above all - SOFTWARE - -   -     -      
433 11   YES Strength - - - - Variable Security Vulnerability CODE The security vulnerability of a variable v@l is determined by the combined security damage it might cause to the overall system security when v@l is attacked. The more security properties that can be left intact, the less vulnerable the variable is; on the other hand, the more security properties are violated, the more criticall the variable is. - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is only applicable if the source code is available      
449 11   YES Weakness - - - - Faults found during manual inspection       SOFTWARE       YES     It is related to software and it can be applied to embedded software      
458 11   YES Weakness - - - - Number of Design Flaws Related to Security (NSDF)   Security-related design flaws occur when software is planned and specified without proper consideration of security requirements and principles. For instance, clear-text passwords are considered as design flaws. Design flaws can be detected using design inspection techniques (e.g., design reviews). Identifying the number of design flaws related to security can help detect security issues earlier in the design process - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
459 11   YES Weakness - - - - Number of Exceptions That Have Been Implemented to Handle Execution Failures Related to Security (NEX)   Number of exceptions that have been included in the code to handle possible failures of the system due to an error in a code segment that has an impact on security - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
462 11   YES Weakness - - - - Number of Implementation Errors Found in the System (NERR)   Number of implementation errors of the system - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Related to the implementation phase      
463 11   YES Weakness - - - - Number of Implementation Errors Related to Security (NSERR)   Number of implementation errors of the system that have a direct impact on security. One of the most common security related implementation errors is the buffer overflow - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Related to the implementation phase      
464 11   YES Weakness - - - - Number of Omitted Exceptions for Handling Execution Failures Related to Security (NOEX)   Number of missing exceptions that have been omitted by software engineers when implementing the system. These exceptions can easily be determined through testing techniques. - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     Related to the implementation phase      
465 11   YES Weakness - - - - Number of Omitted Security Requirements (NOSR)   Number of requirements that should have been considered when building the application - SOFTWARE SEMI-AUTOMATIC* STATIC*   ¿?     If the design is available, it can be applied      
471 11   YES Weakness - - - - Number of violations of the LP principle   Number of violations of the Least Privilege principle. A component does not adhere to LP if it, based upon the permissions attributed as described before, is capable of executing tasks it is not responsible for - SOFTWARE AUTOCATIC* STATIC*   YES     This could be used in embedded systems      
473 11   YES Weakness - - - - Percentage Software Hazards (PSH)   Comparing the number of software hazards identified against historical data, it indicates the sufficiency of the software hazard identification based on the identified hazards. (# software hazards / # System hazards ) * 100 - SOFTWARE SEMI-AUTOMATIC* STATIC*   SÍ     Hazard is similar to risk.      
480 11   YES Weakness - - - - Static analysis alert count (number of)       SOFTWARE                    
488 11   YES Weakness - - - - Vulnerability Density CODE Number of vulnerabilities in the unit size of a code. VD = size of the software / # vulnerabilities in the system - SOFTWARE SEMI-AUTOMATIC* STATIC*   YES     It seems that it can be applied to embeded systems, but I am not sure if it is applicable in the evaluation phase      
494 11   YES Dependency* - - - - Security metrics of Arithmetic Expression   The security flaws of arithmetic expression include divide by zero, overflow of arithmetic operation, misused data type of arithmetic expression, and truncation error of arithmetic operation - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified. Part of a checklist      
495 11   YES Dependency* - - - - Security Metrics of Array Index   The security flaws of array index include index out of range, incorrect index variable and uncontrollable array index - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified. Part of a checklist      
496 11   YES Dependency* - - - - Security Metrics of Component Interfaces   The security flaws of component interface include inconsistent parameter numbers, inconsistent data types, and inconsistent size of data types - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified. Part of a checklist      
497 11   YES Dependency* - - - - Security Metrics of Control Operation   The security flaws of control operations include infinite loop, deadlock situations and boundary defects - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified. Part of a checklist      
498 11   YES Dependency* - - - - Security Metrics of I/O Management   File is an important media which can store critical information and record log data. However, file privilege definition, file access management, file contents, file organization and file size are major factors to affect the security software operation - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified. Part of a checklist      
499 11   YES Dependency* - - - - Security Metrics of Input Format   The security flaws of data format include mismatched data contents, mismatched data type, mismatch data volume - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified. Part of a checklist      
500 11   YES Dependency* - - - - Security Metrics of Kernel Operation   A released software system must be adapted to a suitable operating system and environment. The kernel of operating system and environment become a critical factor to affect the operating security of software system. Resource management, execution file protection, main memory control and process scheduling are major tasks of operating system. The security flaws, which embedded in the tasks of operating system, become high security risk for software system operation - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified. Checklist. Only when there is an OS      
501 11   YES Dependency* - - - - Security Metrics of Network Environment   Network environment is a critical tool in the e-commerce years. However, data transmission management, remote access control, and transmission contents always become the security holes of software system operation - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified      
502 11   YES Dependency* - - - - Security Metrics of Resources Allocation   The security flaws of resource allocation include exhausted memory, unreleased memory exhausted resources, and unreleased resources - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified      
503 11   YES Dependency* - - - - Security Metrics of User Authority   Many users may use the released system to do specific jobs. However, user privilege definition, user password management and user detailed information maintenance are important tasks to control and manage the user authority. Without user authority control and management, the operation environment of software system will be on high security risk - SOFTWARE AUTOMATIC* STATIC*   ¿?     This is not a metric, but a group of them. Individually, they could be used if they are specified      
526 11   YES Weakness - - - - Kolmogorov Complexity       SOFTWARE                    

Author: Angel Longueira

Created: 2020-04-28 Tue 17:13