Developing Secure Software in a Agile environment

Transcription

1 Developing Secure Software in a Agile environment Dejan Baca [email protected] Blekinge school of Technology Ericsson AB Research planning Abstract Software developers can use agile software development methods to build secure information systems. Current agile methods have few explicit security features. While several discrete security methods can supplement agile methods, few of these integrate seamlessly into other software development methods. Because of the severe constraints imposed by agile methods, these discrete security techniques integrate very poorly into agile approaches. My research aims to examine the effectiveness of known security touch points in an agile development process. BACKGROUND During development of software, faults and flaws are introduced either from the implementation or from the design of the software. During runtime these faults and flaws can propagate into failures that can result in vulnerabilities if the right conditions are present. Failures and especially vulnerabilities increase the cost for the developers and require them to spend time on maintenance instead of new features. Many telecom developers rely on testing to reduce their maintenance cost and achieve software with high availability. Unfortunately most of the testing is done to verify functionality and not to find vulnerabilities. Figure 1. Requirements compared to implementation Figure 1 illustrates the problem with most common development process, testing and early fault detection is focused on bugs and verifying requirements and spend little time on any extra functionality that might have been added, i.e. vulnerabilities. To improve the software s security many developers use penetration testing on release products. While penetration testing does find vulnerabilities it has to be performed late in development after all the functions have been verified as no more functionality is permitted to be added after the penetration testing has passed. Therefore it is expensive to do security verification testing and it adds lead time for the product. An alternative is to use an security development process that includes security during the entire process, instead of trying to add it at the end of development. Some attempts like Microsoft s, Security Development Lifecycle, have been tried with encouraging results. Figure 2 shows a layout of the Security Development Lifecycle.

2 Besides Microsoft s Trustworthy Computing Security Development Lifecycle (SDL) [1] there are also, the SEI s Team Software Process (TSP) [2], Correctness by Construction [3], Common Criteria [4] and several other security development processes [4]. Unfortunately all of these processes focus on waterfall models and less iterative development cycles. It therefore creates integration problems when security measures from these processes are integrated into an agile project. Security Touch Points Figure 3. Security touch points Software security touchpoints are based on good software engineering and involve explicitly pondering security throughout the software lifecycle. [5] This means knowing and understanding common risks (including language-based implementation bugs and architectural flaws), designing for security and subjecting all software artifacts to thorough, objective risk analyses and testing. "Software Security Touchpoints" specifies one set of touchpoints and shows how software practitioners can apply them to the various software artifacts produced during software development. This means understanding how to work security engineering into requirements, architecture, design, coding, testing, validation, measurement and maintenance. 1. All software projects produce at least one artifact: source code. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. Code review is a necessary practice, but not sufficient for achieving secure software. Security bugs (especially in C and C++) are a real problem, but architectural flaws wreak just as much havoc. Just as you can't test quality into software, you can't bolt security features onto code and expect it to become hack-proof. Security must be built in throughout the application development lifecycle.

