Entornos ICS y gestión de parches: qué hacer si no puede aplicar parches

La evolución de las de amenazas de ciberseguridad destaca la necesidad emergente de que las organizaciones fortalezcan su capacidad para identificar, analizar y evaluar estos riesgos antes de que evolucionen a incidentes de ciberseguridad. Aunque los términos “gestión de parches” y “gestión de vulnerabilidades” se utilicen como si fueran intercambiables, la aplicación de parches es una de las muchas herramientas disponibles para mitigar los riesgos cibernéticos.

Beneficios y riesgos de aplicar parches (y gestión de parches)

Antes de decidir si instalar un parche o no, es importante que comprendamos los beneficios y riesgos asociados al hacerlo. ¿Vale la pena el parchear?

La razón más obvia para la aplicación de parches, y lo que las organizaciones generalmente piensan cuando se trata de parches, es la necesidad de corregir fallas de seguridad en el sistema operativo o en las aplicaciones. Sin embargo, este no es el único beneficio que obtiene al aplicar parches de manera oportuna y correcta. Muchos proveedores lanzan parches para mejorar la estabilidad de las aplicaciones. Este tipo de mejoras proporcionan un caso sólido para implementar parches en el entorno ICS porque la estabilidad y el tiempo de actividad de los dispositivos críticos son de suma importancia. Por último, los parches también pueden ayudar a resolver errores o fallas específicas en ciertas aplicaciones. Una vez más, este es otro beneficio, y fortalece el caso comercial de por qué las organizaciones deberían parchear.

Sin embargo, además de los beneficios, existen razones igualmente negativas o riesgosas para no aplicar parches. Esto está estrechamente relacionado con la forma en que se percibe el riesgo dentro del lado de IT del negocio en comparación con el lado de OT. Dentro del lado de IT de la organización, los beneficios superan los riesgos, ya que la pérdida de datos se considera una preocupación mayor que el tiempo de inactividad de una red. Por otro lado, para el lado OT, el tiempo de actividad de los sistemas es de gran importancia. La forma en que las dos partes de una organización (IT / OT) ven el riesgo versus el beneficio es muy diferente.

Centrándose en entornos ICS, donde la confiabilidad es un factor clave, un riesgo importante podría ser eliminar una red o componente crítico debido a un parche mal formado o dañado. Además, el aplicar parches puede considerarse como un trabajo que consume mucho tiempo y, en algunos casos, un trabajo de tiempo completo si consideramos que se descubren diariamente más de 15 nuevas vulnerabilidades.

Otro factor a considerar es el costo asociado con probar los parches lanzados. Nuevamente, los lados de IT y OT del negocio tienen diferentes factores de costo a considerar. Ambas partes tienen que construir laboratorios para probar los parches antes de implementarlos en los sistemas de producción. En el mundo OT, se debe comprar hardware que imite los sistemas de producción reales, a diferencia del mundo de IT, donde podría imitar los sistemas de producción con el uso de entornos virtuales. La logística y los costos asociados detrás de la replicación de los sistemas de producción de OT superan con creces el tamaño de los sistemas de IT.

Además, IT también podría utilizar soluciones automatizadas de implementación de parches que reducirían enormemente la cantidad de personal y horas de trabajo necesarias para probar todos esos parches. Desafortunadamente, este no es el caso con OT. Los parches tienen que ser probados en cada dispositivo individualmente, y lo más probable es que los equipos de OT tengan que depender del especialista o proveedor para entregar las actualizaciones ellos mismos. Esto incurre en una relación de costo a beneficio mucho más alto que en el lado de IT.

Lo último que debemos tener en cuenta son los ciclos de producción del proveedor (EOL). Esto no es un gran riesgo en el lado de IT de la organización. Probar y actualizar el sistema operativo, por ejemplo, es mucho más fácil con el uso de soluciones como entornos virtuales. Si combinamos eso con la preocupación por el tiempo de actividad que es mínima, es mucho más fácil lidiar con los problemas de EOL dentro del lado de IT que dentro del lado OT del negocio. En entornos OT, algunos sistemas de producción han existido durante más de veinte años. En la mayoría de los casos, probablemente nunca se hayan actualizado o parcheado. Pedirle a personal de OT que se arriesgue a aplicar parches a un sistema que ha estado funcionando sin problemas durante décadas en beneficio de hacer que sea más difícil ser hackeado es algo difícil de lograr.

