Qué vas a conseguir
Conectar la red de una planta con la corporativa de forma que el negocio vea los datos de producción y los proveedores puedan dar soporte, sin que un cambio pensado para las oficinas llegue a una línea. En la parte de oficinas, un error se arregla con un reinicio; en la planta, un PLC que deja de recibir órdenes para la línea, y una hora de línea parada se mide en piezas que no salen. La regla de toda la guía: en OT manda la disponibilidad, y cualquier cosa que IT haga en la planta se acuerda antes con el jefe de planta y con el responsable de automatización.
Antes de empezar
- El responsable de OT o de automatización de cada planta y el jefe de planta: son quienes deciden cuándo se toca algo. Sin ellos no se empieza.
- Los planos de red de la planta, aunque estén desactualizados, y las listas de equipos que entregaron los integradores y fabricantes de cada línea.
- El calendario de paradas planificadas de producción del año: es tu calendario de ventanas.
- Los contratos de soporte de los fabricantes (SCADA, PLC, robots) y qué acceso remoto exige cada uno.
- Acceso de lectura al firewall entre IT y la planta y a los switches de la red de planta.
1. Inventario de activos OT sin escanear
En OT no se lanza un escaneo de red para "ver qué hay". Un barrido de puertos o un escáner de vulnerabilidades puede colgar un PLC antiguo o un panel de operador, y eso es una línea parada. El inventario se construye con fuentes que no tocan los equipos:
- Listas de los fabricantes e integradores: cada línea se entregó con su documentación (as-built): modelos, firmware, direcciones IP.
- Recorrido físico por los armarios con el responsable de automatización: etiquetas, modelos, qué está conectado a qué.
- Tablas de los switches de planta: leer la tabla de direcciones MAC y la tabla ARP del switch es pasivo para los equipos conectados.
- Una sonda pasiva de OT conectada a un puerto SPAN (espejo) del switch: escucha el tráfico, reconoce protocolos industriales (Modbus TCP, EtherNet/IP, S7, OPC UA) y deduce qué es cada equipo sin enviarle nada.
show mac address-table vlan 120 Mac Address Table-------------------------------------------Vlan Mac Address Type Ports---- ----------- -------- ----- 120 0008.dc2a.11f0 DYNAMIC Gi1/0/3 120 001d.9c4b.07a2 DYNAMIC Gi1/0/5 120 5cf8.21e4.9b10 DYNAMIC Gi1/0/12show ip arp vlan 120Si alguien propone "un escaneo suave" en producción, la respuesta es no. Los escaneos activos, si hacen falta, se hacen en una parada planificada, con el responsable de automatización delante y equipo a equipo.
Cada activo va a una ficha con lo mismo en todas las plantas:
| Campo | Ejemplo |
|---|---|
| Nombre y tipo | L2-PLC-01 · PLC de la línea 2 de envasado |
| Fabricante, modelo y firmware | Los de la placa y del proyecto del integrador |
| IP, MAC y VLAN | 10.40.20.15 · VLAN 120 |
| Nivel Purdue y zona | Nivel 1 · Zona Línea 2 |
| Sistema operativo (si es un PC) | Windows 10 IoT Enterprise LTSC en un HMI |
| Responsable y soporte | Responsable de automatización · contrato con el integrador |
| Dónde está su copia | Repositorio de proyectos de PLC, versión y fecha |
La CMDB es el sitio natural para estas fichas, con una clase propia para activos OT.
2. Niveles Purdue, zonas y conductos
El modelo Purdue ordena la planta por capas, de la máquina al ERP:
| Nivel | Qué hay | Ejemplos |
|---|---|---|
| 0 | El proceso físico | Sensores, motores, válvulas |
| 1 | Control básico | PLC, variadores, controladores de seguridad |
| 2 | Supervisión de la línea | HMI, servidor SCADA de la línea |
| 3 | Operaciones de la planta | Historian, MES, estaciones de ingeniería, servidores de la planta |
| 3.5 | DMZ industrial | Réplica del historian, jump host, relé de parches y antivirus |
| 4 y 5 | Red corporativa e Internet | ERP, correo, puestos de oficina |
La norma IEC 62443 (en concreto la parte 3-2) añade dos ideas sencillas:
- Una zona es un grupo de equipos con las mismas necesidades de seguridad: por ejemplo, todo lo de la línea 2 (sus PLC, sus HMI y su SCADA). Lo que pasa dentro de una zona no afecta a otra.
- Un conducto es el único camino permitido entre dos zonas, con lo que puede pasar por él: quién, hacia dónde, qué protocolo y en qué sentido.
En la práctica: una VLAN y un segmento por zona, un firewall entre zonas y una lista de conductos aprobada por OT. Si dos equipos de zonas distintas hablan, lo hacen por un conducto que alguien ha documentado.
3. La DMZ industrial
La regla de oro: ninguna conexión cruza directamente de la red corporativa a la planta. Todo termina en la DMZ industrial (nivel 3.5) y desde ahí se sirve o se reenvía:
- Réplica del historian: el historian de la planta (nivel 3) envía sus datos a una réplica en la DMZ. Los usuarios de oficina y los informes consultan la réplica, nunca el historian de la planta.
- Jump host: el único punto de entrada para administrar o dar soporte a equipos de la planta. Se entra con MFA y desde ahí, solo a los equipos autorizados.
- Relé de parches y antivirus: un servidor WSUS y el servidor de distribución del antivirus en la DMZ. Los equipos de la planta descargan de ahí, no de Internet ni de los servidores corporativos.
- Intercambio de ficheros: si producción necesita recibir recetas u órdenes en fichero, una carpeta en la DMZ con análisis antivirus, no un recurso compartido de la oficina mapeado en un HMI.
Los equipos de la planta no deberían estar en el dominio corporativo. Si lo están, en una OU propia que bloquea la herencia y con GPO pensadas para OT; la guía de GPO de seguridad se aplica a oficinas, y sus directivas solo llegan a OT tras probarlas con el fabricante.
4. Reglas del firewall por conducto
Cada regla del firewall corresponde a un conducto de la lista, con su número de cambio en el comentario. Un ejemplo de la planta de Northwind en Zaragoza:
| Conducto | Origen | Destino | Servicio | Sentido |
|---|---|---|---|---|
| C-01 Historian | Historian planta 10.40.30.10 | Réplica DMZ 10.40.35.10 | El puerto que documente el fabricante del historian | Planta → DMZ |
| C-02 Informes | Red corporativa | Réplica DMZ 10.40.35.10 | HTTPS 443 | Corporativa → DMZ |
| C-03 Soporte | Red corporativa y proveedores (VPN) | Jump host 10.40.35.20 | HTTPS 443 (RD Gateway) | → DMZ |
| C-04 Administración | Jump host 10.40.35.20 | Estaciones de ingeniería 10.40.30.21-22 | RDP 3389 | DMZ → Planta |
| C-05 Parches | Servidores y HMI de la planta | WSUS DMZ 10.40.35.30 | HTTPS 8531 | Planta → DMZ |
| C-06 MES | MES 10.40.30.20 | SCADA línea 2 10.40.20.10 | OPC UA 4840 | Nivel 3 → Nivel 2 |
| Final | Cualquiera | Cualquiera | Todo | Denegado y registrado |
- Nada de reglas any hacia la planta ni de objetos compartidos con reglas de oficinas: los objetos de OT se nombran
OT-...y solo se usan en reglas de OT. - Los protocolos industriales (Modbus TCP 502, EtherNet/IP 44818, S7 102) no deberían cruzar de la red corporativa a la planta. Si alguno cruza, es un conducto que hay que revisar.
- Las reglas de la planta no entran en las "limpiezas de reglas sin uso": un conducto que se usa una vez al mes en un cambio de formato sigue siendo necesario.
La guía de FortiGate explica cómo escribir estas políticas con mínimo privilegio.
5. Acceso remoto de proveedores
El fabricante del SCADA o el integrador de la línea necesitan entrar para dar soporte. El acceso se da siempre por el mismo camino:
- Una cuenta por persona del proveedor, nunca una cuenta compartida "proveedor-scada", y deshabilitada por defecto.
- Entrada por VPN o portal con MFA, solo hasta el jump host.
- Aprobación de la sesión: el proveedor la pide con un ticket; el responsable de automatización la aprueba para una ventana concreta (por ejemplo, de 14:00 a 16:00) y solo hacia los equipos de esa línea.
- Desde el jump host, solo los destinos de su conducto. Las sesiones se graban si la herramienta lo permite.
- Al acabar, la cuenta vuelve a deshabilitarse y el ticket recoge qué se hizo.
Los módems 4G o los programas de control remoto que algunos integradores dejan instalados "para soporte" saltan todo lo anterior. En el recorrido del inventario, búscalos y quítalos con el responsable de la planta.
Si la empresa ya tiene una herramienta de cuentas privilegiadas, como en la guía de CyberArk, las cuentas de proveedores de OT van en un safe propio con sesiones grabadas.
6. Parches y antivirus en ventanas de parada
- Solo en paradas planificadas, acordadas con el jefe de planta: nunca durante la producción, aunque el parche sea "solo de seguridad".
- Lista de compatibilidad del fabricante: los fabricantes de SCADA publican qué actualizaciones de Windows y qué versiones de antivirus han validado con su software. Lo que no está en la lista, no se instala.
- Primero en un equipo de pruebas: un HMI o una estación de repuesto con la misma imagen.
- Copia antes de tocar: imagen de los servidores SCADA y de las estaciones de ingeniería con la restauración probada.
- Antivirus: firmas desde el relé de la DMZ con un retraso (por ejemplo, 24 horas detrás de las oficinas), exclusiones que indica el fabricante y análisis completos programados solo en paradas. En equipos que no admiten antivirus, control de aplicaciones (lista blanca).
En el calendario de paradas, cada ventana tiene su lista: qué equipos, qué parches, quién de OT valida que la línea arranca y cuál es la vuelta atrás.
7. Copias de los programas de PLC
Si un PLC se avería o alguien borra parte de su programa, la línea no arranca hasta que se recarga. Sin copia, hay que pedirla al integrador, que quizá ya no la tenga.
- El responsable de automatización saca la copia con el software de ingeniería del fabricante (subida del programa desde el PLC) después de cada cambio y, como mínimo, cada trimestre.
- IT pone el repositorio: una carpeta en un servidor de la planta, con versiones, acceso solo para automatización y copia a otra ubicación.
- Cada copia con su ficha: PLC, versión, fecha, quién y por qué (cambio de receta, mejora, corrección).
- Comprobar de vez en cuando que el programa del PLC coincide con la última copia: la herramienta de ingeniería permite comparar el programa del equipo con el del repositorio. Una diferencia es un cambio sin registrar.
8. El ticket: "la línea 2 se ha parado tras un cambio de IT anoche"
Martes, 6:20. El turno de mañana avisa: la línea 2 de envasado está parada. El SCADA de la línea no recibe las órdenes del MES y los paneles de operador muestran que no hay orden de fabricación activa. Anoche hubo cambios de IT.
- Primero, la línea: con el jefe de turno y el responsable de automatización. Ellos deciden si la línea puede trabajar en modo local mientras se investiga. Nadie de IT toca un PLC ni un HMI sin ellos.
- Qué cambió anoche: el calendario de cambios muestra dos candidatos: una limpieza de objetos del firewall a las 23:00 y la actualización mensual de la GPO de seguridad con nuevas firmas de antivirus a medianoche.
- El firewall: una traza del tráfico del MES hacia el SCADA de la línea 2:
diagnose debug flow filter addr 10.40.20.10diagnose debug flow show function-name enablediagnose debug enablediagnose debug flow trace start 10id=65308 trace_id=1 func=print_pkt_detail line=5911 msg="vd-root:0 received a packet(proto=6, 10.40.30.20:52814->10.40.20.10:4840) tun_id=0.0.0.0 from port7. flag [S], seq 3021457710, ack 0, win 64240"id=65308 trace_id=1 func=fw_forward_handler line=1015 msg="Denied by forward policy check (policy 0)"diagnose debug disableEl tráfico del conducto C-06 cae en la política 0, la denegación implícita. En Log & Report › System Events, el registro de anoche dice que se editó el grupo de direcciones GRP-SERVIDORES-MES, compartido por una regla de oficinas y por la del conducto C-06, y se quitó el MES de la planta al "limpiar servidores antiguos".
Vuelta atrás: devolver el miembro al grupo, con un cambio de emergencia aprobado por el responsable de OT. La lista de revisiones de la configuración (Configuration › Revisions, en el menú del administrador) sirve para comparar el antes y el después; restaurar una revisión completa reinicia el equipo y deshace todo lo de la noche, así que se corrige el objeto, no la configuración entera.
Si el firewall está bien, la GPO o el antivirus: en un HMI, con el responsable de automatización:
gpresult /scope computer /rGet-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 20 | Where-Object Id -in 1116,1117 | Select-Object TimeCreated, Id, Message& "C:\Program Files\Windows Defender\MpCmdRun.exe" -Restore -ListAllSi gpresult muestra una GPO de oficinas aplicada al HMI, la OU de la planta no bloqueaba la herencia; si los eventos 1116 y 1117 muestran que el antivirus puso en cuarentena un componente del software del SCADA, se restaura con MpCmdRun.exe -Restore -Name <nombre>, se añade la exclusión del fabricante y se para la distribución de esas firmas a la planta.
Comprobación: la línea vuelve a recibir órdenes y el responsable de automatización da por buena la producción. Hasta entonces el ticket no se cierra.
Para que no se repita, el control de cambios incluye a OT:
- Todo cambio que toque una zona OT, un objeto usado en un conducto, una GPO que llegue a equipos de la planta o el antivirus de la planta necesita la aprobación del responsable de OT en el comité de cambios.
- Los activos y conductos de OT están en la CMDB, así que el análisis de impacto de un cambio los ve.
- Objetos del firewall propios de OT, sin compartir con oficinas.
- Firmas y parches a la planta por el relé de la DMZ, con retraso y tras un equipo de pruebas.
En el ticket: hora de la parada, cambio causante, vuelta atrás, hora de recuperación de la línea y las acciones preventivas, con su responsable.
Siguientes pasos
- La guía de LAN, WAN y WiFi entre plantas cubre la red de cada sede en la que se integra la red de planta.
- La de Defender Antivirus y reglas ASR explica las exclusiones y el modo auditoría antes de aplicar nada a un equipo de OT.
- La de DR/BCP sirve para dar a cada línea su RTO y probar la recuperación del SCADA y del historian.
- La de mantenimiento de VMware cubre los servidores virtuales de la planta y su calendario según los turnos.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
Connecting a plant's network to the corporate one so the business can see production data and vendors can give support, without a change meant for the offices reaching a line. On the office side, a mistake is fixed with a reboot; in the plant, a PLC that stops receiving orders stops the line, and an hour of a stopped line is measured in parts that don't ship. The rule for the whole guide: in OT, availability comes first, and anything IT does in the plant is agreed beforehand with the plant manager and the automation lead.
Before you start
- Each plant's OT or automation lead and the plant manager: they decide when something is touched. Without them, nothing starts.
- The plant's network drawings, even if they're out of date, and the equipment lists delivered by each line's integrators and vendors.
- Production's planned shutdown calendar for the year: it's your calendar of windows.
- The vendors' support contracts (SCADA, PLCs, robots) and the remote access each one requires.
- Read access to the firewall between IT and the plant and to the plant network switches.
1. Inventorying OT assets without scanning
In OT you don't run a network scan "to see what's there". A port sweep or a vulnerability scanner can hang an old PLC or an operator panel, and that's a stopped line. The inventory is built from sources that don't touch the devices:
- Vendor and integrator lists: each line was handed over with its documentation (as-built): models, firmware, IP addresses.
- A physical walkdown of the cabinets with the automation lead: labels, models, what is connected to what.
- The plant switches' tables: reading the switch's MAC address table and ARP table is passive for the connected devices.
- A passive OT sensor connected to a SPAN (mirror) port on the switch: it listens to traffic, recognises industrial protocols (Modbus TCP, EtherNet/IP, S7, OPC UA) and works out what each device is without sending it anything.
show mac address-table vlan 120 Mac Address Table-------------------------------------------Vlan Mac Address Type Ports---- ----------- -------- ----- 120 0008.dc2a.11f0 DYNAMIC Gi1/0/3 120 001d.9c4b.07a2 DYNAMIC Gi1/0/5 120 5cf8.21e4.9b10 DYNAMIC Gi1/0/12show ip arp vlan 120If someone suggests "a gentle scan" in production, the answer is no. Active scans, if needed, are done in a planned shutdown, with the automation lead present and one device at a time.
Each asset gets a record with the same fields in every plant:
| Field | Example |
|---|---|
| Name and type | L2-PLC-01 · PLC for packaging line 2 |
| Vendor, model and firmware | From the nameplate and the integrator's project |
| IP, MAC and VLAN | 10.40.20.15 · VLAN 120 |
| Purdue level and zone | Level 1 · Line 2 zone |
| Operating system (if it's a PC) | Windows 10 IoT Enterprise LTSC on an HMI |
| Owner and support | Automation lead · contract with the integrator |
| Where its backup is | PLC project repository, version and date |
The CMDB is the natural home for these records, with its own class for OT assets.
2. Purdue levels, zones and conduits
The Purdue model arranges the plant in layers, from the machine to the ERP:
| Level | What's there | Examples |
|---|---|---|
| 0 | The physical process | Sensors, motors, valves |
| 1 | Basic control | PLCs, drives, safety controllers |
| 2 | Line supervision | HMIs, the line's SCADA server |
| 3 | Plant operations | Historian, MES, engineering workstations, plant servers |
| 3.5 | Industrial DMZ | Historian replica, jump host, patch and AV relay |
| 4 and 5 | Corporate network and Internet | ERP, email, office desktops |
The IEC 62443 standard (specifically part 3-2) adds two simple ideas:
- A zone is a group of devices with the same security needs: for example, everything on line 2 (its PLCs, HMIs and SCADA). What happens inside one zone doesn't affect another.
- A conduit is the only allowed path between two zones, with what may travel through it: who, to where, which protocol and in which direction.
In practice: one VLAN and segment per zone, a firewall between zones and a list of conduits approved by OT. If two devices in different zones talk, they do it through a conduit someone has documented.
3. The industrial DMZ
The golden rule: no connection crosses directly from the corporate network to the plant. Everything ends in the industrial DMZ (level 3.5) and is served or forwarded from there:
- Historian replica: the plant historian (level 3) sends its data to a replica in the DMZ. Office users and reports query the replica, never the plant historian.
- Jump host: the only entry point for administering or supporting plant devices. You sign in with MFA and from there reach only the authorised devices.
- Patch and antivirus relay: a WSUS server and the antivirus distribution server in the DMZ. Plant devices download from there, not from the Internet or from the corporate servers.
- File exchange: if production needs to receive recipes or orders as files, a folder in the DMZ with antivirus scanning, not an office share mapped on an HMI.
Plant devices shouldn't be in the corporate domain. If they are, they go in their own OU that blocks inheritance, with GPOs designed for OT; the security GPOs guide applies to offices, and its policies only reach OT after testing them with the vendor.
4. Firewall rules per conduit
Each firewall rule matches a conduit on the list, with its change number in the comment. An example from Northwind's plant in Zaragoza:
| Conduit | Source | Destination | Service | Direction |
|---|---|---|---|---|
| C-01 Historian | Plant historian 10.40.30.10 | DMZ replica 10.40.35.10 | The port the historian vendor documents | Plant → DMZ |
| C-02 Reports | Corporate network | DMZ replica 10.40.35.10 | HTTPS 443 | Corporate → DMZ |
| C-03 Support | Corporate network and vendors (VPN) | Jump host 10.40.35.20 | HTTPS 443 (RD Gateway) | → DMZ |
| C-04 Administration | Jump host 10.40.35.20 | Engineering workstations 10.40.30.21-22 | RDP 3389 | DMZ → Plant |
| C-05 Patching | Plant servers and HMIs | DMZ WSUS 10.40.35.30 | HTTPS 8531 | Plant → DMZ |
| C-06 MES | MES 10.40.30.20 | Line 2 SCADA 10.40.20.10 | OPC UA 4840 | Level 3 → Level 2 |
| Final | Any | Any | All | Denied and logged |
- No any rules towards the plant and no objects shared with office rules: OT objects are named
OT-...and only used in OT rules. - Industrial protocols (Modbus TCP 502, EtherNet/IP 44818, S7 102) shouldn't cross from the corporate network to the plant. If one does, it's a conduit to review.
- Plant rules are left out of "unused rule clean-ups": a conduit used once a month for a product changeover is still needed.
The FortiGate guide explains how to write these policies with least privilege.
5. Vendor remote access
The SCADA vendor or the line integrator need to connect to give support. Access is always given the same way:
- One account per person at the vendor, never a shared "vendor-scada" account, and disabled by default.
- Entry through VPN or a portal with MFA, only as far as the jump host.
- Session approval: the vendor requests it with a ticket; the automation lead approves it for a specific window (for example, 14:00 to 16:00) and only towards that line's devices.
- From the jump host, only the destinations in its conduit. Sessions are recorded if the tool allows it.
- When finished, the account is disabled again and the ticket records what was done.
The 4G modems or remote control programs some integrators leave installed "for support" bypass all of the above. During the inventory walkdown, look for them and remove them with the plant manager.
If the company already has a privileged account tool, as in the CyberArk guide, OT vendor accounts go in their own safe with recorded sessions.
6. Patching and antivirus in shutdown windows
- Only in planned shutdowns, agreed with the plant manager: never during production, even if the patch is "security only".
- The vendor's compatibility list: SCADA vendors publish which Windows updates and antivirus versions they have validated with their software. What isn't on the list doesn't get installed.
- First on a test device: a spare HMI or workstation with the same image.
- Backup before touching: an image of the SCADA servers and engineering workstations with the restore tested.
- Antivirus: signatures from the DMZ relay with a delay (for example, 24 hours behind the offices), the exclusions the vendor specifies and full scans scheduled only in shutdowns. On devices that can't run antivirus, application control (allowlisting).
In the shutdown calendar, each window has its list: which devices, which patches, who from OT confirms the line starts and what the rollback is.
7. PLC program backups
If a PLC fails or someone deletes part of its program, the line doesn't start until it's reloaded. Without a backup, you have to ask the integrator, who may no longer have it.
- The automation lead takes the backup with the vendor's engineering software (uploading the program from the PLC) after every change and at least every quarter.
- IT provides the repository: a folder on a plant server, with versioning, access only for automation and a copy to another location.
- Each backup with its record: PLC, version, date, who and why (recipe change, improvement, fix).
- Check from time to time that the PLC's program matches the latest backup: the engineering tool can compare the program on the device with the one in the repository. A difference is an unrecorded change.
8. The ticket: "line 2 stopped after an IT change last night"
Tuesday, 6:20. The morning shift reports that packaging line 2 is stopped. The line's SCADA isn't receiving orders from the MES and the operator panels show no active production order. There were IT changes last night.
- The line first: with the shift lead and the automation lead. They decide whether the line can run in local mode while you investigate. Nobody from IT touches a PLC or an HMI without them.
- What changed last night: the change calendar shows two candidates: a firewall object clean-up at 23:00 and the monthly security GPO update with new antivirus signatures at midnight.
- The firewall: a trace of the traffic from the MES to the line 2 SCADA:
diagnose debug flow filter addr 10.40.20.10diagnose debug flow show function-name enablediagnose debug enablediagnose debug flow trace start 10id=65308 trace_id=1 func=print_pkt_detail line=5911 msg="vd-root:0 received a packet(proto=6, 10.40.30.20:52814->10.40.20.10:4840) tun_id=0.0.0.0 from port7. flag [S], seq 3021457710, ack 0, win 64240"id=65308 trace_id=1 func=fw_forward_handler line=1015 msg="Denied by forward policy check (policy 0)"diagnose debug disableConduit C-06 traffic hits policy 0, the implicit deny. In Log & Report › System Events, last night's log shows the address group GRP-SERVIDORES-MES was edited. It's shared by an office rule and by the C-06 conduit rule, and the plant MES was removed while "cleaning up old servers".
Rollback: put the member back in the group, with an emergency change approved by the OT lead. The configuration revision list (Configuration › Revisions, in the administrator menu) is useful to compare before and after; restoring a full revision reboots the unit and undoes everything from last night, so you fix the object, not the whole configuration.
If the firewall is fine, the GPO or the antivirus: on an HMI, with the automation lead:
gpresult /scope computer /rGet-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 20 | Where-Object Id -in 1116,1117 | Select-Object TimeCreated, Id, Message& "C:\Program Files\Windows Defender\MpCmdRun.exe" -Restore -ListAllIf gpresult shows an office GPO applied to the HMI, the plant OU wasn't blocking inheritance; if events 1116 and 1117 show the antivirus quarantined a component of the SCADA software, restore it with MpCmdRun.exe -Restore -Name <name>, add the vendor's exclusion and stop distributing those signatures to the plant.
Check: the line receives orders again and the automation lead signs off production. Until then the ticket isn't closed.
So it doesn't happen again, change control includes OT:
- Any change that touches an OT zone, an object used in a conduit, a GPO that reaches plant devices or the plant antivirus needs the OT lead's approval in the change board.
- OT assets and conduits are in the CMDB, so a change's impact analysis sees them.
- Firewall objects owned by OT, not shared with the offices.
- Signatures and patches reach the plant through the DMZ relay, with a delay and after a test device.
In the ticket: time of the stop, the change that caused it, the rollback, the time the line recovered and the preventive actions, each with an owner.
Next steps
- The LAN, WAN and Wi-Fi between plants guide covers each site's network that the plant network joins.
- The Defender Antivirus and ASR rules guide explains exclusions and audit mode before applying anything to an OT device.
- The DR/BCP guide helps give each line its RTO and test recovery of the SCADA and historian.
- The VMware maintenance guide covers the plant's virtual servers and their calendar around shifts.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →