What has changed in the rules engine in version 4 - Migration guide.

The rules engine is at the core of the automation features in IriusRisk.  We use the JBoss (Redhat) Drools engine with a customized rule editor front-end to make creating rules easier than learning a new syntax.  In IriusRisk v4 we have made significant changes to how we use the engine under the covers to bring more flexibility to creating architectural rules that involve multiple dataflows and components.

Background

Drools is a forwards and backwards chaining inference based rules engine, where the reasoning capabilities exist within the concept of a “Session”.  In IriusRisk we use the session to inject “facts” about the threat model and then take actions based on the final state of the session.  From IriusRisk v1 to v3 we have used the following independent sessions executed in the order below:

This meant that IriusRisk would execute the Main session, Drools would reason over the Product facts, and take actions necessary.  Then it would start up the Component session, reason over each Component facts it, and take actions and so on.

The limitation with this approach is that facts inserted in one session are not available to the next session except through the shared state of custom fields.  For some use cases, this was good enough, for example the Main session could reason over some facts representing meta-data of the product, and take the action of marking a “Business criticality” custom field to “High” for example.  Then the Component or Dataflow sessions could have rules that referred back to the Business Criticality value, because it was stored in the shared state of a custom field.  But using this approach we lose the full power of a backwards chaining rules engine, where conflicts between facts can automatically be resolved – as long as they are in the same session. 

What’s changed in v4

Our customers are increasingly creating rules that apply to the entire architecture of the system: Product, Components and Dataflow; and they need to change the state of countermeasures based on a combination of the architectural attributes.  To solve this challenge we have changed the rules engine sessions in v4 as follows:

The following diagram explains how the rule sessions are executed in order: 

The key changes are that we have separated the creation of the threat model and the setting of the status of the countermeasures into two distinct sessions.  At the same time we have merged the previous Component and Dataflow sessions into a single “Threat Model” session.  This means that your dataflow rules can now interact with your component rules within the same Drools session.

With this change, we are setting the foundations to add more complex architectural conditions and actions in the Rules Editor. Also, it is now possible to create more sophisticated architectural rules, for example, we can now relate the presence of a given component type to some actions in other components. Let’s say, for example, that you want to import risk patterns into an Oracle Database component if and only if there is a WAF in your diagram (WAF) and there is a dataflow between the WAF and the database.  This is now possible within a single rule. 

package com.iriusrisk.drools;

rule "import risk pattern if WAF exists"

no-loop

when

    $project : ProjectFact()

    $component : ComponentFact()

    ComponentDefinitionFact(uniqueId == "waf-component");

    ComponentDefinitionFact(uniqueId == "oracle-db", componentReferenceId==$component.componentReferenceId);

then

    insertLogical(ImportRiskPatternFactory.importRiskPattern($component.getComponentReferenceId(), "lib1", "riskpattern1", 50));

end

Are my v3 rules compatible with v4?

The following actions or conditions are no longer supported in v4: 

These actions and conditions should be removed or replaced before upgrading to version4.

How can I check rule compatibility with v4?

We have developed a utility you can use to verify that rules would be compatible with v4 before starting your migration process. You can download it from [here]. (sha256: 78677011fd674907c99a8009e30ff741e864eca56ab4a33e3a7c95b20034cdfa)

You can execute:

java -jar rulesvalidator-4.jar --connectionString=[jdbc connection string]  --dbUser=[database user] --dbPassword=[database password]

Use this command to display the help:

java -jar rulesvalidator-4.jar help

The results are printed in the output. Each line of error describes either a condition or an action or a custom rule that is not supported in version 4.  If there are non-trivial to remove rules, please contact your customer success manager to resolve them.

What if I have custom .drl rules?

The custom rules should be adapted to use the new version facts that supersede those of the previous versions. The migration tool will detect the outdated ones and it will display the content of the rule.

If you have generated the custom rules by creating a rule in the editor and then inspecting the code created in the Drools editor, you can follow the same process to identify the changes. They are mainly in the objects used that have now been renamed to represent the “Facts” objects.  

If you have more complex custom rules, It is recommended to contact your customer success manager to obtain an adaptation of the custom rule with greater guarantees.