Security testing from perspective of scrum development
Rudra Prasad Tripathy
Ph.D. scholar, Utkal university
Technical architect, JDA india software(P) Ltd.
Ranjit Kumar Panda
Senior Engineer, MindTree Limited
Abstract— We are trying to show how security testing plays predominant role in secured development and through agile methodology-particularly scrum is a suitable development process. Keywords-scrum;security testing.
Application security is in attention for last few years where security no more allures to network security and transcen. Security testing is also crux of secured development though it’s not getting its due importance. In this paper we would discuss issues involved in security testing in traditional software development lifecycle approach like waterfall and would compare with scrum methodology, which is a agile methodology to see how it would smoothen few issues and would facilitate security testing. We would take cross-side scripting as the example to illustrate the study. 1.1What is security testing?
Application security would basically deals with the situation to try to break the software as what an attacker would do. This is different from traditional testing because of following idiosyncratic features. a.Traditional testing doesn’t deal with what happens if it fails, where as security testing objective to break the system and would play a role of antagonist. Hence it requires dexterity and experience to draw suitable test cases apart from tools and frameworks.. b.This would be part of risk management and hence need to reckon the cost involved. We may need to define adequate security  parlance to application’s business domain and value proposition aimed at. For example definition of adequate security a online credit card application and online healthcare system would differ. Hence prioritization and budgeting of resources are few factors need to be considered. c.Testing of different possible vulnerabilities .
1.2Security testing approaches.
Currently application security testing has been done as a white box testing, may be with help of few tools like static analysis tools to study the vulnerability. Apart from that non functional testing has been conducted to see chance of failures against vicarious attack of adversary. 1.3Cross-Site Scripting
Cross-Site Scripting (XSS) vulnerabilities were verified as executing code on the web application. This occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. XSS can generally be subdivided into two categories-stored and reflected attacks. Stored attacks are something like form stored on the target server, such as in a database, or via a submission to a bulletin board or visitor log. Reflected attacks, on the other hand, come from somewhere else. This happens when user input from a web client is immediately included via server-side scripts in a dynamically generated web page. Insufficient filtering of client-supplied data that is returned to web users by the web application is the major cause. In many cases, the client-supplied data is being used in the HTTP headers, which could be exploited by using carriage return-linefeed sequence-an attacker can add HTTP headers to the response and completely write the body of the HTTP request. 2. MOTIVATION
In one of the web application, an XSS was found through use of third party tool. This was a critical defect. Design had been made and after implementation code had been tested by security compliance team. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007. A full security review usually involves more than just...
Please join StudyMode to read the full document