Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted 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.
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:
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.
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:
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:
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.
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
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.
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:
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:
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:
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:
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.
February 21, 2024
By IANS Research
Learn why cloud IR is critical to security and not just another box to check. Find guidance to get started building a strong cloud IR program.
February 15, 2024
By Alex Sharpe, IANS Faculty
IANS Faculty member Alex Sharpe discusses the risks around AI adoption and provides governance guidance to make your AI launch safe and mitigate risk.
February 13, 2024
By IANS Faculty
Learn how to how to use NIST to modify secure baseline configurations to account for risk and improve security posture.