Download to read offline
![#RSAC
Continuous feedback loop success story
“I discovered the vulnerability late Friday afternoon and wasn't
quite ready to email it to them … [Etsy] had detected my requests
and pushed a patch Saturday morning before I could email them.
This was by far the fastest response time by any company I've
reported to.”
- Source:
https://www.reddit.com/r/netsec/comments/vbrzg/etsy_has_been_one_of_the_best_companies_
ive](https://image.slidesharecdn.com/asd-r02practical-appsec-lessons-learned-in-the-age-of-agile-and-devops-170420061714/75/Practical-appsec-lessons-learned-in-the-age-of-agile-and-DevOps-41-2048.jpg)
Uploaded byPriyanka Aash
Practical appsec lessons learned in the age of agile and DevOps
The document discusses the transition of application security (AppSec) practices from traditional waterfall models to more dynamic DevOps environments, emphasizing the need for teams to become self-sufficient in security. It highlights the importance of adapting legacy security practices, such as static analysis and dynamic scanning, to support faster development cycles and continuous integration. The key takeaway is that modern AppSec should focus on continuous feedback and visibility while transforming the security team's role to empower development teams rather than serve solely as gatekeepers.
More Related Content
![[DevSecOps Live] DevSecOps: Challenges and Opportunities](https://cdn.slidesharecdn.com/ss_thumbnails/20200316dsochallengesopportunities-200416111818-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Practical appsec lessons learned in the age of agile and DevOps
![Governance, Deployment & Methodologies for Agentic Automation [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day2-251112135038-a386476d-thumbnail.jpg?width=640&height=640&fit=bounds)
Practical appsec lessons learned in the age of agile and DevOps
- 1. SESSION ID:SESSION ID: #RSAC ZaneLackey Practical AppSec Lessons Learned in the Age of Agile and DevOps ASD-R02 Co-Founder / Chief Security Officer Signal Sciences @zanelackey
- 2. #RSAC Who you’ll beheckling today Started out in offense Pentester / researcher at iSEC Partners / NCC Group Moved to defense First CSO at Etsy, built and lead the four security groups Now scaling defense for many orgs Co-Founder / CSO at Signal Sciences, delivering a product that defends web applications in the DevOps/Cloud world
- 3. #RSAC So what isthis talk about anyway? Lessons learned adapting AppSec/SDLC from a Waterfall world to the DevOps/Cloud world
- 4. #RSAC Spoiler: Security shiftsfrom being a gatekeeper to enabling teams to be secure by default
- 5.
- 6. #RSAC The new realitiesin a DevSecOps world 1. Changes happen multiple orders of magnitude faster than previously Deployments go from a few a year to a few a month, week, or even day Many injection points for security drops to few injections point 2. Decentralized ownership of deployment: — The long and perilous journey of Dev->QA->Security->Dev->Sysops->Production becomes just Dev->Production — As Dev/DevOps teams own their own ability to build and deploy production infrastructure/apps, conversations with security become opt-in rather than mandated A large culture shift is necessary around this Spoken previously on this: http://www.slideshare.net/zanelackey/building-a-modern-security- engineering-organization
- 7. #RSAC The new realitiesin a DevSecOps world The combination of these two means security can no longer be “outsourced” to the security team, but rather that the security team’s mission changes to providing the resources for teams to be security self-sufficient Security only becomes successful if it can bake in to the Development/DevOps process
- 8. #RSAC How do legacyAppSec approaches fare in a DevSecOps world?
- 9. #RSAC An example oflegacy AppSec approaches in a DevOps world
- 10. #RSAC Select components ofcommon SDLCs Developer Training Threat modeling Design Reviews Static Analysis Dynamic Scanning Pentesting Feedback
- 11. #RSAC What pieces ofthe SDLC need to adapt the most?
- 12. #RSAC Which components we’lldiscuss today Developer Training Threat Modeling Design Reviews Static Analysis Dynamic Scanning Pentesting Security Visibility Feedback Continuous Feedback — Note: Just because we’re not discussing several of these items in this talk doesn’t mean you stop doing them!
- 13. #RSAC Static Analysis: It’snot a party until the 32847326th page of the report!
- 14. #RSAC Static Analysis (legacy) Traditionallydone as heavyweight process: — Run once a week/month resulting in a large output — Extensive configuration/tuning period, typically lasting months+ — Top down: search for everything, slowly refine to eliminate false positives Both of these issues were acceptable-ish in a Waterfall world where you had plenty of time in each release cycle
- 15. #RSAC How do weadapt this control?
- 16. #RSAC Static Analysis (modern) Shiftfrom from a top down model to a bottoms up one: — Identify specific classes of vulnerabilities you care about most, and start with just those — Focus on eliminating false positives and enabling velocity with the goal of only producing real issues that can be directly consumed by a developer themselves — Once completed, add one or two more vulnerabilities classes — Repeat This enables the velocity needed in DevOps of being able to run static analysis on every code commit
- 17. #RSAC Static Analysis (modern) Example:Rather than trying to start with static analysis for XSS, SQLi, Directory Traversal, Command Execution, etc all at once, pick one: — Pro tip: Pick the easiest to implement first, (ex: Command Execution) Grep’ing for system() has a pretty low false positive rate… The focus is not only on findings, but demonstrating to the development org that this approach to static analysis can bring them both value and velocity
- 18. #RSAC Static Analysis (modern) Identifyuse of certain primitives that should initiate a conversation with the security team rather than just be blocked: — Ex: Hashing, Encryption, File system operations, etc Common example: Use of hashing or encryption functions — Old approach: “MD5 is banned, use SHA256!” — New approach: “Hey, we saw you’re making use of a hashing function, can we chat on what you’re trying to protect?” — Silently allowing an approved hashing function to be used doesn’t help anyone in cases where it’s not the appropriate use, ex: a case where the data should be encrypted not hashed
- 19. #RSAC Static Analysis (modern) Buildproactive alerting to know when sensitive and rarely changed portions of the codebase have been modified — Can be as simple as alerting on when the hash changes on certain key files Ex: authorization primitives, session management, encryption wrappers, etc By not blocking on these changes, you don’t impact velocity but you ensure that the relevant security/development engineers know if key platform protections are being changed
- 20.
- 21. #RSAC Dynamic Scanning (legacy) DynamicScanning (legacy): Used to meet a baseline standard of discovering vulnerabilities: — Ex: “If a scanner can find it, we should probably fix it” Occasionally even (mis)used as a substitute for pentesting
- 22. #RSAC How do weadapt this control?
- 23. #RSAC Dynamic Scanning (modern) Applicationsarchitectures and functionality have changed significantly since scanners were pioneered in the early-mid 2000s — Modern applications are often far too complex to be effectively covered by scanners Client side functionality, single page applications, etc. In the old use cases there’s too little bang for the buck from scanners when used with modern apps However, scanners can be adapted to two cheap and effective use cases:
- 24. #RSAC Dynamic Scanning (modern) 1.Ensuring that security policies are being enforced — Ex: TLS only supporting strong ciphers — Ex: Crawl the app and ensure that CSP exists, or that X-Frame-Options header is always set to DENY 2. An extra control on ensuring previous vulnerabilities aren’t accidentally regressed back in to the application: — Ex: We had an XSS in this parameter before, always check it with this specific payload to ensure the protection didn’t get accidentally rolled back
- 25.
- 26. #RSAC Security Visibility (legacy) Logs,customer service reports, outages Each source of information was generally isolated in who had access to the data — Ex: Ops had logs, customer support dealt with emails from customers, outages would page only certain dev or ops on-call / leads, etc
- 27. #RSAC How do weadapt this control?
- 28. #RSAC Security Visibility (modern) GOAL:Break down the previous silos of data isolation and empower security, development, and DevOps teams to all know security relevant information from their application in real time This isn’t a new idea! Take principles of general operational visibility, and apply to a security perspective — Superset of operational data + security relevant data
- 29. #RSAC This graph provokeswildly different assumptions from Development, DevOps, and Security teams
- 30. #RSAC Give everyone thedata they need. Context is key, for *all* groups +
- 31.
- 32. #RSAC Feedback (legacy) Typically doneas annual pentests Unfortunately this really only answers the question “do I have bugs?” Spoiler alert: The answer is yes. Always. When applications were released annually or bi-annually that could be “real time enough” feedback
- 33. #RSAC How do weadapt this control?
- 34. #RSAC Feedback (modern) Combination ofbug bounty + pentests Bounty is not a replacement for pentest, it augments pentest Value is in the continuous nature of it, whereas pentests can be more directed Bounty gives general but more real time feedback, pentest shifts to giving more directed but less frequent feedback
- 35. #RSAC PENTEST BOUNTY DAST HIGH COVERAGE LOW FREQUENCYHIGH FREQUENCY LOW COVERAGE
- 36. #RSAC Break out theThought Leader-hosen! It’s time for some thoughts on where modern Application Security should be headed towards
- 37. #RSAC The hallmark ofa modern AppSec program is the combination of continuous feedback + visibility
- 38. #RSAC Or: To besuccessful against real attackers, you need to be able to answer the question: “How do I know when my attackers are being successful?”
- 39. #RSAC Three pillars ofeffective visibility + continuous feedback 1. Ability to detect attackers as early as possible in the attack chain You want to know when the attacker discovers the vulnerability, long before the database goes out the door 2. Ability to continuously test and refine your vulnerability triage/response The beauty of DevOps is that you can actually move faster than your attackers for the first time, especially the more you empower development / DevOps teams
- 40. #RSAC Three pillars ofeffective visibility + continuous feedback 3. Ability to continuously test and refine your incident response/DFIR/SecOps process By treating even benign bug reports as sample incidents, you can continuously exercise and adapt your process Ultimately you want to be able to answer several questions for any given bug report that comes in: Did this bounty participant find any additional issues they’re not reporting? Was this reported vulnerability exploited previously? etc
- 41. #RSAC Continuous feedback loopsuccess story “I discovered the vulnerability late Friday afternoon and wasn't quite ready to email it to them … [Etsy] had detected my requests and pushed a patch Saturday morning before I could email them. This was by far the fastest response time by any company I've reported to.” - Source: https://www.reddit.com/r/netsec/comments/vbrzg/etsy_has_been_one_of_the_best_companies_ ive
- 42.
- 43. #RSAC The thesis ofmodern application security is about shifting From: A mindset of “Exclusively focus on gatekeeping controls to eliminate bugs before code is deployed” — (An impossible goal, bugs will never be fully eliminated) To: Focus on obtaining and refining continuous visibility and feedback from deployed applications, and providing security capabilities that make developers/DevOps teams security self-sufficient
- 44.