El adagio de “no es si te hackean, sino cuando te hackean” resalta el riesgo de no hacer nada. Desafortunadamente, muchas organizaciones OT todavía creen que a ellos no les puede pasar o no les sucederá. Sin embargo, el riesgo asociado con “cuando te hackean” debe analizarse con mayor detalle y compararse con la probabilidad de un “shutdown” incontrolable e inesperado de los sistemas en lugar de aplicar parches controladamente, manual y segmentadamente.

IT contra OT

Para comprender las diferencias en la percepción del riesgo y la priorización entre IT y OT, sería útil revisar cómo estos dos mundos ven la tríada de la seguridad CID (Confidencialidad, Integridad, Disponibilidad).

Para el lado de IT, la confidencialidad tiene la máxima prioridad. Perder algo valioso, como los datos personales del cliente o del personal, podría ser catastrófico para cualquier organización y podría implicar pérdidas financieras, daños a la reputación y sanciones regulatorias. La integridad es la segunda mayor preocupación para las organizaciones de IT. El manejo de marca y la retención de clientes podrían verse enormemente afectados si una organización tiene que admitir que han tenido una brecha y que se han robado datos o propiedad intelectual. Un incidente que afecte la integridad también podría dar como resultado pérdidas financieras, y las organizaciones podrían enfrentar problemas tales como multas o incluso la pérdida de ingresos comerciales de clientes insatisfechos.

La última preocupación es la disponibilidad. A las organizaciones les gusta y se esfuerzan por mantener la disponibilidad del sistema, especialmente en sistemas orientados al cliente. Sin embargo, si un sistema deja de funcionar, el impacto en el tiempo medio de reparación (MTTR) es mucho menor en los entornos de IT que dentro de las organizaciones OT. Reconstruir un sistema a partir de una copia de seguridad virtual es mucho más simple que tener que quitar un dispositivo físico de producción y reemplazarlo por uno nuevo, lo que generalmente requiere un especialista de proveedor aumentando el costo y el downtime.

Por otro lado, para las organizaciones OT, la disponibilidad tiene la máxima prioridad. Esto es completamente comprensible, ya que el costo asociado con el tiempo de inactividad del sistema, incluso uno corto, podría ser de millones de dólares o euros. Sin mencionar que tales “downtimes” o tiempos de inactividad pueden tener un impacto significativo en la sociedad en general. Solo imagine cuántos hogares se verían afectados por el downtime de una red eléctrica. Además, el quitar repentinamente sistemas OT de producción puede obstaculizar otras organizaciones o industrias, ya que las interconexiones y las interdependencias entre productos y servicios son muy fuertes.

La integridad viene como segunda prioridad, con IT, por las mismas razones: marca, pérdida de ingresos y multas. Lo último en la lista de prioridades es la confidencialidad, aunque no debe verse con mínima preocupación. De hecho, la pérdida de datos confidenciales o secretos debido al espionaje industrial puede tener consecuencias aún más graves para la organización como la pérdida de datos personales.

A pesar de todas estas diferencias, IT y OT comparten un terreno común, y eso es la seguridad. Pero no es lo único, al observar la siguiente ilustración de sistemas y soluciones específicas para cada lado de la organización, nos damos cuenta de que se superponen en muchas áreas, como descubrimiento de activos, evaluación de vulnerabilidades, gestión de políticas, detección de cambios, evaluación de configuración y manejo de registros o logs.

Con organizaciones que convergen OT y IT que esencialmente informan bajo un mismo paraguas técnico, es fácil comprender los beneficios de usar una herramienta SIEM típicamente IT para analizar todos los datos OT. IT ya tiene un equipo de operaciones centralizado y las herramientas para poder identificar rápidamente posibles patrones maliciosos de interés y alertar al equipo OT. El equipo OT tendría que lidiar con un solo evento en lugar de tener que lidiar con el ruido proverbial, reduciendo los costos asociados y el personal necesario.

¿Qué se puede hacer si no podemos parchear?

Habiendo analizado las diferencias entre IT y OT y el costo-beneficio de la aplicación de parches en entornos ICS, estamos en una mejor posición para comprender por qué sería necesario evitar la aplicación de parches en ciertas circunstancias. Si no podemos aplicar parches, ¿qué más se puede hacer?

Todo empieza por reconocer que la administración de parches es solo un área de la gestión de vulnerabilidades. La gestión de vulnerabilidades no es una función independiente de escaneo y parchado. Es una función proactiva que tiene la visión holística de administrar la desalentadora tarea de abordar las vulnerabilidades identificadas en los dispositivos de hardware y software.

