Practical Cybersecurity for early Startups

This week's topic is cybersecurity, how to think about it, and tactical tips to protect yourself.

---

What you'll learn this week:

• This week's insight — putting your eggs in one basket (SVB)
• What is and why does cybersecurity matter?
• Three areas to look at to protect your SaaS
• Practical ways to start protecting yourself today

Enjoy!

---

This week's insight 👉 Putting all your eggs in one basket 🍳

Unless you've been living under a rock, you've already heard and read about the dramatic and sudden collapse of Silicon Valley Bank.

There are many takes about the cause and the impact it'll have.

But as a startup founder, what's there to learn from this?

The insight I took away is knowing where you've placed all your eggs in one basket. You can often do nothing to avoid it, but knowing your risks is essential.

Here are a few that came to mind:

• If my infrastructure platform (AWS, GCP, CloudFlare, Azure, Supabase, etc.) goes down, am I set up to handle it? What would happen if this happened?
• How would it impact me if one of my core vendors (Stripe, for example) changed rates? Do I have enough cushion to handle these changes, or must I pass them on?
• If I got sick, what would happen to day-to-day operations? Have I documented everything enough to have someone step in for me?

Please take the time and think through where you have put your eggs, and at least spend a few minutes considering what you can do to mitigate things.

---

🦹‍♂️ Cybersecurity 101

I'll make this quick because I assume most of you know what it is and why it matters. But for those who need a quick primer (such as non-technical founders).

You've probably heard of credit card breaches, the hacking group Anonymous, and how companies have had incidents because they stored passwords in their GitHub repositories.

What do these all have in common?

These are all facets of the larger realm of cybersecurity.

Put succinctly. Cybersecurity is pretty simple. It's the protection of digital assets. Aka, securing your digital assets.

There are three critical components to think through in cybersecurity:

• Who are you securing it from
• What are you securing
• What outcome are you trying to avoid

It's always important to consider all three aspects of your security.

Let's make these three categories real. Because context is king.

Who are you securing it from?

For our context, you'll want to consider two types of threat actors.

• Cyber Criminals — This can be anyone outside your startup who wants to do your business harm in some manner. This can include kids who learned to "hack" by watching YouTube up to Nation States (ex., North Korea). They're likely not out to get you personally. They're just out to make money. Ransomware is an excellent example of this.
• Insiders — Anyone internal to your startup. But this doesn't mean they carry ill will, this can be accidental stuff like misconfiguring your servers to let confidential info out.

What are you protecting?

If you have nothing anyone wants, no one will bother you, right? Well, not exactly, because everyone has something. As a startup, criminals will think you have more than you probably do. So what are you securing?

• Your service, for starters — maybe you're storing emails (which GDPR requires you to take seriously). Hopefully, you're letting someone like Stripe store your credit cards, but still, you could be a vector to get ahold of them.
• Your financial resources are another one. You have a bank account. Ransomware attacks are all about getting at that.

What outcomes are you avoiding?

Most SaaS are trying to avoid one of two things:

• A data breach — Where a cyber criminal exploits a flaw in your systems and can get ahold of confidential data (emails, credit cards, credentials, etc.). Or where an insider fat fingers something and lets the data get out to anyone (see common ways in configuration below).
• An outage — Where a cyber criminal DDoSs you or even exploits a vulnerability again and can take you down. Or worse hits you with ransomware locking a system up or you out of a critical system. And again, maybe you do it to yourself. Who hasn't accidentally messed up their DNS once and made it impossible for people to get to your site?

Anything else?

It gets far more nuanced than this. You can dive down a deep well quickly. But the above adds the necessary context to understand.

If you don't know what you're securing and why, you can't have an appropriate defense for it.

🔒 Three Key Concepts for Web App Cybersecurity Defense

1. Education
2. Key Security Controls
3. Automation

Eventually, you'll need to go far deeper. And I hope you do because that means you're successful and need to grow your team, hire infosec engineers, do regular pentesting, and more.

But for starters, these three areas will get you far.

1. Education

If you're reading this, you're already on the path to education. There are MANY great resources out there. But here are the top places I recommend to get started.

OWASP Top 10

The Open Worldwide Application Security Project is a nonprofit focused on helping improve software security. When it comes to education for the tech minded, the first step is to understand how your code is likely to be exploited (aka used against you!). For this, I recommend reading up on the OWASP Top 10. Their top-10 list is a must-read because it informs you of the likely vectors attackers use.

Broken Access Controls are the number one vector used. 94% of applications tested by OWASP in 2021 had some form of broken access control.

