Customizing the Questionnaires

Types of Questionnaires

The questionnaires provided within IriusRisk are divided into two types: 

• The Main Questionnaire: We leverage this questionnaire for selecting the components comprising the architecture. This questionnaire is disabled by default. To enable it, we shall go to the "settings" section and in the "General" tab, go to the "User Interface" section and enable the option "Show main questionnaire". We can use the main questionnaire in the following ways:
  • To create questions and associated rules to propagate the answers to other components.
  • To create questions and associated rules to import templates into the product when specific questions are answered.
  • To import a template by selecting it from the template list.

• The Component Questionnaire: Poses questions about a specific Component within the Architecture. These Questionnaires are tailored to each type of component and contain questions relevant to that component only.
  
  

The main questionnaire is triggered when a new Product is created or by clicking on the "Product Architecture Questionnaire" option in the Architecture tab.

Both types of questionnaires are dynamic and fully customizable through the IriusRisk Rules Engine which is explained below.

Terminology used in the Questionnaires

Sections 

The terms used for elements of the questionnaires are highlighted below:

These are: 

• Question Categories: The different tabs that are part of the questionnaire, each tab groups a specific set of Question Groups. A group of Question Groups is called a Category.

• Question Group: It is a group of selectable Questions used to provide a multiple choice selection option, e.g. pose the question in the Question Group and then use a list of Questions to present the possible answers. 

• Questions: The individual options for a question group, they act as the answers to the specific question formulated in the Question Group.  Questions must belong to a question group.

• Control Buttons: Control the flow during the process of filling out the questionnaire.  

• Debug panel enable checkbox: Shows an extra panel with dynamic information on what actions are performed based on the progress of the questionnaire. This option is only available to users with the EDIT_RULES permission.

• Analysis and debug information area: Shows hints and alerts during the process of answering the questionnaire.   

   

  

Question Types

The only question type allowed within the questionnaires is the checkbox question type so any question that is not in that format should be rephrased to use only checkboxes, for example, if you'd like to ask for the type of Java Web Container used on the Server Side you cannot use a free text field, instead create a list with all the possible options e.g.: (Tomcat, JBoss, WebSphere, Other).

Additional fields such as text, date and user selectors are supported through the User Defined Types (UDT) functionality.  And these can, in turn, be used to create questionnaires associated with the product itself.  To learn more about them, please refer to →  User Defined Types (UDT)

Ordering

The order of the Question Categories and Question Groups is controlled by the priority attribute.  Question Groups are ordered left to right from lowest to highest priority.  The position of the category is determined by the highest priority question group in that category.  Within the same category, question groups are ordered from top to bottom - lowest to highest priority.

These priorities can be chosen when creating the rules. 

The priorities of the current questionnaire tabs are as follows:

• Trust Zones: 1900 - 1999
• Assets: 2000 - 2100
• Authentication: 6200 - 6220
• Data Transport: 6631 - 6650
• Deployment: 6500 - 6510
• Features: 6701 - 6811
• Languages/Frameworks: 6801 - 6816
• Mobile OS: 6051 - 6060
• Server: 6101 - 6105
• Session Management: 6601 - 6611
• User registration: 7000 - 7001

Rules Editor

The rules engine can be customized with the graphical Risk Rules Editor:

We can see several options on the screen above:

• Library: Rules are associated with Libraries so that when we create a set of rules, they will be related to that Library and exported when the Library is exported.
• Rule Name: The name to identify the specific rule, this must be a unique name throughout the system.
• Module: This section refers to which Questionnaire the rule will be related to, options are Main or Component.  Rules in the Main Module are only executed when the Main Architecture Questionnaire is run, and when the product is saved.
• Conditions: The conditions which must be satisfied to trigger the actions. If we put more than one condition, an AND operation is performed by default.
• Actions: The actions that will be performed if the Conditions are fulfilled. 

Each of the Modules has different Conditions and Actions, they are described as follows: 

Main Module: 

Conditions:

• Conclusion exists: A conclusion is like a global variable that some rule has decided to set (because of the logic) and it is available to all the other rule executions. Some types of Conclusions are shown on the Analysis section of the Questionnaires. This condition allows checking whether a given conclusion has been set by some other rule. 
• Conclusion not exists: Same as above but checks that the specific conclusion does not exist.
• Question group exists:  Check for the existence of a specific Question Group in the Main Questionnaire.
• Question is answered: Check if a specific question is answered in the Main Questionnaire.
• Question is not answered: Check if a specific question is not answered in the Main Questionnaire. 
• Is product creation: Check if the product has been created, this condition only occurs one time, when the product creation is finished.
• User defined field: Check if there is User Defined Field with a specific value. This is a composed condition which has:  
  • Data Type: The source of the User Defined Field, currently it can be a UDF set up on a Product, Countermeasure or a Test.
  • Name: The name of the UDF.
  • Comparator: The logical comparator we want to use for its value (Equals, Not equals, Greater than or equals, Less than and Less than or equals). 
  • Value: The value we want to compare against.

