Intro to Security in SDLC
•Download as PPTX, PDF•
9 likes•6,037 views
This document discusses implementing a secure software development lifecycle (SDLC). It emphasizes building security into software from the start rather than adding it later. The summary is: The document outlines a secure SDLC process involving defining security requirements, designing for security, implementing secure coding practices, testing software security, and ongoing security monitoring. It notes that software security is a shared responsibility and discusses challenges like team pushback and measuring security benefits. The document also presents a case study of a company that implemented a secure SDLC process to address client security issues and prevent future problems.
Report
Share
Intro to Security in SDLC
- 1. Secure SDLC
- 2. Because the question is not IF The Question is WHEN
- 3. Protecting software is much easier if the software is built with security in mind
- 4. GENERIC APPROACH FOR SECURITY Secure SDLC Proactive Approach security requirements / risk and threat analysis Design coding guidelines /code reviews/ static analysis Build Reactive Approach security testing / dynamic analysis vulnerability scanning / WAF Test Production
- 5. SECURE SDLC Governance Definition Risk Assessment Review Penetration Testing Security Awareness Trainings Security Review Incident Response Plan Response Code Analysis Security Testing Release Secure Architecture Code Reviews Verification Compliance Analysis Risk Assessment Implementation Security Requirements Design Requirements Ensure the Best Practices are integral to the development program and applied over the lifecycle of the Application Incident Forensics Security Monitoring
- 6. SOFTWARE SECURITY IS EVERYONE’S JOB
- 7. 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
- 8. ORGANIZATION CHALLENGES An organization’s behavior changes slowly over time There is no single recipe that works for all organizations • Changes must be iterative while working toward long-term goals • A solution must enable riskbased choices tailored to the organization Guidance related to security activities must be prescriptive Overall, must be simple, well-defined, and measurable • A solution must provide enough details for non-security-people • Understandable measurement can be used 8
- 9. IMPLEMENTATION CHALLENGES Team Pushback Security Ownership The “Security is Special” problem “Official/Actual Adoption Dilemma” Benefits Measurement
- 13. ITERATION BASED TEST ONLY APPROACH • After the backlog of security related items has been reviewed and evaluated by Development Management, a 2-week Development cycle (iteration) will address the highest ranked items • Upon delivery of completed code, security testing is performed both manually and using automated testing tools • Results from manual and automated scans end up in the same backlog repository, to be reviewed and prioritized by Development Management
- 14. HOW TO GET STARTED Discovery Analyze Current Practices Define Goals Define Roadmap Execute /Oversee /Adjust
- 15. Case Study
- 16. BUSINESS ISSUE Drivers: Customer Request, Potential Issues Requestor: Security Department Client knows they have an issues and requested a team to address them
- 17. SOLUTION Issues Root Cause Analysis • Tactical Goals: address existing local finding (tool generated) • Strategic Goals: address security design flaws, prevent issues reappear in the future Solution for the Strategic Goals • Team structure to Addressing and Remediation teams, achieving Tactical and Strategic Goals correspondingly • Prioritized roadmap for the Remediation Team • Security Risk Assessment • Security Architecture Analysis • Security Awareness Trainings for the Team • Roadmap for the Secure SDLC practices adoption
- 18. SOLUTION Phase 1: 1 – 2 Month Governance Definition Risk Assessment Review Penetration Testing Security Awareness Trainings Security Review Incident Response Plan Response Code Analysis Security Testing Release Secure Architecture Code Reviews Verification Compliance Analysis Risk Assessment Implementation Security Requirements FTE Security Analyst Design Requirements Team: Incident Forensics Security Monitoring
- 19. SOLUTION Phase 2: 2 – 3 Month Governance Definition Risk Assessment Review Penetration Testing Security Awareness Trainings Security Review Incident Response Plan Response Code Analysis Security Testing Release Secure Architecture Code Reviews Verification Compliance Analysis Risk Assessment Implementation Security Requirements Part Time Security Analyst Design Requirements Team: Incident Forensics Security Monitoring
- 20. VALUE Approach addressing both Tactical and Strategic Goals Decrease number of the Security issues on Project Minimize potential Security issues that might be introduced in the future Improve Security Expertise/Practices for current Team Experience Sharing with Client Security Program POC Remediation Approach for other Products in Client Portfolio
Editor's Notes
- Case of the Security Program Building, Security Remediation Project. Key Challenge is Optimization and prioritizationof the efforts All these activities need to be done by right people, Security Engineer vs. Software Engineer vs. Quality Engineer mindset is different.
- SDLC applicability to the Project Roles. Ownership and contribution
- Presenter for this slide: Jimmy Nix