forumAbrir tema

Tenemos sistemas SCADA en la línea de producción — ¿es obligatoria la prueba de penetración y en qué se diferencia de una normal?

LLale B***ParticipanteMiembro de la comunidad
Miembro desde
oct 2025
Mensaje
282
#1

Somos una fábrica de tamaño medio del sector auxiliar de la automoción. El mes pasado hicimos un pentest completo de la red de la oficina central servidores de contabilidad y ordenadores de los empleados. Se cerraron las vulnerabilidades de la oficina, pero el auditor de ciberseguridad nos indicó que también debemos incluir en las pruebas las unidades PLC, servidores SCADA y sensores IoT de la planta de producción.

En la fábrica se produce en tres turnos ininterrumpidos. Al director de planta le preocupa seriamente que un escaneo activo o un test de puertos en la parte de SCADA bloquee los controladores de automatización, pare la producción y desincronice los brazos robóticos. ¿En qué se diferencia exactamente un pentest SCADA de uno corporativo estándar de IT y cómo debemos planificar esta auditoría sin poner en riesgo la fábrica?

YYağmur C***ParticipanteMiembro de la comunidad
Miembro desde
may 2023
Mensaje
274
Más útil#2

Respuesta corta: En sistemas SCADA y de tecnología operacional (OT) no se pueden aplicar las técnicas clásicas de pentest de IT; los paquetes agresivos que envían los escáneres de seguridad estándar pueden colgar los PLC (de capacidad de procesamiento limitada) y provocar paradas en la línea o averías mecánicas.

En redes industriales, la auditoría se realiza según los principios del estándar IEC 62443, priorizando la escucha pasiva de red y el análisis de arquitectura sobre la inyección activa de paquetes. En una primera etapa se prueban los cortafuegos y la configuración DMZ entre la red IT corporativa y la capa de producción (OT). Se investiga si hay accesos no autorizados desde los PC de oficina hacia la capa de control de producción. Este paso no envía ningún paquete a la línea, por lo que no genera riesgo de parada.

Las pruebas de controladores y SCADA de la segunda fase no deben hacerse en horario de producción activa, sino durante paradas de mantenimiento planificadas o en un laboratorio con equipos de repuesto. Se cargan las copias de seguridad de configuración en el hardware réplica del laboratorio y se simula ahí la búsqueda de vulnerabilidades. Si es imprescindible probar en línea real, se aplican estas reglas: 1) Un ingeniero de automatización supervisa en pantalla durante el test, 2) Se desactivan por completo las funciones de escaneo agresivo y explotación de servicios de las herramientas estándar, 3) Se usan herramientas especiales de velocidad limitada, sensibles a protocolos de comunicación industrial.

En el contrato debe definirse desde el principio un protocolo de parada de emergencia para cortar el test con un solo botón ante cualquier respuesta anómala del hardware, así como el marco de responsabilidad legal ante posibles daños por paradas.

HHatice Ş***Participante
Cargo
Especialista en recursos humanos
Sector
Servicios de TI
Tipo de organización
startup recién creada
Miembro desde
sept 2025
Mensaje
123
#3

Las dudas de tu director de planta son totalmente acertadas y con razón. Si una empresa de seguridad típica le lanza un escaneo de puertos a un controlador antiguo, el dispositivo puede quedar colgado y entrar en modo fallo. Tenéis que confiar este test solo a equipos con certificación OT que conozcan la dinámica de la automatización industrial.

UUğur S***Participante
Cargo
Director de marketing
Sector
Agricultura
Tipo de organización
cooperativa
Miembro desde
nov 2025
Mensaje
284

Doki · Migración de infraestructura · 2024

#4

El año pasado pasamos por una auditoría similar para la automatización de la sección de pintura. Cuadramos el test con una parada de mantenimiento de seis horas un domingo. Incluso con un escaneo suave hecho con la línea vacía, se bloqueó un módulo de sensores y tuvimos que reiniciarlo. Ni se os ocurra permitirlo durante un turno de trabajo.

ÖÖmer I***VeteranoMiembro de la comunidad
Miembro desde
jul 2024
Mensaje
50
#5

Cláusulas de seguridad imprescindibles en el pliego de condiciones: 1) Prohibición absoluta de pruebas de denegación de servicio (DoS) durante la producción, 2) Extracción física de respaldos de software de todos los PLC y SCADA antes del test, 3) Ejecución de escaneos únicamente en las ventanas de mantenimiento pactadas, 4) Monitorización del tráfico con dispositivos pasivos de red durante los primeros días.

UUfuk S***Veterano
Cargo
Administrador de red
Sector
Fabricación de muebles
Tipo de organización
taller
Miembro desde
oct 2024
Mensaje
187
#6

en la prueba de nuestra fábrica no tocaron los controladores para nada solo miraron la configuración del switch entre la red de la oficia y la de la fábrica y cazaron dos túneles vpn abiertos que daban acceso directo a la planta. se pueden encontrar fallos supercríticos sin tocar la línea en producción.

CCeren A***Experto
Cargo
Director de marca
Tipo de organización
cadena de tiendas
Miembro desde
ago 2023
Mensaje
154
#7

