May update for RiskTree

The latest update for RiskTree has just gone live. There aren’t any big, flashy features this time – just a number of incremental improvements that will make your experience smoother and easier. The most noticeable change will be at login: instead of including a field for the MFA code with the username and password, we’ve split this onto a separate box. Everyone will enter their standard credentials, but only users who have enabled MFA will be prompted for their code. It’s a small change, but it makes the logging in process a little bit clearer!

Another change is the ability to save files in a compressed format. This is particularly useful for the risk assessment reports created by RiskTree Processor, as these files can get rather large. The new compressed format has the extension .rtz (RiskTree zipped), and this can be used for loading and saving both RiskTree files and reports.

Please continue to let us have your suggestions for improvements and features for RiskTree. We’re driven by our users’ requests, and they all help to make the process better for everyone.

Principles are good, but exceptions are OK

Recently we discussed the security of RiskTree with a client, who ran through the NCSC Cloud Security Principles. Since RiskTree is delivered as software-as-a-service, this made sense. One point that arose was the lack of Multi-Factor Authentication (MFA) in use: CSP Principle 10 states that 2FA is ‘considered good practice’, using either a hardware or software token or out of band challenge.

We subsequently implemented MFA, using the Time-based One-time Password Algorithm. This allows users to enter a code (either manually, or by scanning a QR code) into an app on their mobile ‘phone, such as Google Authenticator, Microsoft Authenticator, or LastPass Authenticator. We haven’t mandated its use, preferring to let our users decide whether they need it. We’re allowing our users to make the decision about their data, because it isn’t ours to make. To help inform their decision, we used RiskTree to analyse the risks of client data being stolen from RiskTree, and put the information onto the site as a demo ( Consequently, some users have enabled it, and some haven’t.

The key question though, and the reason for this blog post, is “what are we actually protecting?”. RiskTree stores no risk data from any of our clients – all of the data are handled locally in the browser. For the risk calculations, just a node reference and the six assessment values are transferred to the servers for transferred to the servers for processing into the risk assessment, and creation of the data charts and visualizations, making the most of the power of cloud processing for the intensive number-crunching part of the work. The only data that we hold about our users is their name, e-mail address, and organization, and we don’t show the latter two, even if a user is logged in. There is no ability for the user to change any of these, so the risk of data tampering has been removed. The only thing than can be achieved by stealing credentials is that the attacker can use RiskTree without paying.

This leads us to conclude that for RiskTree, MFA is overkill. We’ve designed our SaaS to avoid holding any data – to an extent it’s almost like a lambda, in that a user throws some data at it and it returns some results. Whilst the principle of applying MFA to SaaS is sound, it isn’t important if there isn’t anything to protect. Having security principles is a great idea, but following them slavishly isn’t. When performing a risk assessment, always keep the context in mind, and be prepared to have exceptions.

Introducing RiskFlow™

A RiskFlow diagram, created using RiskTree

We’ve added a new data visualization tool to RiskTree. It’s a Sankey diagram for risk, showing how your risks change as you introduce countermeasures. The example above shows a typical diagram, with risks moving from intrinsic on the left, to residual in the middle, to target on the right. Residual risks are risks that have been mitigated to some extent, through the application of countermeasures. Target risks show the effect of future countermeasures – this could be a ‘what if’ scenario, or could be taken from a project plan showing that they will be introduced at a future date.

The thickness of the arrows reflects the number of risks moving between each block. So, of the eight intrinsic risks at Very High , when their residual status is assessed, three remain at this level, one becomes High , three become Medium-High , and one becomes Medium .

The diagram is interactive. As you move your mouse over the blocks and the arrows, a pop-up box lists the risks. These are all linked back to the main risk table in RiskTree, so you can drill into the data in the same way you can with all of our other charts.

The RiskTree Processor tabs, showing the location of RiskFlow

As with all of our other upgrades, RiskFlow will work for reports that have been previously created. Just reload the report file and you should see the new tab in the Risk Charts section.

Reaction to RiskFlow from our testers has been uniformly positive. We hope that you’ll feel the same way when you get to see it.

RiskTree update

We’ve just updated RiskTree ready for 2020. The changes include:

  • You can now view charts showing how you’ve used tags in your RiskTree and reports.
  • The search functionality uses tabs to display its results (much clearer!) and is now available in the RiskTree Processor, as well as the Designer.
  • The risk labels on the RiskSpider and RiskGraph data visualizations can now be wrapped to two lines (no more truncated risk names!).
  • Improvements to the CSV file downloads.
  • A number of other minor tweaks and improvements.


Welcome to the 2T Security blog. We’ve created this so that we can write about security and risk topics that interest us, and that might be of interest to the community. We’ll also be writing about our RiskTree process for risk management, especially where this doesn’t fit in with the standard help pages.

We’re looking forward to the conversation!