Threat Modeling Handbook #6: Agile Threat Modeling

It has been a long journey! In the past stories (links below) of this series we discussed in detail how to build a process using threat modeling to define security for a project, then use that to verify and continuously test the needed security control (the 3 phases of threat modeling). In this story, we tackle a question that must have crossed the minds of many readers; How to make sure this process doesn’t become a bottleneck blocking the engineering teams?

Previous stories:

• Threat Modeling Handbook #1: What is a threat model and why your service needs one
• Threat Modeling Handbook #2: Threat modeling is a process, not a document
• Threat Modeling Handbook #3: The Thought process behind identifying threats (with an Example)
• Threat Modeling Handbook #4: How to get better at Threat modeling
• Threat Modeling Handbook #5: Convert your threat model into an automated pentest using DevSecOps tools (with Examples)

In an agile environment, it is important to make sure all the steps we discussed in the previous stories don’t block the flow of the project being developed. Also, another challenge is that as the size of the organization and the number of teams and applications grows it becomes harder to scale the process. Hence, in this story, we discuss some suggestions to help make the threat modeling process efficient, scalable, and consistent without sacrificing the quality.

For this to work on an organizational level, these suggestions need to span all of the 3 tracks of the PPT Framework; People, Processes, and Technology to have the desired impact.

People

Most organizations have a painfully low ratio of application security engineers to developers. On average, the ratio could be 1:200 (1 applications security engineer for every 200 developers), and I have even seen that go up to 1:1000 and higher in some cases. This is why the main bottleneck affecting the threat modeling process is the scarcity of application security people and knowledge.

Imagine one application security engineer trying to perform all the phases of the process we discussed in this series for 20–30 projects at the same time, this of course doesn’t work very well. This is why investing in the “People” track is crucial for the threat modeling process to work as the knowledge needs to be distributed amongst enough people for the process to work and scale. Here are some suggestions to help achieve that:

1. Training:

Training your developers on threat modeling, and on the attacks, vulnerabilities, and misconfigurations that are most relevant is crucial if you don’t want to be fully reliant on the application security engineer for everything.

Ideally, developers should be able to create a threat model at least for projects that don’t have a high level of complexity or risk, which helps application security engineers focus on the projects that do have a high level of complexity or risk. This also helps embed security awareness in the culture of the development team.

Training on threat modeling can be added to the developers' onboarding training, as well as performed periodically.

2. Security Champions:

As the number of development teams grows in the organization, communication and cooperation with application security becomes both more crucial and harder. One way to handle this is by building a Security Champions program. Security Champions are members of the development team who have a special role related to security. They should receive special training on security and threat modeling and should have recurring meetings with the application security team.

Security Champions act as advocates for security in their teams, and some of the steps of the threat modeling process can be offloaded to them like identifying threats for projects without a high level of complexity and risk and writing the continuous tests covering the mitigations.

For more resources related to building a Security Champions program, you can refer to the Security Champions Playbook.

Process

We also need to tune the process in a way that best utilizes the scarce application security people and knowledge, and at the same time doesn’t disrupt the flow of things for the development teams. Here are some suggestions to achieve that:

1. Triage and Prioritize:

It is rarely possible to apply the full threat modeling process we discussed in this series for all projects and features being developed. Hence, we need to define specific criteria to select projects that meet a specific threshold in terms of added complexity and risk.

Complexity can be identified by factors such as:

• Are we creating new infrastructure or adding significant changes to the existing infrastructure?
• Are we handling user input directly or indirectly?
• Are we implementing/using cryptography?

Risk can be identified by factors such as:

• Do we have access to read/write customer PII?
• Is the project used for authentication/authorization?

This information can be gathered in a small questionnaire as early as the time the User story is added to the backlog and used to decide on which features need to go through the threat modeling process.

For other features that don’t meet the threshold, we can rely on tooling or custom tests instead of going through the full threat modeling process.

2. Use the same tools the developers use:

We should minimize the introduction of new tools and workflows to the existing process as much as possible when introducing threat modeling as this adds disruption. For example, we shouldn’t ask the developers to change the tool they are using to draw the design diagrams or document the project details. Instead, we should make use of what they are already using, and adapt it to the needs of the threat modeling process.

3. Gather metrics and set SLAs:

