Security metrics feasibility analysis

# Security metrics feasibility analysis ## *Code Security Metrics* ### 1) Stall Ratio The number of non-progressing code statements present in a block of code (e.g., in a loop statement), divided by the whole number of lines of code in that block of code. Examples of non-progressing statements are neutral operations such as: - a=a+0, a=a, a=a*1, a=a/1 - empty loops - tautologies (a==a) - unused counters :x: `if (a==a) && (b==b) {}` -> in questo caso numerator = 1 `if (a==a) && (b==b) || (c==c) {}` => in questo caso numerator = 3 total line = ploc (no blank, no comments, figli commento da scartare Comment node, delle blank line non mi preoccupo) *SR = (Lines of non progressive statements in a loop) / (Total lines in the loop)* Any statement in a loop that does not help bring the program to the final state is considered a stall statement. One common method of attack involves saturating the target (victim) machine with external communication requests. In that situation, the victim cannot respond to legitimate traffic or it responds so slowly that can be rendered effectively unavailable. Similar attack can be attempted to exploit code sections with high stall ratio. ## How to start 1. Let's start with `for` loops 2. Search for inside `for` loops the conditions defined above 3. ***Problems:*** - Non-progressing operation are not clearly defined and some are very complex to detect. It would not be easy to detect things like a high production of logs or continuous requests to an external server. ***Sources:*** - Official paper: https://www.researchgate.net/publication/221554988_Security_metrics_for_source_code_structures ***Stall ratio is useless for security:*** - Blogpost: https://blogs.oracle.com/javamagazine/post/java-hotspot-hsdis-disassembler ### 2) Coupling Corruption Propagation Given a parameter s for a method f, the coupling corruption propagation is defined as the number of children methods of f based on the parameter s of the original invocation. ``` void f(int s){ int new_s = s + 1; g(new_s) } void g(int s){ h(s); } ``` Coupling corruption propagation is meant to measure the total number of methods that could be affected by erroneous originating method. With CCP, we can estimate the extent of the damage propagation when some data elements are compromised by a successful attack. ***Problems:*** - Difficult to integrate in RCA. For each method or function we must keep track of the parameters and how they are manipulated inside the function (they could change name). ***Sources:*** - Official paper: https://www.researchgate.net/publication/221554988_Security_metrics_for_source_code_structures ### 3) Critical Element Ratio It measures the number of critical elements that are present in a specific block of code. A critical element is defined as an element of a class that is not instantiated and is not used during the program execution, divided by the number of elements defined in a code block. CER = (Critical data elements in an object) / (Total number of elements in the object) A critical data element is the one that must eventually be used through the course of the program. An example of non critical data element is an integer variable used for logging. That integer could be compromized without any effective damage to the program. The critical element ratio metric measures the ratio of elements that can be possibly corrupted by malicious user inputs to the total elements in a class or method. Elements that have default values and are used to print messages or store error messages are considered as non critical. ***Problems:*** - Difficult to identify critical elements inside a class. The definition is too ambiguous and hard to detect. - Difficult to keep track of data usage: when we use a variable inside a method is that a local variable or an attribute? ***Sources:*** - Official paper: https://www.researchgate.net/publication/221554988_Security_metrics_for_source_code_structures --- ## *Object Oriented Specific Security Metrics* ### *Information Flow and Data Accessibility* #### Terminology - *Classified Attribute*: An attribute which is defined in UMLsec as secrecy. - *Instance Attribute*: An attribute whose value is stored by each instance of a class. - *Class Attribute*: An attribute whose value is shared by all instances of that class. - *Classified Methods*: A method which interacts with at least one classified attribute. - *Unclassified Method*: A method which doesn’t interact with any classified attributes. - *Mutator*: A method that can set the value of an attribute. - *Accessor*: A method that can return the value of an attribute. #### 4) Classified Instances Data Accessibility (CIDA) :x: It is calculated by dividing the number of public classified instance attributes in a class to its total number of classified attributes. #### 5) Classified Class Data Accessibility (CCDA) :heavy_check_mark: This metric is calculated by dividing the number of public classified class attributes of a given class by its total number of classified attributes. #### 6) Classified Operation Accessibility (COA) :heavy_check_mark: It is calculated by dividing the number of classified methods which are declared as public in a given class by its total number of classified methods. #### 7) Classified Mutator Attribute Interactions (CMAI) :x: To calculate this metric, it is at first needed to find out in how many places in the design/program classified attributes could be mutated. Then, this number is divided by the total number of possible ways of mutating these classified attributes. #### 8) Classified Accessor Attribute Interactions (CAAI) :x: This metric is calculated in a similar way to the CMAI metric by first finding out in how many parts of the design/program classified attributes could be accessed. Then, this number is divided by the total number of possible ways of accessing these classified attributes. #### 9) Classified Attributes Interaction Weight (CAIW) :x: This metric is calculated by finding the number of methods of a given class which may interact with classified attributes and dividing this number by the total number of potential interactions with all attributes in that class. #### 10) Classified Methods Weight (CMW) :x: We can calculate this metric by initially summing the number of methods which may interact in any form with classified attributes in a class. Then, this number is divided by the total number of methods in that class. ***Problems:*** - We don't have classified attributes nor classified methods. ***Sources:*** - Official paper: https://sci-hub.hkvisa.net/10.1109/QSIC.2009.11 ### *Unhandled exceptions* #### 11) Number of Catch Blocks per Class (NCBS) The ratio of catch blocks in a class to the total number of possible catch blocks in a class. This ratio measures thus the percentage of handled exception on the total number of possible exceptions for a catch block. ***Problems:*** - It is unknown how to identify how what are all the possible exceptions that can be thrown by a block of operations. #### 12) Exception Handling Factor (EHF) The ratio of number of exception classes to the total number of possible exception classes in software, where the number of exception classes is the count of exceptions covered in a system. The exception class is passed as an argument to the catch construct as type of argument arg. This type of argument specifies types of exception classes. ***Problems:*** - It is unknown how to identify how what are all the possible exceptions classes in a software. ***Sources:*** - Official paper: http://www.jot.fm/contents/issue_2007_01/article4.html (Section 4 introduces various complex techniques available to find number of possible exceptions.)