Primero aprender, luego proteger

Primero aprender, luego proteger

Que toda disciplina profesional requiere de un proceso de formación y desarrollo específico, resulta innegable. Más aún, cuando esta se basa en aspectos tan dinámicos como los tecnológicos, donde un espacio de uno o dos años da lugar a nuevos paradigmas, nuevos escenarios, nuevas tendencias y, como no, nuevos riesgos.

Las tecnologías de operación, aquellas que encontramos en entornos industriales, no son una excepción. Más aún cuando el creciente aumento de conectividad y grado de exposición de componentes, sistemas y dispositivos, hacen que sean alcanzables y, por tanto, potencialmente alterable su normal funcionamiento. Esto hace que deban protegerse reduciendo el riesgo de que algo o alguien, de una manera intencionada (o no), pueda aprovechar alguna de sus posibles vulnerabilidades y modificar el proceso en el que están envueltos. Es muy común oír hablar de que lo primero es realizar un inventario para identificar, catalogar y cuantificar cada uno de los activos de los que dispone una organización y, en consecuencia, desplegar de manera razonable y razonada, las medidas de protección que más se ajuste a cada tecnología. Ahora bien, ¿sabemos realmente qué tipo de elementos nos podemos encontrar? ¿Sabemos interpretar los distintos procesos producticos en los que se ven envueltos? ¿Sabemos establecer las diferencias entre dispositivos?

Resulta necesario que todo profesional, que pretenda proteger de manera efectiva un entorno industrial, conozca los activos tecnológicos de cada empresa antes de poder determinar cómo protegerlos.

Es decir, podremos encontrar un autómata programable que controle los componentes de una mandriladora, una línea de ensamblaje, una célula robotizada o un autoclave. Todos estos sistemas son distintos. Una línea de ensamblaje no contará con los kilopascales que pueda tener un autoclave; ni tampoco la forma en la que se controla el movimiento de un motor de una mandriladora, con respecto a las diferentes trayectorias que puedan programarse en un robot de 3 o más ejes; o si el cierre de una válvula pueda generar un “golpe de ariete”.

Un cambio en la lógica programable debido a la ausencia de métodos de validación, control de accesos, protección de know-how o copia de su programa, puede desencadenar efectos físicos distintos, que irán desde la interrupción de las operaciones hasta situaciones de peligro para los operarios.

Si hablamos de situaciones de peligro, es inevitable hablar de seguridad. Para empezar las máquinas son seguras desde su propio diseño. Pero, ¿no dijimos que la ciberseguridad es algo “relativamente” nuevo? Ha de diferenciarse entre “security” y “safety”, siendo el segundo término prioritario frente al primero. Sin embargo, dependiendo de entorno, maquinaria o instalación, esta puede llevarse a cabo mediante lógica cableada en lugar de programable, como la que puede contar en un PLC. Por tanto, aun siendo sistemas críticos ¿cómo proteger los sistemas SIS si no pueden parametrizarse, configurarse o programarse?

Hasta hora, se intuye la necesidad de aplicar una seguridad lógica a través de medidas restrictivas mediante el límite de comunicaciones, aplicación de contraseñas, actualización, cuando sea posible, de versiones de firmware o sistemas operativos vulnerables, etc. Esto no siempre debe ser así. Un simple selector de operación de una CPU, o la presión de un pulsador para poder llevar a cabo cambios u operaciones en manual, hace que la seguridad física tenga un protagonismo, en algunos casos mayor, que la propia seguridad lógica.

Mencionaba a las comunicaciones y el hecho de limitarlas para restringir accesos por redes, propias o de terceros. Aquí, extrapolar las medidas tradicionales mediante la implementación de cortafuegos, bajo esquemas de separación, segmentación o virtual patching, puede no ser viable. Bien por la introducción de latencias inaceptables, determinismo, naturaleza de algunos protocolos no enrutables, o un largo etcétera. ¿Aplicar seguridad de red? Sí, pero sabiendo que no son iguales.

Si no sabemos el objetivo, naturaleza o propósito de las tecnologías de operación, sobre las que se basan los procesos industriales y modelos de negocio de las empresas, no podremos determinar las consecuencias e impacto que puede tener un incidente de seguridad para cualquier organización. Sea la que sea, desde una pyme a una multinacional.

Adicionalmente, quienes integran, mantienen y soportan no serán administradores de sistemas o redes, sino técnicos o ingenieros con conocimientos de automática, neumática, mecatrónica, electrónica de potencia o seguridad funcional, entre otras especialidades. Esto hace necesario, un conocimiento del lenguaje. Un lenguaje donde TCP no es Transport Control Protocol, sino Tool Centre Point; donde IP no es Internet Protocol, sino Ingress Protection; donde un switch no es un equipo de red sino un dispositivo que permite el paso o corte de corriente; donde FAT no es Fiber Access Terminal sino Factory Acceptance Test; y así un largo etcétera.

En resumen, como decía al inicio: “Primero aprender y luego proteger”. Sepamos primero qué papel juega, cómo funciona, qué es lo que hace y qué consecuencias pueden tener sobre el entorno. Si no, las medidas destinadas a protegerlas serán ineficaces, poco optimizadas o no tan eficientes como deberían ser.

Edorta Echave

Departamento de Ciberseguridad Industrial de Secure&IT

 

0/5 (0 Reviews)
Facebooktwitterpinterestlinkedinby feather