Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Towards a Secure Software Development Lifecycle

Towards a Secure Software Development Lifecycle

These are the slides of the talk given at the Security Meetup by SBA Research: https://www.meetup.com/Security-Meetup-by-SBA-Research/events/257211889/

While everyone seeks to be on the cutting edge of hacks and bugs, the number of rather basic issues in software security are still usually unresolved. The SBA Security Meetup on January 17, 2019 strives to explain why basic software security measures have the potential to solve a good number of existing threats, why many of them are still not done, and why many of them are a question of the software development process instead of just pure coding. “Software security is about integrating security practices into the way you build software, not integrating security features into your code”, says Gary McGraw, an expert for software security an author of many books and articles in this field. We’ll explore this in this meetup.

In this talk, Thomas Konrad explores what a secure software development lifecycle can look like. What needs to be done in the requirements phase? Why are the design phase and technology decisions so important for security? What is a threat model and when and how should it be done? How can we categorize security bugs, and what can we do about them? How about testing and automation? What are non-tech aspects of a secure development lifecycle?

Thomas Konrad

January 17, 2019
Tweet

More Decks by Thomas Konrad

Other Decks in Technology

Transcript

  1. Classification: Public 2 Towards A Secure SDLC Let’s Build Security

    Into The Way We Build Software! Thomas Konrad, Meetup at SBA Research on Jan 17th, 2019 SBA Research gGmbH, 2019
  2. Classification: Public 3 About SBA Research an Me • SBA

    Research o Founded in 2006 o Biggest research center for IT security and one of the largest security service providers in the DACH countries o Know-how in research, audits, consulting, implementation and operation under one roof • Thomas Konrad o Pentester, Software Security Guy o Started 2010 at SBA Research o Pentesting, Web Application Security, Software Development, Training SBA Research gGmbH, 2019
  3. Classification: Public 4 Software Security is ... • The absolute

    absence of security bugs • Coding fast, then fixing what we did wrong • A security test after we have launched • Security features in our code • Putting a WAF in front of the sh** SBA Research gGmbH, 2019
  4. Classification: Public 8 SDLC Oftentimes “Backwards Integration“ of Security How

    do I recover? How do I react on problems? How do I detect problems? How do I protect? What to protect and why? Ad-hoc Security Integration Security testing before Go-Live Incident
  5. Classification: Public 9 Core Security Concepts SBA Research gGmbH, 2019

    Image source: http://www.scriptcaseblog.net/basic-software-security-concepts/
  6. Classification: Public 10 Prioritize! • Not every app carries sensitive

    data • Not every app has 1M users • The real thing would be a Business Impact Analysis (BIA) o But we want to keep it easy for now! o Give every app a rough C/I/A rating of 0 to 3 o Start with the 3s! SBA Research gGmbH, 2019
  7. Classification: Public 11 BIA Quickie Aspect Low Medium High Critical

    Confidentiality (What if a third party can access the data?) E.g., public data E.g., internal, but not sensitive data E.g., organizational processes E.g., trade secrets Integrity (What if a third party can manipulate the data?) E.g. profile pictures E.g. customer contacts E.g. user permissions E.g. medical diagnosis data Availability (What if the data is not available?) E.g. archived data E.g. past email communicatio ns E.g. emails E.g. patient‘s records SBA Research gGmbH, 2019
  8. Classification: Public 13 Secure Software Requirements • What‘s not required,

    might not be implemented • Without software requirements, software will fail and without secure software requirements, organizations will • We need basic and reusable security requirements for our organization! SBA Research gGmbH, 2019
  9. Classification: Public 14 Secure Software Requirements • Common misconceptions o

    „But security is their responsibility, not mine!” o Throwing a whole standard at somebody works o We have to redefine that for every piece of software SBA Research gGmbH, 2019
  10. Classification: Public 16 Typical Requierments ... ... that are often

    not accounted for: „Security-relevant input that has a specific target format (such as an email address or URL) and where one has to be able to determine its uniqueness, has to be canonicalized.“ Example: [email protected][email protected] SBA Research gGmbH, 2019
  11. Classification: Public 17 Typical Requierments ... ... that are often

    not accounted for: “If user input is concatenated into data structures such as SQL, HTML, JavaScript, JSON, XML, CSV, LDAP filters, SMTP, XPATH, etc., there has to be context-sensitive output encoding according to the target format, or the concatenation has to be avoided altogether.” SBA Research gGmbH, 2019
  12. Classification: Public 18 Typical Requierments ... ... that are often

    not accounted for: „The application needs to implement countermeasures against password guessing attacks while also minimizing the risk of systematically locking out users, according to the confidentiality/integrity and availability requirements. SBA Research gGmbH, 2019
  13. Classification: Public 19 Typical Requierments ... ... that are often

    not accounted for: „The users of the system must receive email notifications upon sensitive actions with their user account such as the login on a new device, a password change, changes to MFA settings, the lockout of the account, etc.“ SBA Research gGmbH, 2019
  14. Classification: Public 23 Secure Design Concepts • We want the

    software to be secure by design. SBA Research gGmbH, 2019 Image source: http://www.scriptcaseblog.net/basic-software-security-concepts/
  15. Classification: Public 24 Technology Decisions • They can make a

    difference! o How well does Framework X protect me against XSS automatically? o Can a message queue make my app meet availability requirements? o Does the library have a centralized means of declare access control rules (think “/api/admin”: “ROLE_ADMIN”)? o ... SBA Research gGmbH, 2019
  16. Classification: Public 25 Technology Decisions • Indicators for a good

    framework / library o The security track record (if there is none, run!) o How often the word „security“ is mentioned in the docs (and how, of course) o Whether there is a security@ email address • Think well about it, this is hard to reverse! SBA Research gGmbH, 2019
  17. Classification: Public 26 Threat Model! • Four questions 1. What

    are we building? 2. What can go wrong? 3. What are we doing about that? 4. Did we do a good enough job? SBA Research gGmbH, 2019
  18. Classification: Public 29 Context-Sensitive Output Encoding • Think about all

    of these o SQL statements (SQL Injection) o HTML (Cross-Site Scripting) o XML (XML Injection) o CSV (CSV Injection) o LDAP filters (LDAP Injection) o OS commands (OS Command Injection) o XPath queries (XPath Injection) o STMP commands (SMTP Injection) • The core of all these problems? The lack of context- sensitive output encoding! SBA Research gGmbH, 2019
  19. Classification: Public 30 Input Validation • No user input without

    validation! o At least a maximum length o A date should be e date within a range o A number should be a number o An email... You get the point! • Watch out: This does not protect against specific threats! But it‘s a good baseline and can slow attackers down. SBA Research gGmbH, 2019
  20. Classification: Public 31 Canonicalization • Sometimes, uniqueness is security-critical o

    Email addresses ([email protected] vs. [email protected] vs. [email protected]) o URLs (https://www.a.com vs. https://www.a.com/ vs. https://www.a.com:443/ vs. ...) o IP addresses (127.0.0.1 vs. 2130706433) SBA Research gGmbH, 2019
  21. Classification: Public 32 Check Buffer Lenghts in Languages Without Memory

    Management • Otherwise we have buffer overflows! • Relevant in languages without memory management o C o C++ o ... • Languages safe from this problem o Java o C# o Interpreted languages (Python, Ruby, PHP, ...) o Go o Rust SBA Research gGmbH, 2019
  22. Classification: Public 33 Access Control at Each Request • This

    is also referred to as the Principle of complete mediation • Function-level access control o A.k.a., „Does the user have the role to access this part of the page?“ o https://www.example.com/admin • Object-level access control o A.k.a. „Does the object with this ID actually belong to this user? o https://www.bank.com/account-details/38520 SBA Research gGmbH, 2019
  23. Classification: Public 34 Session Management • Watch out for these

    things in session management o Sessions are identified by a random token. o There is a server-side idle timeout (the length depends on the sensitivity of the data). o Uses can log out, and logging out fully destroys the session on the server side. SBA Research gGmbH, 2019
  24. Classification: Public 35 Session Management • Watch out for these

    things in session management o Users have the ability to see all devices they have ever used to log in, and the corresponding sessions. o They can revoke devices / sessions in the user interface if necessary. o Users get email notifications upon critical actions, such as the login from a new device, an account lockout, or changes to security settings. SBA Research gGmbH, 2019
  25. Classification: Public 36 Generating Random Numbers „Random numbers are absolutely

    essential for a crypto library, if they suck we don’t even have to get started with encryption or anything else, because it all collapses to something trivially deterministic and therefore predictable.” Martin Boßlet SBA Research gGmbH, 2019
  26. Classification: Public 37 Generating Random Numbers • Generally: Use libsodium

    if you can! • In Java, use SecureRandom • In C#, use RNGCryptoServiceProvider • In Ruby 2.5+, use SecureRandom • In Python, use os.urandom() • In PHP 7+, use random_int() • In Linux, use /dev/urandom • In C[++], use what the OS provides o Windows: CryptGenRandom o Linux: getrandom() if available, else /dev/urandom • In Go, use crypto/rand • In Rust, use rand::os::{OsRng}; • In JavaScript (in the browser), only use window.crypto.getRandomValues() SBA Research gGmbH, 2019
  27. Classification: Public 38 Exception Handling • Don‘t show detailed error

    messages or stack traces to users • How can we still get the details? o Generate a random log reference upon an exception (most logging libraries can do this) o Write that reference into the log o Show that reference to the user o If they call support, ask them for the number SBA Research gGmbH, 2019
  28. Classification: Public 39 Software Security Testing How to verify whether

    we‘ve done a good job SBA Research gGmbH, 2019
  29. Classification: Public 40 Types Of Security Tests • Penetration test

    • Static source code analysis • Automated dynamic tests • Dependency checks • Unit tests • (Design / architecture reviews) • ... SBA Research gGmbH, 2019
  30. Classification: Public 41 Penetration Test • What? o Attack simulation

    o White box / grey box / black box o Less prone to false positives o Focus on exploitabilty (PoC) • When? o Should be done on a regular basis SBA Research gGmbH, 2019
  31. Classification: Public 42 Dependency Checks: CI/CD For The Win! •

    Check for known vulnerabilities in your depencencies • This is crucial! • Things to consider o Automate, automate, automate! o Get over that first „security bump“! o Send actionable notifications! o Fail that build! SBA Research gGmbH, 2019
  32. Classification: Public 43 Dependency Checks • Tools you can use

    o OWASP Dependency Check (best for Maven) o OWASP SafeNuGet (for NuGet, obviously) o SonarQube o GitLab (they acquired Gemnasium) o retire.js o npm now has this built-in o yarn audit o SensioLaabs Security Checker (PHP) o ... SBA Research gGmbH, 2019
  33. Classification: Public 45 Keep An Eye on You Logs! •

    Make sure security-sensitve actions are logged o Failed login attempts o Denied access to a area / object o ... • Create visibility! o Set thresholds and notify when exceeded • Start simple! SBA Research gGmbH, 2019
  34. Classification: Public 47 The First Steps towards a Secure SDLC

    • Get the right mindset! It‘s the way we build software, not features. • Understand the core concepts (CIA) and prioritize your software by them. • Write some basic security requirements that tend to repeat themselves in your organization, and include them in the requirements analysis. SBA Research gGmbH, 2019
  35. Classification: Public 48 The First Steps towards a Secure SDLC

    • Include security into technology decisions. • When the design is done, create and maintain a centralized threat model for important modules. • Learn the most common implementation mistakes and internalize them. Think like an attacker, always! SBA Research gGmbH, 2019
  36. Classification: Public 49 The First Steps towards a Secure SDLC

    • As a first step towards automation, check your dependencies for known security issues. • Do external penetration testing. • Log security-relevant events and implement some basic monitoring. • Hack yourself from time to time, and have fun doing so! SBA Research gGmbH, 2019
  37. Classification: Public 51 sec4dev • Security conference for developers •

    Feb 25 to 27, 2019 o Day 1: Whole-day bootcamps o Day 2: Talks, conf dinner o Day 3: Talks • TU Wien, Campus Gußhaus • https://sec4dev.io
  38. Classification: Public 52 Thomas Konrad SBA Research gGmbH Favoritenstraße 16,

    1040 Vienna [email protected] @_thomaskonrad SBA Research gGmbH, 2019 Thank you!