RSAC 2020: Facilitar el cumplimiento con una gestión de parches más rápida

Durante la Conferencia RSA 2020, el CEO de KernelCare, Igor Seletskiy, tuvo la oportunidad de compartir las mejores prácticas para permitir el cumplimiento con una gestión de parches más rápida. En este artículo encontrarás los puntos clave de la ponencia.

Para las empresas, cumplir la normativa no es una moda, es una necesidad. Cada vez más, los clientes no harán negocios con usted a menos que cumpla las normas. El incumplimiento puede causar graves pérdidas, en ingresos y en toda la empresa.

Las buenas prácticas en materia de cumplimiento afectan a todos los aspectos de la actividad de su empresa, desde los departamentos de personal y RRHH hasta el núcleo mismo de su infraestructura informática. Hay docenas de normas entre las que elegir.

Si nos fijamos en SOC2 o la Ley Sarbanes-Oxley, por ejemplo, dicen que "las vulnerabilidades del software deben mitigarse en un plazo de 30 días". Si alguna vez has gestionado una flota de servidores, sabrás que es más fácil decirlo que hacerlo.

Por eso hoy quiero explicarte cómo puedes cumplir la normativa racionalizando la gestión de parches, y por qué la gestión de parches es crucial para la seguridad y el cumplimiento de la normativa.

¿Por qué es importante la gestión de parches?

En primer lugar, ¿por qué es tan importante la gestión de parches?

Todos sabemos que el software obsoleto o vulnerable es una de las principales causas de las brechas de seguridad. He aquí algunos ejemplos para recordárnoslo:

1. La filtración de datos de Equifax en 2017, en la que una vulnerabilidad no parcheada de Apache Struts llevó a los hackers a robar los datos de casi 150 millones de clientes. La vulnerabilidad significa que un hacker puede ejecutar comandos bajo los privilegios del servidor web. Se trata de una ejecución remota de comandos completa y ha sido explotada activamente desde su divulgación inicial. Equifax ha perdido cerca de 700 millones de dólares, y todavía están contando el coste de su... seamos amables y digamos "descuido".
2. La filtración de datos de Marriott en 2018, un hackeo que filtró entre 300 y 500 millones de registros de clientes de un sistema de reservas hoteleras. Marriott recibió una alerta de una herramienta de seguridad interna el 8 de septiembre de ese año, advirtiéndoles de que alguien estaba intentando acceder a su base de datos de reservas de huéspedes de Starwood en Estados Unidos. Cuando investigaron, descubrieron que una parte no autorizada había copiado material de la base de datos, lo había cifrado y lo había descargado. La razón de esta violación de datos fue un software sin parches en un sistema adquirido previamente por Marriott (la red Starwood) que permitió a los piratas informáticos acceder a la base de datos de clientes.
3. Filtración de datos de una empresa eléctrica Fortune-500. Una compañía eléctrica anónima infringió las normas de seguridad obligatorias al ignorar los parches de software del sistema de control físico durante más de un año, poniendo en peligro el suministro eléctrico de millones de hogares. La causa fue una mala configuración que impidió que el sistema se actualizara automáticamente. Esta empresa no tenía copias de seguridad porque el sistema estaba siendo desmantelado. No querían hacer parches manuales porque habría significado un reinicio. Aunque la empresa autodenunció el incidente al Western Electricity Coordinating Council y pagó una sanción, siguió incumpliendo la normativa hasta julio de 2017, cuando se sustituyeron los sistemas de control de acceso físico en cuestión y se implantó un nuevo programa de gestión de parches de seguridad.

Related post: Tres violaciones de datos de renombre

Estos son sólo algunos de los muchos casos que ayudan a explicar la importancia de la gestión de parches. El problema es que sólo los grandes nombres y las grandes violaciones de datos aparecen en los titulares. Para ver lo que quiero decir, echa un vistazo a privacyrights.org. Tienen una hoja de cálculo con más de 9.000 casos, y eso sólo en Estados Unidos. Imagínate todos los demás casos no denunciados en el resto del mundo.

