CSE 6324: Advanced Topics in Software Engineering

Paper Presentation on

An Overview of Security Practices in Agile Software Development

- Naieem Khan

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.

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.

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.

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.

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.

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.

Approach: The Generic PrincipleA 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

Approach: The DisagreementCurrent security assurance practices clash with agile development on four fronts:

1. Tacit Knowledge/Documentation: The specialists were not present during the development stages.

2. 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.

3. Refactoring: Refactoring of designs and other major architectural changes is difficult and time-consuming.

4. Testing: The testing philosophy focuses on the least exercised parts of the system (as opposed to general functional testing).

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

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

Approach Solution: Scrum (contd.)

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.

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.

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 definitionsInput: Candidate definitions from IEEE and other standardsTechnique: Structured interviews, focus groupParticipants: Stakeholders, requirements engineersOutput: Agreed-to definitionsIncorporating 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 goalsInput: Business policies and procedures, examples Technique: Facilitated work session, interviewsParticipants: Stakeholders, requirements engineersOutput: GoalsIncorporating in DSDM: Security goals for the project are clearly outlined along with business goals.

Approach Solution: DSDM (contd.)Step 3: Develop artifacts to support security requirements definitionInput: Potential artifacts (e.g., scenarios, misuse cases)Technique: Work sessionParticipant: Requirements engineersOutput: Needed artifacts: scenarios, misuse casesIncorporating in DSDM: Create artifacts necessary for full understanding of the system.

Step 4: Perform risk assessmentInput: Misuse cases, scenariosTechnique: Risk assessment methodParticipants: Requirements engineers, risk expert, stakeholdersOutput: Risk assessment resultsIncorporating in DSDM: The initial risk assessment should also include security risk. The identified security risk should then be prioritized.

Approach Solution: DSDM (contd.)Step 5: Select elicitation techniquesInput: Goals, organizational style, level of security needed, cost/benefit analysis, etc.Technique: Work sessionParticipant: Requirements engineersOutput: Selected elicitation techniquesIncorporating in DSDM: Select elicitation technique best suited for the project.

Step 6: Elicit security requirementsInput: Risk assessment results, selected techniquesTechnique: Joint Application Development (JAD), interviews, model-based analysis, checklists, lists of reusable requirements types, document reviewsParticipants: Stakeholders, requirements engineersOutput: Initial cut at security requirementsIncorporating in DSDM: Gather initial security requirements in terms of misuse cases that support the goals and security definitions already collected.

Approach Solution: DSDM (contd.)Step 7: Categorize requirements as to level (system, software, etc.) and whether they are requirements or other kinds of constraintsInput: Initial requirements, architectureTechnique: Work sessionParticipants: Requirements engineers, other specialists as neededOutput: Categorized requirementsIncorporating in DSDM: Categorize the elicited security requirements Step 8: Prioritize requirementsInput: Categorized requirements and risk assessment resultsTechnique: Prioritization methodsParticipants: Stakeholders, requirements engineersOutput: Prioritized requirementsIncorporating in DSDM: The categorized security requirements are prioritized Step 9: Requirements inspectionInput: Prioritized requirements, candidate formal inspection techniqueTechnique: Inspection method such as peer reviewsParticipants: Inspection teamOutput: Initial selected requirements, documentationIncorporating in DSDM: The inspection process can include inspection of the security requirements

Approach Solution: DSDM (contd.)DSDM Phase: Functional model iterationSQUARE 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.

Analysis: ScrumThe 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.

Analysis: DSDMSQUARE 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.

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.

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.

Thank You