Download as PDF, PPTX
![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”]
}](https://image.slidesharecdn.com/appsecagile-180516193527/75/AppSec-in-an-Agile-World-2-2048.jpg)
Uploaded byDavid Lindner
AppSec in an Agile World
The document discusses the integration of application security (AppSec) within Agile and DevOps methodologies, emphasizing the need for executive support, governance, and collaboration among teams. It outlines the transition from traditional waterfall development to Agile practices and highlights the importance of security tools and processes throughout the software development lifecycle. Key points include the necessity of threat modeling, secure design principles, and continuous security integration into development and deployment processes.
More Related Content
Similar to AppSec in an Agile World
AppSec in an Agile World
- 1. AppSec in an AgileWorld Wednesday, May 16 11:00AM 2018 Secure360 Twin Cities @secure360 www.Secure360.orgfacebook.com/secure360 David Lindner
- 2. Who is thisguy? 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 forexecutive 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 Stateof 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 1990sreferred 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 differentmethodologies • Extreme Programming (XP) • Scrum • Crystal • Dynamic Systems Development Method (DSDM) • Lean Development • Feature-Driven Development (FDD) • And more…. Agile Methodologies
- 12. Agile and ApplicationSecurity
- 13.
- 14.
- 15. • Everyone isresponsible for security • Security as code • Ensure data security DevSecOps
- 16. So you saysecurity…..
- 17. Systems used tolook 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 theinherent 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.
- 23. • Scoping andRules 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 andRecon • 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 andPost 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 • Whenand 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 youknow 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 • Builda 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 • StaticCode Analysis § FindSecurityBugs § Brakeman § ESLint § Phan § etc • Dynamic Scanning § ZAP § BurpSuite § Sqlmap § ssllabs-scan
- 31. Security Tooling • DependencyMgmt § Dependency Check § Bundler-Audit § Retire.js • IDE Plugins § DevSkim § FindSecurityBugs § Puma Scan § Sonar Lint
- 32. • Secure DevOpsToolchain and SWAT • https://www.sans.org/security-resources/posters/appsec/secure-devops- toolchain-swat-checklist-60 Security Tooling
- 33. • So wehave 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 problemdoes CI solve?
- 35. • Not ContinuousDeployment • All changes “could” go to production but may not • How can we provide security benefit with CD? Continuous Delivery
- 36. Building a SecureCI/CD Pipeline
- 37. Discovery • Review whatyou 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.
- 39. Implement Automation • UseCI 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
- 40.
- 41. Determine Risk andActions 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 • Integratesecurity 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 securityissues • With details • Fixed issues • New threats • All tracked in bug tracker Issue Tracking
- 44. OLD Security andthe SDLC
- 45. OLD SDLC andSecurity 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 isyour 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 isyour application’s current security posture? • What is current? 1 year? 1 month? 1 day? Current Security Posture?
- 49. Process Integration Application Securityis not a unicorn
- 50. Process Integration –Risks of Gating
- 51. Process Integration Integrate intothe processes and existing workflows. If they don’t exist, help create them. Design Design Review Code Review Test Deploy
- 52.
- 53. What did welearn? • 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
- 54.