Authored By: Jonathan Knudsen, Senior Security Strategist, Synopsys Software Integrity Group
Psychologist Abraham Maslow wrote, in 1964, “Give a small boy a hammer, and he will find that everything he encounters needs pounding.” This is commonly rephrased as “if you have a hammer, everything looks like a nail.”
This applies especially well to doctors and surgeons — they want to do the thing that they know how to do, whether that is prescribing pills or performing surgeries. Even when your particular situation and symptoms don’t exactly match the conditions that they treat, they’ll still be inclined to do the thing that they know how to do, just because the alternative is saying either “I cannot help you,” which no doctor wants to say, or “I do not understand what is going on with you,” which no doctor wants to say.
It applies equally well in the technology world. People tend to latch on to the latest shiny new technology as the way to solve many kinds of problems. It is easy to get swept away by the enthusiasm of the latest movement while forgetting about the more mundane aspects of your life or your business. In the domain of application security, it’s easy to get swept up in shiny new tool features, and indeed, exciting things are happening.
Sometimes you just need a knife
Developments are exciting and point to the future of application security. But you have to take a holistic look at your application security to understand what you really need. If you need something to spread cream cheese on your bagel, you don’t need that fancy light sabre; a butter knife might work fine, or you might consider something a little more specialised like a cheese spreader. Nevertheless, it is important to keep in mind the realities that are in front of you now.
If you need to improve your application security, begin by concentrating on fundamentals. You need to find vulnerabilities so you can fix them, and you need to integrate security to your existing processes for minimal disruption. Many development groups have a workflow based around issue tracking software; a good first step for application security would be automated runs of security tools in the build and test cycle, with results integrated into the existing issue tracker.
For engineers, it is easy to slip into a mindset where application security is all about the tools you run, but this is an illusion. The reality is that application security is as much about policy and process (not very exciting) as it is about tools (fun!).
Start with an application security policy and process
The right place to begin is with policy. Writing application security policy forces you to think about the way things should be—what design-time activities must happen, what education you provide your engineers, what kind of testing applications you must use, and what kinds of results are acceptable.
Once you’ve settled on policy, you can start building the application security processes that will get you there. At this point you can get more specific about tools, how they are automated, and how they integrate to existing components in your processes. It is important to select good tools, but always choose them to fit into the framework of your policy.
Stay on target
No matter what shiny new tools are available, your policy guides how you implement application security. The end goal is risk reduction—get the tools that help you achieve the goal and put them inside the framework of your existing processes so that application security is inseparable from development.