Minimum Viable Security - Wharton Web Conference 2015

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