Manténganse alejados del enfoque de 'nosotros también nos encargamos de las pruebas industriales' de las empresas de seguridad web y de servidores clásicas. Si en el equipo no hay alguien que conozca a nivel de hardware los controladores de automatización industrial y las arquitecturas PLC, pueden convertir su fábrica en un laboratorio de pruebas.

İİbrahim A***ExpertoMiembro de la comunidad
Miembro desde
may 2024
Mensaje
1
#8

En lugar de lanzarse directamente a una prueba, primero hagan revisar el aislamiento físico y lógico de su red de producción con la red de la oficina y el mundo exterior. Si garantizan un firewall estricto y restricciones de acceso entre ambas redes reducirán enormemente el riesgo cibernético de su línea de producción.

BBeyza T***ParticipanteMiembro de la comunidad
Miembro desde
nov 2024
Mensaje
336
#9

Nuestro jefe de planta también se asustó mucho cuando oyó lo de la prueba pensando que pararían la producción. Encontramos la solución comprando un PLC de repuesto y montándolo en una mesa. El equipo de seguridad probó ese hardware de repuesto y tapamos las fugas del sistema en vivo según los resultados. Es el método más seguro y con el que te quedas más tranquilo.

AAlper C***Experto
Cargo
Agente de atención al cliente
Sector
Software
Tipo de organización
cooperativa
Miembro desde
dic 2023
Mensaje
74
#10

Sus servidores SCADA y su red de producción ¿están actualmente cableados de forma físicamente independiente de su red de oficina, o solo hay una capa de red virtual (VLAN) de por medio? Además, ¿los dispositivos de la planta de producción tienen permiso para salir directamente a internet?

Nota: esto es mi experiencia, puede no aplicar a todos.

RRabia Ç***ParticipanteMiembro de la comunidad
Miembro desde
dic 2023
Mensaje
23
#11

Aquí hay una trampa, no puedo dejar de mencionarla. Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Corrijanme si me equivoco.

CCeren A***Experto
Cargo
Responsable de TI
Sector
Electricidad-electrónica
Tipo de organización
distribuidor regional
Miembro desde
jun 2024
Mensaje
263
#12

Resumen breve para nuevos usuarios: El tiempo que tardas en detectar un problema determina directamente su coste.

Que todo el mundo haga algo no significa que sea lo correcto. Esta es mi opinión, no lo escribo como una verdad absoluta.

GGökhan B***Experto
Cargo
Especialista en seguridad de la información
Sector
Software
Tipo de organización
Equipo de 8 personas
Miembro desde
nov 2023
Mensaje
20
#13

el punto que más se pasa por alto sobre pentest scada es este: Si el permiso y el alcance no están por escrito, que no empiece la prueba.

eso es todo disculpa si me he extendido demasiado.

AAleyna S***Participante
Cargo
Responsable de exportaciones
Sector
Comercio electrónico
Tipo de organización
mediana empresa
Miembro desde
ago 2024
Mensaje
3
#14

Tema muy oportuno.

AAhmet Y***Experto
Cargo
Representante de ventas de campo
Sector
Consultoría
Tipo de organización
distribuidor regional
Miembro desde
oct 2023
Mensaje
2
#15

Hace mucho que oímos eso, pero a nosotros nunca nos pasó así. Que todo el mundo haga algo no significa que sea lo correcto.

Por supuesto, cambia si tu situación es diferente.

DDoruk T***ParticipanteMiembro de la comunidad
Miembro desde
jul 2023
Mensaje
23
#16

Hay tres cosas que revisar al hacer esto. Las soluciones que funcionan a pequeña escala se rompen al crecer aprendí esto tarde.

Cuanto más difícil sea revertir una decisión, más despacio debéis tomarla. Lo dejo como nota, por si sirve.

ZZafer A***Experto
Cargo
Director de TI
Sector
Comercio electrónico
Tipo de organización
Empresa de 300 empleados
Miembro desde
feb 2023
Mensaje
4
#17

¿Y cómo resolvieron esto? Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

KKadir A***Experto
Cargo
Agente de atención al cliente
Sector
Distribución alimentaria
Tipo de organización
empresa dentro de un holding
Miembro desde
sept 2024
Mensaje
392
#18

Después de vivir eso, mi perspectiva cambió. La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.

Espero que le sea útil.

MMerve Y***Nuevo miembro
Cargo
Planificación de producción
Sector
Comercio electrónico
Tipo de organización
mediana empresa
Miembro desde
jul 2026
Mensaje
313
#19

No tengo ninguna experiencia en pentest scada, por eso pregunto. Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan.

Si intentas cambiarlo todo a la vez, nada termina de asentarse. Si tenéis dudas, escribid, os responderé en la medida de lo posible.

İİlker C***ParticipanteMiembro de la comunidad
Miembro desde
may 2023
Mensaje
29
#20

Voy a defender lo contrario no se molesten. Cuanto más difícil sea revertir una decisión, más despacio debéis tomarla.

Yo seguiría por ese camino.

Responder