Be Agile, Not Vulnerable: Security engineering in an agile world

Slide 1

Slide 1 text

Be Agile, Not Vulnerable: Security Engineering in an agile world Jacob Kaplan-Moss [email protected]

Slide 2

Slide 2 text

Every day, Heroku deploys 100 times

Slide 3

Slide 3 text

about:me

Slide 4

Slide 4 text

Co-BDFL about:me

Slide 5

Slide 5 text

Director of Security Co-BDFL about:me

Slide 6

Slide 6 text

Security is a process, not a product.

Slide 7

Slide 7 text

Heroku’s security team: @jacobian @tmaher

Slide 8

Slide 8 text

Security is everyone’s responsibility.

Slide 9

Slide 9 text

The OWASP Top 10 https://www.owasp.org/index.php/Top_10_2013 1. Injection 2. Broken authentication and session management 3. XSS 4. Insecure direct object references 5. Security misconfiguration 6. Sensitive data exposure 7. Missing function-level access control 8. CSRF 9. Components with known vulnerabilities 10. Unvalidated redirects

Slide 10

Slide 10 text

A thought experiment...

Slide 11

Slide 11 text

You’re working on an API library. There are three formats in common use in these types of API. Do you support all three of them? Does this decision have security ramifications?

Slide 12

Slide 12 text

You need to store some configuration data. A is a common dependency, very readable, and used by most Python developers. B is less common, harder to read and write, and isn’t used as often. Which do you choose? Does this decision have security ramifications?

Slide 13

Slide 13 text

You’re implementing a serialization format. At first it only supports primitive types, but users quickly request that you extend the language to allow serialization of arbitrary objects. Do you say yes? Does this decision have security ramifications?

Slide 14

Slide 14 text

Did you just create a vulnerability?

Slide 15

Slide 15 text

2013 Ruby/Rails YAML Vulnerabilities http://www.sitepoint.com/anatomy-of-an-exploit-an-in-depth-look-at-the-rails-yaml-vulnerability/ http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/

Slide 16

Slide 16 text

“LOL Rails suxxors amirite!?”

Slide 17

Slide 17 text

STFU.

Slide 18

Slide 18 text

Real-world security issues are multifaceted.

Slide 19

Slide 19 text

“Secure by default” matters.

Slide 20

Slide 20 text

You can’t prove that software is secure. You can only fail to prove that it’s insecure.

Slide 21

Slide 21 text

“There are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don't know. But there are also unknown unknowns – there are things we do not know we don't know.” — Donald Rumsfeld

Slide 22

Slide 22 text

If an issue of this magnitude was discovered in your stack, would you be prepared to respond?

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

How severe are these issues?

Slide 25

Slide 25 text

“not too bad” “no big deal” “kinda serious”

Slide 26

Slide 26 text

“The sky is falling!” . . . . . “No big deal.”

Slide 27

Slide 27 text

A good security policy Lays out standard terminology used when talking about security issues. Explains the expectations and commitments around vulnerability handling. Creates a transparent, repeatable assessment mechanism.

Slide 28

Slide 28 text

Terminology Advisory Low Medium High Critical

Slide 29

Slide 29 text

Advisory Issues that the security team wishes to communicate but that carry no specific required action. May sometimes contain recommended actions, but no specific response is required to an advisory, and no timeline is defined.

Slide 30

Slide 30 text

Low Issues that need to be resolved, but have either a low risk of exploit or low consequences for an exploit. Should not interrupt day-to-day operations, but should be scheduled for the next appropriate slack time.

Slide 31

Slide 31 text

Medium Issues that carry a noticeable risk, but are still theoretical, not ongoing, or have a low impact. Expect Medium vulnerabilities to cause limited interrupts, but otherwise have minimal impact on normal operations.

Slide 32

Slide 32 text

High Carry a substantial risk to your customers, finances, reputation or otherwise. Expect High-level vulnerabilities to interrupt several developers, perhaps from multiple teams.

Slide 33

Slide 33 text

Critical Critical vulnerabilities threaten the integrity of your company, contain substantial financial risk, or are otherwise “sky is falling”-level issues. These are literally existential threats to your company. Critical vulnerabilities are “all hands on deck” moments.

Slide 34

Slide 34 text

Assessment

Slide 35

