OT e IoT

Sí, desde el plan Pro. NetSenX lee Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm mediante captura pasiva en un puerto SPAN o TAP. Los dispositivos clasificados como OT nunca se sondean activamente, así que no hay riesgo para autómatas (PLC) ni sistemas SCADA.

Sí, con monitorización pasiva: el sensor lee una copia del tráfico desde un puerto SPAN o un TAP y nunca envía nada a los controladores. NetSenX funciona así desde el plan Pro y nunca sondea de forma activa los dispositivos clasificados como OT.

Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm, mediante captura pasiva, en el plan Pro y superiores.

No hace falta ningún appliance de NetSenX: el agente es software que funciona en el equipo que usted elija. Un agente conectado a un puerto SPAN o TAP vigila todo el segmento y cuenta como un solo dispositivo.

NIS2 se aplica a entidades de sectores como la energía, el transporte, el agua potable, la sanidad y la fabricación de determinados productos (anexos I y II de la Directiva (UE) 2022/2555). Las medidas de su artículo 21 se refieren a las redes y sistemas de información que una entidad utiliza en sus operaciones, y entre ellos pueden estar los sistemas OT. Confirme el ámbito con su autoridad nacional.

La monitorización pasiva no puede, porque solo escucha una copia del tráfico y nunca envía nada a los controladores. El escaneo activo es otra cosa: algunos PLC y unidades remotas antiguas se cuelgan, se reinician o entran en fallo cuando una herramienta de descubrimiento o un escáner de vulnerabilidades los sondea, y por eso muchas plantas mantienen los escáneres fuera de la red de control. Tome la copia de un puerto SPAN de un switch industrial o de un TAP de red pasivo, y confirme con el fabricante del switch que la réplica no sobrecargará un modelo antiguo. NetSenX lee Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm mediante captura pasiva, desde el plan Pro, y nunca sondea de forma activa los dispositivos clasificados como OT. No se instala nada en los controladores y ninguno de sus ajustes cambia.

Sí. Cámaras, impresoras, controladores de puertas, pantallas y sensores suelen ser antiguos, se actualizan poco y no admiten un agente, lo que los convierte en una vía de entrada habitual y en un buen escondite para un atacante que ya está dentro. Empiece por los pasos gratuitos: inventaríelos, cambie las contraseñas por defecto, actualice el firmware, desactive las funciones en la nube que no use y póngalos en un segmento de red propio, con reglas que solo permitan lo que necesitan. La monitorización le dice después si esas reglas se cumplen. Un sensor en ese segmento ve su tráfico sin tocar los dispositivos; NetSenX detecta en ellos escaneos, beaconing y volúmenes salientes inusuales, en todos los planes, y el mapa de red muestra los dispositivos que ve comunicarse. Un dispositivo que permanece en silencio, o que está en un segmento sin réplica, queda fuera de la vista.

Menor, pero sí. Una red local virtual (VLAN) separada solo ayuda si las reglas entre ella y el resto de la red son estrictas, y las cámaras y grabadores suelen recibir excepciones amplias para que el personal pueda ver las imágenes desde cualquier PC o móvil. Además, suelen necesitar acceso a internet para aplicaciones y actualizaciones, lo que también es una vía de salida para un atacante. Permita que solo el puesto de visualización o el servidor de vídeo lleguen a las cámaras, impida que la VLAN de cámaras alcance todo lo demás, bloquee el acceso a internet que no necesiten, cambie las contraseñas por defecto y actualice el firmware. Un sensor en esa VLAN ve su tráfico; NetSenX detecta en ellas escaneos, beaconing y volúmenes salientes inusuales, en todos los planes, de modo que una cámara que empieza a hablar con destinos nuevos destaca.

Vigilando el tráfico hacia y desde los controladores, porque un controlador lógico programable (PLC) apenas guarda registros de seguridad propios. Las señales útiles son sencillas: una escritura o una descarga de programa desde un ordenador que no es su estación de ingeniería, una orden de paro o arranque que nadie planificó, equipos de oficina que hablan directamente con controladores y actividad de noche o en fin de semana, cuando nadie trabaja en la línea. Empiece por los pasos gratuitos: anote qué estaciones pueden programar cada PLC, compruebe que la red de oficina no llega a la red de control y deje los selectores de modo de los controladores en RUN cuando su hardware los tenga. Desde el plan Pro, NetSenX lee Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm desde un puerto SPAN o TAP y genera cuatro tipos de alerta OT: escrituras no autorizadas, tráfico que cruza niveles de la red de planta, actividad OT fuera del horario laboral y comandos S7comm. Nunca sondea los controladores y no ve los enlaces serie ni los segmentos que usted no replique.

Porque no tiene autenticación ni cifrado: cualquier dispositivo que alcance un controlador Modbus/TCP puede leer sus valores y, salvo que el propio controlador lo limite, escribir en sus bobinas y registros. Modbus se diseñó en 1979 para enlaces serie entre dispositivos de confianza, mucho antes de que las redes de control se unieran a las redes de oficina y a internet. Existe una variante protegida con TLS, pero pocos dispositivos instalados la admiten. En la práctica, Modbus se protege desde fuera: el puerto 502 no debe estar expuesto a internet, solo hosts de ingeniería y SCADA concretos deben llegar a los controladores, y conviene usar cualquier protección contra escritura que ofrezca el PLC. Como el tráfico no está cifrado, un sensor pasivo puede leer qué estación lee o escribe en qué controlador. NetSenX lo hace desde el plan Pro y genera una alerta cuando un equipo que no está autorizado a escribir envía una escritura; no cambia el protocolo ni bloquea el comando.

