This document discusses how to scale web security programs to enable security at large organizations. It argues that relying solely on security professionals is not scalable, and that security must be embedded throughout the entire software development lifecycle (SDLC). It recommends automating as many security tasks as possible, such training developers, conducting static/dynamic analysis, and defending applications post-release. Security experts should focus on strategic tasks like risk management, architecture design, and tackling new problems. The key is gaining incremental security wins at each stage and building everything with scaling in mind.

1. Scaling Web Security - Tools,
Processes and Techniques to Enable
Security At Scale

2. About Me
michael.coates@owasp.org

3. “The global cost of cybercrime is greater than
the combined effect on the global economy of
trafficking in marijuana, heroin and cocaine”
theregister.co.uk
Sept 7, 2011

4. Reality

5. Data Loss & Breaches
Verizon Data Breach Report 2013datalossdb.org/statistics

6. Data Loss & Breaches
Verizon Data Breach Report 2013datalossdb.org/statistics

7. The Supposed Security Program
• “Security is everyone’s job…”
• “Security training is the answer…”
• “It’s easy, just use encoding…”
• “Companies that care about security wouldn’t
have those vulnerabilities…”

8. Two Facts about Security Programs

9. 1) Fixing a single security bug:

10. 1) Fixing a single security bug:
Easy

11. 1) Fixing a single security bug:
Easy (generally)

12. 2) Ensuring no critical bugs are introduced to
software

13. 2) Ensuring no critical bugs are introduced to
software
• While moving fast

14. 2) Ensuring no critical bugs are introduced to
software
• While moving fast
• With minimal impact to developers

15. 2) Ensuring no critical bugs are introduced to
software
• While moving fast
• With minimal impact to developers
• Within an agile or constant deployment model

16. 2) Ensuring no critical bugs are introduced to
software
• While moving fast
• With minimal impact to developers
• Within an agile or constant deployment model
• Across thousands of developers, multiple sites
and services, and numerous new lines of code

17. 2) Ensuring no critical bugs are introduced to
software
• While moving fast
• With minimal impact to developers
• Within an agile or constant deployment model
• Across thousands of developers, multiple sites
and services, and numerous new lines of code

18. The Goal
• Eliminate all possible security bugs?
• Keep company out of the headlines?
• Protect data?
• Ensure uptime?
• The real goal – manage risk

19. RETHINKING SECURITY PROGRAMS
Eliminate the Security Professional

20. You can’t solve security by throwing
bodies at the problem
Security Professionals
– Expensive
– Hard to find
– Competition for employment

21. Humans Don’t Scale Well

22. Security Throughout SDLC

23. Development
• Developer Training
• Coding Guidelines
– Cheat Sheets
– Concise, Usable
owasp.org/index.php/Cheat_Sheets

24. Development
• Security Libraries & Services
– Abstract away internals of security code
– Standardized security libraries
• OWASP ESAPI – an example of what you should build
within your organization
– Web services for security

25. Automation
• Dynamic security
analysis built for
developers
– Report what can be
found >95% accuracy
– Skip issues where
accuracy is low
– Accurate Tool > Tool
which requires security
team
wiki.mozilla.org/Security/Projects/Minion

26. Automation
• Static / Dynamic Analysis
– Careful – security resource may be required
– Can scale if homogenous environment
• Security X as a Service
– Yes! The Future!

27. QA
• Security validation within QA
• Functional testing of forms + basic sec tests
• Follow patterns of current QA
– Pass / Fail
– Self contained testing – no need for security evaluation
“><script>alert(‘problem’)</script>

28. Organizational Strategy
• Embedding security
inside dev team
– team effort to ship
– real time collaboration
– eliminates “us” vs
“them”
– build alliance
Dev
Team
Dev
Team
Dev
Team

29. Organizational Strategy
• Scaling via Security Champions
• Primary Role: Developer
Secondary: Security
• Scales Effectively
• Liaison to security team
Dev Team
Dev Team

30. Post Release - Bounty Programs!
• Engage Security Community
https://bugcrowd.com/list-of-bug-bounty-programs/

31. Post Release – Defend That App
• Detect and repel common
attacks
– Web Application Firewall
• Detect and repel custom
attacks at business layer
– Integrated application defense
– OWASP AppSensor
owasp.org/index.php/OWASP_AppSensor_Project
crosstalkonline.org/storage/issue-archives/2011/201109/201109-Watson.pdf

32. Post Release – Defend That App
• Scale!
– Attack blocking?
Automated only
– No human analysis in
critical path.

33. How to Use Security Expertise
• Security strategy, risk programs, architecture &
design
• Tackle new problems, determine how to
automate them
• Build scalable security resources & services

34. Key Points
• Security is not just an activity conducted by a
single team
• A strategic security program gains incremental
wins at every step
• Build everything for scaling
• Automate first, human SMEs only when required

35. Thanks
@_mwc
michael.coates@owasp.org
security101@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/security101