Así pues, todos deberíamos saber que es necesario parchear el software vulnerable en un plazo de 30 días desde que una vulnerabilidad se hace pública. Una práctica de seguridad informática esencial es buscar vulnerabilidades y luego parchearlas, normalmente mediante una herramienta de gestión de parches.

De uso obligatorio: Escáneres de vulnerabilidades y herramientas de gestión de parches

Tal vez haya oído hablar de algunos de estos escáneres de vulnerabilidades.

1. 1. Qualys
   2. Nessus
   3. Rápido7

Estas herramientas facilitan enormemente la gestión de vulnerabilidades. Incluso pueden encontrar y parchear vulnerabilidades por usted, lo que realmente ayuda al personal de seguridad y operaciones. Los escáneres detectan y clasifican los puntos débiles del sistema, priorizan las correcciones y, en ocasiones, pueden ayudar a predecir la eficacia de las contramedidas.

Normalmente, la superficie de ataque objetivo se busca en una base de datos de información sobre agujeros de seguridad conocidos, que incluye detalles como anomalías en la construcción de paquetes y rutas a programas o scripts explotables.

1. Herramientas de gestión de parches
   1. Actualización de Yum / apt
   2. Ansible
   3. Marioneta
   4. SaltStack
   5. Chef
   6. Paseo espacial

Este tipo de herramientas automatizadas de gestión de parches alivian la presión de los administradores de sistemas. Si habla con alguno, le dirá lo estupendo que es disponer de algo que descargue e instale automáticamente los parches en distintos dispositivos. Los parches para servidores Linux se despliegan con mayor rapidez y fiabilidad.

Gestión de parches - Algunas buenas prácticas

Las empresas suelen pensar en utilizar herramientas automatizadas de gestión de parches cuando su parque de servidores Linux supera los 40 ó 50. A partir de ese número, los departamentos de TI se ven tan desbordados por la aplicación manual de parches que acaban desplegando únicamente los parches urgentes o de alta prioridad.

Los parches de Linux implican algo más que una simple actualización del código fuente de un núcleo. Estos parches incluyen actualizaciones que garantizan la seguridad del sistema, minimizan los errores e introducen las últimas funciones. Pero lo más importante es que una gestión adecuada de los parches puede mejorar enormemente la seguridad de una empresa, al abordar las vulnerabilidades de su software y sus sistemas operativos.

Pero parchear servidores Linux puede ser complejo. El desarrollo de software de código abierto está menos reglamentado, por lo que las actualizaciones tienen cadencias de lanzamiento más impredecibles. El software de código abierto también se ejecuta en todos los puntos de la pila de software, por lo que los cambios deben analizarse cuidadosamente.

Aunque la mayoría de las actualizaciones son tan sencillas como ejecutar un comando de Linux, no se trata sólo de los aspectos técnicos. También hay cuestiones organizativas. Hay que hacer un seguimiento de lo que hay que actualizar y comprender el impacto de las actualizaciones. Las actualizaciones deben probarse y ponerse en marcha, y el cambio debe comunicarse a todos los departamentos.

Según un estudio del Ponemon Institute, las organizaciones dedican anualmente una media de 18.000 horas, con un coste de 1,1 millones de dólares, a actividades de aplicación de parches. A pesar de este esfuerzo, muchos han visto una reducción en el tiempo que tarda en aparecer un exploit en la naturaleza para una vulnerabilidad parcheada dada. Si no se aplican las mejores prácticas de gestión de parches, las empresas perderán tiempo y se arriesgan a dejar la puerta abierta a los ataques.

También en ese estudio de Ponemon figuraba el hecho de que casi dos tercios de las víctimas de ciberataques afirmaron que la aplicación de un parche habría evitado el ataque. Y un tercio dijo que conocían la vulnerabilidad antes del ataque pero no hicieron nada. Da miedo.