Necesita algo que lea el protocolo industrial en la red y sepa qué equipos pueden escribir, porque el PLC normalmente acepta la escritura sin protestar y no registra nada. Primero anote qué estaciones deberían cambiar algún ajuste: normalmente una o dos estaciones de ingeniería y los servidores SCADA o HMI. Después haga que la red lo imponga donde pueda, con reglas de cortafuegos que solo dejen llegar a esos equipos a los controladores. La monitorización cubre lo que las reglas no ven: un portátil conectado a la línea, un PC de oficina con una ruta olvidada, malware en una estación autorizada. Desde el plan Pro, NetSenX lee las solicitudes de escritura mediante captura pasiva en un puerto SPAN o TAP y genera una alerta cuando una escritura procede de un equipo no autorizado, indicando el origen, el controlador, la función y la hora. No registra el valor escrito ni quién estaba ante el teclado.

Las que significan que algo cambió en el proceso: una escritura o descarga de programa desde un ordenador inesperado, un controlador parado, arrancado o cambiado de modo, tráfico de oficina que llega al nivel de control, y cualquiera de ellas fuera del horario laboral. En funcionamiento normal son poco frecuentes, así que cada una merece una llamada al responsable de la línea. Las alertas de volumen o de destinos nuevos también importan, pero en el lado IT, donde empiezan la mayoría de los ataques a fábricas. Acuerde de antemano quién recibe las alertas OT, en cuánto tiempo alguien las revisa y que nadie desconecte un equipo de producción sin consultar al jefe de turno, porque una desconexión brusca puede costar más que la alerta. Desde el plan Pro, NetSenX genera exactamente estas alertas OT: escrituras no autorizadas, tráfico que cruza niveles de la red de planta, actividad OT fuera del horario laboral y comandos S7comm, junto a las alertas de beaconing, escaneo, movimiento lateral y volumen saliente inusual que genera en todos los planes.

Combinando un registro de cuándo trabajan realmente sus ingenieros en los controladores con un sensor que vea en la red las descargas de programa y las escrituras. Un cambio de programa a las 2:00 de un domingo no prueba un ataque, porque el mantenimiento suele hacerse con la línea parada, pero alguien debería poder explicarlo a la mañana siguiente. Lleve un registro de cambios sencillo con las ventanas de mantenimiento previstas, compárelo con lo que muestra la red y guarde fuera de línea una copia validada del programa de cada PLC para poder comparar y restaurar. Algunos controladores también pueden avisar al SCADA de un cambio de programa. Desde el plan Pro, NetSenX marca la actividad OT fuera del horario laboral y decodifica solicitudes S7comm como la descarga de un bloque de programa, con el nombre del bloque, desde un puerto SPAN o TAP. No lee el contenido del programa ni compara versiones; eso lo hace su software de ingeniería.

Sí, cuando la orden de paro viaja por la red en S7comm, el protocolo que usan los controladores Siemens S7 para programación y diagnóstico. S7comm no va cifrado, así que un sensor pasivo que recibe una copia del tráfico puede decodificar la solicitud como un paro, junto con el ordenador que la envió y la hora. Un paro hecho con el selector o el panel del propio controlador nunca pasa por la red, así que ningún sensor lo ve. Los controladores más nuevos pueden usar un sucesor protegido, S7comm-plus; consúltenos antes de confiar en NetSenX para ese tráfico. Desde el plan Pro, NetSenX decodifica las solicitudes S7comm en nombres de comando, como paro del PLC, escritura de variable o descarga de un bloque de programa, y genera una alerta de comando S7comm desde un puerto SPAN o TAP, sin enviar nada al PLC. Informa a sus ingenieros; no bloquea el comando.

Puede mostrar qué ordenador envió la escritura y cuándo, lo que normalmente basta para encontrar a la persona. La mayoría de los protocolos industriales no llevan nombre de usuario, así que la red solo conoce la dirección de origen. La relación con una persona se obtiene del registro de auditoría del HMI o del SCADA, del log del software de ingeniería y del cuadrante de turnos. Para que sea posible más adelante, dé a cada estación de ingeniería una dirección fija, exija inicios de sesión nominales en HMI y SCADA y conserve sus registros tanto como su documentación de calidad. Desde el plan Pro, NetSenX lee las escrituras mediante captura pasiva en un puerto SPAN o TAP y, cuando quien escribe no está autorizado, genera una alerta con el equipo de origen, el controlador, el código de función y la hora. No registra el valor escrito y nunca identifica a una persona: observa dispositivos y conexiones, no personas.

No. NetSenX registra que hubo una escritura, desde qué equipo, en qué controlador, con qué código de función y a qué hora, pero no el valor escrito ni el contenido de un bloque de programa. Es un límite deliberado: los valores de proceso y los programas son su saber hacer, y una alerta necesita el quién y el cuándo, no la receta. Si necesita los valores, por ejemplo para reconstruir un lote defectuoso, salen del historian, del registro de auditoría del SCADA o del HMI o del diagnóstico del propio controlador. Prepárelo antes de necesitarlo: compruebe cuánto tiempo guarda datos su historian y si los cambios en el HMI se registran con nombre de usuario. NetSenX lee Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm mediante captura pasiva, desde el plan Pro, y nunca envía nada a los dispositivos.

