A Beginners Guide to Third-Party Risk Management

Summary

In this blog post, I’ll go into the basics of third-party risk management, what the challenges are, and give you an overview of what an average Third-Party Risk Management (TPRM) program looks like. This is designed primarily for people new to the industry up to the mid-level, but there might be a few points valid for seniors with mature programs too.

Background

In recent years TPRM has become a growing chunk of work for cyber security teams. The main thing driving that is that each organization uses a significant amount of vendors for just about everything they do. This can range from staffing services and contractors to hardware and software. In the days of yore, these applications were bought and then run on the company’s servers internally. Still, as we’ve shifted primarily to the cloud, the risk landscape has changed as that data is now sitting with other companies.

These days many of the vendors we use host critical information relating to our companies; think about the standard tools you likely use every day, such as Slack, Salesforce, Confluence and Microsoft Teams. These tools are all cloud hosted and may store sensitive information about your company’s financials, your customer’s personally identifiable information (PII) and potentially your customer’s user-generated content (UGC).

Partner this with the fact these services are easy to sign up for, driven by sprawling organizations, and it’s easy for companies to lose track of what services they are using and where their data is going. This makes it challenging to secure the services that store this information. The more significant risk here is that it may also break local laws and regulations if employees are unaware of what data they are holding and where it’s going. Data protection regulations are growing as GDPR, CCPA, HIPAA, and FedRAMP have become priorities, all of which have significant repercussions, including legal and financial penalties for breaching.

Combine these factors and add in a sprinkle of breaches at large companies like Equifax, Solarwinds or Kaseya, and you can see why it’s become a priority of late. For attackers, a better way to get into a company with a strong cybersecurity posture is not through the company itself but through one of its vendors who have significantly weaker controls. It can also be an intelligent way to breach multiple companies at once rather than focusing all your time on a single target.

The Process

Of course, this is going to change a little bit in every company, but I figured I’d start with an average-looking flow to give new folks an idea of what the process looks like. There are often two sides to the story: the buyer side, which is what most TPRM analysts work on, and the seller side.

Buyer Side

1. An employee requests a service through the procurement pathway providing as much information as possible about the request. Often through a helpdesk request or a ticket.
2. The vendor is evaluated and usually put into a specific “bucket” such as contracting services, hardware, software, or however the company groups its vendors.
3. The use case is identified and ensured it’s valid.
4. The vendor is reviewed against current vendors. Some companies may want one tool for a specific thing. e.g. a company only works efficiently if the entire company is on one tool. It’s chaos if half the company is on Slack and the other half is on Microsoft Teams.
5. The vendor needs to provide information to be assessed, sometimes in the form of their Trust/Security webpages, but often it’s through questionnaires or tools like Whistic.
6. Once the TPRM analyst has all of the information, they can validate the security posture of the vendor and if it is valid for their company. This usually starts with an analysis to ensure that the vendor meets all compliance and regulation requirements, e.g. a company storing healthcare data for the company will be required to have HIPAA.
7. Next is the general security review. This process can vary heavily depending on the maturity and depth of the company. It could involve next to nothing in a start-up to detailed analysis and even on-site audits for regulated industries.
8. Finally, there is an approval or denial stage based on the previous review.

Vendor Side

1. The vendor will often get communications from the buyer to provide questionnaire information. This could be through an email, a salesperson at the vendor, or other means.
2. Usually, a support engineer, salesperson or even a dedicated TPRM analyst will fill out the required security questions for the buyer. Some teams may use software like RFPIO or TextExpander to speed up this process (canned responses for questions).
3. Once it’s complete, there can sometimes be some back and forth with the buyer.
4. The main goal for the analyst at this point is to validate if there were any pushbacks, and if the buyer did not purchase the product due to a privacy or security issue, then it should be noted.
5. On some cadence, the analyst should validate with the business and security teams if a security control or compliance certification is worth it. This information, when stored, can be a great marketing opportunity. A company will likely not bother with the high spend involved in SOC2 if a single customer asks for it. However, If many customers ask for it, then the ROI may be worthwhile. Security shouldn’t be a cost centre but a value-add at the enterprise level.

Gates and Checkpoints

In a TPRM program, you need checkpoints or gates where you can review vendors and verify them. Checkpoints are points in the process where you can verify a tool. Gates are locked checkpoints where someone cannot progress until a process has been completed.

As a rule of thumb, If you cannot put a sufficient checkpoint in place, then you are generally better off not reviewing at all.

If you don’t have application allowlisting, for example, you will likely be fighting the tide when it comes to your employees. If they can install apps without your approval, then you’ll only be reviewing a small portion of apps, and some less inclined employees may bypass your guidelines entirely. Due to this, TPRM and procurement teams generally pick a number of checkpoints based on what they can control. These vary depending on the company and sector, but a rough guide is attached below.

Commonly Reviewed:

These are all paid, and as they require spending, it’s easy to put a checkpoint in place during the purchasing stage.

• Paid SaaS Apps
• Personnel (Contractors, Staffing etc.)
• Hardware

Less Commonly Reviewed:

