How to work collaboratively when creating custom libraries

As a Central Security Team you may want to get other Security Teams to work in a collaborative way with each other. The purpose of this document is to analyse how distributed security teams could work together to create custom threat libraries for IriusRisk.

Usage Scenario

As a central security team I want all other teams to create their own custom Components and Libraries and have those changes visible by all other teams in my organisation.  

Recommended approach

A single IriusRisk production system with an additional development system. Teams create content on a shared development instance, those changes could be pushed to a VCS (Version Control System), and the central team takes those changes, tests them and deploys to the production environment. Once in the production system, the development system is then synchronized with all the libraries from the production system. 

Explaining by Example

The best way to explain this is by example:

A Central Security Team wants to create two new IriusRisk components. 

The first one (a new NGINX component definition) is assigned to the Sec Team North, one of the distributed security teams within the company. The second one (a new Apache component definition) is assigned to Sec Team South, another of the distributed security teams in the company.

Both teams will be working with the same IriusRisk development instance, at the same time, to create the new security content, those two new components mentioned before, into a custom library called “MyCustomLibrary”, managed by the Central Sec Team.

After the new security content is created by those Sec Teams and tested by the Central Sec Team, the updated version of the library “My custom” will be updated in the production environment to be used across all of the Security Teams.

Let’s take a detailed look at the process.

Step by step

With these subjects in mind the workflow could be illustrated with the following example:

As a Central Security Team, you want to create two new components into MyCustomLibrary Library. So you have to follow these steps:

1. STEP 1. Central Security Team wants to create two new IriusRisk components:
   a. The first one (a new NGINX component definition) is assigned to the Sec Team North
   b. The second one (a new Apache component definition) is assigned to Sec Team South. 
    
2. STEP 2. Both teams will work with the same IriusRisk development instance to create the new security content (two new components for this example). 
   a. Team North edits MyCustomLibrary library and adds a new Risk Pattern for their NGINX component definition.
   b. Team North adds a new Component Definition for NGINX component and links it to their risk pattern.
   c. Team South edits MyCustomLibrary library and adds a new Risk Pattern for their Apache component definition.
   d. Team South adds a new Component Definition for Apache component and links it to their risk pattern.      To learn more about creating content take a look at this article.
    
3. STEP 3. At the time that both teams have completed their tasks the Central Security Team receives a notification about the completion of the tasks. Thus a new version of MyCustomLibrary library is ready to be exported from IriusRisk development instance to an XML file with the new security content within.
    
4. STEP 4. Now, the Central Security Team can export the MyCustomLibrary library from the IriusRisk development instance in an  XML file: 
   a. Since new security content was included in the MyCustomLibrary library, to better track the changes is a good practice to edit the xml file of the library to manually increase the revision number attribute in the XML file.

                      

   b. You are creating a feature branch from the dev branch in the VCS. This new branch will contain a copy of the development instance libraries.
   c. Then you copy this new version of MyCustomLibrary to this new branch by overwriting the xml file MyCustomLibrary.xml into the folder where the libraries of the feature branch are and use the “Update Library” action for libraries in the IU. This will update your instance with the new security content.

          

   
   d. Now you can test this new library version x2 by creating threat models based on this new version x2 to see if the new risk-patterns, components and rules work as expected in a development environment.
   e. If any tests do not pass, the process is that the Central Security Team should return back the ticket to the responsible team where the issue arises and returns to step 2 to let the corresponding team fix the issues relevant to the failed tests.
   f. Otherwise, if tests return OK, the changes and new content are approved, so you can merge the feature branch with the dev branch. You can see an example here.     
    
5. STEP 5. Now that the updates and new content are merged with the dev branch, you should open two new tickets for production and/or DevOps teams to get the changes at development (Dev) instance  propagated to production (Prod) Instance and to merge dev branch with the master branch at the VCS.

Now then let’s identify actors and objects on this example and some detailed description: 

Actors:

• Central Sec Team: The Central Security Team, who is responsible for the creation of the content and acts as the orchestrator, tester and deployer of the new content of the libraries.
• Sec Team North: One of the distributed security teams which will be responsible for the creation of a piece of the content.
• Sec Team South: Another distributed security team which will be responsible for the creation of another piece of the library content

Objects: 

• IriusRisk Development Instance: An instance of IriusRisk that can be used to make changes to libraries. This  environment will  also be used to test those changes.
• IriusRisk Production Instance: An instance of IriusRisk that can be used to hold and propagate libraries across different Security Teams and different Development Teams. The updated libraries will be stored in there.
• VCS: Tool or system that could be used to manage and trace the changes and versioning on the files and the source code anytime they are being created and/or modified by several people. VCS stands for Version Control System. In our example we will use GIT (https://git-scm.com/).

Step by step detailed description:

• Creating new (security) content (STEP 2b and Step 2d): The creation of new objects at the security libraries, like:
  • Risk patterns
  • Use cases
  • Threats
  • Countermeasures
  • Component definitions
  • Components
  • Rules
  • Even a whole new library
  To learn more about creating content take a look at this article.

• Working with branches (STEP 4b, STEP 4c and STEP 5): The dev branch contains the latest version of the libraries and the master branch contains the production version of the libraries. When a change is made in the libraries a feature branch is created from the dev branch and merged again to the dev branch once the changes have been tested and accepted. Master branch is updated when the Central Security Team decides to release a new version of the libraries in production. It could be considered as a simplified Gitflow workflow with only feature branches (see this guide about GitFlow). No release or hotfixes branches are needed in this case.

• Creating a new branch (STEP 4b): In this example, When you make a copy of the libraries that are in use in the Production Environment to work with them without altering the production instance libraries.

  • • Example create:

      $ git checkout -b NewCompNginx003 
      
      (Creates the branch and moves pointer to it)

• Exporting a library (STEP 3): You have your library in an IriusRisk instance and you use the “Export” action to get an export of the library in a XML format.

                     

• Updating a library (STEP 4c): You have your library updated with the new content in a XML file and you use the “Update Library” action to update this new content of the library in an IriusRisk instance.

         

• Test libraries (STEP 4d): Create threat models based on the new version of the libraries to see if the new risk-patterns, components and rules work as expected in a devevelopment environment.

• Merge with the dev branch (STEP 4f) : Once the Central Sec Team has tested the new security content and changes successfully, then the changes can be integrated into the dev branch. This way you can keep the dev branch synchronized so that other security teams can start working from the latest libraries versions.

• Example merge:

  $ git checkout NewCompNginx003 (Change to new branch)
  
  $ git add MyCustomLibrary.xml (add updated file)
  
  $ git commit -m "New Component 003 for Nginx."
  
  Created commit 17c688a: New Component 003 for Nginx.
  
  $ git checkout dev (Change to dev branch)
  
  $ git merge NewCompNginx003 (add changes to dev branch)

  NOTE: To get better diffs on large XML files it’s useful to set the global diff algorithm as “patience”. This can be done with the following command:

  $ git config --global diff.algorithm patience

• Merge dev with master branch (STEP 5): Once the Central Security Team decides to deliver a new version of the production libraries, the master branch is updated from the dev branch. The master branch is the source of truth for the production system.The process is the same as above.