"We need to move fast, we'll work on security things later"

They didn't

Security is one of those things that usually gets pushed back. "We need to move fast, we'll work on security things later". The truth is that security should be part of the first learning cycle. "Can we build this?". You should be learning how to build a secure product from day one.

Why?

Because security is not a feature. It's not something that you can add later. It's not something that you can bolt on. It's something that you need to build on from the ground up. It's the solid foundation your product will stand on.

Security is not a feature. It's a mindset. It's a culture. It's a way of working. It's a way of thinking. It's a way of building.

I also want to touch on the idea of value. Security is not a cost. It's an investment. It's an investment in your product. It's an investment in your customers. It's an investment in your reputation. Don't underestimate the cost of a security breach. It can be catastrophic. With a startup it's easy to assign value to the features you are working on, but much harder to assign value to security.

Security basics

Here are some security basics that you should be thinking about from day one in no particular order:

Least privilege: Only give access to what is needed and no more.
Four eyes: Admin access only with another engineer.
Multi-factor authentication: Require more than one piece of evidence to prove the identity of a user.
Logging and monitoring: Keep track of what's happening in your system.
Incident response: Have a plan in place for when things go wrong.
Encryption: Encrypt your data at rest and in transit.
Vulnerability management: Keep up to date with the latest security updates.
Secure coding practices: Make sure your developers are writing secure code.

That's a lot right? You know how you make your life easier? Automation

If you look back on this blog, I've talked a lot about cloud networking and all my examples show Cloudformation templates. Think, what are some of the main reasons for automation? Scalability is one reason. The ability to do a task 10s, 100s to 1,000,000s of times, with the same result, in much less time than a human can. Plus, you remove human error, assuming the automation itself is correct.

Automation is one piece of the security puzzle. The other is visibility. Attackers work in the dark, they cover their tracks. They hunt for exploits, open ports, permissive security. They scan your network, your endpoints.

Now consider most security breaches, what are the likely underlying reasons:

Human Erorr: Permissive security, misconfigured IAM, forgotten infra (drift)
Exploits: Actual code level security issues, open to be exploited
Insider threat: Disgruntled or compromised actors with motive and/or opportunity

Automating your platform, from infra deployment via Infrastructure as Code (IaC) to CI/CD code scanning, linting infra deployments, to cloud level security, in the case of AWS, deploying Service Control Policies (SCPs) in your organization to prevent actions such as one IAM user granting admin to another, or denying wildcard access to resources, which cannot by bypassed in your account.

Visibility comes from using tooling to bring forward what is happening in your cloud environment. Again I'm going lean on AWS here, so using services like Guard Duty and Inspector can greatly increase the awareness of what is going on.

Guard Duty uses various sources to understand what is common behaviour in your account and can alert if it detects anomolous behaviour. Inspector scans your containers. Another tip is Config, which can be used for drift detection. You can have rules setup to check if resources in your account have drifted from what you have deployed via IaC, see this template.

Tie Guard Duty and maybe Config to a paging solution. Get the logs to slack or whatever chat tooling you are using, open it up to your engineers so they also see what's going on (and by extension, see that activity is being montiored).

This is especially important for Four Eyes access. Have an automated process for granting four eyes access and have it log to a channel, again let's say slack. Have it open to all. It's also good if that triggers Guard Duty.

It shows, what's happening is being recorded. Not due to a lack of trust, but to keep us all safe.

I've touched on a lot here superficially, for more information, maybe I'll write more, but for now, consider the following links