3 Static code analysis articles: Improving security using extensible lightweight static analysis, D Evans, D Larochelle [7] ITS4: A Static Vulnerability Scanner for C and C++ Code, J Viega, JT Bloch, T Kohno, G McGraw [6] 2. At the design and architecture level, a system must be coherent and present a unified security front. Designers, architects and analysts should clearly document assumptions and identify possible attacks. At both the specifications-based architecture stage and at the class-hierarchy design stage, risk analysis is a necessity. At this point, security analysts uncover and rank architectural flaws so that mitigation can begin. Disregarding risk analysis at this level leads to costly problems down the road. Note that risks crop up during all stages of the software lifecycle, so a constant risk analysis thread, with recurring risk tracking and monitoring activities, is highly recommended. Risk analysis articles: Attack Trees, B Schneier [8] Attack Modeling for Information Security and Survivability, AP Moore, RJ Ellison, RC Linger [9] Assessment and control of software risks, C Jones [10] 3. Penetration testing is also useful, especially if an architectural risk analysis is driving the tests. It provides a good understanding of fielded software in its real environment, but any such testing that doesn't take the software architecture into account probably won't uncover anything interesting about software risk. Software that fails during the kind of canned black-box testing practiced by prefab application security testing tools is truly bad. Thus, passing a low-octane penetration test reveals little about your actual security posture, but failing a canned penetration test indicates that you're in very deep trouble indeed. Testing security articles: Exploiting Software: How to Break Code, G Hoglund, G McGraw [11] 4. Security testing must encompass two strategies: testing security functionality with standard functional testing techniques, and risk-based security testing based on attack patterns. A good security test plan does both. Security problems aren't always apparent, even when you probe a system directly, so standard-issue quality assurance is unlikely to uncover all critical security issues. Risk base testing articles: Risk-based testing: Risk analysis fundamentals and metrics for software testing including a financial application case study, S Amland [12] 5. Building abuse cases is a great way to get into the mind of the attacker. Similar to use cases, abuse cases describe the system's behavior under attack; building abuse cases requires explicit coverage of what should be protected, from whom, and for how long. Abuse cases articles: Using abuse case models for security requirements analysis, J McDermott, C Fox [13] 6. Security must reside explicitly at the requirements level. Good security requirements cover both overt functional security (say, the use of applied cryptography) and emergent characteristics (best captured by abuse cases and attack patterns). Requirements and abuse case articles: Eliciting security requirements with misuse cases, G Sindre, AL Opdahl [14] Security Requirements Engineering: When Anti-requirements Hit the Fan, R Crook, D Ince, L Lin, B Nuseibeh [15] 7. Battle-scarred operations personnel carefully monitor fielded systems during use for security attacks. Attacks do occur, regardless of the strength of design and implementation, so monitoring software behavior is an essential defensive technique. Knowledge gained by understanding attacks and exploits should be cycled back into software development.

4 Taxonomy articles: Use of A Taxonomy of Security Faults, T Aslam, I Krsul, E Spafford [16] Seven pernicious kingdoms: a taxonomy of software security errors, K Tsipenyuk, B Chess, G McGraw [17] Agile Security The software industry has formalized agile product development [24] in various forms of agile software development methods [1]. For competitive reasons, developers often use these methods for web and network applications where security risks are prominent. Despite the prominent risks, the existing agile methods have few features specifically addressing security risks. The agile process mostly ignores the idea of lightweight security, thou the use of touch points. As a result, agile software products will lack security protection unless such protection is added afterwards, e.g. penetration testing on the finished product. To integrate a security measurement into an agile process these four requirements have to be fulfilled: 1. Security approach must be adaptive to the agile software development methods; 2. They must be simple; they should not hinder to the development project; 3. Security approach, to be integrated successfully with agile development methods, should offer concrete guidance and tools at all phases of development, i.e., from requirements capture to testing. 4. A successful security component should be able to adapt rapidly to ever-changing requirements owing to a fast-paced business environment, including support for handling several incremental iterations. In their article Towards Agile Security Assurance, Beznosov and Kruchten address this issue and make some proposals as to how security assurance activities could be merged into Agile development methods [Beznosov 05]. They classified existing software assurance activities into four categories: those that are a natural match for Agile methods, those that are independent of any development methodology, those that can be automated or semi-automated so that they could be incorporated into Agile methods, and those that are fundamentally mismatched with Agile methods. Semiautomate Security assurance method or technique Match Independent Mismatch d Guidelines Specification Analysis Review Application of specific architectural approaches Use of secure design principles Formal validation Informal validation Internal review External review Informal requirements traceability Requirements testing Informal validation Formal validation Security static analysis High-level programming languages and tools Adherence to implementation standards Use of version control and change tracking Change authorization Integration procedures Use of product generation tools Internal review External review Security evaluation Test depth analysis Security testing Vulnerability and penetration testing Requir ement Design Implementation Test