Sí, como una fuente de pruebas entre varias. Una alerta OT indica que un controlador recibió una escritura de un equipo no autorizado, un comando S7comm o tráfico fuera del horario laboral, con el equipo de origen, el controlador y la hora. Colóquela en una línea temporal junto a los datos del historian, el registro de auditoría del HMI, el libro de turnos y los partes de mantenimiento, y normalmente podrá acotar cuándo y desde dónde llegó un cambio. Asegúrese de que los relojes coinciden, porque unos minutos de desfase entre sistemas hacen que la línea temporal engañe. Tenga también presente lo que las alertas no cubren: una escritura autorizada durante el turno no genera alerta, así que el registro del HMI sigue siendo su constancia de los cambios cotidianos. NetSenX conserva las alertas durante el historial de alertas de su plan; puede consultarlas en el panel, mediante la API desde el plan Pro o en su SIEM desde el plan Business. No contienen valores escritos ni nombran a ninguna persona.

No. NetSenX lee cinco protocolos industriales, Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm, pero no hay una alerta de anomalía propia de cada protocolo, por ejemplo para un sondeo Modbus inusual o un tráfico BACnet extraño. Sus alertas OT son cuatro tipos que funcionan sobre todo lo que lee: una escritura en un controlador desde un equipo no autorizado, tráfico que cruza niveles de la red de planta, actividad OT fuera del horario laboral y comandos S7comm como un paro o una descarga de programa. Además, las detecciones generales vigilan los mismos equipos: beaconing, escaneo, movimiento lateral y volumen saliente inusual. Si su análisis de riesgos exige una detección de anomalías profunda y específica de un protocolo, por ejemplo para el telecontrol de una empresa de servicios, pregúntenos qué está cubierto antes de confiar en ello, o use una herramienta OT especializada junto a NetSenX. Las funciones OT están disponibles desde el plan Pro.

No. NetSenX escucha una copia del tráfico e informa a sus ingenieros; no está en el camino de los paquetes, así que no puede descartar ninguno, y nunca actúa sobre el proceso. Es intencionado: un equipo en línea que bloquea comandos industriales puede parar una línea por error, y NetSenX no es un sistema de seguridad funcional. La protección frente a comandos peligrosos viene de otras capas: un cortafuegos entre zonas que solo permita equipos concretos, la protección contra escritura y los selectores de modo de los controladores, y un sistema instrumentado de seguridad independiente de la red de control. Lo que NetSenX aporta, desde el plan Pro, es la alerta cuando escribe un equipo que no debería, cuando un controlador recibe un comando S7comm como un paro o cuando aparece tráfico OT de noche, para que alguien lo revise antes de que empiece el siguiente turno.

Hoy no. NetSenX lee mediante captura pasiva, desde el plan Pro, cinco protocolos industriales: Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm. El resto del tráfico industrial de un segmento monitorizado se sigue viendo como conexiones entre equipos: el beaconing, el escaneo, el movimiento lateral y el volumen saliente inusual siguen aplicándose, y el mapa de red sigue mostrando los dispositivos. Lo que falta es la decodificación de los comandos de ese protocolo, así que las alertas OT sobre escrituras y comandos no lo cubren. Si su planta funciona sobre todo con PROFINET, OPC UA o el protocolo de telecontrol IEC 60870-5-104, díganoslo antes de comprar y pregunte qué quedaría cubierto en su red, o combine NetSenX con una herramienta que decodifique esos protocolos. Es mejor saberlo ahora que descubrir el hueco durante una auditoría.

No. Un sensor de red ve el tráfico Ethernet e IP que se le replica. Los enlaces serie como Modbus RTU sobre RS-485, Profibus DP y otros buses de campo nunca llegan a Ethernet, así que sus comandos quedan fuera de su vista. Lo que sí ve es la pasarela que traduce entre Ethernet y el bus serie: quién habla con ella, cuándo y con qué frecuencia. En muchas plantas es una señal útil, porque quien quiera llegar a un dispositivo serie desde la red tiene que pasar por esa pasarela. Inventaríe sus pasarelas, protéjalas como si fueran controladores y replique el segmento en el que están. NetSenX lee Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm mediante captura pasiva, desde el plan Pro. Para el lado serie, apóyese en el diagnóstico de los propios controladores y en armarios cerrados con llave.

Significa que el sensor nunca envía un paquete a un dispositivo clasificado como OT: ni escaneo de descubrimiento, ni escaneo de puertos, ni consulta de protocolo, ni intento de inicio de sesión. Solo lee una copia del tráfico que sus sistemas ya intercambian, tomada en un puerto SPAN o un TAP de red. Las herramientas activas funcionan de otro modo: hacen preguntas a cada dispositivo, y algunos PLC, unidades remotas y HMI antiguos reaccionan mal a solicitudes inesperadas, desde respuestas lentas hasta bloqueos. Para un director de planta, en la práctica significa que activar NetSenX no añade tráfico a la red de control y no puede cambiar el estado de un controlador, así que no hace falta ninguna ventana de mantenimiento en los propios controladores. La contrapartida es que un sensor pasivo solo sabe lo que los dispositivos dicen: un controlador que nunca se comunica en un segmento replicado no se ve. La monitorización OT está disponible desde el plan Pro.

