Even if an application has been built following security and defensive coding best practices, it will still require significant testing before it's ready for release.
Whether this is routine testing for common vulnerabilities or security-focused penetration testing to pick up on the types of problems that often slip through the cracks, following security best practices will help your dev team find and fix problems before the deployment phase of the SDLC.
Today I'm looking at six best practices for security testing your application.
1) Look for What Isn't There
With security testing you are more concerned with finding functionality that isn’t supposed to be there, rather than with specification-based testing which makes sure your code does what it’s supposed to do.
Instead of testing that your application delivers the anticipated outcomes, you will be looking for unexpected side effects or behaviors that aren't specified in the design. This will help you identify hidden vulnerabilities that could be exploited by anyone trying to gain access to your application’s data.
2) Test Outside of Public Interfaces
Security testing can all too often be a matter of forcing as many inputs through an application’s API as possible. However, the inputs that arrive to an application through its API and other public interfaces are far outnumbered by those that arrive from the network and file system.
Therefore, it’s much more important to test inputs that aren’t coming from public interfaces as this is the first place that attackers will look for a "way in" to access your sensitive data.
3) Static Analysis
Static analysis inspects code at rest – without executing the program. It allows developers to perform a thorough inspection of every aspect of the software's source code, in order to identify any flaws or back doors that will make your application vulnerable to attack.
Static analysis tools, which read through your software code, can be programmed to look for clues that point to vulnerabilities that your developers may not have identified during code reviews.
4) Dynamic Analysis
Dynamic analysis is the natural follow-on from static analysis. Dynamic testing is performed in a runtime environment, with security analysis carried out while the application is in operation. Dynamic analysis can reveal vulnerabilities and flaws that may be too subtle or complicated for static analysis to pick up on.
Dynamic testing tools can uncover hidden problems like memory manipulation or file access that don't appear in plain view in the application's API.
5) Test the Deployment Environment
A single misconfiguration or mistake in the setup process can render an otherwise secure application vulnerable. Therefore, it is vital to check for configuration errors before deployment.
If you're deploying an application to a server, you will need to check it for security. You will want to scan the server for open ports, review configuration files, and ensure that attackers can't gain access to sensitive files or directories via the server.
6) Test Incident Response Procedures
Don't wait until a security breach takes place to find out if your incident response procedures are up to the task. By running breach simulation exercises with any high-priority vulnerabilities identified during security testing, you can test your organization’s reaction to fixing the problem and developing and implementing the security patch.
This means that if a serious breach occurs after deployment, your organization will be well practiced in incident response and remediation.
