Agile and Secure SDLC
Download as PPTX, PDF10 likes9,657 views
This document discusses implementing a secure software development lifecycle (SDLC) to improve application security. It outlines why the traditional approach of only involving security experts does not work. Instead, it proposes integrating security practices throughout each phase of the development process, including requirements, design, implementation, verification, and release. This includes training developers, conducting threat modeling and security testing, using security tools in continuous integration, and analyzing results to address issues early. The goal is to reduce security defects over time by changing developer mindsets and integrating security as applications are built.
Agile and Secure SDLC
- 1. Secure SDLC. Approach and realization by Nazar Tymoshyk, Ph.D., CEH
- 2. Even best applications get challenges
- 3. Big applications get bigger challenges
- 4. Security is important factor for your app
- 5. Consequences Reputation loss Penalties Data loss
- 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
- 8. Web application firewall Microsoft IIS Apache Nginx
- 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
- 14. Risks are for managers, not developers
- 15. Typical Security Report delivered by security firm
- 16. Typical Security Report delivered by other auditor
- 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.
- 23. Microsoft SDL
- 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
- 32. CI SECURITY
- 34. Continuous Integration Delivery Deployment
- 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
- 39. Supported Languages • Java • .NET (C#, ASP.NET, and VB.NET) • JSP • Client-side JavaScript • Cold Fusion • C/C++ • Classic ASP (both JavaScript/VBScript) • PHP, Perl • Visual Basic 6 • COBOL • T-SQL, PL/SQL
- 40. Analysis of App Security Statistic
- 41. Sonar – for code quality coverage
- 42. Code Security Analysis We are able to detect line of bugged code
- 44. It really works! Applications Secured - Business Protected
- 45. THANK YOU 45 Email: root.nt@gmail.com Skype: root_nt