La vulnerabilidad log4j es una laguna de seguridad cibernética que explota una pieza de software pequeña y casi omnipresente llamada log4j, que se utiliza para registrar las actividades de varios programas informáticos. Este registro de eventos, errores y operaciones rutinarias del sistema se realiza para que los mensajes de diagnóstico se puedan comunicar a los administradores y usuarios del sistema. Sin embargo, log4j también permite que los servidores de terceros envíen código de software que, en manos de un pirata informático, podría usarse para realizar acciones maliciosas en un sistema objetivo, como robar información confidencial, tomar el control de un sistema o pasar contenido malicioso a otros usuarios que se comunican con el servidor afectado.
Actualmente, no se ha puesto a disposición información sobre compromisos de log4j para ningún sistema de control industrial (ICS). Aún así, debido a que el código se usa con tanta frecuencia, sigue siendo completamente posible. Para obtener más información sobre cómo los operadores industriales pueden proteger sus sistemas, Automation World habló con Dennis Hackney, jefe de desarrollo de servicios de ciberseguridad industrial en ABS Group, una empresa de gestión de riesgos operativos y proveedor de servicios de consultoría de ciberseguridad.
Cómo la vulnerabilidad de Log4j puede afectar un ICS
Si se produce un ataque de log4j, se podría ejecutar un código malicioso en un ICS, otorgando a un actor de amenazas la capacidad de tomar el control de las aplicaciones utilizadas para ver y controlar los procesos físicos, dice Hackney. Si se cuenta con un sistema de seguridad del ICS, esta pérdida de control solo puede resultar en un apagado temporal del sistema desde el cual se puede reiniciar el ICS a un estado anterior. Sin embargo, si no existe un sistema de seguridad y el software que controla el ICS está comprometido, un pirata informático podría obtener el control. Esto puede ocurrir incluso si el software en el ICS violado no controla un proceso directamente. En el peor de los casos, donde una aplicación controla procesos físicos que involucran maquinaria grande, como bombas, válvulas o tanques que contienen materiales peligrosos o están muy cerca de los empleados, podrían producirse riesgos de seguridad catastróficos y graves.
Según Hackney, una violación de log4j podría dar lugar a varias situaciones hipotéticas:
· Si un servidor histórico se viera comprometido, los datos de procesos históricos relacionados con las tendencias de procesos o el rendimiento del sistema de control podrían ser robados.
· Si un servidor SCADA (control de supervisión y adquisición de datos) se ve comprometido, los actores de amenazas podrían ver o controlar los procesos interpretando los datos, realizando cambios de control o modificando las lecturas de los sensores de una manera que pasa desapercibida para los operadores. Esto podría provocar daños en el equipo, accidentes ambientales o incluso lesiones a los empleados.
· Si se instalara ransomware en un ICS, todo el sistema podría cerrarse, lo que obligaría a los operadores a pagar una tarifa de rescate o participar en una reconstrucción completa de sus servidores y estaciones de trabajo ICS.
¿Cómo se pueden proteger las operaciones industriales contra los ataques de Log4j?
Hackney también ofrece varias sugerencias sobre cómo los usuarios finales de los sistemas de control pueden volverse más proactivos para prevenir un posible ataque log4j:
· Identifique y aísle cualquier ICS crítico de Internet y las redes comerciales.
· Desarrolle soluciones alternativas de aislamiento y control manual que limiten la cantidad de impactos operativos que podrían ocurrir si se descubre una vulnerabilidad como log4j.
· Supervise las conexiones salientes necesarias para las amenazas cibernéticas. Muchos ICS producen comunicaciones salientes relacionadas con el mantenimiento, la medición, el diagnóstico y más.
· Asegúrese de que se realicen copias de seguridad frecuentes y de que existan procedimientos de copia de seguridad rígidos. Si los operadores tienen una copia de seguridad estable de su ICS, pueden garantizar que, en caso de que ocurra un incidente, puedan volver a poner sus sistemas en línea lo más rápido posible.
· Actualice la versión de log4j utilizada en sus sistemas. El National Institute of Standards Vulnerability Database informa que Log4Shell (el nombre de la vulnerabilidad log4j) se desactivó de log4j 2.15.0 y se eliminó por completo de la versión 2.16.0.
Además, hay pasos que pueden tomar los proveedores de ICS y los fabricantes de equipos originales (OEM), dice Hackney. Por un lado, deberían anunciar cualquier vulnerabilidad de log4j que exista en sus productos, ya que es posible que los usuarios finales ni siquiera las conozcan. A partir de ahí, deberían lanzar soluciones, mitigaciones y parches para ayudar a prevenir una infracción de log4j. Los fabricantes de equipo original también pueden ayudar a sus clientes a descubrir vulnerabilidades de log4j mediante el desarrollo de servicios de soporte especializados. Esto no solo ayudaría a los usuarios finales a protegerse más fácilmente, sino que también podría beneficiar a los fabricantes al brindarles a sus clientes acceso a un servicio premium que los competidores pueden no brindar. Según Hackney, este servicio podría brindarse a través de una línea directa de respuesta cibernética a la que los clientes podrían llamar para recibir orientación sobre la mejor manera de descubrir y abordar las vulnerabilidades en su ICS. Finalmente, Hackney recomienda que todos los proveedores de ICS y OEM actualicen sus procesos de prueba de diseño, ingeniería y aceptación para incluir prácticas de ciberseguridad y gestión de vulnerabilidades.