Así pues, está claro que un proceso sólido de gestión de parches es una parte esencial de un marco de seguridad maduro. Cuanto más rápido pueda aplicar el parche adecuado a la aplicación correcta, más seguro será su entorno.

Aunque la gestión de parches es un reto, no es imposible. Hay una serie de mejores prácticas de gestión de parches que las empresas utilizan en su beneficio:

1. En primer lugar, realizan un inventario exhaustivo de todo el software y hardware del entorno. Una vez que la empresa tiene una idea clara de lo que tiene, compara las vulnerabilidades conocidas con el inventario para descubrir rápidamente qué parches son importantes.
2. Ya he mencionado que las empresas pierden una media de 18.000 horas al año por parchear los sistemas equivocados. Hay una forma de evitarlo. Aunque todos los sistemas deben parchearse, tiene sentido asignar niveles de riesgo a cada elemento del inventario. Por ejemplo, la aplicación de parches en algunos componentes puede ser una actividad planificada, mientras que la aplicación de actualizaciones de seguridad contra las principales CVE en el kernel de Linux es crítica para la empresa. Una regla de oro es: cuanto más expuesto a ataques esté un elemento, más rápido debe parchearse.
3. Las empresas acostumbran a consolidar las versiones de software (y el propio software). Cuantas más versiones de un software utilice la organización, mayor es el riesgo de exposición. También crea grandes cantidades de sobrecarga administrativa. Revise periódicamente todo el software en uso y su finalidad, encuentre varias piezas de software que realicen la misma función, elija una y deshágase del resto.
4. Otra práctica común en el proceso de gestión de parches es mantenerse al día de los anuncios de parches de los proveedores y crear un proceso para garantizar que cada parche pueda añadirse al calendario de parches.
5. A veces, la aplicación de un parche requiere más tiempo, cuando hay que realizar los cambios necesarios para que el parche funcione. En estos casos, las empresas mitigan el riesgo en la medida de lo posible. Es importante reducir el impacto y la probabilidad de un exploit hasta que el parche pueda aplicarse con seguridad.
6. No importa lo entusiasmado que esté por conseguir un nuevo parche y aplicarlo a todos los servidores de producción a la vez: pruébelo primero. Porque cada entorno es único, incluso un simple parche puede causar problemas o hacer caer los servidores. Normalmente, las empresas toman un pequeño subconjunto de sus sistemas y les aplican el parche para asegurarse de que no hay problemas graves.

Parcheado de núcleos Linux

El 99% de los tipos de parches no requieren reiniciar el sistema. Pero cuando se trata de parchear el núcleo de Linux, el 99% de las organizaciones aplican los parches de la misma manera: reiniciando sus servidores. Como reiniciar una flota de servidores es un quebradero de cabeza, la gente lo pospone todo lo que puede. Esto significa que los parches no se aplican lo antes posible. Este desfase entre la emisión del parche y su aplicación supone un riesgo, y también una mala praxis.

Además, la mayoría de las empresas no pueden desconectarse, lo que dificulta mantener actualizado el software del sistema. Las empresas se enfrentan a ello desarrollando ventanas de mantenimiento o ciclos de reinicio y siguiéndolos rígidamente. Estas prácticas requieren mucho tiempo de planificación y muchos recursos de aplicación, y aun así acaban con un reinicio del sistema y el inicio de otro ciclo de reinicio. He aquí un proceso de parcheo típico.