Actions:

• Answer Question From Main Questionnaire: Automatically answer a question from the Main Questionnaire (with all the implications that will have).
• Answer Question: Automatically answer a question from the Main Questionnaire (with all the implications that will have).
• Assign Product to BU: Add the current Product to a specific Business Unit.
• Assign Product to User: Change the ownership of the Product to a specific User.
• Generate report: Generate a new report of the product with a determinate format, when the conditions have complied.
• Import Template: Import a template into the current Product. 
• Import product threat: Import a determinate threat to the product component, this component represents the global threats, weaknesses, and countermeasures for the whole project.
• Insert Notification: Insert a notification into the rules engine. This notification is shown in the notification section from the Architecture tab. There are different types of notifications: Alert, Warning, and Info.
• Insert Conclusion: Insert a conclusion into the rules engine. There are different types of Conclusions that can be set:
  • Hidden, Error, Alert, Warning, Info, Advice, Security Policy, Required Information: These conclusions are shown in the Analysis sections of the application. The Hidden type is not shown and used only to make internal decisions based on rules.  The Required Information conclusion will not allow the questionnaire to be completed, while it is active.
• Insert Question: Insert a new specific Question to a given Question Group. This action requires the conditions Question group exists, the Question will be added to the selected Question group.
• Insert Question Group: Insert a new Question Group and display it in the questionnaire based on the stated Priority. Parameters are:
  • Unique ID.
  • Question Category: The Question Category as indicated in Sections.
  • Text: The text of the question. 
  • Priority: Priority to set up the Question Group ordered from top to bottom.
  • Mutually Exclusive Answers: Only one answer will be allowed at the same time. 
  • Required: The question is mandatory.
  • Description: The description text of the question.
• Set Custom Field Value: Set the value of a specific User Defined Field. 
• Set Custom Field Visibility: We can change the visibility of a custom field: true or false.

Module Component: 

Conditions:

• Applied Control: An specific Control is applied. This is indicated by its individual Unique ID.
• Conclusion exists: Check whether a Conclusion has been inserted into the rules engine.
• Conclusions not exists: Check for the non-insertion of a Conclusion.
• Component: Check if a given Component exists in the engine. 
• Component Definition:
• Control Not Applied: An specific Control is not applied, indicated by its Unique ID.
• Question group exists: Check if an specific Question Group exists.
• Question from main questionnaire is answered.
• Question from main questionnaire is not answered.
• Question is answered.
• Question is not answered. 
• Risk Pattern exists:
• User defined field: Same as in the Main Module.

Actions:

• Answer Question From Main Questionnaire: Same as in the Main Module.
• Answer Question: Automatically answer a question from the Component Questionnaire (with all the implications that will have).
• Apply Control: Applies a specific control/countermeasure, changes its status from Recommended to Required. Parameters are:
  • Library: The Library that holds the Control.
  • Countermeasure: The Control that must be applied if the condition is True.
• Apply security standard: Change the countermeasure status from all countermeasure of the project with the selected standard of this action.
• Extend Risk Pattern: Overwrite the information from a risk pattern with new data. For example, we overwrite the description of the threats or include more countermeasure in several threats.
• Mark Countermeasure as Implemented: Change the status of the selected countermeasure to Implemented.
• Import Risk Pattern: Imports a specific Risk Pattern from a Library. Parameters are:
  • Library: The Library that holds the Risk Pattern. 
  • Risk Pattern: The specific Risk Pattern to be imported.
• Import Specific Risk: Import a specific Risk/Threat from a given Library. Parameters are: 
  • Library: The Library that holds the specific risk.
  • Risk: The Risk we want to import.
• Import Specific Use Case: Import a specific Use Case from a given Library. Parameters are:
  • Library: The Library that holds the specific Use Case. 
  • Use Case: The Use Case we want to import.
• Insert Conclusion: Same as in the Main Module.
• Insert Notification: Insert a notification into the rules engine. This notification is shown in the notification section of the Architecture tab. There are different types of notifications: Alert, Warning, and Info.
• Insert Question: Same as in the Main Module but applicable to the Component Questionnaire.
• Insert Question Group: Same as in the Main Module but applicable to the Component Questionnaire.
• Modify Mitigation Value: Modify the mitigation % of a Control for a Threat based on the condition. Parameters are:
  • Templates & Libraries: The Template or Library where the Control we want to modify is located
  • Risk Pattern: The Risk Pattern which holds the Control. 
  • Threat: The Threat which holds the Control. 
  • Countermeasure: The Control itself. 
  • Mitigation: The new mitigation value to set.
