Integrating Information Security into your Software Development Lifecycle

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Let’s talk about Security

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

LET’S EXPLORE THE PROBLEM

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

I want to talk about the software we write.

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

“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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

A real thing that happened in the world.

Slide 18

Slide 18 text

Typical update list full of memory safety issues.

Slide 19

Slide 19 text

PATCH YOUR STUFF! Most software is broken.

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

Let’s talk about WEB

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

ALWAYS! Every site. Every request.

Slide 27

Slide 27 text

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?

Slide 28

Slide 28 text

Let’s use a case study…

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Content Manipulation

Slide 31

Slide 31 text

HTTPS PROTECTS YOUR CONTENT & REVENUE

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

Another Reason to use HTTPS

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Web Security: XSS

Slide 39

Slide 39 text

CAN YOU SPOT THE XSS VULNERABILITY?

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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)

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Handling Passwords

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Dealing with Fraud

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Hint: this site is not PayPal

Slide 52

Slide 52 text

Hint: this IS a real Equifax site

Slide 53

Slide 53 text

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.

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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)

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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