Tuesday 3:40 p.m.–4:25 p.m.

Minimum Viable Security

Jacob Kaplan-Moss

Audience level:



In this age of "lean startups", where does security fit? At a startup, you're lucky if there's a single dedicated security engineer, let alone a whole program. Good news: it's easy to whip your organization into shape! We'll look at creating a "minimum viable" security program for a startup, one that can start quite small, but can be iterated and improved continually.


We'll look at creating a full security program for a startup-sized company, one that can start quite small, but can be iterated on continually, and grown to match the growth of your business. This talk uses the conceit of a five day program, to be completed in a one-week sprint, but the steps could easily be scaled down to just a few hours, spread out, or otherwise modified to fit your time and organization.

  • Day 1 - Training: for a security program to work, it needs to be everybody's responsibility, not just a select few. So your first step in creating a security program is to establish a minimum bar for secure coding techniques. Luckily, basic secure coding is easily explained and taught, and there are great free guides and resources that can form the backbone of a simple, easy training program. On Day 1, you'll pull together these guides and create a training manual.

  • Day 2 - Secure Development Lifecycle: now we know how to write good code, but how do we ensure that best practices are followed? As we learn lessons about our own product and its security posture, how do we make sure those learnings are captured, retained, and applied in the future? The answer to these questions lies in creating a Secure Development Lifecycle, which is just a fancy name for procedures and checklists that capture your best practices, and help remind you of them as you ship new features. On day 2, you'll write those checklists, adopt some lightweight process, and being tracking your product security.

  • Day 3 - Incident Response: sooner or later, something will go wrong. When it does, will you be able to respond? Trying to make up an incident response process when something's already on fire is an unpleasant experience, and you can avoid it with a little bit of preparation. On day 3, you'll develop a basic IR plan, run a table-top exercise to try it out, and be ready to respond if and when something goes bump in the night.

  • Day 4 - Governance, Risk, and Compliance: there's an alphabet soup of security standards: ISO, SOC, SIG, PCI, HIPAA, FIPS, FISMA, FedRAMP... oh my! At small scale, most of these are formal attestations probably aren't worth the investment. However, at larger scale these ways of formally proving security standards start to become increasingly important. Completely ignoring formal risk programs can get you into a bind if you decide to pursue them later. Thus, on day 4 you'll lay the groundwork for a formal GRC program, making sure you're ready to start down this path once your business grows to that point.

  • Day 5: Brag about it! At this point, you've got a security program far better than most startups (and better than many established businesses). This is great! Security is increasingly a concern even for non-technical customers, and now that you've got a good story to tell, you should tell it! On day 5, you'll lay out that security story, publicly, and make sure your customers know about all your hard work.