Basic Security Setup for Startups

Preamble

I recently had a conversation with my friend about starting a new company. We discussed the various stages a company should go through to become mature and secure enough to operate in the modern market. This article will outline those stages. The suggested approach is based on the following principles:

• Security by default
• Security by design
• Identification, authentication, and authorization
• Segregation of responsibilities

You can follow this flow assuming that you're starting a product from scratch without any existing VNETs, IDPs, or parent companies' networks. However, if you have any of these things, you must adjust the flow accordingly.

Here are some definitions of terms that we'll be using in this article:

• SIEM (Security Information and Event Management) – an approach and tool used to monitor anomalies in networks and applications.
• SOAR (Security Orchestration, Automation, and Response) – a tool that sources the events produced by SIEM and applies corresponding automated responses. Security information and event management are approaches and tools that monitor anomalies in networks and applications.

Amble

You have an idea and a couple of developers with burning ideas, but at least you would like to feel safe from a security perspective. You have already imagined the financial model and have a product vision; you are almost ready to invest time and money. The first step is to choose the identity provider (IDP).

Why?

Sooner or later, your development team will grow, and managing identities across multiple non-integrated services will become a headache. You can choose:

• Public IDPs, such as Azure Directory services and AWS IAM.
• Hosted IDPs, such as MS AD, Simple AD, open-source LDAP services, etc.

The choice will significantly affect the tools and order of tasks that need to be done. For generic cases, assume a public IDP provider is used. In most cases, the IDP tool dictates a method for implementing access control policies; however, if not, you need to choose among RBAC, GBAC, ABAC, or other options.

The next step is to create a plan for environments, network planning, and a network map.

Why is it important?

Network segregation is significant not only for the operations team, which will handle maintaining applications, and the DevOps team, which will care about deployments, but also for security reasons: You will need to restrict network access and implement SIEM/SOAR systems. Without wise network planning, these systems become ineffective.

We will start building a closed perimeter for our product during this step. Only authenticated and authorized users should have access to it.

Therefore, it’s time to select public, private, or closed subnets per environment, specify ranges for tunnels (if applicable), and define a VPN subnet. We also need to deploy a VPN server and configure it to use our IDP as a source of truth. At this stage, we are only ready to start developing the MVP.

POC/MVP/Demo Stage

The application deployment is performed in subnets based on its logical structure. However, the build/deploy engine cannot reach orchestration or database endpoints from external networks. There are three ways to overcome this issue:

• Deploy the build engine with build agents inside networks
• Deploy the build agent and configure management with the pull model
• Use the GitOps approach

Now that there is a codebase, it's time to conduct SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing). SAST tools, such as SonarQube, Snyk, and Fortify SCA, as well as DAST tools like Veracode, Acunetix, and Burp Suite, can be used for this purpose. Some of these tools are cross-functional and can play both roles, and the difference is only in the application stage.

Over several sprints, the product will be developed to a decent quality that can be delivered to demo users or shown to investors.

Live

Your product is now ready to go live. We have a deployed stage with an identical network and application to the production environment. This is the time to configure firewall rules, NACLs, or any other method of restricting access to people who are not part of the QA/Security/Ops or any other assigned team.

We need this because our application was previously located within a closed perimeter with no external load balancers, CDNs, or WAFs. Therefore, these must be rolled out, configured, checked, and tested consistently. Once we have identified potential live users, we will deploy a SIEM system to track malicious activity within the subnets. This will help us prevent cybersecurity attacks at an early stage.

One significant difference between enterprises and start-ups is the implementation of SSO. Although it can be costly and pose integration challenges, it standardizes sign-in approaches and protects the authentication endpoints.

Post-Live Security

I omit the questions of security hardening and legal requirements because they’re particular to industry and country, and proceed to post-production ideas.

Our product is observed and defended, and it’s time for proactive deeds:

1. Deploy the SOAR system to offload the security team
2. Establish End-to-End encryption
3. Learn AI models based on security issues reported by SIEM/SOAR
4. Establish a security audit process, including regular penetration testing, red team and blue team exercises, etc.

If you want to combat cybercrime consistently, it’s a good idea to set up a honeypot and report abuse to databases.

Epilog

As you can see, building a secure startup is not as complex as it appears, and it is much easier to do so at the early stages to avoid financial and reputational losses.