AppSec in an Agile World
•
2 j'aime•370 vues
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.
![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”]
}](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à AppSec in an Agile World
Similaire à AppSec in an Agile World (20)
Dernier
Dernier (20)
AppSec in an Agile World
- 1. AppSec in an Agile World Wednesday, May 16 11:00AM 2018 Secure360 Twin Cities @secure360 www.Secure360.orgfacebook.com/secure360 David Lindner
- 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. • Dev Types • Security and the SDLC • Integrating AppSec into Process Agenda
- 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. • 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. 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. Waterfall 1. Concept 2. Requirements 3. Design 4. Code 5. Test 6. Deploy 7. Support (maybe)
- 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. Agile 1. Design • Stories 2. Build 3. Test • Unit Tests • Security Tests 4. Release
- 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. • Many different methodologies • Extreme Programming (XP) • Scrum • Crystal • Dynamic Systems Development Method (DSDM) • Lean Development • Feature-Driven Development (FDD) • And more…. Agile Methodologies
- 12. Agile and Application Security
- 13. DevOps
- 14. DevOps
- 15. • Everyone is responsible for security • Security as code • Ensure data security DevSecOps
- 16. So you say security…..
- 17. Systems used to look like this Client (Web Browser) Web Application + Apache Tomcat Database Monolithic
- 19. • 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
- 20. • 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
- 21. • 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
- 22. Threat Modeling
- 23. • 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
- 24. • 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
- 25. • Vulnerability Analysis • Tools • Manual discovery Testing and Verification Scoping and Rules of Engagement Pre- engagement and Recon Vulnerability Analysis Exploitation and Post Exploitation Reporting
- 26. • 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
- 27. • 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
- 28. • 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
- 29. • 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
- 30. Security Tooling • Static Code Analysis § FindSecurityBugs § Brakeman § ESLint § Phan § etc • Dynamic Scanning § ZAP § BurpSuite § Sqlmap § ssllabs-scan
- 31. Security Tooling • Dependency Mgmt § Dependency Check § Bundler-Audit § Retire.js • IDE Plugins § DevSkim § FindSecurityBugs § Puma Scan § Sonar Lint
- 32. • Secure DevOps Toolchain and SWAT • https://www.sans.org/security-resources/posters/appsec/secure-devops- toolchain-swat-checklist-60 Security Tooling
- 33. • 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?
- 34. Continuous Integration What problem does CI solve?
- 35. • Not Continuous Deployment • All changes “could” go to production but may not • How can we provide security benefit with CD? Continuous Delivery
- 36. Building a Secure CI/CD Pipeline
- 37. 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
- 38. Integrate Teams
- 39. 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
- 41. 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.
- 42. 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.
- 43. • Current security issues • With details • Fixed issues • New threats • All tracked in bug tracker Issue Tracking
- 44. OLD Security and the SDLC
- 45. 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
- 46. • What is your application’s current security posture? • What is current? 1 year? 1 month? 1 day? Current Security Posture?
- 47. • 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
- 48. • What is your application’s current security posture? • What is current? 1 year? 1 month? 1 day? Current Security Posture?
- 49. Process Integration Application Security is not a unicorn
- 50. Process Integration – Risks of Gating
- 51. Process Integration Integrate into the processes and existing workflows. If they don’t exist, help create them. Design Design Review Code Review Test Deploy
- 53. 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