We are excited to announce the release of IriusRisk 4.14 which includes these new enhancements and features:
- Make sure rules are consistently applied over time and across different environments with the new rules validation endpoint
- Take IaC design security to the next level by creating threat models from your Terraform Plan files
- Action threat models faster with four new threats and countermeasures filters
- Plus more!
Take Infrastructure as Code design security to the next level by creating threat models from your Terraform Plan files
Given this AWS example from HashiCorp:
$ terraform plan -out=plan
$ terraform show -json plan >> aws-example-plan.json
$ terraform graph -type=plan -plan=plan >> aws-example-graph.gv
We can then send the plan files to IriusRisk with a simple curl command to build the IriusRisk threat model:
-H "Accept: application/json" \
-H "api-token: $IRIUS_API_TOKEN" \
-H "Content-Type: multipart/form-data" \
-F "firstname.lastname@example.org,aws-example-graph.gv" \
-F "product-id=terraform-plan-test" -F "name=terraform-plan-test"
And this is the resulting threat model in IriusRisk:
Action threat models faster with four new threats and countermeasures filters
The new Threats filter is “Countermeasure progress” and lets you filter by different ranges of countermeasure implementation progress.
- Priority - use this to focus on the highest impacting countermeasures
- Owner - for when you want to see your own countermeasures or those assigned to a colleague
- Issue ID - really useful to see which countermeasures to send to the backlog next
Make sure rules are consistently applied over time and across different environments with the new rules validation endpoint
curl -L -X POST 'https://yourinstance.iriusrisk.com/api/v1/rules/verify' \
- Run all active rules for a temporary test project on a production instance and compare the output with the previous output in order to proactively spot unexpected changes over time. These could be caused by unexpected changes to global objects such as trustzones, tags, or custom fields that result in a change in rule conditions being met.
- Run all active rules for a temporary test project on a product and development instance, and compare the two outputs. This would help you spot differences and inconsistencies between those environments.
- When developing new rules, run those rules against a test project to ensure they behave as expected. You can do this while those rules are still inactive so they don’t impact other projects.
New rules action to mark threats as Not Applicable
- Marking threats not applicable for a component in a Trusted Partner trust zone because they are mitigated by the third party.
- A component is nested inside another component where the parent component renders certain threats in the child component as out of scope. For example, network related threats to a web service inside an EC2 instance.
- OCI Analytics Cloud
- OCI Autonomous Shared Databases
- OCI Block Volumes
- OCI Cloud Guard
- OCI Compute
- OCI Container Engine for Kubernetes
- OCI Events Service
- OCI File Storage
- OCI Flexible Load Balancing
- OCI Functions
- OCI IAM
- OCI Identity Cloud Service
- OCI Integration Cloud
- OCI Logging
- OCI Notification Service
- OCI Object Storage
- OCI Streaming
- OCI Vault
- OCI VCN
- Kerberos Authentication Server
- DNS Server
- IBM WebSphere Liberty
- Apache HTTP Server
- Apache Tomcat
- Microsoft IIS
For more information, see the Version 4.14 Release Notes.
Shape the future of Threat Modeling with us!
Join IriusRisk Horizon
IriusRisk Horizon - Customer Research, Product Discovery, and Early Access. Join today.