5 MY REASEACH While my research is dependent on development process as the SDL or G McGraw s books, my focus is not to add new methods and tools to the process. Instead I m investigating the process claim that they can be integrated into existing development cycles, more specifically an agile process, to be able to do that I have to know if any improvement has been done to the software after a security method has been added. This presents the problem of measuring the results as the total amount of vulnerabilities in the program is always unknown. There is also the problem with integration issues that Beznosov addresses in his article. HYPOTHESIS Lightweight security touch points can be introduced into an agile development process in a non-intrusive manor that does not conflict with agile metrology. The touch points also create a measurable improvement on the security and overall quality of the finished product. APPROACH 1 - Identifying the most common and destructive vulnerabilities By examining and classifying known vulnerabilities from public and private databases the most common vulnerabilities can be identified and sorted. This data can then be used to measure and determine what touch point has the greatest effect on overall security. The end result of this study should be a published paper detailing the most common vulnerabilities and there classification. 2 Examining know touch points With the common vulnerabilities database as a starting point, different touch point are examined on there effectives to detect the vulnerabilities. Will probably be done by minor case studies where touch point are used on software with known vulnerabilities. 3 Putting it together Large scale case study where several work packages in a project uses the examined touch points. The results are compared to the work packages that lack touch points, examining if there are any overall quality improvements. This also forces the touch points to be agile compliant. ARTICLES Touch point Static code analysis 1 A case study on old released code with already known faults, the results from the static analysis tool would be compared to the already known faults. Determining if any known vulnerabilities are detect, if any dormant unknown vulnerabilities are detected and what types of vulnerabilities are detected by a static analysis tool compared to the products customers. Touch point Static code analysis 2 A case study on a running project and the use of static code analysis as a touch point. Focusing on non-intrusive usage and return of investment. Touch point Static code analysis 3 Questioner study on the agile developers that are trying to incorporate touch points into there development cycle. Touch point Abuse cases / attack trees Case study in an ongoing project that incorporates design and requirement touch points. Measures the overall quality of the effected work packages. Data gathering Collecting vulnerabilities data from public and private databases and classifying them. Creating a picture of what types are most common. Agile case study

6 Large scale case study where touch point are used during the entire development cycle of several work packages. Compares trouble report data with the projects other work packages and examines the touch points effectiveness. Out of project penetration testing will probably be needed to determine if vulnerabilities that the touch points focus on have been affected. JOURNAL Touch point Static code analysis Several case studies on old released code with already known faults, the results from the static analysis tool would be compared to the already known faults. Determining if any known vulnerabilities are detect, if any dormant unknown vulnerabilities are detected and what types of vulnerabilities are detected by a static analysis tool compared to the products customers. Agile case study Several large scale case study where touch point are used during the entire development cycle of several work packages. Compares trouble report data with the projects other work packages and examines the touch points effectiveness. Out of project penetration testing will probably be needed to determine if vulnerabilities that the touch points focus on have been affected. Expected results Understanding of the most common vulnerabilities Security touch points weaknesses and strengths The ability to integrate with agile development Possibility to measure improved security indirectly CURRENT ACTIVES Articles: Touch point Static code analysis 1 Written not published, out for review. Touch point Static code analysis 2 Written and published. Touch point Static code analysis 3 Case study done, nothing written. Should be done Touch point Abuse cases / attack trees Case study started. Should be done Data gathering Case study done, nothing written. Should be done Agile case study Nothing. Should be done after Journal: Touch point Static code analysis 1 Case study party done, partly written, should be done Agile case study Nothing. Should be done after Courses before lic.: Telecom Node overview Java Enterprise Reliability Engineering Software Testing FOSSAD Research Planning Brown Bag seminars Adv. Topic Decision Making 1&2 2p 4p 3p 5p 1p 3p 2p 5p 10p

