To build a product, founders juggle security issues ranging from data protection to structuring access on an engineering team to what cloud services to trust. Somewhere between the extremes, there’s a sweet spot of both security and convenience – and Founders Network entrepreneurs have been sharing their best practices.
On the forum and in person FNers been discussing security through the stages of growth, from bootstrap to series A and beyond. Ensuring your IP is protected is only part of the conversation – protecting consumer data and mastering the regulatory requirements of your domain also shape product and team decisions from a startup’s early days.
“You have to think of security as part of your overall architecture design. Code debt is one thing – security debt can be company-ending,” says Awesense founder Mischa Steiner (April ’15). “Ultimately, your customers need to trust you and you need to remain credible. If you do not have a good security design, procedures, and policy in place then hire someone to guide you.”
Steiner works in a super-sensitive area – energy, public utilities and power grids – so he’s used to being vetted by potential customers with a long list of data privacy and security questions. Especially for enterprise startups, security savvy is an essential first way to prove their bona fides.
“Look at Box versus Dropbox – which one is winning more sales to enterprise clients? The one that focused on security at the beginning, which slowed them out of the gates, but now they’re winning with a better product for enterprises.”
Be ready to tell a prospective client or investor:
- What governance is in place?
- What are the Independent Privacy Protection audits that have been done, if any?
- What are your audit schedules?
- How often are there log reviews? What logging is in place?
- What automated flagging is there? What is the procedure in the event of a flag? Or in the event of a systems compromise?
“Any employee that touches customer data, essentially everyone on the back-end, data science, and some of the front-end, must submit to a background check by a third-party provider,” Steiner says. “We use Garda, but there are others than can be used.”
Internal threats: how do you balance team efficiency and security?
As Devang Patel (Nov. ‘12) points out, there are two fronts to worry about – securing your code from unknowns, and securing it from your own partners and contractors. Early stage founders often have to worry more about the second case. Errors of access – on the most basic level, for instance, controlling who can commit to production – can creep in as a young startup builds not just an engineering team but also figures out how to respond quickly to troubleshooting incidents for early customers.
Gunnar Counselman (June ’15) worked in human intelligence in the United States Marine Corps before moving into the private sector and reimagining CRM for the world of learning and education with his startup, Fidelis. As he works with school systems, confidentiality and data security aren’t just a priority for customers – they’re legislated under the Family Educational Rights and Privacy Act (FERPA), the educational equivalent of the U.S. healthcare system’s HIPAA requirements.
Fidelis has grown into a funded company with high-profile customers spread across the world. Their ability to maintain a SaaS product that runs without hitches across every time zone has required a product team able to balance responsiveness with carefully restricted access, and clearly defined protocols for who is on-call 24 hours a day and how they can initiate mission-critical fixes responsibly.
“A lot of our customers are asking for security reports and security reviews – they want to make sure all the data they are passing to us is secure and FERPA compliant,” says Rakesh Veetil, Fidelis’ head of product.
“One of the things they always question is, if you guys are so small, what do you do to make sure you have everything in place?”
The answer includes some common sense efficiencies – as their user base grows but Fidelis continues to operate with a relatively small team, they’ve learned to make the most of the monitoring and alerts that come with using Amazon Web Services for their infrastructure. But they’ve also invested explicitly in this area, hiring a security engineer as one of their primary DevOps.
As an engineering team scales, it requires more structured escalation procedures on who to call, when. At Fidelis, they use a timeline of who did what to map out what worked and what could be speeded up in their incident responses. In the name of security, even most their key engineers don’t have access to everything. A few managers directly work on production, but most of their team sticks to staging and development. But to meet ambitious service level agreements with customers who want zero downtime, Fidelis is having to smooth out a protocol that can quickly (and securely) adjust access at any time of day. That requires planning ahead and making sure everyone knows the response process – including restricting most troubleshooting to a development environment. Bug-tracking tools like Jira also allow startups like Fidelis to look back and track who had access to what if they want to do a postmortem on a specific incident response.
External threats: how do you store sensitive information, from customer data to source code?
You can’t assume that everyone on your engineering team will have a native appreciation for what information is sensitive and why, so education about data handling procedures has to be part of a team’s culture.
“Our customers always ask two things: is the data encrypted at rest – when it is sitting in your database – and how is it encrypted when the application is using it, including when it is in transit and the application is decrypting and showing it to the user,” Veetil says. “You have to make sure it is encrypted, and you try to build in multiple layers of encryption and ways to block somebody from getting in, but if somebody DOES get in, you also shouldn’t have data in a table they can read off or query off.”
Fidelis, Gunner Counselman’s education startup, runs routine penetration tests carried out by an outside party to check for vulnerabilities they’ve missed internally. They commission an external source to try to break their system and receive detailed reports of what they could tighten, anything from the “immediate action” items to the “nice to haves” to add to a roadmap.
Resources to vet
Repo storage services like GitHub allow an early-stage startup to swiftly work with remote developers, but that requires a level of trust – and early vetting – as well as evaluating the risks specific to your own sector. Not every startup is going to be developing a code base with IP so precious it lures high profile attacks. But every founder has to prove her chops by knowing the risks and benefits of the security environment they pick. Maybe you store core source code on an internal server and use GitHub repos exclusively for projects with contract developers. In the big picture, the security of your source code itself may be less of a differentiation for your startup than your deftness in protecting a customer’s data and delivering competitive SLAs – not that it’s an either/or choice.
“If a foreign nation-state breaches the vendor and takes your code – is that catastrophic, or is it irrelevant?” asks John Poffenbarger (May ’15), who founded Definitive Data Security. He’s not sold on using third-party hosting for your IP – entrusting it to somebody else’s competence. But those who choose to self-host are trusting their own competence, which is not likely to match the security experts employed by major services. You have the protection of relative obscurity when you go it alone, but your source code is only as secure as the sysadmin who is managing your server.
“One thing is absolute: If you roll out your own, do not wing it – getting it wrong can be, and often is, catastrophic,” Poffenbarger says. “This is usually the reason some will opt to go with a public service – and sometimes, it’s the right choice. Though maintenance is not that difficult, you absolutely must pay attention to it.”
Just as with self-hosting there are potential risks to big hosted services, and thinking those through is a prerequisite to making your pick, says Jonathan Tang (Oct. ’15), who has been building his own startups after working on Google search.
“It’s not so much that *Git* is insecure as that whenever you host a piece of your infrastructure on some other company’s servers, your infrastructure is at most as secure as their security procedures,” he says. GitHub isn’t bad at security – but they ARE a big target, because of how many companies use them as a repo.
Tang has used a variety of services, ranging from Heroku to AWS, for his own companies and thinks that even technical founders will often find the big hosted services the best options for early stage work.
Other resources FNers have used to track and distribute data selectively while leaving their code base tightly secured include SumoLogic for log collection and monitoring, and services like New Relic and SendGrid for app monitoring and notification generation and delivery.
Want a deeper dive into the questions raised above? Founders Network members share peer-to-peer advice in a confidential forum where subject experts can debate how general security principles apply across specific sectors and stages. Learn more about our community of startup entrepreneurs at foundersnetwork.com.