Download to read offline
Uploaded byNetlight Consulting
Application Security within Agile
Dimitrios Stergiou discusses application security approaches, highlighting ineffective strategies like bolt-on security and extreme security measures, while advocating for a balanced process aligned with agile frameworks. He emphasizes the importance of integrating security throughout the software development lifecycle and leveraging governance models such as OWASP and BSIMM. The conclusion stresses that while there is no absolute truth in application security, consensus exists on core practices necessary to manage risk and ensure a secure environment.
More Related Content
Similar to Application Security within Agile
Application Security within Agile
- 1.
- 2. Who am I? •Dimitrios Stergiou (@dstergiou) • Information Security Manager @ NetEnt • 7 years InfoSec experience in gaming companies • 15 years InfoSec experience (engineer, consultant, manager) • Mini bio: • Greek (and Swede) • Loves: InfoSec, Social Engineering, Economics, Video games • Hates: Vegetables, Rain, Pronouncing “j” as “y”
- 3. Disclaimer I don’t havethe ultimate truth But I am also NOT trying to sell you anything Listen, question and take everything with a grain of salt
- 4. Application security placement •Server •Custom-developedapplication •Server •Protocols like HTTP, SSH,SMTP •Router •TCP,UDP •Switch •IP, ARP, ICMP •Ethernet •Network cards, fibers, leased lines In-house code Application Transport Network Physical
- 5. What doesn’t work? Let’s talkabout 4 approaches to Application Security that don’t (generally) produce results
- 6. 4 FAIL approachesto AppSec Bolt on Security •Functional first, Security afterwards •Weakness: Design decisions, long cycle to fix Waterfall Security •Prepare every security solution in advance •Weakness: Not Agile friendly (who does waterfall these days?) “Random” Security •Implement every security countermeasure known to man •Weakness: Expensive, bloats the product / service, time-consuming All or Nothing Security •Reactively implement all proposed security controls (usually after an audit) •Weakness: Too big of a chunk to bite, maybe overdoing it
- 7.
- 8. Can you recommenda process? OpenSAMM Governance Strategy& Metrics Policy & Compliance Education& Guidance Construction Security Requirements Threat Assessment Secure Architecture Verification Design Review Security Testing CodeReview Deployment Environment Hardening Vulnerability Management Operational Enablement BSIMM Governance Strategy& Metrics Policy & Compliance Training Construction Standards & Requirements AttackModels Security Features& Design Verification Architecture Analysis Security Testing CodeReview Deployment Software Environment Configuration & Vulnerability Management Penetration testing
- 9. Conclusion • We stilldon’t have an “absolute truth” – there is no standard for AppSec • But these 2 modelslook EXTREMELYsimilar • So maybe we have some kind of consensus on what needs to be done
- 10. What are we tryingto achieve? • Cover the basis • Auditrequirements • Regulatoryrequirements • Manage risk • Mitigate,avoid
- 11. OWASP, They groupedeverything!
- 12. Some basics! Error handling •Genericerror messages • Handle all exceptions •Log, log, log •But don’t log everything •Safeguard logs Data protection •HTTP is dead, so isSSL • Use TLS everywhere •Manage your cryptokeys •Avoidstoring sensitivedata Authentication •No hardcoded credentials •Proper password reset system •Strong password policy •Accountlockout • Watch what you disclose in error messages Input &Output • Validate everything •Whitelists over blacklists • Use token for CSRF protection • User parameterized SQLqueries • Use Content- Securityheader Session management •Random session IDs •Force idle session timeouts • Invalidate sessionsafter logout • Use “secure” and “httpOnly” for Cookies Access control •Check every request •Least privilege • Avoid direct objectreferences • Validate forwardsand redirects
- 13. That is TOO much! •How are we going to do all these things? • “Do we need a security project?”
- 15. Agile & AppSec • BringAppSec activities into your Agile framework • Iteration and continuity is key • Breed new (improved) habits!
- 16. Exploration Backlog Architecture Spikes UserStories Iteration 0 Teamsetup Processsetup Infrastructure setup Iteration N Backlog Grooming Incremental Delivery UserStories Release Preparation AcceptanceTest Documentation Release Publish SecurityObjectives MinimSeucmuritVyiable RePqruoirdemucentts SecuritySpikes Vision/ Scope AbuseStories Threat Abuse Model Stories Design Code Inspect Inspect Security Security SRpiektersospecGtoivaels SecurityTesting Packaging / Release SecurityTesting Security Documentation Security Retrospective Typical Agile Organization
- 17. Latest nightmare • Not abad idea, but… • … there is a difference between DevOps and the “Wild, wild west”
- 18. Simplified DevOps • End-to-end productteam • Responsible for the full lifecycle of the product • BUT…
- 19. Etsy, the poster boy (orgirl) • “Invented DevOps” • Made it a trend • But… Fine print: Etsy built a new, segmented PCI-DSS compliant environment for their payment systems - "we built a whole separate Etsy, essentially"; In the payments environment they "still have to follow the rules: a developer still doesn't have access to a production database", but they'll have dbas working alongside them who they can ask for help, and graphs showing metrics from the database
- 20.
- 22. Should we DevOps? Benefits •Time to market • Ownership & Culture • Security actually improves • Knowledge spread • Improved product Caveats • Without discipline, chaos • Without automation, chaos • Jack of all trades, master of none • Segregation of duties out the door • Regulators not ready yet
- 23. What about security,SevDevOps?
- 24. SecOps Provide “secure” baselinesfor theDevOps teams Pass test results and risk assessments to DevOpsASAP Monitor all things – threat landscape changes by the minute Deliver security as code