CSE 6324: Advanced Topics in Software Engineering Paper Presentation on An Overview of Security Practices in Agile Soft

1. CSE 6324: Advanced Topics in Software Engineering Paper Presentation onAn Overview of Security Practices in Agile Software Development - Naieem Khan

2. The Topic & Motivation • Agile development has been the scheme for developing software during the past decade. • Development teams can ensure speedy and timely delivery of software coping with the requirements change phenomenon. • However, the security issues and problems related to that software phenomenon are hardly considered. • These issues can make software products greatly vulnerable and prone to malicious attacks by individuals. • Hence, this paper proposes the integration of security principles in the development phases of agile methodology to solve the problems which can make the software products vulnerable. • All in all, the proposed solution of the paper would be based on research papers which had addressed security issues during agile software development.

3. The Problem: Security Issues • There is no combined or specific process to follow for planning on security in agile methods. • In most cases the idea of what may happen if a software product is intentionally and maliciously attacked, is neglected. • The software products these days are so fragile that they barely function properly when the environment is not traditional.

4. The Problem: Security Issues (contd.) Three most known security problems: Buffer overflow, SQL Injection and Cross-site scripting. • Buffer overflow: When a program writes data outside the bounds of allocated memory. It is usually exploited to overwrite values in memory to the advantage of the attacker. • Example: A call to gets() is a guaranteed buffer overflow vulnerability because it requires the user to pass in a fixed-size buffer, but it does not place any limits on the amount of data it writes into the buffer. char buf[128]; gets(buf); • By allocating an array on the stack and then calling gets(), the program is a perfect setup for a stack buffer overflow.

5. The Problem: Security Issues (contd.) • SQL Injection: An SQL injection is often used to attack the security of mostly a website by giving input to SQL statements, to perform operations on the database other than the usual operations as intended by the designer. • Example: SELECT * FROM items WHERE owner = "admin"; DELETE FROM items; • SQL commands are injected from the form into the database like queries to change the database content or dump the database information.

6. The Problem: Security Issues (contd.) • Cross-site Scripting: It is a type of computer security vulnerability typically found in web applications that enables attackers to inject client-side script into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls. • Example: • Inserting JavaScript in a form field which does not have validation can redirect the page to some malicious content. • DNS Cache poisoning which is to setup a site and collect information from that site.

7. State of the Art • Current agile methods have very few explicit security features. • It has been approached that the security requirements must be specified and should be considered concurrently when we are designing business process and physical implementation. • Use of several discrete security methods (such as checklists and management standards) in agile methods. • Involve third-party to assure security. • Classifications of security assurance methods and techniques to ensure security. • Proposed theories in assuring security in agile methods.

8. Approach: The Generic Principle A set of key security elements, which can be added seamlessly in each stages of agile software development methods are: • Requirements analysis phase: • Identify security-relevant objects from requirements analysis • Identify security-relevant subjects from requirements analysis • Do risk analysis and management • Design phase: • Ensure that security requirements are included in the design phase • Implementation phase: • Ensure that the wanted security features are implemented • Testing phase: • Test that selected features work as wanted Involvement of third-party in all phases

9. Approach: The Disagreement Current security assurance practices clash with agile development on four fronts: • Tacit Knowledge/Documentation: The specialists were not present during the development stages. • Lifecycle: In an iterative lifecycle which includes fast production, the theory states that the third-party should have been involved at each iteration. Involving a third party is expensive and time-consuming. • Refactoring: Refactoring of designs and other major architectural changes is difficult and time-consuming. • Testing: The testing philosophyfocuses on the least exercised parts of the system (as opposed to general functional testing).

10. Approach: Scrum • Product Backlog: • Master list of all functionality desired in the product • Minimal documentation • Release Backlog: • Subset of the product backlog that is planned to be delivered in the coming release • Sprint Backlog: • List of tasks that the Scrum team is committing that they will complete in the current sprint • Time boxed • Time release has been decided, and any addition in security part will be hard to manage in time • Testing and potentially shippable product: • Here all products have been integrated and will be tested for a final delivery • Security part will cost a lot of time and money to maintain

