Managing Remote Access for Partners & Contractors

Published: 2020-09-29
Last Updated: 2020-09-29 11:00:55 UTC
by Xavier Mertens (Version: 1)
1 comment(s)

Yesterday, I wrote a quick diary about a potential security issue that some Tyler customers faced[1]. Some people reacted to my diary with interesting comments in our forums. Two of them were interesting and deserve some review.

« Sometimes their techs will install the Bomgar jump client on your servers when they are troubleshooting issues. They don't remove it, it is left to the local entity to remove it or at least disable the service until it is needed again. »


« A lot of vendors, especially in the local government sector expect customers to install these clients and leave them on. They are truly offended when you tell them no, same on the SCADA side of things. »

When you are outsourcing some tasks to a third-party (read: an MSSP, an integrator, ...), it’s very important to keep an eye on what they do and how they do it.

The installation of remote access tools (some of them are very close to a malicious backdoor) or specific accounts is a key point to allow them to perform their day-to-day job. But it does not mean that they can do whatever they want. When I read « it is left to the local entity to remove it or, at least, disable it », it means that a process must be implemented to follow this. The main risks are to detect an attacker using the third-party network to pivot into your organization or to detect their credentials used by attackers from unknown locations. That’s why Tyler asked its customers to reset all passwords related to their remote activities.

Here are some tips to increase the operations security when working with third-parties.

  1. Know « who’s behind the keyboard ». Are the third-party employees on the payroll, dedicated to you (read: they know you and your business). Are they also contractors? Are they located in the same country as yours?
  2. When it's not mandatory, do not keep the remote access open 24x7. All access requests must be approved following a procedure.
  3. Do not grant full access to your infrastructure. Restrict the third-party rights to the minimum resources to perform its job (least privilege). Keep segmentation in mind. Restrict its access to a jump host that will be used to enforce more security controls.
  4. Keep logs of who did what, when, why, and from where. Log everything, all connections, all commands. 
    Example: Detect an unforeseen connection from an unusual location outside the business hours.
  5. Keep an inventory of your partners and installed software. Force them to upgrade them and audit the settings.
  6. Enable security settings available in the deployed tools
    Example: Enable MFA, activate client-side certificates, provide security tokens.

Finally, don’t be afraid to say « No » and explain why you don’t agree with their requirements. They will work on YOUR platform which hosts YOUR data. You’ll be responsible in case of a data breach!

This list is not exhaustive. If you've implemented other specific controls when working for third-party organizations, please share!


Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant

1 comment(s)


Sysmon & Auditd are your friends.

Periodic automated checksum of every small or vaguely code-like file, over the whole filesystem. Check everywhere for weirdness. Build a tight exclusion list if you need to.

Likewise for automated Registry audits....

Determine what normal looks like, and baseline using it, then check the baseline makes sense!

The first step to knowing what good looks like, is knowing what normal looks like.

Diary Archives