Taming Mr. Beeblebrox: Uniting the Two Heads of Agile and Security in Software Development (with Test Driven Development)

Using test driven development (TDD) to include security in the software development process.

Presented at Hacker Halted 2018 in Atlanta, Georgia.

Transcript

2. Taming Mr. Beeblebrox: Uniting the Two Heads of Agile and Security in Software Development (with Test Driven Development) Frank S. Rietta M.S. Information Security @frankrietta on Twitter https://rietta.com
3. Briefly About Me Building security in from the beginning! • Studied Computer Science and Information Security at Georgia Tech. • Dissatisfied with options in infosec industry in 2007, restarted web development work. • Now own a web application security firm with a growing team.
4. All security depends on software security.
5. All security depends on software security.
6. A Big Problem “Security is a non- functional requirement” Project Management Professor
7. “It is irresponsible for a developer to ship a line of code that [he or she] has not executed any unit test for, and one of the best ways to make sure you have not shipped a line of code without testing is to practice TDD” Robert Martin in his 2012 debate on TDD with Jim Coplien, video at https://www.youtube.com/watch?v=KtHQGs3zFAM&t=14%3A42
8. Agile Software Development Values We Value Over Individuals and interactions Processes and tools Working software Comprehensive documentation Customer collaboration Contract negotiation Responding to change Following a plan These have value! Software fails without these! Source: http://agilemanifesto.org
9. Invalid, Mythical Agile Claims • We don’t plan! We just execute. • We don’t design up front! • We don’t write documentation! • We don’t write tests!
10. Are firewalls destined for extinction?
11. Web Application Security • Firewalls have limited value in an environment where authorization decisions are made by the web app alone. • A significant number of data breaches (63%+ by DBIR data) are the result of poor password security, especially staff passwords with extraordinary access. • Most developers do not know the basics of the OWASP Top 10 or Advanced Security Verification Standard.
12. Have you heard of the OWASP Top 10 or the Application Security Verification Standard (ASVS) Source: Rietta's 2017 Survey of Atlanta area developers in a Slack chat community.
13. 2017 OWASP Top 10 • Injection • Broken Authentication • Sensitive Data Exposure • XML External Entities (XXE) • Broken Access Control • Security Misconfiguration • Cross-site Scripting (XSS) • Insecure Deserialization • Using Components with Known Vulnerabilities • Insufficient Logging & Monitoring
14. Changing Software to Fix Defects • When there is a security defect, how do the developers change the code without breaking the software? • Two industry approaches: – Edit and Pray – Cover and Modify
15. Legacy Code is Hard to Change “In the industry, legacy code is often used as a slang term for difficult-to-change code that we don’t understand. But over years of working with teams, helping them get past serious code problems, I’ve arrived at a different definition. To me, legacy code is simply code without tests." Feathers, Michael. Working Effectively with Legacy Code (Robert C. Martin Series) (Kindle Locations 226-229). Pearson Education. Kindle Edition.
16. Must change code to fix vulnerabilities!
17. Feather's Legacy Code Change Algorithm • When you have to make a change in a legacy code base, here is an algorithm you can use. 1.Identify change points. 2.Find test points. 3.Break dependencies. 4.Write tests. 5.Make changes and refactor. Feathers, Michael. Working Effectively with Legacy Code (Robert C. Martin Series) (Kindle Locations 624-628). Pearson Education. Kindle Edition.
18. Test Driven Development Strong Test Coverage Guaranteed! Catches Regressions. Catches Critical Security Mistakes
19. The Three Rules of TDD 1)Don’t write a line of production code without having a corresponding failing test 2)Don’t write too many failing tests without writing production code 3)Don’t write more production code than is sufficient to pass the currently failing test Robert Martin http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd (2005)
21. “The act of writing a unit test is more an act of design than verification. It is also more an act of documentation than verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function!” Robert C. Martin, Agile Software Development, Principles, Patterns, and Practices, p. 23
22. Test Driven Development Enables Continuous Deployment Update→ Tests Pass → Automatic Deploy!
23. Test Driven Development Cycle • Read the user (or abuser) story • Write a failing test • Implement the feature • See the tests pass • Deploy! Ship it to the cloud!
24. Components of a Good User (or Abuser) Story 1)a written description of the story used for planning and as a reminder 2)conversations about the story that serve to flesh out the details of the story 3)tests that convey and document details and that can be used to determine when a story is complete. Cohn, Mike (2004-03-01). User Stories Applied: For Agile Software Development (Kindle Locations 400-403). Pearson Education. Kindle Edition.
25. Three Example Abuser Stories • URL Tweaker: As an Authenticated Customer, I see what looks like my account number in the URL, so I change it to another number to see what will happen. • Curious Editor: As an Authenticated Customer, I paste HTML that includes JavaScript into every field possible to see what happens. • Infrastructure Takeover: As a Malicious Hacker, I want to gain access to this web application’s Cloud Hosting account so that I can lock out the legitimate owners and delete the servers and their backups, to destroy their entire business. Source: https://rietta.com/blog/2015/10/11/what-is-an-abuser-story-software
26. Example Abuser Story As a malicious user, I see that my account ID is 1337 and I change it to 1338 to see what will happen! Acceptance Criteria: When attempting to access another account, a user should receive an HTTP unauthorized status code (401).
29. It was vulnerable!
31. Red (Fail) Green (Pass) Refactor The TDD Cycle Read User Story
32. Who writes abuser stories and associated tests? • While user stories are expected to be written by customers only, abuser stories should be written by: – The Customer (Business) – The Developers (who have unique technical understanding of the system) – Security team (who have unique understanding of security threats) • Every story must have an accompany test as part of its definiton of done and to feed the TDD cycle • Developers write detailed tests as part of their implementation to fill in more technical details and to show that no code was shipped without tests and that the particular issue cannot reappear without the tests failing
33. What abuser stories to create? • Start with the OWASP Top 10, and craft abuser stories appropriate for the application. • Every time a security vulnerability is identified, enter a story that includes a definition of done
34. Questions?
35. Thanks!