Abstract— This document gives information about software Engineering methodology used in Information security domain for project management and product management



Download 38.83 Kb.
Date conversion23.12.2016
Size38.83 Kb.
Product Security and Risk management in Agile Product and Project Management

Sandeep Sharma#1


#Electronics And Computer Engineering Department,


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.


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

TABLE I
SECURITY Categorisation in Different Realm



S. No.

Categorisation of Security

IT Realm

Physical Realm

Political / Financial Realm

1


Application Security of Applications


Airport/Office security

Homeland Security

2

Computing security of computers ,Operating System and network.

Infrastructure security

Human security

3

Data security of databases

Physical security

International security

4

Information security of information systems protecting Confidentiality, Integrity, Availability CIA

Port security/Supply chain security

National security

Public security



5

Network security

School/ Shopping centre security

Financial security

  1. security categorisation

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


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


  1. Requirement engineering for Security

Security work classified into

Fig1. Threat Analysis and attacker story integrated into Agile project management process.

Security in IT realm can be classified into 2 types [3]:


  1. Security Risk Management

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

  1. Security Engineering

Task here include:

  • Secure design and coding.

  • Security Testing

  • Security assessment

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


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

  1. Optimize Security Testing and development of Product/Project using Security Testing methodology

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

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


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

  • Webgoat: guide for secure programming practises.

  • ESAPI: Enterprise Security API contains methods needed to build secure web application.

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




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

Fig. 3 A sample line graph using colors which contrast well both on screen and on a black-and-white hardcopy

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

4

Confidentiality

Information

Disclosure



The exposure of information to unauthorized users

5

Availability

Denial of Service

The ability to deny or degrade a service to legitimate users

6

Authorization

Elevation of

Privilege


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





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



    References

  1. Roman Pichler, 2010Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn)) page 98-108.

  2. Larman, Craig, 2004.scaling Lean and Agile developement:Thinking and Organizational Tools for large scale scrum.

  3. Leffing, Dean, 2009, "Product owner in agile enterprise" Agile journal, April 6.

  4. Open Source testing methodology manual 2.1.http://isecom.org


  5. STRIDE,http://msdn.microsoft.com.

  6. OWASP Project http://owasp.org

  7. Blackhat presentation Microsoft SDL 30 June 2009 Available: http://www.blackhat.com/presentations/bh-dc-10/Sullivan_Bryan/BlackHat-DC-2010-Sullivan-SDL-Agile-wp.pdf







The database is protected by copyright ©hestories.info 2017
send message

    Main page