The Vendor Laptop Is on Your Network Now

The drive technician arrived, plugged a laptop into the switch in the pump panel, fixed the drive parameter that had been causing the trips, and left. It was a good service call. A week later the operator found a remote access tool running on the SCADA server, installed by the same technician to finish the job from the road, with a password the technician had picked and the utility did not know. The tool was not malicious. It was also a door into the plant, held open by someone who was no longer thinking about it, on a server the utility believed was reachable only from inside. Nothing about the story is unusual except that the operator noticed.

What a connected laptop is

When a laptop joins the control network it becomes a device on that network, with whatever reach the network gives it. On a flat network that is every controller and server on the site. The laptop has been on other networks that week, some of them at plants with less discipline than yours, and it carries whatever it picked up. It has programming software with the ability to change every controller it can see, and a technician under time pressure who will use the shortest path. None of that makes the vendor the enemy. Vendors fix things a utility cannot fix itself. It makes the laptop a risk to be managed, the same way a contractor's excavator is managed near a buried main: with a rule about where it may dig.

Before

The utility decides where a vendor connects. That is a labeled maintenance port, or a designated switch port, on a VLAN whose firewall rule reaches the device the vendor is there to work on and nothing else. If the plant is still flat, the interim version is a port on the panel of the device in question and a technician standing there. For remote work, the utility owns the access path: a VPN or a jump host with multi-factor authentication, an account for that vendor that is disabled between visits, and a session that a utility person enables for a stated window and closes afterward. Vendor-supplied remote tools, cellular modems in drive cabinets, and anything that phones home to the vendor's cloud are declined unless the utility has decided, in writing, to allow that one.

Before the vendor touches anything, the utility takes a backup of the device: the controller program, the drive parameters, the SCADA project. It takes five minutes, and it is the reference for everything that follows. The vendor is told what the job is, and that the job is the scope: a drive parameter fix is not an occasion to also update the firmware, tidy the ladder, or install a monitoring agent.

During

Someone from the utility is present, physically or on the session, and that person is entitled to ask what a step is for. A vendor who explains as they go is doing the utility a service twice, once by fixing the problem and once by teaching what the fix was. The vendor uses their own accounts where the system supports it, and never a shared plant password. Nothing from the laptop is copied onto a plant machine except the files the job needs, and nothing from the plant is copied off except what the vendor needs to do the job, which the utility agrees to. If the job turns out to need more than the scope, that is a conversation, not a decision the technician makes alone.

After

1. 1

   Compare

   Use the programming software to compare the controller, drive, or project against the backup taken before. Every difference is either the change the vendor came to make or a question to ask before the vendor leaves the parking lot.

2. 2

   Collect the files

   The modified program and parameter files go to the utility, named and dated, and into the utility's own backup. The vendor keeps a copy; the utility keeps the master.

3. 3

   Close the access

   Disable the vendor account, close the session, confirm that no remote tool, service, or scheduled task remains on any plant machine. Look; do not ask.

4. 4

   Record it

   A change record with the date, the vendor, the device, what changed and why, and the compare result. One page, in the same place as the drawings.

5. 5

   Watch for a week

   Trend the device that was changed. A parameter fix that solved one problem occasionally introduces another, and the change record is where the next technician will look first.

The conversation

Vendors who serve water utilities have been hearing this for years, from the larger utilities first and now from everyone, and most have their own policies that already forbid their technicians from installing remote tools on customer systems. The way to have the conversation is to send the policy with the purchase order, ask the vendor for theirs, and let the two meet. A vendor who says that the rules make the work impossible is usually saying that they are used to working without oversight, and that is exactly the condition the rules exist to end. The rare vendor who will not work under a utility's access policy is a vendor the utility has learned something important about at low cost.

The principle under all of it

The utility owns the control system: the programs, the configuration, the access, and the record of change. A vendor is a guest with skills, welcome and paid, who works inside rules the owner sets. Every item above is an expression of that one idea, and a utility that holds to it will find that its systems are documented, its backups are current, and its doors are closed, not because of a security project but because that is what ownership looks like day to day.