CIOs may think that getting software and applications to market faster is the key to aligning with business objectives. To do so often comes at the expense of thorough security testing, which can reflect in reputation, revenue and customer or end-user satisfaction.
Now is the time for CIOs to start thinking seriously about using quality assurance (QA) professionals to gain a competitive advantage by going on the offensive with security testing. QA can add some needed chops to security testing and help fill the skills gap many companies are facing. The 2017 DevSecOps Community Survey found that developers often outnumber AppSec professionals by 100 to one. This indicates a lot of software development, which results in a growing need for additional security testing.
According to the Building Security in Maturity Model (BSIMM) Version 8, “…improving software security almost always means changing the way an organization works—something that doesn’t happen overnight.”
If you rely on software to succeed in business, you need a set of people in your company focused on software security. Network security people are not the right choice. You need people who understand software and applications. Because software security people are in short supply, it can be a boon to augment your security testing team with QA software testers who are the subject matter experts on your apps—from the front end and the back.
Eight iterative steps to security maturity in the SDLC
Security testing as related to pre-release testing is focused on finding vulnerabilities in the construction of your software. It works best when integrated with your QA process. It also is more successful when led from a top-down approach by the CIO’s office.
BSIMM data finds that successful security testing outcomes depend on an executive champion. This is the most common placement for software security groups within the organizations that participated in their latest research.
The following eight steps will help you achieve maturity at your organization:
1. Moving to the edge
Software testers are already probing with edge and boundary tests. It’s simply an extension to have them begin to move beyond functional testing to basic adversarial testing. There really aren’t any special skills involved that testers don’t already have, but rather a change in perspective that promotes thinking like the “bad guy.” For example, what happens when you enter the wrong password repeatedly?
2. Based on requirements
QA testing uses requirements for software development to test features. The same is true for security requirements and features. The requirements for security features such as account lockout, transaction limitations, authentication and user privileges can all be tested based on the security requirements defined by the software architect for development.
3. Black box testing
Black box security testing tools can be run by testers as part of the QA process. They may need help from trained security testers to interpret the data accurately, but the work of the testing can be done by your QA team, reserving the limited resources of your security software testers for the more important work of deriving insights into vulnerabilities from the data.
4. Security is a natural extension for DevOps
The nature of continuous integration (CI) and continuous development (CD) already includes testing as a part of the cross-functional team. Sharing this information across the team can lead to using the results of security tests to inform and evolve particular testing patterns.
5. Security test automation
Automation frameworks for testing are the same whether used for QA or for security. By running functional and security tests in parallel on your QA automation platform, testers can identify abuse cases earlier in the SDLC. This also serves to make security testing part of the QA routine. Testers may also see creative ways to evolve functional tests into security tests.
6. Apply architecture analysis
An analysis of the architecture of an application should determine the critical dependencies for security. Testers can then focus on testing the highest risk flaws first. If, for example, interrupting a transaction partway through introduces a vulnerability, then testing for torn transactions should be designated as a high priority for security testing.
7. Expand code coverage
While black box testing is necessary, it doesn’t exercise a lot of code. Testers focus on the depth of testing across code. Using standard measurements such as function coverage, line coverage or multiple condition coverage can help to ensure that a majority of your software code has been test explored.
8. Apply the attacker’s perspective
As your testers become more adept at security testing, they can begin to build a library of test cases based on abuse cases by thinking more like threat actors. Adversarial testing will evolve from the basics they began to apply at the edge to replicating attacks based on your organization’s history. In this step testers make the transition from testing features to attempting to break the software under test.
What level of maturity is your security testing?
It’s important to look at security testing as more than a necessary evil or a formality that must be performed with the least impact to time to market and revenue. Improper testing can expose your organization to costs that far outweigh the costs and commitment to make security testing a priority.
CIOs need to ask themselves how their teams are tracking security testing to ensure that thoroughness is achieved not only during pre-release, but is an ongoing process with each update and version release. Incorporating security testing into your QA process is one way to ensure that it becomes a routine part of your SDLC. The ultimate payoff of security testing is reducing the cost of creating and maintaining high-quality software. Your brand and organizational reputation depend on it.