Introduction
Many software developmentorganizations, including many product and online services groups within
Microsoft, use Agile software development and
management methods to build their applications.
Historically, security has not been given the attent
ion it needs when developing software with Agile
methods. Since Agile methods focus on rapidly creating
features that satisfy cu
stomers’ direct needs, and
security
is
a customer need, it’s important
that it not be overlooked. In
today’s highly interconnected
world, where there are strong regula
tory and privacy requirem
ents to protect privat
e data, security must
be treated as a high priority.
There is a perception today that Agile methods do no
t create secure code, and, on further analysis, the
perception is reality. There is very little “secure Agile
” expertise available in the
market today. This needs
to change. But the only way
the perception and reality ca
n change is by actively
taking steps to integrate
security requirements into
Agile development methods.
Microsoft has embarked on a set of software devel
opment process improvemen
ts called the Security
Development Lifecycle (SDL). The SDL has been shown to reduce the number of vulnerabilities in shipping
software by more than 50 percent. However, from an
Agile viewpoint, the SDL is heavyweight because it
was designed primarily to help secure very large prod
ucts, such as Windows® and Microsoft Office, both
of which have long development cycles.
If Agile practitioners are to adopt the SDL, two ch
anges must be made. First, SDL additions to Agile
processes must be lean. This means that for each feat
ure, the team does just
enough SDL work for that
feature before working on the ne
xt one. Second, the development
phases (design, implementation,
verification, and release) associated
with the classic waterfall-style SDL do not apply to Agile and must be
reorganized into a more Agile-friendl
y format. To this end, the SDL te
am at Microsoft
developed and put
into practice a streamlined approach that melds agile methods and security—the Security Development
Lifecycle for Agile Development (SDL-Agile).
Melding the Agile and SDL Worlds
With Agile release cycles taking as little as one
week, there simply isn’t enough time for teams to
complete all of the SDL requiremen
ts for every release. On the othe
r hand, there are serious security
issues that the SDL is designed to address, and th
ese issues simply can’t be ignored for any release
—
no
matter how small.
Integrating the two worlds is not as
difficult as it might
seem—at its heart, the SDL defines tasks, and
these tasks can be mapped into an
Agile development process. One bene
fit of the SDL is that it is
relatively artifact-free, which means there is little
documentation overhead (wit
h the notable exception of
threat models
, which are discussed later in th
is document). It is possible to
create artifacts if they are
needed, but this is generally not r
equired in an Agile environment.
SDL-Agile Requirements
A workhorse of Agile development is the
sprint
, which is a short period of time (usually 15 to 60 days)
within which a set of features or
stories are designed, developed, tested,
and then potentially delivered to
customers. The list of features to
add to a product is called the
product backlog
, and prior to a sprint
commencing, a list of features is selected from the product backlog and added to the
sprint backlog
. The
Security Development Lifecycle for Agile Development
4
SDL fits this metaphor perfectly—SDL requirements
are represented as task
s and added to the product
and sprint backlogs. These tasks ar
e then selected by team members to complete. You can think of the
bite-sized SDL tasks added to the backlog as
non-functional stories
.
Every-Sprint Requirements
In order to fit the weighty SDL requirements into th
e svelte Agile framework,
SDL-Agile places each SDL
requirement and recommenda
tion into one of three categories def
ined by frequency of completion. The
first category consists of the SDL r
equirements that are so
essential to security that no software should
ever be released without thes
e requirements being met. Th
is category is called the
every-sprint
category.
Whether a team’s sprint is two weeks or two months
long, every SDL requirem
ent in the every-sprint
category must be completed in ea
ch and every sprint, or the spri
nt is deemed incomplete, and the
software cannot be released. This includes any releas
e of the software to an external audience, whether
this is a box product release to manufacturing (RTM),
online service release to Web (RTW), or alpha/beta
preview release.
Some examples of every-sprint requirements include:
•
Run analysis tools daily or per build (see the
Tooling and Automation
section later in this document).
•
Threat model all new features (see
Threat Modeling: The Co
rnerstone of the SDL
).
•
Ensure that each project member ha
s completed at least one security tr
aining course in the past year
(see
Security Education
).
•
Use filtering and escaping libra
ries around all Web output.
•
Use only strong crypto in new code
(AES, RSA, and SHA-256 or better).
For a complete list of the every-sprint requiremen
ts as followed by Microsoft SDL-Agile teams, see
Appendix A
.
Bucket Requirements
The second category of SDL requirem
ent consists of tasks that must be performed on a regular basis over
the lifetime of the project but that ar
e not so critical as to be mandated
for each sprint. Th
is category is
called the
bucket
category and is subdivided in
to three separate buckets of
related tasks. Currently there
are three buckets in the bucket ca
tegory—verification tasks (mostly fu
zzers and other analysis tools),
design review tasks, and response planning tasks. In
stead of completing all bu
cket requirements each
sprint, product teams must complete only one SDL r
equirement from each
bucket of related tasks during
each sprint. The table below contains only a sampling
of the tasks for each buck
et. To see a complete list
of all tasks for all three buckets, consult
Appendix B: Bucket Requirements
.
Verification Tasks
Design Review
Response Planning
ActiveX® fuzzing Conduct a privacy review Create privacy support documents
Attack surface analysis Review crypto des
ign Update security response contacts
Binary analysis (BinScope) Assembly na
ming and APTCA Update network down plan
File fuzz testing User Account Cont
rol Define/update security bug bar
Table 1. Example of bucket categories. Fo
r a complete list of bucket items, see
Appendix B: Bucket
Requirements
.
Security Development Lifecycle for Agile Development
9
Starting a Threat Model for an Existing Project
If an Agile team adopts the SDL-Agile as outlined in this document while a product is already in
development, a threat model needs to
be built for the current product, bu
t it is imperative that the team
remains lean. A minimal, but useful, threat model can be
built by analyzing high-r
isk entry points and data
in the system. At a minimum, the following should be
identified and threat model
s built around the entry
points and data:
•
Anonymous and remote network endpoints
•
Anonymous or authenticat
ed local endpoints into high-privileged processes
•
Sensitive, confidential, or personally identifiable
data held in data stores
used in the application
Continuing Threat Modeling
Threat modeling is one of the ev
ery-sprint SDL requirements for
SDL-Agile. Unlike most of the other
every-sprint requirements
, threat modeling is not easily automated and can require significant team
effort. However, in keeping with
the spirit of agile development, on
ly new features or changes being
implemented in the current sprint n
eed to be threat modeled in
the current sprint. This helps to minimize
the amount of developer time required while still providing all the benefits of threat modeling.
Fuzz Testing
Fuzz testing is a brutally effective security testing
technique, especially if the team has never used fuzz
testing on the product. The threat mo
del should determine what portions
of the application to fuzz test. If
no threat model exists, the initial list should include high-risk items, such as those defined in
Appendix D:
High-Risk Code
.
After this list is complete, the relative exposure of ea
ch entry point should be de
termined, and this drives
the order in which entry points ar
e fuzzed. For example, remotely acce
ssible or unauthenticated endpoints
are higher risk than
local-only or authen
ticated endpoints.
The beauty of fuzz testing is that once a computer or group of computers is configured to fuzz the
application, it can be left running,
and only crashes need to
be analyzed. If there are no crashes from the
outset of fuzz testing, the fuzz test is probably inadequate, and a new task should be created to analyze
why the fuzz tests are failing and make the necessary adjustments.
Using a Spike to Analyze and Measure Unsecure Code in Bug Dense and “At-Risk”
Code
A critical indicator of potential security bug density
is the age of the code. Ba
sed on the experiences of
Microsoft developers and testers, the older the code, th
e higher the number of security bugs found in the
code. If your project has a large amount of legacy code or risky code (see
Appendix D: High-Risk Code
),
you should locate as many vulnerabilities in th
is code as possible. This is achieved through a
spike
. A spike
is a time-boxed “side project” with a well-defined goal (in
this case, to find security bugs). You can think of
this spike as a mini security push. The goal of the se
curity push at Microsoft is to bring risky code up to
date in a short amount of time relative to the project duration.
Note that the security push doesn't propose fixing
the bugs yet but rather an
alyzing them to determine
how bad they are. If a lot of security bugs are fo
und in code with network co
nnections or in code that
handles sensitive data, these bugs should not only be
fixed soon, but also another spike should be set up
to comb the code more thoroughly
for more security bugs.
Security Development Lifecycle for Agile Development
10
Examples of analysis perfor
med during a spike include:
•
All code.
Search for input validation failures leading
to buffer overruns and integer overruns. Also,
search for insecure passwords and key handling,
along with weak cryptographic algorithms.
•
Web code.
Search for vulnerabilities caused through improp
er validation of user input, such as CSS.
•
Database code.
Search for SQL injection vulnerabilities.
•
Safe for scripting ActiveX controls.
Review for C/C++ errors, info
rmation leakage, and dangerous
operations.
All appropriate analysis tools available to the team
should be run during the
spike, and all bugs triaged
and logged. Critical security bugs,
such as a buffer overrun in a netw
orked component or a SQL injection
vulnerability, should be treated as high-priority
unplanned items
.
Exceptions
The SDL requirement exception workfl
ow is somewhat different in SDL-Agile than in the classic SDL.
Exceptions in SDL-Classic are grant
ed for the life of the release, but this won’t work for Agile projects. A
“release” of an Agile project may only last for a few days until the next sprint is complete, and it would be
a waste of time for project managers to
keep renewing exceptions every week.
To address this issue, project team
s following SDL-Agile can choose to
either apply for an exception for
the duration of the sprint (which wo
rks well for longer sprints) or for a specific amount of time, not to
exceed six months (which works well fo
r shorter sprints). When reviewin
g the requirement exception, the
security advisor can choose to incr
ease or decrease the severity of th
e exception by one level (and thus
increase or decrease the seniority of the manager
required to approve the
exception) based on the
requested exception duration.
For example, say a team requests an
exception for a requirem
ent normally classified as severity 3, which
requires manager approval. If they
request the exception on
ly for a very short period of time, say two
weeks, the security advisor may drop the severity to
a 4, which requires only approval from the team’s
security champion. On the other hand, if the team re
quests the full six months,
the security advisor may
increase the severity to a 2 and
require signoff from senior mana
gement due to the increased risk.
In addition to applying for except
ions for specific requirements, team
s can also request an exception for
an entire bucket. Normally teams must complete
at least one requirement
from each of the bucket
categories during each sprint, but if a team cannot
complete even one requirement from a bucket, the
team requests an exception to cover that entire
bucket. The team can request an exception for the
duration of the sprint or for a specific time pe
riod, not to exceed six mont
hs, just like for single
exceptions. However, due to
the broad nature of the exception—basi
cally stating that the team is going
to skip an entire category of r
equirements—bucket exceptions are cla
ssified as severity 2 and require the
approval of at least a senior manager.
Final Security Review
A Final Security Review (FSR) similar to the FSR performed in the classic waterfall SDL is required at the
end of every agile sprint. However,
the SDL-Agile FSR is limited in scop
e—the security advisor only needs
to review the following:
•
All every-sprint requirements have been completed,
or exceptions for those
requirements have been
granted.
Security Development Lifecycle for Agile Development
11
•
At least one requirement from ea
ch bucket requiremen
t category has been
completed (or an
exception has been gran
ted for that bucket).
•
No bucket requirement has gone
more than six months without be
ing completed (or an exception
has been granted).
•
No one-time requirements have
exceeded their grace period deadline (or exceptions have been
granted).
•
No security bugs are open that fall above the desig
nated severity threshold (t
hat is, the security bug
bar).
Some of these tasks may require manual effort from the
security advisor to ensure that they have been
completed satisfactorily (for example, threat model
s should be reviewed), but
in general, the SDL-Agile
FSR is considerably more lightweig
ht than the SDL-Classic FSR.
Now that the basic methodology and foundation is
in place, it's time for an example scenario.
SDL-Agile Example
A database-driven Web product is currently in developme
nt by a team with a four-week sprint duration. It
is primarily written using C# and ASP.NET. There is
a Windows service that processes some data from the
Web application. The service was originally writte
n three years ago and is about 11,000 lines of C++
code—it’s pretty complex.
Input to the Web application is mostly unauthentica
ted, but it does offer a remotely accessible admin-
only interface. The application also uses a small ActiveX control written in C++.
The product backlog includes 45 us
er stories—21 of these are high
-priority stories, 10 are medium-
priority stories, and 14 are low-priority stories. Du
ring the sprint planning phase, 10 user stories are
selected for the current sprint, 3 stor
ies are high priority, 3 are medium
priority, and the final 4 are low
priority.
At this point, the team adds technology stories fo
r each of the every-sprint
SDL requirements. Even
though the product uses both managed and native mod
ules, the team is only
working on the managed-
code modules during this sprint, so
only the every-sprint tasks that
apply to managed online services are
added to the sprint.
Since this is the first sprint in which the team is
using the SDL-Agile process,
additional high-priority
stories are added to complete some of
the one-time requiremen
ts (for example, registering the project in
the security compliance tracking sy
stem, creating a privacy form, iden
tifying a privacy incident response
person, and identifying a se
curity program manager). One more high
-priority story is added to update the
build process to integrate the SDL-
required, every-build requirements
(use of the SDL-required compiler
and linker flags and integration of the FxCop security rules).
Security Development Lifecycle for Agile Development
12
Finally, the team also adds in high-priority stories fo
r the bucket tasks that the team wants to complete
during the current sprint. For this sp
rint, the team chooses to add tasks
to run an attack surface analyzer,
review the crypto design of the syst
em, and create a content publishing
and user interface security plan.
The sprint begins, and two people on the team take
on the task of building
the threat model for the
features to be developed during this
sprint. The big problem is that no one knows how to build a threat
model, so the two people read th
e threat modeling
chapter in the
SDL book
2
and read Adam Shostack’s
series of threat modeling blog posts. This gives th
em enough information to
perform the threat modeling
task.
After the threat model is
built (and the corresponding story completed), the team uncovers a critical
vulnerability—the database contains sensitive data
(users’ names, computer information, browser
information, and IP addresse
s), and the data is not prot
ected from disclosure thre
ats. Because the data is
sensitive, and it appears that un
authenticated attackers could access
the data through a potential SQL
injection vulnerability, two more high-priority stor
ies are added to the sprint backlog—one to add
defenses to protect the data in
the database and the other to
scour the code for SQL injection
vulnerabilities. The team does not know about protecti
ng data from disclosure, so the person slated to
work on this defense reads chapter 12, “Failing to Store and Protect Data Securely,” in the
19 Deadly Sins
.
One developer checks to ensure th
at the build environment is set up
to use the SDL-required compiler
and linker switches and that
the security-focused code an
alysis tools are also set
to run as part of the
build process.
After looking at the new set of user stories so fa
r, the team decides to remove two medium-priority
stories and two low-priority stories to keep within th
e sprint time box—these stories are put back in the
product backlog. Finally, after talking to the cust
omer, one high-priority story is downgraded to a
medium-priority story but is to be completed in this sprint.
One developer elects to address the possible SQL inje
ction vulnerabilities identified by the threat model.
He spends three days finding all database access co
de within the Web and C++ code and modifying it to
use stored procedures and parameterized queries. He al
so modifies the access rights of the interactive
database user so that it does not have access to
any database tables that are not necessary for the
application. He also removes the interactive user’s
permissions for deleting database objects and creating
new database objects, since these are also not necessa
ry for the application to function. These practices
are good defense-in-depth measures that help preven
t the system from being expl
oited in the event that
a vulnerability accidentally slips into the production code.
Nineteen days into the sprint, all of
the SDL-required, high-priority stor
ies are completed, as are many of
the selected user stories. The team fi
nishes out the sprint, completing the
rest of the selected user stories.
The sprint is a success, and th
e team is poised to release their new code to the public.
2
Howard, Michael, and Steve Lipner.
The Security Development Lifecycle
(Chapter 9). Microsoft Press, June 28, 2006.
Security Development Lifecycle for Agile Development
13
Appendix A: Every-Sp
rint Requirements
Title
Requirement/
Recommendation
Applies to
Online
Services
Applies to
Managed
Code
Applies to
Native Code
Communicate privacy-impacting
design changes to the team’s
privacy advisor
Requirement X X X
Compile all code with the /GS
compiler option
Requirement X X
Comply with SDL firewall
requirements
Requirement X X
Do not use banned APIs in new
code
Requirement X X
Ensure all ASP.NET applications
use the ValidateRequest cross-site
scripting input validation
attribute
Requirement X X
Ensure all database access is
performed through
parameterized queries to stored
procedures
Requirement X X X
Ensure all team members have
had security education within the
past year
Requirement X X X
Ensure the application domain
group is granted only execute
permissions on the database
stored procedures
Requirement X X X
Fix all issues identified by code
analysis tools for unmanaged
code
Requirement X X
Fix all security issues identified by
CAT.NET and FxCop static analysis
Requirement X X
Follow input validation and
output encoding guidelines to
defend against cross-site scripting
attacks
Requirement X X X
0 Comments:
Post a Comment