Third-party risk management has become a big thing in IT and security circles. Everybody is talking about it and it seems like everyone is trying to do it; there’s even an acronym for it, TPRM, which is the sure sign that a thing is a “thing” in IT.
However, TPRM and other related activities like risk assessments and risk management, in general, can often seem like a dry abstract topic; full of risk weighting, applying probability percentages to likelihoods, and theoretical impacts of occurrences. It’s easy to see the discipline as just a bunch of numbers and statistics. But at the heart of third-party risk are people. And if you don’t understand the all-important human element as an underlying cause of third-party risk, you will have a harder time coming up with protections and controls to reduce third-party risk on your networks and systems.
Defining the human factor of TPRM
While there are certainly other factors involved in managing third-party risk (technical issues, vendor problems, etc.), the human factor is a big one. Let’s start with the fact that you simply don’t know as much about this set of humans (vendor reps, partners, etc.) as you do your employees. When you give your internal staff remote access, you generally know that HR has done their due diligence on them, via background checks, drug screens, reference checks, or whatever processes your company employs. You also have a work history with these folks, so you hopefully know they are trustworthy when provided with external keys to your network and systems. You wouldn’t give an admin password to a first-day internal hire, so why are you giving them to external vendors? They may have been hired yesterday or be a long term employee. They may be highly qualified for the job they do inside your network or they may be a trainee, learning on the job and on your critical systems.
Now, most vendor employees are skilled and qualified for the job. A vendor wouldn’t keep you as a customer for long if they consistently provided techs without the appropriate skills, but if their vetting processes arent as strict as your own, sometimes an incompetent or malicious individual can slip through those cracks. That is why the risk of a vendor employee on your networks is substantially higher than one of your own. You need to treat remote access for vendors differently than remote access for employees. One way this can be done is through designing robust onboarding and offboarding processes with additional checks, as well as using technical controls to ensure that your vendor’s employees stay in their lanes and don’t get themselves or you in trouble.
It is human nature, that’s at the root of almost all third-party risk. First of all, laziness, one of the seven deadly sins, is a major culprit. Shared credentials is one example of this. When a company has many support reps, it can become an administrative nightmare to get them all individual credentials. And on the company side, entering all those people into an internal Active Directory can be a full-time task. Often the path of least resistance kicks in with a vendor being assigned a single company-wide credential. This is bad for so many reasons; first of all, it generates compliance risk by taking you out of compliance with most current security frameworks. But, it also greatly increases the risk of a credential compromise since it will be used by so many people and passed around on vendor email systems or bulletin boards. The only way around this is a well-designed workflow process both for onboarding and offboarding vendors. Ideally, this process would be automated and be as self-service as possible to make it efficient. The best cure for laziness is to make the proper processes easy for people. Do that and they will make it easy for you to reduce third-party risk.
They say that to err is human. And that part of human nature is another third-party risk that is hard to control. An incompetent vendor rep can do more damage in your key systems than a hacker if they know just enough to be dangerous. An overly confident database admin can corrupt or wipe out years worth of data. Overeager reps can screw up a config file and then lock themselves out, leaving local internal staff to pick up the pieces.
Even a competent rep can cause issues if they are allowed too many choices and end up rebooting or upgrading servers that were out of scope for their work. You can’t make your vendor train their employees better, but having a very granular access log, ideally with video captures or keystroke logs of vendor’s sessions can allow your King’s men to put Humpty Dumpty back together again if a vendor pushes him off the wall.
Finally, the worst parts of human nature, greed and avarice, can come into play if you have a vendor rep who decides, for whatever reason, to act maliciously on your network. He or she may be actively in the pay of a cybercriminal group or more likely, a disgruntled former employee who might want to cause trouble for their erstwhile employer by messing with their customers. Either way, these “human elements” can cause catastrophic damage if allowed to run free inside your systems with privileged credentials. There are several things you can do to stop or limit damage from this risk.
First of all, a robust and near real-time offboarding process is necessary to remove access for former vendor reps as soon as possible. If you are using shared credentials, obviously this becomes difficult or impossible. Using multi-factor authentication and obfuscated credentials, as is available in most Privileged Access Management (PAM) and Vendor Privileged Access Management (VPAM) systems can prevent them from using credentials to your systems that they took with them from a vendor. And finally, having detailed audit logs of remote access activity, especially from third parties, can allow you to catch such activity early on and greatly limit the damage that can be done by these third-party bad actors.
Understand your risks from all angles
So, as you can see, managing third-party risks has a large human element to it. It is impossible to completely eliminate the risk as long as there are humans involved in your third parties (the perfect AI support bot has not been developed yet and probably never will be). However, with the right upfront processes and procedures, backed up with strong technical controls such as PAM and VPAM can go a long way to limit your exposure to human-generated third-party risk.
Not only are humans a risk to your third-party risk management plan, but so are your tools. Whether you’re using a VPN, a vendor-supplied support tool, or a Privileged Access Management (PAM) solution to manage network vendor access, the limitations of those tools leave you vulnerable to breaches. Download our brochure that highlights the importance of having a separate software platform specifically to manage vendors’ privileged access to systems, networks, and applications.