Context Engine and Exception Engine

This section will guide you through the process off creating automations, including the context engine and the Exception engine.

Context Engine

The context engine allows users to determine the locality of assets, including the option to change the locality based on rules which can manually be set. The locality will determine the exploitability factor which contributes to the risk level.

There are 3 different asset categories for which rules can be defined which should be selected by clicking on the category underneath the Context engine title.

Follow these steps to set up automations:

1. Select the default locality new assets are to be set to.
2. Set the precedence locality for assets which match multiple rules of different locality filters. Since the same asset can match multiple rules, you need to decide which locality takes precedence in that case.
3. To create a rule follow these steps:
   • Select the asset category
   • Select the asset value
   • Click on the blue box to add an exclusion
   • Select the locality you wish to change the asset to based on the rules at the bottom of the rule tab
4. Press save once a new rule has been set at the bottom of the page.

There are two sections for defining rules, one to be used to define rules for setting assets as internal and the other to be used to define rules for setting assets as DMZ, these can both interchangeably be

Exception Engine

The Exception engine is used to define rules for setting assets as false positives or as risk mitigation. They can be scheduled to be set as false positive/risk mitigation and to also have an expiry date allowing for automated processing of Vulnerabilities and prioritising of Vulnerabilities that matter.

Navigation

Follow these steps to add an exception rule:

1. Click on the blue box, “Add New Exception Rule”.

Step 1

2. Enter the rule name which will be displayed on the Exception Engine rule table.
3. Select if it is to be scheduled or manually triggered using the enabled field in the Exception engine rule table. Then select how often the exception is to be renewed which will send a notification of the new status being a risk exception or false positive.
4. Enter the description of the rule, outlining the reason for the exception proposal and an other important details.

Step 2

5. To set an if condition start by selecting the category of the rule definition (e.g Asset locality) and the corresponding value (e.g Internal).
6. To add a BUT NOT condition press the blue button in the bottom right corner of the rule and it will give you the same options to add another rule.

7. To add an AND condition press the plus button next to the value column.

Step 3

8. Select the exception type

Risk Mitigation

Risk mitigation is to be set for vulnerabilities/assets which aren’t as severe as they are made out to be. Risk mitigation can also be set for vulnerabilities/assets which are about to be changed, due to an update for example, and an expiry date can be set for when risk mitigation ends/the update is implemented. This will ensure that the asset/vulnerability won’t exist as a focal point for the given time frame allowing prioritisation of more important vulnerabilities.

1. Enter the name for the new risk mitigation.
2. Assign the risk mitigation to a responsible user.
3. Select a expiry date for when the asset is no longer flagged as risk mitigation or select no expiry date by ticking the box next to this.
4. The risk mitigation percentage can be set as Low, medium, high or custom and reduces the risk score for that asset/vulnerability as a percentage e.g setting it as high will reduce the risk score by 100% to 0. While setting the risk mitigation percentage as low will reduce the risk score by 30%. This enables vulnerabilities known not to be as severe as made out to be deprioritized enabling engineering teams to focus on what matters most.

5. Select an option once all required fields have been filled in:
   • Test rule – this will test run the rule and tell you how many findings it will affect, without leaving the page. This is to be used to ensure no mistakes have been made in defining the rule.
   • Save rule – this will save the rule and it will be visible on the exception engine rule table but will need to be enabled.
   • Save rule and enable – this will save the rule and it will now be enabled requiring no further action.

Test run of rule

False Positive

Setting an asset/vulnerability/finding as a false positive will mark it as no longer a threat and will mean it no longer contributes to the global risk score/risk score of the application/environment it is within. False positives can be viewed from the risk exceptions page within security and be reviewed by security users. Risk Exception article. It is advised to test this rule as you don’t want to accidentally set a large number of findings as false positives as this could accidentally hide a lot of exploitable Vulnerabilities.