Slide 35 text

Start here: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

Slide 36

Slide 36 text

Risk = Likelihood × Impact

Slide 37

Slide 37 text

Likelihood: How likely is it that this issue will be discovered and exploited?

Slide 38

Slide 38 text

Impact: If exploited, what are the ramifications on the company?

Slide 39

Slide 39 text

4. What resources are required for an attacker to exploit the vulnerability? (0) Full superuser-level access (sudo access) (2) Staff-level access (access to internal tools) (4) Special access required (needs a particular type of account) (7) Limited access required (anyone with an account) (9) No access or resources required

Slide 40

Slide 40 text

E.g.: PostgreSQL argument injection vulnerability http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1899 http://bit.ly/13ds9X0

Slide 41

Slide 41 text

Likelihood: threat agent

Slide 42

Slide 42 text

1. How technically skilled is the attacker? (3) Network and programming skills - The attack requires a carefully required connection string, so we assume an attacker would need some network and programming skills.

Slide 43

Slide 43 text

2. How motivated is this attacker? (9) High reward - in a worst-case, the attack could be used to remotely access arbitrary databases, which is quite valuable.

Slide 44

Slide 44 text

3. What resources and/or opportunities are required for this attacker to find and exploit the vulnerability? (9) No access or resources required

Slide 45

Slide 45 text

4. How large is group of potential threat agents? (9) Anonymous Internet users

Slide 46

Slide 46 text

Likelihood: ease of discovery and exploit

Slide 47

Slide 47 text

5. How easy would it be for an attacker to discover this vulnerability? (3) Difficult - the vulnerability existed in PostgreSQL for many years and went undiscovered, and was eventually only discovered by a core contributor.

Slide 48

Slide 48 text

6. How easy would it be to actually exploit the vulnerability, assuming knowledge that it exists? (5) Easy - once you know of the vulnerability, it's easy to craft a proof of concept.

Slide 49

Slide 49 text

7. How well-known is this vulnerability among the community of potential attackers? (1) Unknown

Slide 50

Slide 50 text

8. How likely is it that we'd detect an exploit (or attempt)? (6) Logged and and reviewed eventually

Slide 51

Slide 51 text

Total likelihood: (3+9+9+9+3+5+1+6)/8 5.625

Slide 52

Slide 52 text

Impact: confidentiality and integrity

Slide 53

Slide 53 text

1. How much private data would be disclosed, and how sensitive would that data be? (9) Complete data disclosure

Slide 54

Slide 54 text

2. How much data could be corrupted, and how damaged would that data be? (7) Extensive corruption to much customer data with difficult or incomplete recovery possible.

Slide 55

Slide 55 text

Impact: availability and accountability

Slide 56

Slide 56 text

3. How much downtime would an exploit cause, and how vital would that downtime be? (9) Complete outage

Slide 57

Slide 57 text

4. How easy would it be to trace an exploit back to the attacker? (7) Partially traceable

Slide 58

Slide 58 text

Impact: business factors

Slide 59

Slide 59 text

5. How much financial damage would we suffer as a result of an exploit? (7) Significant and noticeable effect on annual profit

Slide 60

Slide 60 text

6. Would an exploit result in reputation damage that would harm our business or our brand? (7) - worse than "loss of public goodwill", not quite "long-term or permanent brand damage"

Slide 61

Slide 61 text

7. How much legal/regulatory exposure would an exploit introduce? (5) Clear violation of regulation/law

Slide 62

Slide 62 text

8. How much personally identifiable information (e.g. customer emails/ passwords/credit cards) would be exposed? (9) All of it.

Slide 63

Slide 63 text

Total impact score: (9+7+9+7+7+7+5+9)/8 7.5

Slide 64

Slide 64 text

Likelyhood Likelyhood Likelyhood 0 to <3 3 to <6 6+ Impact 0 to < 3 Advisory Low Medium Impact 3 to <6 Low Medium High Impact 6+ Medium High Critical

Slide 65

Slide 65 text

Likelyhood: 5.625 Likelyhood: 5.625 Likelyhood: 5.625 0 to <3 3 to <6 6+ Impact: 7.5 0 to < 3 Advisory Low Medium Impact: 7.5 3 to <6 Low Medium High Impact: 7.5 6+ Medium High Critical