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

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

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

Given at DjangoCon US 2013.

Jacob Kaplan-Moss

September 04, 2013
Tweet

More Decks by Jacob Kaplan-Moss

Other Decks in Technology

Transcript

  1. 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
  2. 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?
  3. 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?
  4. 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?
  5. You can’t prove that software is secure. You can only

    fail to prove that it’s insecure.
  6. “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
  7. If an issue of this magnitude was discovered in your

    stack, would you be prepared to respond?
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. High Carry a substantial risk to your customers, finances, reputation

    or otherwise. Expect High-level vulnerabilities to interrupt several developers, perhaps from multiple teams.
  13. 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.
  14. 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
  15. 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.
  16. 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.
  17. 3. What resources and/or opportunities are required for this attacker

    to find and exploit the vulnerability? (9) No access or resources required
  18. 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.
  19. 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.
  20. 8. How likely is it that we'd detect an exploit

    (or attempt)? (6) Logged and and reviewed eventually
  21. 1. How much private data would be disclosed, and how

    sensitive would that data be? (9) Complete data disclosure
  22. 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.
  23. 3. How much downtime would an exploit cause, and how

    vital would that downtime be? (9) Complete outage
  24. 4. How easy would it be to trace an exploit

    back to the attacker? (7) Partially traceable
  25. 5. How much financial damage would we suffer as a

    result of an exploit? (7) Significant and noticeable effect on annual profit
  26. 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"
  27. 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
  28. 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
  29. 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.