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

Integrating Information Security into your Software Development Lifecycle

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.

Simon Sturmer
PRO

November 01, 2017
Tweet

More Decks by Simon Sturmer

Other Decks in Technology

Transcript

  1. Integrating
    Information Security
    into your Software Development
    Lifecycle

    View Slide

  2. Hello.
    I’m Simon Sturmer
    I like software development,
    startups and infosec.
    You can find me at:
    @sstur_

    View Slide

  3. Let’s talk about
    Security

    View Slide

  4. “THE FIRST SIX months
    of 2017 have seen an
    inordinate number of
    cybersecurity meltdowns”
    - wired.com

    View Slide

  5. View Slide

  6. View Slide

  7. LET’S EXPLORE THE
    PROBLEM

    View Slide

  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.

    View Slide

  9. AS DEVELOPERS
    We can do things.
    To make the
    problem less bad.

    View Slide

  10. WHAT ARE
    THE CAUSES?
    If we look at
    Heartbleed,
    WannaCry,
    Blueborne,
    Experian and
    the dozens of
    severe
    incidents in
    recent years…

    View Slide

  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

    View Slide

  12. I want to talk about the
    software we write.

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  16. “Address space randomization
    is an OS-level workaround for
    a language-level problem”
    - Golang and Rustlang Memory Safety

    View Slide

  17. A real thing
    that happened
    in the world.

    View Slide

  18. Typical update list
    full of memory
    safety issues.

    View Slide

  19. PATCH YOUR STUFF!
    Most software is broken.

    View Slide

  20. View Slide

  21. View Slide

  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.

    View Slide

  23. Let’s talk about
    WEB

    View Slide

  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

    View Slide

  25. HTTPS?
    When should you use
    AKA Secure HTTP (SSL / TLS)

    View Slide

  26. ALWAYS!
    Every site. Every request.

    View Slide

  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?

    View Slide

  28. Let’s use a
    case study…

    View Slide

  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

    View Slide

  30. Content Manipulation

    View Slide

  31. HTTPS PROTECTS YOUR
    CONTENT & REVENUE

    View Slide

  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.

    View Slide

  33. Another Reason to use HTTPS

    View Slide

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

    View Slide

  35. “86% of the Alexa Top 1
    million websites aren't
    served over HTTPS”
    As of mid-2017

    View Slide

  36. SECURE
    TRANSPORT
    LAYER
    Two easy options for HTTPS:
    ▸ Cloudflare (free)
    ▸ Let’sEncrypt (free)

    View Slide

  37. SECURE
    TRANSPORT
    LAYER
    Also:
    ▸ Enforce HTTPS using the
    HSTS Header
    (HTTP Strict Transport Security)
    ▸ Automate certificate renewal.

    View Slide

  38. Web Security: XSS

    View Slide

  39. CAN YOU SPOT
    THE XSS
    VULNERABILITY?

    View Slide

  40. WEB
    SECURITY
    Catching XSS mistakes is hard.
    Even for experienced programmers.
    ▸ Hint: JSON.stringify() does not
    escape ‘’

    View Slide

  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)

    View Slide

  42. “Most of the vulnerabilities
    found were due to poor
    programming techniques.
    ...most of the bugs
    discovered were very basic
    mistakes.”
    - Project Zero (Google)

    View Slide

  43. Handling Passwords

    View Slide

  44. View Slide

  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.

    View Slide

  46. “People cannot create strong,
    unique passwords across all
    their services using only their
    brain to remember”
    - Troy Hunt

    View Slide

  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.

    View Slide

  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

    View Slide

  49. Dealing with Fraud

    View Slide

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

    View Slide

  51. Hint: this site is not PayPal

    View Slide

  52. Hint: this IS a real Equifax site

    View Slide

  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.

    View Slide

  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
    ▸ …

    View Slide

  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)

    View Slide

  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

    View Slide

  57. In some ways, your goal is to
    be slightly less terrible than
    everyone else.
    The current state of security

    View Slide

  58. Thanks.
    I’m Simon Sturmer
    You can find me at:
    @sstur_

    View Slide