Gestión de vulnerabilidades de OT: un enfoque basado en el riesgo
La cantidad de parches de seguridad que faltan en un sistema OT suele ser muy grande, se mide en miles, al menos. Sería difícil y costoso para el propietario de un activo evaluar cada parche de seguridad / par de activos cibernéticos faltantes. Esta puede ser una de las razones por las que vemos un enfoque de parchear todo, pero esto también es difícil y costoso. De hecho, las evaluaciones muestran que esto rara vez se hace, incluso cuando lo exige la política.
Un sistema de gestión de vulnerabilidades puede identificar los parches de seguridad que faltan para cada activo cibernético. De igual o mayor importancia, un sistema de gestión de vulnerabilidades puede ayudar al propietario de un activo a automatizar la decisión de qué parchear y cuándo. Si bien soy partidario de un enfoque de árbol de decisiones, ver ICS-Patch: Qué parchear cuando está en ICS, hay una serie de enfoques. La clave es que el proceso cumpla con dos criterios:
- Se desarrolla un proceso de aplicación de parches priorizado en el que los parches se implementan en un intervalo de tiempo relacionado con la reducción del riesgo de aplicar cada parche.
- La decisión está automatizada. La información se introduce en un proceso, lo que ayuda a decidir si parchear lo antes posible, programar la reparación en el intervalo regular de parches/mantenimiento o diferirla para cuando se actualice el software por otros motivos.
En un mundo perfecto, el software y el firmware nunca tendrían vulnerabilidades. En un mundo casi perfecto, todas las vulnerabilidades de software y firmware se repararían lo antes posible. No hay duda de que aplicar parches de seguridad es una buena práctica de seguridad y reduce el riesgo.
Sin embargo, la realidad de OT es que una cantidad muy pequeña de parches de seguridad dan como resultado una reducción significativa del riesgo, y la mayoría de los parches de seguridad que podrían aplicarse en OT dan como resultado una reducción de riesgo pequeña, casi nula. Por lo tanto, la clave para una gestión eficaz de vulnerabilidades de OT es hacer coincidir la velocidad y la frecuencia de los parches de seguridad con la reducción de riesgos lograda con el parche.
Un enfoque de aplicación de parches de seguridad basado en el riesgo como parte de la gestión de vulnerabilidades aún es raro. Muchos propietarios de activos determinan una cadencia de parches de seguridad, mensual, trimestral, semestral, etc., e intentan aplicar todos los parches de seguridad necesarios en este intervalo. Una vez más, esto no está mal en el sentido de que es una mala práctica. Está mal desde la perspectiva de la gestión de riesgos porque los recursos no se están aplicando para maximizar la reducción de riesgos.
Alta prioridad / Parche lo antes posible
Uno de los primeros pasos de cualquier programa de seguridad de OT es implementar un perímetro de seguridad entre OT y TI, generalmente en forma de firewalls y dispositivos de acceso remoto seguro. Si hay una vulnerabilidad en el firewall o en la solución de acceso remoto, debe repararse de inmediato porque la vulnerabilidad puede eliminar estos perímetros y permitir que los atacantes de TI accedan sin restricciones a OT. En muchos casos, querrá desconectar estos dispositivos de seguridad e interrumpir las comunicaciones de TI a OT hasta que se parcheen.
Este no es un tema hipotético. Los productos de seguridad son los principales objetivos de los ataques debido al valor de una vulnerabilidad para un atacante. Por ejemplo, en los últimos dos años, ha habido múltiples vulnerabilidades en Pulso Conectar Seguro y Fortinet Firewalls, ambos ampliamente utilizados en OT.
De manera similar, cualquier control de seguridad relacionado con el escaneo de medios extraíbles y computadoras portátiles transitorias antes de su uso en OT estaría en la categoría de alta prioridad/parche lo antes posible. Los activos cibernéticos, como las estaciones de escaneo USB, son en realidad otra forma de perímetro de seguridad: el perímetro para abordar los dispositivos físicos que se recorren alrededor del perímetro de seguridad cibernética.
Finalmente, cualquier activo cibernético al que se pueda acceder directamente desde la red de TI debe estar en la categoría Prioridad alta/Parche lo antes posible. Si su arquitectura sigue buenas prácticas de seguridad, estos serían principalmente activos cibernéticos en una DMZ de OT. Muchos propietarios de activos permiten alguna comunicación directa de TI a OT, y esto debe repararse lo antes posible porque un atacante en TI está a solo un paso de lograr un punto de apoyo en OT.
Prioridad baja/Aplazamiento/Parche para mantener en una versión compatible
La mayoría de los elementos de esta categoría son «inseguros por diseño». Esto significa que casi todo lo que un atacante querría hacer es posible sin necesidad de encontrar y explotar una vulnerabilidad. Si el atacante puede acceder al activo cibernético, puede hacer lo que quiera utilizando funciones documentadas que carecen de autenticación. (Esta es otra razón por la cual el perímetro de seguridad de OT es tan importante).
Los activos cibernéticos de OT más comunes en esta categoría son PLC, controladores y otros dispositivos Purdue Model Level 1. Si bien hay algunos modelos más nuevos con características de seguridad, más del 99% de estos dispositivos son inseguros por diseño. Si un atacante quiere aumentar la temperatura, hacer que algo gire más rápido o emitir otro comando de control, todo lo que debe hacer es enviar la solicitud de escritura adecuada.
Si un atacante quiere cambiar la lógica o el programa, solo necesita cargarlo porque generalmente no requiere autenticación. Lo que un atacante puede hacer está limitado por las habilidades de ingeniería y automatización, no por su capacidad de piratería. Muchos PLC ni siquiera requieren autenticación para cargar un nuevo firmware.
Se logra muy poca reducción de riesgos al parchear una vulnerabilidad en un dispositivo inseguro por diseño. Imagine que un PLC tiene una vulnerabilidad en su interfaz web o una vulnerabilidad en su servicio ftp. La aplicación del parche no ralentizaría ni distraería al atacante. De hecho, es más trabajo, e innecesario, que un atacante identifique el dispositivo que tiene la vulnerabilidad, explote la falla y luego aproveche el error.
Todo en el medio
Los activos cibernéticos de alta y baja prioridad para la gestión de vulnerabilidades se identifican fácilmente. Es una decisión más difícil sobre qué hacer con el resto de los activos cibernéticos en OT. Por un lado, si el atacante está en la red OT, puede aprovechar los dispositivos inseguros por diseño sin explotar ningún otro sistema. Por otro lado, muchas computadoras y dispositivos OT pueden fortalecerse para que sean más difíciles de comprometer.
Hay una serie de factores a considerar más allá del factor Exposición (que conduce a la cadencia ASAP) y el factor Inseguro por diseño (una Postura de seguridad clasificada) (que conduce a la cadencia Aplazar). Recomiendo considerar:
- Seguridad Impacto de una pérdida de disponibilidad o integridad del activo cibernético
- Proceso Impacto de una pérdida de disponibilidad o integridad del activo cibernético
- Impacto técnico de la vulnerabilidad (que suele ser un CVSS u otro puntaje)
Automatización de la decisión
Todos estos factores, y muchos otros que podría considerar, suelen ser estáticos y no cambian con el tiempo. Por ejemplo, el impacto en la seguridad de los activos cibernéticos, el impacto en el proceso y la exposición rara vez cambian. Agregar estos factores estáticos a un inventario de activos que admita los campos o agregar campos personalizados es un evento único con una revisión periódica. Si recién está comenzando su inventario de activos, pueden ser campos adicionales ingresados con cada activo cibernético.
El módulo de gestión de vulnerabilidades en su inventario de activos, y algunas secuencias de comandos u otro árbol de decisiones simple pueden tomar como entrada los miles de activos cibernéticos/pares de parches faltantes y generarlos en las categorías que ha asignado. Luego puede parchear cada categoría en la cadencia acordada.
La aplicación de parches de seguridad pasa de ser un proceso que requiere mucho tiempo y está separado de la gestión de riesgos a un proceso que aplica tiempo y otros recursos de acuerdo con un enfoque de gestión de riesgos. Aplicará los parches de seguridad que proporcionan una reducción significativa del riesgo mucho más rápido y aquellos que no lo hacen mucho más lento de lo que lo haría con una estrategia de parches de seguridad de talla única.
