By
·
3 minute read
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 burning ideas, but at least you would like to feel safe from the 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 identity management across several non-integrated services will become a headache. You can choose:
- Public IDPs like Azure Directory services, AWS IAM, etc.
- Hosted IDPs: 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. In most cases, the IDP tool dictates a method of implementing access control policies, but if not, you need to choose it across RBAC/GBAC/ABAC or others.
The next step is creating a plan of environments, network planning, and a network map.
Why it’s 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 turn into garbage.
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 pick out public/private/closed subnets per environment, ranges for tunnels, if applicable, and 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 only, we are ready to start developing the MVP.
POC/MVP/Demo stage:
The application deployment is done in subnets based on its logic. 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 some codebase, it's time to conduct SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing). SAST tools like SonarQube, Snyk, Fortify SCA, and 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 appliance 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 previously, our application was within a closed perimeter with no external load balancers, CDNs, or WAF. Therefore, these must be rolled out, configured, checked, and tested consistently. Once we have potential live users, we will deploy an SIEM system to track malicious activity within subnets. This will help us prevent cyber security attacks at an early stage.
One major 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 question of security hardening and legal requirements because they’re highly specific to industry and country and pass on to post-production ideas.
Our product is observed and defended, and it’s time for proactive deeds:
- Deploy SOAR system to offload the security team
- Establish End-to-End encryption
- Learn AI models based on security issues reported by SIEM/SOAR
- Establish security audit process: regular penetration testing, red/blue team, etc.
If you would like to fight against cybercrime all the time, it’s a good idea to set up a honeypot and fill abuse databases)
Epilog
As you can see, building a secure startup is not as complex as it looks, and it is much easier to do it at early stages to avoid financial and reputation losses.