Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AppSec in an Agile World

285 views

Published on

In the ever-evolving, fast-paced Agile development world, application security has not scaled well. Incorporating application security and testing into the current development process is difficult, leading to incomplete tooling or unorthodox stoppages due to the required manual security assessments. Development teams are working with a backlog of stories—stories that are typically focused on features and functionality instead of security. Traditionally, security was viewed as a prevention of progress, but there are ways to incorporate security activities without hindering development. There are many types of security activities you can bake into your current development lifecycles—tooling, assessments, stories, scrums, iterative reviews, repo and bug tracking integrations—every organization has a unique solution and there are positives and negatives to each of them. In this slide deck, we go through the various solutions to help build security into the development process.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

AppSec in an Agile World

  1. 1. AppSec in an Agile World Wednesday, May 16 11:00AM 2018 Secure360 Twin Cities @secure360 www.Secure360.orgfacebook.com/secure360 David Lindner
  2. 2. Who is this guy? class Speaker { let name = “David Lindner” let title = “Chief Strategy Officer” let company = ”nVisium" let twitter = “@golfhackerdave” var hobbies = [“Dadding”, ”Golf”, “IoT/Mobile”, “Fishing”] }
  3. 3. • Dev Types • Security and the SDLC • Integrating AppSec into Process Agenda
  4. 4. • Need for executive level support • Need for a program with governance, people, process, and tools • Collaborative relationships between teams • Authentication/Authorization, Input handing, crypto, logging… • Need for Threat Models, Secure Design, etc. • Still write code, for the most part… What hasn’t changed
  5. 5. • Architecture patterns • Development methodologies have changed • The speed of development/deployment • The need for tooling and automation has greatly increased • The infrastructure that applications live on • Who is responsible for the infrastructure What has changed
  6. 6. The Changing State of Development Waterfall Agile DevOps Monolithic Apps Physical Bare Metal Physical Bare Metal VMs Containers Public/Private N-Tier Apps Microservices & APIs
  7. 7. Waterfall 1. Concept 2. Requirements 3. Design 4. Code 5. Test 6. Deploy 7. Support (maybe)
  8. 8. • After development • Usually perform yearly assessments • Standalone tools • Manual assessments • Time consuming • No real understanding of current security posture Waterfall and Application Security
  9. 9. Agile 1. Design • Stories 2. Build 3. Test • Unit Tests • Security Tests 4. Release
  10. 10. • Early 1990s referred to as ”the application development crisis” • Time between business need and application was about 3 years • Snowbird meeting in Utah in 2001 • The Agile Manifesto Agile Development
  11. 11. • Many different methodologies • Extreme Programming (XP) • Scrum • Crystal • Dynamic Systems Development Method (DSDM) • Lean Development • Feature-Driven Development (FDD) • And more…. Agile Methodologies
  12. 12. Agile and Application Security
  13. 13. DevOps
  14. 14. DevOps
  15. 15. • Everyone is responsible for security • Security as code • Ensure data security DevSecOps
  16. 16. So you say security…..
  17. 17. Systems used to look like this Client (Web Browser) Web Application + Apache Tomcat Database Monolithic
  18. 18. • Authentication • Username • Password, MFA • Account Management • Authorization • Role-Based Access Control • Attribute-Based Access Control • Rule-Based Access Control • Input Handling • Test input for type, length, context • Output encode contextually • Privacy • Need to know access to customer/client data • Cryptography • Standard algorithms, strengths, and modes • What data to encrypt at rest/in transit • Third-party libraries • Maintain list of 3rd party dependencies • Monitor updates to known dependencies • Logging/Audit • Standard format • Criteria for what to/not to log and when • Criteria for who should review and when • Error and Exception Handling • Criteria for error messages (include/not include) • When to fail open/closed Security Standards should be technology agnostic. They should be fairly static, however, if vulnerabilities are found without a matching standard, consider updating them. Security Standards
  19. 19. • Understand the inherent risk of an application • Prioritize resources and security investments • Gain a better understanding of the risk presented by the applications • Process for completion and maintenance of application catalog • Inherent Risk “…is an assessed level of raw or untreated risk; that is, the natural level of risk inherent in a process or activity without doing anything to reduce the likelihood or mitigate the severity of a mishap, or the amount of risk before the application of the risk reduction effects of controls.” Gregory Monahan (2008). Enterprise Risk Management: A Methodology for Achieving Strategic Objectives. John Wiley & Sons. • 20-25 Question survey to measure: • People • Process • Infrastructure • Data Application Risk Categorization
  20. 20. • Least-Privilege • Default-Deny • Economy of Mechanism • Complete Mediation • Open Design • Separation of Concern • Least Common Mechanism • Psychological Acceptability • Defense-in-Depth • And more… Secure Design Principles Resources: OWASP Security by Design Principles https://www.owasp.org/index.php/Security_by_Design_Principles IEEE Avoiding Common Security Design Flaws http://www.computer.org/cms/CYBSI/docs/Top-10-Flaws.pdf
  21. 21. Threat Modeling
  22. 22. • Scoping and Rules of Engagement • In scope and out of scope targets • Contact information • Debriefing schedule Scoping and Rules of Engagement Pre- engagement and Recon Vulnerability Analysis Exploitation and Post Exploitation Reporting Testing and Verification
  23. 23. • Pre-engagement and Recon • Black box or white box? • Permission to test all in scope targets? • OSINT and Recon Testing and Verification Scoping and Rules of Engagement Pre- engagement and Recon Vulnerability Analysis Exploitation and Post Exploitation Reporting
  24. 24. • Vulnerability Analysis • Tools • Manual discovery Testing and Verification Scoping and Rules of Engagement Pre- engagement and Recon Vulnerability Analysis Exploitation and Post Exploitation Reporting
  25. 25. • Exploitation and Post Exploitation • Create or recreate any exploits • Document exploits • Perform agreed upon level of post exploit activities • Clean up exploit data Testing and Verification Scoping and Rules of Engagement Pre- engagement and Recon Vulnerability Analysis Exploitation and Post Exploitation Reporting
  26. 26. • Reporting • When and how long was the testing • What process was followed • What was found and what are the risk levels • How can issues be recreated • How can issues be fixed Testing and Verification Scoping and Rules of Engagement Pre- engagement and Recon Vulnerability Analysis Exploitation and Post Exploitation Reporting
  27. 27. • Do you know what code is in your applications and who put it there and when? • Intentional malicious code • Unintentional malicious code • Open Source with unfriendly licensing • Dependency Squatting • Embarrassed Developer Software Integrity
  28. 28. • Git • Build a process to review with pull requests • Restrict access to the Master branch (If not Github, make the Git repo only writeable by one user, and make it readable by all others. That way they can fork and issue a PR to the master.) • Provide reviewers with review baseline • Sign commits with PGP • Ensure that all users are only internal accounts • If using GitHub, ensure that SSH keys are not shared across accounts. • Standard Review Baseline • Develop a baseline to review commits • Certain functions, keywords, size • Initially not all commits would need to be reviewed • Automate many checks in later phases • Code Signing • Verify code is what it should be • Verifiable update mechanism • Do you check for signature? • Hash? Software Integrity Examples
  29. 29. Security Tooling • Static Code Analysis § FindSecurityBugs § Brakeman § ESLint § Phan § etc • Dynamic Scanning § ZAP § BurpSuite § Sqlmap § ssllabs-scan
  30. 30. Security Tooling • Dependency Mgmt § Dependency Check § Bundler-Audit § Retire.js • IDE Plugins § DevSkim § FindSecurityBugs § Puma Scan § Sonar Lint
  31. 31. • Secure DevOps Toolchain and SWAT • https://www.sans.org/security-resources/posters/appsec/secure-devops- toolchain-swat-checklist-60 Security Tooling
  32. 32. • So we have all these security practices…. • How do we go from Waterfall AppSec to a more continuous security model? • Tools are only so good • False Positives • Can’t handle assessing Access Control or Environmental controls • Manual is normally slow and a hindrance What’s Next?
  33. 33. Continuous Integration What problem does CI solve?
  34. 34. • Not Continuous Deployment • All changes “could” go to production but may not • How can we provide security benefit with CD? Continuous Delivery
  35. 35. Building a Secure CI/CD Pipeline
  36. 36. Discovery • Review what you have, what you want to do, what tools work best for you • Make it an interactive process with artifact reviews, face to face conversations, white boarding
  37. 37. Integrate Teams
  38. 38. Implement Automation • Use CI triggers to determine when scanning activity is required • Work with development teams to implement unit-tests in the language or testing framework already in use • Determine how best to utilize messaging services, notify the security teams as to when scans begin and when the results should be reviewed
  39. 39. Automation Develop Test Build Security Deploy
  40. 40. Determine Risk and Actions Risk Rating Testing Method Action Taken High, Medium, Low Unit-Tests (All environments) Failing unit-tests should mean that code will not be deployed until all the unit-tests pass, whether or not the unit-test fails because it is broken or because the application is vulnerable. High, Medium Dynamic Scanning - Production Env Code should not enter production. The security team should be notified immediately. Low Dynamic Scanning - Production Env Remediation should be prioritized by an agreed timeline between the security team and product managers. High, Medium, Low Dynamic Scanning - Alpha Env Unless the vulnerability is a known false positive or an issue that the security team has accepted as a necessary risk, the code triggering new issues should be resolved prior to moving any further in the development pipeline.
  41. 41. Security Implementation • Integrate security testing into automation • Create a system with early detection and efficient remediation of security vulnerabilities that are part of the development process • Eliminate existing duplicate dependencies in order to de- duplicate outstanding tickets and updated outstanding tickets in JIRA.
  42. 42. • Current security issues • With details • Fixed issues • New threats • All tracked in bug tracker Issue Tracking
  43. 43. OLD Security and the SDLC
  44. 44. OLD SDLC and Security Process The old way to do it was to have a separate SDLC and security process with different tracking systems. Who still does this? UX Workflow Design Coding Testing QA SDLC Bug Tracker Report Scope Recon Analyze Exploit Document Security Security Issues Tracker
  45. 45. • What is your application’s current security posture? • What is current? 1 year? 1 month? 1 day? Current Security Posture?
  46. 46. • Scrum • Analysis • Planning • Design • Coding • Testing • Releases NEW Secure SDLC Process Integrate security into a defined process, don’t attempt to create a parallel security process. Many activities within the SDLC process simply need to be done with a security mindset, checklist, guide, or similar support. Business Analysis Define User Stories Refine Feature List -Business Requirements -User Requirements -Estimate -Scoping Sprint Planning Meeting Daily Work Sprint Review UX Workflow Design Coding Testing QA SDLC Threat Modeling Secure Design Principles IDE Tooling Security Automation Change Management Defect Tracker
  47. 47. • What is your application’s current security posture? • What is current? 1 year? 1 month? 1 day? Current Security Posture?
  48. 48. Process Integration Application Security is not a unicorn
  49. 49. Process Integration – Risks of Gating
  50. 50. Process Integration Integrate into the processes and existing workflows. If they don’t exist, help create them. Design Design Review Code Review Test Deploy
  51. 51. Relationships & Collaboration
  52. 52. What did we learn? • Application Security is hard, but we need to keep trying • There is no easy button or one stop shop for everything you may need • Every org has different needs and requirements • We all need to work together
  53. 53. @secure360 www.Secure360.orgfacebook.com/secure360 david.lindner@nvisium.com @golfhackerdave https://linkedin.com/in/dlindner Questions?

×