Soporte técnico
Documentación
Inicio de sesión
Póngase en contacto con nosotros
Reflexiones sobre el tiempo de despliegue de parches
Joao Correia
10 de febrero de 2023 - Evangelista técnico
A menudo, las organizaciones intentan parchear sus sistemas "a tiempo" para protegerse de las nuevas amenazas. En este contexto, "a tiempo" significará cosas diferentes para cada organización: algunas se esforzarán por parchear en el plazo de un mes desde que se divulgue una vulnerabilidad, otras lo harán en el momento en que haya un parche disponible (como permite el live patchingpor ejemplo), mientras que otras lo harán en cuanto las necesidades de la empresa les permitan el tiempo de inactividad necesario.
Pero, ¿estamos contando el tiempo de la forma correcta? ¿Qué significa realmente "a tiempo" cuando hablamos de parches?
A tiempo
Veamos un ejemplo de una vulnerabilidad algo inocua que acaba de anunciarse: CVE-2023-25136 - una vulnerabilidad de OpenSSH en el proceso de preautenticación causada por el intento de "liberar" una variable ya liberada, causando así problemas potenciales. Se dio a conocer públicamente el 3 de febrero, y algunos registradores de CVE aún carecen de detalles al respecto.
Haciendo caso omiso de la (aparente) falta de riesgo, y suponiendo hipotéticamente que se tratara de una vulnerabilidad de alto riesgo, ¿qué significaría parchear "a tiempo" este fallo? Si se parchease hoy (en el momento de escribir este artículo), se parchearía una semana después de su anuncio público, lo que estaría muy bien y permitiría volver a considerar segura la infraestructura. tardaban más de un mes para parchear vulnerabilidades de alto riesgo. Todas las casillas correctas estarían marcadas, su responsable de cumplimiento estaría muy contento y usted podría volver a sus actividades habituales.
Considere ahora que la vulnerabilidad, de hecho, ha sido reportada en enero al equipo de OpenSSH, y que hubo mensajes intercambiados en la lista de correo pública sobre ella alrededor del 15 de enero. Esto añade otras dos semanas de información pública sobre un fallo potencialmente inductor de fallos antes de que se produjera la revelación real de la CVE. Y esto es sólo el aspecto visible de un fallo que provoca una CVE. Puede haber una escala de tiempo completamente diferente si el fallo no se comunicó al equipo adecuado en primer lugar. Por ejemplo, si se vendió como un exploit de día cero en algún foro sospechoso. En el caso de esta vulnerabilidad específica, incluso si la parcheas el día en que se anuncia la CVE, ya estarás potencialmente en riesgo durante dos semanas.
CVE sobrevalorados
Por tanto, "a tiempo" significa realmente "desde que se divulga públicamente de forma oficial" o "desde que se le asigna un número CVE", no realmente "desde que se conoce". Hay situaciones en las que la información inicial sobre un fallo se produce meses antes de que aparezca un CVE. ¿Te has preguntado alguna vez por qué algunas CVE tienen un indicador del año anterior? Es porque se encontraron el año anterior y todo el proceso de análisis-creación de parches-lanzamiento llevó varios meses. Y este proceso suele ocurrir a la vista del público bajo la apariencia de informes de errores y discusiones en github o en listas de correo.
Y aquí es donde la conversación puede descarrilar: no se puede tener un sistema inseguro si ni siquiera hay un CVE para que lo conozcas, ¿verdad? Desgraciadamente, esa no es la pregunta correcta.
No todas las vulnerabilidades tienen asignados CVE. Por ejemplo, el equipo de seguridad del kernel introducirá cada semana correcciones de nuevas vulnerabilidades sin que nunca se les haya asignado un CVE (conocido públicamente), en parte porque eso proporcionaría a los actores maliciosos un vector para los sistemas sin parches, y en parte porque el propio sistema CVE tiene una serie de ineficiencias. Más información aquí.
El sector de la ciberseguridad se centra en los CVE. Creamos, rastreamos, priorizamos, parcheamos y diseñamos estrategias para los que no podemos parchear, pero los CVE son solo la punta del proverbial iceberg.
Minimizar la ventana de riesgo
Si tu única medida de seguridad es el número de CVE que parcheas en un plazo determinado, por ejemplo, para cumplir los requisitos de conformidad, probablemente estés un poco menos "seguro" de lo que crees. La ventana de riesgo no empieza cuando se anuncia una CVE, sino en algún momento antes, y no se sabe con certeza cuánto dura, así que lo mejor es acortar la ventana de riesgo todo lo posible. Sólo se controla la hora de cierre de la ventana de riesgo. Este riesgo implícito es elocuente cuando las organizaciones tardan un mes o más en parchear, además de todo lo que ocurre antes.
Por supuesto, no es exactamente posible parchear algo antes de que salga dicho parche, pero hay que tomar todas las medidas necesarias para asegurarse de que se parchea lo antes posible en lugar de tardar semanas en hacer frente a una nueva vulnerabilidad.
El periodo de tiempo (a veces largo) que transcurre hasta que se divulga realmente una vulnerabilidad debería ser la mejor razón para adoptar un enfoque más rápido en la aplicación de parches. Los actores de amenazas vigilan activamente los informes de fallos en busca de nuevas oportunidades y tienen las habilidades necesarias para "convertir en armas" los fallos rápidamente.
No ayude a los hackers, no lo necesitan. Parche ahora.
