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

Integrating Information Security into your Software Development Lifecycle

A01b931867096ec8874202e233279212?s=47 Simon Sturmer
November 01, 2017

Integrating Information Security into your Software Development Lifecycle

Security is a critical part of building a product, startup or software system. Many businesses unknowingly get this aspect of technology very wrong and they may not find out until damage has already been done. It's important to use secure software tools and processes, ensure your dev team is conscious of security best-practices and be aware of the common pitfalls when developing software. This talk focuses on the fundamentals of information security and how it applies to software developers.

A01b931867096ec8874202e233279212?s=128

Simon Sturmer

November 01, 2017
Tweet

Transcript

  1. Integrating Information Security into your Software Development Lifecycle

  2. Hello. I’m Simon Sturmer I like software development, startups and

    infosec. You can find me at: @sstur_
  3. Let’s talk about Security

  4. “THE FIRST SIX months of 2017 have seen an inordinate

    number of cybersecurity meltdowns” - wired.com
  5. None
  6. None
  7. LET’S EXPLORE THE PROBLEM

  8. INFORMATION SECURITY ▸ Security is hard. ▸ Tech professionals don’t

    always get it. ▸ There’s a lot of confusing information. ▸ The tools we have are broken.
  9. AS DEVELOPERS We can do things. To make the problem

    less bad.
  10. WHAT ARE THE CAUSES? If we look at Heartbleed, WannaCry,

    Blueborne, Experian and the dozens of severe incidents in recent years…
  11. WHAT ARE THE CAUSES? … we’ll notice a few things

    of interest to developers. ▸ Buffer Overflows and memory safety issues ▸ Broken and unpatched software ▸ Programmer mistakes
  12. I want to talk about the software we write.

  13. SAFER CODE As an industry, we need to write safer

    code. Type safety and Memory Safety: ▸ Prevent buffer overflows, out of bounds reads, use after free, etc. ▸ Languages: Go, Rust, Swift, Kotlin, Ocaml
  14. “Programming in C means you are using an unsafe memory

    model 100% of the time.” - Tony Arcieri – It’s time for a memory safety intervention
  15. MEMORY SAFETY As an industry we have gone to great

    lengths to work around our rampant use of unsafe languages. ▸ Address Space Randomization ▸ Elaborate static analysis tools ▸ Kernel-level safeguards
  16. “Address space randomization is an OS-level workaround for a language-level

    problem” - Golang and Rustlang Memory Safety
  17. A real thing that happened in the world.

  18. Typical update list full of memory safety issues.

  19. PATCH YOUR STUFF! Most software is broken.

  20. None
  21. None
  22. SOFTWARE PATCHES Make a Policy about Updates You need to

    patch your: ▸ Operating System(s) and drivers ▸ Server Software (Apache, etc.) ▸ Runtimes (PHP, Node, etc.) ▸ Tooling (Curl, IDE, Browser) ▸ Libraries (Rails, React, Django) ▸ … also, everything else.
  23. Let’s talk about WEB

  24. WEB-BASED RISKS Risks facing Web Developers ▸ Man in the

    Middle (MitM) attacks ▸ XSS, CSRF and other JS-based ▸ Server-side (SQL-injection, etc.) ▸ Fraud: Phishing, account enumeration, password attacks ▸ Denial of Service
  25. HTTPS? When should you use AKA Secure HTTP (SSL /

    TLS)
  26. ALWAYS! Every site. Every request.

  27. SECURE TRANSPORT LAYER OK, but is HTTPS really necessary for:

    ▸ Site with no ecommerce / payments? ▸ Simple blog/WordPress site? ▸ Content-based website like news? ▸ Basic company brochure site?
  28. Let’s use a case study…

  29. DATA INTEGRITY ▸ Here we have an integrity problem …

    (data integrity) ▸ “Man in the Middle” modifies HTML coming from server. ▸ Removes your site’s ads and places their own. ▸ Ad Revenue for you: $0
  30. Content Manipulation

  31. HTTPS PROTECTS YOUR CONTENT & REVENUE

  32. SECURE TRANSPORT LAYER HTTPS Provides 3 things: ▸ Confidentiality ▸

    Integrity ▸ Authenticity It doesn’t solve everything, but it should be a fundamental part of your infosec strategy.
  33. Another Reason to use HTTPS

  34. NOT PREPARED? You’re not alone. HTTPS IS COMING!

  35. “86% of the Alexa Top 1 million websites aren't served

    over HTTPS” As of mid-2017
  36. SECURE TRANSPORT LAYER Two easy options for HTTPS: ▸ Cloudflare

    (free) ▸ Let’sEncrypt (free)
  37. SECURE TRANSPORT LAYER Also: ▸ Enforce HTTPS using the HSTS

    Header (HTTP Strict Transport Security) ▸ Automate certificate renewal.
  38. Web Security: XSS

  39. CAN YOU SPOT THE XSS VULNERABILITY?

  40. WEB SECURITY Catching XSS mistakes is hard. Even for experienced

    programmers. ▸ Hint: JSON.stringify() does not escape ‘</script>’
  41. WEB SECURITY Mitigating these kinds of errors: ▸ Peer review

    code. ▸ Compartmentalize different systems. ▸ If your system is critical, get it audited by a team of professionals. ▸ Run a bug bounty (BugCrowd)
  42. “Most of the vulnerabilities found were due to poor programming

    techniques. ...most of the bugs discovered were very basic mistakes.” - Project Zero (Google)
  43. Handling Passwords

  44. None
  45. HANDLING PASSWORDS Passwords: ▸ Do not set arbitrary length limits

    (NIST recommends no less than 256 chars) ▸ Never prohibit any special characters ▸ Allow paste and password managers ▸ Always [salted] hash. Never store a password using reversible encryption! ▸ Offer two-factor authentication.
  46. “People cannot create strong, unique passwords across all their services

    using only their brain to remember” - Troy Hunt
  47. HANDLING PASSWORDS Additionally NIST recommends: ▸ Do not implement password

    expiration. ▸ Do not impose composition rules (such as mixture of letters, numbers and special characters) * Microsoft agrees ▸ Do not use password hints.
  48. HANDLING PASSWORDS Extra credit: ▸ Replace password composition rules with

    real-time checking against known password dumps (data breaches). ▸ An example of such a database is haveibeenpwned.com
  49. Dealing with Fraud

  50. Phishing. This is hard to mitigate. 2fac helps a lot.

  51. Hint: this site is not PayPal

  52. Hint: this IS a real Equifax site

  53. PHISHING Can you tell if it’s the real site? ▸

    Well neither can anyone else. ▸ Equifax accidentally tweeted a link to a SIMILAR domain that was not theirs.
  54. Summary: Actionable Items ▸ Choose Type-safe and Memory-safe technologies ▸

    Patch your software ▸ Use HTTPS ▸ Programmers make mistakes: Use code review ▸ Implement a bug bounty program ▸ …
  55. Summary (cont.) ▸ Use hosting best practices (compartmentalize to mitigate

    breaches) ▸ Use password best practices ▸ Use two-factor auth ▸ Condition your users to look for signals of authenticity (mitigate phishing)
  56. IF TIME PERMITS There’s so much more! ▸ The terrible

    state of IoT ▸ Account Enumeration and timing attacks ▸ Generating random numbers with adequate entropy. ▸ Bug Bounties done right. ▸ Keeping secret keys safe. ▸ Attacks that layer vulnerabilities
  57. In some ways, your goal is to be slightly less

    terrible than everyone else. The current state of security
  58. Thanks. I’m Simon Sturmer You can find me at: @sstur_