Data protection requires application security. Threat modeling and vulnerability management help you secure your apps from development through production.
What’s in a name?
Software security can be confusing. People use the same words to mean different things, or different words to mean the same thing. A deep technical understanding eludes many of us, and the industry has no shortage of people who will sell you something shiny that is supposed to solve all your problems.
Even the words “application security” are overloaded with two distinct meanings.
Most of my time is spent talking about managing vulnerabilities, with special focus on finding vulnerabilities. Synopsys makes security testing tools that are good at finding vulnerabilities and offers security consulting services to help organizations start or evolve a software security initiative.
As it happens, both meanings are important to ensure data protection. Let’s look at why.
Software systems handle all kinds of information, from instant messages to medical information, intellectual property, nation-state secrets, and everything in between. Information has value, and so part of the challenge of designing and implementing a software system is implementing data protection. This means making sure that access to the information is limited to people or systems that are authorized.
Unfortunately, the nature of modern computing makes the goal of data protection difficult, to say the least:
We know that cryptography is good at protecting the confidentiality and integrity of information, and we know that two-factor authentication is good at preventing unauthorized access. These techniques are security controls. But how do you know when to apply the controls?
The answer comes from the design phase of the secure development life cycle. Specifically, the activity of threat modeling helps you figure out how to apply security controls to maximize the security of your system.
Threat modeling is a fancy name that really means “thinking about all the things that could go wrong.” The goal of threat modeling is to create a traceability matrix, which is a list of threats and the controls that will mitigate the threats.
You start by creating a diagram of your system and its data flows, imagine how an attacker might approach your system, and think about how to make those attacks more difficult.
A variety of threat modeling approaches are available, with funny names like LINDDUN and PASTA, but the grandpappy of them all is STRIDE, which was brought to prominence by Adam Shostack when he was working at Microsoft.
Working through this design-time exercise will give you a list of security features that you would like to have in your application. Here are a few simplified examples:
If you don’t have the expertise or the time for threat modeling, Synopsys has experts that can help.
The secure development life cycle spans the entire process of creating software, from design through to maintenance. Threat modeling helps you analyze your design and make sure that appropriate application security controls are in the appropriate places.
The other meaning of application security, managing vulnerabilities, is no less important. Whatever cycle you have in place for building and testing your application, it needs to be augmented to include security testing. I’ve discussed these tools previously—source code analysis, software composition analysis, and so forth—but the key thing is to automate the tools and to integrate the results into your normal workflows.
Security testing helps prevent a cruel paradox of application security, when vulnerabilities in a security feature end up making your application less secure.
As a simple example, consider a log-in form on a web application. Let’s say you did your threat modeling and decided that authenticating users was an important security control. However, when your developers implemented the form, they created a SQL injection vulnerability, which allows attackers to control the database.
You might have done your threat modeling correctly, but if you are not also incorporating security testing to manage vulnerabilities, embarrassing problems like this can happen.
If you’re deep in the weeds, working on getting a security testing tool integrated into your workflow, it might be hard to see the bigger picture sometimes. Don’t forget to take a step back once in a while to make sure you’re working on the full spectrum of the secure development life cycle. This means working with both meanings of “application security.”
On the one hand, perform threat modeling when you are designing new systems or new features for applications. This will allow you to think like an attacker and include security controls (features) that will make attacks difficult.
On the other hand, remember that finding and fixing more vulnerabilities before release is a surefire way to reduce your overall risk. Work on automating and integrating security testing into your application development to help your development teams produce higher quality, more secure software with minimal friction.
Jonathan Knudsen likes to break things. He has tested all kinds of software, from network infrastructure and medical devices to cryptocurrency nodes. Jonathan has worked as a developer, consultant, and author. He has published books about 2D graphics, cryptography, and Lego robots, and has written more than one hundred articles on a wide range of technical subjects.