The following techniques are used in security testing. No single technique can be covered most of the security issue. The balanced approach, that include several testing from manual to penetration will help to find most of the security issue.These techniques are suggested from OWSAP. We security team following balanced approach for security testing/reviewing.
- Manual Inspections & Reviews
- Threat Modeling
- Code Review
- Penetration Testing
Manual Inspections & Reviews
The concept of manual inspections and human reviews is simple and it is powerful and effective technique. By asking someone how something works and why it was implemented in a specific way, the tester can quickly determine if any security concerns are likely to be evident. Manual inspections and reviews are one of the few ways to test the software development life-cycle process itself and to ensure that there is an adequate policy or skill set in place. Manual reviews helps to understand the security process.
- Requires no supporting technology
- Can be applied to a variety of situations
- Promotes teamwork
- Early in the SDLC
- Can be time consuming
- Supporting material not always available
- Requires significant human thought and skill to be effective
Threat modeling is an approach for analyzing the security of an application. It is a structured approach to identify, quantify and address the security risks associated with an application. Modern threat modeling looks at a system from attacker's perspective.
The threat modeling process can be decomposed into few high level steps.
- Decomposing the application – use a process of manual inspection to understand how the application works, its assets, functionality, and connectivity.
- Defining and classifying the assets – classify the assets into tangible and intangible assets and rank them according to business importance.
- Exploring potential vulnerabilities - whether technical, operational,or management.
- Exploring potential threats – develop a realistic view of potential attack vectors from an attacker’s perspective, by using threat scenarios or attack trees.
- Creating mitigation strategies – develop mitigating controls for each of the threats deemed to be realistic.
- Practical attacker’s view of the system
- Early in the SDLC
- Relatively new technique
- Good threat models don’t automatically mean good software
Source Code Review
Source code review is the process of manually checking the source code of a web application for security issues. Many serious security vulnerabilities cannot be detected with any other form of analysis or testing. As the popular saying goes “if you want to know what’s really going on, go straight to the source.” Almost all security experts agree that there is no substitute for actually looking at the code. All the information for identifying security problems is there in the code somewhere. Unlike testing third party closed software such as operating systems, when testing web applications especially if they have been developed in-house) the source code should be made available for testing purposes.
Examples of issues that are particularly conducive to being found through source code reviews include concurrency problems, flawed business logic, access control problems, and cryptographic weaknesses as well as backdoors, Trojans, Easter eggs, time bombs, logic bombs, and other forms of malicious code.
- Completeness and effectiveness
- Fast (for competent reviewers)
- Requires highly skilled security developers
- Can miss issues in compiled libraries
- Cannot detect run-time errors easily
- The source code actually deployed might differ from the one being analyzed
Penetration testing is also know as black box testing or ethical hacking. In penetration testing we can find security vulnerabilities without knowing the inner working of application.
Penetration tester would have access to an application as if they were users. The tester act like an attacker and attempts to find vulnerabilities. Many people's primary testing technique is web application penetration testing.
- Can be fast (and therefore cheap)
- Requires a relatively lower skill-set than source code review
- Tests the code that is actually being exposed
- Too late in the SDLC
- Front impact testing only.
P.S Some of contents are taken from OWSAP guide.