Scroll to discover
See a Demo
Skip to content

New Dataflow library in IriusRisk v4.6

Data flow diagrams (DFDs) are graphical representations of a system architecture and its primary purpose is to model how data flows through a system. DFDs became popular in the 70s when they were used for structured analysis and design, and have maintained their popularity since then because they're easy to understand.

Introducing data flows

Data flow diagrams (DFDs) are graphical representations of a system architecture and its primary purpose is to model how data flows through a system. DFDs became popular in the 70s when they were used for structured analysis and design, and have maintained their popularity since then because they're easy to understand. We can see in these diagrams which processes act upon what data, and where this data is stored. They can also be used to provide helpful context related to the security decisions and assumptions made for that system. This representation of the system under design is strongly suited to answer the first question in Adam Shostack's 4 Question Framework for Threat Modeling: What are we working on? DFDs highlight the security-relevant parts of the system because, as Shostack usually says: threats tend to follow data.

IriusRisk Dataflow Library

In IriusRisk v4.6 we've released a new library called "IR Dataflow Library''. It was designed to take advantage of the IriusRisk rules engine to provide some dynamic behavior on the threat models. While IriusRisk users have been able to create their own dataflow rules for some time, this is the first time that we are releasing a library with dataflow rules out of the box.  In the following figure you can see some of the rules included in this new library:

Each of these new rules uses the IriusRisk Data Flow module for rules:

Data flows and IriusRisk tags

Right clicking on a IriusRisk data flow allows you to assign "tags" to the dataflow. These tags are arbitrary string values. Tags that have already been used on dataflows in this, or in other threat models will appear in a drop down list. You can select one of these, or enter a new string value that will become a new tag.

A common use-case for tags is to use them to represent protocols, such as TLS, SSL, HTTP and/or HTTPS. Tags serve two purposes:

1. They act as a visual aid to help understanding the diagram

2. They can trigger rules that will modify the threat model.

We'll use the following set of tags to characterize data flows in IriusRisk. These tags represent the protocol or file format used in a dataflow to dynamically update the threat model:

  • http (HyperText Transfer Protocol).
  • https (Hypertext Transfer Protocol Secure).
  • tls (Transport Layer Security).
  • 2fa (Two-Factor Authentication).
  • mfa (Multi-Factor Authentication).
  • json (JavaScript Object Notation).
  • xml (Extensible Markup Language).
  • jwt (JSON Web Token).
  • ssl (Secure Sockets Layer).

Example architecture

Let's see how these rules work with the following example architecture:

Dataflow's threats can be located in the threat model by using the "Source" attribute:

The same can be done to filter dataflow's countermeasures:

Besides the new risks and countermeasures based on the protocol or file format used in the data flow, the dataflow rules have triggered other changes in the final threat model:

  • Due to the fact that Credit Card data is flowing in some of the dataflows, the Asset tab questions for the involved components (at the origin and at the destination) are automatically answered to reflect this data movement. For example, for the Android Device Client component:
  • Since we are using HTTPs for the dataflow between the Android Device Client and the Microservice component, the countermeasure CWE-319-TRANSPORT (Encrypt data between the client and server/service) is automatically implemented:

  • However, since we are using SSL to encrypt the traffic between the Microservice and the Elastic File System (EFS), we'll get a warning message in the IriusRisk's Notification panel to suggest us to use a safer alternative (TLS):

  • Since we are transferring sensitive data (Personally Identifiable Information data) to a Public trustzone, we'll get a warning message in the IriusRisk's Notification panel:

Conclusion

We have covered some of the dataflow rules that are included in the release 4.6 of IriusRisk. This is only the first iteration for this new library, however, it could serve as a baseline to create your own dataflow rules to meet your specific requirements with your threat models.

We would love to hear from you about this new library. Please, drop us a line at info@iriusrisk.com.

)