$30 off During Our Annual Pro Sale. View Details »

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. Be Agile, Not Vulnerable:
    Security Engineering in an agile world
    Jacob Kaplan-Moss
    [email protected]

    View Slide

  2. Every day, Heroku deploys
    100 times

    View Slide

  3. about:me

    View Slide

  4. Co-BDFL
    about:me

    View Slide

  5. Director of Security
    Co-BDFL
    about:me

    View Slide

  6. Security is a process,
    not a product.

    View Slide

  7. Heroku’s security team:
    @jacobian @tmaher

    View Slide

  8. Security is
    everyone’s
    responsibility.

    View Slide

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

    View Slide

  10. A thought experiment...

    View Slide

  11. 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?

    View Slide

  12. 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?

    View Slide

  13. 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?

    View Slide

  14. Did you just create a vulnerability?

    View Slide

  15. 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/

    View Slide

  16. “LOL Rails suxxors amirite!?”

    View Slide

  17. STFU.

    View Slide

  18. Real-world security issues
    are multifaceted.

    View Slide

  19. “Secure by default” matters.

    View Slide

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

    View Slide

  21. “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

    View Slide

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

    View Slide

  23. View Slide

  24. How severe are these issues?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  28. Terminology
    Advisory
    Low
    Medium
    High
    Critical

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  34. Assessment

    View Slide

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

    View Slide

  36. Risk = Likelihood × Impact

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  41. Likelihood: threat agent

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  46. Likelihood: ease of discovery
    and exploit

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  52. Impact: confidentiality and
    integrity

    View Slide

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

    View Slide

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

    View Slide

  55. Impact: availability and
    accountability

    View Slide

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

    View Slide

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

    View Slide

  58. Impact: business factors

    View Slide

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

    View Slide

  60. 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"

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  67. Be safe out there!
    Jacob Kaplan-Moss
    [email protected]

    View Slide