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

Minimum Viable Security - Wharton Web Conference 2015

Minimum Viable Security - Wharton Web Conference 2015

In this age of "minimum viable products" and "lean startups", is there room for security? Large, established companies often come with large, established security programs... but most of us don't work for one of those large companies. If you're at a startup or small business unit, chances are you're lucky if there's a single dedicated security engineer, let alone a whole group or program. So how do we bridge that gap? Well, good news: it's easy to whip your organization into shape! This talk covers five simple steps to create a security program. This "minimum viable security program" starts small, but can be iterated on, grown, and improved along with your product and business.

Jacob Kaplan-Moss

July 16, 2015
Tweet

More Decks by Jacob Kaplan-Moss

Other Decks in Technology

Transcript

  1. [email protected]
    SECURITY
    minimum viable

    View Slide

  2. Director of Security
    Core developer
    about:me

    View Slide

  3. Who is this talk for?

    View Slide

  4. Table of Contents

    View Slide

  5. 1. Train your staff
    2. Develop an SDL
    3. Plan for incident response
    4. Governance, Risk, and Compliance
    5. Brag about it!
    Photo by Mike Rohde - http://flic.kr/p/eufzY

    View Slide

  6. TRAIN
    your staff
    Day 1:

    View Slide

  7. Security is a

    shared responsibility

    View Slide

  8. Basic security awareness training
    • Passwords
    Buy your staff a password manager (LastPass, 1Password),
    and train them in its use and in good password hygiene
    • Multifactor auth
    Require it it everywhere possible, and train staff to use it.
    Recommendations: Authy, Duo Security, Yubikeys
    • Privacy
    “Keep customer data in production”

    View Slide

  9. Phishing

    View Slide

  10. “Phishing [is] a favorite tactic of state-
    sponsored threat actors and criminal
    organizations… for two years
    running, more than two-thirds of
    incidents that comprise the Cyber-
    Espionage pattern have featured
    phishing.”
    — 2015 Data Breach Investigations Report

    View Slide

  11. “23% of recipients [open] phishing
    messages and 11% [click] on
    attachments.…
    “A campaign of just 10 e-mails yields a
    greater than 90% chance that at least one
    person will become the criminal’s prey.”
    — 2015 Data Breach Investigations Report

    View Slide

  12. How can we combat phishing?
    • Better email filtering
    Google is really good at this — use them
    • Be prepared to detect and respond
    Enable Vault; encourage staff to forward suspicious emails
    • Investing in training
    phishme.com; you can run your own campaigns fairly easily

    View Slide

  13. Writing secure code

    View Slide

  14. Who’s responsible for
    writing secure code?

    View Slide

  15. Who’s responsible for
    writing secure code?
    Who’s responsible for
    writing tests?

    View Slide

  16. “Push decisions around
    security as far down 

    as possible.”
    — Parisa Tabriz [paraphrased]

    View Slide

  17. Good news: 

    writing secure code is easy!

    View Slide

  18. Writing secure code
    • OWASP Top 10
    https://www.owasp.org/index.php/Top_10_2013-Top_10
    • Mozilla’s Secure Coding Guidelines
    https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines
    • Microsoft’s “Writing Secure Code”
    http://msdn.microsoft.com/en-us/security/aa570401.aspx
    • Apple’s Introduction to Secure Coding
    https://developer.apple.com/library/mac/documentation/security/
    Conceptual/SecureCodingGuide/Introduction.html

    View Slide

  19. BONUS
    POINTS

    View Slide

  20. BONUS
    POINTS
    Your own secure coding guides
    1. The Big Three: SQLi, XSS, and CSRF
    Your web framework should be handling these for you!
    2. “Preventing the OWASP Top 10 at YourCo”
    3. Authentication and session guidelines
    4. Cryptography handbook

    View Slide

  21. Day 1: Training
    • Basic security awareness
    Passwords, multi-factor auth, phishing
    • Secure coding guides
    Several good public guides
    • Bonus: write your own secure coding guides
    The Big Three: XSS, CSRF, SQLi
    “Preventing the OWASP Top 10 at YourCo”

    View Slide

  22. SDL
    Day 2:
    (secure development lifecycle)
    develop an

    View Slide

  23. Now we know how to write
    secure code; how do we ensure
    these practices get followed?

    View Slide

  24. knowledge
    best practices
    development
    retrospective The

    View Slide

  25. Minimum viable SDL
    1. When do we do security?
    2. Who needs to do security?
    3. What is “doing security”?

    View Slide

  26. When do we do security?
    • Throughout development, as much as possible
    Set up an internal security mailing list and/or chat channel,
    even if you don’t have dedicated security staff.
    • Before development starts (security architecture),
    and before you ship (security review)
    This is much harder without dedicated security staff.
    • Agile makes this much more complicated…

    View Slide

  27. Who needs to do security?
    • Everyone!
    “Push decisions around security as far down as possible”
    Give engineers the tools and training to make good
    decisions… and trust them to do so
    • Dedicated security staff should serve as consultants
    Consult on architecture; answer questions; provide expert
    review in high-risk situations
    • Decide how “far up” to push security based on risk

    View Slide

  28. View Slide

  29. What is “doing security”?

    View Slide

  30. ❤☑

    View Slide

  31. View Slide

  32. “[A] critical care specialist at Johns
    Hopkins Hospital named Peter
    Pronovost decided to give a doctor
    checklist a try. … He designed it to
    tackle just one of their hundreds of
    potential tasks:… central line
    infections.
    “For a year afterward, Pronovost and his colleagues
    monitored what happened. The results were so
    dramatic that they weren’t sure whether to believe
    them: the ten-day line-infection rate went from 11
    percent to zero.”

    View Slide

  33. “[There are] three different kinds
    of problems in the world: the
    simple, the complicated, and
    the complex. Simple problems…
    are ones like baking a cake from a
    mix.… Complicated problems are
    ones like sending a rocket to the
    moon. They can sometimes be
    broken down into a series of
    simple problems. But there is no
    straightforward recipe.…
    Complex problems are ones like
    raising a child.…
    “We are besieged by simple problems.”

    View Slide

  34. View Slide

  35. http://www.projectcheck.org/checklist-for-checklists.html
    A
    A C
    CH
    HE
    EC
    CK
    KL
    LI
    IS
    ST
    T F
    FO
    OR
    R C
    CH
    HE
    EC
    CK
    KL
    LI
    IS
    ST
    TS
    S
    D
    De
    ev
    ve
    el
    lo
    op
    pm
    me
    en
    nt
    t
    ‰ Do you have clear, concise
    objectives for your checklist?
    Is each item:
    ‰ A critical safety step and in great
    danger of being missed?
    ‰ Not adequately checked by other
    mechanisms?
    ‰ Actionable, with a specific
    response required for each item?
    ‰ Designed to be read aloud as a
    verbal check?
    ‰ One that can be affected by the
    use of a checklist?
    Have you considered:
    ‰ Adding items that will improve
    communication among team
    members?
    ‰ Involving all members of the team
    in the checklist creation process?
    D
    Dr
    ra
    af
    ft
    ti
    in
    ng
    g
    Does the Checklist:
    ‰ Utilize natural breaks in workflow
    (pause points)?
    ‰ Use simple sentence structure and
    basic language?
    ‰ Have a title that reflects its
    objectives?
    ‰ Have a simple, uncluttered, and
    logical format?
    ‰ Fit on one page?
    ‰ Minimize the use of color?
    Is the font:
    ‰ Sans serif?
    ‰ Upper and lower case text?
    ‰ Large enough to be read easily?
    ‰ Dark on a light background?
    ‰ Are there fewer than 10 items per
    pause point?
    ‰ Is the date of creation (or revision)
    clearly marked?
    V
    Va
    al
    li
    id
    da
    at
    ti
    io
    on
    n
    Have you:
    ‰ Trialed the checklist with front line
    users (either in a real or simulated
    situation)?
    ‰ Modified the checklist in response
    to repeated trials?
    Does the checklist:
    ‰ Fit the flow of work?
    ‰ Detect errors at a time when they
    can still be corrected?
    ‰ Can the checklist be completed in
    a reasonably brief period of time?
    ‰ Have you made plans for future
    review and revision of the
    checklist?

    View Slide

  36. Day 2: SDL
    • Create a virtuous cycle
    • Minimum Viable SDL:
    When do we do security?
    Who needs to do security?
    What is “doing security”?
    • Checklists are an amazingly powerful tool
    knowledge
    best practices
    development
    retrospective

    View Slide

  37. INCIDENT
    RESPONSE
    plan for
    Day 3:

    View Slide

  38. “But I would not feel so all alone

    Everybody must get owned”
    — Bob Dylan*
    *more or less

    View Slide

  39. Data breaches are fast becoming just a
    “fact of life.” Companies, thus, are
    judged as much for their response as
    for the breach itself.
    Bruce Schneier [paraphrased] — 2015 Year-End Review:
    http://info.resilientsystems.com/bruce-schneier-jon-oltsik-year-end-review-predictions-resilient-systems

    View Slide

  40. You can’t effectively plan
    your emergency response
    during the emergency!

    View Slide

  41. Minimum viable IR plan
    1. Initiate
    Where should a (potential) incident be reported?
    How will incidents be tracked?
    What are the roles and responsibilities during an incident?
    2. Communicate
    Where will comms happen? Who will be involved?
    Who will send situation updates? To whom? How often?

    View Slide

  42. Minimum viable IR plan
    3. Assess
    Where do we collect information? Who follows up?
    How do we determine severity?
    4. Remediate
    Given that severity, what is our response SLA?
    How do we prioritize remediation (short vs long-term)?
    How do we communicate and track remediation?
    When and how do we notify customers?

    View Slide

  43. Minimum viable IR plan
    5. Retrospective
    How do we explore causes? Five Whys? Infinite Hows?
    How will we piece together a timeline for the retro?
    What metrics do we need to collect?
    How will we track long-term follow-up?

    View Slide

  44. More reading
    • Incident Response at Heroku
    https://blog.heroku.com/archives/2014/5/9/incident-response-at-heroku
    • The Incident Command System
    https://en.wikipedia.org/wiki/Incident_Command_System
    • Security Breach 101
    https://medium.com/@magoo/security-breach-101-b0f7897c027c

    View Slide

  45. BONUS
    POINTS

    View Slide

  46. BONUS
    POINTS
    Run a tabletop exercise

    View Slide

  47. Day 3: Incident Response
    • Bad things do happen to good people
    Better to be prepared than to be in denial
    • Create an incident response plan
    Initiate, Communicate, Assess, Remediate, Retrospective
    • Bonus: run a tabletop exercise

    View Slide

  48. Governance,
    Day 4:
    Risk,
    & Compliance

    View Slide

  49. ISO 27001
    SIG
    SOC II
    NIST 800
    FedRAMP
    FIPS
    FISMA
    HIPAA
    PCI-DSS SOX
    HITECH

    View Slide

  50. ISO 27001
    SIG
    SOC II
    NIST 800
    FedRAMP
    FIPS
    FISMA
    HIPAA
    PCI-DSS SOX
    HITECH
    NOPE

    View Slide

  51. Formal risk programs
    • Aren’t worth the investment at small scale
    Startups are more concerned about traction than
    compliance — and this is fine.
    • However, at scale they become increasingly vital
    • Don’t shoot yourself in the foot
    You can save a world of effort in the future by laying the
    groundwork now.

    View Slide

  52. GRC 101
    • Document everything
    Make a decision about security, privacy, or company policy?
    Write it down.
    Don’t worry about formal language: it’s not necessary.
    • Track as much as you can
    Good: “Hi Mary, this email is to confirm that I’ve given you
    commit access github.com/myorg/myrepo”
    Better: build systems to track security work, access, etc.

    View Slide

  53. View Slide

  54. Your most important documents
    • Data classification guide and policy
    What data you have, where it’s stored, who has access to it
    • Access control checklists
    Access control is tremendously important, and you’ll spend ages
    cleaning it up later if you don’t get it right now.
    Bonus: you can use these for on- and off-boarding.
    • Exception process
    There’s an exception to every rule (except this one). So document
    how they work, and document when you grant them.

    View Slide

  55. BONUS
    POINTS

    View Slide

  56. BONUS
    POINTS
    Formal risk programs
    • Safe Harbor
    Is fairly easy, simple (mostly privacy-related), and lets you sell services to Europe.
    • PCI-DSS 3.0 SAQ-A-EP
    https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.pdf
    Fairly complex (~100 controls), but well-written, actionable, and a good starting
    point. Many companies use PCI as a proxy for “has their shit together”
    • Consensus Assessments Initiative Questionnaire
    https://cloudsecurityalliance.org/group/consensus-assessments/
    Consolidates most-commonly-asked questions into a single 

    questionnaire, focused on *aaS. Comprehensive 

    (~300 controls), maps to PCI, HIPAA, FedRAMP, etc.

    View Slide

  57. Governance, Risk, and Compliance
    • Document everything
    • Write a few basic policies:
    Data classification, access control, exception process
    • Bonuses: Safe Harbor, PCI, CAIQ

    View Slide

  58. BRAG
    Day 5:
    about it

    View Slide

  59. Congratulations:
    you’re now better off than
    90%* of your peers!
    * completely made-up statistic

    View Slide

  60. Tell the world
    • Privacy policy
    yoursite.com/privacy
    • Security information page
    yoursite.com/security
    • Security FAQ/knowledgebase
    May be public or private, depending (more later)

    View Slide

  61. Privacy policy
    • Boilerplate, but necessary — don’t skip it
    Many companies won’t do business with you without one.
    • If you have lawyers, ask them to write it.
    • If not, there are several OK templates to start from:
    http://automattic.com/privacy/ (CC-By-SA)
    https://wordpress.org/about/privacy/ (CC-By-SA)

    View Slide

  62. Security information page
    • Summarize your security practices and policies
    This can (and should) be less formal; it’s where you can tell
    your security “story”
    • If you have any formal attestations, list them here.
    • Explain how to report vulnerabilities
    [email protected] should be a thing
    Having a PGP key helps pass the “brown M&M test”

    View Slide

  63. Security FAQ/KB
    • Every time a customer asks you a question about
    security, write down the answer.
    Over time, natural groupings will occur. Or, you could use
    the PCI or CAIQ topics as your groupings.
    • Should you publish this publicly?
    Transparency is good, but there are also good reasons to
    limit this to “available on request” or “only with an NDA”
    My litmus test: does publishing it make customers safer?
    Then it should be public. If not, keep it private.

    View Slide

  64. Day 5: Brag about it
    • yoursite.com/privacy
    Boilerplate, but necessary
    • yoursite.com/security
    Tell your story, and how to report vulnerabilities
    • Security FAQ
    DRY for customer customers

    View Slide

  65. 1. Train your staff
    2. Develop an SDL
    3. Plan for incident response
    4. Governance, Risk, and Compliance
    5. Brag about it!
    Photo by Mike Rohde - http://flic.kr/p/eufzY

    View Slide

  66. Congratulations!

    View Slide

  67. [email protected]
    SECURITY
    minimum viable

    View Slide