Business Unit: a group of users and Products within the system. With basic permissions, the users only have access to the Products that are in their Business Unit and limited to the role they have assigned within IriusRisk.
Compliance View: a filtered view on the Countermeasures tab that allows to see, based on a Standard, how many Countermeasures have been implemented, are in requires status, have failed tests or are non-compliant.
Component Definition: is a specification for a component within IriusRisk, they are available system wide and can be used as part of a product. New components can be defined by using the Component Definitions configuration option. They can have none or several associated Risk Patterns that would be included within the threat model.
Component Questionnaire: is the questionnaire related to a specific Component, it holds the questions that will be used within the rules to trigger actions (i.e. import Risk Patterns, create notifications, etc.). These questionnaires are customizable through Rules.
Countermeasure: a remediation action that should be performed to remove weaknesses and, hence, mitigate the risk of a threat being realised. They can be also referred as a Security Requirements.
Current Risk: is the calculation of the Inherent Risk minus the risk mitigatied through implemented Countermeasures.
Custom Field or UDT: a custom user input field that can be configured within the tool at a Product, Countermeasure, Test or Threat level. Product Custom Fields also allow rules to be written using them in the Condition and Actions.
Drools Rules: rules that are represented in the native Drools + Java format. IriusRisk allows to define rules in this format when the Rules Editor has some limitations.
Global Asset: a system wide defined asset based on a Security Classificaton the can be used within Product Components. These assets (when the are of type data) will be shown on each Component Questionnaire and iriusRisk will ask if they are stored, processed, sent or received by this specific Component.
Inherent Risk: a base risk value for a given threat or Product (as an average). This risk is calculated using the formula Risk = Impact x Likelihood. Using different parameters for each one of the product's parts.
Library: It is a collection of Risk Patterns that are logically grouped. The grouping can be done using different criteria (i.e. per standard or regulation represented). The Libraries are also used as a logical containers to group defined rules.
Main Questionnaire: it is the questionnaire related to a specific Product. This questionnaire is also managed by Rules and has specific actions to set Custom Fields, add Product Threats or import Templates based on several Conditions.
Product: the product is the unit of applications within IriusRisk, each one represents one project and it is composed by components and dataflows that are deployed into trustzones and manage assets respectively. You can find the listing of the products under the Products screen.
Product Threats: threats that are not linked to a Component but to the whole Product. They use to be thinks you need to do for all of the Components that are part of your Product.
Projected Risk: is the calculation of the Inherent Risk substracting the risk mitigation that would happen when all the Countermeasures in Required status were implemented.
Recommended Counteremeasure: a Countermeasure that is part of the model but not a strong security requirement, they will not be part of the Projected Risk Calculation and are meant to be optional for implementation.
Required Countermeasure: a strong security requirement within IriusRisk. They are meant to be implemented and will be part of the Projected Risk Calculation. They can also be uploaded to an Issue Tracker in batches.
Risk Pattern: It is a structure with Use Cases, Threats, Weaknesses and Countermeasures each one hanging from the other as an hierarchical structure. The Risk Pattern is an applicable set of threats that can be imported within a threat model due to the use of a component that has it assigned or due to a rule which action indicates it must be imported (i.e. a rule that has an associated answer as a condition and with an Import Risk Pattern condition).
Rule: a specification formed of one or several Conditions and one or several Actions within the system. The Rules Engine would evaluate each rule's condition and will trigger the action in case they are true.
Rules Editor: a graphical interface for Drools Rule generation and management.
Rules Engine: a JBoss Drools based rules engine that evaluates the rules within the system and perform the related actions.
Rules Module: the different action areas to which a rule can affect, currently we have three modules: Dataflows, Component and Main (for the Main Questionnaire).
Security Classification: a data classification based on the impacts on Confidentiality, Integrity and Availability that is used to define the Global System Assets.
Standard: a set of Countermeasures that belongs to the same source (i.e. a standard like ASVS or MASVS). Standards within IriusRisk are defined on the general configuration and added to each of the Countermeasures as if they were tags. This allows IriusRisk to provide the Compliance view or the Compliance Report as well as apply some Countermeasures that are part of the model by using the Standard as a reference.
Template: a Product that is intended to be used several times as part of other different Products. Templates allow to manage the templated Product on a central place and then cascade the changes to the Products that are using it.
Test: it is a verification action on a Countermeasure or Weakness that can be performed either manually or automatically using external tools (Cucumber, JUnit, Fortify, Checkmarx...).
Threat: it is a possible danger against your Product that can exploit a vulnerability and have unwanted consequences on it.
Use Case: it is a logical aggregation of threats that have something in common, it is used in the Libraries and the threat model representation for a Product.
Vulnerability: a weakness that have been proven it is present on the Product and therefore it is exploitable.
Weakness: a property of the software that could potentially be exploited by an attacked to materialize a threat.
Workflow Rules: a set of rules that can be defined over the Workflow States.
Workflow States: a system-wide set of logical states that applies to Products. The permissions that would be applicable by a user to a Product can be redefined on each Workflow State. The Reports that would be available can also be configured. The Products can be iterated through the Workflow States either manually or by using the Workflow Rules.