7 IMPORTANT RESOURCES PAPERS Static code analysis These papers focus on static analysis that is an important touch point in security. J. Viega, J. T. Bloch, T. Kohno, and G. McGraw. Its4: A static vulnerability scanner for c and c++ code. In Proceedings of the 16th Annual Computer Security Applications Conference, December [6] D. Evans and D. Larochelle. Improving security using extensible lightweight static analysis. IEEE Software, 19(1):42 51, February [7] Bush, W.R., Pincus, J.D. and Sielaff, D.J. A Static Analyzer for Finding Dynamic Programming Errors. Software-Practice and Experience, 30 (5), 2000, [18] B. Chess and G. McGraw. Static Analysis for Security. IEEE Security and Privacy, 2(6), [19] Secure software development General papers about secure development processes. P. T. Devanbu and S. G. Stubblebine. Software engineering for security: a roadmap. In ICSE - Future of SE Track, pages , [20] K. P. Birman. Building Secure and Reliable Network Applications. Manning Publishing Company and Prentice Hall, December [21] Lee Y., Lee J. and Lee Z. Integrating Software Lifecycle Process Standards with Security Engineering. Computers & Security Vol 21, No 4, pp , [22] Siponen, M., Baskerville, R., Kuivalainen, T., Integrating Security into Agile Development Methods. Proceedings of the 38th Hawaii International Conference on System Science [23] Steven B. Lipner. The trustworthy computing security development lifecycle. In 20th Annual Computer Security Applications Conference (ACSAC 2004), pages 2 13, December [24] LITERATURES Building Secure Software: How to Avoid Security Problems the Right Way, by John Viega, Gary McGraw [25] This book provide an analysis of the major problems with all software, and give a collection of techniques with which to address the recurring problems, such as buffer overflows, access control exposures, randomness flaws and other security-related defects. Secure Programming with Static Analysis, by Brian Chess, Jacob West [26] This book shows the reader how to effectively use static analysis tools as a part of the code review process to automate finding security bugs. Because most programs are to large for manual line by line analysis this book presents a good automated solution. Secure Coding: Principles and Practices, by Mark G. Graff, Kenneth R. Van Wyk [27] This book is about the process that designs and implements strong programs. It starts with architecture and design documents, then follows through to design and maintenance. Software Security: Building Security In, by Gary McGraw [5] This book emphasizes the differences between bugs (coding errors) and flaws (deeper architectural problems). It shows that automated code inspection tools can be applied more or less successfully to the first problem set, but human investigation is required to address the second. The book clarifies the need for an entire development process and not a bolt on solution. JOURNALS Information and Software Technology Information and Software Technology is the international archival journal focusing on research and experience that contributes to the improvement of software development practices.

8 Journal of Systems and Software The Journal of Systems and Software publishes papers covering all aspects of programming methodology, software engineering and related hardware/software systems issues. CONFERENCES These are conferences that have the highest prestige and are still relevant in the lightweight secure process field. I calculated prestige based on several different criteria. The number of publications and citations of the articles published at the conferences, but also abstract measurements. CSF : IEEE Computer Security Foundations Many new techniques and methods within security have been presented at Security Foundations Symposium and therefore there publications often become seed papers that many refer to. IEEE Computer Society's Technical Committee on Security and Privacy In this conference real implementations and actual projects results are often published and therefore have more contact with industry. ACM Conference on Computer and Communications Security (CCS) The annual ACM Computer and Communications Security Conference is a leading international forum for information security researchers, practitioners, developers, and users to explore cutting-edge ideas and results, and to exchange techniques, tools, and experiences. European Systems & Software Process Improvement and Innovation While the three first conferences focus on security, my research enters the realm of software process, but there are no security software process conferences. This conference focuses heavily on case studies, the same as my research. International Symposium on Empirical Software Engineering and Measurement The conference focuses on the processes, design and structure of empirical studies, and the results of specific studies. These studies may vary from controlled experiments to field studies and from quantitative to qualitative studies. GROUPS AND ORGANIZATIONS Center for Internet Security - CIS members develop and encourage the widespread use of security configuration benchmarks through a global consensus process involving participants from the public and private sectors. - Computer Emergency Response Team - CERT has developed a methodology to help organizations build security into the early stages of the production life cycle. The Security Quality Requirements Engineering (SQUARE) methodology consists of nine steps that generate a final deliverable of categorized and prioritized security requirements. Although the SQUARE methodology could likely be generalized to any large-scale design project, it was designed for use with information technology systems. - Swedish IT Security Network for PhD Students A Swedish network for Ph.D student in IT security. - IMPORTANT RESEARCHERS G Mcgraw Produced numerous article and books about secure development processes. Lead researcher in the field and the seed writer of lightweight security, touchpoints. D Viega Code security researcher that has done much collaborator work with G Mcgraw. D Evans, D Larochelle Several seed papers in that are today standards in automated vulnerability research. An, according to me, important part in the development of secure software. J Jürjens Research and seed paper on designing security with the aid of UML. B Schneier Lead developer in cryptology but also seed paper on attack trees and security design.

