Third-party security risk management (TPRM) is the process of analyzing and addressing risks associated with outsourcing to third-party vendors or service providers.
The era of the mega hack is upon us. With the increasing number of advanced persistent threat actors and sophisticated tactics, techniques and procedures, hundreds of thousands of companies are getting burned in third-party breaches. This escalation is just getting started.
The news is riddled with third-party breaches. Since December of 2020, security professionals have grappled with the SolarWinds attack, followed by O365 exploits, the Accellion vulnerability, and now the Microsoft Exchange Server breach. Not to mention countless other smaller, third-party breaches peppered in.
So who owns third-party security risk management in your organization, and do you have a plan to address it?
Third-party risk management (TPRM) is the process of analyzing and addressing risks associated with outsourcing to third-party vendors or service providers. As a business owner, you are trusting them with your organization's intellectual property, data, operations, finances, IT, employee data, customer information or other sensitive resources.
The state of TPRM is in somewhat of a mess, as made clear by these breaches. Nearly all of the recent big breaches can be traced back to third parties.
Your business needs to go on the offensive with TPRM.
As the leader of your organization, you are responsible for its outcomes, even–or, especially–when things go wrong. Take the SolarWinds breach as an example of what NOT to do. They blamed their breach on a lowly intern using a weak password. But who was responsible for authorizing the intern program? Providing the budget for security tools? Confirming that security policies, procedures, and controls were current? Ensuring that the organization had a security training program? Ensuring the efforts of the security team would provide a defense-in-depth approach to security? Hiring the right people to fill critical positions? All threads lead back to the top in a healthy organization.
Ultimately, you are responsible. That means setting meaningful expectations, making sure the right people are part of the TPRM program, and scheduling regular touchpoints. During those meetings, discuss documented results from the team so you can help them stay on track with their efforts and bring them back into alignment if needed.
Choose someone to execute on the TPRM program. Ideally, they will care about identifying risks, genuinely want to protect the business and your customers’ data, and have some experience identifying cybersecurity risks.
Small-to-medium businesses (SMBs) generally choose people to drive their TPRM efforts based on bandwidth and functional skills, which often means choosing an existing department or individual to pull double duty. Here are some pros and cons to consider when making that decision:
Many SMBs assign TPRM to IT, but it is important to understand that not all IT teams also fulfill Information Systems (IS) functions. If your IT team is well-versed in security or if you have a dedicated IS team, they will be excellent subject matter experts for TPRM. However, a typical IT team is primarily concerned with ensuring systems, applications, and networks are functional, and might not have sufficient depth of security knowledge to execute TPRM efforts. This is true of many outsourced IT departments as well.
This might seem like the perfect fit to lead your TPRM program because they deal with vendors and contractors so often. The challenge here is that purchasing and contracting teams don’t generally have the technology prowess or cybersecurity knowledge to judge risk levels of your vendors, attack surface or threat landscape.
If your business is lucky enough to have someone who manages compliance or policies, they could be a good fit if they have a background in auditing. Remember though, their plate is often full, and they may not have a deep technological background to identify cyber threats or risks.
Contract management is a small subset of TPRM. When legal runs TPRM, we find they focus too much on dealing with risk through what is written in the contract rather than identifying technology considerations or third-party vulnerabilities. This option may also be cost prohibitive.
Read to learn about business continuity plans.
At this point, you may decide to hand off daily TPRM activities to the team including picking a TPRM framework. Make sure the framework provides industry-based guidance. Take into account regulatory and compliance requirements. Third-party banking risks, for example, will be vastly different from e-commerce, retail, hotel or industry sector risks. Organizations like NIST and ISO have put together several effective options to help you get started in addressing all the right questions.
It’s important to document every third party that interacts with your business. It is tempting to ignore the mundane, low-risk vendors, but they can still cause some of the biggest breaches if they are missed in your TPRM assessment. For example, the recent General Electric breach was caused by an HR document management vendor, and the Target breach of 2013 came from an HVAC service provider’s stolen credentials.
The greatest challenge when documenting third parties is the unknowns. For example, you may have an insecure soda machine in the break room that connects to the company WiFi providing threat actors a window into your network.
After working through your chosen risk framework, establish a cadence for revisiting the risk assessment process, updating previous documentation with new risks and the controls put in place to remediate them. Create a process to assess future vendors, based on what you learn through this process. Fold TPRM into your regular risk assessment and risk management activities.
Identifying all third-party risks is a challenging endeavor, so you should plan how to respond if one of your third-party vendors is breached. Ensure that your contracts include breach notification language. Establish contingency plans, including business continuity and breach response. Finally, consider how you will communicate a breach to the public, should that be required.
.svg)
