Microsoft SDL in practice - owasp
Microsoft SDL in practice - owasp
Microsoft SDL in practice - owasp
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
The OWASP Foundation<br />
http://www.<strong>owasp</strong>.org<br />
<strong>Microsoft</strong> <strong>SDL</strong> <strong>in</strong> <strong>practice</strong><br />
Alex Thissen<br />
Pr<strong>in</strong>cipal Architect, Achmea<br />
alex.thissen@achmea.nl @alexthissen
Alex Thissen<br />
• Architect with a focus on <strong>Microsoft</strong> technologies<br />
and products<br />
• Security<br />
• Competencies<br />
• Tra<strong>in</strong>er/coach <strong>in</strong> software development<br />
• Regional Director for The Netherlands<br />
• Most Valuable Professional<br />
for Visual C#
Agenda<br />
• Overview of <strong>Microsoft</strong> <strong>SDL</strong><br />
• Phases of <strong>SDL</strong><br />
• Implement<strong>in</strong>g <strong>SDL</strong> at Achmea<br />
• Lessons learned<br />
• Questions and answers<br />
|3
Th<strong>in</strong>k security<br />
• Force yourself to pay attention to<br />
security dur<strong>in</strong>g application development<br />
• Security is often first victim<br />
4
• Embedd<strong>in</strong>g security <strong>in</strong>to software and<br />
culture<br />
• Platform agnostic approach<br />
• Proven benefits<br />
• <strong>Microsoft</strong> <strong>in</strong>ternal adoption<br />
• Extensive experience with security<br />
• Trustworthy comput<strong>in</strong>g<br />
5
<strong>SDL</strong> optimization model
Achmea <strong>SDL</strong> optimization<br />
Start<br />
Goal
Phases of Simplified <strong>SDL</strong><br />
8
Comb<strong>in</strong><strong>in</strong>g <strong>SDL</strong> and agile<br />
• Requirements def<strong>in</strong>ed<br />
by frequency, not phase<br />
• Every-Spr<strong>in</strong>t (most critical)<br />
• One-Time (non-repeat<strong>in</strong>g)<br />
• Bucket (all others)<br />
9
Embedd<strong>in</strong>g <strong>SDL</strong> <strong>in</strong> process<br />
• Guidance for process<br />
changes<br />
• Process template for<br />
Visual Studio ALM<br />
<strong>in</strong>tegration<br />
• <strong>SDL</strong><br />
• MSF Agile with <strong>SDL</strong>
IMPLEMENTING <strong>SDL</strong> AT ACHMEA<br />
11
Focus at Achmea<br />
• Emphasis on implementation at MScc<br />
• L<strong>in</strong>e-of-bus<strong>in</strong>ess apps<br />
• Web portals<br />
• Part of cha<strong>in</strong>: bigger scope<br />
• Embed <strong>SDL</strong> <strong>in</strong>to “exist<strong>in</strong>g” development<br />
process<br />
• Sync with quality gates<br />
12
Deliverables <strong>SDL</strong> for Achmea
Tra<strong>in</strong><strong>in</strong>g<br />
• Onl<strong>in</strong>e assessment and awareness<br />
course<br />
• Security expert tra<strong>in</strong><strong>in</strong>g<br />
• Roadshow for all MScc employees<br />
• Focus on different phases <strong>in</strong> <strong>SDL</strong> for<br />
different roles<br />
14
Requirements<br />
• Bus<strong>in</strong>ess Impact<br />
Analysis (BIA)<br />
• Determ<strong>in</strong>es CIA rat<strong>in</strong>g<br />
• Weighs <strong>in</strong> on <strong>in</strong>itial<br />
Architecture design and<br />
documentation<br />
15
Design<br />
• Comb<strong>in</strong>ed Attack Surface Analysis and<br />
Threat model<br />
• Change design to reduce surface<br />
• Threat models as part of architecture<br />
• Use <strong>SDL</strong> Threat Model<strong>in</strong>g Tool<br />
• Determ<strong>in</strong>e risks from STRIDE<br />
• Part of security view of SAD<br />
16
Implementation<br />
• Adopted Patterns &<br />
Practices guidance<br />
• Best <strong>practice</strong>s<br />
• Guidel<strong>in</strong>es and checklists<br />
• Tool<strong>in</strong>g<br />
• Included CAT.NET <strong>in</strong> build<br />
• Watcher<br />
17
Verification<br />
• BTOcc testplan adopted from OWASP<br />
• Test<strong>in</strong>g for OWASP Top 10<br />
• ASVS test<strong>in</strong>g<br />
• Dynamic, static and manual penetration<br />
test<strong>in</strong>g<br />
• Code reviews<br />
18
Release<br />
• F<strong>in</strong>al Security Review (FSR)<br />
• Check on deliverables of previous phases<br />
• Approval by Design Authority<br />
• Ultimate quality gate<br />
19
Response plan<br />
• Incident response part of<br />
other departments<br />
• IT Operations (IDS,<br />
monitor<strong>in</strong>g)<br />
• Security departments<br />
• Close loop by apply<strong>in</strong>g<br />
lessons learned<br />
20
LESSONS LEARNED<br />
21
Tak<strong>in</strong>g hurdles<br />
• Security as a hurdle<br />
• “False positives”<br />
• Break perception<br />
• “Security takes time,<br />
budget and <strong>in</strong> not cool”<br />
• Miss<strong>in</strong>g or<br />
sub-optimal tool<strong>in</strong>g<br />
22
Visibility<br />
• Make sure you have security experts<br />
• Advocat<strong>in</strong>g security<br />
• People to ask questions<br />
• Pick people that like it<br />
• F<strong>in</strong>d management<br />
that demands it<br />
23
Achievable goals<br />
• Small steps<br />
• Not all at once<br />
• Prioritize and<br />
pick from top 3<br />
24
Cont<strong>in</strong>uous metrics<br />
• Include security<br />
metrics <strong>in</strong> build<br />
• Tool<strong>in</strong>g is essential<br />
• Test<strong>in</strong>g only at end<br />
leads to disaster<br />
25
Bus<strong>in</strong>ess and management<br />
• Buy-<strong>in</strong> from management is essential<br />
• Awareness at bus<strong>in</strong>ess is critical<br />
• Don’t end <strong>in</strong> a showdown with bus<strong>in</strong>ess<br />
26
Ongo<strong>in</strong>g tra<strong>in</strong><strong>in</strong>g<br />
• Tra<strong>in</strong><strong>in</strong>g alone is not enough<br />
• Offer help on-the-job<br />
• Not just before but dur<strong>in</strong>g project as well<br />
• Fast-mov<strong>in</strong>g field of security, attacks,<br />
vulnerabilities<br />
27
Responsibility<br />
• Def<strong>in</strong>e clear roles<br />
• Who does what?<br />
• Shar<strong>in</strong>g responsibility<br />
28
WRAPPING UP<br />
29
Summary<br />
• Embed security <strong>in</strong> your process<br />
• It’s not easy<br />
• <strong>Microsoft</strong> <strong>SDL</strong> turned out to be a good<br />
choice<br />
• OWASP <strong>in</strong>itiatives helped a lot<br />
• You’re never done<br />
30
Questions and Answers<br />
& A<br />
31
Tra<strong>in</strong><strong>in</strong>g Requirements Design Implementation Verification Release Response<br />
Security<br />
Tra<strong>in</strong>ed?<br />
No<br />
Complete<br />
Core<br />
Tra<strong>in</strong><strong>in</strong>g<br />
Sec/Priv<br />
Reqs?<br />
No<br />
Perform all<br />
subtasks<br />
Design<br />
Reqs?<br />
No<br />
Perform<br />
all<br />
subtasks<br />
Tools<br />
ID’d?<br />
No<br />
Specify<br />
compilers,<br />
tools, flags<br />
& options<br />
Dynamic<br />
Analysis?<br />
No<br />
Conduct<br />
runtime<br />
verification<br />
tests<br />
Response<br />
Plan?<br />
No<br />
Document<br />
emergency<br />
response<br />
procedures<br />
END<br />
Yes<br />
Yes<br />
Yes<br />
Yes<br />
Yes<br />
Yes<br />
Experts<br />
ID’d?<br />
No<br />
Assign<br />
advisors &<br />
team leads<br />
Security<br />
No<br />
Consult<br />
advisors<br />
for review<br />
Unsafe<br />
APIs?<br />
No<br />
Ban bad<br />
functions<br />
& APIs<br />
Fuzz<br />
Tests?<br />
No<br />
Fuzz all<br />
program<br />
<strong>in</strong>terfaces<br />
F<strong>in</strong>al<br />
Security<br />
Review?<br />
No<br />
Review all<br />
security &<br />
privacy<br />
activities<br />
Yes<br />
Yes<br />
Yes<br />
Yes<br />
Yes<br />
M<strong>in</strong><br />
Reqs?<br />
No<br />
Def<strong>in</strong>e<br />
m<strong>in</strong>imum<br />
security<br />
criteria<br />
Privacy<br />
No<br />
Consult<br />
advisors<br />
for review<br />
Static<br />
Analysis?<br />
No<br />
Perform<br />
periodic<br />
static code<br />
analysis<br />
TM/ASR<br />
Review?<br />
No<br />
Validate<br />
models<br />
aga<strong>in</strong>st<br />
code<br />
complete<br />
project<br />
Release<br />
Archive?<br />
No<br />
Archive all<br />
pert<strong>in</strong>ent<br />
technical<br />
data<br />
Yes<br />
Yes<br />
Yes<br />
Yes<br />
Yes<br />
Bug<br />
Track?<br />
No<br />
Specify<br />
bug/work<br />
track<strong>in</strong>g<br />
tool<br />
Crypto<br />
No<br />
Consult<br />
advisors<br />
for review<br />
Pen Tests?<br />
(Option)<br />
No<br />
Deliberate<br />
attack<br />
test<strong>in</strong>g on<br />
critical<br />
components<br />
Yes<br />
Yes<br />
Yes<br />
Quality<br />
Gates?<br />
No<br />
Specify<br />
quality<br />
gates &<br />
bug bars<br />
Attack<br />
Surface?<br />
No<br />
Layered<br />
defenses &<br />
least<br />
privilege<br />
Yes<br />
Yes<br />
Assessed<br />
Risk?<br />
No<br />
Use SRA/<br />
PRA to<br />
codify risk<br />
Threat<br />
Models?<br />
No<br />
Assess<br />
threats<br />
us<strong>in</strong>g<br />
STRIDE<br />
Yes<br />
Yes<br />
32