Threat Scope for Minimum Viable Products — Startups
In a Startup, It is mostly a small and dedicated team to quickly deliver a new product to customers, whether in a B2C or B2B setting. Sometimes, due to their limited size, they may overlook the importance of good UI/UX design as well. Ultimately, the approach to building a minimum viable product depends on the mindset of the engineer or founder leading the project.
Startups focus on building stable, well-functioning, and scalable products but often overlook security. Security is only considered when a compliance requirement hinders the organisation’s ability to operate the product and obtain ISO or SOC2, etc certification. I have been fortunate to work with a team that prioritised security before the MVP was ready.
My plan for writing this document is that of something I come across in my product security journey. This note might help founders or engineers consider building a secure product without any security engineers to start considering security, But I write and explain things in a way that non-security people can understand. It’s called the Minimum Viable Threats. I’m not sure if this term exists. :-D
Here is another short note on the threat modelling, this writing also relates to the same threat modelling understanding.
What is the Minimum Viable Threat Scope?
Startups and organisations reach a point when they recognise that security impacts their business. This is where the concept of minimum viable threat scope comes into play. The idea is that an organisation’s minimum viable threat scope involves initiating security measures from the ground up and gradually progressing towards a mature security model.
The terms “minimum viable threat” and “scope” describe products or assessments with minimal consideration for security. However, this list may be extensive regarding tasks or engineering efforts. It’s important to consider a more mature security program. Nonetheless, the team needs to have a starting point to at least consider security from an engineering perspective.
Engineers should prioritise building security features to protect against potential threats, such as malicious users, to create a minimum viable product. It’s essential to anticipate what could go wrong and possible risks to address them effectively.
1. Authentication
2. Authorisation
3. Data In Transit
4. Data at Rest
5. Input Validation
To better understand the threats, let’s liken them to a physical scenario within the application or products. Picture an office building with various rooms with critical documents and essential products. First, we’ll examine the threats from a layman’s perspective and then align them with our application.
Authentication
You need to go to the office for business. Are you allowed to enter the building? If yes, you will need a key or an ID card to access the office, and you must use the key or show an ID card to the gatekeeper to enter.
Application perspective: If you are allowed to access the application as a user, the application will grant you an identifier, such as a session or a token.
Threats: Consider if someone were to print an ID card that looks like the one used in the office and use it to gain unauthorised access, or if they were to use another person’s ID card.
Similarly, misusing tokens or session generation to access the application poses a threat, and tampering with the tokens or sessions represents another method for gaining unauthorised authentication to the application.
As an engineer, security considerations would ensure that unauthorised individuals cannot obtain a token, and I need a secure method to implement this.
Acting team: Software Engineers
Authorisation
Imagine if you have the key or an ID card to enter a building, but you’re not allowed to access all areas. How would you restrict access? One way could be to have a gatekeeper inside to check if the ID card or key permits access to certain areas.
Application Perspective: The user has been granted the key or session, but the key should specify the scope of access and privileges. For example, a user may have access to the application but be unable to make any changes or perform operations on it. However, an admin or root user may be privileged to access and perform any necessary operation. Just like a boss can enter any space on the premises, the concept of isolating users based on their specific needs is called authorisation.
Threats: Tampering with user B’s information by user A in session, key, parameters in the request body, or URL
As an engineer, Build isolation validation or restriction based on privilege and generate the token only for it.
Acting team: Software Engineers
Data In Transit
Understanding Data in Transit from a non-expert perspective can be challenging when we try to relate it to a real-life scenario in an office setting. For instance, consider a situation where vital documents from higher officials are being passed between different departments. A specific group needs to access these documents by passing them between teams or making physical copies. However, administrative staff should be able to view the documents appropriately, make unauthorised copies, or dispose of them in appropriate places such as dustbins.
Application Perspective: The information we handle, such as Personally Identifiable Information (PII) or financial information, login credentials, or any other sensitive information, is securely transmitted through API transactions using SSL/TLS protocols. This provides an additional layer of security to keep the information secret. Only authorised applications or servers can decrypt the data, which is not visible to transiting channels or proxy servers due to encryption. It is crucial that no information is logged in the error logs or access logs of the application, as anyone with access to these logs for debugging purposes may be able to access this sensitive data.
Additionally, Introducing anti-API tampering mechanisms to the crucial APIs the system uses for transactions will ensure additional security.
Threats: Information leaking on the channel or ensuring the integrity of the data for the server
As an engineer, Implementing the secure channel for in-transit is the remediation. Using SSL/TLS is the minimum requirement, ensuring necessary encryption or data masking is added without logging in the logs.
Acting team: Software Engineers and Infra engineers
Data at Rest
Data at Rest is more like a store room; how do we ensure room security, and how do we provide the document security or product stored in the store room? Imagine the file is being stolen, someone coming and reading or making holes in the room and getting the files whatever the thief wanted. Or is the termite eating the files and not able to read the document or use the product for anything else after that?
Application Perspective: It is crucial for the application to collect and secure data and information for business, analytics, or compliance purposes. This includes using SQL/NoSQL databases for data and storing static and media files in blob storage like S3. Encryption, hashing passwords, and implementing database access control are essential for security.
Threats: Storing data confidentially, no unauthorised access and ensuring no information leakage
As an engineer, Implement encryption before storing data in the database, hash passwords, and implement access controls for databases and blob storage.
Acting team: Software Engineers and Infra engineers
Input Validation
Input validation is checking if users or customers provide the correct content in the document or raw data for the products in the office to process or function the business. This involves accepting only financial records from the accounts department and correcting data in the documents, while rejecting anything else. A bad example is this: What if I write someone’s name in a chequebook’s “account number” field? This customer drops the chequebook in a box, and later, the bank staff tries to process all the chequebooks from the box and sees this one. How could a bank employee process it,
Application Perspective: The application will only accept accurate business information or task automation information. For example, entering a phone number in the name or address section or entering random values in the phone number section could result in incorrect data being entered. This could potentially cause issues for the business or lead to system vulnerabilities that might be exploited.
Acting team: Software Engineers
Conclusion
To sum up, the idea of a minimum threat scope (MVTS) is a practical way to protect new and small businesses with limited resources. By focusing on fundamental security measures such as authentication, authorisation, data encryption, and input validation, even a small team can significantly enhance the security posture of their MVP. This approach allows them to launch their product quickly and establish a solid foundation for a more mature security program in the future.
Note : This is not a detailed write or notes. Please let me know what you would like to hear more, so I can improve it or add it to it and re-publish it.
Claps appreciated, if a non-security team found this interesting, just to understand if I'm adding value to the engineering.
