How to deal with suppliers VPN device?

We have a lot of suppliers (production facility) wo want to remote control their equipment. Mostly they use small vpn devices in their cabinet like IXON, eWon , Cisco Meraki or Secomea.

We are used to give these devices internet access so they can reach their internallnstuff behind the device.

What are your best practices to do this safely? Do you have a specific vlan to store these vpn appliances?

Indeed, putting the equipment along with their VPN device in a separate VLAN (and configuring appropriate ACLs) is the right way to do this.

My $0.02…

Dedicated VLAN with explicit egress routing rules to block everything except whitelisted destinations nominated by the vendor (ideally, single IP or Host target)

Intra-VLAN routing only to explicit hosts that have been nominated by the business.

Additional evidence from the vendor to provide copy of current Cyber insurance and last security assessment.

Where possible, request they forward syslog from the on-prem device(s) to your SIEM (assumption is you’ll be monitoring your network infra syslog already).

At a minimum - In their own vlan with firewall rules to only allow the essential traffic required.

Ideally - in their own VRF to fully isolate them from the wider network.

Isolated Subnet , Supplier accounts are enabled on an as needed basis

We just give the maintenance department a 4G portable router/modem and they can plug it into the uplink port on them when the PLC guy needs access. Which is really pretty rarely after in working.

Our intended policy is to allow integrators full reign on the isolated LAN, with just two restrictions: no RF, and no remote access. We’ve found that at least half of them push hard against these reasonable requests, while taking the remainder of our hands-off approach for granted.

In principle, remote access is either for monitoring, or for making changes, or for both. Monitoring is more than reasonable, but we need that to happen over a read-only push mechanism in most cases. Outbound MQTT or HTTP(S) REST are good choices.

Changes, well – changes need to go through change control, don’t they? It’s probably a good idea if the vendor can’t make random changes on a Sunday afternoon, right?

Having these respectful discussions isn’t as productive as you’d think. What’s been productive is to use the Target breach from years ago, as leverage to push back against remote access, and push for logging/auditing not under control of the supplier.

Say no, then provide them the company’s standard remote access solution. All remote access goes through our official solutions.

For my company, these systems are typically air-gapped, so I just maintain the separation using VLANs and sometimes entirely separate connections. On the firewall, I can often limit the connection to a specific IP range.

If we can’t manage it then it’s going on it’s own VLAN, that being said we are able to grant vendors access to a majority of devices utilizing SecureLink (SSH, RDP) so we don’t have to open them up to the internet except for necessary traffic.

Sir. You don’t know my factory. Berkoa and Robot techs are in our machines every few days.

How many remote access boxes are we talking about? Handful just do a vlan per device. More than that I’d look at a IoT type vlans with port isolation.

About a dozen. We are upgrading a factory in Canada next summer. I wasn’t here for the US factory mentioned above when it was installed. I’m going to set some restrictions and good practices with Canada facility then come back and make them match the same in US after. It’s easier to do it this way than to beg maintenance to change things “randomly”.