Agile security - Getting it right from the start
•Descargar como PPTX, PDF•
4 recomendaciones•1,810 vistas
When implementing security into the various phases of the SDLC, it’s important to implement these activities with purpose. This presentation explains why and how to get security correct from the start.
Recomendados
Más contenido relacionado
Destacado
Destacado (12)
Más de Cigital
Más de Cigital (18)
Último
Último (20)
Agile security - Getting it right from the start
- 1. Agile Security Getting It Right From the Start Nick Murison Managing Consultant nmurison@cigital.com Twitter: @nickmurison
- 2. The Challenge • Idea Prototype Reality When do we put security into the design?
- 3. In the old days… waterfall Requirements Gathering Architecture and Design Code and Development Testing Deployment Security Gate Security Gate Security Gate Security Gate
- 4. Modern Software Development The Agile Manifesto is a set of principles, not a rigid methodology. There are many Agile method- ologies, including Scrum and Kanban.
- 6. Common Security Design Flaws • Baby Duck Authentication • First thing I “see” must be my mother • Download instructions, firmware update, admin mode, whatever • Kung-Fu Grip • Press a magic key physical sequence to get factory reset • Perfect for resetting/bypassing security • Secret Handshake • Exchange special message, username, password, etc. • Often used for maintenance, admin, debugging • Usually abused
- 7. 7 • No little numbers (e.g., Acct=482, Device=1). • Just use GUIDs all the time. • If it’s human-readable, it’s probably easy to attack. • You MUST rate-limit everything • How many Xs per Y? Request/hour, signups/day, emails/human, etc. • Plan for regular upgrades • Your platforms, your hardware, your dev tools, your libraries • Expect software to be abandoned, too (open source, etc.) • The backwards compatibility problem is real • If you didn’t secure version 1, will you abandon those users in version 2? Seriously Important Security for Start- ups
- 8. Cigital’s “Agile Security Manifesto” • Rely on good developers and testers over security specialists • Implement secure features over adding security features afterwards • Continuously improve security over completely changing processes • Focus on fixing software over finding bugs • www.cigital.com -> Resources -> eBooks
- 10. Security User Stories Secure Code Review Security Testing Penetratio n TestingSecure Design Review Modern Software Development with Security
- 12. 12 Adding Security User Stories As a fraudster, I want to see the details of an order that is not my own so that I can learn another person’s private information. As a customer, I want to track the shipment of my order so that I know when it will arrive. User Story Security Story 12
- 13. 13 “Bad Guys” in Security User Stories • Competitor • Misbehaving customer • Hacker • Journalist • Vandal • Disgruntled employee • Learn private information • Commit a fraudulent transaction • Damage the company’s brand • Prevent people from doing their job • Sell valuable information “Users” Goals 13
- 14. 14 “Good Guys” in Security User Stories • Auditor • Customer Service Rep • System Operator • Well-behaved user • Manager • Verify a transaction • Determine some important information • Report on error conditions • Display the status of something “Users” Goals 14
- 15. 15 Acceptance Criterion 1 • Given that the user is logged in • And the session is valid • And the request is for an order that does not belong to the logged-in user, • When the user requests the details • Then display an error message • And ensure the user is no longer logged in • And log an error to the application log. Acceptance Criterion 2 • Given that the user is not logged in • And the request is for an order • When the user requests the details • Then display an error message • And ensure the user is not logged in • And log an error to the application log. 15 Security User Stories As a misbehaving customer, I want to see the details of an order that is not mine So that I can learn private information of another person
- 17. Bugs and Flaws Architectural flawsImplementation bugs misuse of cryptography duplicated code missing authorization checks SQL injection cross-site scripting buffer overflow 50%50%
- 18. 18 Bugs versus Flaws • Localised • Found in the code • Fixed in the code • Design remains the same • General • Design needs adjustment • Code could be right, but problem would still occur Bugs Flaws
- 19. We Care About Bugs Versus Flaws Bugs Flaws Find • IDE Tools • Code scanning • Peer review • Compiler tools • Architecture review • Design review Fix • Change the code • Use a 3rd party library • Change the design • Re-implement new code
- 20. Key Components of a Threat Model • Threat Modeling outlines a systematic way to enumerate and visualize the potential threats to a system. • Key components are: • Model of the system (or protocol, etc.) • Traceability Matrix • Optionally: • Misuse/Abuse cases • Security test strategy • Security requirements 20
- 22. Traceability Matrix “A threat agent, trying to compromise some asset, using an attack, interacting via attack surface, in order to achieve attack goal, having impact, mitigated to an acceptable risk level by control.” 22 Threat Agent Asset Attack Attack Surface Attack Goal Impact Controls
- 23. Threat Modeling Improves Security • Targeted pen tests • Targeted code reviews • Discover new things • Design flaws • Connections that were not considered part of the normal test strategy 23
- 24. Code Review “The other 50%”
- 25. Types of Code Review • Tools that scan like compilers • Tools that search for key words • Tools that check platform configuration • People reviewing code • People reviewing tool output 25
- 27. Choices for Code Review Your Developers Partners / Vendors Peer Review Train them Make it verifiable part of the SDLC IDE Plugin Buy it, use it Require it, perhaps buy it Repository Periodically Keep copy or master repository, scan it Nightly Builds Do it Require the unfiltered output 27 Whatever You Do: Track the issues yourself. Get exposure to the raw issues and follow them.
- 28. Code Review is Hard • Code review is hard when: • Teams first start • Tools are not configured well • Determining validity is hard • False positive • False negative • Root cause analysis of true positive • Determining priority is hard • Impact • Likelihood 28
- 29. Security Testing
- 30. 30 Testing • Your advocate • Full, systematic coverage of all user journeys • Relatively complete test data • Reasonable domain knowledge • Lots of time • Independent • Risk-based coverage of a fraction of possible journeys • Typically incomplete test data • Minimal domain knowledge • Time budgeted Functional Testers Penetration Testers 30
- 31. 31 1. Capture test data from penetration tests • Give to regression testers • Duplicate their results • Test every subsequent release 2. Track Defects • Use the same defect tracker the devs use 3. Pinpoint training needs based on security results • Advanced framework features • Cryptography • Defensive Programming 31 Making the Most of Security Testing
- 32. So where to start?
- 33. BSIMM
- 34. Building BSIMM (2008) • BIG idea: Build a maturity model from actual data gathered from 9 well-known large-scale software security initiatives. • Create a software security framework. • Interview 9 firms in-person. • Discover 110 activities through observation (1 removed, 3 added later). • Organize the activities in 3 levels. • Build a scorecard. • The model has been validated with data from 129 firms (95 in BSIMM7). • There is no special snowflake.
- 35. BSIMM: Software Security Measurement • 129 firms measured (data freshness) • BSIMM7 = data from 95 real initiatives • 290 distinct measurements over time • 30 over time (one firm 5 times) • McGraw, Migues, and West
- 36. 95 Firms in BSIMM7 Community
- 37. Monkeys Eat Bananas • BSIMM is not about good or bad ways to eat bananas or banana best practices. • BSIMM is about observations. • BSIMM is descriptive, not prescriptive. • BSIMM describes and measures multiple prescriptive approaches.
- 38. A Software Security Framework See informIT article on BSIMM website http://bsimm.com 4 Domains 12 Practices
- 40. Earth (95)
- 41. BSIMM7 as a Measuring Stick
- 42. BSIMM7 Results • Top 12 activities • purple = good? • red = bad? • “Blue shift” = practices to emphasize
- 43. Improvement Over Time • 30 firms measured twice (an average of 25 months apart) • We know how firms improve • An average of 34.6% activity increase
- 44. Using the BSIMM • BSIMM7 released October 2016 under Creative Commons. • http://bsimm.com • Download the document • Look at the most common activities • Get ideas about what activities make the most sense for your organisation to implement • BSIMM is a yardstick. • Use it to see where you stand. • Use it to figure out what your peers do. • Use it to figure out what to do next!
- 45. The best time to plant an oak tree was twenty years ago. The next best time is now. —Ancient Proverb Nick Murison nmurison@cigital.com Twitter: @nickmurison
Notas del editor
- Agile Security: Getting it right from the start
- The Challenge: Idea – Prototype – Reality When do we put security into the design? Sketch: https://www.flickr.com/photos/karmadude/132682739/ – commercial reuse allowed Robot: https://www.flickr.com/photos/firepile/438125743/ - commercial reuse allowed Big robot: https://www.flickr.com/photos/127771812@N05/15089377110/ - commercial reuse allowed
- In the old days: waterfall. Requirements gathering. Architecture and design. Code and development. Testing. Deployment. https://openclipart.org/detail/11463/rpg-map-symbols-gate-2 - Creative commons licensed.
- Modern Software Development: The Agile Manifesto is a set of principles, not a rigid methodology. There are many Agile methodologies, including Scrum and Kanban. Manifesto picture: https://www.flickr.com/photos/visualpunch/8745184787/
- Problems Start-ups Face Security is hard. It’s not easy, but it’s easier than ever. Use secure frameworks. Don’t disable their sensible defaults. We’ll secure that later, just get it working. Later never comes. Software isn’t released; it escapes. What could possibly go wrong? Lots. You’re creating something that has never existed before. Attackers have way more resources than you do. Image: https://www.flickr.com/photos/toffehoff/244870160/
- Common Security Design Flaws Baby Duck Authentication First thing I see must be my mother. Download instructions, firmware update, admin mode, whatever. Kung-fu Grip Press a magic key physical sequence to get factory reset. Perfect for resetting/bypassing security. Secret Handshake Exchange special message, username, password, etc. Often used for maintenance, admin, debugging. Usually abused.
- Seriously Important security for start-ups. No little numbers (e.g., Acct=482, Device=1). Just use GUIDs all the time. If it’s human-readable, it’s probably easy to attack. You MUST rate-limit everything How many Xs per Y? Request/hour, signups/day, emails/human, etc. Plan for regular upgrades Your platforms, your hardware, your dev tools, your libraries Expect software to be abandoned, too (open source, etc.) The backwards compatibility problem is real If you didn’t secure version 1, will you abandon those users in version 2?
- Cigital’s “Agile Security Manifesto” Rely on good developers and testers over security specialists. Implement secure features over adding security features afterwards. Continuously improve security over completely changing processes. Focus on fixing software over finding bugs. www.cigital.com -> Resources -> eBooks
- Modern Software Development.
- Modern Software Development with Security. Don’t change your process, augment it, iteratively.
- Security User Stories.
- Adding Security User Stories. 1. User Story: As a customer, I want to track the shipment of my order so that I know when it will arrive. 2. Security Story: As a fraudster, I want to see the details of an order that is not my own so that I can learn another person’s private information.
- “Bad Guys” in Security User Stories Users: Competitor Misbehaving customer Hacker Journalist Vandal Disgruntled employee Goals: Learn private information Commit a fraudulent transaction Damage the company’s brand Prevent people from doing their job Sell valuable information
- “Good Guys” in Security User Stories Users: Auditor Customer Service Rep System Operator Well-behaved user Manager Goals: Verify a transaction Determine some important information Report on error conditions Display the status of something
- Security User Stories As a misbehaving customer, I want to see the details of an order that is not mine So that I can learn private information of another person Acceptance Criterion 1 Given that the user is logged in And the session is valid And the request is for an order that does not belong to the logged-in user, When the user requests the details Then display an error message And ensure the user is no longer logged in And log an error to the application log. Acceptance Criterion 2 Given that the user is not logged in And the request is for an order When the user requests the details Then display an error message And ensure the user is not logged in And log an error to the application log.
- Software Architecture.
- Bugs and Flaws Implementation bugs: 50% SQL injection cross-site scripting buffer overflow Architectural flaws: 50% misuse of cryptography duplicated code missing authorization checks
- Bugs vs. Flaws: Hackers don’t care.
- We care about bugs vs. flaws.
- Key Components of a Threat Model: Threat Modeling outlines a systematic way to enumerate and visualize the potential threats to a system. Key components are: Model of the system (or protocol, etc.) Traceability Matrix Optionally: Misuse/Abuse cases Security test strategy Security requirements
- Example Threat Model.
- Traceability Matrix “A threat agent, trying to compromise some asset, using an attack, interacting via attack surface, in order to achieve attack goal, having impact, mitigated to an acceptable risk level by control.”
- Threat Modeling Improves Security Targeted pen tests Targeted code reviews Discover new things Design flaws Connections that were not considered part of the normal test strategy
- Code Review: The other 50%
- Types of Code Review Tools that scan like compilers Tools that search for key words Tools that check platform configuration People reviewing code People reviewing tool output
- Code Review.
- Choices for Code Review.
- Code Review is Hard Code review is hard when: Teams first start Tools are not configured well Determining validity is hard False positive False negative Root cause analysis of true positive Determining priority is hard Impact Likelihood
- Security Testing.
- Testing Functional Testers Your advocate Full, systematic coverage of all user journeys Relatively complete test data Reasonable domain knowledge Lots of time Penetration Testers Independent Risk-based coverage of a fraction of possible journeys Typically incomplete test data Minimal domain knowledge Time budgeted
- Making the Most of Security Testing Capture test data from penetration tests Give to regression testers Duplicate their results Test every subsequent release Track Defects Use the same defect tracker the devs use Pinpoint training needs based on security results Advanced framework features Cryptography Defensive Programming
- So where to start?
- BSIMM
- Building BSIMM (2008) BIG idea: Build a maturity model from actual data gathered from 9 well-known large-scale software security initiatives. Create a software security framework. Interview 9 firms in-person. Discover 110 activities through observation (1 removed, 3 added later). Organize the activities in 3 levels. Build a scorecard. The model has been validated with data from 129 firms (95 in BSIMM7). There is no special snowflake.
- BSIMM: Software Security Measurement 129 firms measured (data freshness) BSIMM7 = data from 95 real initiatives 290 distinct measurements over time 30 over time (one firm 5 times) McGraw, Migues, and West
- 52 of 78 firms. Some firms choose to remain anonymous.
- Monkeys Eat Bananas BSIMM is not about good or bad ways to eat bananas or banana best practices. BSIMM is about observations. BSIMM is descriptive, not prescriptive. BSIMM describes and measures multiple prescriptive approaches.
- Software Security Framework
- This is the 95 firm raw data about activities. Each highlighted activity is the most common one in its practice, one for each practice.
- Spider graphs have been created with the 95 firm data. This is the curve for all 95 firms in the study.
- BSIMM7 as a Measuring Stick
- BSIMM 7 Results.
- Improvement Over Time 30 firms measured twice (an average of 25 months apart) We know how firms improve An average of 34.6% activity increase
- Using the BSIMM BSIMM7 released October 2016 under Creative Commons. http://bsimm.com Download the document Look at the most common activities Get ideas about what activities make the most sense for your organisation to implement BSIMM is a yardstick. Use it to see where you stand. Use it to figure out what your peers do. Use it to figure out what to do next!
- The best time to plant an oak tree was twenty years ago. The next best time is now. —Ancient Proverb http://commons.wikimedia.org/wiki/File:Napa_Valley_oak_tree.jpg