No. La monitorización pasiva no necesita software, cambios de configuración ni de firmware en los PLC, los HMI o los variadores. El cambio se hace en la red: un puerto SPAN (espejo) en un switch gestionable, o un TAP pasivo en un cable, envía una copia del tráfico a un pequeño ordenador que ejecuta el sensor. Planifique ese cambio como cualquier otro en la red de producción: acuérdelo con el ingeniero OT, compruebe que el switch puede replicar los puertos que necesita sin sobrecarga y hágalo en una ventana de mantenimiento si sus normas lo exigen. Después decida dónde va el equipo del sensor y cómo envía las alertas, idealmente mediante una regla de cortafuegos que solo permita eso. Con NetSenX, el agente funciona en un equipo Linux que usted elija y lee Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm desde el plan Pro; un agente en un puerto espejo cuenta como un solo dispositivo.

Use un TAP de red, o añada un switch gestionable donde necesite visibilidad. Los switches no gestionables, habituales en los armarios de las máquinas, no pueden replicar tráfico. Un TAP es una pequeña caja que se intercala en un cable, por ejemplo en el enlace entre el switch de línea y el núcleo de red de la planta, y copia el tráfico en ambos sentidos a un puerto de monitorización sin ser visible en la red. Muchos modelos mantienen el enlace aunque pierdan la alimentación; compruébelo en el modelo que compre. Elija el enlace que lleve el tráfico que más le importa: entre oficina y producción, o entre los servidores SCADA y los controladores. El tráfico entre dos dispositivos conectados al mismo switch no gestionable nunca pasa por ese enlace y queda fuera de la vista. NetSenX funciona con un puerto SPAN o con un TAP; un agente en él cuenta como un solo dispositivo, y los protocolos OT se leen desde el plan Pro.

Sí. Todo lo que la máquina hace en la red puede observarse desde fuera, a partir de una copia de su tráfico tomada en un puerto SPAN o un TAP. Es el enfoque habitual para controladores, HMI, bancos de pruebas, equipos médicos y cualquier sistema cuyo proveedor prohíba cambios o condicione a ello la garantía. Lo que ve es su comportamiento: con qué equipos habla, a qué horas, cuántos datos y, en los protocolos industriales decodificados, qué pide a los controladores. Lo que no ve es lo que ocurre dentro: archivos, procesos e inicios de sesión locales quedan ocultos, igual que el tráfico de los enlaces sin réplica. NetSenX funciona así: un agente en un puerto espejo vigila todo el segmento y cuenta como un solo dispositivo. El beaconing, el escaneo, el movimiento lateral y el volumen saliente inusual se detectan en todos los planes; los protocolos y alertas OT llegan con el plan Pro.

Sí. La mayoría de los ataques que paran la producción empiezan en la red de oficina, por un correo, una contraseña robada o el acceso de un proveedor, y una red plana les deja llegar directamente a los controladores. Separar no tiene por qué significar aislar físicamente. El diseño habitual pone un cortafuegos entre oficina y producción, con una pequeña zona desmilitarizada (DMZ) en medio para los sistemas que necesitan ambos lados, como una copia del historian, un servidor de parches o la pasarela de acceso remoto, y sin conexión directa de un PC de oficina a un controlador. Empiece por enumerar las conexiones que la producción necesita de verdad, permita solo esas y registre lo que se rechaza. Después compruebe que la separación se mantiene en la práctica, porque las excepciones se acumulan. Desde el plan Pro, NetSenX genera una alerta cuando el tráfico cruza niveles de la red de planta, por ejemplo de un equipo de oficina directamente a un controlador, a partir de un puerto SPAN o TAP.

El modelo Purdue es una arquitectura de referencia que ordena los sistemas de una planta por niveles: abajo el proceso físico y sus sensores, encima los controladores, luego los sistemas de supervisión como HMI y SCADA, después las operaciones de planta como el historian y la planificación de la producción, y arriba la red corporativa. La regla que importa es que cada nivel hable sobre todo con sus vecinos y que el tráfico entre la red corporativa y la producción pase por una frontera controlada, normalmente una DMZ. El tráfico que salta niveles, como un PC de oficina que habla directamente con un PLC, es o un error de diseño o algo que está usando un atacante, y es una de las señales de alarma más claras en OT. Muchas plantas reales no encajan del todo en el modelo, y no pasa nada; lo importante es saber qué cruces son intencionados. Desde el plan Pro, NetSenX marca el tráfico que cruza niveles Purdue, mediante captura pasiva.

Pruébelo y luego vigílelo. Para la prueba, tome un portátil de oficina normal y, con el acuerdo del ingeniero OT, intente abrir una conexión con la dirección y el puerto de un controlador y con los servidores HMI y SCADA; use una simple prueba de conexión, nunca un escáner, contra dispositivos de producción. Revise las reglas del cortafuegos entre oficina y producción en busca de permisos demasiado amplios y de excepciones antiguas que nadie sabe explicar. Después vigile el tráfico real durante unas semanas, porque los caminos que importan suelen ser los olvidados: un PC con una tarjeta de red en cada red, la VPN de un proveedor que termina dentro de producción, un puente inalámbrico. Desde el plan Pro, NetSenX marca el tráfico que cruza niveles de la red de planta, como un equipo de oficina que llega a un controlador, de modo que un camino que no debería existir aparece la primera vez que se usa. Un camino que existe pero nunca se usa sigue siendo invisible para cualquier sensor pasivo.

