Speaker: Timur Khrotko Language: English We have lost the war for secure software, hackers won, because codes contain vulnerabilities anyway -- as the current state of software production is such, the quality of developers is such. Let's face it: general devs will never care about security. QA methodologies and EH robots may change the landscape of AppSec someday. Until then let's focus on those few developer brigades who are disposed to improve. Secure coding trainings are essential and should be used in conjunction with vuln audits and coaching. Only findings in software made by such trained brigades are to cause satisfaction for a real EH professional. And please LOL at those clients who still believe they cannot afford preventive AppSec. CONFidence: http://confidence.org.pl/pl/

1. AppSec, the untrustable dev
timur @ owasp

2. ■ Timur ‘x’ Khrotko, PhD
■ x@azd.se
■ timur@owasp.org
■ linkedin.com/in/timurx
@timurxyz

3. ■ Open Web Application Security Project[s]
o owasp.org, open-source, non-profit
o AppSec evangelism
■ OWASP ≠ Top 10 (which is an educational project imo)
■ some projects
o ASVS (Application Security Verification Standard)
o (T10) Proactive Controls
o Testing Guide (TG)
o ZAP (Zed Attack Proxy)
o dependency-check …
O.W.A.S.P.

4. untrustable dev
image: deviantart.com, by sefesoft

5. ■ coders will never care about security
○ it can only be a by-product of their gut/tacit practice
■ don’t rely on appsec, detect and handle incidents
■ applications are vulnerable anyway - why?:
○ complexity, culture of devs, complicity (yours also,
see culture of audits), mismanagement,
immature methodologies and robots
■ for the dev teams who aren't lost:
○ secure coding course +dev coaching
+ review of audit findings
abstract / goo.gl/mbrPYO

6. ■ AppSec = QA (security QA, SeQA)
o product + production/dev + support + etc practices
■ don’t buy it w/o threat modeling (risk assessment)
■ AS policy, S-SDLC
o design, code, configuration, controls, testing
o patch management, support agreement, sec SLA
■ countermeasures: filter, isolate, monitor, respond
o waf, sandboxing, dmz, log audit, id(p)s
■ audit/test
o va, sast, dast, iast, code review, bl tests, pentest, ci …
appsec concepts

7. appsec, the short story
■ application security is created by the developers to meet
the set requirements

8. untrustable quality
image: deviantart.com, by sefesoft

9. The task of the software development team is
to engineer the illusion of simplicity.why #1: complexity
image: Bobbi J. Young et al. 2007. Software complexity: how do we bring order to chaos?

10. why #2: dev culture
image: en.wikipedia, by Klean Denmark

11. why #3: complicity
image: Thomas van de Weerd

12. CEO, business, legal
CIO, CISO, CRO, etc.
why #4: appsec mgmt
image: microsoft

13. why #5: methodologies
image: flickr.com/photos/bagogames/16153704398

14. trusted devs
image: en.wikipedia

15. trusted security
image: en.wikipedia, by AlephGamma

16. tno (trust no one)
image: wikimedia.org, cover art / trust no one / Dave Navarro (c) capitol/emi

17. threats
image: deviantart.com, by Christopher-Dombres

18. trust as soc construct
image: (c) playmobil

19. open sw production culture
■ HB -- a failure of the opensource QA myth
o “OpenSSL is written by monkeys”
/ Marco Peereboom, 2009
o “… is a patchwork nightmare”
/ Matthew Green, 2013
o “I told you so, la la la, I told you so!”
/ Marco Peereboom, 2014 image: XOX

20. enterprise sw culture
■ “Threats in custom app development: enterprises' lack of
security”
o Veracode Inc. blog, 2014 Sep

21. still untrustable devs
image: en.wikipedia, by Klean Denmark

22. OWASP Proactive Controls
C1: Parameterize Queries
C2: Encode Data
C3: Validate All Inputs
C4: Implement Appropriate Access Controls
C5: Establish Identity and Authentication Controls
C6: Protect Data and Privacy
C7: Implement Logging, Error Handling and Intrusion Detection
C8: Leverage Security Features of Frameworks and Security Libraries
C9: Include Security-Specific Requirements

23. OWASP ASVS
■ AppSec Verification Standard
o “security engineering checklist”
o levels (eg. L2): risk --> requirements --> verification

24. 40-20-40
+design
+testing

25. did you threat-model?!

26. secure coding course?!

27. + coaching + re:findings
dev
training
audit/va
dev
coaching

28. + do incident response!

29. resource: cut eh bdgt
■ eh (ethical hacking incl webapp assessments) is just
another expensive social construct you subscribed to
o eh culture is just as bad as that of the dev’s
■ relocate and spend more on:
o trainings
o S-SDLC, AppSec policy enforcement
o threat modeling and IR
■ use appsec specialists with whom your devs can work
constructively (eg. coaching)

30. resource for the smb-s
■ involve a visiting appsec specialist in critical moments
■ have a visiting ciso, at least rarely visiting
■ make one resident member of the dev team security
champion (see MS SDL)
■ secure coding courses

31. appsec synchronized
image: en.wikipedia, by Klean Denmark

32. next meetup: TBD
meetup.com/owasp-hu
twitter.com/owasp_hu
this prezo: goo.gl/mbrPYO