Photo by Matthew Henry
Whenever you are working on a pet project or you are building an MVP for the future startup, you should be aware of cyber security part of your product. It might be hard to think about the security of your project at the early stages, because you are mostly focusing on delivering solution to the market for verifying and testing hypothesis and ideas as fast as possible. That could cause several cyber security risks in the future and even affect the future and existence of your product. Let’s imagine that your product idea will go viral and will bring many unique visitors to the website or mobile application. It could probably become a target for the cyber criminals and hackers. There are seven simple steps and recommendations that you and/or your team can apply for better security coverage. Let’s have a quick look at them.
You should evaluate every technical solution that you are planning to use in your startup technological stack, before taking a final decision to use it or not in the product. Usually, the best recommendation that you will find in every book or on the web is to use the technologies that you and/or your team are familiar with. It might have several advantages from business, engineer and time point of view, but it might also cause cyber security risks in the future. My recommendations are always to think critically and perform technologies assessment in advance.
There are 5 metrics and questions that you can use to do this.
The product supported by a group of engineers will probably receive necessary security features, patches and updates faster. If an individual support the product and the tool is famous in the community, it is a prominent sign for considering it as well.
If there is any critical security vulnerability discovered, the product should receive patches and updates in a timely manner. Usually, it might be a defined and regulated in SLA or SLS service agreements.
I recommend to check it out, then you will have an idea how popular the solution/framework/module is and how often it receives updates by contributors. For example, if you are using some module significantly in your code, and at some moments, you will encounter a bug or would like to have any specific features, you might end up writing and fixing this yourself. My recommendations it to define a list of open-source projects, and evaluate them based on several aggregated metrics and ranks: commits, contributions, issues opened and PR numbers. In addition, you might also include stars into account, but do not underestimate the other four metrics.
Bug Bounty Program is a cyber security program hosted on bug bounty platforms (for example, Hacker One). The goal of the program is to pay hackers across the world for their reports and findings inside the application/ or solution. If the project has a bug bounty program, it might be a significant plus for the solution or the project from security point of view.
This might be a good metric for product evaluation. Nowadays, every vulnerability discovered in products and reported by security researcher has CVE (Common Vulnerabilities and Exposures) number and CVSS score (Common Vulnerability Scoring System). CVSS is used to evaluate vulnerability impact, and it score varies based on the severity from Low to Critical. You can use cve.mitre.org website to find, if there are any findings and vulnerabilities for the project. It's also worth checking out, if there were security reports and CVEs in the past.
Small tip: When you will find a CVE number, you can search for it to find commits or issues/PR’s inside the product history. It will help you to understand how fast they were fixed, and will give you insights about the time to remediate vulnerabilities inside this project. (MTTR)
It is better to be aware of all operational costs of the solution and the product. The more experience and knowledge you have with it, the better it is for your project. Let's imagine if the deployment of the solution or microservice is not trivial at all, and you need to spend significant time and resources to achieve this. If the incident will happen and you will need to restore the service, it will take time for you to find the root cause and to restore the operations of it. In comparison, if you will be using tools familiar to you and you will have a detail contingency plan with necessary steps.
It might be beneficial to dedicate some time to learn about security coding practices and SDLC (Software Development Life Cycle). Today, modern frameworks and solutions incorporate application security recommendations by following security coding guidelines. It is better to be aware of them and use them on a daily basis.
Try to turn on security features and capabilities of the frameworks and programming products if they provide them. For example, one of the popular web framework for Go language called Lab Stack Echo has some configuration options to increase the security of application and web server, but you need to define the configuration and explicitly turn then on in the code.
You might enable some security scanning solution for the codebase and the application to find and to remediate the vulnerabilities at the early stages of the development life cycle. There are three main approaches in the IT industry for implementing this. One approach called SAST (static application security testing), IAST (Interactive Application Security Testing), RAST and another one DAST (dynamic application security testing). SAST solution scans your code for the security flows and vulnerabilities in it using code analysis tools, while DAST solutions perform a security scanning on running application. For example, GitHub now offers DepenDabot for scanning of outdated dependencies, this is static code analysis technique. As for the DAST, you can run any vulnerability scanner against your application find the threats, vulnerabilities during the execution.
Threat modelling is a useful tool for evaluating cyber security threats, risks and preventing them from happening by underlining them. The core idea of this exercise is to create a map of your infrastructure/project and to think from an attacker’s perspective about identifying possible entry points and loopholes. The goal is to help you to identify and evaluate the risk by having visibility of your solution and preventing potential cyber-attack by minimizing the impact of it.
There are 6 industry frameworks defined for performing threat modelling: STRIDE, NIST 800-154, PASTA, VAST, OCTAVE, Trike. While using any of those frameworks that will mostly cover your needs, you might find other methodologies available on the web at your disposal. The whole idea behind these frameworks is to list down all your product cloud/code assets, actions from the attacker to these assets, assign risk score, and to estimate potential damage. We will talk about more straightforward and convenient methodologies for doing this efficiently in the next articles.
All applications nowadays work with data. The application can store, process, and analyze the data. There are multiple regulations that define how applications should deal with the collected information and user data. One of them is GDPR, which requires companies to have certain procedure in place for their customers: such as data deletion, data transparency for users, and business procedure for informing authorities in case of the data breach. In addition, customers data might require to be stored and processed inside the country borders. For example, according to the GDPR, all data of EU citizens needs to be processed inside the countries in EU.
You need to implement certain functionalities in your application before public release to be compliant with data regulation laws in the countries, which you plan to operate. It will save your time in the future to change the architecture design/code base, if required. You will also minimize legal risks and possible penalties by authorities by implementing necessary features to avoid legal complaints.
The cloud infrastructure is one of the core components of every IT product. It is essential to select the right provider and right Cloud stack for your project from business, time, skill & knowledge and security aspect. There are several important aspects that you need to consider for selecting the infrastructure platform for fulfilling your requirements of your project.
Most probably, your application will require a deployment of its components to the cloud provider. It might be servers, virtual machines, containers in Kubernetes or it might be designed to go fully serverless with edge computing (Edge lambda). The recommendation is to select cloud provider that you had more experience with, or you are more familiar with, if you choose between AWS, Google Cloud, Azure or another vendor. I would suggest creating a comparison table with prices of services, your expertise score. deployment time and security controls into account.
Sometimes infrastructure and cloud providers have additional services for extra cost to secure your deployment and solution. It might be a web application firewalls, audits and events logs, automated remediation and evidence collection services, and so on. It's worth checking if cloud provider has any security tools and controls in place.
One more thing to be aware of is SOC2 compliance. If the cloud infrastructure provider has SOC2 compliance certificate, it means that it has some security business processes and controls in place for doing its operations. For example, the provider might have an SOC, perform regular security audits, have a procedure in place, in case of the incident and contingency plan.
Understand provider’s privacy and data processing policies. It is important to know how they store and process the data of your applications inside their platform. There are many laws and regulations nowadays that require the company to be compliant with, for example GDPR, HEPA and so on. Your project might store users data, and as a result, you need to be in line with the laws by underlining the process for storing and processing the data of your customers. We will discuss more about it in the data section.
Check providers SLA’s and SLS to ensure that the cloud infrastructure has some warranty to be accessible. It is another important thing to consider is infrastructure health dashboard. It is now an industry standard to provide health metrics of the services, for example health dashboard for infrastructure providers. This way if there is something wrong with their infrastructure or service, you will be notified and you will have a visibility about it.
Nothing could go wrong. Right? What will you be doing if something will go wrong? What will happen if your application will be a target for cyber criminals? Contingency plan is a plan used to ensure business continuity and its operations during a critical phase, for example, during cyber-attack. Usually, the part of the plan contains DRP (Disaster Recovery Plan), that includes the scenario, checklist and detailed execution recommendations for each of the steps and components. While creating and working on full business continuity process and DRP plan might require some professional expertise and time, you might simplify it by writing a very basic recover/contingency plan. It will save your time, money and potentially increase customer satisfaction, which is very important, because the service or applications in case of interruption will be restored and recovered faster.
Here is the simple idea of how you can implement it. Identify critical components in the application by performing infrastructure/product assessment. You can get some ideas from the threat modelling frameworks, risk assessment models and my future articles. I plan to write more about it in my upcoming posts. As for now, let’s say from the high level, you have two critical components in your project: Cloud Infrastructure (Database, Servers, containers), and your source code. For each of those components, prepare a checklist that will underline necessary steps to recover for all relevant components that are required for continuous operation of your product. For example, you might have a list of required steps with commands to restore the database and return it to normal operation. Why? Most probably, you will need to react fast, and you will be during a high pressure at critical moment. You need to be very precise about what you are doing and why to get back service to the normal operation as soon as possible, without making the problem more complex by executing improper command or forgetting something. The other crucial factor is a time constraint. By having the list of steps, it will help you restore the infrastructure faster and to have less downtime, as a result, to have happier customers.
It is essential to perform security assessment for every IT product. While SAST and DAST practices and techniques mostly focusing for helping and identifying threats in your applications during the development and deploying of the product, the automated security assessment solutions might not discover all security threats and vulnerabilities. This is where manual security assessment and reviews performed by security professional called penetration testing comes into account. There are many professionals and companies in the world, who are offering this type of services for their clients. Usually, you agree on the project: scope of security assessment, time and specific constraints. The outcome of this will be a report with discovered security vulnerabilities and finding for the solutions that you need to fix. If you don’t have resources to delegate this to professionals, you can do this yourself. I would recommend getting familiar with OWASP TOP 10 vulnerabilities and to read Bug Bounty reports. This way, you would get some insights about the vulnerably in the applications and the approach to identify them. If you have any friend who does the bug bounties, you may ask them to perform the assessment for you. While they might not be a professional, they still may find security flows in your application.
One of the alternatives will be to start a private or public bug bounty program. It will allow to bring enthusiast and penetration testing from all over the globe to perform a security assessment (hacking) of your application. The advantage of this, that there are many professionals specialized and having expertise for finding a very specific types of the vulnerabilities: for example, some of the bug bounty hunters focused on XSS (Cross Site Scripting), the other experts on SSRF (Server-Side Request Forgery). If a bug bounty hunter discovers any vulnerability, they report of the finding inside the bug bounty platform for your review and bounty. It is a good rule of thumb to perform a security audit by hiring a security consultancy company or professional expert first and later to publish it on the bug bounty platform. Otherwise, it might be an extensive amount of security reports that you need to evaluate and to pay a bounty, if the reports contain valid finding.
If you don’t have time to read the article, here are the areas that you need to be aware of and that will help to increase your product security. Usually at the early stages of your startup, you might not have a full security department that might work and support security areas of your solutions. It is a high probability that most of the work as a security engineer will rely on your side, so I wrote a simple guide for exploring the security aspects and necessary security areas.
By using these simple recommendations, you will already increase the security of your startups and personal projects. You can contact me on LinkedIn if you have questions or comments. It will be several interesting articles and security recommendations released in the future.
Stay secure!