Abstract— This document gives information about software Engineering methodology used in Information security domain for project management and product management.Keywords—Security,Threat,vulnerability,SecurityPatterns,Sprint,Release,Agile,Kaban,Lean.

Introduction

This document describes methodology used in software project and Product management which involve heavy consideration to software security. As Agile project management incorporates principles of Lean techniques [2], kaban and six sigma into software development life cycle. Lean comes into picture as instead of huge inventory of requirements getting stacked in Product/Project Backlog [1] an inventory is kept as small or as lean as possible. Security feature or requirements are more costly if not caught early in life cycle or product development life cycle. Paper discusses lean management of security requirements. Also application of Security Testing Methodology , application of Security patterns anti-patterns to increase Reuse and reduce time and reduce cost.

In Agile processes new User stories related to security are also added as when it arise to keep cost down. Security as condition defines degree of resistance to or protection from harm. Security applies to any vulnerable and valuable asset such as IT asset defined by IT Realm (Table 1), Physical Asset defined as Physical realm in table and similarly we protect Political and Financial Realms. Security applies to any of vulnerable asset of any of Security categorisation or realm defined in table 1. Product or Project caters to any of realm discussed above. But here we will focus on IT realm of application, network, data, Operating System(OS) security, device web and protocol security

Lean or Agile benefits to Product/Project management

In Agile project/Product management User stories define something user wants to be able to do. User Story is first step in requirement gathering. User Story is written in format :

As a _________ I want to ______. E.g.

As a Network Security Specialist I want to be able configure IPS,IDS and firewall from same unified User Interface so that I would be able to define security rules for securing network.

Use case describe process or action that provide results to an Actor. In use cases we add business Rules, constraints, features to create User Stories [1]. User Stories accumulated to be taken for implementation in a phase called Sprint. Sprint starts with meeting of all developers called Scrum. Post coding completed it ready to be tested for integration called SIT system integration testing and continuous integration of code happens immediately.

Agile And lean benefits to security :

Early is cheaper: Security user stories identified early changes required are easier to implement.

Avoid Queue: As when Security User stories are identified its inserted in product backlog taken up in same sprint thus avoid long queues.

Reduce Variability: variation in product sprint to sprint is reduced. Day to day activity optimize according to security requirements taken up early.

Small batches: reduce risk and do not clog machine keep sprint lean.

Rapid feedback: Local Early feedback loops enable quicker response to changes. Every product owner sprint team work independently hence feedback is quick.

Decentralize: helps to build scalable capacity into product and project management. As security user stories keep integrating from each team into code. Scrum team has business ownership of code for threat analysis apply regularly security user stories or attacker stories. Product owner can override when required.

The tasks here more on Administration side include working on refining and implementing Policy, Procedure and Processes. Tasks here are:

Threat Analysis: Find Threat.

Decide on What control to use or implement?

Approve Residual Risk

Security Engineering

Task here include:

Secure design and coding.

Security Testing

Security assessment

Requirement Engineering of Product for Security:

In figure 1 we see in agile process how can we manage Security Risk early in cycle. Any new requirement is captured in business case from this we derive Epic as seen in figure. Epic is high level user story and is not very actionable not tangible taken from business case and fed into requirement funnel. Epic is decomposed into smaller low level actionable requirements which are more tangible more specific and become more actual coding tasks.

Then come implementation phase where Sprint takes over which takes requirement from product backlog and put them into present sprint backlog which can be taken up for coding and testing .These are implemented and reviewed in sprint review. Code at end of sprint is fed into continuous integration testing which further passes this to Release management.

Product Owner [3] take high level user stories and decompose them into task. Product owner are sensitized for security requirements and use template to do Threat analysis as when user story come up. Security user story or attacker story are segregated and inserted separately. Attacker story are negative user story. Product owner should be able to write there worry like privacy issue as negative user story which in sprint is decomposed into attacker story. Example of attacker story is like a worry in non-functional requirement user should not be able to do certain task.

