- This line was added.
- This line was removed.
- Formatting was changed.
This page has been moved to Zendesk. Please, refer to this link for the latest version.
This article details the data model and how to manage risks, weaknesses and countermeasures, as well as how the risk rating is calculated.
The Threats Tab offers a complete view of the Threat Model for a specific product/application/solution. The view is provided by default using a tabular tree structure:
(\------- Use Case)
\------------ Threat 1
\------------ Weakness 1
\------------ Countermeasure 1
\------------ Countermeasure 2
\------------ Countermeasure n
\------------ Weakness 2
\------------ Weakness n
\------------ Threat 2
\------------ Threat n
This structure can be identified on the Threats window:
- Components contain Use Cases. Use cases are uniquely identified by their name.
- Use Cases contain Threats. Threats are uniquely identified by their "Reference" field. Two threats with the same "Reference" 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 "Reference" field. The parent of a Weakness is the Component. Two weaknesses with the same "Reference" 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 "Reference" field. The parent of a Control is the Component. In the same model as described above for Weakness, multiple Controls with the same Reference 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 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 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.
- 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.
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.
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
On this page: