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.

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
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.
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
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_