How to Approach Vendor Management Post SolarWinds Breach

December 22, 2020 | By IANS Faculty

The SolarWinds attack is driving a discussion around both SolarWinds itself and the role vendors in general can and should play in an organization. While useful, these discussions should be leveraged to adopt methods that reduce the risk of all vendors – not just SolarWinds – as well as change internal understandings around how vendor context and nuanced usage can dramatically affect risk levels.

SolarWinds Breach Impact on Vendor Management

In this article we will examine the SolarWinds breach and its impact on vendor management, particularly in terms of supplier ratings (pre-selection) and supplier monitoring (post-selection) and consider:

  • How should organizations measure vendors considering the SolarWinds breach?
  • How should vendor assessment evolve?

Issues with Vendor Management

Vendor management, as it commonly exists today, is the result of years of balancing scalability with resource availability and data availability. Vendor management has never been able to provide as strong a level of assurance as internal programs, but in the wake of high-profile vendor-related security issues, the push for a vendor management program has grown – even being codified into law for certain industries. However, the practice of vendor management has not kept pace with the changing reliance on vendors due to the rapid growth of vendor services, automation and integration.

Simply put, the only way to build a vendor management practice that can detect issues such as those recently discovered in the SolarWinds Orion breach requires devoting a significant number of resources to a dedicated reverse-engineering team and funding any existing incident management team at a level sufficient to gain an extremely high-level understanding of legitimate internal traffic. Many organizations do not do this and are technically incapable of detecting external compromise of vendor technology of which the vendor is unaware. Worse, of the few organizations that do invest in such an effort, only one (FireEye) was able to detect the issue and even then, only several months after the initial compromise was placed on its network and several years after it impacted the vendor.

Issues with Classification and Scoring

Traditional vendor classification using a high-medium-low rating system misses the nuance in terms of the risks vendors pose. Even a more modern tagging system can miss some of this nuance because the risk brought by vendors is highly dependent on how they are used. By some measures, SolarWinds Orion might not be considered a high-risk vendor because:

  • It does not work with end-user data or sensitive internal data.
  • The SolarWinds company does not gain internal access via its tool, so remote compromise of SolarWinds would not pose an access risk to the network.

SolarWinds Orion was targeted by the attacker group because it can run arbitrary commands on all the systems it monitors, often with a high level of privilege. But this issue applies to every vendor that uses a high-privilege service account internally, and the risk is elevated whether the remote command functionality is actively used.

The more modern scoring approach is similarly flawed because:

  • Scoring vendors are strictly limited to public data and have no way to legally identify if vendors are engaging in poor password practices, which is believed to be the initial access vector for the SolarWinds attack.
  • Because scoring vendors must operate at scale, they must ignore nuanced views of a vendor, which can make the difference between a critical issue for a vendor posing anywhere from a critical risk to the business or no risk at all.

Some scoring vendors, such as BitSight and Security Scorecard, make their analysis metrics more transparent to allow you to do your own nuanced analysis. However, there is still a significant blind spot in terms of what the assessment vendor can and cannot see. This is true whether an automated scoring service is used, an automation service is used for elements of the vendor program, or if the program is fully outsourced to a dedicated vendor management vendor.

Fundamentally, attempting to recognize the true risk would result in a requirement to assess an incredibly high number of high-risk vendors, and to do so in a thorough way that is not possible via simple questionnaires or remote scanning of the vendor's public presence. The internal cost of running such a program is usually significantly greater than simply pulling outsourced tasks back in-house. The economics of the situation simply do not allow most organizations to build a program at this level.

Unfortunately, the market economics driven by this reality do not address the issue either because the need for assurance is typically addressed by third-party assessment, such as a Service Organization Controls (SOC) 2 audit or penetration test, and neither of these activities are typically capable of identifying issues like the SolarWinds attacks. While some firms certainly can do this level of analysis, the costs of hiring them is such that they are only used when either executive or market demand is there. Thus far, the market is not pushing for this level of assessment, because such a push would cause a significant increase in prices across the industry.

Focus on Resilience and True Management

The core issue driving this situation is that organizations hire third parties to do work those parties can do cheaper, better or faster than the organization can. However, these gains are not free and to be cost-effective require the vendor to accept a higher risk level than the organization would. Risk management programs that attempt to drive this risk level down to the same level the organization would like will, on average, spend a comparable amount of money in monitoring, negotiating and changing systems as is saved in the original outsourcing. There is no reliable method to force a third party to operate as if it were an internal organization because no third party can adhere to every one of its customers' internal policies and remain profitable.

