Security Testing from Agile Perspective

Security testing from perspective of scrum development Rudra Prasad Tripathy Ph. D. scholar, Utkal university Technical architect, JDA india software(P) Ltd. Hyderabad,India Rudra1in@yahoo. com Ranjit Kumar Panda Senior Engineer, MindTree Limited Bangalore, India panda. ranjitkumar@gmail. com 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. 1. Introduction 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

[1] 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 [2]. 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 seeking out XSS vulnerabilities. it also involves overall threat modeling, testing for different threats like overflows, information disclosure, error handling, SQL injection, authentication, and authorization bugs. The nice thing is that doing a thorough job in any one area often overlaps with another. Like, while testing for XSS vulnerabilities, you will very often identify error handling and information disclosure problems as well.

Though automated tool like webinspect were available, we did some manual testing through a tool called Paros

[8] for HTTP traffic interception. Intercepting the client GET and POST requests is extremely important. One could circumvent any sort of client-side JavaScript input validation code that may have been pushed down. A simple test will be changing a get parameter in the request. Let the URL is as below https://www. yoursite. com/index. html? param=test. One would modify the URL like https://www. yoursite. com/index. html? name=alert(‘XSS’), and subsequently, if a popup opens up saying XSS then this parameter is open to XSS vulnerable. Paros Proxy is used to intercept the request parameter.

Using this tool we will inject some malicious javascript code into the cookies, header or form parameters. If the code will be executed while the response is displayed in the browser, the application is vulnerable to XSS. 2. 1 Security testing models There are many methodologies proposed by SEI

[5] like SSE-CMM, TSM for secured development. Following are the steps for secured development life cycle

[4] followed at Microsoft. Stage 0: Education and Awareness Stage 1: Project Inception Stage 2: Define and Follow Design Best Practices Stage 3: Product Risk Assessment Stage 4: Risk Analysis Stage 5: Creating Security Documents, Tools, and Best Practices for Customers Stage 6: Secure Coding Policies Stage 7: Secure Testing Policies Stage 8: The Security Push Stage 9: The Final Security Review Stage 10: Security Response Planning Stage 11: Product Release Stage 12: Security Response Execution This best suits to development practice like waterfall model. 2.. 2 Techniques for security testing Though security testing requires some level of craftsmanship, still we could derive some common techniques for analysis. We can broadly divide insecurities into two categories –insecurity by design and insecurity by implementation [7]. Analyses of bugs are another way of identifying the problem and deriving the solution, to some extent general use of this could be ascribes to already available taxonomies. We could see how following agile practice would better tackle the problems and techniques could be applied in a better way. 3. ACHIEVING AGILITY Many enterprises like Microsoft [9], IBM have presented skewed steps of normal life cycle to achieve agility Followings are mapping between steps provided for agile development features of scrum process. In above mentioned works authors try to explain from waterfall perspective of agile. In the following points, we are trying to show how agile is inherently suitable for secured development and particularly for security testing. . Short development period A typical development period is 2-3 weeks which means at end of every sprint one would test the software. In various papers, limitation of seven plus minus two has been advocated. Duration of 2-3 week development would make it easier for a security tester to identify impacted area, hence would help in fuzz testing. ii. Incremental development As the development is incremental, work like threat modeling. It also help in planning when to implement requirement exceptions and hence security review. iii.

Cross functional team As there is paucity of security experts, one would conduct sprints specific to implement security features. As output application size is incremental developer would find it easy to do code review and rectify cryptographic error code. iv. Defining done Though 2-3 weeks is a small amount of time, we cannot really achieve everything. But we could define what we mean by done. We may define identifying issues as done only, may be through static analysis tool. There is a flexibility to inject short sprints in between where we could pick up security implementation instead of product features. Hence agile is a natural choice for secured development. v. No Documentation Maintaining document for threat modeling and other security test cases would be redundant and overhead maintaining documents for satisfying process requirement would not be required. Hence from process perspective we don’t need to do agile, secured testing can be agile. 4. CONCLUSION There is a gap in understanding of scrum from quality perspective. We tried to bridge the gap and to make development process more secured. Further empirical studies and experience papers would help to buttress use of agile for development of secured applications and products. References 1]Bruce Potter and McGraw Gary, “Software Security Testing” [Article], IEEE Security and Privacy. 2004. pp. 32-35. 2]C. E. Landwehr et al. , “A Taxonomy of Computer Program Security Flaws,with Examples”, tech. report NRL/FR/5542—93/9591, Naval Research Laboratory, Nov. 1993. 3]Allen Julia, Barnum Sean, Ellison Robert, McGraw Gary and Mead Nancy. “Software Security: A Guide for Project Managers”, Addison-Wesley, 2008. 4]Steve Lipner,Michael Howard,”The Trustworthy Computing Security Development Lifecycle”,Security Engineering and Communications Security Business and Technology Unit,Microsoft Corporation, March 2005. 5]Noopur Davis,”Secure Software Development Life Cycle Processes”, Software Engineering Institute ,2009. 6]K Tsipenyuk, B Chess, G McGraw – IEEE Security & Privacy Magazine, 2005 7]OWASP Top Ten Most Critical Web Application Security Vulnerabilities, https://www. owasp. org/documentation/topten. html 8]https://www. parosproxy. org 9]https://www. blackhat. com/presentations/bh-dc-10/Sullivan_Bryan/BlackHat-DC-2010-Sullivan-SDL-Agile-wp. pdf

Cite this page