A journey into Application Security
2 likes1,212 views
The document discusses the evolution of application security in relation to software development methodologies, contrasting the traditional waterfall model with agile and DevOps approaches. It emphasizes the need for security to be integrated throughout the development phases, backed by the Microsoft Secure Development Lifecycle (SDL) and adapts its practices for agile environments. Additionally, it presents 'rugged software' as a concept for organizations to proactively create secure and resilient software amidst evolving threats.
A journey into Application Security
- 1. A Journey into Application Security Christian Martorella ISACA Italy 2014 Venezia, 3rd October
- 2. Who am I • Principal Program Manager, Product Security Skype – Microsoft • Edge-‐Security: Wfuzz, theHarvester, Metagoofil, Webslayer • Presented in many Security conferences: Hack.lu, BlackhatArsenal, Source, OWASP Summit, OSIRA • CIS(A,M,SP), OPS(T,A)
- 3. My background • Started as internal security auditor (Offensive) • System and network security responsible of a small ISP (Defensive) • Penetration tester -‐> Team leader (Offensive) • Practice lead for Threat and Vulnerability in EMEA (Offensive) • Product Security Analyst in Skype (Defensive)
- 4. Introduction This presentation is about the evolution of software development and the relation with Applicationsecurity. How application security teams adapted over time and the challenges we are facing
- 7. Waterfall development • Originated from the manufacturing and construction industries. • Hardware oriented model adapted to Software development • Sequential design process • Introduced by Winston Royce in the ’70
- 8. Waterfall development • Make sure each phase is 100% complete and absolutely correct before proceeding to the next phase • Emphasis on documentation • Project span across long period of time • Time spent early on making sure requirements and design are correct saves much time and effort later.
- 9. Application Security Microsoft Secure Development Lifecycle (SDL) Set of software development process improvements Born in 2002 and established in 2004, as result of MS Trustworthy Computer (TWC) initiative. More than 50% less vulnerabilities in shipped code
- 11. SDL evolution
- 12. Security approach Influence in the Design phase: • All functional and design specifications, regardless of document size, should contain a section describing how the component impacts security • Threat Modeling: Understand assets to protect, threats and vulnerabilities to the product and how will be mitigated. Critical to create a secure software Most important phase in Waterfall
- 13. Security approach Development phase: Implement security tools: • Static analysis, Banned Apis, FxCop, /Analyze Implement security checklist Secure coding best practices Verification / Release phase: Fuzzing Verify / validate Threat Model Final security review (FSR) Security testing by another team or third party
- 14. Challenges • Lack of security requirementsin design phase will make it difficult to add them in later stages • Non iterative nature makes difficult to fix issues identified in advanced stages of development • Issues detected in the Final review, will be expensive to fix
- 16. Agile development • Cross functional teams, self organizing • Short time boxed development iterations • Delivery of small functional stories • Listen to customer needs and adapt • Usually low in documentation
- 17. Agile Manifesto Individuals and interactionsover processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
- 20. Challenges • SDL too complex to fit in each release/Sprint • Design, requirements evolve over time • New interactions with third parties are not known in advance • Teams usually don’t have an Application Security specialist • Teams move faster than Waterfall • New code is being pushed to production every week or even days. • Low on documentation
- 21. SDL for Agile
- 22. SDL for Agile The categorization of SDL requirements into: • every-‐sprint • one-‐time • Three bucket groups (Verification, design, Response) is the SDL-‐Agile solution for dealing with SDL in Agile environments
- 23. Recommendations • Training the teams and providing them with tools is the most important aspect in order to implement SDL in Agile teams • Security specialist assigned to a few teams, to provide consultancy • Useful to participate in Sprint planning to understand what is going on • Sprint Security Checklist (FSR), after Sprint planning • Get familiar with Agile tools, backlog.
- 24. SDL for Agile • Continuous Integration (Automation): Secure Code analysis Security unit test Vulnerability scanning Secure configuration
- 25. Happiness
- 26. Cloud fotos
- 27. Cloud • “We want to start using Cloud services”
- 28. Challenges • Security of the data • Security of the servers • Who is responsible for the servers • Where is the data located • Encryption at rest • Disks reutilization
- 29. Security Approach • New Security policy for Cloud services • Security Onboarding for teams • Inventory of cloud services
- 31. DEVOPS
- 32. Why Devops? • Continuous software delivery • Faster delivery of features • Faster resolution of problems • Less complex problems to fix More Deploys Means Faster Time to Market and Continual Improvement
- 34. Challenges • Rapid releases cycles (every day, multiple times a day) • Autonomous teams • Teams are doing development and operations now • Infrastructure also changes fast
- 38. Surviving Devops • Providing security training to teams • Provide security policies, guidelines • Security and abuse stories, driven by business • Situational awareness: • What do we have? • Changes, alerts. • Attack surface, priorities
- 39. Surviving Devops • Automation: • Integrate testing into continuous integration and release process (Chef & Puppet) • Integrate and extend production configuration monitoring • Develop your own security testing tools, more focused and adapted to your particular needs
- 40. Surviving Devops Situational awareness & Automation example: -‐Source code Product attack surface analyzer, alerts, prioritization of efforts. -‐Internet footprint, scanning and inventory. Updated every hour.
- 41. Surviving Devops • Integrate InfoSec and IR into the Ops/Devs escalation process • Harden the production environment • Provide guidelines/baselines on what is a hardened environment • Automate hardening (Chef/Puppet) • Tolerate failure in production environments (Chaos Monkey)
- 42. Surviving Devops • Metrics: • Identify if teams are repeating certain type of vulnerabilities, train them to prevent repeating again. • Prioritize training • Modify policies and baselines • Tune tools • Interact more closely with teams, attend to standups • Be more flexible and adapt to team processes • mesh with the unique development cultures of individual teams
- 43. The Future? Rugged software “Rugged” describes software development organizations which have a culture of rapidly evolving their ability to create available, survivable, defensible, secure, and resilient software Rugged is NOT a technology, process model, SDLC, or organizational structure. It’s not even a noun.
- 44. Rugged software Rugged describes staying ahead of the threat over time “We are convinced that negative and reactive approaches to application security cannot scale and are doomed to fail. These approaches primarily rely on finding vulnerabilities and fixing them.”
- 45. Rugged Manifesto I am rugged and, more importantly, my code is rugged. I recognize that software has become a foundation of our modern world. I recognize the awesome responsibility that comes with this foundational role. I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended. I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security. I recognize these things – and I choose to be rugged. I am rugged because I refuse to be a source of vulnerability or weakness. I am rugged because I assure my code will support its mission. I am rugged because my code can face these challenges and persist in spite of them. I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.
- 46. Conclusion • Development methodologies and processes changed considerably over time • More things happening in shorter period of time • Security tools and techniques needs to adapt to this situation • Automation is key in Devops environment • Security professionals need to be flexible and engage more than ever with development teams
- 47. ?
- 49. Resources • Microsoft SDL -‐ http://www.microsoft.com/security/sdl/default.aspx • Rugged Software -‐ https://www.ruggedsoftware.org/ • http://labs.securitycompass.com/appsec-‐2/the-‐cultural-‐challenges-‐of-‐ application-‐security/ • http://devops.com/features/the-‐unexpected-‐benefits-‐of-‐devops/ • http://newrelic.com/devops/benefits-‐of-‐devops