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.

Transcript

1. jacob@jacobian.org SECURITY minimum viable
2. Director of Security Core developer about:me
3. Who is this talk for?
4. Table of Contents
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
6. TRAIN your staff Day 1:
7. Security is a
 shared responsibility
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”
9. Phishing
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
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
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
13. Writing secure code
14. Who’s responsible for writing secure code?
15. Who’s responsible for writing secure code? Who’s responsible for writing tests?
16. “Push decisions around security as far down 
 as possible.” — Parisa Tabriz [paraphrased]
17. Good news: 
 writing secure code is easy!
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
19. BONUS POINTS
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
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”
22. SDL Day 2: (secure development lifecycle) develop an
23. Now we know how to write secure code; how do we ensure these practices get followed?
24. knowledge best practices development retrospective The
25. Minimum viable SDL 1. When do we do security? 2. Who needs to do security? 3. What is “doing security”?
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…
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
29. What is “doing security”?
30. ❤☑
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.”
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.”
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?
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
37. INCIDENT RESPONSE plan for Day 3:
38. “But I would not feel so all alone
 Everybody must get owned” — Bob Dylan* *more or less
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
40. You can’t effectively plan your emergency response during the emergency!
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?
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?
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?
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
45. BONUS POINTS
46. BONUS POINTS Run a tabletop exercise
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
48. Governance, Day 4: Risk, & Compliance
49. ISO 27001 SIG SOC II NIST 800 FedRAMP FIPS FISMA HIPAA PCI-DSS SOX HITECH
50. ISO 27001 SIG SOC II NIST 800 FedRAMP FIPS FISMA HIPAA PCI-DSS SOX HITECH NOPE
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.
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.
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.
55. BONUS POINTS
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.
57. Governance, Risk, and Compliance • Document everything • Write a few basic policies: Data classification, access control, exception process • Bonuses: Safe Harbor, PCI, CAIQ
58. BRAG Day 5: about it
59. Congratulations: you’re now better off than 90%* of your peers! * completely made-up statistic
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)
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)
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 security@yoursite.com should be a thing Having a PGP key helps pass the “brown M&M test”
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.
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
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
66. Congratulations!
67. jacob@jacobian.org SECURITY minimum viable