If you compromise an employee at a mature, well-secured enterprise, what do you get?
Lots of team-specific communication and documents, sure, but any broader company information or systems access is usually locked down behind approvals processes.
Getting to anything good requires some lateral movement and privilege escalation.
Startups, however, are like a raw egg.
Break the shell, and everything falls out:
A huge chunk of their Slack instance: company conversations and every embarrassing detail from the #incidents channel.
Broad access to production systems and data.
No extra work required.
Hardening the shell
Good, post-compromise security is difficult for a startup.
There’s only so much “least-privilege access” you can achieve when most of your engineers participate in on-call and so need production access.
And having almost everything take place in public Slack channels is just necessary to keep up with the speed of shipping.
But, compared to an enterprise, startups have a much smaller and easier to understand perimeter.
Hardening the shell of the startup egg can be very effective.
Tools like passkeys make credential phishing significantly less of a worry.
And rolling out controls like this at a small startup is a breeze.
There’s no need to phase the rollout over months to avoid overwhelming your tech support team:
when a handful of people run into issues, you can just walk them through the issue yourself.
Hardening the shell is simple, but it only reduces the likelihood of compromise.
The egg is stronger, but still raw inside, with the same resulting impact if breached.
Boiling the egg
There are some quick wins to harden your shell as a startup, but lots of really great controls just aren’t feasible with a small security team.
An airtight application allowlisting policy could almost eliminate the threat of malware,
but can you keep up with maintaining it?
You’d now be a bottleneck every time anyone in the business wants to use some new software.
Instead, you need to start boiling the egg: reducing how much falls out if that perimeter is breached.
Re-evaluating who actually needs production access, and how much.
It’s unlikely your entire engineering team still all require the same level of access.
Requiring approvals for processes that are now too critical to be run or triggered by one person.
Even if the shell cracks, the whole thing shouldn’t collapse.
Don’t overcook it
If your startup has some magical, unique-to-you technology then, absolutely, go wild with security.
Apply every control you can think of to protect that intellectual property.
But, if your edge comes from being able to ship fast, the overhead of too much security could be just as disastrous as a breach from too little.
Introduce too much friction and watch product development fall behind.
Making users more secure generally means annoying them.
Whether it’s making them carry a hardware security key or just enforcing a short screensaver timeout, changing how people go about their work is annoying—and an annoyed user is not a secure user.
The effectiveness of a lot of security controls relies on the user cooperating.
If they get frustrated with all the barriers and friction between them and doing their actual job, they might just find ways around the controls—their shortened screensaver timeout is soon “fixed” with a keep-awake app and now they’re less secure than they were before.
