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. Suggested approach is based on the following principles:
- Security by default
- Security by design
- Identification, Authentication, and Authorization
- Segregation of responsibilities
Assuming that you're starting a product from scratch without any existing VNETs, IDPs, or parent companies' networks, you can follow this flow. However, if you have any of these things, you'll need to 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 an approach and tool that monitors 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 have a significant consequence on 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, doing network planning and a network map.
Why it’s important?
Network segregation is significant not only for the operations team, who will handle maintaining applications, and the DevOps team, who will care about the 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 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 the development of MVP.
POC/MVP/Demo stage:
The application deployment is done in subnets based on its logic. However, the build/deploy engine is unable to 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, and 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, the difference is only in the appliance stage.
Over several sprints, the product will be developed with a decent level of 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.
The reason we need this is that previously, our application was within a closed perimeter with no external load balancers, CDNs, or WAF. Therefore, these need to 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 to the post-production ideas.
Our product is observed and defended, and it’s time for proactive deeds:
- Deploy SOAR system to offload 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 see the building the secure startup is not complex as it looks like, and it much easier to do it at early stages, avoid financial and reputation losses.