O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

0

Compartilhar

Baixar para ler offline

Application Security Webcast

Baixar para ler offline

Berezha Security webcast Application Security.

  • Seja a primeira pessoa a gostar disto

Application Security Webcast

  1. 1. bitter truth about software security Andriy Varusha Vitaly Balashov Vlad Styran
  2. 2. Who? Stake-holders: Software people Security people Business people
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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 Think their developers are well educated in appsec DevOps of the frontal cortex
  7. 7. What? is wrong with security people: Have mainly network, infrastructure, intelligence/law enforcement background Are focused on “paper tigers” and “blinking boxes” Believe that ”pentest” or “code review” will solve all their problems The followers of the Best Practice Church
  8. 8. How? is the appsec done wrong: ”Penetration Test” attitude No developers awareness training before the project starts Treating appsec as a dull routine that has to be automated
  9. 9. How? Pentestasafirstortheonlypartof 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
  10. 10. How? No developers training When Lemon Markets, Imposter Syndrome & Dunning–Kruger collide - Haroon Meer https://www.youtube.com/watch?v=YCijTioaCDw
  11. 11. How? Urge for automated security scanning
  12. 12. 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
  13. 13. 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
  14. 14. Thank god, there are hackers! How hackers changed the security industry - Chris Wysopal https://www.youtube.com/watch?v=LSH3CyR35x4
  15. 15. https://www.microsoft.com/en-us/sdl/default.aspx
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. Good practice https://www.owasp.org/
  20. 20. Notable OWASP projects OWASP Top Ten OWASP Testing OWASP SAMM OWASP ASVS OWASP ZAP OWASP Juice Shop
  21. 21. SAMM practices example
  22. 22. Cheat codes: roadmap templates
  23. 23. 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
  24. 24. How to find us Andriy Varusha https://fb.me/avarusha Vitaly Balashov https://fb.me/vitaly.balashov Vlad Styran https://fb.me/vstyran Berezha Security https://berezhasecurity.com sales@berezhasecurity.com

Berezha Security webcast Application Security.

Vistos

Vistos totais

116

No Slideshare

0

De incorporações

0

Número de incorporações

0

Ações

Baixados

1

Compartilhados

0

Comentários

0

Curtir

0

×