Cuando un parche de seguridad es un problema y no la solución

Cuando un parche de seguridad es un problema y no la solución

Cuando un parche de seguridad es un problema y no la solución 6912 3456 Centro de Ciberseguridad Industrial

En los ’90 y a principios del 2000, para todos los que trabajábamos en sistemas y en particular en el ámbito de infraestructura, el temor a aplicar un parche de seguridad en un servidor en producción era aterrador.  Fue normal en la época de Windows NT 4.0 Server sufrir ansiedad entre otras emociones, solo pensar que había una nueva versión disponible de Service Pack o una actualización. Era inevitable preguntarse si al implementarla no se rompería la compatibilidad con los demás sistemas y aplicaciones de nuestra organización.  Muchas cosas sucedieron en el camino como la iniciativa TwC (Trustworthy Computing) de Microsoft. Poco a poco los procesos fueron madurando tanto en los vendors como en las organizaciones, llegando así hasta el momento actual donde por ejemplo contamos una fecha programada de publicación de actualizaciones (primer martes de cada mes salvo casos de urgencia) y donde incluso contamos con la facilidad de crear entornos de test ágilmente gracias a las actuales tecnologías. Sin embargo, en el mundo de las tecnologías de operación (OT) esta historia no tomó el mismo camino.   Al día de hoy, en el sector seguimos teniendo cierto temor y vemos que aún nos falta madurez de algunos procesos. Esta situación se hace patente cuando hacemos un diagnóstico de ciberseguridad y nos encontramos con un gran porcentaje de servidores y estaciones de ingeniería desactualizados (y ni hablar de versiones de firmware de los controladores y las RTU).

La falta de experiencia en el sector de OT puede llevar a realizar un diagnóstico de ciberseguridad o incluso una auditoría a las instalaciones un tanto incompleta o con errores. La probabilidad de caer en prejuicios respecto al por qué no se implementan las actualizaciones en los servidores MES, SCADA e Historiadores,  es realmente muy alta. Por ello muchos informes se hace referencia a “la falta de madurez en la gestión de parches de la organización”.    Sin embargo, situaciones como la sucedida con la serie de actualizaciones publicada por Microsoft para solucionar el CVE 2021-26414 a partir de junio 2021 es un claro ejemplo de la complejidad del problema para las organizaciones industriales.

El contexto de los parches de seguridad en un servidor

Hace un poco más de un año, más precisamente en junio de 2021, Microsoft publicó la primera de las actualizaciones para corregir el problema reportado en el CVE mencionado, en donde básicamente lo que se intenta hacer es cambiar la forma en que sus sistemas operativos permiten el funcionamiento de conexiones cliente/servidor en la red a través del protocolo DCOM (Distributed Component Object Model).   Parecería poco importante en OT si no fuera porque DCOM se utiliza en los sistemas de control industrial a través del uso de conexiones OPC (versión clásico distribuido), y sabemos bien que OPC se utiliza habitualmente para interconectar sistemas de distintos fabricantes industriales.  Al día de hoy con las actualizaciones enviadas por Microsoft no hubo cambios reales en el funcionamiento de DCOM, sin embargo, se espera que el parche que se publicará en marzo del 2023 según lo anunciado por la propia empresa sí afecte al OPC clásico distribuido e incluso a otras comunicaciones basadas en DCOM.

¿Todas las versiones de OPC utilizan DCOM?

No, no todas implementaciones de OPC utilizan DCOM.   Las aplicaciones OPC que se verán afectadas son las DA/AE/HDA1 clásicas distribuidas (remotas) que deberán utilizar una configuración de autenticación con seguridad mínima denominada «Integridad de paquetes».  Las aplicaciones que utilicen OPC UA y OPC DA/AE/HDA clásicas locales no utilizan DCOM y por tanto no se ven afectadas ya que la función de cliente OPC se ejecuta de manera local.

Implementando seguridad: Notas generales

La implementación de una actualización de seguridad es, y seguirá siendo por bastante tiempo más, un desafío para los equipos técnicos de las organizaciones industriales.  Está claro que ya hay considerables avances con respecto a lo que sucedía años atrás, como por ejemplo el concepto de virtual patching en equipos de protección de red, la virtualización o el envío a la nube de servidores como Historian o Scada, etc.… sin embargo en la planta el riesgo a tener un problema luego de implementar una actualización es un riesgo vigente.  ¿Pero qué hacemos? ¿no hacemos nada? ¡Eso sería un gran error!   La gestión de la ciberseguridad en la planta implica conocer los riesgos a los que nos enfrentamos para luego poder gestionarlos, saber que hay un CVE con una vulnerabilidad reportada no implica entender el riesgo.  Debemos profundizar la lectura de la vulnerabilidad, como también la lectura de la documentación de la solución propuesta por el vendor o fabricante para entender si es aplicable de manera directa a mi instalación.  De la simple lectura, muchas veces encontramos información sobre lo que definimos como “workaround”, es decir soluciones indirectas a nuestro problema para evitar tener que instalar la actualización, pero también estar protegido ante el vector de ataque reportado.   Conocer el detalle de la vulnerabilidad reportada y la solución planteada implica tener gente con un claro conocimiento de los diversos sistemas interconectados a los sistemas de control y que sea capaz de analizarlos, es decir que requiere invertir en personal calificado o en formación al personal técnico para que sea calificado a futuro, de cualquier manera y sabiendo que este problema nos afectará por mucho tiempo, es un buen momento para empezar a abordarlo seriamente si aún no lo han hecho.

AUTOR:

Claudio Caracciolo

@holesec

Responsable de Plataformas, Innovación, Talento en el CCI

Coordinador General para LATAM

Ecosistema par avanzar juntos en Ciberseguridad Industrial
Networking | Conocimiento | Experiencias