Intro to Security in SDLC

3,489 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,489
On SlideShare
0
From Embeds
0
Number of Embeds
714
Actions
Shares
0
Downloads
223
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • 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
  • Intro to Security in SDLC

    1. 1. Secure SDLC
    2. 2. Because the question is not IF The Question is WHEN
    3. 3. Protecting software is much easier if the software is built with security in mind
    4. 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. 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. 6. SOFTWARE SECURITY IS EVERYONE’S JOB
    7. 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. 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. 9. IMPLEMENTATION CHALLENGES Team Pushback Security Ownership The “Security is Special” problem “Official/Actual Adoption Dilemma” Benefits Measurement
    10. 10. Typical Engagement Models
    11. 11. AUTOMATED CODE ANALYSIS
    12. 12. LINEAR INTEGRATION APPROACH
    13. 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. 14. HOW TO GET STARTED Discovery Analyze Current Practices Define Goals Define Roadmap Execute /Oversee /Adjust
    15. 15. Case Study
    16. 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. 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. 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. 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. 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
    21. 21. Thank You Questions?

    ×