🚩🚩🚩 Did you read that?! 94%. What's a broken access control? How about not setting permissions on an S3 bucket or your Supabase table?

Certified Ethical Hacker Training

I recommend training in ethical hacking to get an even deeper understanding. I recommend everyone takes at least an intro-level CEH course. You can spend big money on this with the likes of the EC-Council. But you can pay nothing, but your time, on YouTube with the many free ethical hacking training videos.

2. Key Security Controls

What's a control? It's what prevents someone from breaking in.

For web application (including mobile apps) focused attacks controls boil down into three key buckets:

1. Application Gateways
2. Secure Configuration
3. Secure Code

(There are many controls, but for web apps, these are the big hitters and where to start, if you look at the OWASP Top-10, you'll see why.)

Let's unpack these.

Application Gateways

If the attacker can never get to your web app, it'll be hard for them to attack you. That's the point here. We're talking about:

• Firewalls (blocking scanning of ports that probably shouldn't be open anyhow)
• Web Application Firewalls (filters and blocks malicious attempts on the Top 10 list)

The good news is that most big cloud providers have these incredible systems available to you.

But, if you don't use them, they can't help you.

AWS and Azure have excellent application gateways that you can put your web application entirely behind. Configuration is easy (be sure to integrate your certificate, or it can't help you), and they don't cost a ton.

Just by being on a big cloud provider, you will get a lot of security controls. They have intrusion detection systems and more to secure their networks (and thus your networks).

But, there are a lot of "geniuses" out there who convince themselves that they really need to open port 8080 directly to the internet for … reasons.

Don't be that type of genius. Put your app behind an application gateway.

Secure Configuration

Do you have a boat? If you do, you'll likely know about boat drain plugs. They're the literal plug (sometimes screwed in, sometimes just pushed in) that allows your boat to drain water out. Or let water in if you remove the plug while out on the water.

Sound like a stupid thing?

So is forgetting to turn on a security policy for your S3 buckets. Yet SO MANY PEOPLE DO THIS.

That's just the tip of the iceberg for configuration mistakes. People still commonly set files with sensitive data as globally readable.

The list goes on.

If you're in the cloud, read this great list of top mistakes people make with cloud security.

👉 Hint, bucket security is #1, but 7 and 8 have been in the news lately.

Secure Code

Finally, the area most people are familiar with — is secure code, aka patching vulnerabilities.

For custom web apps, the core areas to be aware of are:

• Infrastructure-related vulnerabilities — Virtual machines need to be patched! This is one of the many reasons I love serverless.
• Dependency-related vulnerabilities — You know all those vulns NPM warns you about that you ignore? It turns out they matter, as they could let someone break in.
• Application-related vulnerabilities — Everyone's code has bugs, and some bugs let bad guys in.

The good news is detection of the first two is easy and practically free. App-related vulns can be trickier and more costly to find. But there are inexpensive ways to start, which I've listed below.

Ultimately, the first step to avoiding writing security flaws in your code is to know what they are. That's why I put education first.

3. Automation

I’ll be quick on this. Whenever possible, automate your security checks. For example, I have Qwiet AI integrated into GitHub, so whenever I do a check-in for ProductFoundry it scans my code for vulnerabilities.

If it's automated, you won't forget to do it.

💡 Practical ways to secure your SaaS today

Besides education (can I say go education enough?), here are some practical ways to start addressing security for your SaaS startup today.

(FYI — I'm not affiliated with any of the vendors mentioned below)

1. Implement code scanning. Companies like Qwiet AI and Snyk have free tiers to scan your code. I recommend you do this before you launch.
2. Use your cloud provider's additional security tools. I mentioned Application Gateways above, but AWS has many security offerings, and so do Azure and GCP. I've listed the big three, but look into your cloud provider, and I'm sure you'll find more. I encourage everyone to go beyond the defaults. Again before you launch.
3. Pay for Penetration Testing. This isn't cheap, and I recommend you do it as soon as you have customers and can afford it. Sooner if possible. But as I wrote above, application-related vulns are hard to find. Application Gateways do help, but pentesting always finds stuff. A single pentest can run thousands per app. You can find suitable vendors for $3k-$5k per test.
4. Do a Bug Bounty. Don't have enough cash to pay for a pentest, then offer a bug bounty! The Open Bug Bounty project lets you start your own bug bounty. Set a price and see what ethical hackers report.
5. Use established packages. It used to be surprisingly common for people to roll their own encryption. What a stupid thing to do. Everyone has figured out you don't do that now. But a surprising amount of people still write code that they could get for free off the shelf that has been hardened. Whenever possible, use code that's already been battled tested and has a group behind it.