An unmonitored process is bound to fail. Hence, we need to gather the right metrics, track them in dashboards, and agree on reasonable SLAs. For example, the threat modeling process generates different categories of action items including fixing unmitigated threats, improving existing mitigations, as well as verifying and creating tests for mitigations, these action items need to be prioritized and should have an SLA for fixing based on the impact.

Technology

Lastly, we need the right tools to make the steps of the threat modeling process efficient, so that the process is free-flowing. Here are some suggestions to achieve that:

1. Use tools for verification and continuous tests:

Verifying the mitigations and creating continuous tests are the second and third phases of the threat modeling process as discussed in the previous stories, and having the right tools to verify and test the mitigations of the most common threats, and having the right people trained (e.g. application security engineers, security champions, and developers) on these tools makes this phase much more efficient.

For example, a SAST tool (e.g. Semgrep) could be used to verify SQL injection is mitigated by parametrized queries, and a configuration checker (e.g. scout suite) could be used to verify S3 buckets with customer data are not public and have encryption enabled, and these tools could be added to the CI/CD pipeline for continuous tests. This is much more efficient than verifying through manual code and configuration reviews.

You can find more detailed examples of the use of tools to verify and test mitigations in story 5.

2. Create frameworks/libraries for common business logic threats:

Tools rarely cover common business logic threats like authorization bypasses. Hence, you may need to create your own custom frameworks or libraries to make it easier to verify and test the mitigations of these threats.

For example, you can create your own library or framework to run different authorization test cases based on the authorization model you use in your application or organization. You can use testing frameworks such as Robot Framework or Jest to create these libraries.

3. Secure by default libraries and templates:

Prevention is always better than cure, that is why making the path of least resistance the secure one is one of the most effective ways to promote security and minimize friction in the threat modeling process.

For example, if developers are using Cloudformation/Terraform templates or AWS CDK to manage the application infrastructure, you can create Cloudformation/Terraform templates or AWS CDK constructs that have the security best practices for the created resource by default, and make sure the developers use these templates/constructs. This makes verifying that these best practices are enabled much easier, as we only need to verify the secure by default template is used which can be done manually or automatically (e.g. through a custom Semgrep rule as discussed in story 5).

The below example shows an AWS CDK construct for creating an S3 bucket with the security best practices such as making it private, enabling encryption, disabling HTTP access, and enabling access logging.

const cdk = require('@aws-cdk/core');
const s3 = require('@aws-cdk/aws-s3');
const iam = require('@aws-cdk/aws-iam');
const logs = require('@aws-cdk/aws-logs');

class SecureBucket extends cdk.Construct {
  constructor(scope, id, props) {
    super(scope, id, props);

    this.bucket = new s3.Bucket(this, 'MySecureBucket', {
      encryption: s3.BucketEncryption.S3_MANAGED, // enable encryption
      serverAccessLogsBucket: logs.LogGroup(this, 'AccessLogs'), // enable access logging
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, // block public access
    });

    // set a bucket policy to deny non-encrypted HTTP access
    const policy = new iam.PolicyStatement({
      effect: iam.Effect.DENY,
      actions: ["s3:*"],
      resources: [this.bucket.bucketArn + "/*"],
      conditions: {
        "Bool": { "aws:SecureTransport": "false" }
      }
    });

    this.bucket.addToResourcePolicy(policy);
  }
}

module.exports = { SecureBucket };

4. Use threat modeling tools for identifying threats:

Lastly, for organizations with a high number of development teams and a high load of new features that need to be reviewed, there are threat modeling tools for automating threat identification which is the first phase of the threat modeling process. Threat modeling tools automatically detect threats and suggest mitigations which helps with efficiency and consistency.

However, keep in mind that as this is the most complex phase of threat modeling, threat modeling tools usually have a lot of misses and false positives. Hence, my suggestion is to use threat modeling tools along with manual reviews not instead of it, or at least only depend on the tools for the features with low complexity and risk.

For example, you can use SDElements which uses surveys for threat identification, and IriusRisk which uses diagrams for threat identification.

Agile Threat Modeling

Conclusion

In this series, we discussed how to use threat modeling to have a conscious approach to security in the SDLC process, and as people with application security knowledge and experience is a scarce resource, we need to make sure we utilize these people in the most efficient way possible for this process to work and not block the progress of development, especially in an agile environment, and as the size of the organization grows.

The suggestions and examples discussed in this series obviously are not a complete list, but they can be used as a reference to devise your own process that works best in your organization. Feel free to reach out if you have any questions or comments. Thanks for tuning in!