Craft an effective application security testing process
For many reasons, only about half of all web apps get proper security evaluation and testing. Here's how to fix that stat and better protect your organization's systems and data.
Whether it's business, relationships or IT, expectations are everything. People like to be kept in the loop. They need to know where they are and where they're headed. Every aspect of society and human interaction depends on communication, and when communication breaks down, bad things start happening. Application security is no different.
One of the greatest oversights in terms of an application security testing process is a lack of information. By this I mean, specifically, information as it relates to development and source code; performance and security monitoring and alerting; and, most importantly, not knowing where things stand in terms of application security posture.
Based on what I've seen in my work, only half of all web, mobile and client-server applications are being properly evaluated for security risks. Of the ones that are subjected to application security testing, easily half of these tests are not being done properly. Even though adequate application security testing is hard to come by, those who take this aspect of information security seriously ensure that decisions made will be based on good information. This must start with the app security scoping process.
How best to launch an application security testing process
If you're going to properly test your applications for security vulnerabilities and fully understand how they're affecting your business, there are three things you must do:
Know which applications you have that need to be tested. There are probably more than you think.
Understand what the specific requirements are for the application security testing process -- a common unknown that needs to be discussed.
Perform the testing to the best of your abilities using known methodologies and proven tools. If you have little or no application security expertise in-house, outsourcing this function is the only way to go.
Tenable CEO Amit Yoran discusses 'cyber-helplessness'
Before any security testing takes place, you must make sure that everyone's on the same page in terms of needs and deliverables. Every situation is different. However, if you consider the following questions for every application security test you perform, it will ensure that your focus and attention are where they need to be:
What, specifically, will be tested? This should include, at a minimum, websites and applications, web services and any underlying hosts. Be sure to include any traditional client-server software as well as mobile apps if they're part of the environment.
Will authenticated testing be included? Sometimes a true outsider's perspective is desired. However, there's a ton of value in performing authenticated security testing of applications, as that's where many of the vulnerabilities, including SQL injection and session manipulation, are found.
What tools will be used? It should be more than basic network-centric vulnerability scans and include web-focused vulnerability detection tools such as Netsparker, Acunetix Vulnerability Scanner and Burp Suite Professional. Looking beyond traditional testing and at the actual source code, a tool such as Veracode and NowSecure can be invaluable.
Will testing be against the production environment or a test environment? Some people want the former since it outlines specifically where things stand. However, others would prefer the latter given the risks associated with performance impacts, data insertion and manipulation, and the like.
Will security controls such as firewalls, web application firewalls and intrusion prevention systems be disabled, especially if throttling or blocking takes place? I'm of the belief that unless you are simply testing your security control or incident response capabilities, you need to disable these systems or otherwise whitelist the testing source IPs if you want to get the most value out of this work.
When can testing take place? Occasionally, limits will be placed on when automated vulnerability scans can be run due to any potential performance hits.
What information will the final report contain? Interestingly, some so-called professional security testing organizations will deliver nothing more than vulnerability scanner or source code analyzer reports, and the end client is left to decipher what needs to be addressed and how. I have found that most clients prefer to be guided in terms of which findings to focus on and which ones don't matter as much.
Will remediation validation testing be included to determine which higher-priority findings have been resolved? It's always nice to know which vulnerabilities have or have not been resolved.
Answering these openly and honestly will ensure that you and management together understand not only what's being done but also what will be delivered. This will help ensure that the necessary follow-up actions will be taken in a timely manner.
Why application security tests get skipped
Today, because of privacy and security regulations and lawyers, due care and defensibility are the name of the game.
Over the past two decades, when it comes to application security tests, I've seen countless web applications, mobile apps and client-server programs skipped. This happens for many reasons but is usually one of the following:
It's assumed that someone else, such as a cloud or SaaS vendor or hosting provider, is doing the proper vulnerability and penetration testing or that they are responsible for any security exploits that occur.
Security teams believe testing won't do any good because vendors are no longer supporting the software or there's no perceived way to fix any flaws that are uncovered.
If security vulnerabilities are never acknowledged then no one knows about them and, therefore, nothing needs to be done. (I don't know whether this is a situation of "ignorance is bliss" or plausible deniability, but either way, it's bad for business.)
Make sure that you and your team are doing what's necessary to pull application security into the overall business risk equation. Critical software translates into critical business risks. Find out what's needed to scope the appropriate application security testing process -- now and moving forward. If no one is asking about or otherwise requiring application security, then it's up to you to ensure that you have a good inventory of your application environment. Starting with your most critical systems, you simply go down the list until all of them are being tested on a periodic and consistent basis.
Unfortunately, today, because of privacy and security regulations and lawyers, due care and defensibility are the name of the game. But you can play that game as well as anyone else. Just make sure you're practicing and keeping your skills sharp. This is a game you don't want to lose.
