How to Add Security Requirements into Different ... · How to Add Security Requirements into...
Transcript of How to Add Security Requirements into Different ... · How to Add Security Requirements into...
Copyright © 2013 SD Elements. All rights reserved.
How to Add Security Requirements
into Different Development Processes
Whitepaper:
How to Add Security Requirements into Different Development Processes
3
Table of Contents
1. Introduction ........................................................................................................................................ 3
2. Current State Assessment .................................................................................................................. 4
3. Waterfall-Style Development ............................................................................................................. 5
3.1. Description ................................................................................................................................... 5
3.2. Waterfall Roles & Responsibilities ............................................................................................... 6
4. Agile-Style Development .................................................................................................................... 7
4.1. Description ................................................................................................................................... 7
4.2. Agile Roles & Responsibilities....................................................................................................... 8
5. Continuous Development / No Process ............................................................................................. 9
5.1. Description ................................................................................................................................... 9
5.2. Continuous Development Roles & Responsibilities ................................................................... 10
6. Conclusion ......................................................................................................................................... 11
How to Add Security Requirements into Different Development Processes 3
1. Introduction
Embedding software security requirements into development teams can be complicated. Organizations often struggle to understand how to change their development processes to include requirements. Very few organizations with multiple development teams have a single, standard development process. Instead, development teams tend to build software the way that works best for them and their business needs. We have observed that while each team's development process may differ in details, most teams tend to fall into one of three patterns of development: • Agile • Waterfall • Continuous development This whitepaper outlines suggestions for embedding security into each, allowing individual development teams to select the method that works best for them. In order to use these processes you must first have a program in place to generate software security requirements. Read our whitepapers: 5 Steps to Starting a Software Security Requirements Program and Automated Scaling of Security Requirements. As with any process guidance, you will need to change elements of this document to
incorporate your organization's unique culture, nomenclature, and processes prior to using
the guidance.
How to Add Security Requirements into Different Development Processes 4
2. Current State Assessment
We recommend every existing application should undergo a current state assessment of
security requirements as a first step, prior to changing the development process. A current
state assessment involves the following steps:
• Define security requirements for an application. For example, by modeling the
application in SD Elements.
• Review resultant list of requirements over a certain risk threshold (e.g. all high
risk/priority requirements). Identify all requirements that have not been
implemented or that the development team is not sure have been implemented. This
is the set of in-scope requirements. Explicitly identify requirements where the
business is willing to accept the risk not completing these requirements.
• Add in-scope requirements to the appropriate requirements repository. Generally
this is a defect tracking or application lifecycle management (ALM) system. In less
structured teams, this may simply mean e-mailing a lead developer with the set of
security requirements or adding them to a spreadsheet.
Remember that each requirement adds overhead to the development process. We
recommend limiting scope to high risk/priority requirements to begin with.
How to Add Security Requirements into Different Development Processes 5
3. Waterfall-Style Development
3.1. Description
This development style breaks software development into distinct phases and generally has
different stakeholders involved in each phase. Waterfall development styles generally
include up-front planning phases such as requirements gathering. Contrasted with agile
development, waterfall development tends to have large release cycles (e.g. once every
quarter, bi-annually, or annually). Note that some organizations use a hybrid agile-waterfall
approach where they develop software in short sprints/ iterations but still have large
software releases. For the purposes of the embedding security requirements, such agile-
waterfall hybrid teams should follow the guidance in the waterfall-style development model.
The following diagram depicts a typical, simplified waterfall development process with
security requirements integration.
Process Diagram
We recommend embedding security requirements roughly at the process steps listed above. After
the Current State Assessment, you should periodically review application security requirements
according to their risk profile. We recommend the following frequencies:
Application risk profile Frequency of review
High risk applications. For example, external facing
web applications with credit card data
Every major release, or every quarter
(whichever is more frequent)
How to Add Security Requirements into Different Development Processes 6
Medium risk applications. For example, internal
applications storing / processing Personally
Identifiable Information (PII)
Twice per year
All other applications that are subject to
information security review Once per year
3.2. Waterfall Roles & Responsibilities
The following table outlines the stakeholders involved in using security requirements within
a development process, and their suggested responsibilities.
Role
Init
iate
pro
cess
Rev
iew
req
uir
emen
ts
Dec
ide
on
re
qu
irem
ents
in-
sco
pe
for
rele
ase
Ass
ign
req
uir
emen
ts
to d
evel
op
ers
Per
form
tes
tin
g ta
sks
Follo
w-u
p o
n
req
uir
emen
ts
pro
gres
s
Information security analyst X
Development lead X X X
Project manager X X X
Quality Assurance (QA) lead X
How to Add Security Requirements into Different Development Processes 7
4. Agile-Style Development
4.1. Description
This development style uses short iterations to build software incrementally. While there are
several specific types of agile development, such as Scrum and Kanban, they share certain
characteristics:
• Iterations are short, generally from between 1 to 4 weeks in length
• Iterations begin with short planning meetings
• Every iteration involves building shippable software
• Practitioners tend to push back on unnecessary process overhead
The following diagram depicts a typical agile development process with security
requirements process integration.
Process Diagram
We recommend embedding security requirements at the process steps listed above. Add security requirements to the product backlog and allow development teams to select when the requirements should be in-scope. After the Current State Assessment, you should periodically review applications in security requirements according to the risk profile. Add any newly-introduced requirements into the product backlog. We recommend the following frequencies:
Application risk profile Frequency of review
High risk applications. For example,
external facing web applications with
credit card data
Every sprint / iteration
How to Add Security Requirements into Different Development Processes 8
Medium risk applications. For example,
internal applications storing /
processing Personally Identifiable
Information (PII)
Twice per year
All other applications that are subject
to information security review Once per year
4.2. Agile Roles & Responsibilities
The following table outlines the stakeholders involved in using security requirements within
an agile development process, and their suggested responsibilities.
Role
Init
iate
pro
cess
Rev
iew
req
uir
emen
ts
Dec
ide
on
re
qu
irem
ents
in-
sco
pe
for
bac
klo
g
Ass
ign
req
uir
emen
ts
to it
erat
ion
Per
form
tes
tin
g ta
sks
Follo
w-u
p o
n
req
uir
emen
ts
pro
gres
s
Information security analyst X
Product owner X X X
Scrum master / project manager X X X
Quality Assurance (QA) X
How to Add Security Requirements into Different Development Processes 9
5. Continuous Development / No Process
5.1. Description
This development style uses short iterations to build software incrementally. While there are
several specific types of agile development, such as Scrum and Kanban, they share certain
characteristics:
Many modern fast-moving development teams have removed the concept of release
planning altogether. Instead, the organization maintains a list of features & defects and
developers build, test, and deploy continuously using automated deployment processes.
This means that security teams cannot review release / iteration development goals to
embed security. On the other hand, the time to deploy a fix or change is much lower than
other development styles. In other cases, development teams do not follow any
development process at all. In these teams, requirements are not formally tracked in any
system.
In both of these cases, the best option is to regularly review Security requirements
retroactively against recent changes while continuously embedding security controls into the
application's framework.
The following diagram depicts a typical continuous development process with Security
requirements process integration.
Process Diagram
With this development style, you must periodically review application security requirements
according to the risk profile. We recommend the following frequencies:
Application risk profile Frequency of review
High risk applications. For example, external facing web
applications with credit card data Bi-weekly
How to Add Security Requirements into Different Development Processes 10
Medium risk applications. For example, internal
applications storing / processing Personally Identifiable
Information (PII)
Semi-annually
All other applications that are subject to information
security review Once per year
5.2. Continuous Development Roles & Responsibilities
The following table outlines the stakeholders involved in using security requirements within
a development process, and their responsibilities.
Role
Init
iate
pro
cess
Rev
iew
req
uir
emen
ts
Dec
ide
on
re
qu
irem
ents
in-
sco
pe
for
rele
ase
Ass
ign
req
uir
emen
ts
to d
evel
op
ers
Per
form
tes
tin
g ta
sks
Follo
w-u
p o
n
req
uir
emen
ts
pro
gres
s
Information security analyst X
Development lead X X X X
Quality Assurance (QA) lead X
How to Add Security Requirements into Different Development Processes 11
6. Conclusion
Successfully deploying security requirements can yield dramatic results: applications built
faster with fewer security vulnerabilities, improved communication between development
and security teams, and increased assurance that you are aware of known security risks you
are taking when deploying code.
Like any other process change, embedding software security requirements is not easy.
Development teams are optimized to deliver value to their business, and asking them to
alter their process for the sake of security is often a losing battle. By following the practices
outlined in this paper, you can dramatically reduce the burden of development teams to
integrate software security. At the same time, you can save thousands of dollars in
remediation and significantly reduce the risk of costly breaches.
While the steps above discuss generalized process integration, remember that technical
details matter as well. In particular, how you present security requirements to developers
can dramatically alter the chance of them being adopted. Our experience is that adding
security into application lifecycle management (ALM) tools is the most effective method of
adoption.
How to Add Security Requirements into Different Development Processes 12
About SD Elements
SD Elements is your guide for secure software development. Be more proactive with automated requirements generation that scales quickly. Make security measurable with clear links between requirements & test. Proactively eliminate up to 97% of application security risks by building more secure software from the start. Learn more at www.sdelements.com