1. 1. Security Toolbox: Managing Security Risk for Agile Practitioners Matthew Coles & Izar Tarandach RSA, the Security Division of EMC
2. 2. Challenges in Agile
   • Agile Development simulated by a classic arcade game
   • 3. Defects (holes) occur for many reasons
     • Flood of requirements
     • 4. No visibility
     • 5. No resources
3. 6. Challenges in Agile
   • Goal to successfully implement slices of requirements, adapting to changes as they come from the customer
     • Function over Form
     • 7. Success criteria defined by Product Owner (channelling the customer)
     • 8. Acceptance tests and design requirements only as good as team
   • Reliance on subject matter expertise; not always dedicated to the effort
4. 9. Traditional Techniques
   • Security for Software Development Lifecycle
     • Risk Analysis
     • 10. Code Analysis
     • 11. Security Testing
     • 12. Security Documentation
   • Only Risk Analysis can help avoid security risk
     • Before security debt exists
     • 13. But can still be too late to avoid costly rework
5. 14. Security Debt
   • Technical Debt
     • Measure of rework that will be required to address built-in flaws
   • Security Debt
     • Technical Debt which leads to security vulnerabilities
6. 15. Our Vision
   • Give Product Owners and Agile teams a method to prevent injecting security defects
     • Predict backlog items, acceptance tests, and documentation as architecture is defined
     • 16. Enable better work estimation
     • 17. Identify and manage technical debt
   • Give security SMEs a helping hand
     • or give small organizations the benefit of an SME if they don't have one
   • Minimize Security Debt
7. 18. Security Toolbox
   • Playbook for security
     • Collection of security knowledge
     • 19. Each item associated to architectural feature
   • Built-in Security
     • Functional elements for security improvement
     • 20. Acceptance tests to implement
     • 21. Policy compliance updates
     • 22. Resource cost estimates
     • 23. Priority Hints to Product Owners and Scrum Masters
8. 24. Constructing the Toolbox
   • Requires security knowledge (of course)
   • 25. Where can we find good security knowledge?
     • Microsoft (de facto reference)
       • Also discusses applying this knowledge in Agile
     • OWASP
     • 26. Security Innovations (vendor)
     • 27. Policies
     • 28. Corporate resources
9. 29. Constructing the Toolbox
   • MITRE has a great source for security knowledge
     • Common Weakness Enumeration (CWE)
     • 30. Common Attack Pattern Enumeration and Classification (CAPEC)
     • 31. Common Vulnerability Enumeration (CVE)
   • Toolbox Items = Community-driven security knowledge + solid software engineering
10. 32. Toolbox Schema (CWE) (CWE) (CAPEC) (Policy) Architectural Elements Toolbox Item Lens or Filter Web Server (generic) Apache (specific) Apache 2.0.29 (instance) IIS (specific) CVE Policy CWE Internal Document CWE Mitigation (Backlog) Mitigation (Task) Acceptance Criteria (Test) Component Whitelist*
11. 33. Exercise
    • The Team
      • Three dev teams, each with a ScrumMaster
      • 34. One Product Owner
      • 35. Shared security consultant
    • Each dev team has
      • 2-3 domain-knowledgable programmers
      • 36. One QA engineer
      • 37. One doc writer
      • 38. One business analyst
12. 39. Exercise
    • Customer Requirements for Online Comment System
      • Flexible, easy to use, nice looking
      • 40. User at home or mobile with web browser
      • 41. Storage in backend processing system
      • 42. User name and email address stored for later follow-up
    Acceptance Criteria Interface works on Windows and Mac Acceptance Criteria User data goes from Interfaceto backend User Story User with web browser enters data into interface and data is stored in backend system. Acceptance Criteria User interface is visually appealing (focus group).
