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.
Requirement of 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 the 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 almost all kinds of software testing, there exist some universally accepted guiding principles, which are used for estimating how long will the testing of a particular project take & how much of the focus and effort must be allotted to which parts of the project. These guiding principles are often applied to many types of software testing. However, in the case of security testing, these principles need some reconsideration and, in certain cases, reversals. Some of them are-
- Code Maturity: Conventionally, the most critical guideline to perform software testing over existing codes is, the more developed a code normally is, the lesser the number of detectable errors within it. However, in the case of security testing, the norm becomes slightly more complex, almost contradicting the guidelines of the functional testing. In case performing security testing on your software project has just started recently, then the current code could be containing more security defects in comparison to the new one.
- Code Complexity: Rule for software testing in terms of code complexity is not so different. The higher the code complexity, the more the existence of functional bugs. Generally, the complexity of the code and security vulnerabilities is directly proportional to each other.
- Code Coverage: If high-level security testing has been performed on the project code previously through code analysis, its chances of containing security vulnerabilities is quite less in comparison to the one which has not received a security examination ever before. Code coverage is generally measured by estimating the amount of code that has been touched at the time of a typical test pass. However, this is not actually meaningful for the security testing efforts. Though it is quite common for the white-box testing teams to check the entire code looking for security threats, the real chunk of code touched by the testing process is actually the most meaningful when it comes to the functional 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.
Connect with KiwiQA to leverage focused capability for focused Security Testing services.