Product owner may not be developers they use prebuilt template to express their worry (based on template)or negative abuse cases (attacker story).As product owner may not have security expertise but they can express there worry which will further decomposed into security story. Scrum team takes highest priority backlog item and produce code. Sprint review is quality check of functional and non-functional requirement including attacker story. If Stories risk is not acceptable level from security point of view are re-fed into product backlog to be taken up in another sprint. In sprint review as understanding of product increases after each sprint Threat analysis is done on existing user story to find and flag the security sensitivity of task. Security sensitive task are added up as threat analysis task on product backlog. Research Spikes tasks on which team is not sure it will work or not ?.In agile its said 5% time should be reserved for Research Spikes [3].At sprint planning stage Research spikes and security sensitive task are flagged to be taken up for Threat analysis in another sprint as user story.

Release and integration Phase Requirement Engineering.

Product owner takes decision on feature or user story level on whether it is good enough for release from risk perspective also. Identify task which have regulatory requirement thus can have rapid release cycle for task which does not have regulatory requirement. Most important non-functional requirements are security testing.

Methodical security testing is different from penetration testing. It relies on a combination of creativeness ,knowledge bases of best practices, legal issues, and the client’s industry regulations as well as known threats from vulnerability databases, and the breadth of the target organization’s security presence (or points of risk).As security testing department is cost centre for client (which is debateable under outcome based model). Hence security testing has to operate very efficiently. There are many security testing methodology in market most popular one in market are

Open Source Security Testing Methodology [4]OSSTM: ISECOM institute of security and open methodology came up with security testing methodology. We can test for known vulnerability, weakness, and configurations at the time of testing so this is not enough for future. So model provide Risk Assessment Values RAV which adds dimension of frequency and timing context to security tests. Model provides correct balanced, unbiased judgement of security risk, value and business justification of target being tested.OSSTMM covers following areas:

Fig. 2 OSTMM coverage areas and their intersections

OWASP [6] Open Web Application Security Project: Its open source project has two main category development and documentation project. Its has many community project with common aim of providing Web application security framework and tools. It releases 10 web application vulnerability each year.

XSSer a framework to detect exploit and report cross site scripting XSS vulnerability.

AntiSamy enterprise web input validation and output encoding tool.

Webscarab proxy server used to intercept, examine and modify content of http packets.

Microsoft Security development lifecycle SDL [5], [7]: A security development lifecycle for security assurance processes consisting of security practises grouped by seven phases: training, requirements, design, implementation, verification, release and response. This comes with its own SDL threat modelling tool for threat analysis and many other tools which reduce development and testing at same time increase assurance and reusability of secure practises.

Microsoft SDL Threat modelling is a process to understand security threats to a system, determine risks from those threats, and establish appropriate mitigations. It uses STRIDE[5] methodology which was developed by Microsoft for classifying computer security threat. It gives 6 categories:

Hence its named as STRIDE.

STRIDE Threat types

Desired Property

Threat

Definition

1

Authentication

Spoofing

Impersonating something or someone else

2

Integrity

Tampering

Modifying code or data without authorization

3

Non-repudiation

Repudiation

The ability to claim to have not performed some action against an application

The ability of a user to elevate their privileges with an application without authorization

Conclusions

The version of this template is V2. We have seen how we can include principle of lean to incorporate better reusable security processes. Lean principle help in early incorporation of threat hence economic, provide variability in product and provide rapid responses to changes due to security user stories, security user stories taken up in each group sprints which decentralize process and reduce risk of big bang security changes. We have seen role of product manager and product backlog. Using time tested methodology like OSTMM, Microsoft SDL,OWASP help in identification fixation and provide reusability of processes and tools.
Acknowledgment

The heading of the Acknowledgment section and the References section must not be numbered.

Causal Productions wishes to acknowledge OWASP Microsoft, OSSTMM, all references agile paper and book. Security is continuous process this not end of road we need further Security pattern and Anti pattern to look at optimising the incorporating reusability into security aspect of project/product management.