Secure Software Development Adoption Strategy
5 likes2,435 views
This document discusses adopting a secure software development strategy at Kiatnakin Bank. It recommends starting with a goal like the OWASP Top 10 controls, establishing an application security team, processes like code reviews and testing, baseline frameworks and guidelines, introducing security design concepts, and setting security checkpoints. The presentation emphasizes building knowledge, leading change, and getting management support to successfully adopt secure development practices.
Secure Software Development Adoption Strategy
- 1. Secure Software DevelopmentSecure Software Development Adoption StrategyAdoption Strategy Narudom Roongsiriwong, CISSP
- 2. WhoAmI ● Lazy Blogger – Japan, Security, FOSS, Politics, Christian – http://narudomr.blogspot.com ● Information Security since 1995 ● Web Application Development since 1998 ● Head of IT Security and Solution Architecture, Kiatnakin Bank PCL (KKP) ● Consultant for OWASP Thailand Chapter ● Committee Member of Cloud Security Alliance (CSA), Thailand Chapter ● Consulting Team Member for National e-Payment project ● Contact: [email protected]
- 3. Background ● June 2014 – Invitation from Kiatnakin Bank to discuss how to improve in- house software security. ● August 2014 – 5-Day Training for KK developers about concept, requirement, design and implementation of the application security ● December 2014 – Joining KK as VP, Head of IT Security, no team member. ● January 2015 – First report on secure code review, Corporate Internet Banking system ● February 2015 – First release of KK secure coding guideline, adapted from OWASP Testing Guide, PCI DSS and other best practices ● March 2015 – KK SDLC regulation announcement, including secure development life cycle ● May 2015 – KK application log specification released
- 4. Application Security Training at KK, August 2014
- 5. What Are Application Security Risks? Source: OWASP: Open Web Application Security Project
- 6. OWASP Top 10 2013 Risk Source: OWASP: Open Web Application Security Project
- 7. Security controls cannot deal with broken business logic such as A2, A4 and A7 Security controls cannot deal with broken business logic such as A2, A4 and A7 Software weaknesses reduction down to zero is possible Software weaknesses reduction down to zero is possible Reduce Security Weaknesses vs Increase Security Controls
- 8. Source: Patrick Thomas (twitter @coffeetocode)
- 9. Security as an Afterthought Relative cost of security fixes, based on time of detection Source: The National Institute of Standards and Technology (NIST) Implementation Challenges
- 10. How Can We Start?
- 11. >>> Set the Goal ● Which level of secure software development we want to achieve? – Minimal – OWASP Top 10 Proactive Controls – Intermediate – Microsoft Security Development Lifecycle – Expert – OpenSAMM (OWASP’s Software Assurance Maturity Model) ● Is that level sufficient for our business? ● How much our confidence to achieve that level?
- 12. Option#1: OWASP Top 10 Proactive Controls C1: Verify for Security Early and Often C2: Parameterize Queries C3: Encode Data C4: Validate All Inputs C5: Implement Identity and Authentication Controls C6: Implement Appropriate Access Controls C7: Protect Data C8: Implement Logging and Intrusion Detection C9: Leverage Security Frameworks and Libraries C10: Error and Exception Handling Source: https://www.owasp.org/index.php/OWASP_Proactive_Controls
- 13. Option#2: Security Development Lifecycle https://www.microsoft.com/en-us/sdl
- 14. Option#3: OWASP’s Software Assurance Maturity Model Source: OWASP’s Software Assurance Maturity Model (OpenSAMM)
- 15. >>> Build A-Team ● Mentors ● Software Security Architects ● Security Designers ● Secure Code Reviewers ● Application Penetration Testers
- 16. >>> Establish Processes ● Embed security gates in the existing processes – Project Kick Of – Requirement Gathering – Solution Design – Architecture Review – Incident Response ● Create additional processes – Code Review – Application Penetration Testing – Production System Security Configuration Review
- 17. >>> Set Up Baseline ● Desired frameworks, for example – Java: Spring + Hibernate – .NET: MVC (Web), Entity Framework ● Development guidelines – Secure software requirement – Security patterns – Standard application log specification
- 18. >>> Introduce Design Concept ● Need to Know ● Least Privilege ● Separation of Duties ● Defense in Depth ● Fail Secure / Fail Safe ● Economy of Mechanisms ● Complete Mediation ● Open Design ● Least Common Mechanisms ● Psychological Acceptability ● Leveraging Existing Components
- 19. Set Security Checkpoint ● Business Requirement Sign Of ● Solution Architect Review ● Code Review ● Application Penetration Testing ● Change Advisory Board
- 21. >>> Lead the Change The Big Opportunity For Example: Using John P. Cotter’s “Eight Steps to Transforming Your Organization”
- 22. Lessons Learned ● Making developers know security is easier than making security persons know software development. ● Keys of secure software development adoption – Repeat design concepts regularly – Use security patterns – Set security checkpoints – Guide developers to fix security bugs – Get top management supports