Manage unknown cyber risk from 3rd (and greater) party software and systems

Measuring known unknowns.

The breach of information technology (IT) vendor SolarWinds – and subsequently of its customers, who include U.S. government departments and agencies – was unprecedented in terms of its impact. As part of their infiltration, what were likely Russian hackers compromised the software supply chains of their targets (government information systems) by exploiting weaknesses in another party (a federal contractor). The episode is a perfect example of the risks – and, in today’s digitally interconnected world, the necessity – of relying on the cybersecurity practices of people not under your direct control.

Although there were several notable warning signs about SolarWinds and its security posture prior to the late 2020 disclosure of the company’s breach, harbingers of an impending catastrophe originating from the government’s digital supply chain were not limited to that company alone. More generally, since at least 2012 the Government Accountability Office (GAO) has pointed out the risks to federal IT systems from what I call third and greater (>3rd) parties.

Unfortunately, the state-of-the-art with respect to managing >3rd party risk is primitive. Many organizations do not even understand how their software supply chain functions, much less conduct any risk analysis of it. Those that conduct due diligence of other individuals or groups upon which their data depends are often hyper-focused on certain parties and relationships while completely ignoring others. Furthermore, when faced with novel situations, security practitioners frequently resort to ad-hoc and manual assessments without any underlying framework, encouraging team members to work around or ignore vague procedures that have unclear end points or timelines for resolution.

Unfortunately, for both public as well as private sector organizations, what you don’t know about your technology supply chain – and the >3rd parties that comprise much of it – definitely can hurt you. In this article, I propose a methodology for thinking about the relevant risks, and in future ones I will explore the tools necessary to evaluate and mitigate them.

Definitions and scoping

Building from a framework I developed previously, it is worthwhile to scope this analysis narrowly to managing risk from unknown vulnerabilities. I have previously written about best practices for identifying and remediating known vulnerabilities in >3rd party code but would like to focus this article on a separate topic. The case of the SolarWinds hack is an excellent example of what I mean by unknown vulnerabilities: potential vectors through which an attacker could negatively impact the confidentiality, integrity, or availability of an organization’s data that are not identifiable from existing (at the time of exploitation) public and proprietary commercial sources. Two vulnerabilities (CVE-2020-13169 and CVE-2020-14005) used by the actors who compromised SolarWinds met this definition when the infiltration actually began, although they did surface publicly before widespread reporting of the breach. To tie this definition to more commonly used terminology, “zero-day” exploits necessarily target unknown vulnerabilities.

To be clear, I absolutely do not advocate ignoring known vulnerabilities. Managing them is a critical part of any cybersecurity program and I have written previously about how to do so. The purpose of establishing this dichotomy is simply to limit the scope of this particular discussion. Furthermore, I will focus only on risks stemming from malicious exploitation of such vulnerabilities. Financial insolvency and natural disasters impacting >3rd parties can certainly cause your organization headaches, but I will also exclude them from consideration in this article to maintain a manageable scope.

To expand on my previously established definition of >3rd parties, I would further describe them as groups or individuals over which you have no direct authority with respect to their software development or operations activities. At the same time, the security of your data relies on them to some extent. By direct authority, I mean that you could terminate an individual’s employment and network access if s/he did not write a line of code, shut down a virtual machine, or take (or refrain from) some other specific action. Examples include but are not limited to non-profit organizations publishing open-source code, individual hobbyists, public cloud service providers, software vendors, and other business partners.

>3rd party risk necessarily includes 4th party risk, which refers to that originating from sources with whom you do not have any direct relationship at all, and of which you may not even be aware. This category includes the suppliers of your suppliers or even infrastructure services like domain name providers (DNP), which experience has shown can be the target of malicious actors.

For example, in late 2016 a distributed denial of service attack against the DNP Dyn (later acquired by Oracle) temporarily brought down the software development and collaboration platform GitHub. It is likely that many organizations reliant on the latter had never heard of Dyn, and even more likely that they had never vetted it for vulnerabilities prior to the attack.

Due to the necessarily multi-layer relationship involved, 4th party risk can be even harder to track and quantify than 3rd party risk. Thankfully, its effects may be attenuated the further away it is in the supply chain from your organization. With that said, analyzing it is still warranted due to the potential for a low-probability but high-impact incident gravely disrupting your operations.

Because of the very nature of unknown vulnerabilities, managing the risk stemming from them impacting >3rd parties is difficult. Doing so requires an analytical methodology that can help predict how said vulnerabilities might be expected to impact your organization over time without actually knowing specific details about them. The essence of this task is forecasting how frequently such vulnerabilities will appear in external parties on whom you rely, how severe they will be, and how frequently malicious actors will exploit them. Although doing so can certainly be a challenging task, it is feasible when using a systematic and rigorous methodology.

