Application security testing is an essential part of a global security strategy but if it is not done the right way it can poison your progress.
Below I’ll explain the mistakes to avoid in order to test all your applications, find and fix the flaws whilst still creating a global application security programme.
In most cases companies believe that testing their most critical apps for vulnerabilities is the right way to go, but in fact most breaches occur because of a vulnerable legacy app that is dormant. There are many real life examples, like the JP Morgan Chase, where a breach occurred due to a vulnerable charity donation website. This website had not been used in a year, yet still access to the corporate database!
Yes, you are right, MPT may find the logical flaws in applications, but it is absolutely impossible to scale manual pentesting. This would only work for a few applications otherwise you need an army of pentesters to test all your applications all of which costs a lot of time and money. This forces companies to only test their most critical apps, leaving hundreds unassessed and thus vulnerable.
Software today is a composition of many different things. The biggest parts of applications today are open source components or pre build libraries. Do you know if they have known vulnerabilities? It should always be a priority to check third party components of your software. A very famous third party library for example is OpenSSL and I bet you remember the HeartBleed and Freak vulnerabilities!
Do you only test you own build code? Do you blindly trust your software vendors that they build secure code - all because they say they do? All software you buy should go through the same process your own goes through.
Once the software is breached it’s too late. Who will you blame it on? It’s your company’s data and reputation that’s already lost.
If companies won’t train their developers they will make the same mistakes again and again without even knowing it. Software development normally is driven by deadlines not by security, therefore a good security knowledge in the development team is essential to build secure applications at speed.
Whenever you consider testing your software for security it also is mandatory to find a way to integrate this process into your SDLC. Developers tend to work in their environments and don’t want to learn new tools in order to test their software. You need to catch the developer in their usual workspace and offer plugins for the tools they already use. Only in this case developers will efficiently integrate into this process and run necessary test as needed.
On premise solutions are so 90ies! Compensate cloud-fear with an effective security approach like data encryption, access control, running applications in memory not on hard disk and several others. Do you really want to add more boxes to your network forcing your infrastructure team to manage even more hardware? Do you want your network security team to manage more outgoing connections in terms of updating? Are you sure the box can handle the amount of scans you are planning? A cloud based solution will not face a single question like this, as it just runs outside your network, automatically scales and no infrastructure or network security will ever be involved.
Especially for large enterprises it should be a high priority to build a full, global application security programme. It doesn’t make sense to have dedicated silos in different countries or even in different development teams. Some developers using tool X, other using service Y and the rest maybe Z. Either management has to hire another overlaying team to manage all of these different types of solutions and services or they have to run results on their own. This means they’re spending an enormous amount of time getting the different data aligned. Why not rely on the same tool for everyone and having an application security programme management service attached to it that helps keep the programme running and delivers the right statistics and reports?
The biggest problem in application security and the one slowing down the progress is the false sense of being secure. You never will be secure, even if you implemented all above, you always need to adjust from time to time to fit new requirements, new attack vectors will be discovered over time or new programming languages are introduced. So only by living the above and continuously evolving will get you the most out of your applications security efforts.
Always ask the question – did I do everything I could to secure my applications?