9 REFERENCES 1. Steven B. Lipner. The trustworthy computing security development lifecycle. In 20th Annual Computer Security Applications Conference (ACSAC 2004), pages 2 13, December Humphrey W. S. Introduction to the Team Software process. Addison Wesley, Anthony Hall and Roderick Chapman. Correctness by Construction: Developing a Commercial Secure System. IEEE Software January/February 2002, pp R. Anderson: Security Engineering. John Wiley, McGraw, G. Software Security: Build Security In, Addison-Wesley, J. Viega, J. T. Bloch, T. Kohno, and G. McGraw. Its4: A static vulnerability scanner for c and c++ code. In Proceedings of the 16th Annual Computer Security Applications Conference, December D. Evans and D. Larochelle. Improving security using extensible lightweight static analysis. IEEE Software, 19(1):42 51, February Schneier, B., Attack Trees, Secrets and Lies. pp , John Wiley and Sons, New York, Moore, A P, Ellison, R J and Linger, R C Attack Modeling for Information Security and Survivability. Technical Note CMU/SEI-2001-TN-001 (March 2001) 10. Jones, Capers, Assessment & Control of Software Risks, Prentice-Hall, Hoglund, G. and McGraw, G Exploiting software: How to break code. Addison-Wesley. 12. Stale Amland, Risk Based Testing and Metrics: Risk analysis fundamentals and metrics for software testing including a financial application case study, 5 th International Conference EuroSTAR 99, November, McDermott, J., Fox, C. Using Abuse Case Models for Security Requirements Analysis. Proceedings 15 th IEEE Annual Computer Security Applications Conference G. Sindre and A. L. Opdahl, "Eliciting Secutiry Requirements by Misuse Cases", Proc. TOOLS Pacific 2000, pp , Nov R. Crook, D. Ince, L. Lin and B. Nuseibeh, "Security Requirements Engineering: When Antirequirements Hit the Fan", Proceeding of the 10th Requirements Engineering Conference (RE'02), Germany, 9-13 Sep T. Aslam, I. Krsul and E. Spaord, A Taxonomy of Security Faults, Proceedings of the National Computer Security Conference, Katrina Tsipenyuk, Brian Chess, and Gary McGraw, Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors, Proceedings of Workshop on Software Security Assurance Tools, Techniques, and Metrics, op. cit., pp Bush, W.R., Pincus, J.D. and Sielaff, D.J. A Static Analyzer for Finding Dynamic Programming Errors. Software-Practice and Experience, 30 (5), 2000, B. Chess and G. McGraw. Static Analysis for Security. IEEE Security and Privacy, 2(6), P. T. Devanbu and S. G. Stubblebine. Software engineering for security: a roadmap. In ICSE - Future of SE Track, pages , K. P. Birman. Building Secure and Reliable Network Applications. Manning Publishing Company and Prentice Hall, December Lee Y., Lee J. and Lee Z. Integrating Software Lifecycle Process Standards with Security Engineering. Computers & Security Vol 21, No 4, pp , Siponen, M., Baskerville, R., Kuivalainen, T., Integrating Security into Agile Development Methods. Proceedings of the 38th Hawaii International Conference on System Science Steven B. Lipner. The trustworthy computing security development lifecycle. In 20th Annual Computer Security Applications Conference (ACSAC 2004), pages 2 13, December G. McGraw and J. Viega, Building Secure Software: How to Avoid Security Problems the Right Way. Addison-Wesley, Sept Brian Chess, Jacob, Secure Programming with Static Analysis, West Addison-Wesley, M.G. Graff and K.R. van Wyk, Secure Coding: Principles & Practices. O Reilly, first edition 2003.