Analyzing Risk and Automating Threat Modeling within your Supply Chain

Secure Software and Adhering to Standards

Software supply chains are becoming increasingly complex; exposing organizations to risks that they previously never had to consider. We all need to get a stronger grip on the risks our supply chain poses and our responsibilities, especially when it comes to data protection. Threat modeling is one route to understanding and mitigating these risks.

A lot has changed with deploying and testing software. There are additional security assessments for third parties, and more complex software supply chains, especially where a lot is operated from within cloud environments. As we know, OWASP Top Ten recognised Insecure Design as number four in 2021, and developers and architects do their best to ensure designs meet their requirements for security.

However, alongside the testing is the pressure to go fast into production which leaves organizations open to vulnerabilities if these activities are rushed. We all know how cyber attackers have exploited weak links in the security systems of SolarWinds, Goldcorp and many other organizations. Governments and regulators are responding, and in 2021 we saw Executive Order 14028 from President Biden, with an entire section (section 4) focussed on security in the supply chain. NIST has also released new guidance, including NIST Secure Software Development Framework and NIST Guidelines on Minimum Standards for Developer Verification of Software.

In this increasingly challenging environment it is critical that we look beyond our own organization's cyber security and ensure we secure our software supply chains.

Blurred Lines of Cloud Supply Chain Responsibility

Ensuring security in a software supply chain comes down to the movement of data from one organization to another; from cloud consumer to cloud provider, or vice versa and the emergence of hybrid cloud infrastructure has introduced new risks and complexities and uncertainty about data protection.

It has become necessary to establish exactly who is responsible for data protection at all the different levels within the cloud; the network level, the OS level, the application infrastructure level, and at the data level.

We have seen the emergence of more mature third-party audits and risk assessments to help manage this process. However, because the Shared Responsibility Model at one cloud provider can be different to another there is no one size fits all solution so we can’t rely on these alone.

Threat Modeling as a Pathway

One way to assess the risks in our software supply chain is by threat modeling.

When we threat model we create an architecture diagram that enables us to follow the movement of data. We can see when it crosses the provider's control and where it is stored. This repeatable process allows us to identify the gaps and potential gaps and how we can mitigate against these risks.

Whiteboarding, Visio diagrams or other manual techniques can be good threat modeling to start with, as long as it's structured and repeatable. This is where standard frameworks like STRIDE or PASTA can help (find out more in our Methodologies Blog). As long as a tool is used which is structured and repeatable, your organization can find a way to identify the gaps and come up with a strategy to mitigate them.

Teams need to be clear on what they are operating or building. Your cloud supplier might have responsibility managing its security, but you are accountable for the whole system and the data you are operating.

If you ask yourself these four questions, it will help create the pathway to threat modeling throughout your existing software supply chain:

Are you threat modeling?
Are you threat modeling throughout your supply chain?
How well do you understand your landscape?
How can you create a repeatable process?

Managing a large number of risks

Your threat model is likely to identify a number of recommendations that you will need to consider and some may require the allocation of considerable time and resources. So how do you prioritize what to take forward?

Step one - perform a qualitative risk assessment

Carry out a qualitative risk assessment first to identify which are high, medium and low risks based on your preferred framework and focus your efforts on addressing the highest risks first. Some industries are able to define mitigations by financial value and prioritize accordingly, but this differs per sector and organization.

Step two - choose a methodology or framework

If defining your priorities by financial risk is not your common practice, you could try the FAME open source Methodology (Filter, Analyze, Measure and Evaluate), alongside your automated threat modeling platform, and to accompany any other frameworks you may execute. Alternatively, read about some specific Threat Modeling Methodologies here.

Step three - implement a shared responsibility model

To save surprises later, and to ensure a common expectation and areas of accountability, agree on a shared responsibility model across your providers, and know where the lines cross over.

So, which mitigation is of higher priority than another one? Especially if teams are seeing 20 recommendations to close at a time, how do these get prioritized?

What next?

Take a look at the rest of our resources for more insights, or see our Platform page if you would like to understand more about IriusRisk Threat Modeling.

‍