Instead of attempting to monitor a third party's security posture and leverage contract and economic pressure to drive change, consider the risks a vendor poses and address them internally. This fundamental shift moves monitoring away from a partial monitor of external factors to a comprehensive monitor of internal factors. By identifying the ways in which a vendor could increase your risk and taking internal steps to reduce that risk, it is possible to move toward a true management stance, avoiding whack-a-mole style iterative external assessment.

The classic example of internal resilience is tokenization. If vendors can be supplied with tokens that represent internal data for each data element not truly needed, and the data set can be reconstructed on its return, the overall security exposure via that vendor drops significantly. Organizations could also drop vendors into zero-trust zones for remote access and/or leverage automated deployment technologies to allow vendors to engage in change management paired with a staging environment, enabling internal resources to "replay" their changes into the production environment.

Once such methods are in place, collaboration efforts between your organization and a vendor can move into a management model, where expectations are set by your firm – via contract, addendums or simple communication – and the burden then falls to the vendor to provide the service within those constraints. Iterative discussion around the constraints, with the appropriate resources, can result in a much better understanding of vendor-related risk, as well as improve speed, quality and cost-efficiencies on both sides.

Supply Chain Analysis Fundamentals

The other factor to consider in the SolarWinds attack is the software supply chain. Even if you did not use SolarWinds Orion as a product, perhaps your vendors did. If one of those vendors had access to your systems or data, does this mean the attackers did too?

In this case, odds are high the attackers had potential access, but that potential access was not used – again, due to the limited resources on the part of the attackers. So, the fundamental questions for a supply chain analysis are:

  • How far down the rabbit hole do you go?
  • How worried are you about likely vs. potential compromise?

Most supply chain security analyses focus on the stability of the chain and the trustworthiness of the components delivered through the chain. Little work has been done in terms of what a breach of trust in a services chain could mean for others in the same chain, so it is difficult to know how different industries will react – over the long term – to the SolarWinds attacks. That said, some commonsense questions to consider as you do your own analysis include:

  • Have you classified your vendors into operational, tactical and strategic layers in terms of the services they provide and the data to which they have access?
  • Have you considered what impact a breach of trust in any of those vendors would have on your business, both in terms of maximum possible impact and likely impact?

Starting with strategic vendors that could have a significant likely impact, do you know which software elements they use, and which vendors supply their services?

As the analysis progresses:

  • Use confidence levels on each element of each vendor. The further out you get on the chain, the lower those confidence levels will be.
  • Set a limit on acceptable confidence to serve as a brake on the rabbit hole issue.
  • Tie each assessment element to a recommendation to reduce risk. Recommendations can focus on internal or external changes. Any element that lacks a recommendation should be considered an accepted risk and communicated accordingly.

Continuous Vendor Analysis

Vendor analysis is, by itself, a process that can never end. Most analyses are never complete, and further effort on analysis can find more information and improve confidence levels. However, analysis consumes resources and there is always a point of diminishing returns. When this type of analysis is extended to an entire supply chain, the issue compounds on itself, so it is critical to identify – in advance – how deep such analysis should go. Additionally, vendor management is necessarily limited, due to a lack of leverage on large vendors and lack of resources within smaller vendors.

The best approach is to devote resources toward reducing vendor risk via internal programs, improving resilience and reducing risk for all vendors. This approach makes the residual risk easier to see and manage. Organizations should consider:

  • Focusing monitoring efforts on elements that are understood and measurable, even if greater risks exist.
  • Ensuring greater risks are either accepted or addressed through internal efforts and vendor contracts.
  • Contextualizing scoring results. If third party scoring/ranking systems are in use, be sure each vendor’s operational context within your environment is documented so if a critical issue is discovered, the nuance that drives the overall risk level can be quickly and easily understood.
  • Remembering that risk cannot be reduced to zero. Every outsourcing effort brings with it a certain level of inherent risk. When a high-profile event occurs, all discussions should be redirected away from the high-profile event and toward contextualizing the vendor relationship with the generalized risk, with the high-profile event used to adjust the confidence level of that risk. Such an approach can reduce knee-jerk reactions and allow resources to be diverted to an appropriate practice to reduce risk for everyone. For example, much of the discussion around SolarWinds Orion has been focused on the product itself, when more productive discussion can be found around:
  • Improving egress monitoring and management within the organization.
  • Improving incident response capabilities, potentially including full packet capture for critical network juncture points.
  • Reviewing least privilege for each vendor's technologies, ensuring that potential damage is minimized.

In the end, the risk is there, regardless of how vendors are vetted or monitored. While improvements to vetting and monitoring can help, the amount they can shift the risk needle is usually small. High-profile events like this should be used to drive more fundamental conversations around reducing all vendor risk.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.


Find additional resources from our security practitioners.


Learn how IANS can help you and your security team.