Esta guía detallada habla sobre por qué los equipos de seguridad están abrumados por las vulnerabilidades, el peligro que se esconde detrás del doble informe de vulnerabilidades y cómo mitigar dichas vulnerabilidades utilizando herramientas de parcheo en vivo como KernelCare.
Sabemos que la amenaza a la seguridad cibernética está creciendo, con un crecimiento equivalente en los esfuerzos para tratar de mitigar la amenaza y los costos asociados. Pero la evidencia sugiere que la mitigación no está progresando lo suficientemente rápido.
Según un análisis conjunto realizado por McAfee y el Centro de Estudios Estratégicos e Internacionales , en 2020 el costo global del ciberdelito aumentará más allá del 1 billón de dólares marca por primera vez:un aumento masivo del 50% sobre el total de 2018. Esa es una tasa de cambio que supera claramente cualquier métrica comparable, como el crecimiento del PIB o el crecimiento del gasto en TI.
La concientización no es el problema; después de todo, las empresas están gastando grandes sumas de dinero para defenderse de las ciberamenazas.
En cambio, en este artículo, argumentamos que los jugadores de seguridad cibernética están esencialmente abrumados por los desafíos que enfrentan. Señalamos una ocurrencia reciente de doble informe de vulnerabilidades conocidas como evidencia clara.
Siga leyendo para ver por qué los equipos de seguridad se ven abrumados por las vulnerabilidades, cómo afecta la aplicación de parches y qué pueden hacer los equipos para aplicar parches de manera constante frente a una avalancha incesante de vulnerabilidades y exploits.
¿Otra vulnerabilidad más?
En la segunda mitad del año pasado, se descubrió e informó una vulnerabilidad del kernel de Linux. Se le asignó una C común V vulnerabilidades y E número de exposiciones (CVE), CVE-2020-29369 , y la vulnerabilidad se corrigió como se esperaba. Hasta ahora nada inusual.
Tampoco había nada fuera de lo común en la vulnerabilidad en sí. En cualquier sistema operativo, el núcleo debe administrar la memoria con cuidado, asignando (asignando) espacio de memoria cuando una aplicación lo necesita y eliminando correctamente las asignaciones y reasignando memoria libre cuando una aplicación ya no la necesita.
Sin embargo, este proceso de administración del espacio de memoria puede ser propenso a fallas. Cuando se codifica sin el cuidado necesario, los procesos de manejo de la memoria del kernel pueden brindarles una oportunidad a los ciberdelincuentes. En el caso de CVE-2020-29369, el problema ocurrió en la función mmap que se usa para el mapeo de memoria en Linux.
La naturaleza de la vulnerabilidad significaba que dos aplicaciones distintas podían solicitar acceso al mismo espacio de memoria, lo que provocaba un bloqueo del kernel.
Si un atacante jugó sus cartas correctamente, en otras palabras, diseñó un exploit, el atacante podría obtener datos que de otro modo estarían protegidos por el kernel. Podrían ser datos completamente inocuos, o algo más valioso, como datos personales valiosos o contraseñas.
Una historia de dos informes de vulnerabilidad
Entonces podemos ver que se informó una vulnerabilidad típica y se aceptó según los procedimientos habituales. Pero algo desconcertante sucedió a continuación.
Solo unos meses después, se informó exactamente la misma vulnerabilidad. Nuevamente, se asignó un número CVE, esta vez CVE-2020-20200 . Sin embargo, pronto resultó que la nueva alerta de vulnerabilidad era un duplicado de otra vulnerabilidad:CVE-2020-29369.
Los investigadores que "encontraron" la vulnerabilidad por segunda vez por algún motivo no pudieron encontrar la primera instancia de la vulnerabilidad antes de solicitar otra reserva de CVE para lo que habían descubierto. Una de las intenciones principales de las bases de datos de CVE es evitar la doble notificación, pero en este caso en particular, se solicitó otro CVE.
Este caso de lo que se llama “doble reporte” no es la primera ni la única instancia de una vulnerabilidad que se informa dos veces. Peor aún, cuando las investigaciones sobre una vulnerabilidad llegan al punto en que se asigna un CVE, la vulnerabilidad ya habrá sido revisada por numerosos expertos en seguridad altamente capacitados.
Incluso los investigadores de seguridad pueden mezclarlo
En este ejemplo de informe doble, está claro que los investigadores de seguridad deberían haber sido conscientes de la vulnerabilidad existente o deberían haber encontrado el CVE existente si investigaron suficientemente la "nueva" vulnerabilidad antes de solicitar un nuevo número de CVE.
Es un pensamiento preocupante. Esta vulnerabilidad de mapeo de memoria se encuentra en el núcleo del kernel de Linux, pero los investigadores de seguridad aparentemente no la conocían, de ahí la doble lista. Peor aún, no es como si cada listado tuviera una década o incluso años de diferencia:los listados individuales de la misma vulnerabilidad se realizaron con solo meses de diferencia, uno en agosto de 2020 y otro en noviembre de 2020.
¿Son negligentes los investigadores de seguridad? No. Los investigadores de seguridad simplemente están completamente abrumados por el gran volumen de desafíos de ciberseguridad. Es por eso que, en este ejemplo, los expertos en seguridad del kernel de Linux pasaron por alto un informe existente de una vulnerabilidad potencialmente crítica.
El peligro oculto detrás del doble informe de vulnerabilidades
La evidencia clara de que la amenaza a la seguridad cibernética está creciendo, combinada con ejemplos en los que incluso los expertos en seguridad se equivocan, sugiere que el doble informe tiene implicaciones mayores de lo que parece tener a primera vista.
No sugiere que los expertos en seguridad de Linux sean propensos a cometer errores y descuidos. Simplemente sugiere que el trabajo de administrar las vulnerabilidades de seguridad se ha vuelto tan increíblemente difícil que incluso los expertos luchan por mantenerse al día.
Considere por un momento un equipo de tecnología interno típico que tiene un mandato integral:sí, incluida la seguridad, pero también cubre el mantenimiento, las operaciones y un sinfín de otras responsabilidades.
Incluso cuando los equipos empresariales tienen expertos en seguridad dedicados, es probable que la experiencia deba aplicarse en una variedad de amenazas y herramientas tecnológicas. Sería extremadamente raro, incluso para una gran empresa, contratar a un experto en seguridad del kernel de Linux. E incluso si lo hicieran, como hemos visto, estos expertos en seguridad pueden equivocarse.
Los equipos de TI tienen tiempos difíciles por delante
Los equipos en el sitio siempre gestionarán las vulnerabilidades de seguridad hasta cierto punto. Respondiendo a las noticias de los principales exploits, por ejemplo, y aplicando parches en consecuencia. Las advertencias de los proveedores también pueden impulsar la acción, y la mayoría de los buenos departamentos de TI tendrán algún tipo de régimen de parches que garantice que los parches se apliquen a intervalos establecidos.
Pero, ¿cómo pueden los equipos de TI mantenerse al día de manera realista con una creciente cantidad de CVE que afectan a las distribuciones de Linux en todos los ámbitos y que llegan a diario? ¿Proporciona, digamos, un régimen de parches trimestrales realmente suficiente seguridad? Y sí, los parches son importantes , pero ¿debería dominar la actividad a costa de todo lo demás, lo que puede suceder fácilmente dado el volumen de parches?
Es fácil ver que a los equipos de TI les resultará difícil mantenerse a la vanguardia de la lista cada vez mayor de vulnerabilidades.
Obtenga su régimen de parches correcto
Formalizar su régimen de parches es el primer paso para tratar de hacer frente a la montaña de CVE. Los parches ad-hoc basados en informes de noticias alarmantes no son el camino a seguir:simplemente hay demasiadas vulnerabilidades y relativamente pocas se vuelven ampliamente conocidas, lo que deja innumerables vulnerabilidades ocultas y exploits asociados que representan un peligro.
No obstante, uno de los pasos clave para crear un régimen de parches es priorizar los parches. Las vulnerabilidades críticas y ampliamente conocidas deben parchearse rápidamente, sin demoras y sacrificando la disponibilidad si es necesario. Se pueden programar parches para vulnerabilidades de riesgo medio y bajo para adaptarse a las cargas de trabajo de los equipos de tecnología o para evitar problemas de disponibilidad.
Otro paso clave es construir un inventario suficientemente completo del hardware y software que requiere parches. Algunos objetivos para parchear serán inmediatamente obvios, pero otros pueden pasarse por alto fácilmente.
Al crear su inventario, también puede identificar algún alcance para la estandarización; en otras palabras, actualizar el software a la misma versión o consolidar proveedores para facilitar la administración de parches.
Finalmente, vale la pena codificar su régimen de parches en una política de parches formal. La aplicación de parches es difícil de hacer de manera consistente, y todo lo que se necesita es una sola falla para abrir la puerta al desastre. Un régimen de parches codificado puede ayudar a su equipo a mantenerse al día con los parches, año tras año.
La compensación con la aplicación de parches
Con cualquier régimen de aplicación de parches, generalmente se debe hacer un compromiso entre disponibilidad y seguridad. Sí, puede aplicar parches de forma muy segura, aplicando los parches tan pronto como se lanzan. Pero la aplicación de parches inevitablemente tiene un impacto en la disponibilidad, ya que la aplicación de parches a menudo requiere reiniciar el servidor.
De hecho, algunas empresas pueden tener requisitos comerciales específicos que impiden desactivar servicios o servidores para aplicar parches incluso si aparece un CVE crítico, lo que puede dejar a los servicios vulnerables a una nueva vulnerabilidad.
Incluso cuando puede desconectar los servidores para realizar tareas de mantenimiento, los servicios se degradan y, en consecuencia, se degrada la experiencia del usuario final. Piense en un minorista en línea con miles de clientes en línea que repentinamente desconectan la mitad de sus servidores para realizar tareas de mantenimiento, por ejemplo.
Luego también está la pérdida de equipos de tecnología que inevitablemente están sacrificando el tiempo que dedican a otras tareas para dedicar tiempo a parchear. Los equipos de seguridad simplemente podrían verse completamente abrumados por la carga de aplicar parches. Sin embargo, hay una alternativa.
Considere herramientas de aplicación de parches automatizadas
Hemos identificado dos problemas clave detrás de los regímenes de parches estándar:el tiempo y el esfuerzo requeridos por los parches y la interrupción asociada con los parches. Una solución que vale la pena considerar es la aplicación de parches automática, y más aún si se trata de una parche automática sin reinicio. que aplica parches sin necesidad de reiniciar el servidor.
Las herramientas de aplicación de parches automatizadas monitorean continuamente los lanzamientos de parches y los aplican automáticamente sin intervención. Elimina la necesidad de dedicar mano de obra a las flotas de servidores de parches:la aplicación de parches simplemente se realiza sin problemas en segundo plano. Con la aplicación de parches automatizada, los equipos de tecnología nunca se ven abrumados con innumerables tareas de parches, ni los equipos de tecnología necesitan intentar predecir qué parches son los más importantes. En cambio, todos los parches se aplican de manera uniforme, uniforme y uniforme.
Algunas herramientas de parches automatizados como KernelCare puede aplicar parches sobre la marcha:parches en vivo, mientras una máquina está funcionando y sin necesidad de reiniciar. La aplicación de parches en vivo limita la interrupción ya que las máquinas no se desconectan para procesar un parche. Cuando existe un riesgo mínimo de interrupción, es probable que mejore la consistencia de los parches.
En otras palabras, la herramienta de aplicación de parches automatizada adecuada puede resolver dos de los mayores problemas a los que se enfrentan las empresas con la aplicación de parches:el esfuerzo necesario y la interrupción.
La aplicación de parches es fundamental, independientemente de cómo decida hacerlo
Independientemente de lo que haga su empresa para cubrirse de la aplicación de parches o de cómo organice su régimen de aplicación de parches, la única certeza es que la aplicación de parches es fundamental. Se deben aplicar parches, pero se debe tomar una decisión sobre la frecuencia y la forma de parchear.
Dado el tamaño de la amenaza a la ciberseguridad, existe un fuerte argumento a favor de la aplicación automática de parches. Los equipos de tecnología y los investigadores de seguridad están cada vez más abrumados y la aplicación de parches automatizada soluciona el problema de los recursos y la disponibilidad.
Siempre es una opción simplemente aplicar más mano de obra al desafío de la aplicación de parches y, para algunas cargas de trabajo, esa puede ser la única opción. Sin embargo, en la mayoría de los casos, los parches automatizados y sin reinicio pueden ofrecer una gran victoria frente a los enormes desafíos de ciberseguridad de la actualidad.
Lectura recomendada:
- ¡Parche el kernel Linux de Raspberry Pi con KernelCare GRATIS!
- Detectar bibliotecas compartidas obsoletas en la memoria con UChecker