Introduction
In the following text we are going to explain how the Rules module works. This module has been designed in order to give the user the possibility to configure the tool to perform some tasks when some inputs are given.
To start working with rules, first we have to select the library where we are going to save our rules and then select New. To create a new rule, we have to give it a name, select one of the modules we have (in the following pages we are going to explain what kind of rules we can create on each of them with examples) and then select our conditions and actions.
A rule is basically an action (or actions) that will be done if the conditions given are fulfilled. We can select a group of actions or a group of conditions. Only if all conditions are met will the actions be executed.
The modules we have are:
Threat (Component conditions)
Threat (component conditions) rules apply to data flows, components, and assets.
On these rules it's possible to apply different actions:
| Action | Description |
| Insert conclusion | We can insert a conclusion, which is just a message under the component questionnaire. |
| Insert notification | We can insert a custom notification in the Notification tab to have feedback about any action. |
| Mark countermeasure as implemented | This option will mark a specific countermeasure as already implemented. It must be a countermeasure that our project contains. |
| Mark countermeasure as required | We can choose any countermeasure to be required in our project, so that its status will change from recommended to required. |
| Modify mitigation value | We can modify the mitigation value so we can decide the weight of every risk pattern on our project. |
The conditions we can use in the Threat (component conditions) module and some examples are listed below:
Answer is selected
This could be helpful for example if we have a sensitive custom asset. If the user selects that it is being stored or processed in the component questionnaire, we could insert additional threats or countermeasures in order to secure it or comply with a standard.
Answer not selected
It could be used for example to raise an alert or display a message if we want or need the user to give an answer to a specific question.
Applied countermeasure
It could be useful if a custom countermeasure has been defined and we want to notify when it is in use.
Component is
With this rule we will perform an action if the component is selected.
For example, it is possible to create a specific library for a component, so we could create a rule that imports this risk pattern if the component is chosen.
Component is in trust zone
We can carry out an action based on the trust zone the component is in.
With this condition we could manage the use of trust zones in our project. For example, we can avoid the use of certain trust zones by warning about their use or directly changing them for another more secure trust zone.
Component is not in trust zone
With this rule we can perform an action if the component has not been included in the chosen trust zone.
This could be useful for example to make sure that all components we want are inside a chosen trust zone. We could raise an alert if a component is not in the trust zone selected and in this case correct it.
Conclusion exists
With this rule we can perform an action if there is a specific conclusion in the component questionnaire. Remember that a conclusion is a message that we can include at the bottom of a questionnaire.
This condition could be used like a flag to perform other actions. For example we could add a conclusion if a component or a group of components are not in the right trust zone, so we could make a rule saying, if this conclusion exists, then perform additional actions to mitigate it.
Conclusion not exists
This condition can be used when we need to do something but there is something else that has not been done yet. For example, imagine we have a product in version 1 and version 2 is going to fix some risks. We could set a conclusion in v1, but when we start v2 this conclusion will not be there anymore. We could make a rule saying if this conclusion does not exist, then mark the countermeasures as implemented.
Countermeasure not applied
This rule can be used to perform an action if there is no countermeasure in the component.
Something that we can do with this condition is to give more importance to another countermeasure if this one is not applied. To do so, we would have to modify the mitigation value.
Custom Field
We can use a custom field as a condition, comparing it with a value we define.
There are custom fields of different types, like date, text, or user. We could use this condition for example to make an action if this custom field has been defined with a specific user.
Question exists
With this condition we can run an action if there is a specific question in the component questionnaire.
We can use this condition to build our questionnaire. We can set our question first and then, if this question exists, we can include the possible answers selecting the order and the tab we want it to be in.
Risk pattern exists
With this condition we can run an action if the chosen risk pattern exists in the component.
This condition could be used, for example, if we have already patched a vulnerability, marking a countermeasure as implemented if the risk pattern exists.
Threat (Dataflow conditions)
Threat (dataflow conditions) rules apply to data flows, component and assets.
On these rules, it's possible to apply different actions:
| Action | Description |
| Implement Countermeasure in Destination | Mark a countermeasure as implemented in the component receiving the data flow. |
| Implement Countermeasure in Origin | Mark a countermeasure as implemented in the component that is sending the data flow. |
| Insert Notification | Add a notification in the notification tab of a project. |
The conditions we can use in the Threat (dataflow conditions) module and some examples are listed below:
Dataflow contains tag
This rule is used to perform actions depending on the protocol (tag) used for data exchange.
We could use this condition, for example, if the modeler specifies a tag as HTTPS. Then we can mark the traffic encryption requirements as done.
Dataflow crosses Trust Boundary
This rule refers to data traffic crossing a trust boundary.
This case could be used, for example, if the traffic goes from a trusted zone to the Internet. In that case we could add new requirements or some notifications to alert the user.
Dataflow not contains tag
This rule is used to perform actions if a tag is not used for data exchange.
Imagine that we have a set of predefined tags. It is possible to specify some action if a tag is not present in the data flow. For example, we have defined http, https, ssh and telnet. It could be useful to notify and add new requirements if it is using an insecure protocol.
Destination Trust Zone
This rule is useful to apply actions if a destination component is within a specific trust zone.
For example, if the server is sending sensitive information (credit card, personal data, ...) to a component within the Internet zone, it is possible to insert a notification to the user.
Destination Trust Zone is not
This rule is useful to apply actions if a destination component is not within a specific trust zone.
For example, if a certain component is not within a specific trust zone, then implement a risk pattern and/or add a conclusion.
Origin Trust Zone
This rule is useful to apply actions if an origin component is within a specific trust zone.
For example, if a client device is sending information from the Internet to a server, it is possible to add a new risk pattern to the server or trigger a notification.
Origin Trust Zone is not
This rule is useful to apply actions if an origin component is not within a specific trust zone.
For example, if a certain component is not within a specific trust zone, then implement a risk pattern and/or add a conclusion or any other action.
Risk pattern imported in destination
This rule is useful to apply actions if a risk pattern has been imported in some destination component.
For example, it is possible to create a notification to warn of the import of a certain risk pattern in destination, or to simply add a conclusion in the destination component.
Risk pattern imported in origin
This rule is useful to apply actions if a risk pattern has been imported in some origin component.
For example, it is possible to create a notification to warn of the import of a certain risk pattern in origin, or to simply add a conclusion in the origin component.
Security classification of any of the involved assets
This rule is useful to apply actions if a dataflow contains any data protected by security regulations (credit card, personal information, ...).
For example, if a dataflow contains credit card data, then import the PCI regulation.
Component
These rules apply to the component. Imported risk patterns or conclusions are applied directly to the component:
In component rules it is possible to apply different actions:
| Action | Description |
| Answer Question | We can respond to a question from a specific component questionnaire. |
| Answer Question From Main Questionnaire | We can also respond to a question from the main questionnaire. |
| Apply security standard | We can choose to apply a security standard in our project, like CIS, FedRAMP, GDPR, etc. |
| Import Risk Pattern | We can add threats and countermeasures to our project from any library. |
| Import Specific Risk | We can import a specific risk from any library. |
| Import Specific Use Case | We can import an existing use case. |
| Insert Answer | We can insert a custom answer in the component questionnaire for the question we want. |
| Insert Conclusion | We can insert a conclusion, that is just a message under the component questionnaire. |
| Insert Notification | We can insert a custom notification in the Notification tab to have feedback about any action. |
| Insert Question | We can insert a question in a specific component questionnaire so that, along with the answers, we can compose our customized questionnaire. |
| Mark Countermeasure as Implemented | This option will mark a specific countermeasure as already implemented. It must be a countermeasure that our project contains. |
| Mark Countermeasure as Required | We can choose any countermeasure to be required in our project, so that its status will change from recommended to required. |
| Modify Mitigation Value | We can modify the mitigation value so we can decide the weight of every risk pattern on our project. |
| Move to trust zone | We can change the trust zone our component is in (this action is deprecated and it will be removed in the next major release). |
| Set Custom Field Value | We can modify the value of a specific custom field already defined. |
The following actions can’t be used with all conditions.
-
Insert Answer:
-
Set Custom Field Value:
The conditions with some examples are listed below:
Answer is selected
This rule is used to perform an action if an answer of the component questionnaire has been selected.
This could be helpful for example if we have a sensitive custom asset. If the user selects that it is being stored or processed in the component questionnaire, we could insert additional threats or countermeasures in order to secure it or comply with any standard.
Answer not selected
This rule is used to perform an action if there is no answer for a specific question.
It could be used for example to raise an alert or display a message if we want or need the user to give an answer to a specific question.
Any parent component is a
A parent component is a component that has been embedded with another one. To parent two components we just have to drop a component on another one. The parent will be the first component we add, so it is in this one where the condition has to be met.
This rule is used to perform an action if one of the parent components is the selected component.
It could be helpful when, for example, you want to add some components that belong to the same type. Imagine you have 3 clients (web, Android and iOS). Then you can add a generic client device as the parent of the others and create a rule to carry out actions involving all devices inside the parent component.
Any parent component selects answer
This rule will perform an action if a specific answer has been selected in the parent component questionnaire (remember, the first component is added to the group, so the underneath component).
It could be helpful if you want some components, related ones or the same generic type, to behave the same way. Imagine you have 3 clients (web, Android and iOS). You could add a generic client as the parent of the other components and the actions defined will involve all the devices inside the parent component to, for example, import risk patterns or trigger notifications.
Component category is
With this rule we can carry out an action if the category (AWS, Automotive, Docker, Functional, etc.) of the component is the one selected.
Something we could do with this condition is to import threats applied to a specific component category, for example data store. Regardless of whether it is MySQL, PostgreSQL, or MongoDB, we could import the threats if any of them are in use.
Component is
With this rule we will perform an action if the component is the one selected.
For example, it is possible to create a specific library for a component, so we could create a rule that imports this risk pattern if the component is the chosen one.
Component is in trust zone
We can carry out an action based on the trust zone the component is in.
With this condition we could manage the use of trust zones in our project. For example we can avoid the use of certain trust zones by warning of their use or directly changing them for another more secure trust zone.
Component is not in trust zone
With this rule we can perform an action if the component has not been included in the chosen trust zone.
This could be useful for example to make sure that all the components we want are inside a chosen trust zone. We could raise an alert if a component is not in the trust zone selected and in this case correct it.
Conclusion exists
With this rule we can perform an action if there is a specific conclusion in the component questionnaire. Remember that a conclusion is a message that we can include at the bottom of a questionnaire.
This condition could be used like a flag to perform other actions. For example we could add a conclusion if a component or a group of components are not in a correct trust zone, so we could make a rule saying, if this conclusion exists, then perform additional actions to mitigate it.
Conclusion not exists
With this rule we will carry out an action if there is no specific conclusion in the component questionnaire.
This condition can be used when we need to do something but there is something else that has not been done yet. For example, imagine we have a product in version 1 and version 2 is going to fix some risks. We could set a conclusion in v1, but when we start v2 this conclusion will not be there anymore. We could make a rule saying if this conclusion does not exist, then mark the countermeasures as implemented.
Custom Field
We can use as a condition a custom field comparing it with a value we define.
There are custom fields of different types, like date, text, or user. We could use this condition for example to make an action if this custom field has been defined with a specific user.
Question exists
With this condition we can run an action if there is a specific question in the component questionnaire.
We can use this condition to build our questionnaire. We can set our question first and then, if this question exists, we can include the possible answers selecting the order and the tab we want it to be in.
Question from main questionnaire is answered
With this condition we can perform an action if a specific question from the main questionnaire has been answered.
Imagine we have set a question in the main questionnaire about the data store component we are going to use in our application. We could set a rule to add the chosen component to our project.
Question from main questionnaire is not answered
With this condition we can perform an action if a specific question from the main questionnaire has not been answered.
Imagine we have a group of templates and we only want projects based on those templates to build a new one. We have the option to raise an alert if any of the templates have not been used.
Risk pattern exists
With this condition we can run an action if the chosen risk pattern exists in the component.
This condition could be used for example, if we already have patched a vulnerability, to mark a countermeasure as implemented if the risk pattern exists.
Main
The rules we can create in the Main module are going to be applied to the entire diagram. We have to know that there are two different questionnaires, the Main or architecture questionnaire (found in the Diagram, IriusRisk, Architecture Questionnaire) and the Component questionnaire (explained in the Component module).
Imported risk patterns or conclusions will apply to the entire architecture rather than to a component or data flow.
In the main rules it's possible to apply different actions:
| Action | Description |
| Answer Question | We can respond to a question from the architecture questionnaire. |
| Assign project to BU | We can assign a project to a specific Business Unit. If we select a project we can check which BU it belongs to in the Ownership tab. |
| Assign project to user | We can assign a project to a specific user. We can see if there is any user assigned to the project in the Ownership tab. |
| Create component | We can create a new component. We will have to select the trust zone that we want it to be included in. |
| Generate report | If we select any project we can see the Reports tab. With this action we can create a report here. We can choose between several predefined reports and the format we want. |
| Import project threat | We can import any threat from any library available to our project. |
| Import Template | We can import an existing template. |
| Insert Answer | We can insert an answer in the architecture questionnaire but only if a question has been selected as a condition. |
| Insert Conclusion | A conclusion is a message that will appear under the main questionnaire. |
| Insert Notification | We can insert a notification. It is just a selected message that will appear in the notification tab inside a project. |
| Insert Question | We can define a new question that will appear in the main questionnaire. We can select the tab and the order we want. |
| Mark Countermeasure as Implemented | This option will mark a specific countermeasure as implemented. It must be a countermeasure that our project contains. |
| Mark Countermeasure as Required | We can choose any countermeasure to be required, so it will change the status from recommended to required. |
| Set Custom Field Value | With this action we can change the value of a specific Custom Field in our project. To do so, we need to have previously created a custom field. |
The following actions cannot be used with all conditions.
-
Insert Answer:
-
Set Custom Field Value:
The conditions we can choose in these rules and some examples are listed below:
Answer is selected
This rule is used to perform an action if in the main questionnaire an answer has been selected.
With this feature we could match answers of custom questions with certain actions, for example we could ask the user to select if they want to use any security standard. In that case we could perform the action of creating the component of the standard chosen.
Answer not selected
This rule is used to perform an action if there is no answer for a specific question.
It could be used for example to raise an alert or message if we want or we need it to be answered.
Conclusion exists
With this rule we can perform an action if a conclusion has been included in the questionnaire. A conclusion is a message that we can include at the bottom of a questionnaire.
This could be useful mixed with another rule, using it like a flag. Imagine we have 2 users, a and b. If we want user b to add his content to the project once user a has finished, we could set a conclusion when the project has been assigned to user b. Once we have the flag, user b could make a rule to add his part of the project so they can work in parallel.
Conclusion not exists
This condition is used to perform an action in case a specific conclusion in the main questionnaire does not exist.
Following the previous case, we could set the conclusion until the user b has been assigned. Then the conclusion will no longer exist so user b can run the rule to add his content.
Custom Field
We can use as a condition a custom field compared with a value.
Custom fields can be of different types, like date or text. We could use this condition to make an action on a specific date. For example we could assign the project to a user on that date.
Is project creation
With this condition we can perform an action when a new project is created.
This is useful if we want something to be done everytime we create a new project. For example we could create a generic questionnaire and run it every time so the user could make the threat model just using the questionnaire.
Question exists
With this condition we can run an action in case a specific question exists.
The most useful case is when we want to build a questionnaire. We will use this condition to include some possible answers.
Data Flow
Data Flow rules apply to data flows and everything surrounding them, such as the tags or components involved.
On these rules it's possible to apply different actions:
| Action | Description |
| Implement Countermeasure in Destination | Mark a countermeasure as done on the component receiving the data flow |
| Implement Countermeasure in Origin | Mark a countermeasure as done on the component, that is sending the data flow |
| Import Risk Pattern in Destination | Add threats and countermeasures on the component receiving the data flow |
| Import Risk Pattern in Origin | Add threats and countermeasures on the component sending the data flow |
| Insert Conclusion in Destination | Add an advice or message on the component receiving the data flow |
| Insert Conclusion in Origin | Add an advice or message on the component sending the data flow |
| Insert Notification | Add a notification in the notification tab of the project |
The conditions we can use in the Data Flow module and some examples are listed below:
Dataflow contains tag
This rule is used to perform actions depending on the protocol (tag) used for data exchange.
For example, if the modeler specifies a tag as HTTPS then we can mark the traffic encryption requirements as done.
Dataflow crosses Trust Boundary
This rule refers to data traffic crossing a trust boundary.
For example, if the traffic goes from a trusted zone to the Internet, it is possible to add new requirements or some notifications.
Dataflow not contains tag
This rule is used to perform actions if a tag is not used for data exchange.
Imagine that we have a set of predefined tags. It is possible to specify some action if a tag is not present in the data flow. For example, we have defined http, https, ssh and telnet. In this case we could notify and add new requirements if it is using an insecure protocol.
Destination Component is
This rule is useful to apply actions depending on the component receiving the data flow.
It is possible to mix several conditions and specify for example, if personal data is sent to an Android device, then import a new risk pattern.
Destination Trust Zone
This rule is useful to apply actions if a destination component is within a specific trust zone.
For example, if the server is sending sensitive information (credit card, personal data, ...) to a component within the Internet zone, it is possible to insert a notification to the user.
Destination Trust Zone is not
This rule is useful to apply actions if a destination component is not within a specific trust zone.
For example, if a certain component is not within a specific trust zone, then implement a risk pattern and/or add a conclusion.
Origin Component is
This rule is useful to apply actions depending on the component sending the data flow.
For example, it is possible to mix conditions and specify if personal data is sent by an Android device, then import a new risk pattern.
Origin Trust Zone
This rule is useful to apply actions if an origin component is within a specific trust zone.
For example, if a client device is sending information from the Internet to a server it is possible to add a new risk pattern to the server or trigger a notification.
Origin Trust Zone is not
This rule is useful to apply actions if an origin component is not within a specific trust zone.
For example, if a certain component is not within a specific trust zone, then implement a risk pattern and/or add a conclusion or any other action.
Risk pattern imported in destination
This rule is useful to apply actions if a risk pattern has been imported in some destination component.
For example, it is possible to create a notification to warn of the import of a certain risk pattern in destination, or simply add a conclusion in the destiny component.
Risk pattern imported in origin
This rule is useful to apply actions if a risk pattern has been imported in some origin component.
For example, it is possible to create a notification to warn of the import of a certain risk pattern in origin, or simply add a conclusion in the origin component.
Security classification of any of the involved assets
This rule is useful to apply actions if a dataflow contains some data protected with security regulations (credit card, personal information, ...).
For example, if a dataflow contains credit card data then import PCI regulation.
Comments
0 comments
Please sign in to leave a comment.