La gestión de vulnerabilidades es más que solo recibir alertas cada vez que su infraestructura necesita un parche. La gestión de vulnerabilidades consiste en tomar decisiones informadas y priorizar adecuadamente qué vulnerabilidades mitigar y cómo. Esto se logra al incorporar ganchos internos para telemetría en todos los sistemas de interés, así como ganchos externos para inteligencia de amenazas de todas las fuentes.

En base a estas consideraciones, si las organizaciones de ICS no están en condiciones de aplicar un parche como mínimo deberían de hacer lo siguiente:

1. Análisis o descubrimiento de activos para saber lo que tiene en su entorno y protegerlo. Este proceso podría plantear una pregunta básica de seguridad: ¿realmente necesitamos todos estos activos o estamos pasando tiempo tratando de asegurar cosas que no son necesarias?
2. Protección perimetral para fortalecer su organización contra la intrusión física y digital. Esto podría incluir cualquier cosa, desde firewalls hasta controles de acceso.
3. La segmentación, que viene con muchos beneficios al intentar defenderse de movimientos laterales al mismo tiempo que contiene un incidente de seguridad para no dañar a el resto de la organización.
4. Manejo de logs, que no debe usarse como una herramienta IDS o para detectar cambios, sino como una herramienta diseñada para buscar movimiento dentro de la organización que indiquen posibles ataques.
5. Evaluación de vulnerabilidades para determinar posibles puntos débiles e identificar la postura de riesgo por vulnerabilidades de cada activo. Una vez que se completa el análisis, se asigna un puntaje a cada vulnerabilidad encontrada en función de las habilidades requeridas para explotarla y los privilegios obtenidos tras una explotación exitosa. Cuanto más fácil sea explotar la vulnerabilidad y cuanto mayor sea el privilegio obtenido, mayor será el puntaje de riesgo.
6. File Integrity Monitoring (FIM) para poder monitorear los cambios reales que tienen lugar dentro de la organización ICS. Si bien los pasos anteriores mencionados cubren predominantemente las amenazas externas y el monitoreo, FIM echa un vistazo dentro de la organización e intenta correlacionar el movimiento con los cambios reales para reducir aún más el ruido y dar la alarma.

Cómo ayuda Tripwire

La cartera de Tripwire consta de las mejores soluciones en el mercado, ya sea integradas o como soluciones independientes ofrecen a los clientes la máxima flexibilidad. El monitor de integridad de Tripwire es una solución que evalúa la integridad y configuración de archivos que puede alertar sobre todos los cambios que tienen lugar dentro de la red de una organización, proporcionando información detallada sobre el cambio, como quién realizó el cambio, cuando ocurrió el cambio y también cuál fue el cambio realizado con la posibilidad de tener una comparación lado a lado del estado original con el actual.

Tripwire IP360 es una herramienta de vulnerabilidades que no solo tiene la funcionalidad para descubrir activos en la red, sino que también los coteja con una base de datos de vulnerabilidades conocidas con más de 130 mil pruebas únicas. IP360 también es único en la forma que prioriza las vulnerabilidades con su propio algoritmo de puntuación. Este método de priorización es muy poderoso, ya que ayuda a reducir la cantidad de vulnerabilidades en las que una organización debería enfocarse, lo que facilita la estrategia de administración de parches de una organización.

Tripwire Log Center podría considerarse como un historiador inteligente que proporciona una recopilación de logs completa, segura y confiable, y destaca eventos de interés dentro de un mar de datos.

Finalmente, Tripwire Industrial Visibility (TIV) es una solución específica de ICS que ha sido diseñada para capturar, procesar y alertar sobre los mismos elementos críticos que Tripwire Enterprise e IP360 desde una perspectiva de análisis de paquetes, es decir, sin agentes en el tráfico “dentro del cable.”

Tener todas las soluciones de Tripwire integradas proporcionaría no solo las medidas de seguridad recomendadas como un mínimo absoluto (incluida la administración de parches) sino que también proporcionarían procesos que podrían reducir la cantidad de datos requeridos para detectar posibles amenazas. Tener la capacidad de usar tecnologías basadas en agentes y sin agentes garantizará que las organizaciones incluyan todos los dispositivos dentro de su infraestructura sin preocuparse por la estabilidad, garantías y variabilidad de end points. Si una organización considera que un dispositivo es crítico, independientemente de cuál sea, este debe ser monitoreado y reportado, ¡sin excusas! Esa es la filosofía detrás de la gestión de parches.

The post ” Entornos ICS y gestión de parches: qué hacer si no puede aplicar parches” appeared first on TripWire

Source:TripWire – Denisse Vega