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?
Each time you see such a prompt, what do you do?
I’m a highly technical security professional and I’m not even sure what I should 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. What we really do is get ticked off at the interruption, then immediately click whatever button will let us continue whatever it is we were trying to do.
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!” Later, when an actual wolf shows up, nobody believes the boy.
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.
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 run one or more tools to get a list of results, then work on making corresponding fixes in the source code.
Security teams, which are keen to minimize risk, want to run as many tools as they can and then have development teams plug as many holes as possible.
Development teams, which 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.
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 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 in which 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.
By Jonathan Knudsen