• Set Custom Field Value: Set the value of a specific User Defined Field. 

Drools

Within the rules option of the Interface, we also provide a raw Drools rule viewer. The Rule System is based on JBoss Drools and Java. The UI for the Rule Editor just translates the visual configuration to Drools code. For complex rules which cannot be created using the available conditions and actions, they can be created directly in drools: 

The rules under the user_defined folder are the ones created with the Rules Editor and should not be modified as they will be rewritten when changing the GUI rules.

A Practical Example: Import AWS Cloud Risk Patterns based on the questions. 

Let's imagine you have a Library holding some different Risk Patterns for AWS deployments and you want to customize the questions on the questionnaires and import specific risks accordingly. 

Let's also say, we have a Library already setup within the system, the Hydras-AWS-Foundation Library and the Risk Patterns it holds are as following: 

So our requirement is to divide this into three actions, we will import the Risk Pattern for EC2 if the user answers EC2 is being used, we will import the Risk Pattern for S3 if the user answers S3 is being used and all the other Risk Patterns if the user is using AWS. We will setup all the Questions to support this as well. So we will be creating these Rules one by one as follows: 

Step 1- Add an AWS option to the Public Cloud deployment option.

There is already a "Public cloud" Question on the Deployment Question Category for the "How will the component be deployed?" Question Group. Hence we will use this as our starting point.  

We want a new Question Group to be created and inserted if the user clicks on the "Public cloud" checkbox so that we can ask which cloud services are in use:

• First, we create the Question Group based on the answer of "Public cloud":
  
  
  We have set the priority to a high value (3150) so we make sure it will be added to the end of the Question Category screen. 
  
  
• Then we add the AWS option to this Question Group: 
  
  
  We select the newly created Question Group as a Condition and set the Action to add a new Question. 

After these two steps we will have this new option on the Questionnaire: 

Step 2- Import Generic Risks if AWS is used.

Now we want to import all the General Risks that apply to using AWS regardless of which individual AWS services are used: 

We have selected here the Question is Answered Condition and added a new Import Risk Pattern Action for each of the general AWS Risk Patterns we want to add to the model.

Step 3- Add specific questions for EC2 and S3 usage.

In addition to general AWS risks, we'd also like to provide risk and controls for that relate to using specific AWS services.  If the user has answered AWS is being used, then we can include a new Question Group asking which AWS Services are used: 

And we will add the two possible options for this Question Group with a new rule: 

So now we have all the questions set up:

Step 4- Import EC2 or S3 Risk Patterns based on the answers provided.

The final step is to import the individual risks for each of the options, we will create two different rules, one for each of the answers.

To import EC2 based risks when the option is marked, we will create the following rule: 

To import S3 based risks when the option is marked, we will create the following rule: 

Step 5- Test the setup is working.

To test the rules, you can create a new Product, select one server-side component (i.e. Web Application - Server side), answer the Component Questionnaire and under the Deployment section, mark "Public Cloud", "Amazon Web Services", "EC2" and "S3" and check the configured Risk Patterns are included in the Threat Model. 

Additionally, you can check the "debug rules" box on the component questionnaire to view in real-time which risk patterns will be imported based on the current state of the questionnaire:

For Reference.

Rules naming convention.

The name convention for the rules is as follows: 

   {Prefix indicating the type of rule it is}: {functional area affected} - {Generic Component Classification} - {Specific info about the conditions/actions}

Possible values for each of them are: 

{Prefix indicating the type of rule it is}: 

• MQ: In these rules the question groups and the questions are inserted into the main questionnaire.
• Q:  In these rules the question groups and the questions are inserted in the component questionnaire.
• Risk Pattern: The rules with this prefix are defined to import or extend the risk pattern from determinate libraries. The countermeasure weights are also modified in these rules.
• Conclusion: The rules are used to show a determinate notification in the component questionnaire when some conditions are provided.
• MConclusion: The rules are used to show a determinate notification in the main questionnaire when some conditions are provided.
• Change Questions: One question from the questionnaire is answered with a determinate value when some conditions are provided.
• ControlApplied: These rules are used to apply a control when some conditions are provided.

{functional area affected}: That represents the tab name from the questionnaire.

{Generic Component Classification}: Here the name of the component or the component type is written.

{Specific info about the conditions/actions}: This is a special case because it can be the name of a question group, name of answered question, * (that means that the questions are inserted into one question group) or the rule action.