Sí, y es la forma más común en que un incidente cibernético para la producción, aunque las máquinas no se toquen. Las líneas dependen de sistemas informáticos para pedidos, recetas, etiquetas, envíos y registros de calidad; cuando el ERP, el servidor de etiquetas o las carpetas compartidas quedan cifrados, muchas plantas prefieren parar antes que producir sin trazabilidad. Otras detienen la producción por precaución mientras averiguan hasta dónde llegó el atacante. Proteger la producción empieza, por tanto, en el lado IT: enumere los sistemas que necesita cada línea, planifique cómo trabajar un día sin ellos, guarde copias de seguridad fuera de línea de esos sistemas y pruebe a restaurarlas. NetSenX vigila, en todos los planes, los pasos en el lado IT que preceden al cifrado: beaconing, escaneo, movimiento lateral y volumen saliente inusual. Desde el plan Pro muestra el tráfico OT en el mismo panel. No detiene el ransomware; le da tiempo para actuar.

Trátelos como visitantes con llave: admitidos para un trabajo, por un puerto conocido y vigilados mientras están dentro. Acuerde con cada fabricante de máquinas e integrador qué portátil puede conectarse, dónde y para qué. Deles un puerto o una VLAN de mantenimiento dedicados que solo lleguen a su máquina, en lugar de cualquier toma libre del switch de línea, y desactive ese puerto al terminar el trabajo. Pida que el portátil se revise en busca de malware antes de conectarlo, o présteles un portátil de la empresa con el software de ingeniería, algo que muchas plantas prefieren. Lleve un breve registro de visitas: quién, cuándo, qué máquina. En la red, el portátil aparece como un dispositivo nuevo en el mapa de red de NetSenX, en todos los planes, y si escanea o empieza a hablar con muchos equipos, saltan las alertas de escaneo y de movimiento lateral. Desde el plan Pro, una escritura en un controlador desde un equipo no autorizado genera una alerta OT.

Sí, si el segmento que usó el portátil se replica a un sensor: cada conexión que hizo pasó por la red y puede listarse después por su dirección. Eso responde a la pregunta que hacen los directores de planta y los auditores tras una visita: ¿tocó el portátil solo la máquina a la que venía? Facilítelo dando a las visitas direcciones de un rango conocido o una VLAN de mantenimiento propia, para que su tráfico se distinga fácilmente del suyo. En el mapa de red de NetSenX, en todos los planes, el portátil aparece como un dispositivo con los equipos con los que habló y cuándo se vio por primera y última vez. Desde el plan Pro, NetSenX también decodifica Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm, de modo que las escrituras de un equipo no autorizado y los comandos S7comm generan alertas OT. Una conexión hecha a través del router 4G del propio fabricante, o en un switch interno de la máquina sin réplica, nunca pasa por su red monitorizada y no se ve.

Mediante un único punto de entrada controlado que sea suyo y que solo se active cuando haga falta. En la práctica: una pasarela de acceso remoto o un servidor de salto en la DMZ entre oficina y producción, autenticación multifactor en cada cuenta de proveedor, una cuenta nominal por técnico en lugar de una compartida, acceso limitado a las máquinas que ese proveedor atiende, sesiones habilitadas a petición y cerradas después, y registros o grabaciones de lo que se hizo. Cuando ese camino exista, retire las herramientas permanentes de los proveedores, como las aplicaciones de escritorio remoto en los HMI y los routers 4G en los armarios. NIS2 también espera medidas de seguridad de la cadena de suministro, así que incluya estas reglas en los contratos. En la red, una sesión de proveedor aparece como conexiones de la pasarela hacia producción; NetSenX detecta en ellas escaneo y movimiento lateral en todos los planes y, desde el plan Pro, escrituras de equipos no autorizados. NetSenX no decide quién obtiene acceso; eso lo hace su pasarela.

Sí. Un router móvil instalado para soporte remoto conecta la máquina a internet a través de la red móvil, rodeando por completo su cortafuegos, así que no se le aplica ninguna de sus reglas, registros ni controles de VPN. Si el portal del proveedor o el propio router se ven comprometidos, o nadie cambió su contraseña por defecto, un atacante aterriza en su red de producción. Muchos de estos routers no figuran en ningún plano porque llegaron con la máquina. Pregunte por escrito a cada proveedor de máquinas si su equipo contiene un módem o router móvil, inspeccione los armarios y después retírelo, manténgalo apagado hasta que haya una sesión de soporte programada o sustitúyalo por su propio acceso remoto controlado. Un sensor de red no puede ver el enlace 4G en sí, porque ese tráfico nunca pasa por su red; solo ve el lado LAN del router, si ese segmento se le replica.

