Sigma Open Tech Week: Bitter Truth About Software Security
•
1 like•146 views
This document discusses common problems with how application security is implemented. It argues that software developers often lack security knowledge and focus on functionality over security. Security teams also lack development experience and focus on compliance over practical security. As a result, security is treated as an afterthought through ineffective practices like sole reliance on penetration testing. The document recommends a proper Secure Development Lifecycle approach involving security training, secure coding practices, testing and ongoing improvements.
Report
Share
Sigma Open Tech Week: Bitter Truth About Software Security
- 1. bitter truth about software security Vlad Styran OSCP CISSP CISA Berezha Security
- 5. Disclaimers Crappy science: no supporting data or peer reviews Based on my own (mostly negative) experience If you have rotten potatoes, wait until the end
- 6. Agenda… sort of… Application Security is done wrong. Period. Questions are: 1. Who does it wrong? 2. What is done wrong? 3. How is it done wrong?
- 7. Who? Stake-holders: Software people • Have no idea about security • Driven by functionality and deadlines • Focused on visible features Security people • Have no idea about software development • Driven by budgets, "risk” and compliance • Focused on policy and best practice Business people (we won’t touch those)
- 8. What? is wrong with software people: Don’t care about security by default Start hiring appsec folks “into projects” once clients start to ask questions Rarely create “horizontal practices” for ad-hoc security assessments
- 9. What? is wrong with software people: Too much into their own stuff Usually very isolated cultures Don’t bother about appsec until they get hacked
- 10. What? is wrong with software people: Don’t care about security at all Have zero initial budget Are forced into appsec by market regulations or investors Are forced into appsec as a part of general corporate BS once they end being startups
- 11. What? is wrong with software people: Don’t see appsec as a feature (because it’s invisible) Think their code is secure by default and maybe has a few vulnerabilities to be “tested” or “scanned” before release Think their developers are well educated in appsec because they follow some weirdos on Twitter and Facebook
- 12. What? is wrong with security people: Have mainly network, infrastructure, intelligence/law enforcement background Are focused on setting the rules (“paper tigers”) and deploying controls (“blinking boxes”) As much as the software folks, believe in that ”pentest” or “code review” will solve all their problems The followers of the Best Practice Church
- 13. How? is the appsec done wrong: Pentest as a first step in a security program Pentest as the only appsec exercise before the product goes live No initial budget as a way to cut costs No developers awareness training before the project starts Treating appsec as a dull routine that has to be automated
- 14. How? Pentestas a firstortheonlypartof securityprogram Pentest is a measurement tool for the effectiveness of your security program If there is nothing yet to measure, it makes no sense • Some hackers will come • They will report a bunch of bugs • These won’t be all the bugs • These won’t be the worst bugs • These will be the easiest to find • This will affect your release date
- 15. How? No initial budget as a way to cut costs Built-in vs Bolt-on security Startups don’t care (Until it’s too late) Thinking of security as a project, process, business function etc. Not getting an intuition of risk (Not knowing how much it actually costs) The job market is hell (Or heaven, depends on your POV)
- 16. How? No developers training When Lemon Markets, Imposter Syndrome & Dunning–Kruger collide - Haroon Meer https://www.youtube.com/watch?v=YCijTioaCDw
- 17. How? Urge for automated security scanning
- 18. How? Urge for automated security scanning DAST (Security Scanner) Knows nothing about your code Gets mostly input/output flaws Covers about 15% of bugs Requires a consultant to get more Costs less than SAST SAST (Source Code Analyzer) Knows everything about your code (but gets nothing) Gets only semantic and implementation-level flaws: business logic is way out of scope Covers about 274% of bugs (out of 1078% possible) Costs 10x–100x more than DAST
- 19. Let’s summarize Developers and QAs who have no appsec background or training Are supposed to write secure code That contains only few security bugs All of which will be found by a security scanner or a code analyzer For free
- 20. Thank god, there are hackers! Expectations 1. Come to an ethical hacker 2 weeks before the release 2. Ask for a DAST for about $2-3k 3. Expect a clean & green report 4. Put it on the wall and go live 5. Live happy ever after Reality 1. Get shocked DAST takes at least 3 to 4 weeks 2. And costs much more 3. Get 10 critical bugs during first week and 50+ pages report 4. Fix the bugs for 2 months 5. Cry over the retest report and realize you still have bugs
- 21. Thank god, there are hackers! How hackers changed the security industry - Chris Wysopal https://www.youtube.com/watch?v=LSH3CyR35x4
- 23. What is SDL? A bunch of practices that improve “software assurance” level (a fancy name for appsec) Security architecture and design Formulating security requirements Secure coding and code review Security testing/pentesting Secure deployment and operation Incident response and security patches Automating all of the above And many many more
- 24. How to SDL? 1. Give the team an appsec awareness training 2. Consult an SDL framework and choose practices you can implement 3. Plan for adding practices that you should implement 4. Hire a security pro or consultant to help you with practices you cannot implement by yourself 5. Undergo an external appsec assessment after the first full SDL cycle and at least before every major release 6. Undergo an external SDL assessment/audit regularly and improve using the results
- 25. Who should SDL? Developers, Testers, DevOps – to relevant extent Security “Champions” or “Evangelists” – part time Project Managers – at higher level Architect and Leads – deep dive AppSec Analysts – full time
- 27. Notable OWASP projects OWASP Top Ten OWASP Testing OWASP SAMM OWASP ASVS OWASP ZAP OWASP Juice Shop
- 30. Cheat codes: roadmap templates
- 31. How to get in? OWASP Kyiv https://owasp.kyiv.ua AppSec Awareness Training notes https://github.com/sapran/appsec_a wareness_training Awesome AppSec curated list https://github.com/paragonie/aweso me-appsec AppSec Course on Coursera https://www.coursera.org/learn/soft ware-security WAHH book Ross Anderson’s Security Engineering book
- 32. How to find me sapran@pm.me https://fb.me/vstyran @arunninghacker