13. 43. Epic User with web browser enters data into interface and data is stored in backend system. Story B UI process sends data to backend store Points: 200 Story A User enters data into interface Points: 500 Story C User gets response of successful upload Points: 100
14. 44. WebBrowser HTTP Server Database Constraint - UI Technology Choices HTML, Flash Constraint - Server Technology Choices LAMP (Linux, Apache, MySQL, PHP) Constraint - DB Technology Choices MySQL
15. 45. Backlogs w/o Toolbox Product Sprint Task 1 (80 pts) Construct Flash UI for user input Task 3 (30 pts) Validate UI input Task 2 (40 pts) Enable connection to server via HTTP Task 4 (30 pts) Write user input to database Task S1 (25 pts) Create form with user input fields in Flash/ActionScript Task S2 (25 pts) Check input meets type/range criteria Task S3 (25 pts) Create submit() function to send user data to server Task S4 (25 pts) Accept data from web client and write to database Acceptance Test Validate test data is stored in database after user hits submit button Acceptance Test Validate user input field accepts only plain text input.
16. 46. WebBrowser HTTP Server Database User Interface Flash Web Server Apache Apache 2.0.29 Database MySQL HTML Server HTTP/1.1
17. 47. Web Server Apache Apache 2.0.29 Security Test: Sniffing data communications (CAPEC-157) Task: Enable port 443 in firewall Policy: Secure user communications Component Check: Apache 2.0.29 Backlog: SSLv3/TLSv1 Risk: High Cost: 10 Acceptance Test: Network vulnerability scan reports 0 critical defects
18. 48. HTTP/1.1 HTTP/1.1SSLv3 tcp/443 SPRINT 1 Without Toolbox With Toolbox Flash UI Apache MySQL Flash UI Apache 2.0.29 MySQL
19. 49. Now when you play that game...
    • Give teams hints to predict how the pieces come together
      • Avoid blank spaces
      • 50. Avoid technical debt
      • 51. Don't defer security
20. 52. References
    • Keramati, H; Mirian-Hosseinabadi, S.H., Integrating Software Development Security Activities with Agile Methodologies, IEEE, 2008
    • 53. Siponen, M.; Baskerville, R.; Kuivalainen, T., Integrating Security into Agile Development Methods, IEEE, 2005
    • 54. Common Weakness Enumeration (CWE): http://cwe.mitre.org/
    • 55. Common Attack Pattern Enumeration and Classification (CAPEC): http://capec.mitre.org/
    • 56. Common Vulnerability Enumeration (CVE): http://cve.mitre.org/
    • 57. Microsoft Security Development Lifecycle (SDL): http://go.microsoft.com/?linkid=9769715
21. 58. Security Toolbox Discussion Q & A
22. 59. Future Topics Areas for additional work
23. 60. Adding and removing knowledge
    • Security knowledge as 'facts'
      • Apache X.Y.Z is vulnerable to a buffer overflow via the HTTP version field (CVE-AAAA-BBBB):
        • (Apache,X.Y.Z,CVE-AAAA-BBBB) -> CWE-121: Stack-based Buffer Overflow
        • 61. (Apache,X.Y.Z,CVE-AAAA-BBBB) -> CWE-120: Buffer Copy without Checking Size of Input
    • Periodic purges of out-of-date facts
      • Set all versions of SSL lower than 0.9.7a to UNACCEPTABLE
24. 62. Giving the Sec SME a break Facts and derivations are ideal for expert systems.
    • target(WWW Server)
    • 63. instance(WWW Server,Apache,OS=Any)
    • 64. instance(WWW Server,FooServer,OS=Linux)
    • 65. constraint(OS = Microsoft Windows)
    • 66. constraint(instance = Apache:9.2.3, OS = not Microsoft Windows)
    • 67. vuln(WWW Server,Privileged network port open)
    • 68. vuln(WWW Server,Tainted data over network)
    • 69. vuln(Apache:7.0.12:-,CVE-2011-1475)
    • 70. mitigation(Tainted data over network,SSL,cost=5)
    • 71. mitigation(Privileged network port open,drop privileges after opening port,cost=1)
    • 72. (.)
    Example Goal: secure implementation of target X == list of all needed mitigations per instance of targets, observing constraints, ranked by cost.