Developing your process

From a process perspective, developing a risk management system that is capable of periodic or real-time updates without manual intervention is critical to allowing for rapid re-assessment of >3rd parties. Additionally, you should always prefer electronic ticketing or alerting systems over any process that relies on email, chat, or voice communications. While the latter media are often easier for conveying information in the moment, using them sometimes causes chaos after the fact when attempting to re-create analyses, approvals, and justifications for actions. Ensuring easy traceability of actions and decisions is critical for any program.

With that said, the first step in conducting your analysis should be a comprehensive inventory of >3rd parties upon which your organization relies. Due to the expansiveness of this effort, you should not spend time analyzing risk at this stage. This exercise should be simply a surface-level identification of the relevant parties, to the best extent of your knowledge. In many cases, such an exercise can take you many levels deep, such as determining which data center company hosts the cloud provider on top of which a Software-as-a-Service (SaaS) product runs. Similarly, it could include identifying a chain of dependencies for a 3rd party library called by your proprietary code.

Tracking these relationships in the appropriate tool(s) is vital. I have a strong preference for web-based applications that allow for live collaboration over emailing spreadsheets or using similar techniques that can cause version control problems. Many software composition analysis (SCA) and security rating products offer these features, and you should capitalize on them. With that said, you will need some sort of system or list that tracks these tools. Ensuring that your various inventories are mutually exclusive and completely exhaustive and are maintained in a centralized location accessible to all those with a need-to-know is the ultimate goal of this exercise.

Analyzing risk: impact

With the accounting of relationships in place, building a framework to evaluate risk is the next step. Whether you use the Factor Analysis of Information Risk (FAIR) or some other model, whichever methodology you employ should factor in both the impact and likelihood of potential attacks while also allowing for a side-by-side comparison between relevant situations, preferably in numerical rather than qualitative terms. Focus first on the impact aspect of your relationships with >3rd parties. Understanding how badly a breach of – or malicious activity by – the party in question would damage your organization is critical to prioritizing your subsequent evaluation of the likelihood of such an event occurring.

For example, the theft of information from a vendor that provides your company with non-electronic office supplies (staplers, paper, etc.) would, at worst, likely only lead to the exposure of relatively anodyne financial information (e.g. how much you spend on said office supplies). You probably should not spend too much time analyzing risks associated with this potential outcome. Conversely, a sustained loss of service from a cloud services provider upon which your SaaS product runs could be devastating. This is where you should pay a lot of attention.

Because every enterprise has limited time and resources, the potential impact to your organization should drive the level of detail in the analysis you conduct regarding the likelihood of such an adverse event. As you proceed through your evaluation, your understanding of the impact may also evolve. Additionally, you may even identify new relationships with >3rd parties which you had not previously considered. During the initial assessment and periodically thereafter, you should revisit both the inventory and impact evaluations.

Analyzing risk: likelihood

Once you have inventoried your >3rd party relationships and identified their potential impact to your organization’s operations, the next step is identifying the likelihood of the loss-incurring events actually happening (again, this discussion is focused only on those stemming from unknown vulnerabilities). To develop reasonable estimates, you will need to deploy various techniques to dig more deeply into each relationship. Additionally, in the process of conducting this analysis, you are likely to discover previously unknown but now actionable gaps in the security of external parties on which you rely.

Currently available tools for projecting the probable future concentration of unknown vulnerabilities in >3rd parties have widely varying degrees of effectiveness and sophistication. In future articles, I will analyze the available solutions such as security questionnaires, contractual terms, external audits, security ratings, and technical due diligence. Finally, after reviewing the available options for identifying risk, I will turn to how to synthesize and take action on the information you have gathered.

Conclusion

While the principles of risk management are generally consistent whether you are dealing with unknown vulnerabilities internal to your organization or ones outside of it, handling >3rd parties does require incorporating some unique considerations. Participants in the software supply chain often have widely varying cybersecurity risk tolerances, practices, and controls in place. This is not always clear to those who rely on their offerings, who, as a result, may make incorrect assumptions about the cybersecurity maturity of the former. 

Any organization that relies on others beyond its direct control to protect its data – which is essentially every one in the modern economy – would thus be well advised to implement a systematic >3rd party risk management program. Specifically with respect to forecasting the impact and likelihood of malicious exploitation of unknown vulnerabilities found externally, a wide variety of tools exist to assist in this endeavor. Building a logical framework to apply them, however, is a critical first step. Only with that in place can government, corporate, and non-profit security professionals begin to manage >3rd party risk in an efficient and cost-effective manner.