Threat Modeling for Web Developers

I’ve met developers who love application security and want to do their best to write secure code and keep users safe. I’ve met others who don’t care about security. “It’s someone else’s job and they’ll let me know if I need to fix something.”

The latter thinking is like not locking your doors at night and saying, “Keeping me safe is the police officers’ job. They’ll let me know if my house got broken into.” By that time, the damage has been done.

No amount of security testing, automated or otherwise, will find all security vulnerabilities. A vulnerability left in the wild could be how the attacker steals your data.

Threat modeling gives you the tools to find problems before any code has been written. For the sake of your user’s safety and your company’s reputation, let’s look at what threat modeling is, why you should care, and how to implement it, even in agile environments.

What is Threat Modeling?
Threat modeling is the practice of examining the design of a software system to find possible security problems. The purpose is to anticipate how an attacker would compromise an application.

Finding vulnerabilities early in the development lifecycle allows you to build protections into the code from the start. Taking a little time upfront to find possible vulnerabilities may save lots of money down the road.

There are four basic questions to address during threat modeling:

What are we building?
What can go wrong?
What are we going to do about it?
Did we do a good job?

This process doesn’t have to take a massive amount of time but will make your software much more secure when you do it consistently.

Why Web Developers Should Care About Threat Modeling

‍
Threat modeling is great, but isn’t threat modeling something the security team should handle? Why should developers care about threat modeling?

Code quality is important to many developers. You create unit tests to make sure the code works according to the requirements of the business. You build code that’s easy to maintain.

A mindset shift may be necessary to accept the fact that secure code is good code. Security is part of code quality in the same way functional requirements are. Your duty as a developer is to the users of the system as well as to the company building it. Keep them safer with threat modeling.

Building new functionality is fun, going back and constantly changing old functionality is not. When security is handled up front, you build things right the first time. You don’t have to go back later to keep fixing problems with existing code.

Fixing problems in the old code is not only boring but can lead to the code rotting over time. Constantly placing band-aids on gushing security wounds will mean always playing catchup and being left with an unmaintainable codebase.

When web developers embrace threat modeling, it helps to build strong relationships between development and security teams. Good relationships are becoming more important as security is joining the “shift left” movement and becoming a key piece of the application build pipeline. Security and development teams must work together to create repeatable processes that lead to secure software without getting in the developers’ way. This can’t happen if the developers don’t care.

Finally, web developers who participate in threat modeling will learn important security skills. The ability to imagine how an attacker could attack your application or ways for the users to abuse it is an invaluable skill. Again, it’ll allow you to build things right the first time, making you an extremely valuable developer for your company.

What If We’re Agile?

Some may believe threat modeling takes too much time up front to work in an agile environment. Agile methodologies focus on getting functionality out quickly and iterating on it. Is agile methodology compatible with threat modeling?

Yes, it is. How threat modeling is done may need to shift slightly, but it’s possible to use the principles of threat modeling with agile practices..

If you use user stories or Kanban tickets, make threat modeling a task and acceptance criteria on every task. It may not be necessary every time, but it should be consciously removed instead of forgotten.

Any changes to the system could introduce security problems. Including threat modeling in every story encourages developers to think about how they implement new functionality. Create a simple design to fulfill the requirements, then look for possible threats within that new functionality.

Part of accepting a piece of code is understanding the risk it may bring to the organization. Acceptance of the story by the business should only occur after someone has thought about the possible risks associated with the code change.

Large threat modeling meetings aren’t necessary for every small code change. Developers should be trained enough to spot glaring security problems in their code. Save large meetings for major architectural changes and bigger reviews of the system (perhaps every few sprints). Only invite the people who are absolutely necessary to the threat modeling meeting so others can continue working on their stories.

Not every developer will be a security expert. Assign security champions and security team liaisons to help development teams when needed. Having a security expert on hand can increase confidence in developers tasked to assist in threat modeling. Developers can ask for help when they find something that may be a security vulnerability in their code.

Any agile and DevOps environment requires tools and automation to function. Using the right tools to provide continuous threat modeling functionality will allow developers to stay on top of problems their code changes may introduce. The right tools will reduce the need for traditional threat modeling meetings.

‍Start Threat Modeling Your Applications Today

‍
Threat modeling sounds like a good idea, but how do you get started? You can get started today learning more about threat modeling and driving its adoption in your company.

First, make it known you want to learn about security. The security team will throw a small reception for you and gladly welcome you. Developers who care about security are immensely valuable to their companies.

Once you have the security team’s attention, suggest threat modeling if they don’t already do it. Give them the tips above on how to incorporate threat modeling into agile environments. Tell them what gets in your way as a developer so you can work together to solve your problems.

The security team can get a head start on threat modeling with your help. Start diagramming the data flow of your system. You know it better than anyone. Taking the first step will move your company toward threat modeling.

Sign up to our community version and start threat modeling today! If you would like to see a full demo of IriusRisk you can download our Secure Design Webinar for free, or alternatively, if you would like to talk to our team for a custom demo of IriusRisk get in touch.