Security Toolbox: Managing Security Risk for Agile Practitioners Matthew Coles & Izar Tarandach RSA, the Security Division...
Challenges in Agile <ul><li>Agile Development simulated by a classic arcade game
Defects (”holes”) occur for many reasons </li><ul><li>Flood of requirements
No visibility
No resources </li></ul></ul>
Challenges in Agile <ul><li>Goal to successfully implement slices of requirements, adapting to changes as they come from t...
Success criteria defined by Product Owner (channelling the customer)
Acceptance tests and design requirements only as good as team </li></ul><li>Reliance on subject matter expertise; not alwa...
Traditional Techniques <ul><li>Security for Software Development Lifecycle </li><ul><li>Risk Analysis
Code Analysis
Security Testing
Security Documentation </li></ul><li>Only Risk Analysis can help avoid security risk </li><ul><li>Before ”security debt” e...
But can still be too late to avoid costly rework </li></ul></ul>
Security Debt <ul><li>Technical Debt </li><ul><li>Measure of rework that will be required to address built-in flaws </li><...
Our Vision <ul><li>Give Product Owners and Agile teams a method to prevent injecting security defects </li><ul><li>Predict...
Enable better work estimation
Identify and manage technical debt </li></ul><li>Give security SMEs a helping hand </li><ul><li>or give small organization...
Security Toolbox <ul><li>”Playbook” for security </li><ul><li>Collection of security knowledge
Each item associated to architectural feature </li></ul><li>Built-in Security </li><ul><li>Functional elements for securit...
Acceptance tests to implement
Policy compliance updates
Resource cost estimates
Priority Hints to Product Owners and Scrum Masters </li></ul></ul>
Constructing the Toolbox <ul><li>Requires security knowledge (of course)
Upcoming SlideShare
Loading in …5
×

Matthew Coles - Izar Tarandach - Security Toolbox

2,208
-1

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,208
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Welcome This presentation is presented by Matthew Coles and Izar Tarandach with the EMC Product Security Office. We are presenting a method for identifying and managing security in product development. While our focus today is a result of issues we have observed from teams performing software development in an Agile or iterative lifecycle, this approach may be feasible for more traditional development methods. Ask people why they are at the presentation. Have they done agile before? Are they planning to? Software development team. Scope of work we do at EMC.
  • Security engineering is a puzzle game. We thought Tetris actually provided an excellent way to represent Agile development. Tetris presents a number of matching qualities: * The game starts cleanly, and builds upon previous layers, ad nauseum * Components are added according to some pattern, but that pattern is not known to the player * The player must somehow make all the pieces fit together, and must do this more quickly as time progresses * When (not if) mistakes are made, holes are present in the structure being built. These holes represent security defects. The caveat: in the real world, those holes are not visible, unless certain activities are performed.
  • In an Agile development model, requirements are collected and components fit together, but unlike in standard development lifecycles (i.e waterfall) the order and priority is vaguely random. This is similar to the selection pattern of components in the game from the previous slide. Success criteria is also a moving target, and requires the Product Owner to successfully interpret customer and stakeholder requirements. Finally, acceptance tests, functional design, and other metrics are only as good as the subject matter experts knowledge. Given the often shortened timeframe between requirement generation and functional product, there is limited time to review possible options to select the most secure option.
  • There are of course ways to detect security defects. Risk Analysis – EMC uses a variant of Threat Modeling based on a ”library” tying architecture to threats.
  • As more features are added, security debt (and therefore risk) increases, without mitigations. When mitigations happen (fixing threats and bugs, not testing or threat modeling), there is a momentary drop in debt/risk. Until security detection activities like Threat Modeling or Code Analysis is performed, debt/risk is ”potential” rather than ”kinetic”.
  • Caveat: Toolbox cannot alone fix security defects, only help you avoid them. Just-in-time guidance, without the promise of 100% completeness.
  • .
  • Describe how to select based on architecture, and how to choose between generic or specific.
  • The architecture of the knowledge base upon which the toolbox is created is a great example of the use of the famed expert systems of years gone by. A team looking for help can perform many different queries upon the same fact database: Given a need for a web server, which instance would give me less work to make secure? Given a vulnerability (at any granularity) what instances are NOT vulnerable? Given a set of constraints, what kind of mitigations will I be considering?
  • Matthew Coles - Izar Tarandach - Security Toolbox

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

    ×