How to cyber security: Addressing security fatigue

Addressing security fatigue with small changes to your AppSec strategy can help you manage and minimize risks in your applications. 

How many times a day does something like this happen to you?

Is it 10 times a day? 25? 100?

I’m a highly technical security professional and I’m not even sure what I should do. What is PC-Doctor? What is SystemIdleCheck.exe? If I click No, will something not work the way that I want it to work?

Each time you see such a prompt, what do you do?

You’d like to say that you read the prompt carefully and consider all the possible implications before proceeding. You’d like to say that you do some additional research to verify that proceeding is safe.
But let’s be honest amongst ourselves. What we really do is get a little ticked off at the interruption, then immediately click on whatever button will continue whatever it is we were trying to do.

The software that cried “Wolf!”

This is the modern analogy of the old story about a shepherd boy who thought it would be funny to get everybody riled up by yelling “wolf!” He tries it out a few times, amused by the ensuing panic. Later, when an actual wolf shows up, nobody believes the boy. The wolf makes a meal out of the boy’s sheep, and depending on the version of the story, the boy himself.

The difference is that your software is not just stirring up trouble. Nevertheless, evaluating the risk that is presented to you is often difficult.

Suppose you visit a website and your browser complains about the certificate. Has someone hijacked the website? Is something not configured quite right? It’s nearly impossible to know, and your choices are (a) forge ahead, hoping that nothing is seriously wrong, (b) don’t do whatever it is you wanted to do, or (c) try again in a day or two to see if it’s resolved.

For most people, (b) and (c) aren’t good choices and so, in general, we tend to ignore security warnings and hope for the best.

This is security fatigue.

Vulnerability overload

A similar phenomenon happens in the world of application security. Development organizations that are new to software security often see application security in terms of tools. They will run one or more tools to get a list of results, then work on making corresponding fixes in the source code.

Security teams, who are keen to minimize risk, want to run as many tools as they can and have the development teams plug as many holes as possible.

Development teams, who are keen to ship code, want as little disruption as possible to getting their code into customers’ hands.

The problem is that security tools can produce too many results. Faced with a mountain of reported vulnerabilities, development teams are likely to throw up their hands in despair and ignore security results altogether. This is vulnerability overload.

Prioritize security issues

Huge problems, like global warming or gun violence, can seem unsolvable. In the case of application security, the sheer scope of the problem can be daunting, like some sadistic mathematics word problem: “If the developers have 2,377 findings from four different security tools, and five days to prepare the application for release, what should they do?”

Progress is achieved in small steps, not by changing everything at once. Security findings can be prioritized in a variety of ways, which means you can sort your pile of issues by risk and start working on the most dangerous ones.

You can use a similar approach to ease security into the development workflow. Instead of dumping every finding on the development team, you can implement a policy-based approach where certain types of security findings are automatically integrated to the development issue tracker. If the volume of issues is reasonable, developers will adapt and improve security just as they address any other issue.

Developers don’t like repeating work. Once they have grasped a certain type of security weakness, they will be less likely to repeat it in the future.

Small steps toward a better application security strategy

Paradoxically, one of the reasons humans hesitate to tackle tough challenges is that they believe it is hopeless, that nothing they do will make a difference.

The only thing that is certain is that nothing will change if we don’t try.

If you want to improve the security of your application, do something. Start somewhere. Consider adding threat modeling to your design process. Run a static application security testing (SAST) tool like Coverity® on your source code, and make a small, achievable commitment to address the findings with the highest risk. Use an interactive application security testing (IAST) tool like Seeker® on your web application and make a small, achievable commitment to fix the findings with the highest risk.

Integrate security tools so that findings are addressed just like any other issues in the issue tracker. Make security a part of everyday life on the development team.

Start small, then increase slowly. Celebrate your wins and learn from your mistakes.

Application security is inseparable from application development. Take one step at a time until you achieve the risk levels your applications need.