1
Q
SDLC Software Development Life Cycle –>
A
Framework of steps in software development process
2
Q
SDLC Steps:
A
- Planning
- Defining
- Designing
- Building
- Testing
- Deployment
3
Q
SDLC is …
A
not optional
4
Q
Why Microsoft SDLC?
A
- very well documented
- widely known
5
Q
Purpose of the legendary Bill Gates E-Mail?
A
Security by Design approach is needed during SDLC –> Threat modeling is a mandatory part
6
Q
SDLC Process:
A
7
Q
SDLC: Training =
A
assess organizational knowledge on security and privacy, establish training program as necessary
8
Q
SDLC: Requirements =
A
consider security at the outset of a project
9
Q
SDLC: Design =
A
define and document security architecture, identify security critical components
10
Q
SDLC: Implementation =
A
Full spectrum review, used to determine processes, documentation and tools necessary to ensure secure deployment and operation
11
Q
SDLC: Verification =
A
started as early as possible, conducted after “code complete” stage
12
Q
SDLC: Release =
A
Creation of a clearly defined support policy
13
Q
SDLC: Response =
A
“Plan the work, work the plan…”
14
Q
Steps of SDLC Training phase:
A
- Establish training criteria – content covering secure design, development, test and privacy
- Establish minimum training frequency, n classes per year
- Establish minimum acceptable group training thresholds, organizational training targets (e.g. 80% of all technical personnel trained prior to product RTM (Requirement Traceability Matrix)
15
Q
Steps of SDLC Requirements phase:
A
- Development team identifies security and privacy requirements
- Development team identifies lead security and privacy contacts
- Security Advisor assigned
- Security Advisor reviews product plan, makes recommendations, may set additional requirements
- Mandate the use of a bug tracking/job assignment system
- Define and document security and privacy bug bars
16
Q
Steps of SDLC Design phase:
A
- Identify design techniques (layering, managed code, least privilege, attack surface minimization)
- Document attack surface and limit through default settings
- Define supplemental security ship critieria due to unique product issues
**Cross-Site scripting tests
**Deprecation of weak crypto - Threat Modeling
**Systematic review of features and product architecture from a security point of view
**Identify threats and mitigations - Online services specific requirements
17
Q
Steps of SDLC Implementation phase:
A
- Specification of approved build tools and options
- Static analysis (Tools: PREFix, /analyze (PREfast), FXCop)
- Banned APIs
- Use of operating system “defense in depth” protections (NX, ASLR, Heap Termination)
- Online services specific requirements (e.g. Cross-Site scripting, SQL injection etc.)
- Consider other recommendations (e.g. Standard Annotation Language (SAL))
18
Q
Steps of SDLC Verification Phase:
A
- Start security response planning, including response plans for vulnerability reports
- Re-evaluate attack surface
- Fuzz testing (files, installable controls and network facing code)
- Conduct “security push” (as necessary, increasingly rare)
**Not a substitute for security work done during development
**Code review
**Penetration testing and other security testing
**Review design and architecture in light of new threats - Online services specific requirements
19
Q
Steps of SDLC Release phase:
A
- Response Plan
Provide Software Security Incident Response Plan (SSIRP)
**Identify contacts for Incident Response Team and resources to respond to events
**24x7x365 contact information for 3-5 engineering, 3-5 marketing, 1-2 management (PUM and higher) individuals
**Ensure ability to service all code including “out of band” releases and all licensed 3rd party code - Final Security Review (FSR) –> verify SDL requirements are met and there are no known security vulnerabilities
Provides an independent view into “security ship readiness”
**NOT:
**A penetration test – no “penetrate and patch” allowed
**First time security is reviewed
**Signoff process
**Key Concept: determine factor on whether or not to ship, not used as a “catchall” phase for missed work in earlier phases - Archive –> Security response plan complete
**Customer documentation up-to-date
**Archive RTM source code, symbols, threat models to a central location
**Complete final signoffs on Checkpoint Express, validating security, privacy and corporate compliance policies
20
Q
Steps of SDLC Response phase:
A
Execution on respponse tasks outlined during Security Response Planning and Release Phases
21
Q
Bug Bars and Quality Gates are used to…
A
establish minimum acceptable levels of security and privacy quality
22
Q
A Bug Bar is a …
A
Quality Gate
23
Q
Example of Bug Bar:
A
- no known vulnerabilities in the application with severity “critical” or “important” at time of release
24
Q
Microsoft SDL includes:
A
- Online services development
- Line-of-Business application development
25
SDL Guidance for Agile methodologies -->
Requirements defined by frequency, not phase --> Great for projects without enddates like cloud services
- Every Sprint (most critical)
- One-TIme (non-repeating)
- Bucket (all others)
26
Seucre software development requires ...
continuous process improvement
27
Key concepts of secure software development with continuous improvement?
- “looking for bugs” doesn’t make software secure
- Must reduce the chance vulnerabilities enter into design and code
- Requires executive commitment
- Requires ongoing process improvement
- Requires education and training
- Requires tools and automation
- Requires incentives and consequences
28
Alternatives to MS SDLC?
- NIST
- OWASP SAMM
29
Threat Modeling =
a structured method to analyze assets worth of protection, to analyze possible attacks on these assets and to evaluate the risk. Based on this analysis, countermeasures (mitigations) are defined and specified as requirements.
30
Threat vs. Vulnerability
Threat --> (attacker) ever here, identifiable but not controllable
Vulnerability --> can be (fully or partially) mitigated and not present anymore
31
Vulnerability =
a weakness in a security program that can be exploited BY a threat to gain unauthorized/uncontrolled access to an asset.
32
Threat =
Anything that can exploit a vulnerability (intentionally or accidentally) and damage, obtain or even destroy an asset
33
Threat action =
final assault on system security that the threat cause (intentional or accidental)
34
Risk =
potential (%) for damage, loss or destruction of an asset as a result of a threat exploiting a vulnerability
35
Why Threat modeling?
- Better to find security flaws when there is time to fix
- Can save time, revenue and reputation of company
- Build a secure application
- Bridge the gap between developers and security
- Provides a document of all the identified threats and rated threats
- Offers knowledge and awareness of the latest risks and vulnerabilities
36
Threat modeling process
37
Brainstorming support during Threat Modeling:
- STRIDE attack classification
- OWASP Threat List
- Attack tress
38
Security Testing Principles:
- Confidentiality
- Integrity
- Authentication
- Availability
- Authorization
- Non-repudiation
39
Identify and enumrate Threats with ...
STRIDE
40
STRIDE =
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
41
Moving to Cloud -->
Datenhoheit geht verloren
42
Alternatives to STRIDE:
- Cyber Kill Chain
- MITRE ATT&CK
43
STRIDE and propery we want mapping:
