The rules engine in IriusRisk is central in controlling:
- How threat models are generated, i.e. which threats and countermeasures are included in the model
- The initial state of Countermeasures in the model
- The value of custom fields set on the Product
- The workflow state transitions and corresponding actions
The underlying rules engine is JBoss Drools
The engine has a GUI that allows you to select Conditions and Actions to perform if the all of the conditions are met (Conditions have a logical AND applied). Behind the scenes, this rules generated by this GUI are converted into JBoss Drools syntax and can be viewed on the "Drools" tab, under the "user_defined" section.
Note that if you edit the generated Drool content then your changes will be overridden if the GUI rule is saved again. If you need to make persistent changes directly using Drools then use the Drools tab and the "New Rule" option to create a new .drl file that will persist and have no corresponding GUI rule.
Rules can be execute in 1 of 4 possible contexts:
- Component rules will execute whenever a new component is added to the diagram, or when an existing component's questionnaire is edited.
- Main rules will execute when a new Product is created, or it is saved and any Custom Fields have been modified.
- Data flow rules will execute if a new data flow is created or an existing one edited.
- Workflow rules execute when a workflow state change is triggered. Workflow rules are edited on the "Workflow Rules" tab.
Rules are executed in a "session", each rule is atomic and in general they aren't executed in any particular order. Rules' conditions depend on the state of objects, and the rule actions may insert other objects. The rules keep executing until there are no further changes in the state of the objects. In this article, and in Drools documentation phrases like "insert object into session" essentially means creating a data structure (object) with a set of values and inserting it into the rules session. Any rules that have conditions that depend on that data structure will automatically execute.
In many rule contexts you can both set and read "Conclusion" objects. You can think of these as variables that can be used to make your rules more maintainable, as well as to notify the user while they are editing a Component. For example, imagine the situation where you have 20 rules that must all execute if the following 3 conditions are met:
- The component is in the Internet TrustZone
- and the Data Asset in use is Credit Card Data
- and No authentication option has been selected for the component
Normally, you'd have to create 20 rules and repeat those conditions 20 times in each rule. Instead of doing that, you could create a single rule that includes those 3 conditions, and as the action uses "Insert Conclusion", with the type "Hidden" (this means it won't appear in the Analysis panel on the questionnaire), choose any ID and any name that describes this condition, e.g. "Internet facing with CC data and noauth". This single rule, will ensure that the Conclusion objected is created and inserted into the rules session. Then you would create the 20 additional rules that would all use the condition: "Conclusion exists", "Internet facing with CC data and noauth".
|Question is answered||True if the user has selected the question in one of the component questionnaires.|
|Component Definition||Allows you to select from a list of all possible Component Definitions and returns true if the component being evaluated has the definition selected.|
|Conclusion Exists||The selected Conclusion exists in the rules session. In other words, some other rule has inserted the given Conclusion into the session.|
|Conclusion Not exists||The stated Conclusion does not exist in the session.|