Threat modeling is the process of identifying, classifying and communicating threats. Threat modeling can be performed for any situation, application, organization or even for your own day to day life. We all practice informal threat modeling nearly every waking moment of our life. For example, you want to walk multiple city blocks to purchase coffee on what will be a hot summer day. The primary threats you have identified are the heat, the sun and the traffic on your walk. Therefore, once you have identified these threats, you put on sunscreen, go early in the morning and clearly follow all traffic lights and keep an eye out for traffic. Once you are back, you can review that you have returned safely with your coffee and have not gotten sunburnt. On the other hand, formalized threat modeling focuses on specific assets that you are intent on protecting and then disseminating that information to a larger group to gain consensus, determine threats you may have missed and ultimately inform others on the threats that are present in the environment relative to the assets being protected.
Getting started with Threat Modeling
The first step in threat modeling is defining the scope of what you are ultimately trying to protect. Are we performing threat modeling for a new feature or are we performing a threat model for the entire company? Once we define the scope, we can now move on to each asset and their specific threats. From there, we can now categorize the likelihood of each threat and assign a score to it. There are multiple ways of doing this from gut reactions to using specific modeling techniques like DREAD or FAIR. Once there is a score for each threat posed, a review of current mitigations should be undertaken. Once there is a clearer picture of the current threats and mitigations, this can now inform the overall next steps relative to the scope. There are numerous modeling frameworks available. The goal of threat modeling is to formalize communications across various organizations, so keep in mind who your target audience is when choosing a framework to start with.
Information security threat modeling has evolved from hypotheses about likelihood that one thinks this is critical and likely to using mathematical models that clearly define what critical and likely means. Various models help define the paucity and frequency of threats. When we dig into the threats we’ve defined, are they likely to happen weekly, monthly, yearly or once in ten years or more? Another area that threat modeling focuses on is a multi faceted value assessment. There are multiple ways to classify value from reputation to actual cost of replacement. By using a model that focuses on frequency coupled with the value of the asset, we can put specific numbers and use those to make decisions across the company.
Threat modeling can and should be performed at every level of an organization. When threat modeling applications, this review should be performed as early as possible and be taken into account in the design phase. This will reduce costs overall and improve your overall security posture.
Examples of Threat Modeling
For example, if we are working to protect a brand new application that is being developed we want to conduct a threat model as it is being designed. Some key questions that you will want to ask:
- Who will access the application?
- How will they access the application?
- Will this application be externally available on the Internet?
- What data will the application have access to?
- Will the application be dynamic or static?
- What infrastructure will the application be hosted on?
For each question, you will need to drill down to fully understand the potential threats. For example, for a financial service organization that enables individuals to use web applications to manage their investments online, the InfoSec team would model the threats to that application as follows:
- The application will be hosted online and will therefore be accessible by both intended users and potential attackers.
- Specific methods should be developed to continuously scan and protect the assets that should be public and guard against those that should not be publicly exposed like data endpoints.
- The data in the application is highly confidential and should be highly protected and the potential damage extremely high if a breach were to occur. This assessment in a matrix consideration will raise the threat level of even lower risks which can then be used in an overall prioritization across the organization.
- Given that this is high value information, each method of interaction should be thoroughly examined, from web browser to mobile application. For each of these methods, what are the authentication and authorization methods? The team should do a thorough analysis of login and reset flows, looking to best practices to enable the highest security possible for their customers.
- The application will be dynamic and responsive so a full security analysis should be undertaken to protect against threats like SQL injection, Cross Site Scripting (XSS), password spraying, dependency management and more. Manual and automated testing should be implemented to check for these threats ideally in a CI/CD environment before new builds are promoted to production. Internal and third-part application focused pentests should be performed.
You’ll note that we’ve only focused on the application, and not considered the underlying infrastructure, or even the data that this application is a gateway to. What are all the other technical components that will need to be monitored and protected?
By using a standard threat model across all of your applications, you can be sure to be consistent in your metrics and focus on a data driven approach to your information security program across the organization.
Threat Modeling to protect against Data Breaches
In today’s data driven environment, the data is what we are all protecting. It starts with an examination of where the data is that needs to be protected. In most organizations that are embracing digital transformation, this tends to be splattered across the following:
- SaaS applications
- User and company devices
- Homegrown applications
- Data repositories used by applications, users and BI tools
Over the years, agents, proxy and VPN-based solutions became popular to protect data across the first three, but data repositories were always protected indirectly. With the adoption of SaaS and cloud-based databases, data warehouses and pipelines, the threat exposure for data in those repositories has greatly increased. To learn more about how Cyral can help reduce that risk, register for a demo.
