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.
Design phase
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.
Test phase
White-box testing:
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.
Deployment phase
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.
Conclusion
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.
Comments
Thank you for sharing information about app security testing.As i work at software testing company, i think this info will be of some use. You can also visit our site for any related info- http://salvusappsolutions.com
Posted by: Nita | July 8, 2015 11:05 AM