Security Do’s and Don’ts for Early-Stage Companies
If you’re developing for the web, you have no choice but to build security into your product, process, and company from day one. But getting application security right is tough: you have complex, ever-changing technologies, confusing and contradictory advice, and a risk of massive development costs, all with no guarantee that you’re Doing It Right.
A lot of startups ask me what steps they should take to make themselves “secure”. Here’s my most common advice for pre-Series A companies: five recommendations on what to do, and one big “don’t”.
Do: Understand your Data
First, take stock. Make a list of all the secrets your business possesses – your own secret IP, and the secrets that your customers, partners, and vendors entrust you with. Your own secrets might include your code, your customer lists, any proprietary, business processes, and the tokens, keys, and passwords you use to interact with other apps.
Above all, if you are building a valuable application, your customers have probably given you some data that is very valuable to them, or to their businesses. They expect you to maintain the durability and secrecy of that information, and a breach of that trust can be a fatal event for an early-stage company.
Now imagine what would happen if a hacker stole each thing in the list. How expensive would it be to fix? Put everything in to one of three categories:
- Low value data
- If a hacker stole it, you could fix the problem with a day’s work and minimal customer impact.
- Medium value data
- You would worry if this were stolen and you’d have a lot of work to do. You might be embarrassed or lose customers, but your business would likely survive.
- High value data
- If this data were stolen, you would be forced to shut down the company, and potentially face legal repercussions.
You should spend the vast majority of your time thinking about how you protect that high-value data. The rest of it isn’t worth worrying about yet – you probably have bigger problems, like growing your company and not running out of money. Frankly, a lot more startups are killed by bad products or lack of customers than hackers.
Do: Let someone else do it
You are not a special or unique snowflake, so stick with what works: established, mainstream open-source frameworks and libraries. Prefer major cloud vendors for your infrastructure, and understand how your cloud provider approaches security. I’ve found that it’s generally easier to build secure (and scalable) systems by starting with a PaaS than a hosting provider, as they tend to enforce best practices with technology, whereas IaaS or hosting providers give you too much latitude to screw things up.
A great example is sign-in. Don’t build your own sign-in system – it takes a long time, and it’s easy to get wrong. Ideally, you should delegate sign-in to a third party in the early stages. Depending on your user audience, offer sign in with (one of) Facebook, Twitter, GitHub, Google Apps, or Microsoft. It’s really easy to implement, and they take care of all the boring stuff like password resets, weak passwords, automated take-overs, suspicious IPs, two-factor authentication, and on and on. If you insist on having your own user database, use your framework’s preferred sign-in system, and customize it as little as possible.
» Further Reading: Sign-in libraries for popular frameworks
Do: Use TLS everywhere, always
Your site should run completely over HTTPS (TLS) – even the signed-out landing and marketing pages. All of the data that you deliver to your customers should be encrypted in transit, because it’s trivial for an attacker to steal unencrypted data in the era of ubiquitous public WiFi. Configuring TLS correctly can be complicated – don’t do that. Instead, let your platform vendor take care of terminating TLS connections for you.
» Further reading: SSL support from major cloud vendors
You should buy a wildcard certificate for your domain (i.e. a certificate for *.example.com, not example.com or www.example.com). At first, you’ll use this one certificate for everything – not just your main web app, but any auxiliary sites, API endpoints, your staging environment, and your administrative tools and dashboards. Resist the temptation to use self-signed certs for anything, even if it’s “just internal”.
TLS isn’t just for the front end – use secure connections from your web app to your database. If you use third-party vendors to provide any of these services, insist that they offer a secure connection. Any make sure that passwords used to connect to databases and caches are strong and unique, and different between development, staging, and production.
» Further Reading: how to use TLS for database connections
- CouchDB
- MySQL
- MongoDB
- PostgreSQL
Do: Separate secrets from code
Any modern web application is going to talk to lots of other services, and it’s going to need passwords or secrets for those services: a password for your database, an API key to talk to a payments processor, a set of OAuth client secrets for a service you integrate with, and on and on. I just checked our app – we maintain a list of 29 (!) secrets used for different service connections. Never check in these API keys, passwords, or certificates! Instead, think of them as configuration parameters, to be applied to your code at deploy time. Heroku has done an excellent job explaining this technique as part of their “Twelve-Factor App” manifesto – basically, configuration should be passed to the app as a set of environmental variables.
» Further Reading: how to store PaaS configuration in the environment
Once you’ve scrubbed your code of secrets, you have much less to fear if that code is accidentally disclosed or stolen. You can also more easily share code with contractors and partners. And you are much less likely to accidentally touch a production system from your staging or development environments. You should make sure your development team knows this policy, and enforce it in code reviews and pull requests.
D0: Educate your employees
When thinking about security, it’s really easy to get hung up on technical details and fixes. But in many ways, your largest risk is the set of people who have access to your secrets. Your employees are unlikely to steal your data, but you do need to worry that they will accidentally lose data or be spearphished by a determined attacker.
To mitigate this risk, you should develop onboarding and offboarding checklists for employees and contractors. When you hire someone, what systems are they given access to? Which secrets are shared with them (PINs, passwords, etc.)? When you terminate them, are all of their accounts removed? Is corporate data removed from their devices? And are shared passwords the employee knew changed?
Make education part of the onboarding process, especially for less-technical employees. Explain the virtues of using strong and unique passwords, and teach your team how to use a password manager if necessary (disclaimer / shameless plug: my company makes a password manager and onboarding tool for companies). Make sure they are using screen locks on any phones, laptops, or tablets that they are going to use at work, and make sure employee laptops are patched and firewalled. For highly-sensitive accounts, especially email, teach your employees how to use two-factor authentication, and require it if possible.
Finally, try to limit access to the “crown jewels” of your secret data. Most early stage companies have very flat hierarchies, and in general that’s a good thing – it’s easy and efficient to give everyone access to everything. But there should be a few secrets (bank account passwords, SSL private keys, etc) that are shared only among a core group of executives and key employees or operators. Anyone who gets to enter that “circle of trust” should be savvy enough not to get phished.
Don’t: Bother with crypto
A lot of people I talk to tend to think that in order to secure your data, you need to store it in an encrypted form. This is a bad idea for early-stage companies. If security isn’t part of your company’s core value proposition, then you should probably stay away from crypto at first. Crypto is hard to do, and harder to do correctly. Frankly, you’re likely to get it wrong, and even if you get it right you’re probably not making things harder for attacker: for naïve implementations, if an attacker can steal your encrypted database, they can also steal your keys. Save encryption for when you can hire security professionals to build and operate a working system for you.
Going beyond the early stage
Most of this advice can be boiled down to “be smart, but don’t try too hard”. You should stick with best practices and off-the-shelf solutions almost all the time when you’re just getting started. However, the key thing is to understand what systems and data you have, so that when it’s time to grow up and get more sophisticated you’ll know where to start. Eventually you’ll have a dedicated IT and security staff in house to assess and mitigate risks – while you’re in the “in between” phase (from late seed to Series A) you can engage contractors, penetration testers, and other vendors to help you grow up without compromising your users’ data. Share your tips, dos, and don’ts in the comments or tweet @bradleybuda – how does your company protect its assets with minimal stress and expense?
Feature image via Flickr Creative Commons
Bradley Buda (@bradleybuda) is the CTO at Meldium, an account & password manager for teams, which specializes in storing sensitive data securely for thousands of businesses.