1. En primer lugar, hay que saber qué parchear. Esto significa disponer de un inventario preciso de los sistemas que abarque todos los servicios y plataformas de la empresa.
2. Luego hay que calcular el impacto y poner en marcha algún tipo de proceso de gestión del cambio.
3. Hay que probar, y tiene que ser repetible y auditable.
4. A continuación, la alegría de negociar las ventanas de mantenimiento con docenas de partes interesadas, todas ellas ansiosas por evitar cualquier golpe en sus SLA y registros de tiempo de actividad.
5. Luego se hace la actualización. A menudo, esa es la parte más fácil, salvo para los ingenieros que tienen que trasnochar y trabajar los fines de semana.
6. Finalmente, planeas otro ciclo de reinicio. Y así sucesivamente.

Pero, ¿por qué es tan complicado este proceso? ¿Cuál es la verdadera razón? Yo se lo diré. Es porque:

1. Los reinicios son difíciles de gestionar.
2. Los reinicios requieren programar el tiempo de inactividad.
3. Los reinicios ponen nervioso: ¿y si el sistema no vuelve a funcionar?
4. Cuantos más servidores tengas, más problemáticos serán los reinicios.

Muchas empresas tuvieron que trabajar con software sin parches durante más de 30 días. 
Muchos casos demuestran que incluso un día con un sistema desprotegido puede acabar en una violación de datos 
y miles de millones de dólares de pérdidas. 

Los clientes de KernelCare tienen servidores totalmente parcheados que llevan funcionando sin parar más de 6 años, y es compatible con las principales distribuciones de Linux. Funciona en la nube o in situ, detrás de cortafuegos o en entornos protegidos. Es compatible con escáneres de vulnerabilidades y soluciones de gestión de parches, así como con parches de kernel personalizados.

Así es como funciona:

KernelCare ha ayudado a empresas con más de 300 000 servidores a conseguir la certificación SOC2. He aquí algunas de ellas.

1. Efinity Insurance - Aseguradora online con clientes en 14 países y toneladas de datos personales. Ganan dinero vendiendo un servicio de cotización de seguros en tiempo real. Está implementado en Java y se ejecuta en CentOS en AWS. Por diversos motivos, no pueden agrupar esta aplicación en clústeres, por lo que recurrieron a nosotros para mantener sus servidores en conformidad, es decir, parcheados, sin perder la disponibilidad del servicio. Más información en este caso práctico.
2. Uno de nuestros clientes es una famosa empresa de pagos digitales en línea, una fortuna-500 con cientos de millones de clientes, kernels Linux personalizados y sistemas estrictamente firewall. Estoy seguro de que los conocerías si me permitieran revelar el nombre, pero hemos firmado un acuerdo de confidencialidad con ellos, así que lo siento. Todo lo que puedo decir es que también utilizan KernelCare para mantener los parches de seguridad de cientos de núcleos diferentes sin reiniciar, algo esencial para los servicios de pago electrónico continuos. Más información en este estudio de caso.
3. Una conocida solución de videoconferencia para empresas. Su analista de conformidad se puso en contacto con nosotros en primer lugar. Tenían pendiente una auditoría SOC2 y los ciclos de reinicio les impedían cumplir los criterios de conformidad. Pasaron dos meses probando KernelCare y luego pasaron a una PoC formal. Sólo duró 7 días antes de pasar KernelCare a producción. Les ayudamos a integrarse con Ansible para distribuir KernelCare a más de 7.000 servidores. También obtuvimos una gran retroalimentación y trabajamos con ellos con respecto a su integración con el escáner de vulnerabilidades Qualys que necesitaba ver escaneos completamente limpios.

KernelCare mejora el cumplimiento de normativas en más de 300.000 servidores de diversas empresas en las que la disponibilidad del servicio y la protección de datos son las partes más cruciales del negocio: servicios financieros y de seguros, proveedores de soluciones de videoconferencia, empresas que protegen a las víctimas de abusos domésticos, empresas de alojamiento y proveedores de servicios públicos.

Ofrecemos precios flexibles para distintas flotas de servidores, una prueba gratuita para todo el mundo y pruebas de concepto a medida para clientes con infraestructuras personalizadas.

Obtenga una prueba GRATUITA de 7 días con soporte de KernelCare