Intro and Why is Threat Modeling Necessary?

With the increasing use of technology in all aspects of our lives, the threat landscape has become more complex and challenging. Threat actors are becoming more sophisticated in their attack methods, and the consequences of a successful breach can be severe, ranging from financial loss to reputational damage. This makes threat modeling an essential practice in today's world because it helps organizations stay ahead of evolving cyber threats and vulnerabilities.

Threat modeling provides a structured and systematic approach to identifying potential risks and vulnerabilities. By evaluating potential threats, organizations can make informed decisions about the level of risk they are willing to accept and allocate resources effectively to mitigate those risks. This proactive approach enables organizations to prioritize their security efforts and take the necessary steps to protect their critical assets.

The process also helps organizations comply with some important regulations by identifying potential risks and vulnerabilities and implementing appropriate security controls to mitigate them.

What is Threat Modeling

Threat modeling is a process of looking at the big picture and asking some important questions about the product we are building. The ultimate goal of a Threat model is to find good threats as early as possible. The process of Threat modeling involves asking questions like:

• What are we building?
• What could go wrong with this?
• What are we going to do, when something goes wrong?
• And finally, did we do a good job at Threat modeling and identifying good threats?

These questions need to be asked and answered at every stage of building a product and all the stakeholders of the project engineering teams should be involved in this process.

The process should be designed in such a manner that it should not become yet another burden on the teams. Instead, it should become a productive exercise and an asset that facilitates addressing the security primitives of the product.

When delivering our product, we need to devise some strategy to protect it from various vulnerabilities and security threats online. But, the process of ~strategizing~ of security ~distractors~ is to be followed after the product is ready would be of very little help to us. This is because we do not have factored in the scenarios about What could go wrong and what are we going to do about it beforehand. This could be only achieved once we clearly define our product architecture, its threat boundaries, attack vectors, and possible vulnerabilities and security that could face during the product planning phase. This process enables us to visualize and brainstorm various threats and vulnerabilities that could affect our software product.

A threat boundary, simply put is a place where data is passed between two processes. Whereas attack surfaces are all the possible entry points for getting unauthorized access to a system. With the above inputs at our disposal, we can begin to Threat model.

Brief about all four questions and their importance

Let's discuss some specifics about the process

What could go wrong

To carry out effective threat modeling, we need to clearly define the architecture of the product we are building. Here is the super complex architecture of a web application :p:

By looking at it we can infer that the database (DB) has no permissions to talk to frontend logic (FE) in our application. All the information a client requires is flowing through the backend service (BE). The arrows in a way define the threat boundaries. Now, we have to focus on some specific areas of the product engineering stage. We need to focus on the assets, the attackers, and the software we are building.

By looking at the architecture, its threat boundaries, and possible attack vectors. We can ask, What could go wrong here? and is this allowed? Some, issues we could come up with could be identified by a Threat modeling framework called STRIDE. STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Following are some details on carrying out Threat modeling based on STRIDE methodology and remedial actions for the threats identified:

STRIDE Method of Modeling

• Spoofing: To start with we can ask, what if someone pretends to be a registered client? Someone could also be imitating our website. In these cases, our requirement would be to incorporate some sought of authentication service that confirms that the person logging in is the same person he says he is. For imitation threats, we need to ensure SSL certificates are incorporated and we have a single domain for all our pages.

• Tampering: A programmer erroneously, or mischievously tamper with our application code which could expose our backend and database services to some third party. May even tamper with the authorization logic which could be even more harmful. To mitigate such risks of tampering, we need to ensure that any updates made to the application codebase go through a testing framework in a staging environment well before merging into the main application code. Any of the packages used in our application needs to be scanned for any vulnerabilities.

• Repudiation: This stage deals with implementing a secure logging framework for any actions occurring in the above scenarios. We need to ensure, that we are logging the right information with respect. Whether the logs are protected against tampering?

• Information Disclosure: Is our data safe in the database of our choice? Is the data transfer between various services vulnerable to theft? These can be mitigated by implementing mTLS within our services for encrypting the data in flight. Similarly, for securing the data in the database, we can employ a strategy to encrypt the data at rest.

• Denial of Service: What would happen if our services are pounded with fake traffic — DDoS attack? How we would handle some genuine traffic during some Cyber Monday offer periods? We need a clear DDoS response plan in place. We would also need to implement some tools that safeguard our application using some tools:

• That prevents spoofing by checking if traffic has a source address consistent with the origin addresses.

• Web security tools that remove web-based threats, block abnormal traffic and search for known attack signatures.

• Elevation of Privilege: According to our architecture, only the frontend (FE) is the only service exposed to the clients. But, is that enforced? Is there a preventive mechanism in place to restrict access to other services and update the code, etc. To prevent such cases of someone erroneously or mischievously accessing secure backend and database services can be implemented by formulating meticulous IAM policies.

Once the threats are identified, we can take appropriate remedial action on them. Mainly, there are four ways we can take action against the threats identified. We can mitigate it by some appropriate action, eliminating the threat, at a specific point in time it could be so that the threat can not be mitigated for various reasons. In such scenarios, the best way to mitigate the threat is to eliminate a feature exposing that specific threat, thereby eliminating the threat. The next is to transfer the threat, we can mitigate risk by delegating responsibility to external sources. For instance, you may choose to rely on the operating system to handle authentication threats or to trust a firewall product for enforcing trust boundaries. And the last one accepting the risk, is the final approach to addressing threats. For some threats, the best approach is to accept the threat and move on, as the cost of implementing a remedial action for a threat could be too high for eliminating the threat.

Conclusion

In conclusion, The process of threat modeling is accessible to any technical professional. It involves overlaying two distinct models: one that outlines potential risks and another that represents the software being developed or deployed in a diagrammatic form. One commonly used model for identifying threats is STRIDE, which encompasses threats such as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.