6. IP Theft
Breaching
organizational
perimeters
Modify Victims
website to deploy
MALWARE to website
visitors
Threats
Taking over high-value
accounts
7. Hackers
motives
Previously, attackers used application vulnerabilities
to cause embarrassment and disruption. But now
these attackers are exploiting vulnerabilities to steal
data and much more
9. CYA
(cover your apps)
Time-to-Fix vs.
Time-to-Hack
Automated
Temporary Patches
10. Why
• Effective design of protected code requires a change in
the mindset of the participants involved.
• Existing training resources impose on their study of the
causes and consequences of resistance consequences
instead of eliminating the causes.
• Following the conventional approach, the designer
must be qualified penetration tester to start writing
secure code.
• It DOES NOT WORK!
11. WHY
• Effective design of protected code requires a change in the mindset
of the participants involved.
• Existing training resources impose on their study of the causes and
consequences of resistance consequences instead of eliminating the
causes.
• Following the
conventional approach,
the designer must be
qualified penetration
tester to start writing
secure code.
It DOES NOT
WORK!
12. Developer
• Focus on functional requirements
• Know about:
– OWASP Top 10
– 1 threat (DEADLINE fail)
• Concentrated on risks
«I know when I’m writing code I’m not
thinking about evil, I’m just trying to think about
functionality» (с) Scott Hanselman
13. Security Officer
• Focused on
requirement to
security
• Known difference
between vulnerability
and attack
• Focused on
vulnerabilities
17. How security is linked to development
3rd party or internal audit
Tone of
security
defects
BACK to re-Coding, re-Building, re-Testing, re-Auditing
Than start process of re-Coding, re-Building, re-Testing, re-Auditing
18. How much time you need to fix
security issues in app?
19. How it should look
With proper Security Program number of
security defects should decrease from phase
to phase
Automated
security
Tests
CI
integrated
Manual
security
Tests
OWASP methodology
Secure
Coding
trainings
Regular
Vulnerability
Scans
20. Primary Benefits
Minimize the costs of the Security related issues
Avoid repetitive security issues
Avoid inconsistent level of the security
Determine activities that pay back faster during current
state of the project
22. Mapping SDL to Agile
•Every-Sprint practices: Essential security
practices that should be performed in
every release.
•Bucket practices: Important security
practices that must be completed on a
regular basis but can be spread across
multiple sprints during the project
lifetime.
•One-Time practices: Foundational
security practices that must be
established once at the start of every new
Agile project.
24. Training
PRE SDL TRAINING:
• Introduction to Microsoft SDL
• Essential Software Security Training for the
Microsoft SDL
• Basics of Secure Design, Development and
Test
• Introduction to Microsoft SDL Threat
Modeling
• SDL Quick Security References
• SDL Developer Starter Kit
25. Requirements Phase
• SDL Practice #2: Establish Security and
Privacy Requirements (one time practice)
• SDL Practice #3: Create Quality Gates/Bug
Bars
• SDL Practice #4: Perform Security and
Privacy Risk Assessments (one time
practice)
26. Design
• Establish Design Requirements (one time
practice)
• Attack Surface Analysis/Reduction (one time
practice)
• Use Threat Modeling
• Mitigation of threats
• Secure Design
• Formulating security guidelines
• Security Design Review
27. Implementation
• SDL Practice #8: Use Approved Tools
• SDL Practice #9: Deprecate Unsafe
Functions
• SDL Practice #10: Perform Static Analysis
28. Verification Phase
Bucket practices:
• SDL Practice #11: Perform Dynamic
Analysis
• SDL Practice #12: Fuzz Testing
• SDL Practice #13: Attack Surface Review
29. Release Phase
• SDL Practice #14: Create an Incident
Response Plan (one time practice)
• SDL Practice #15: Conduct Final Security
Review
• SDL Practice #16: Certify Release and
Archive
30. Response Phase
• SDL Practice #17: Execute Incident
Response Plan
– Analysis vulnerability information
– Risk calculation
– Patch release
– Clients notification
– Information publishing
31. Value
20-40% time for testing/re-testing decrease
Catch problems as soon as possible
Avoid repetitive security issues
Improve Security Expertise/Practices for current Team
Automation, Integration, Continuously
Proactive Security Reporting
Full coverage
35. High level vision
Static Code Analysis Dynamic Security testing
CI tools
Deploying application
Security Reports
Pull source code
36. CI Security process
Build
• Build code
with special
debug
options
Deploy
• Pack build
and code
• Deploy app
to VM for
test
Test
Security
• Run code
test
• Run Test
dynamic
web
application
from VM
with security
tools
Analyze
• Collect and
format
results
• Verify results
• Filter false
positive /
negative
• Tune
scanning
engine
• Fix defects
37. CI Workflow
Dynamic tests with Security scanner
OWASP Top 10 Risk coverage
A1-Injection
A2-Broken Authentication and Session
Management
A3-Cross-Site Scripting (XSS)
A4-Insecure Direct Object References
A5-Security Misconfiguration
A6-Sensitive Data Exposure
A7-Missing Function Level Access Control
A8-Cross-Site Request Forgery (CSRF)
A9-Using Components with Known
Vulnerabilities
A10-Unvalidated Redirects and Forwards
38. Tools for Secure SDLC
• IBM AppScan Sources
• Burp Suite
• Sonar
• OWASP ZAP
• HP Fortify
• Netsparcer
• Coverify
• Veracode