11. Approach Solution: Scrum (contd.) • Proposed Solution- Security Backlog: The security backlog follows the existing security principles to make sure that there are not any vulnerabilities and risks associated with software. Through the security backlog the security issues can be reduced. • Security backlog will be handled by – “Security Master” • Security Master Roles: • To identify the features that have a security risk based on security principle • To document risk in security backlog • Perform security testing for selected features

12. Approach Solution: Scrum (contd.)

13. Approach Solution: Scrum (contd.) • The features in product backlog will go through security backlog. • The security master figures out only the certain features in the product backlog that require the security attention. • The security master marks and documents (illustrated as red line) the security requirements for the selected features in security backlog. This will be used in development and testing phases as a reference. • After security backlog, the next is release backlog which contains the prioritized features that are processed in sprint. • It can be seen in the previous figure that the features selected by the scrum master (marked with blue color), are processed as usual like other processes, except with the additional red and dotted line. • The marked security concerns will be carried forward to sprint backlog for developers’ attention. The testing part will be conducted in sprint phases by the security master.

14. Approach: Dynamic Systems Development Method (DSDM) • Pre-project phase: Ensures that the project is set up properly. • Feasibility study phase: Assessments on whether DSDM is a right approach for the project, likely costs, and technical feasibility are some of the factors evaluated in this phase. • Business study phase:Focuses on understanding the business requirements and technical constraints associated with the project. • Functional model iteration phase: Involves the creation of a functional model and prototypes. • Design and build iteration phase: Aims to refine and test the functional prototype created during the previous phase. • Implementation phase:Operates the tested system in the users’ working environment and provides required training to the end user. • Post-project phase: Ensures effective maintenance of the delivered product.

15. Approach Solution: DSDM (contd.) Security Quality Requirements Engineering (SQUARE) Method& Incorporation of SQUARE steps into a DSDM process: All nine steps of SQUARE are performed in the business study phase. Step 1: Agree on definitions Input: Candidate definitions from IEEE and other standards Technique: Structured interviews, focus group Participants: Stakeholders, requirements engineers Output: Agreed-to definitions Incorporating in DSDM: The requirements engineering team and project stakeholders agree on technical definitions that serve as a baseline for all future communication. Step 2: Identify security goals Input: Business policies and procedures, examples Technique: Facilitated work session, interviews Participants: Stakeholders, requirements engineers Output: Goals Incorporating in DSDM:Security goals for the project are clearly outlined along with business goals.

16. Approach Solution: DSDM (contd.) Step 3: Develop artifacts to support security requirements definition Input: Potential artifacts (e.g., scenarios, misuse cases) Technique: Work session Participant: Requirements engineers Output: Needed artifacts: scenarios, misuse cases Incorporating in DSDM: Create artifacts necessary for full understanding of the system. Step 4: Perform risk assessment Input: Misuse cases, scenarios Technique: Risk assessment method Participants: Requirements engineers, risk expert, stakeholders Output: Risk assessment results Incorporating in DSDM: The initial risk assessment should also include security risk. The identified security risk should then be prioritized.

17. Approach Solution: DSDM (contd.) Step 5: Select elicitation techniques Input: Goals, organizational style, level of security needed, cost/benefit analysis, etc. Technique: Work session Participant: Requirements engineers Output: Selected elicitation techniques Incorporating in DSDM: Select elicitation technique best suited for the project. Step 6: Elicit security requirements Input: Risk assessment results, selected techniques Technique: Joint Application Development (JAD), interviews, model-based analysis, checklists, lists of reusable requirements types, document reviews Participants: Stakeholders, requirements engineers Output: Initial cut at security requirements Incorporating in DSDM:Gather initial security requirements in terms of misuse cases that support the goals and security definitions already collected.

18. Approach Solution: DSDM (contd.) Step 7: Categorize requirements as to level (system, software, etc.) and whether they are requirements or other kinds of constraints Input: Initial requirements, architecture Technique: Work session Participants: Requirements engineers, other specialists as needed Output: Categorized requirements Incorporating in DSDM:Categorize the elicited security requirements Step 8: Prioritize requirements Input: Categorized requirements and risk assessment results Technique: Prioritization methods Participants: Stakeholders, requirements engineers Output: Prioritized requirements Incorporating in DSDM:The categorized security requirements are prioritized Step 9: Requirements inspection Input: Prioritized requirements, candidate formal inspection technique Technique: Inspection method such as peer reviews Participants: Inspection team Output: Initial selected requirements, documentation Incorporating in DSDM: The inspection process can include inspection of the security requirements

