Objectives that claim to “Enhance Security” linked to QA and Testing drive me nuts.
To me, “testing” isn’t about enhancing a characteristic or system, nor is it about “adding quality” or “breaking it.” Testers do not wave a magic wand to add quality to a system: quality has to be built-in. Testers do not break things. Often, they are already broken. Testers do not enhance security. Rather, security should be in place before testing commences. Testing is about providing information and asking questions. Testing is about exposing problems to the customer about their software and system so they can make a founded decision on whether or not to “go live.” If the customer is king, then testers are their trusted advisors.
Secondly, when I see a general expression like “Enhance Security,” I always wonder what rationale and scope lay behind it. Exactly what is the fear behind the objective of “enhancing security” and is the focus on the right place? I think that placing an objective like “enhance security” with QA and testing will create a false sense of safety. If you believe that acceptable testing results indicate tight security, you’re bound for big problems.
In the World Quality Report 2016, a whopping 65% of the executives responded that their objective was to “Enhance Security in QA & Testing.” I find that disturbing. Don’t get me wrong, I wholeheartedly welcome that security is on the agenda and that is it at the top of the list of the objectives for QA and Testing. What I find disturbing about this, however, is that apparently one thinks that Testing and QA can enhance security.
I agree that more investments in security testing are wise. Security testing—such as usability and performance testing—has not been given enough attention or priority. Most testing efforts are still made in functionality aspects and in validating if the system is fit-for-purpose. Although I understand that this is important, a working system is worth little when clients won’t use it because it is not safe to do so, or has performance problems, or doesn’t provide a satisfactory user experience. In my opinion, security testing should be a mandatory activity in the software development lifecycle.
Yes, I mean mandatory for every system that is under development. I have observed that organizations struggle with the type of security testing to be done and which focus to have. Some organizations don’t do security testing because their system doesn’t process privacy-sensitive data and they don’t see the need to complete this kind of testing, while other organizations run security testing, but only focus on the data they need to protect.
But it doesn’t stop there. As I already noted, testing will not enhance anything. Testing will show the level of quality regarding security; it will point out the flaws and the weaknesses. It is only when this information is used by the organization and by the developing teams that security can truly be enhanced. In short, putting more resources into security testing won’t increase the safety, but acting upon the information provided will.
This brings me to some pointers that I think are important when it comes to security and are not only limited to QA and Testing:
Security should be part of the software development lifecycle from inception. One should consider what security aspects are involved with the implementation of a system, including architecture, infrastructure, and privacy. Security is not only a matter of IT development. No matter how “secure” your infrastructure or your systems are, when your employees are careless with security or are not security-aware, you are vulnerable. You’re only as strong as your weakest link. Security isn’t only limited to “data”
It might seem painfully obvious when thinking about security—especially because of high fines when leaks occur—but think what happens when a hacker causes your production process to shut down completely or causes a critical malfunction. What if you become unreachable for your clients because your telephone system is suddenly unusable because of ransom-ware?
Security isn’t enhanced or assured by testing
QA and Testing is important when it comes to gaining insight on the level or the quality of security, but security is only enhanced or assured when one actually acts upon those insights in order to mitigate the risks involved. Putting more money or time in security testing doesn’t enhance the quality or value of the security testing.
Just adding security testing to the tasks of your test team doesn’t mean you have security testing in place.
Security testing, like regular testing, is a skill
It requires people who understand what they are doing, and those people must be able to glean insight from what is to be tested in relation to the security of the system under test, the landscape it occupies, and the knowledge of the latest threats.
A fool with a tool is still a fool
Buying a tool for security testing doesn’t mean your testers are suddenly able to do security testing. As I’ve already explained, it takes knowledge and skill to do security testing. It’s also important to know what type of security testing has to be done. Not every tool will suit the needs, and not every need can be covered with one tool.
Write secure codeLines of code
Too often, code is written with functionality as the main focus; as such, performance takes second place. Security is not on the minds of most developers. Complex code, remnants of debugging efforts, and backdoors for easy fixing are some of the things that I can think of when it comes to security gaps, developers should be thinking of these gaps too. Code reviews should include security aspects and developers should be more aware of security when writing code.
Set up a responsible disclosure procedure and act upon it responsibly
No matter how much effort you put into security testing, security awareness, and secure coding, there will always be something that slips through to production: the “one who got away,” so to speak.
Humans run development and as such, human errors occur, whether we like it or not. But it is the way these things are managed that can make the difference between displeasure and disaster. A responsible disclosure procedure can make that difference. But one should also be aware that it is followed up correctly. Reward people that have made an effort to point out flaws. Too many times, I’ve seen things turn ugly when whistleblowers are persecuted rather than rewarded for voicing their concerns.
While I can think of many more pointers on security in QA and testing as on security testing, I feel quite “secure” that the ones I have offered so far provide plenty of food for thought on the ways in which we can further improve security.
(About the author: Natalie Rooseboom de Vries (van Delft) is a consultant with Capgemini. This post originally appeared on her Capgemini blog, which can be viewed here).
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access