Businesses demand certainty. If yours doesn’t, it should.
When you release a new digital product, such as an internet-facing application, to market don’t you want to assure it is fit for purpose? This means that it has been thoroughly tested for all aspects of Quality, including functional and non-functional testing, to determine that it performs as designed.
It’s kind of like, if you purchase a vehicle, you not only expect it to function as designed but also that it has been thoroughly tested to eliminate, or at least reduce, the likelihood that unforeseen events could adversely affect the vehicle. A lock on a car door should work as designed, locking and unlocking the door when the correct key is inserted. However, just as important is testing to see if this security control can be bypassed by someone tampering with the lock in a creative way. This may include simply pulling on the door with force, or gaining access through a window, or using a tool to simulate the action of a key. All of these tests relate to the quality of the product and should be considered together when the solution is being designed and built.
Security testing is quite often viewed as a ‘dark art’ that sits in silo as a standalone unit outside of other project teams. A development team might have spent months, or sometimes years, developing a solution, only to find there are critical vulnerabilities resulting in either urgent patches having to be deployed or the business deciding to accept the risk. Or worse still, going live with known vulnerabilities. This is the ambulance at the bottom of the cliff response, and while there is more awareness of cyberattacks, my time within a security consultancy suggests this approach is still all too often the norm.
A penetration test is still the most accurate test for security bugs, but is often expensive and takes days or weeks to complete. With rapid development methodologies such as DevOps that include terms like continual integration and deployment (CI/CD), the security industry needs to look at other ways to review systems rapidly and repeatably.
To make a real difference in the outcome of our solutions, we need to shift how we approach them. A culture change is needed – security should not be considered as a ‘one-off team’ but as ‘part of the team’. This change starts at the requirement level and continues through to architecture, development and operations.
The testing and verification of any functional or non-functional issue, including security, should form part of the quality assurance conversation where continual testing is the norm.
This integration is natural for quality assurance teams often engaged earlier and embedded into projects during all phases of development. I saw this alliance working first-hand during my time as a developer. Our development team worked alongside the QA team where issues were found and corrected daily. Fortunately, none of the bugs found were security-related; there was no security expertise as part of the team.
Part of the reason for this lack is that both security and quality assurance testing are fundamentally different, and each requires specialist skill sets. The quality assurance team works to ensure the solution functions as designed, whereas the security team works to ensure the solution is free from vulnerabilities. One has the mindset of a normal user and one the mindset of a malicious hacker. For a quality assurance tester, the outcome is already known and documented, however, a penetration tester might work for hours (sometimes days) to find one vulnerability that could be exploited.
By working alongside other complementary specialists, security teams can become exponentially more useful in identifying and removing risk. We can combine expert security testing with a wider range of skills, such as business analysis and automation, to help ‘shift security left’ within our modern IT world that hinges on velocity and trust.
By Mark Keegan