People sometimes ask - what would you do differently if you had to start another company all over again?
Without a doubt, I'd take a smarter approach to IT security in the early stages. So often we, as entrepreneurs, only focus on getting the product to work before we make it secure.
I’d do this differently because, to use a hackneyed saying of Mr. Ben Franklin: "An ounce of prevention is worth a pound of cure."
In this digital world, that saying may ring even truer. Preventing the theft of your data and your customers' data is much, much easier than trying to recover from an actual breach.
Why IT Security Interests Me
In the 90s most of the countercultural nerds were connected in one way or another to the security community.
One of my first projects was a search engine for security community called Nethernet. This project spurred the creation of one of my first companies, Netherweb, that Roland (another of our co-founders) and I founded in 1998 with strong roots in freedom of speech.
Working in this space exposed us to a lot of threats very early in the history of the web, since we were a big target, when most people weren’t even using SSH or shadowed password files.
It's funny (well, now it's funny; at the time it wasn't), but we learned a lot in the early days of running a hosting company: most importantly that people are creatures of habit, and bad habits are hard to change. This means, that if you set things up right in the beginning, and get people thinking about security early in the company by implementing simple policies like strong firewall rules, mandatory VPN, and Public/Private key access you'll be in a much better position than trying to create a culture shift down the line.
Accurately Assess Your Risk
In software, everything you build is at the expense of something else you could have built. You don't want to cut corners, but not everything needs Fort Knox level of security - how do you determine how much time you should be spending on security?
Entrepreneurs are great at taking risks, but most successful entrepreneurs take calculated risks. Ignoring security because you don’t understand it, or because you don’t think it’s important, is a bad idea. Ignoring security as a calculated risk is acceptable.
Let's consider an example of calculated risk: Cross-Site Request Forgery (CRSF), a vector where a user’s session can be tricked into submitting requests on that user’s behalf.
- If the CSRF-vulnerable endpoint is something relatively innocuous, then not fixing it immediately might be a valid decision. For instance, maybe your logout link is unprotected--submitting to that in a valid session in most instances is annoying, not dangerous.
- Perhaps the vulnerable endpoint can be used for something meatier, but in a way that isn’t inherently exploitable (at least, without the help of another): Causing a report to be generated and sent to the default email address on the account. Having the account owner generate and receive a few extra reports isn’t vulnerable by itself, but it could turn into a catastrophe if that address can be changed or if the owner gets charged for each report generated, for example. Not fixing this immediately is less warranted, but can still theoretically be justified in the face of a lack of resources if you’re reasonably sure it’s not exploitable.
- But perhaps the endpoint allows something much worse--say, submission of arbitrary scripts into a rendered page output owned by that user, or to a password change field, or to an action to initiate a payment transfer. Your CSRF vector has now suddenly become an enabler of much worse attacks.
These examples show that a vulnerability can encompass all levels of threat, even though the only real change to the vulnerability is context, not its fundamental nature. The same vulnerability thus could be anything from a minor annoyance to a critical threat, damaging to your customers' business and creating bad press (and potentially massive liability). The latter are things a business might never recover from, and the difference is solely in context.
We’ve seen all those variations (and others). We've seen startups have their AWS keys downloaded off of a public github repository. We’ve seen founders’ banking credentials phished. Usually those startups survive, but not without some significant damage control spent apologizing to their customers and otherwise ameliorating the damage.
Start Securing on Day 1
Michael Borohovski at Tinfoil Security said it best in an email exchange we had recently. He really drove home the idea that security is iterative and should happen as your company grows:
"Too many entrepreneurs, in the interest of building the product as quickly as possible, think that security is a "freeze all the code, do an assessment, and write all the policies" project they can do later. It isn't. Think about security from the very beginning. It's actually not that hard to anticipate what needs you'll have to deal with in the future."
It's true - there are so many examples of little things founders can do when starting out to prevent certain types of attacks:
- Laptops for your remote team - use two factor authentication wherever possible to protect yourself from stolen laptops;
- Storing customer data - use encryption like TLS for network traffic, and encrypt data on-disk as well;
- Site vulnerabilities - run a web application scanner (like Tinfoil) to find and fix vulnerabilities easily;
- Server vulnerabilities - use strong firewall rules to keep attackers from scanning your servers for known vulnerabilities, even if you're not actively using the software.
"Over time, you can integrate tools into your CI / DevOps workflow. All of these things are iterative, continuous and can always be improved. Starting earlier and improving slowly over time helps keep you from getting breached."
Or just connect to a magic security bucket. (kidding, that's not a real solution.)
At Olark we have since augmented our security by encrypting data on disk and implementing one of the first bug bounty programs for a SaaS company our size. We even eventually ended up with an employee dedicated to security - thanks Aaron!
The responsible disclosure program was one of the most beneficial things we’ve ever done for security. To date we've paid out $10,050 for about 75 bugs, and sent out 85-100 t-shirts. Out of those 75 bugs, two or three were serious vulnerabilities that could have really bitten us, and another 10 or so could probably have been used to leverage some other vulnerability to become something serious (even though they weren't serious in and of themselves). It was a lot of work, but created a sense of urgency for security issues, and created a culture around security reviews.
Trust is everything
Losing your customers’ trust due to lapses in security is a risk that could kill your business. Getting caught in a lawsuit due to damage caused to a customer's’ business could also kill your business.
If you're just starting out, take time now to assess your risks - or hire someone to assess risks for you - take steps to secure what you have now, and plan for how you'll secure what you accrue. The plans you put in place now will scale much easier than one, two, five or (hopefully) 10+ years later in your business’ life.
Good luck, and stay secure my friends.
NOTE: A version of this article originally appeared on Fast Company. It has since been updated with input from my co-founder, Zach; Aaron, our 'sometime security guy'; and Michael from Tinfoil. Huge thanks to these guys for their help.
.png)