Preparing ourselves for Application Security Testing
Haven't we all as functional testers, done 'Authentication' and 'Authorization' testing? Almost every application demands some flavor of these tests. So, are we not already doing 'Application Security Testing'?
Let's explore and see what's the extra mile, we need to traverse, in each phase of SDLC, to say confidently, that the applications we are testing are secured ones.
In this blog, I am going to refer ourselves as 'functional testers' in the context of the regular testing tasks that we carry out in a project and as 'security testers' for the additional tasks which we need to plan, to certify that our Applications under Test are secure.
Requirement analysis phase
As functional testers, our focus is to verify all the requirements for completeness, correctness, unambiguity of the requirements and also derive the test scenarios out of the requirements.
As security testers, we need to review the documented security objectives for the application (provided by client) against the security objectives that can be derived out of the requirements, for completeness, correctness and unambiguity.
To do the above, we must perform techniques like role matrix, CIA (confidentiality, integrity and availability) analysis on each requirement to identify the security objectives. We also need to be aware of the set of common questions against which we need to check the security objectives of the application for identifying the missing security objectives. Some of the questions to ask are: 'what are the tangible and intangible assets to be protected?', ' what are the compliance requirements?' etc.
As functional testers, we verify the application design against the functional requirements.
As security testers, we need to verify the application design against the application vulnerabilities and the associated potential problems, in the context of bad design.
To do the above, we should be aware of typical set of potential problems that can arise out of bad design such as 'data tampering', 'cross site scripting', 'buffer overflow', 'SQL injection' and the corresponding good design practices.
As functional testers, we do not typically do the white box testing (code reviews / structured code analysis), as this is mostly carried out by the development teams themselves.
As security testers, our responsibilities might include the white box testing of the code also, but mostly using the automated tools.
To do the above, we should be aware of configuring and executing the tools for secure code analysis, prepare the bug report from the result report of the analysis and track the bugs to closure.
Black-box testing / Penetration testing:
While white box test tools act on the application code, black box test tools act on the executable application.
As functional testers, we do the black box testing either manually or using some automation tools such as QTP, RFT etc.
As security testers, we need to use the penetration testing tools such as IBM Appscan, HP WebInspect and HP QA Inspect etc. These tools are capable of identifying whether our AUT is compliant with respect to our Application security objectives.
To do the above, we should be aware of how to configure these tools to test the security objectives of our AUT. Additionally, we need to methodically identify the business scenarios within the application that can unearth the security breaches and run these tools to crawl and audit each of these flows. We should also be aware of analyzing the results of the scan, understand the recommendations given by the tools and guide the developers on how to update the application code to avoid the security flaws.
As functional testers, our scope of work in this phase is nil.
As security testers, we need to ensure that the infrastructure on which the application is deployed is secure.
To do the above, we should be aware of the appropriate configuration settings/best practices, for both the network and the host. For example we should know how to check whether right patches are applied on the server, whether log files help in troubleshooting the security problems, validate restricted/blocked remote registry administration etc.
Unless and until we approach the application security testing in a focused manner, in each phase of SDLC, we cannot claim that our AUT is secure. Let's gear up on the additional skills that are needed, to upgrade ourselves as 'Application Security Testers' and help our clients create secure applications.