In recent years, the security of the software we use has become a huge issue, and yet security testing remains almost a black art in the software industry. For testers, the sudden announcement of “you’re in charge of security testing” is all the warning they may have that their professional focus has changed. Or, a tester may decide to learn about security testing to help prevent his or her company or product from being mentioned in an ugly industry headline. Now, these testers need to immediately add a whole new set of skills and techniques to their test arsenal. Faced with these new challenges, it is also difficult to find proper resources since a vast majority of resources that are geared specifically toward software security are focused on either development or hacking. This article presents some basic concepts of security testing for beginners.
Need for Security Testing
Many factors have converged in the last few years and made software security one of the largest concerns of both businesses and consumers. Some of these factors are:
- Increase in the number of computers
- Increase in the Use of Internet
- More Activities Are Performed Online
- Security Efforts Have Become More Visible
- Enormous costs of recognizing security exploits
- In-House Software Is No Longer Immune
- Perimeter Security Just Isn’t Enough etc.
Security Testing Versus Functional Testing
The job of a tester is to determine the quality of the product to enable management to make informed decisions about its readiness to ship. From this perspective, it’s pretty clear that both security testing and functional testing fall within the broader umbrella ‘software testing’. Yet, there are some major differences between security testing and functional testing, some of which are given below :
- Functional testing is performed for identifying whether the product serves its intended purpose and does what it is supposed to do. Hence, a vast majority of functional testing is done from the viewpoint of a customer. However, performing testing merely from only this viewpoint will result in bypassing a large percentage of security tests.
- In most types of testing, there exist some universal guiding principles that can be used to help estimate the amount of time it will take and the attention and effort to be applied to test the project in question. Though most of these principles apply to maximum forms of testing, performing security testing nevertheless requires revisiting these principles and, in some cases, even reversing them. Some of them are-
- Code Maturity: Conventionally, the more mature a code is, there is a lesser percentage of bugs that can potentially be found in that code. However, when it comes to security testing, this principle is almost reversed from the traditional application of it in functional testing. In case a dedicated security testing has recently started a project, it’s much more possible for the older code to encompass a larger percentage of security defects than the newer code.
- Code Complexity: The thumb rule for testing in case of code complexity is basically the same in both functional and security testing. This principle is- the more complex the code, the larger likelihood it has to have functional bugs. Generally, the complexity of the code and security vulnerabilities are directly proportional to each other.
- Code Coverage: In case a particular code has been subjected to extensive security testing in the past through several security test tools, it’s less likely to contain security vulnerabilities in comparison to the code that has never been tested before. Thus, a standard for measuring code coverage metrics is to identify the percentage of code touched during a test. However, in case of security testing, this isn’t very meaningful for security test efforts. Although testers prefer to test the entire code for security vulnerabilities, the actual percentage of code that is touched by testing is more meaningful to functional testing than security testing.
Discovering Software Vulnerabilities:
Generally, one should keep in mind that despite the method utilized for discovering vulnerabilities, there are very good odds that such vulnerabilities, nevertheless, will be found. One should, however, realize that the time between security vulnerabilities being found outside the product team and when they are reported or exploited may also vary greatly. If an information about a security vulnerability has a potential to be used for malicious purposes, there is no reason for attackers who think they may be able to exploit that vulnerability to want to tip off anyone about the risk. There is also a lack of predictability of these external reports which can sometimes lull companies and teams into a false sense of security and lead to some rather optimistic decisions when deciding what vulnerabilities need to be mitigated next.