Mirando a la vez los armarios y la red. Físicamente: abra los armarios de las máquinas en la próxima parada programada y busque pequeños routers, módems y antenas, y pida a cada proveedor una lista de los equipos de comunicación de sus máquinas. En la red: busque dispositivos que se comporten como pasarelas, por ejemplo una máquina cuyo tráfico va a una dirección que no es su router, un dispositivo que reparte sus propias direcciones o un equipo que recibe conexiones desde fuera en momentos en que nadie de su lado las inició. Un dispositivo que aparece en su mapa de red pero en ningún plano merece una pregunta. El mapa de red de NetSenX, en todos los planes, muestra los dispositivos que ve comunicarse en los segmentos monitorizados con su primera y última aparición, y los que llaman al exterior a intervalos regulares se marcan como beaconing. Un router que solo habla por su enlace móvil y permanece callado en su LAN no se encuentra desde la red; lo encuentra la inspección de los armarios.

Rodeándolo de protección, ya que no puede arreglarlo. Paneles de operador, HMI y ordenadores de bancos de pruebas suelen funcionar con un sistema operativo que el fabricante ya no soporta, y el proveedor de la máquina prohíbe cambios. Sáquelo de toda red que no necesite, bloquee su acceso a internet, permita solo las conexiones que necesita con los controladores y servidores con los que trabaja, desactive puertos USB y servicios innecesarios si el proveedor lo permite, use una lista blanca de aplicaciones si el fabricante la admite y guarde una imagen probada para poder reconstruirlo. Pida al proveedor una vía de actualización y documente el riesgo restante. Después vigílelo desde la red, ya que no se le puede instalar nada: NetSenX ve sus conexiones desde un puerto SPAN o TAP y detecta beaconing, escaneo, movimiento lateral y volumen saliente inusual en todos los planes y, desde el plan Pro, escrituras en controladores desde equipos no autorizados. No ve lo que se ejecuta dentro del PC.

Es una medida que reduce un riesgo que no se puede eliminar en su origen. Cuando un controlador no se puede parchear, no tiene contraseña o funciona con un sistema sin soporte, se protege desde fuera: segmentación y reglas de cortafuegos para que solo lleguen a él equipos concretos, sin acceso a internet, un camino de acceso remoto controlado, armarios cerrados, copias de seguridad fuera de línea de programas y configuraciones, y una monitorización que avise cuando alguien eluda la protección. Los auditores que trabajan con IEC 62443 o con la gestión de riesgos de NIS2 suelen esperar que estos controles estén documentados: qué riesgo, qué medida, quién es responsable y cómo comprueba que sigue funcionando. La monitorización es la parte que aporta esa prueba de comprobación. NetSenX puede aportarla: desde un puerto SPAN o TAP muestra quién habla con el sistema antiguo y, desde el plan Pro, genera alertas OT por escrituras no autorizadas, tráfico que cruza niveles de la red de planta, actividad fuera del horario laboral y comandos S7comm.

Combinando tres fuentes pasivas: lo que dicen sus documentos, lo que saben sus herramientas de ingeniería y lo que muestra la red. Empiece por los planos, los archivos de proyecto de ingeniería, que enumeran cada controlador, variador y módulo de E/S remotas configurados, y la documentación del proveedor de cada máquina. Después recorra la planta: armarios, pupitres, instalaciones remotas. Por último, añada lo que muestra el tráfico: un sensor pasivo en un puerto espejo ve cada dispositivo que se comunica en ese segmento, también los que nadie anotó. Registre de cada activo su dirección, función, responsable, versión de firmware y si se puede actualizar. El mapa de red de NetSenX, en todos los planes, muestra los dispositivos vistos en los segmentos monitorizados con los nombres que anuncian y su primera y última aparición, y desde el plan Pro NetSenX lee Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP y S7comm. Nunca sondea los dispositivos OT, así que no consulta versiones de firmware; esas las dan sus herramientas de ingeniería.

Los que no se comunican en un segmento replicado. Eso incluye dispositivos que callan la mayor parte del tiempo, como un controlador de reserva o un módulo que solo responde a un maestro que usted no ve; dispositivos en buses de campo serie como Modbus RTU o Profibus; dispositivos detrás de un switch no gestionable cuyo tráfico nunca llega al enlace replicado; equipos que solo hablan por su propio router móvil; e instalaciones remotas sin sensor. La monitorización pasiva también ve menos dentro de los protocolos cifrados y no puede leer una versión de firmware que el dispositivo no anuncie. Cubra esos huecos con un recorrido por la planta, los archivos de proyecto de ingeniería y, si la planta lo acepta, una consulta cuidadosamente planificada con las herramientas del fabricante durante una ventana de mantenimiento. NetSenX es solo pasivo, así que su mapa de red muestra lo que se comunica en los segmentos monitorizados, y nada más.

Normalmente uno por cada segmento de red que quiera vigilar en cada sede, lo que suele significar entre uno y tres por planta. El número depende de dónde se pueda copiar el tráfico: un puerto SPAN en el switch principal de una planta suele ver el tráfico entre oficina y producción y entre los servidores SCADA y los switches de línea, mientras que el tráfico dentro del switch propio de una máquina necesita un sensor o TAP más cerca de ella. Empiece por la frontera entre oficina y producción en cada planta y después añada los segmentos donde se programan los controladores. Cada planta necesita un pequeño equipo para el sensor y una forma de enviar alertas al exterior. Con NetSenX, cada agente en un puerto SPAN o TAP cuenta como un solo dispositivo para todo el segmento que vigila, todas las plantas aparecen en un único panel y los protocolos OT se leen desde el plan Pro. La página de precios indica cuántos dispositivos incluye cada plan.

