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

November 01, 2017

More Decks by Simon Sturmer

Other Decks in Technology


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

    number of cybersecurity meltdowns” - wired.com
  2. 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.
  3. WHAT ARE THE CAUSES? If we look at Heartbleed, WannaCry,

    Blueborne, Experian and the dozens of severe incidents in recent years…
  4. 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
  5. 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
  6. “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
  7. 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
  8. 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.
  9. 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
  10. 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?
  11. 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
  12. 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.
  13. SECURE TRANSPORT LAYER Also: ▸ Enforce HTTPS using the HSTS

    Header (HTTP Strict Transport Security) ▸ Automate certificate renewal.
  14. WEB SECURITY Catching XSS mistakes is hard. Even for experienced

    programmers. ▸ Hint: JSON.stringify() does not escape ‘</script>’
  15. 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)
  16. “Most of the vulnerabilities found were due to poor programming

    techniques. ...most of the bugs discovered were very basic mistakes.” - Project Zero (Google)
  17. 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.
  18. “People cannot create strong, unique passwords across all their services

    using only their brain to remember” - Troy Hunt
  19. 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.
  20. 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
  21. 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.
  22. 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 ▸ …
  23. 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)
  24. 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
  25. In some ways, your goal is to be slightly less

    terrible than everyone else. The current state of security