Our CTO Paul Santapau will be in attendance at the upcoming Def Con conference in Las Vegas August 9th-12th.

Please do let us know if you would like to schedule a meeting with Paul to discuss all things DevSecOps and our IriusRisk threat modeling platform – including new features and future development.


If you’re mulling over why you should invest in a threat modeling platform, please check out our recent blog post on that topic:

…..The key again is a threat modeling tool that can talk the developers language and sync with their toolchain such as issue trackers, allowing for tracking of tickets to manage the status of identified risks as they progress through the development process. Read More

And we have also recently recorded a new introductory video to IriusRisk to give you an overview of its capabilities and benefits:

Hope to see you there!

We are thrilled to announce we are silver sponsors of the upcoming OWASP AppSec Europe conference due to take place in London 2nd – 6th July.

Here’s a little about the conference:

The premier application security conference for European developers and security experts. AppSec EU provides attendees with insight into leading speakers for application security and cyber security, training sessions on various applications, networking, connections and exposure to the best practices in cybersecurity.

Come and visit us at our stand to talk about automated and scaleable threat modeling and the exciting new release of our IriusRisk threat modeling platform which includes new libraries – Docker, Mobile and Google Cloud – as well as architectural and data-flow diagramming capabilities.

We hope to see you there!

At the recent Open Security Summit we had the great pleasure of interviewing Adam Shostack about his keynote presentation “A seat at the table” and the challenge of getting security involved in product and application design.

We covered numerous topics from the benefits brought to business by threat modeling to pooping unicorns.

Adam is a member of our advisory board and one of the preeminent threat modeling experts in the world.


Over on the Leviathan Security blog Crispin Cowan pens his thoughts on the “Calculus of Threat Modelling” within which he makes this comment:

There are many threat modeling tools available, but they are really just substitutes for threat modeling best practice, which is for a threat modeling expert to meet with engineers who are experts on the system being modeled in a conference room with a white board.

This sentiment certainly has merit. There is nothing quite like stakeholders meeting together face-to-face to mull over a threat model. However, there is a problem with this approach.

Software development is increasingly about moving fast with a culture of continuous integration and deployment. This, coupled with development teams working on dozens – or even hundreds – of services simultaneously makes the “whiteboard” method of threat modeling increasingly untenable.

Decongesting the Security Bottleneck

Security has traditionally been seen as something of a bottleneck at the end of the development lifecycle and this only becomes more acute as we move towards the Agile “always shipping” culture. The antidote is to hook security seamlessly into this new culture and empower developers to be self-sufficient by facilitating processes that put security knowledge directly into the hands of development teams.

Given this I’d posit the manual whiteboard threat modeling process is often not practical and is certainly not scalable. We need to leverage other methods and this is where threat modeling tools are the perfect choice.

Many of the applications and service components we build and their underpinning architectures are the same or very similar, meaning the security risks and mitigations associated with them repeat over and again, allowing us to create risk patterns and templates. You may be thinking a one-size-fits-all is a clumsy approach for generating a threat model as many threats generated by an automated tool may not be relevant, but that depends on the sophistication of the threat modeling tool.

The IriusRisk threat modeling tool for example, answers this problem with very small risk patterns that relate explicitly to specific service components and their use-cases and risk patterns are generated as building blocks assembled for the model based on an intelligent rules-based questionnaire relating to the architecture.

Utilising this approach has a twofold benefit.

Firstly, it ensures only relevant security risks are identified.

Secondly, this questionnaire “self-service” strategy allows for those answering the architectural questionnaire to have no prior knowledge of security and yet still arrive at a useful and actionable threat model.

How do we hook this threat model into the modern development toolset?

Communicating threat models utilising the whiteboard method has always been somewhat fraught. Do we manage the model through Excel or a shared Google document? Aside from not scaling well the model and identified threats and risks become difficult to track and keep up-to-date with continuous changes, especially in an Agile environment.

The key again is a threat modeling tool that can talk the developers language and sync with their toolchain such as issue trackers, allowing for tracking of tickets to manage the status of identified risks as they progress through the development process.

The Crux

I view threat modeling tools as complimentary to manual “whiteboard” approaches. As with all things there is no silver bullet and tools do not eradicate the need for highly skilled threat modellers. But as most of what we build are boilerplate applications, services and architectures, we can automate most threat modeling processes allowing experts to focus their attention on those more interesting, bespoke and complex systems that will truly benefit from their input.

High quality threat modeling tools have a solid ROI and allow us to scale and track changes in our increasingly dynamic environments. We should be looking to automate boring repetitive security processes as much as possible in order to increase speed and reduce time, costs and friction.

If you’d like to have a chat and demo of our risk pattern, questionnaire driven IriusRisk Threat Modeling platform don’t hesitate to get in touch.

Back in June I wrote some practical guidance on GDPR and application security and made the following comments:

…..as many applications we develop have commonalities, we are able to create architectural risk patterns that can be applied to other applications.

The key to simplification is to break down the application into individual architectural patterns – for example the registration form – and then ask ourselves pertinent questions in relation to GDPR requirements.


Within our IriusRisk Threat Modeling platform we have done the hard work for you. If you indicate that your application will process PII data and this data relates to data subjects within the EU, then GDPR standards and risk patterns will be applied.

IriusRisk does not simply import the entire GDPR Standard and overwhelm security and development teams, but rather applies specific GDPR security requirements relevant to the service you are building.

For example, it’s only useful to import GDPR requirements relating to a user interface if your service includes one. IriusRisk ensures this is the case and only those measures that make sense are recommended.

The auto-generated GDPR requirements can be viewed by security teams and auditors within IriusRisk and can be uploaded to issue-trackers for developers to implement during the build process.

Communication between IriusRisk and issue-trackers is bi-directional allowing security teams and auditors to observe current adherence to – and progress of – GDPR compliance in near real-time. This has the additional benefit of facilitating communication between the relevant stakeholders.

The simplicity of this process is illustrated in the video below:

BDD-Security is now easier to configure and launch from a Docker container.

Because BDD-Security stores most of its configuration inside a config file (config.xml), it was cumbersome to change the parameters when launching the Docker container.

To solve this we have now made it easier by allowing all of the config.xml attributes to be set via the command line, instead of in the file. This means you can create a docker container with the most commonly used settings configured in the config.xml file, and then change parameters for the test launch via the commandline.

Everything is explained in Github under: “Using config.xml and the command line”.

For those that don’t know, BDD-Security is an open source security testing framework that uses natural language Gherkin syntax to describe security requirements as features. Those same requirements are also executable as standard unit/integration tests which means they can run as part of the build/test/deploy process.

Features & benefits include:

  • Free and Open Source automated testing framework for security
  • Ready to run on a Continuous Integration Server , as part of the build/test/deploy process
  • Upgrade DevOps to SecDevOps
  • Generate reports, to be easily viewed and understood by business and security users
  • Tests are run dynamically against a deployed application, no need to access your source code

BDD-Security is written in Java and based on Cucumber, Selenium 2 (WebDriver), OWASP ZAP and a number of other security tools. This means that any automated testing can be performed, while describing the actions in a easily understandable format.

Why not try it out today!

Stay up to date with our latest news.
Subscribe now