When I worked as a security researcher in the Israeli military, I focused on studying cybersecurity attacks–so I feel I have a unique perspective on how to best defend against them. Now, working at a venture-capital firm, I encounter many technology companies whose developers/employees are not always hyper-focused on building security into their products from the get-go – and sometimes blindly ignore common security flaws.
To me, this is a no-brainer. Building software or hardware products with security in mind is not often a life-or-death situation, as it can be in the military. But a major security breach can kill a company’s reputation and torpedo sales.
With that in mind, here are some guidelines for how fast-moving startups can build products that are secure, or at least more secure, from day one.
It all begins and ends with user input
There is a common theme we encounter when talking with development teams: over-trust of users. There is a naïve, dated mind-set of, “why would the user even try to do that?”—as in, do something that could cause a security problem for the product.
But this happens, and it happens a lot. A good guiding principle here is that you should never trust user input when building technology on a particular feature; always validate yourself that what the application is supposed to get as input is in fact what it’s receiving from users.
Focus your attention on vulnerable areas
What are the most vulnerable areas in product development? Here are a few:
- File I/O
- SQL & database interaction
- Objects serialization & deserialization
- Operating system interactions
- User-input display
Each one of the above allows a potential attacker a particular leverage over the application. For example, passing an unsanitized, serialized object to the application may result in anything from information disclosure to a full-blown remote code execution.
An easy way to avoid pitfalls, would be to use a framework to deal with these vulnerable areas. A framework is essentially a standardized boilerplate and wireframe on which you can construct your application. Why re-invent the wheel? The most common security gaps have already been plugged, likely before your developers even wrote a single line of code. When it comes to file I/O, SQL/DB/OS interaction – most frameworks have you covered from the get-go.
Conduct a “pen-test”
Conducting a penetration test, or pen-test, may seem costly for an early- or even growth-stage company, but a data breach or defacement of a digital property (e.g. website) will cost you more. It seems we’re no longer in the era of ‘if’ your company will be targeted but rather ‘when’ your company will be targeted. A pen-test will allow you to quickly discover specific vulnerabilities in your web applications and network infrastructure; it can be conducted by anyone from a single free-lancer all the way to a large company offering pen-tests as a service.
For this reason, ensure that whoever is handling your test has applicable credentials and ask for references from prior clients. Finding a competent service provider may be tricky – but you can usually get recommendations on who to use (and more importantly who not to use) by asking your digital-neighbor.
Prices can range from a few thousand U.S. dollars to tens of thousands, depending on the size of your application and provider.
Don’t skimp on security expenses
There seems to be a ‘check the box’ mentality around security that may stem from the push to manage expenses. Skimping on security tools can mean purchasing an inadequate solution in the best case and more-harmful-than-secure in the worst case.
Conduct market research, read expert interviews, and try to get in touch with security researchers related to your vertical of operation – don’t just go for the first out-of-the-box solution.
Seeking an adequate security solution to your application would require wading through a variety of mediocre products until you find the one that’s well suited for your use-case.
Don’t relax security to accelerate product launch
It’s crunch time, and your company is trying to hit a launch window: The most common mistake we see here is security going out the window. The pressure put on developers to deliver a working product means that they’ll likely cut corners delivering a potentially unripe product full of security holes.
Shockingly, if the product works (and isn’t too buggy) the likelihood of it being revisited for a security audit is extremely low (the manifestation of a ‘if it ain’t broke don’t fix it’ mentality). However, said security audit will 100% occur immediately after a breach is detected – but of course by then it is too late.
Don’t underestimate the damage that can be done
The truth of the matter is that no matter how hard you work, you can still get hacked. Even if your development team assures you that they’ve done everything they can to protect your application, challenge them to go a step further. Play the ‘what-if’ game to truly believe that you’ve done everything you can to protect your company.
There are products available that enable a ‘the-day-after’ mentality – offering specific remedies in the case that your company already has been hacked. These products help manage and contain the hack and can potentially trick the hacker, allowing for real-time threat detection while maintaining the safety of your assets.
For example, honey pots can detect an active hacker in your network and allow you to take pre-emptive steps to contain and eliminate him, while fooling the hacker into thinking that everything is still a-okay.
While honey pots are a great treat, detecting anomalous network communication (i.e. your toaster sending emails to an unknown, off-shore server) will allow you to instantly recognize that something is off – and give your team a lead on where the problem may reside. Such service is provided by many intrusion-detection systems – again, pick the one best suited for you.
Security is key
Despite continuing headlines about new and more-sophisticated breaches, many development teams lag behind best practices in terms of security. Simply realizing the depth and breadth of the security world while implementing a culture of humility within your development team– allowing developers to admit that maybe they should freshen up on basic secure coding habits– will contribute to a safer experience for both management as well as users.
Battery Ventures provides investment advisory services solely to privately offered funds. Battery Ventures neither solicits nor makes its services available to the public or other advisory clients. For more information about Battery Ventures’ potential financing capabilities for prospective portfolio companies, please refer to our website.