Vendors. Supply chain partners. Third parties. Contractors. All are different names for entities that might need access to your corporate networks and systems. But they have one important thing in common: They are outsiders to your company. We are supposed to trust these outsiders to do the work they were hired for, which often requires remote access into our most critical and sensitive systems. They might be working on mission-critical servers or be accessing data that is covered by various regulations such as PHI or PII. But before we hand these folks the keys to our IT kingdoms, we need to build a practice of verification to make sure that these outsiders are who are say they are and that they’re doing the things they are supposed to be doing.
I recommend the following verification processes to solidify your trust in third parties with remote access.
How do you vet the employees of third parties who need remote access to accomplish some task, either ongoing or one-time? This might be for a contractor coming in to do development work every day or a support rep for a vendor requesting ad hoc access for an urgent maintenance task or a system down situation. Keep in mind, a sense of urgency is often the method used by hackers to get internal employees to let their guard down and let them in. And in some cases, they could be letting the fox into the henhouse.
To properly enroll a third-party for remote access, there must be some form of onboarding process wherein their employment status and authorization to do the work is verified. This can be done the old-school way, with forms filled out or with some sort of automated system. However you do it, make sure your process is documented and airtight; otherwise, you are open to a third-party compromise.
Verify Controls and Access Requirements
Once you’ve gotten the third party in and verified, you need to grant them access. Here, the principle of “least privilege” is paramount, even more so than for internal employees. Often vendors are giving a VPN connection with fairly open network permissions and then credentials on each server they need to work on. This two-part process is both insecure and inefficient. Ideally, never give third-parties wide open VPN access, but rather lock it down by specific server and specific ports. If you have a privileged access management (PAM) or vendor privileged access management (VPAM) system to vault the most sensitive credentials and pass them to the application, hidden from the vendor user, even better. This prevents credential reuse and theft.
Even when vendors are identified and authorized for the right purposes and resources, you still want to keep a close eye on all of your external visitors. Keeping an audit of third-party access, as detailed as possible, will help you keep your third parties in line and catch a problem before it becomes an incident. And, if an incident does happen, granular logs are your only hope of being able to perform accurate forensics to sort out what happened and figure out who the bad actors were so you can take any legal action needed.
In terms of what constitutes a detailed audit, your typical VPN or firewall logs aren’t going to be enough. They will only tell you who entered your network, when and for how long. You really need context around each vendor access session—things such as the reason for the access, who approved it, any ticket numbers or cases, or other supporting documentation. A true remote session management tool such as those found in most PAM and VPAM solutions will actually keep keystroke logs for command-line applications and full video captures of graphical sessions so that you can see the actions taken and commands issued. This can really make the difference when trying to catch a cyber crook and put the pieces back together afterward.
Finally, when a vendor rep is gone from a third-party vendor, it is very important to have a solid and quick system from getting their access purged from your systems. The longer these no longer valid credentials stay usable, the greater the chance there is that either they will be abused by a disgruntled former employee or stolen for use by a hacker group. If you have a multistep process, it will be more difficult to get this done efficiently and completely. The VPN access plus the individual server credentials process mentioned earlier is an example of this: How can you be sure of all of the systems that they had access to if you don’t have a centralized system for tracking it? Also, how quickly you are notified of terminations by the vendor greatly affects your vulnerability window. Even if you have a centralized system, if the vendor only syncs with you once a month, that credential is exposed for that period of time. A real-time or near-real-time process that syncs with the vendors’ employment processes is the ideal here—again, automated so you don’t have to count on human or paper-based systems.
So, in this era of outsourcing and specialization, most companies have multiple vendors handling tasks that require giving outsiders access to their internal networks and systems. This is a fact of life in modern corporate IT. However, if you don’t add the proper verification steps, you could end up with a lot of outside parties doing important tasks on your systems and sensitive data with few controls on their access or actions. But by implementing a few of the best practices controls listed above and implementing technical solutions to back them up, then and only then can you truly trust outsiders on your networks.
— Tony Howlett