The Data and Risk Model

Component 1

        (\------- Use Case)

               \------------ Threat 1

                          \------------ Weakness 1

                                       \------------ Countermeasure 1

                                       \------------ Countermeasure 2

                                       \------------ Countermeasure n

                           \------------ Weakness 2

                           \------------ Weakness n

               \------------ Threat 2

               \------------ Threat n

Component n

This structure can be identified on the Threats window: 

Data Structure

• Components contain Use Cases.  Use cases are uniquely identified by their name.
• Use Cases contain Threats.  Threats are uniquely identified by their "Unique ID" field.  Two threats with the same "Unique ID" value can belong to two different Use Cases and will be treated as independent Threats.
• Threats can reference Weaknesses.  Weaknesses are uniquely identified by their "Unique ID" field.  The parent of a Weakness is the Component.  Two weaknesses with the same "Unique ID" that are attached to two different threats in the same Component are regarded as the same Weakness.  E.g.:  If there are two weaknesses called: "Inadequate data validation" with the reference "BAD-DATA-VAL" and one is attached to Threat1 and another to Threat2, and both Threat1 and Threat2 belong to the same Component - then they are treated as the same weakness.                 
• Threats can reference Controls.  Controls are uniquely identified by their "Unique ID" field.  The parent of a Control is the Component.  In the same model as described above for Weakness, multiple Controls with the same Unique ID value are regarded as the same Control if they belong to the same Component.
• Controls can reference Weaknesses.  Controls can be associated with Weaknesses, but this relationship is optional.

Assets

Assets are the entities that have value and should be protected.  They are typically defined as types of data or services.  Assets can be configured on the Configuration → Global Asset Definitions section or on a per-product basis on the Product→ Architecture Tab.

The value of an Asset is defined by its Security Classification in terms of a Critical, High, Medium, Low scale for each of Confidentiality, Integrity and Availability.  The Security Classification can be configured on the Configuration → Security Classification section. 

Trust Zones

Trust Zones are areas of trust separated by Trust Boundaries.  Each Trust Zone is associated with a numeric trust rating where 1 is untrusted and 100 is very trusted.  This rating is used as a variable when calculating the Likelihood component of the risk rating calculation.

Risk Types

• Inherent Risk: The risk rating that a Threat poses to a Component based on the following attributes:
  • The security classification of the Assets associated with it
  • The trust rating of the Trust Zone where the Component is located
  • The impact rating of the threat
  • The impact rating of the Weaknesses
  • The Ease of Exploitation rating of the threat 
• Current Risk: This rating is based on the Inherent Risk and then adjusted based on the countermeasures that are implemented and the test results.  Implemented countermeasures will reduce this rating, based on their mitigation percentage, as will tests that have passed.  Failing tests will negate any reduction in the risk rating, for example, if the rating had been reduced from a High to a Medium because a countermeasure was implemented - but the test for that countermeasures fails, then the risk rating would change back to its original High value. 
• Projected Risk: The future risk rating we would achieve if all the planned countermeasures were successfully implemented. 

Risk Calculation 

The risk rating is calculated according to the broad formula: 

              Risk = Impact x Likelihood

Those variables are further broken down into:

• Impact = Greatest impact of: (Technical impact of the threat * Impact Weighting  +  value of the Asset * asset Value Weighting)
• Likelihood = (Exposure rating * Exposure Weighting) + (Ease of Exploitation rating * Ease of Exploitation weighting)

The Risk Calculation formulate can be modified using several parameters in the Configuration section:

• Asset Value Weighting: Apply a weighting to the asset value variable 
• Mitigation Factor if Control Implemented: Countermeasures already have a mitigation percentage assigned individually.  This setting can be used to adjust the these mitigation percentages globally.  For example, if a countermeasure has a mitigation value of 100%, and this configuration value is set to 0.2, then the mitigation value applied would be 80%. 
  
• Ease Of Exploitation Weighting: Apply a weighting to the Ease Of Exploitation variable in Impact formula
• Exposure Weighting: Apply a weighting to the Trust Zone trust rating which is used to calculate the Exposure rating and hence the likelihood
• Business Impact Weighting: Apply a weighting to the Technical Impact factor
• Mitigation Factor if Control Test Passed: When a Countermeasure Test is passed, how much of the Threat should be  considered mitigated?  A value of 1 indicates 100%
  
• Mitigation Factor if Control Test not Passed: Current this setting is unused
  
• Vulnerability Found Factor: When a Vulnerability is found (i.e. the Test for a Weakness is marked as Failed) then how much should the risk be increased above the Inherent risk value.  If this value is 0.1 and the Inherent risk is rated as 100, and a Weakness Test fails, then the calculated risk would be 110.
  

Product Risks Ratings

The Product Risk ratings are calculated as an average of all the Threat risk ratings in the product. The Product Risk Summary is presented on the Products tab.

Tests

IriusRisk implement two different types of tests, tests of the Weaknesses and tests of the Countermeasures. Weakness tests are examples of negative tests, for example, a Pen Testing team performing a vulnerability analysis or pentest of the system, checking for Weaknesses and validating or verifying that they're present. Countermeasure Tests are those that a developer, tester or auditor would more typically perform in order to prove the presence of an implemented Countermeasure.  

The possible states for the tests are: 

• Not Tested:  The weakness or countermeasure has not been tested. 
• Error: When tested, there was an error and it could not be tested. 
• Failed: The test failed, that means for a Weakness, that it is a real vulnerability and for a Countermeasure that it is not properly implemented (non-effective).
• Passed: The test passed successful, hence, there is no Vulnerability (for the Weakness case) or the Countermeasure is implemented and effective. 

A global setting can be enabled which will equate Passing Countermeasure Tests with the Countermeasures being implemented.  The setting can be be configured in Global Default Settings → Features → Countermeasure test passed means implemented