You can put checkpoints for these, but they are harder to monitor and contain. There’s no spend attached in many cases, so you need alternative checkpoints such as application allowlisting and enterprise browser controls.

• Browser Extensions
• Desktop Applications
• On-Prem Applications

Rarely Reviewed:

These are generally painful to gate and often forgotten by many procurement teams, but they still have significant risks.

• VSCode and IDE Extensions
• OAuth Logins
• Free SaaS Apps
• Software Dependencies
• Machine Images (E.g. AWS AMIs)

Analysing Risk

The main point of this process is to analyze risk. In most circumstances, the TPRM analyst is going to get little time to do detailed reviews on every single vendor that comes in, especially if you consider all of the above vendors as that’s going to number in the 1000s even at small companies.

There are often two stages of risk analysis:

1. Triage
2. Detailed Review

Triage

The triage phase is required to assign an initial risk rating to a vendor to determine what level of risk it presents to the company. The triage phase can be done by procurement and other non-technical teams, but it’s generally best to have the TPRM analysts do it if time permits. The main reason to do this early is so that you can streamline low-risk reviews and spend more time on those high-risk reviews. People have different ways of assigning risk levels, but the most common is likelihood and impact, like the matrix below:

Detailed Review

Once you get to the detailed review stage, there are three things you need to consider:

1. Compliance and regulations
2. The risk appetite of the company
3. The risk level of the vendor

Compliance

• A filled-out security questionnaire can include
  • Basic security questions (encryption at rest, encryption in transit, SSO support, etc.)
  • A list of regulations they are in compliance with, such as GDPR, CCPA etc
  • Architecture and potentially a list of data sub-processors or sub-vendors
• SOC2 Type 1 & Type 2 Reports
• Verification of their certifications such as HIPAA, FedRAMP etc
• Software architecture diagrams
• Internal policies or tables of contents
• Pentests, internal and external audits

These can vary in level; in general, a verified third-party audit is better than any kind of self-attestation. ISO27001 is usually not a great indicator, the same as a SOC2 Type 1 report. A SOC2 Type 2 report is better as it shows they’ve maintained validation for at least one year. The primary consideration for TPRM analysts to make during this stage is to ensure they comply with local laws and regulations as well as things their customers expect. If you use a non-FedRAMP vendor in your government cloud instance, then US Gov will not be happy with you.

Risk Appetite

Beyond compliance, it’s all going to depend on the company’s risk appetite. Usually, it goes from this:

1. Start-up - Going to care very little about security, cares more about product market fit and gaining revenue. They will use anything to get the job done and probably don’t do any or minimal TPRM. Likely cares about keeping software spending low.
2. SMBs - Maybe does basic TPRM looking more at compliance and making sure they don’t use any obviously bad software or SaaS apps hosted in a Russian teenager’s basement.
3. Large Enterprises - A lot more stringent, their customers are going to expect security and security is a value proposition for them above SMBs. Customers like banks and large multinationals expect the best security practices at a minimum.

Vendor Risk Level

Based on our earlier triage, we should have a risk level for the vendor. The TPRM analyst is usually going to have to make a judgement call based on the vendor itself, the use case internally and a quick scan of their security posture.

• A SaaS application hosted in Russia, designed to store healthcare information, is going to be an extremely risky venture for a US-based company.
• Hiring some temporary UK-based contractors from PWC who are going to be provided laptops by our company is fairly low risk.
• A slack app developed by a single person is likely fine as long as it only has permission to write and not read, assuming you have re-reviews on permission changes.

It’s all about context here, but you need to remember that use cases change. Once you allow an application for an initial use case, you’ll find the floodgates will open up. You can absolutely integrate the use case as a part of your analysis, but you should expect that use case to expand gradually without further checkpoints.

From here, you can then do a detailed analysis of the vendor to determine if they meet your minimum baseline thresholds for that risk tier. I strongly recommend having a written policy on your minimum security baselines. Often teams will be pressured to allow vendors through when they don’t meet your expectations and have defined criteria for this, with business approval required for exceptions is a must. Building these minimum security criteria into your contractual agreements is also a big plus, but you’ll always find that you’ll have to remove them for some problematic vendors.

This stage is very ad-hoc, and there isn’t specific guidance for it, but at a bare minimum, I generally look for this even in the lowest-risk applications.

• Encryption at rest (with good standards)
• Encryption in transit (with good standards)
• SSO Support

For higher-risk applications, I recommend using the list provided at https://mvsp.dev/ developed by Google, Salesforce and others as at least a starting point. This saves recreating the whole thing from scratch, and they put good thought into creating this.

Putting It All Together - An Example-Based Approach

Let’s take three companies and three vendors and pit them against each other. We’ll see what the outcomes of some theoretical reviews would look like. Assume for this exercise that the location is where the servers are located and that the start-ups do not have great security procedures.

Summary

Hopefully, this gave you an idea of some of the work that goes on in TPRM programs today. In the next post, I’ll be going into what some of the largest challenges around TPRM are, how I expect the field to develop, and what I’d consider to be my “perfect” program in the year 2023 would be.