Sí, si alguien tiene tiempo para mantenerlas. Existen herramientas maduras de monitorización de red de código abierto capaces de leer varios protocolos industriales desde un puerto SPAN. El coste no es la licencia, sino el trabajo: instalar y actualizar los sensores, escribir o ajustar reglas para su planta, almacenar los registros, montar paneles y, sobre todo, tener a alguien que mire las alertas. En una planta con un ingeniero OT al que le guste este trabajo, puede ser un buen comienzo. Si nadie tiene ese tiempo, los registros se acumulan sin leer, lo que da la sensación de monitorizar sin el resultado. NetSenX es la alternativa gestionada: un agente en un puerto SPAN o TAP, alertas explicadas en lenguaje claro y los protocolos OT desde el plan Pro, sin reglas que mantener por su parte. Elija lo que elija, empiece por la frontera entre oficina y producción.

IEC 62443 es una serie de normas internacionales sobre la seguridad de los sistemas industriales de automatización y control. Abarca el programa de seguridad del propietario de la instalación, las obligaciones de integradores y proveedores de servicios, los requisitos de un sistema completo dividido en zonas y conductos, y los requisitos de los propios productos, con niveles de seguridad que describen frente a qué atacante debe resistir una zona. Es voluntaria: la ley no obliga a un fabricante típico a certificarse, pero clientes, aseguradoras y auditores la usan cada vez más como referencia, y su enfoque de zonas y conductos es una forma práctica de organizar las medidas de gestión de riesgos de NIS2 en una planta. No hace falta la certificación para aprovecharla: divida la planta en zonas, enumere los conductos entre ellas y decida qué puede transportar cada uno. La monitorización comprueba después los conductos en la práctica. NetSenX puede aportar esa prueba: desde el plan Pro lee protocolos industriales de forma pasiva y marca el tráfico que cruza niveles de la red de planta.

Normalmente pruebas de que la detección existe, cubre los lugares adecuados y lleva a actuar: qué segmentos OT se monitorizan y cómo, qué tipos de eventos se detectan, quién revisa las alertas y con qué rapidez, ejemplos de alertas gestionadas con la decisión tomada y cuánto tiempo se conservan los registros. En Alemania, la Oficina Federal de Seguridad de la Información (BSI) ha publicado una guía sobre sistemas de detección de ataques para operadores de infraestructuras críticas que los auditores suelen usar como referencia; otros países tienen sus propias expectativas, así que consulte a su autoridad nacional. Una lista de herramientas no basta: los auditores buscan un proceso que funcione. Un mapa de red con primera y última aparición, alertas con marca de tiempo y sus notas sobre cada decisión hacen visible ese proceso. NetSenX conserva las alertas durante el historial de alertas de su plan y, desde el plan Pro, añade alertas OT por escrituras no autorizadas, tráfico entre niveles, actividad fuera del horario laboral y comandos S7comm. No le certifica ni sustituye el criterio del auditor.

Sí, y un riesgo subestimado. Calefacción, ventilación, iluminación, ascensores y control de accesos funcionan hoy con controladores en red, a menudo en BACnet/IP, con acceso remoto para la empresa de mantenimiento y una aplicación en la nube para el responsable de instalaciones. Se actualizan poco, suelen conservar contraseñas por defecto y normalmente los gestiona otro equipo o un contratista externo, no el departamento de informática. Un atacante puede usarlos para alterar el funcionamiento del edificio, o como cabeza de puente discreta hacia la red de oficina si ambas no están separadas. Pregunte a su contratista adónde se conecta el sistema, quién tiene acceso remoto y cómo, y ponga los controladores del edificio en un segmento de red propio, con un acceso a internet limitado a lo que el fabricante necesita de verdad. NetSenX lee BACnet/IP mediante captura pasiva desde el plan Pro y, en todos los planes, detecta beaconing, escaneo y volumen saliente inusual de esos controladores. No hay una alerta de anomalía BACnet propia.

Sí, si ambos comparten red o las reglas entre ellos son laxas. Los sistemas del edificio suelen instalarlos contratistas en los mismos switches y el mismo rango de direcciones que la oficina, o con una ruta cómoda para que el responsable de instalaciones abra el software de control en un PC de oficina. Un atacante que entre por el acceso remoto del sistema del edificio o por un controlador débil puede entonces llegar a los ordenadores de la oficina como si estuviera dentro. Compruebe dónde están los controladores del edificio y su servidor, si pueden llegar a los equipos de oficina y si los equipos de oficina pueden llegar a ellos; normalmente solo lo necesita un puesto de gestión. Sepárelos con un cortafuegos o una VLAN con reglas estrictas y haga pasar el acceso remoto del contratista por su propia pasarela. En un segmento monitorizado, NetSenX detecta en todos los planes el escaneo y el movimiento lateral desde un controlador del edificio hacia equipos de oficina, de modo que un controlador que empieza a explorar la red destaca.

Puede serlo, pero debe saber por qué lo hace. Muchos grabadores de cámaras mantienen una conexión permanente con la nube del fabricante para que la aplicación del móvil muestre las imágenes sin abrir un puerto en su router, y esos servidores pueden estar en otro país o en otro continente. Esa conexión es también un canal de acceso remoto que usted nunca configuró, gestionado por un tercero, y los grabadores antiguos tienen un largo historial de fallos de seguridad. Averigüe con el instalador o en la documentación del fabricante qué servicio es, decida si necesita de verdad la visualización remota y, si no, desactive la función en la nube y bloquee el acceso a internet del grabador. Si la necesita, mantenga el firmware al día y cambie las contraseñas por defecto. NetSenX muestra los destinos del grabador desde un puerto SPAN o TAP y detecta beaconing y volumen saliente inusual en todos los planes, de modo que un grabador que de repente envía mucho más de lo habitual destaca. Que la nube del fabricante sea aceptable sigue siendo decisión suya.

