How to Cyber Security: Application security is critical for data security

Apr 13, 2020 / 5 min read

Table of Contents

Two meanings for ‘application security’
Data protection
Threat modeling: Thinking sad thoughts
You must always manage vulnerabilities
Take a step back

Two meanings for ‘application security’

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.

Application security can refer to features (sometimes called controls) that protect the confidentiality, integrity, and availability of the application. For example, an application that encrypts its data provides some protection for confidentiality and integrity.
Application security might also refer to managing vulnerabilities that are present in an application. From this standpoint, application security is about minimizing risk by finding and fixing as many vulnerabilities as possible before application release.

Most of my time is spent talking about managing vulnerabilities, with special focus on finding vulnerabilities. Black Duck 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.

Data protection

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:

Computers and the internet make it drop-dead easy to quickly copy any type of information all over the planet.
The internet is not a secure network. Information flows through it on the digital equivalent of postcards, where it can be read at any intermediate point.
Software security is not understood well. This means that people implementing software systems sometimes make catastrophic errors, such as storing unencrypted sensitive information in publicly accessible cloud storage without any access control.
Software systems are large and complex. Complexity provides many dark nooks and crannies where vulnerabilities can live. Without a disciplined approach to application security, serious mistakes might go unchecked.

Threat modeling: Thinking sad thoughts

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.

Data Protection Threat Modeling and Vulnerability Management Diagram

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:

Because an attacker might eavesdrop on the network traffic between the mobile client and the server, we’ll encrypt the traffic using TLS.
Because we don’t want an unauthorized attacker accessing our service, we’ll require authentication.
Because an attacker might brute-force passwords, we’ll implement an account lockout feature and throttle log-in request speed.
Because an attacker might gain access to our database, we’ll encrypt the contents of the database.

If you don’t have the expertise or the time for threat modeling, Black Duck has experts that can help.

You must always manage vulnerabilities

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.

Data Protection and Threat Modeling for Vulnerability Management in Software Security

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.

Take a step back

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.