All eyes are on you.
The moment you’ve been waiting for has arrived. You’ve convinced your boss that threat modeling warrants consideration. Now it’s time to convince everyone else.
Bosses three levels up the chain, including the VP of engineering, are waiting for you to begin. You feel the piercing stares in the pit of your stomach. What can you say to prove threat modeling makes sense in business, not technical, terms?
Cybersecurity spending is forecasted to exceed $124 billion dollars worldwide. Security is expensive and many security teams are asking for money. How does threat modeling measure up to the other security initiatives vying for budget?
Everyone knows security is necessary. However, it’s difficult to quantify what having secure systems means or how it helps the bottom line, making budgeting decisions difficult.
Many business leaders suffer from a “we haven’t been hacked yet, so we’re okay” attitude. Doubtless Equifax felt the same way. We all know what happened to them.
In practical terms, however, the knowledge that a breach is possible is not enough to make real progress in your cybersecurity program. It’s difficult to measure how secure your systems are right now and where resources are needed to make them more secure in the future.
Threat modeling fills this gap. Continuous threat modeling provides a constant snapshot of the security posture of your applications. At any moment, you’ll know how vulnerable your applications are. You’ll see patterns pointing to architectural flaws that need extra attention.
A continuous snapshot of security gives fast feedback on how your current cybersecurity programs are helping to secure your applications. You know where to invest resources because you can pinpoint where the weak spots are.
Threat modeling measures the effectiveness of developer training. Development teams with similar issues popping up again and again can be retrained to eliminate fundamental flaws.
Your budget won’t be decided by the best middle management pitch, vendor pitch, or industry buzzword. Key security budget decisions are made using real data.
In heavily regulated industries, compliance is a non-negotiable part of the cybersecurity initiative. It’s often a constant struggle and remains in the back of everyone’s mind.
The only way to ensure compliance is to build it in from the start. Threat modeling done right points out exactly which architectures and features are required for compliance with certain regulations. Threat modeling ensures your design is compliant before any code is written.
Once the application is built right, with compliance in mind, you can feel confident during audit time. Your application can be built to enable the day-to-day processes that maintain compliance and provide proof.
When audit time comes, you’ll have everything ready to present to the auditor with the click of a button, saving huge expenses in time and effort.
Compliance-aware threat models encourage and simplify compliance. Use them.
Any business decision comes down to saving or making money (even compliance efforts are saving money by not getting fined).
Threat modeling saves money for the company, giving a tangible ROI in three ways.
You may be surprised at the relative cost of fixing bugs in certain phases of the software development life cycle. It’s quite staggering. A bug that could be fixed for next to nothing using threat modeling could cost you millions if found in production.
There are four main phases of software development: design, implementation, testing, and production (the finished product). Fixing bugs in the design phase is much cheaper than in the other phases.
It costs 6 times more money to fix flaws found in the implementation phase of software than the design phase. It costs 15 times more to fix bugs found in the testing phase.
It costs 100 times more to fix bugs found in production than those found in design. Let’s illustrate these differences.
Let’s say you have a traditional meeting for a threat modeling session with a software architect, 3 developers, a project manager, a security expert, and a compliance expert. The average hourly cost for these experts is $80 USD. If the meeting is 3 hours long, you’ve spent $1,680 USD to hold this meeting.
Let’s say you found 10 major problems with the architecture in those three hours. You’ve only spent $168 USD per bug to fix them. The beauty of the design phase is that there is no code to change yet.
Without the threat modeling meeting, you could find these 10 bugs in either implementation, testing, or production. What’s the cost if you did?
For the implementation phase, you’ll pay $1,008 per bug for a total of $10,080 to fix these bugs.
If found in the testing phase, you’ll pay $2,520 per bug for a total of $25,200 to fix the bugs.
If you find the bugs in production, you’ll now have to pay $16,800 per bug, for a whopping total of $168,000.
This growth rate is huge. For an application with one million lines of code, assuming 15 bugs per 1,000 lines of code (per the great book Code Complete), you’ll be looking at a total of 15,000 bugs. Using these numbers, the difference in cost between finding the bugs in design and production is $2,520,000 in design vs. $252,000,000 if found in production.
If you don’t find the bugs and they are exploited, resulting in a data breach, imagine the cost not only to fix the bug but in fines and lost revenue.
Is threat modeling worth the investment now?
When budgeting time comes, everyone has the next best idea. Many middle managers vie for a piece of the budget pie to implement a pet project. Vendors are knocking down your door to get you to sign on the dotted line. How do you find the best way to allocate the limited money available?
Threat modeling gives you a constant snapshot of your current security posture. This snapshot allows you to send money where it’s needed most, not based on a slideshow or product demo, but based on real data.
A continuous threat modeling system allows you to see what weak spots exist in your applications. Development resources can be put toward reinforcing weak areas. Testing budgets, both internal testing and external penetration tests, can be focused on the most critical areas. Instead of spending huge amounts of money testing a rock solid design, test the areas of concern to flush out vulnerabilities before they cause real damage to your customers and company.
Money is a limited resource. Use threat modeling to allocate the right amounts toward the areas that need it the most. Use real data to make sound decisions, not buzzwords or manager presentations.
Coding errors are not the only source of bugs. Many come from the architecture of the software system itself. Poor design or mistakes in design can lead to major flaws that allow bad guys to bypass basic security measures.
Architecture flaws are also incredibly expensive to fix, since it is the software equivalent of fixing a foundation after the house has been built. You’ll be moving around so many parts that it’ll be difficult not to affect other pieces of the system in a negative way. And vulnerability scanning tools, like DAST and SAST tools, aren’t built to find fundamental flaws in architecture.
Threat modeling identifies major architectural problems before they lead to a security breach. Breaches will cost the company dearly in fines and damages, not including the work needed to fix what caused them (which we’ve already shown to be very expensive).
The bottom line: A few hours of threat modeling will likely save you thousands of dollars or more down the line.