Cindy Chadwick, Supplier Cyber Security Risk & Assurance Principal Architect, GSK

Below is an insight into what can be expected from Cindy’s session at Third Party & Supply Chain Risk USA 2023.

The views and opinions expressed in this article are those of the thought leader as an individual, and are not attributed to CeFPro or any particular organization.

Why should organizations be prioritizing cyber security when it comes to third party risk? Are there any notable incidents that have recently occurred that support this?

Attackers are increasingly using third parties as channels to spread malware faster and wider by injecting malware directly into the software supply chain. Simultaneously, they are also leveraging third parties as softer, less fortified backdoors into larger companies they wish to attack, who generally have more hardened security than their third parties. Think of the third party as the lightly guarded service entrance to an otherwise well-fortified, well-protected castle.

These attackers are essentially exploiting the trust relationship within supplier-customer relationships. In today’s cyber security realm, the move has been towards a security approach called ‘zero trust’, wherein even traffic on our own networks is not assumed to be from a trusted source. However, too few companies adopt a zero trust—or even a ‘trust but verify’—mentality when it comes to the security hygiene of the third parties that receive, use, or store their sensitive and confidential information.

Third party security risk management programs are developed to address the type of third party threat wherein the attacker exploits the data exchange and data storage technologies of a targeted company’s trusted third parties. A good example of this type of data breach occurred at T-Mobile in 2021. The breach exposed 75 million customers’ accounts. Hackers obtained the T-Mobile customer data, which included social security numbers and other government identifiers, by infiltrating a third-party email vendor to gain access to T-Mobile servers.

A 2020 GE data breach was caused by a successful attack on a third party to the company, Canon Business Process Service, a human resources document management provider. Sensitive data, including the personal health information (PHI) of more than 200,000 GE employees, were exposed in the breach.

What is the importance of aligning on the enterprise meaning of risk, and how does this relate to conversations surrounding tech?

The everyday, person-on-the-street definition of risk as ‘something bad could happen; maybe something scary-bad’ is not the definition we use for the word within enterprise risk management functions such as Third Party Security Risk Management (TPSRM). That definition is far more precise, and under formal risk management practices, the level of risk is determined through a well-defined process.

Most people within tech, including those in cyber security, will use the word ‘risk’ synonymously with both ‘threat’ and ‘vulnerability’. All three, however, convey very distinct and separate meanings. Within IT, Audit findings (which are identified compliance gaps) are often mislabeled these days as ‘risks’. Within the formal risk discipline, risk is defined as a combination of likelihood and impact. If you have not identified the likelihood of an event or condition occurring as well as the potential worst impact should it occur, then you have not identified a risk. Likely, what you have identified is a threat, a vulnerability, or an instance of non-compliance.

We rely on our cyber security subject matter experts to identify for us the threats and vulnerabilities that may lead to significant organizational security risks. These differing understandings of what constitutes a risk will obviously get in the way of having productive conversations regarding your company’s enterprise IT security risks. So, the first step in cyber risk conversations is to align on the meaning of ‘risk’ as the term relates to enterprise risk management. Understanding the enterprise definition of what constitutes, for instance, a medium business impact versus a high business impact is important, as the enterprise view of these terms typically sets a very high threshold compared to what most people would think when they think of a medium or high risk. We’re just not accustomed to thinking in such large numbers, particularly when it comes to money. With these common understandings in place, conversations around your company’s threats, vulnerabilities, and risks will be smoother and more productive. The same applies to conversations with your internal or external IT auditors.

What would a successful third party security risk management (TPSRM) framework look like? Should this apply to all organizations or differ between industries?

While regulatory requirements vary by industry sector, malware is an equal threat to all companies. Small, medium, or large, all companies can see their business brought to a screeching halt by ransomware. Therefore, the basic security protections will be the same across industries, including those related to third party security risk management.

At a high level, a pretty standard TPSRM framework would include the following processes:

• Onboarding, which would include an initial risk assessment and a resultant risk tiering (i.e., assignment of a risk level, such as low, medium, high, or critical) to the vendor for the scope of the engagement under consideration
• More in-depth security assessment(s), typically including a questionnaire-based self-attestation, with the depth of assessment dependent on the risk tier assigned to the third party engagement
• Validation through evidence collection of the most critical security controls the third party has asserted that they have in place
• Remediation of security control gaps that present a significant risk to the company’s information assets
• Inclusion of basic and risk-tier-specific security clauses within the contract
• Continuous monitoring of third parties’ ongoing security posture (may not apply to all risk tiers)
• Offboarding, which must include the third party fulfilling their contractual obligations regarding data retention and destruction

Are there any disparities between a TPSRM framework and what happens in real life? Where do the biggest challenges lie?

Of course, there are always differences between the idealism of a framework and the reality of putting it into practice. Each piece of the TPSRM framework has its real-life ‘where the rubber meets the road’ challenges. Rather than trying to look at each of these challenges in a one-off manner, I think it’s more helpful to look at the root cause of the collective challenges so that they may be addressed in a more systemic way.

Historically, third party security has been treated as a checkbox compliance exercise in most industries and most companies. TPSRM traditionally, then, was very small and operated in a silo, though often a silo of just one person. This has resulted in an unfortunate historical lack of focus on the security of the channels of data exchange with our trusted third parties and on how data was secured by our third parties as it was sent and received, used, and stored by them.

It is still just that in far too many companies and organizations. Thus TPSRM programs today, if they exist at all, tend to be relatively new within the broader IT landscape and thus are in the beginning stages of maturation and not well-integrated into the organization’s overall procurement processes.

This lack of integration leads too often to the third party security risk assessment and other due diligence activities being treated as tag-ons at the very end of the procurement process. Because third party risk management has not been integrated into the very beginning of the procurement process—starting in the planning phase of the RFP process—contract deadlines are set without consideration of the expected timeline for completing the required security assessments, remediation, and negotiation of security clauses in the third party contracts. This results in burning-fire situations as the contract-signing deadline approaches, such as when TPSRM first learns of a third-party engagement, when they are told they must do an “urgent assessment” on a “critical” engagement with a contract deadline in 2 weeks, or even 2 days. Sadly, these situations outside of TPSRM control in many organizations result in “security” being frequently blamed as a “roadblock” to getting business done, when in fact, it is the organizational procurement process that is broken because TPSRM was never integrated into it. There should be top-down executive support within the organization to prioritize and drive this integration so that third party security risk management will add all the value to the organization that it is intended to provide.