19. Approach Solution: DSDM (contd.) DSDM Phase: Functional model iteration SQUARE Steps: • Perform risk assessment (Step 4): This step is revisited to develop a revised risk list. Additional security risks are captured and risks are prioritized. • Perform Steps 6, 7, 8, and 9 if new risks arise out of Step 4.

20. Analysis: Scrum The Scrum approach focuses on integrating security principles in Scrum methodology by involving a new security backlog which identifies a number of issues from different aspects of security in Scrum perspective. Pros/Strengths: • It can be beneficial in terms of both time and money. • Applying this method can solve the security issues in Scrum and also the additional overhead of third-party involvement can be greatly reduced since security backlog will be handled by the security master alone. Cons/Weaknesses: • Integrating security backlog to existing Scrum approaches in industries may be difficult. • Additional involvement of a security master can cause overhead. • Security education is needed first in order to train developers and stakeholders to make sure their security awareness are satisfied. This can be difficult to achieve. However, it is to be noted that the theory has just recently been proposed and the result of the proposed solution are not available yet.

21. Analysis: DSDM SQUARE method emphasizes implementing the methodology in the initial phases of the life cycle model, so as to build security into the product from the start. Pros/Strengths: • All the steps of SQUARE fit in the business study phase of DSDM. The other phases of the method will not be affected because of this. • The functional model iteration phase incorporates certain steps of SQUARE easily in case of new risks. • If applied successfully security risks can be greatly reduced. Cons/Weaknesses: • Integrating SQUARE method to DSDM may be difficult. Need additional study on SQUARE and applying the theory in DSDM may cost time and effort. • Need to train an entire team to adapt the methodology. • Industries may be not willing to take risks. Like the security backlog in Scrum, the SQUARE method has not been applied in practice by integrating with DSDM method. Hence, the results of the proposed theory of integrating SQUARE into DSDM are yet to come.

22. Conclusion & Future Work • The results of the proposed solution for security backlog will be available hopefully in the near future after enough data has been collected from various surveys, interviews and experiments. • In the future there will be more publications regarding the integration of SQUARE with various DSDM life cycle models, so that organizations with an existing process can more readily address security requirements concerns. • It can be said that, it is challenging to adopt these methods for security assurances but organizations have applied different applications before and those turned out to be successful. This can be the motivation for trying to integrate SQUARE with DSDM processes and security backlog in Scrum. • We hope to see further work in extending and modifying agile methods to incorporate security concerns.

23. References • A. Tappenden, P. Beatty, A. Geras and M. Smith, "Agile Security Testing of Web-Based Systems via HTTPUnit," in AGILE Conference 2005, p 29-38, 2005. • K. Beznosov and P. Kruchten, "Towards Agile Security Assurance," in Proceedings New Security Paradigms Workshop, p 47-54, 2004. • M. Siponen, R. Baskerville and T. Kuivalainen, "Integrating Security into Agile Development Methods," in 38th Hawaii International Conference on System Sciences, HICSS, p 185-192, 2005. • N. R. Mead, V. Viswanathan and D. Padmanabhan, "Incorporating Security Requirements Engineering into the Dynamic Systems Development Method," in Proceedings 32nd Annual IEEE International Computer Software and Applications Conference, COMPSAC, p 949-954, 2008. • R. Dove, "Pattern Qualifications and Examples of Next-Generation Agile System-Security Strategies," in 44th Annual 2010 IEEE International Carnahan Conference on Security Technology, ICCST, p 71-80, 2010. • R. G. Epstein, "Getting Students to Think About How Agile Processes Can Be Made More Secure," in IEEE 21st Conference on Software Engineering Education and Training, CSEET, p 51-58, 2008. • V. Kongsli, "Towards Agile Security in Web Applications," in Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA, p 805-808, 2006. • Z. Azham, I. Ghani and N. Ithnin, "Security Backlog in Scrum Security Practices," in 5th Malaysian Conference in Software Engineering (MySEC), p 414-420, 2011.

24. Thank You