Like all news-worthy attacks, much has been written about the SolarWinds attack, and there is no lack of opinion about what happened, why it happened, and the lingering effects.  The technical details and the range of impact continues to evolve as more is learned.  However, in all of the information about the attack, one fundamental truth about managing cybersecurity is reinforced: an organization must attain and mature a varied toolbox of capabilities to prevent and recover from such attacks, regardless of the technical means, motive, or method. 

In part two of this three-part blog, we explore a basic premise:  at its core, the SolarWinds attack is a supply chain problem.  This is not to downplay the technical underpinnings of the attack or the technical skills an organization will need to recover.  But, organizations implement technologies like SolarWinds to enable operational visibility and stability, thus relying on the trust relationship they create with the vendor.  When this relationship is breached—either through the vendor’s actions or because of some external malicious force—the organization is left to clean up the effects.    

To be sure, responding to such an attack takes technical competence.  Finding intrusive malware, remediating potential damage to infrastructure, and rebuilding such infrastructure (as might be required for SolarWinds devices) is not a trivial task.  But, more in the organization’s control is the ability to know their exposure to such vendors before an attack happens.  That’s where a solid third-party risk management program (TPRM) is front-and-center. 

Many organizations view TPRM in a compliance context.  It’s something they do because they are required to.  And, while it is indeed a fundamental part of many compliance frameworks, it also is a value investment for the organization as reacting to a breach can be far more costly across the board—in terms of revenue, reputation, fines and legal penalties, etc. 

So, what is third-party risk management? 

TPRM is the identification, assessment, and tracking of vendor relationships that could pose a risk to the organization.  This risk may come in the form of a potential interruption of service (because the vendor fails to deliver a product or service) or as a conduit to an information breach (where an organization shares access to systems or critical data.)  Regardless of the nature of the relationship, using and relying upon vendors expands the organization’s risk profile to “inherit” its partners’ risks.  And, that means that a part of your organization’s risk is not under your direct control. 

A third-party risk management program defines a life cycle for your vendor relationships and is implemented through well-established governance tools:  a policy, a set of vendor risk management standards, and a documented and communicated procedure. 

Once these foundational elements are in place, the real substance of a TPRM program is in defining, categorizing, and assessing the level of risk that is inherent in the relationship.  From a security perspective, this risk is defined by the degree to which the vendor:

• Has access to the organization’s critical assets (often from a remote location)
• Stores, transmits, or processes the organization’s data

The positive side-effect of a good TPRM process is the need to have a robust data classification policy—one that is approved by senior management and implemented across the organization and which clearly classifies organizational data as to its confidentiality, integrity, and availability requirements. 

Vendors that have trusted access to, and use of organizational systems and data, must be able to attest to the administrative, technical, and physical controls they have in place to protect these privileges—and ensure that no additional risk is passed to their customer.  A solid risk assessment questionnaire is a way to gather this information and to identify potential control deficiencies that may affect you before you enter into the relationship.  With this knowledge, you can decide how to better protect the organization from any potential third-party risks….or, just decide to avoid the relationship altogether.  And, by doing your due diligence, you get to make this decision in advance, not after a breach has affected your operations or exposed your confidential or regulated data. 

How does a TPRM program help with respect to the SolarWinds attack?

No doubt, the SolarWinds attack has organizations reevaluating their relationships with, and dependencies on, vendors. On the surface, an organization might feel powerless to control the risks they may inherit from a vendor relationship, but this couldn’t be further from the truth.  Even if there is no direct connection into your environment, when you accept a software update from a vendor, you are in essence providing them some level of access and control.  You are allowing a stranger into your house, and potentially giving them access to your most-prized possessions.  If you can verify that the stranger is indeed legitimate—in this case, if you assessed that SolarWinds had a strong control structure in place to prevent an external actor from injecting malware into a routine software update—you might feel more comfortable with this decision.  Through a third-party risk management program, you are vetting the stranger in advance—and if they don’t exhibit all of the qualities you find desirable in a dependable relationship, you can decide to keep them out.