Security workflows for DevOps teams with IriusRisk

 | Continuum Blog, SecDevOps

Threat Modeling and defining security requirements is just step one on the journey to building a secure system. The threat model should really inform all downstream security activities, including implementation and testing. But all too often, the model is used only during design and then becomes less and less relevant as the project progresses. This is sometimes simply due to a mismatch in tooling: the Threat Model is documented in a spreadsheet, document or other file based system – and that doesn’t travel well when developers are using issue tracker to manage requirements or automated tests to verify that they’ve been implemented.

IriusRisk is firstly a risk and requirements automation tool but for the generated model to be effective and useful for the project team it offers integration with issue trackers, automated testing and security testing tools. A threat model that’s out of date or doesn’t accurately reflect the current risk quickly loses it’s value. The diagram below illustrates a typical security workflow:

Workflow

1. The security or development team creates a new product definition on IriusRisk by answering a questionnaire. The questionnaire as well as the fields that can be stored are customizable by administrative users.

2. IriusRisk creates a threat model based on the responses to the questionnaire and it’s own internal library of risk patterns. The generated model contains Risks, Weaknesses (linked to CWE) and Countermeasures. Some of the countermeasures are created as recommendations, and others as Requirements.  (The security team can optionally review and edit this model before uploading the requirements to an issue tracker)

3. Developers and Operations teams will see the newly created tickets representing the security requirements on their issue tracker.  They treat these as they would any other requirements and can mark them as Implemented, or Rejected.  Additionally, they can choose to include the new tickets and estimate the effort required as part of their normal sprint planning.

4. IriusRisk polls the issue trackers every 5 minutes and updates the status of the Countermeasure with the status of the ticket.  If the ticket has been marked as resolved or implemented, then IriusRisk will do the same for the Countermeasure in its risk model.  And it will then reduce the risk rating of the risk associated with that countermeasure:

5. Run security tests against the application or source code. These could be in the form of unit tests such as are provided by BDD-Security, other Cucumber, JUnit tests or scanning results from OWASP ZAP or HP Fortify.  The tests can be executed as part of the continuous build or deploy process and the results  uploaded to IriusRisk through the API.

6. IriusRisk will then evaluate the test result may adjust the risk rating again.  If the risk rating was reduced due to a countermeasure being marked as Implemented, but the test result indicates that a weakness still exists – then IriusRisk will increase the risk rating back to its original value.  In addition it can automatically create a new ticket on the issue tracker that represents this new vulnerability:

Since the model has an established relationship between Countermeasures and Weaknesses, the newly created ticket can reflect this so that the dev/ops team understands that the two tickets are related:

Should the test status change in a subsequent test run, IriusRisk will update the ticket and can also be configured to automatically close the ticket once the test passes.

Roles

This workflow was designed to cause minimal impact to the DevOps teams.  They can continue to use their existing issue tracker to plan work and resolve incidents, while the security team can use IriusRisk to orchestrate the security process and manage risk as the project progresses.  The near real-time integration between IriusRisk and the issue trackers and testing tools allows the security team to stay up to date on the current risk – and to provide feedback to the DevOps teams about newly identified issues or new security requirements.

If you’d like a demo of IriusRisk please contact our sales team.

 

 

Did you like this article?

YOU MAY ALSO LIKE
  • Web Application Security Checklists as Code
    Web Application Security Checklists as CodeThe problem Imagine ACME Web Development Company performs several tens, hundreds or even thousands of Web Application deployments a year and it has a typically small Application Security Team compared to the development and QA teams. How does ACME ensure that those applications have included a reasonable set of security countermeasures? How does ACME verify […]READ MORE
  • Upgrade your DevOps to SecDevOps at RootedCon
    Upgrade your DevOps to SecDevOps at RootedConJoin our CTO Paul Santapau at RootedCon in Madrid, where he’ll be presenting a talk on implementing security in DevOps cultures. Integrating security into agile development methodologies poses unique challenges to both the security and development teams. These are particularly striking in continuous delivery (CD) processes where the rate of code deploys and automated testing […]READ MORE
  • Launching IriusRisk ‘Community Edition’
    Launching IriusRisk ‘Community Edition’The scalable Threat Modeling and Risk Management solution for product development is now free to use. Developers, architects and technical teams, this is a call for you to contribute to building the first collaborative set of threat model templates licensed under Creative Commons and available to everyone. IriusRisk uses architectural risk patterns and templates to […]READ MORE