4 ms·

This list seems incredible helpful. As a security-conscientious CTO, one of the challenges I faced was determining how much we should be doing now (during YC an

This list seems incredible helpful. As a security-conscientious CTO, one of the challenges I faced was determining how much we should be doing now (during YC and while raising our seed round) versus pushing down the line. For example, we obviously should be monitoring outdated and insecure dependencies from the outset, but when is the right time to switch our servers and external tools to centralized account management, or to pay for an external pen test. Now, I would probably move the external pen test up to seed if the company is well-funded (e.g. post demo day) and holding PHI. But that’s personal preference and my security paranoia talking. Overall I think this list really gets it right. I also liked seeing a recommendation against sharing your WiFi network in the seed stage. Network segmentation to separate your computers and IoT devices, printers, etc. should probably appear somewhere in series A/B.

tptacek 7y ago
The best indication that you need an external penetration test is that you have client prospects demanding to see the output of those tests. A less important indication would be that you (1) have product/market fit, (2) have implemented your core product, (3) can predict what development on that product will look like for the next 12 months, and (4) have revenue sufficient to eat the $20-30k cost of a penetration test. I would not generally recommend that seed-stage companies contract out penetration tests simply because they've raised enough money to do so. You should be on a relatively stable, predictable path with regard to product engineering before you start asking contract pentesters to beat you up. I feel like this is a pretty good illustration of how not useful lists like these are. It's simplified down to this "seed", "series A", "series B" thing in order to suit the format and make it punchy; the real, serious advice isn't as slick, and doesn't showcase their product, so it's nowhere to be found.
tgsovlerkhgsel 7y ago
Having someone on the team who understands security (can be a security engineer who also writes software, or a software engineer who also has some serious clue about security) should happen as early as possible. You will almost certainly need some form of authentication system in a couple places, and it doesn't take a lot to keep you from making the worst mistakes. Once you've build your entire (internal or external) auth system in a broken way, fixing it afterward is much more expensive, and you can expect to have weekly breaches while you do it. This doesn't need to be back-breaking (compare: WhatsApp), but it is avoidable.

tptacek 7y ago

The best indication that you need an external penetration test is that you have client prospects demanding to see the output of those tests. A less important indication would be that you (1) have product/market fit, (2) have implemented your core product, (3) can predict what development on that product will look like for the next 12 months, and (4) have revenue sufficient to eat the $20-30k cost of a penetration test. I would not generally recommend that seed-stage companies contract out penetration tests simply because they've raised enough money to do so. You should be on a relatively stable, predictable path with regard to product engineering before you start asking contract pentesters to beat you up. I feel like this is a pretty good illustration of how not useful lists like these are. It's simplified down to this "seed", "series A", "series B" thing in order to suit the format and make it punchy; the real, serious advice isn't as slick, and doesn't showcase their product, so it's nowhere to be found.

tgsovlerkhgsel 7y ago

Having someone on the team who understands security (can be a security engineer who also writes software, or a software engineer who also has some serious clue about security) should happen as early as possible. You will almost certainly need some form of authentication system in a couple places, and it doesn't take a lot to keep you from making the worst mistakes. Once you've build your entire (internal or external) auth system in a broken way, fixing it afterward is much more expensive, and you can expect to have weekly breaches while you do it. This doesn't need to be back-breaking (compare: WhatsApp), but it is avoidable.