1 / 66

Agile Appsec

Learn how Agile Development impacts software security, the prevalent vulnerabilities, and steps to enhance secure development practices. Stay informed to safeguard against breaches and secure your applications.

mook
Download Presentation

Agile Appsec

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agile Appsec CAMUG 2013 Agile Appsec 2013 Building Real Software

  2. Why we Suck at Building Secure Software… CAMUG 2013 Agile Appsec 2013 Building Real Software

  3. and what we can do about it… CAMUG 2013 Agile Appsec 2013 Building Real Software

  4. Or… CAMUG 2013 Agile Appsec 2013 Building Real Software

  5. How Agile Development is a major Cause of today’s Insecure Software… CAMUG 2013 Agile Appsec 2013 Building Real Software

  6. and how Agile Development can be the Cure too CAMUG 2013 Agile Appsec 2013 Building Real Software

  7. About the Author • Jim Bird • A software guy that cares about security • Experience in software development, Ops, general management, project management (PMP, CSM, PMI-ACP, SCPM) • Worked with financial services organizations in more than 30 countries • Consulted to IBM, Italian Banking Association, Deutsche Borse, Korea Exchanges, Australian Stock Exchange, … • Currently co-founder and CTO of a major US-based institutional trading service • Helps out at SANS and OWASP • “Building Real Software” blog • Find me on LinkedIn Agile Appsec 2013 Building Real Software

  8. Warning • Lots of information to follow • No pictures of puppies, kittens, babies or Star Trek characters • Stuff you can take away and use later Agile Appsec 2013 Building Real Software

  9. The Problem • As an industry we suck at building secure software • Most developers don’t understand software security (take the test and see how you do) https://www.aspectsecurity.com/news/press/press-release-aspect-security-launches-free-tool-to-measure-gaps-in-developers-application-security-knowledge/ • and we don’t include security in development • Microsoft study 2012: Only 37% of developers follow secure development practices • Ponemon Institute study 2012: 79% of developers followed no or only ad hoc secure development process Agile Appsec 2013 Building Real Software

  10. Agile AKA “the A Word” • Many security experts think that Agileis the problem • Agile Development = Security Fail, Adrian Lane, RSA Conference 2011 http://vimeo.com/15505840 • Agile development is seen in some big shops as being undisciplined and unmanaged • 2010 Study: Agile teams did not take meaningful steps to integrate security into development even when security was a mandated requirement http://www.igi-global.com/article/agile-software-development/46153 • Agile development makes it easier to build more software faster. More software = more vulnerabilities Agile Appsec 2013 Building Real Software

  11. We Suck at Building Secure Software • Major security vulnerabilities are found in common desktop software each month: Windows, Java, Adobe, all of the browsers, Quicktime, … • InformationWeek 2013 Strategic Security Survey • 46% of breaches last year were due to software exploits (OS, mobile or other application) • New technologies like HTML 5 and node.JS introduce new capabilities and new security risks http://www.darkreading.com/applications/beware-of-html5-development-risks/240156891https://www.owasp.org/images/3/31/Node.js_Security_Old_vulnerabilities_in_new_bottles_-_Sven_Vetsch.pdf Agile Appsec 2013 Building Real Software

  12. We Suck at Building Secure Web Apps • 2013 Verizon Data Breach Investigations Report: • 1/3 of all breaches are caused by attacks on Web apps • Probability of being hit by a Web app exploit: 75% • Cenzic Report 2013 • 99% of apps tested had at least 1 serious vulnerability • WhiteHat Security Report 2013 • Average Web app has 56 serious vulnerabilities • 25% of organizations had at least 1 security breach caused by an application vulnerability • Veracode State of Software Security April 2013 • Only 13% of Web apps passed OWASP Top 10 (the most common vulnerabilities) • These are apps that people bothered to test… Agile Appsec 2013 Building Real Software

  13. We Suck at Building Secure Mobile Apps • viaForensics Mobile App Security Study 2011 • Only 17% of apps passed basic tests • 10% of apps stored passwords in plain text • In 2/3 of apps, private or sensitive data was recoverable (private communications, personal data, acct numbers) • Veracode State of Software Security Report 2013 • 64% of Android apps have crypto problems • 42% of iOSapps have information leakage problems • 31% of iOSapps have SQL injection bugs • Ponemon Survey 2012 • 65% of mobile apps aren’t tested at all Agile Appsec 2013 Building Real Software

  14. We Suck at Building Secure Industrial Control Systems • Hacking Industrial Systems Turns out to be Easy, MIT Technology Review, Aug 2013 http://www.technologyreview.com/news/517731/hacking-industrial-systems-turns-out-to-be-easy/ • Backdoor in computer controls opens critical infrastructure to hackers, Oct 2012 http://arstechnica.com/security/2012/10/backdoor-in-computer-controls-opens-critical-infrastructure-to-hackers/ • Researchers expose flaws in popular industrial control systems, InfoWorld, Jan 2012 http://www.infoworld.com/d/security/researchers-expose-flaws-in-popular-industrial-control-systems-184629 Agile Appsec 2013 Building Real Software

  15. Cars, TVs, Toilets, Airplanes… • Smart toilet security flaw could result in nasty surprise, Fox News Aug 2013 http://www.foxnews.com/tech/2013/08/05/smart-toilet-security-flaw/ • The same security risks are in today’s cars, smart homes, TVs, … • http://arstechnica.com/security/2013/07/disabling-a-cars-brakes-and-speed-by-hacking-its-computers-a-new-how-to/ • Hacking airplanes in flight? I did that a year ago…, April 2013 http://www.foxnews.com/tech/2013/04/12/hacking-in-flight-airplane-did-that-year-ago-hacker-says/ Agile Appsec 2013 Building Real Software

  16. The Root Causes • Lack of Knowledge and Skills – Developers Don’t Understand Security • Fundamental Asymmetry – the Bad Guys always Win • Quality – Bad Software is Easy to Hack Agile Appsec 2013 Building Real Software

  17. Developers don’t Understand Security • Not firewalls, DMZs and patching • Not just security features: authentication, access control, auditing • Thinking through workflows and exceptions like a bad guy (abuse cases not use cases) • Understanding security risks and weaknesses in your language and platform stack • Technical details that must be understood and executed perfectly: • crypto, session management, language/platform-specific vulnerabilities and attacks and exploits, secure configuration, context-sensitive data encoding, race conditions (TOC/TOU),… Agile Appsec 2013 Building Real Software

  18. Developers don’t Understand Security • Education and Knowledge Gap • Almost no universities teach software security • Most developers don’t get enough – or any – on the job security training (Ponemon Study, 2012) • Leading books/blogs/conferences on software development and design do not touch on security • Agile 2013 conference example: • 1800 people, 200+ sessions • 1 session on application security (attended by 30 people) • Agile 2013 Eventifier was hacked Agile Appsec 2013 Building Real Software

  19. Security don’t Understand Development • Most security people are network infosec(CISSP), or auditing/compliance/risk • They can’t help developers with appsec • Critical worldwide shortage of appsec expertise: Breakers and especially Builders http://www.appsecireland.org/wp-content/uploads/2012/09/7-Ways-to-Scale-Web-Security-Jeremiah-Grossman.pdf • 17 million developers worldwide • BSIMM says 2% of developers need to be security black belts = 340,000 need advanced appsec training Agile Appsec 2013 Building Real Software

  20. Attacker’s Advantage, and the Defender’s Dilemma • Software Security is an Asymmetric Problem Michael Howard, 8 Simple Rules for Developing More Secure Software http://msdn.microsoft.com/en-us/magazine/cc163518.aspx • Developers must make sure that design and code are perfect • Attackers get in through mistakes and bugs that nobody understands or realizes are important (eg. C/C++ bounds violation) • 1 Bug is all that the bad guys need Agile Appsec 2013 Building Real Software

  21. Attacker’s Advantage, and the Defender’s Dilemma • Ensuring that there are no critical security problems in software is very very hard • With enough money, time and talent (e.g., nation-state backed) targeted attackers can get into any system • But we are making it too easy for the lazy bad guys (opportunistic hackers) • Too many security bugs are too easy to find and exploit… even bugs that are easy to fix and prevent Agile Appsec 2013 Building Real Software

  22. Attacker’s Advantage, and the Defender’s Dilemma • The most common attacks stay the same year over year (XSS, CSRF, Directory Traversal ../, SQL Injection) • SQL injection • The most dangerous security vulnerability for the past 5+ years http://cwe.mitre.org/top25/index.html • Easy to fix – use prepared statements and bind variables • NOSQL databases have injection vulnerabilities too http://blog.fortify.com/blog/2011/04/27/ • Bad guys use SQLi to steal data like email addresses and passwords – which programmers don’t store safely • http://www.mnn.com/green-tech/computers/stories/450000-passwords-stolen-in-yahoo-data-breach • http://www.zdnet.com/over-21000-plain-text-passwords-stolen-from-billabong-7000000842/ Agile Appsec 2013 Building Real Software

  23. Security <> Quality, but… • Security = C-I-A • Confidentiality • Integrity • Availability • All of these are also important factors to Software Quality • “Software security relates entirely and completely to quality. “ Dr. Gary McGraw • A poor quality system cannot be secure • Security vulnerabilities are bugs that need to be eradicated like all the other bugs Agile Appsec 2013 Building Real Software

  24. Agile: the Security Problems CAMUG 2013 Agile Appsec 2013 Building Real Software

  25. The Security Problems in Agile • Agile is about building software quickly • Move fast and iterate, respond to feedback • Emphasis on Velocity: how much Business Value is delivered every 1 or 2 weeks • Short time boxes keep getting shorter (1-month, 2-weeks, 1-week, …) • Deliver software to customer before it is finished • Taken to extreme by teams following Continuous Deployment pushing changes 10-100+ times per day (Facebook, Twitter, Linkedin, …) Agile Appsec 2013 Building Real Software

  26. When is “Fast” too Fast? Agile Appsec 2013 Building Real Software

  27. The Security Problems in Agile • “Move fast and break things. The idea is that if you never break anything, you’re probably not moving fast enough.” Mark Zuckerberg, Facebook • http://www.straight.com/life/carol-todd-asks-facebook-fix-security-failures-putting-kids-risk • http://www.zdnet.com/facebook-admits-failure-in-bug-report-7000019657/ • http://www.thetechherald.com/articles/More-security-failure-as-Phishing-attacks-return-to-Facebook/6017/ • http://grahamcluley.com/2013/06/facebook-owns-privacy-breach-tells-world-late-friday-night/ • http://www.dailymail.co.uk/news/article-2396628/Mark-Zuckerbergs-Facebook-page-hacked-Khalil-Shreateh-expose-site-vulnerability.html • http://thehackernews.com/2013/09/vulnerability-allowed-hacker-to-delete.html • …. Agile Appsec 2013 Building Real Software

  28. The Security Problems in Agile • Emergent Design • 50% of security problems are caused in design (Gary McGraw, Cigital) • De-emphasis on architecture definition in Agile (BDUF is B-A-D) • Only design and build what you need (Simple Design, YAGNI, Minimum Marketable Feature) • Refactor and react to feedback – design on the fly • The Code is the Design - so how do you see design mistakes and oversights? You wait to get feedback from the customer… or from hackers…. Agile Appsec 2013 Building Real Software

  29. The Security Problems in Agile • The Product Owner is King/Queen • Defines requirements, decides what gets done when • Under pressure (and pressures team) to deliver Business Value, Time-to-Market • The Product Owner has too much Responsibility: • Doesn’t always understand what they are supposed to do, or have the time to do it properly • Doesn’t understand security beyond mandated compliance requirements in regulated environments • Doesn’t always understand the risks and threats facing the organization • Doesn’t understand software development Agile Appsec 2013 Building Real Software

  30. The Security Problems in Agile • Security is a Chicken, not a Pig • Only Pigs have a voice – Product Owner, the Team • Pigs decide how software is going to be developed • Security is on the outside looking in – a Chicken, a witness, a nag who can be ignored or pushed off to later • Without explicit security gates/approvals, Security has no control over how work gets done or over priorities or outcomes Agile Appsec 2013 Building Real Software

  31. The Security Problems in Agile • Whole Team and Collective Code Ownership • Everybody shares all the work and all the code • The Team decides how work will be done – will they decide to include secure development practices? • Security work requires special knowledge and a Hacker’s/Breaker’s mindset • Remember the Defender’s Dilemma – even small mistakes have serious consequences • You need your best (technically strongest) people working on security – not everybody will “get it” or will be careful enough Agile Appsec 2013 Building Real Software

  32. The Security Problems in Agile • XP has reinforced the value of testing, but… • TDD, automated unit testing (JUnit) and functional acceptance testing (FIT, FITNesse) – “the feature passes the automated tests, so it must work” • Security is a system testing problem, not a unit testing problem • Many teams don’t have testers, or testers who do anything more than follow acceptance checklists – so who will do security testing? “Why Facebook doesn’t have or need testers” http://www.zdnet.com/blog/facebook/why-facebook-doesnt-have-or-need-testers/7191 Agile Appsec 2013 Building Real Software

  33. The Security Problems in Agile • Sprints and Time Boxes • Work needs to be done in little pieces and time-boxed (smaller = better) • Where do you fit security reviews and testing in Scrum or iterationlessKanban or Continuous Deployment? • E.g. Penetration Testing doesn’t fit nicely into a short Sprint – need time to understand the app, explore, hack, assess risk and understand findings, fix and test again… Agile Appsec 2013 Building Real Software

  34. The Security Problems in Agile • Work is defined through Stories • As a <type of user> I want <something> so that <reason> • Most security requirements are non-functional (like maintainability, supportability) http://www.infoq.com/articles/managing-security-requirements-in-agile-projects • Security risks and activities cut across many stories (constraints on design and implementation) • Cannot always be tested (same as other NFRs) • Security is never “Done” Agile Appsec 2013 Building Real Software

  35. The Security Problems in Agile • Traceability and Assurance • Waterfall has natural gates (requirements, design, code, test, deploy) and hand-off documents for security experts to review and assess risk • But Agile: “working software over comprehensive documentation” • Story cards, white boarding, … “barely sufficient” and discarded when work is done • Code and automated tests are the documentation • How do you prove traceability in Agile? How do you know (and show) that you’ve done a responsible job? Agile Appsec 2013 Building Real Software

  36. Agile: the Security Solution CAMUG 2013 Agile Appsec 2013 Building Real Software

  37. Adding Security to Agile • Security Stories and Abuse Cases • Make security activities/risks part of the backlog • SAFECode Security Stories – common non-functional stories and SDLC tasks for security http://www.safecode.org/publications/SAFECode_Agile_Dev_Security0712.pdf • OWASP Evil User Stories: “As a hacker, I can send bad data in URLs, so I can access data and functions for which I’m not authorized” https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories • Cigital Abuse/Misuse Cases – think like a bad guy http://cigital.com/papers/download/bsi2-misuse.pdf Agile Appsec 2013 Building Real Software

  38. Adding Security to Agile • Abuser Stories • Judy Neher, Agile 2013 • As part of working on / elaborating a story, take some time to explore negative cases • Don’t just think about what the user can do and wants to do • Think about what the user can’t do and doesn’t want to do • Write up negative cases/scenarios and include them in scenarios or add them to the backlog Agile Appsec 2013 Building Real Software

  39. Adding Security to Agile • Security Sprint / Security Push • Test and fix security problems in high-risk areas (as much as you can in a time box) • Train the team, then have them look for and fix security vulnerabilities • Evaluate a static analysis tool, run it for the first time and triage the results • Pen test and then fix what you can before you go live • Band aid: won’t solve your security problems • Like a “Hardening Sprint” - difficult to build a business case for – what value is the customer getting? Agile Appsec 2013 Building Real Software

  40. Build Security In • Try following Microsoft: SDL Agile • Available for free but expensive to follow http://msdn.microsoft.com/en-us/library/windows/desktop/ee790621.aspx • Integrate security activities and controls • Start of project – understand security and privacy requirements, training, assign security lead • Each Sprint – using safe libraries, static analysis in CI, threat/risk modeling on new features • Bucket – code reviews, design reviews, incident response planning (do one of these activities each Sprint) Agile Appsec 2013 Building Real Software

  41. Build Security In • Upfront, Iteration 0 stuff • Understand major risks and threats • Understand requirements for security and privacy, compliance – don’t depend only on Product Owner • Include security in coding guidelines and tools/technology selection • If you’re playing Pigs and Chickens, security must be a Pig – make someone the Security Lead • Include time for security tasks in planning, retrospectives/reviews and “Definition of Done” Agile Appsec 2013 Building Real Software

  42. Build Security In • Training • WhiteHat study: teams with training have 40% fewer vulnerabilities, resolve them 59% faster • Train all developers and testers in basics • SAFECode free training https://training.safecode.org/courses • Coursera free MOOCs in Crypto https://www.coursera.org/instructor/~85 • OWASP Cheat Sheet series https://www.owasp.org/index.php/Cheat_Sheets • Security Lead needs extra training: Denim Group, SANS, Cigital • Don’t forget to train the Product Owner! Agile Appsec 2013 Building Real Software

  43. Build Security In • Design and Architecture • Understand the security capabilities of your framework (.NET, Rails, Play, Spring, Django, Yii, iOS, Android, …) • Authentication and Identity Management • Access Control (deny by default) • Auditing (including log injection protection) • Session Management (including CSRF protection) • Data access layer (SQL injection) • Keep frameworks patched and up to date and monitor for vulnerabilities (serious Rails vulnerabilities in 2013, …) Agile Appsec 2013 Building Real Software

  44. Build Security In • Design and Architecture • Use a security library to fill in security gaps: • OWASP ESAPI (for enterprise apps, especially Java) • Apache Shiro (Java general security toolkit) • JASYPT (Java encryption) • Microsoft’s Anti-Cross Site Scripting library (.NET) • IronBoxAntiSQLi (.NET) • OWASP Java HTML Sanitizer (XSS protection) • If you really know enough to write your own crypto, why are you here reading this slide? Agile Appsec 2013 Building Real Software

  45. Build Security In • Attack Surface • How bad guys get in: forms, fields, parms, cookies, files, URLs, APIs, run-time args, configs, sockets, databases… and the code behind this • As you add features, attack surface increases: • Just changing the same code again, adding another field or form…? • Adding a new API, or a mobile interface, or hooking up to a new service? • Introducing a new piece of confidential/secret data? • Changing the stack or plumbing (web server, security library, back-end data store…)? • What additional testing/reviews should be done? Agile Appsec 2013 Building Real Software

  46. Build Security In • Follow the Data • Identify critical data • Private/confidential data (PII, credit card, medical, anything to do with children, financial, …), tokens/passwords/session ids and other credentials, secrets, config, … • Follow this data through the system • What is the source (is the source authenticated, can you tell if the data is being replayed)? • Where is it validated and sanitized? • Where is it stored (does it have to be stored)? • Should it be encrypted or masked? • Where is it displayed and used, are the users authorized? • Who can change it, is this access audited? • Do I need to protect it with a checksum/digital signature? Agile Appsec 2013 Building Real Software

  47. Build Security In • Focus on High-Risk Code • Security plumbing, network-facing APIs, file handling, command and control (root) functions, data validation, error handling, database access layer, auto-update, … • If any High-Risk code is changed: review and testing must be done • Team Ground Rule, or automatically through check-in monitoring (Etsy, Zane Lackey) http://www.slideshare.net/zanelackey/effective-approaches-to-web-application-security Agile Appsec 2013 Building Real Software

  48. Build Security In • Be Careful with High-Risk Code • Code in pairs (always at least one senior developer) • Use OWASP Secure Coding Checklist https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide • Expert Security Code Review • Bring in an outside expert/consultant • Help them to understand the code and design • Time-box their review • Make sure you understand what they found, why it is a problem, and how to fix it • Maybe get them to review your fixes too Agile Appsec 2013 Building Real Software

  49. Build Security In • Write Code that “doesn’t boink” • Correctness and usability isn’t enough • Clean code isn’t enough – although it helps (security and quality problems are correlated with complexity) • Use safe functions and APIs (understand your language and platform and use them properly) • Pay attention to data validation (client-side isn’t enough, strong white-list vs weak black-list) • Error handling and exception handling (check return codes, fail closed, watch for information leakage) • Manage threads and memory carefully • Log and trace – but don’t log confidential/private data Agile Appsec 2013 Building Real Software

  50. Build Security In • Static Analysis Checkers (Source/Binary) • Start with picky Compiler options and flags, and IDE • Continuous Integration: Fail build on serious bugs • Java • Free: Findbugs and PMD (or SonarQube) – superficial but common security bugs • Expensive: Coverity, Fortify, Klocwork, Appscan, Checkmarx – deeper, interprocedural data flow and control flow analysis • .NET • Microsoft FxCop, CAT.NET, MS Source Code Analyzer for SQL Injection, BinScope • PHP: RIPS • Ruby: Brakeman • Binary analysis (if you don’t have source): VeracodeSaaS Agile Appsec 2013 Building Real Software

More Related