Puede serlo. Televisores inteligentes, pantallas de videoconferencia y paneles de reserva de salas funcionan con sus propios sistemas operativos, contactan con el fabricante para actualizaciones, aplicaciones y publicidad, y rara vez se actualizan una vez instalados. En la red de oficina están junto a los portátiles que se proyectan en ellos, y algunos tienen micrófonos y cámaras. La mayor parte de ese tráfico va a los servicios del fabricante, pero desde fuera no se sabe sin mirarlo. Desactive las funciones que no use, como el control por voz, las tiendas de aplicaciones y las estadísticas de visualización, actualice el firmware y lleve las pantallas a una red aparte para dispositivos, con un acceso a internet limitado a lo que necesitan y sin acceso a los equipos de oficina. Los portátiles pueden entonces compartir pantalla por cable o mediante un dispositivo de transmisión en esa red. NetSenX vigila estos dispositivos sin ningún software instalado en ellos, desde un puerto SPAN o TAP, y detecta beaconing, escaneo y volumen saliente inusual en todos los planes.

Normalmente por motivos corrientes: actualizaciones de firmware, avisos de tóner y uso al proveedor, impresión en la nube y escaneo a la nube. Los contratos de impresión gestionada suelen incluir esos avisos, así que pregunte a su proveedor qué envía la impresora y adónde. El riesgo es que las impresoras son ordenadores completos con software antiguo, páginas de administración con contraseñas por defecto y copias guardadas de documentos escaneados, y nadie las vigila. Revise en la configuración las funciones en la nube y remotas que no use y desactívelas, actualice el firmware, ponga una contraseña de administrador y limite su acceso a internet a los servicios del proveedor. Una impresora que empieza a conectarse a muchas direcciones internas, o a destinos nuevos en el exterior, merece una revisión el mismo día. NetSenX ve las impresoras desde un puerto SPAN o TAP sin software en ellas, las muestra en el mapa de red y detecta escaneos, beaconing y volumen saliente inusual en todos los planes.

Sobre todo con el diseño de la red, porque estos dispositivos no pueden ejecutar software de seguridad. Ponga los lectores portátiles, las impresoras de etiquetas, los controladores de cintas transportadoras y el Wi-Fi del almacén en un segmento de red propio que solo llegue al servidor de gestión del almacén y a las impresoras que necesita, no a los PC de oficina ni a internet en general. Use una red Wi-Fi aparte con autenticación por dispositivo o por certificado en lugar de una contraseña compartida que conoce cada antiguo trabajador temporal, mantenga actualizados el sistema y las aplicaciones de los terminales con su herramienta de gestión y bloquéelos en la aplicación del almacén. Retire los dispositivos que el fabricante ya no actualiza. Después vigile el segmento, porque un solo terminal comprometido en una red de almacén plana llega a todo lo demás. NetSenX vigila el segmento con un agente en un puerto SPAN o TAP: el mapa de red muestra los dispositivos, y el escaneo, el beaconing y el volumen saliente inusual se detectan en todos los planes.

No. NetSenX cuenta los agentes que usted ejecuta, no los dispositivos que vigilan. Un agente en un puerto SPAN o TAP cuenta como un solo dispositivo para todo el segmento que monitoriza, así que cuarenta lectores portátiles, las impresoras de etiquetas y el controlador de la cinta transportadora en un mismo segmento replicado quedan cubiertos por ese único agente. Un agente instalado directamente en un servidor o un portátil también cuenta como un dispositivo y vigila ese equipo. La pregunta para planificar es, por tanto, cuántos segmentos quiere vigilar y dónde puede copiar su tráfico, no cuántos dispositivos tiene. Un almacén con su propio switch suele necesitar un agente allí. Los terminales conectados a puntos de acceso Wi-Fi enchufados a ese switch se ven cuando su tráfico pasa por el puerto replicado. La página de precios muestra el límite de dispositivos de cada plan, desde el plan Free.

Desde la red, igual que los equipos industriales. Analizadores, equipos de imagen, bombas de infusión e instrumentos de laboratorio suelen funcionar con sistemas antiguos que el fabricante certifica y le prohíbe cambiar, así que un agente no es una opción. Póngalos en un segmento de red propio que solo llegue a los sistemas a los que informan, como el sistema de información del laboratorio o el archivo de imágenes, bloquee el acceso a internet que no necesiten y haga pasar el servicio remoto de cada fabricante por su propia pasarela. Un sensor en un puerto SPAN o TAP de ese segmento ve entonces sus conexiones sin tocarlos. NetSenX muestra los dispositivos en el mapa de red y detecta beaconing, escaneo, movimiento lateral y volumen saliente inusual en todos los planes. No decodifica protocolos médicos como HL7 o DICOM y nunca descifra el tráfico. Antes de activarlo, consulte a su delegado de protección de datos cómo encaja la monitorización en su registro de actividades de tratamiento.