Wednesday, April 20, 2016

Holding Down Startup Security Costs

So you're part of a fancy new startup. You have fancy new equipment, and fancy new friends. There's a fancy office with other startups who also have varying degrees of fanciness. What is this new thing you have to be concerned with again? You know, that thing hovering over your head like a drone with low batteries about to swan dive through your cranium? Yes, it's the potential money pit known as security.

Capital is scarce in the startup environment, especially for security due to the emphasis being on getting a product to market. Lately, I've seen a larger push from early investors for their startups to keep more equity in the pool. This takes one of the juicier reasons for a good security person to work with you, for lower-than-normal pay, off of the table. Some of the savvier investors are even requiring *ahem* security reviews of the companies/products they bankroll. Perish the thought.

 Here are some suggestions that can help you balance your scant budget with your security needs.

#1 Put the cost of security up front

Try to have someone on retainer instead of a full hire. Do an initial session for a pre-negotiated rate where you lay out everything your product or business does. A good security veteran should be able to put together a notional outline of all the policies and procedures you will need to stay out of trouble. Barring that, they can probably point you to someone who can. Once you are comfortable with the information gathered via Googling or further consult, you have a couple of options. Either pay your existing contractor to flesh out the documentation and stand-up some basic infrastructure, or shop around for a better deal. Putting the policies and procedures for the security of your business/product up front allows your developers and early administrative hires to know what is expected of them. Speaking of developers knowing what is expected of them...

#2 Always separate testing from production.

Do not let your devs operate on the production systems. You don't need to spin up costly AWS instances to create a bastion on which to test. Use lower cost solutions where up-time isn't 5 9's or cobble together some refurbished workstations to get the job done. If you have to cram all of your creative needs into one small group of betrodden individuals, make sure their eventual screw-ups don't take down the production servers. It's probably a good idea to have stricter control over the credentials to all things production as well. Some of those you hire may not be as keen on later decisions you have to make. Use your own imagination on what could happen there. Development costs mad loot, but losing investment capital on a bungled push or vengeful colleague costs crazy mad loot. Crazy mad loot being equal to the entire balance of your credit cards, mortgage, grocery money and corporate account - mathematically speaking. Not only is this division good development practice overall, it leads ever so gently into...

#3 Tackle the low hanging fruit with a bug bounty program.

If you have exposed web services, or a downloadable app, put some bounties on those puppies. Dedicate a few grand to standing up a bug bounty program. It's cheaper to 1099 a security guru to outline a bug bounty program than it is to have a full time reverse-engineer or seasoned code-reviewer. Pay a small retainer to someone experienced who can assign which class of vulns qualify for what level of payout. Have them write down specific guidelines for when you get multiple submissions for the same bug. Ask them to break down the payouts into how helpful the researcher who found the bug was. If they give you a full PoC with patch, give them the max. If you find someone who reports a flaw, but no assistance in reproducing it or a fix, give them considerably less. Depending on the complexity of your system/app, five grand worth of bounty funds could be well worth six-figures of full-time expertise. You'll never catch everything, at least this way you can catch the obvious. BugCrowd and ExploitHub exist for a reason. Use them to lower your vuln discovery costs.

#4 Keep the fridge stocked (bonus since it is not just related to security...maybe security-tangential)

Do you have any idea how far $500 at Costco can go production-wise? There's a reason Google has a cafeteria and places to play games. They keep the smart people at work longer. I am much more inclined to work an extra 10 hours a week if there's Monster in the fridge and Hot Pockets in the freezer. Try the following experiment sometime (not that I support human experimentation ESPECIALLY of the developer kind). Check the commits when you've exhausted your snacking reserves versus a post-Costco spendfest. Go ahead, do it. I won't tell if you don't. By the way, when you check the commits do not just check the count. Not all fixes are the same. I've seen one-liners that took a week to figure out while fifty lines was shat out in one jam session. All due to the fact that one was buried beneath a million rock layers of abstraction and the other was an easy feature request.

P.S. I know #2 was hard on devs, but I'm hoping you'll read into this piece that I mean all devs to include the founders/head-honchos if they are also the ones doing the development.

-vesh

No comments:

Post a Comment