Security testing is an essential part of application development. Issues that appear as security vulnerabilities are often a product of poor code development, and testing helps identify such vulnerabilities early on in the application development process.
Yet, security testing can be expensive, and security leaders often find it difficult to justify its cost. Senior management may feel they are spending money to fix issues developers caused, or at least should have caught.
In contrast to common perception, application security testing doesn’t always have to be a heavy investment. Here are seven tips that security leaders can consider to create an effective and efficient security testing program without breaking the bank.
Include security experts at the start of development
Early testing minimizes the cost of fixing software defects. Including security experts at an early stage of development helps identify security gaps and remediate risks. Organizations can avoid remodeling and remediation efforts if threats are mitigated at the very beginning of development.
RELATED CONTENT: Developers take a larger role in security
Threat modeling is an expensive exercise, but in many cases it can be done internally with free downloadable software. This is not restricted to new applications and can be extended to existing software, too. Especially when existing software is being repurposed or exposed as web services, a structured assessment of the risks and scenarios where an application can be attacked offers the opportunity to create test cases.
Select affordable testing options
In scenarios where budget constraints are a big hurdle to security testing, teams can benefit from affordable and open-source options. While these alternatives are often incomplete in terms of language, framework and vulnerability coverage and functionality, with the appropriate customization and plug-ins, they can enable an effective application security program with minimal resources.
Such free software doesn’t come with enterprise functionality such as dashboards, comprehensive reporting, distributed scanning sensors or plug-ins to integrate into the software development life cycle. However, internal experts can fill this gap by writing their own scripts, or they can operate the tools manually where needed.
Use security testing services for a jump-start
Application security testing services and penetration testing can seem expensive. When considering an investment in these services, present the costs not simply as a service, but as a source of security expertise. The more application security knowledge you can transfer into your development teams, the more likely these teams are to produce higher-quality code.
Involve developers in the testing process so that they can produce high-quality code once they understand the possible threats. Assign one of your developers to shadow the pentester or application security testing service, or have your developer manage the program.
Gartner research suggests that developers in this kind of program are prone to make significantly fewer security errors. These developers can also act as subject matter experts or security champions and identify issues more quickly for the team in the future.
Reevaluate security techniques on a periodic basis
As the program matures and as new styles of coding and new technologies are introduced, vulnerabilities evolve. Plan for this by scheduling periodic evaluations of security techniques in practice. For example, if you have an application that is mostly in maintenance mode and requires mostly cosmetic changes, move resources from code scanning into pentest.
Periodic testing is often wrongly perceived as a cost-draining process. However, semiannual or quarterly reevaluation of priorities can optimize resources and ensure that development and security teams are familiar with all the tools.
Rotate testers and apply time limits
Gartner research suggests that the number of threats found by a security tester reduces gradually over a period of five weeks and significantly declines after eight weeks of running code. This doesn’t mean that threats have been reduced. Because the tester is viewing the code multiple times, fatigue sets in. This can be a problem with critical sections of code or software, especially when the full functionality of the code may not always be tested or exercised.
Rotate testers and apply time limits to prevent overfamiliarity and burnout. Introducing code testing to a fresh set of eyes can help identify vulnerabilities that someone who has been working on the software for too long may have overlooked.
Avoid wasting paid testing hours
Under-preparedness is not new to the testing environment. Often when consultants arrive to begin testing, they are not fully briefed or prepared for the kinds of tests that have been requested. This causes delays in testing, less accurate results, and lower productivity for development teams and pentesters.
Prepare for testing ahead of time by meeting with vendors and discussing the types and scale of testing you want to conduct, and preselect areas of code, infrastructure and processes that are identified as gaps in overall testing coverage. Use external testers to find business logic errors instead of the more “low-hanging fruit” types of issues that your internal testing can uncover.
Be flexible when scheduling opportunities for testing
Rolling out testing changes to a small population is a common practice within DevOps organizations. As these tests are performed in a controlled environment, it reduces the risks of exposing the entire organization to threats. Consider planning for canary or A/B testing during breaks in normal business hours, such as weekends and holidays. Another option is to set up parallel environments for security testing.
