Las actualizaciones se ejecutan automáticamente, pero nadie puede demostrarlo

La pregunta del cuestionario parece inofensiva: «¿En qué plazo se instalan las actualizaciones de seguridad críticas y cómo se verifica esto?». La respuesta sincera en muchas empresas es: Windows se actualiza solo, el resto acaba haciéndose tarde o temprano, y no hay forma de demostrarlo. Es precisamente aquí donde las auditorías de proveedores fracasan con más frecuencia que por falta de tecnología.

Lo lamentable es que, a menudo, la empresa está mejor preparada de lo que puede demostrar. Los sistemas están actualizados, pero nadie puede decir en qué medida lo están, desde cuándo, en cuántos dispositivos ni qué vulnerabilidades se han corregido. Este artículo explica qué es lo que los auditores y los principales clientes realmente quieren ver, qué informes proporcionan esa información, en qué se diferencian los módulos de aplicación de parches de los principales proveedores y qué limitaciones debes tener en cuenta antes de comprarlos.

¿Por qué los auditores preguntan, ante todo, por el estado de los parches?

Porque las vulnerabilidades sin parchear y de dominio público se encuentran entre los puntos de entrada más comunes de todos —y porque, a diferencia de muchos otros factores, este aspecto puede verificarse de forma objetiva. Un auditor no puede evaluar en qué medida su plantilla sabe reconocer el phishing. Sin embargo, sí puede preguntar cuál es la antigüedad de la vulnerabilidad crítica sin parchear más antigua de su inventario, y esa cifra dice mucho sobre la organización en su conjunto.

Además, este tema aparece en prácticamente todas las normativas. La versión de 2022 de la norma ISO 27001 incluye la gestión de vulnerabilidades técnicas como un punto de control independiente en la sección 8.8. La Directiva NIS 2 menciona explícitamente la gestión y la divulgación de vulnerabilidades como una de las categorías de medidas obligatorias. Y la Norma Mínima Suiza de TIC incluye la gestión de vulnerabilidades dentro de las funciones de «Identificar» y «Proteger». Cualquiera que diseñe un cuestionario se basa en estas fuentes, y por eso las preguntas son tan similares.

¿Se exige la actualización o se exige la prueba?

Ambas cosas, pero lo que se verifica es la prueba. Este es el punto en el que la mayoría de las organizaciones subestiman el problema. Un auditor no puede ver si tus dispositivos están actualizados; solo puede ver lo que tú le presentas.

Normalmente, se exigen cuatro cosas. En primer lugar, una política por escrito que especifique las responsabilidades y los plazos en función de la gravedad; por ejemplo, las vulnerabilidades críticas deben solucionarse en un plazo de catorce días. En segundo lugar, informes que demuestren que se realizan análisis de vulnerabilidades de forma regular, con un calendario claro. En tercer lugar, un sistema de seguimiento desde el descubrimiento hasta la resolución que muestre quién hizo qué y cuándo. En cuarto lugar, una política de excepciones documentada para todo aquello que no se pueda corregir con un parche.

La queja más habitual es muy concreta: la organización marca una vulnerabilidad como resuelta sin haber verificado técnicamente que el parche se haya aplicado realmente. Una marca de verificación en una lista no es prueba suficiente; lo es, en cambio, un análisis repetido que ya no detecte la vulnerabilidad.

Responder correctamente a los cuestionarios de seguridad de los principales clientes
muestra qué elementos de dichos cuestionarios pueden corroborarse con software para terminales y cuáles deben verificarse mediante medidas organizativas.

¿No son suficientes las actualizaciones automáticas de Windows?

Para el sistema operativo, sí; para el resto, no —y el resto constituye la mayor superficie de ataque—. Las actualizaciones automáticas de Microsoft cubren Windows y las aplicaciones de Microsoft. No cubren todo lo demás que suele instalarse en una estación de trabajo: programas de PDF, navegadores distintos de Edge, herramientas de archivado, entornos de ejecución, software de mantenimiento remoto y aplicaciones específicas del sector.

Son precisamente estos programas los que figuran en el cuestionario bajo el epígrafe «aplicaciones de terceros», y son precisamente estos los que, en la práctica, suelen estar desactualizados con mayor frecuencia, ya que nadie se ocupa de ellos de forma individual. Un módulo de parches se encarga de gestionarlos de forma centralizada y, al hacerlo, proporciona el efecto secundario que realmente importa: una lista exacta del software que se está utilizando realmente. Este inventario es el primer documento adjunto obligatorio para la mayoría de las auditorías.

Hay un segundo punto a tener en cuenta: las actualizaciones automáticas no se pueden controlar. Cualquiera que necesite demostrar que se ha instalado un parche dentro de un plazo específico necesita un calendario y un informe, no un mecanismo que se ejecute por sí solo en algún momento.

¿Cuál es la diferencia entre la gestión de vulnerabilidades y la gestión de parches?

La gestión de vulnerabilidades identifica y evalúa las vulnerabilidades; la gestión de parches las resuelve. Esta distinción no es solo semántica: es la razón por la que algunas preguntas del cuestionario no pueden responderse utilizando únicamente un módulo de parches.

El proceso consta de cuatro etapas: identificar qué software está instalado y qué vulnerabilidades conocidas presenta; evaluar la gravedad y la posibilidad de explotación de estas vulnerabilidades en su propio entorno; corregirlas, normalmente mediante un parche; y verificar que la corrección ha sido efectiva. La mayoría de los productos de esta categoría abarcan las cuatro etapas, por lo que a menudo se denominan «gestión de vulnerabilidades y parches».

La distinción cobra importancia cuando no hay ningún parche disponible, ya sea porque el proveedor aún no lo ha publicado o porque el software se encuentra al final de su ciclo de vida. En tales casos, cualquier conjunto de directrices exige una medida alternativa y una decisión, no simplemente la inacción. Precisamente por eso es necesaria la fase de evaluación.

¿Qué plazos debo fijar para las vulnerabilidades críticas?

Uno que puedas cumplir. Suena obvio, pero es la única regla sensata: un plazo de siete días que se incumple habitualmente queda peor en una auditoría que un plazo de treinta días que sí se cumple. Te comprometiste y no cumpliste.

Es habitual clasificar los plazos por gravedad, con plazos diferentes para las brechas de gravedad crítica, alta y media. Sin embargo, la gravedad por sí sola es un indicador poco fiable. La clasificación cobra más sentido cuando se tienen en cuenta dos factores adicionales: si la vulnerabilidad ya está siendo explotada activamente y si se puede acceder al sistema afectado desde Internet. Una vulnerabilidad de gravedad media en un servidor conectado a Internet —para la que ya existen herramientas de ataque— es más urgente que una vulnerabilidad crítica en un sistema de pruebas aislado.

Incorpora esta lógica a tu política. Un auditor que observe que estableces prioridades en función de la explotabilidad y la exposición, en lugar de basarte estrictamente en la puntuación, considerará que se trata de un proceso maduro y aceptará plazos más largos para la parte no crítica.

¿Qué informes específicos necesito?

Cinco informes cubren la gran mayoría de todos los cuestionarios y auditorías, y los cinco proceden de la consola de gestión, no de una hoja de cálculo que usted mismo mantenga.

En primer lugar, la lista de inventario: qué dispositivos se gestionan y qué software tienen instalado. En segundo lugar, el informe sobre parches pendientes, desglosado por gravedad; este informe responde a la pregunta sobre el estado actual. En tercer lugar, el mismo informe con información sobre la antigüedad, es decir, cuánto tiempo lleva abierta una vulnerabilidad; esta es la métrica que utiliza un auditor para evaluar tu cumplimiento de los plazos. En cuarto lugar, la lista de instalaciones fallidas, ya que un parche que no se haya instalado correctamente nunca se detectará sin este informe. En quinto lugar, la visión general de los parches excluidos intencionadamente, junto con los motivos de su exclusión.

Todos estos informes tienen dos características de las que carece una tabla mantenida manualmente: una fecha y un alcance. El informe no solo indica que noventa y dos dispositivos están actualizados, sino también que se gestionan un total de noventa y cuatro. Esta diferencia es precisamente lo que se necesita.

¿Qué hago con los sistemas a los que no se les pueden aplicar parches?

Hay que documentarlos como excepciones, incluyendo el motivo, una solución alternativa, un plazo y la autorización correspondiente. Se trata de un procedimiento reconocido y no de una admisión de debilidad. Lo que no se reconoce es no mencionar en absoluto los sistemas afectados.

Entre los ejemplos típicos se incluyen un sistema de control de máquinas cuyo fabricante no concede la autorización para versiones más recientes, una aplicación específica del sector que requiere un entorno de ejecución obsoleto o un sistema heredado que debe permanecer en funcionamiento por motivos contractuales. Las posibles medidas correctivas incluyen el aislamiento de la red, la restricción de los derechos de acceso, el bloqueo de la aplicación en el sistema afectado o una supervisión reforzada.

Es importante fijar un plazo. Una excepción sin fecha de caducidad será señalada durante la próxima auditoría, ya que indica que ya nadie supervisa la situación. Fija una fecha en la que deba revisarse la decisión, incluso si es previsible que el resultado vaya a ser el mismo.

¿En qué se diferencian los módulos de parches de los distintos proveedores?

Los módulos que actualizan de forma centralizada los sistemas operativos y las aplicaciones de terceros, y que proporcionan informes sobre estas actualizaciones, son comparables. Kaspersky ofrece su «Vulnerability and Patch Management» tanto como producto independiente como módulo complementario a paquetes existentes, por lo que se analiza por separado a continuación.

En cuanto a los campos abiertos y restringidos: en Linux, Bitdefender no actualiza las aplicaciones instaladas fuera del gestor de paquetes e instala automáticamente solo los parches con firma digital; para el resto, se requiere un paso manual, lo cual debe tenerse en cuenta en el proceso. En el caso de ESET, la información relativa a los identificadores CVE por parche y a la caché local no está disponible con el mismo nivel de detalle, por lo que debería incluirse en la propuesta. En cuanto a Avast y AVG, se indica explícitamente que no se admiten las actualizaciones de seguridad ampliadas de Microsoft, lo cual debe tenerse en cuenta por cualquier organización que utilice un sistema más allá de la fecha habitual de fin de soporte.

¿Qué producto es el adecuado para cada entorno?

Para entornos exclusivamente Windows que aún no utilizan un paquete empresarial de uno de los principales proveedores, los productos independientes son la opción más rápida: Avast Business Patch Management ⧉ y AVG Patch Management Business Edition ⧉. Ambos permiten programar análisis diarios, semanales o mensuales, muestran los parches que faltan junto con su nivel de gravedad y fecha de lanzamiento, y permiten excluir proveedores o aplicaciones específicos. Para ahorrar ancho de banda, un dispositivo seleccionado de la red se encarga de la distribución. La limitación es clara: solo Windows; ningún otro sistema operativo.

Si ya utilizas GravityZone, puedes añadir Bitdefender GravityZone Patch Management ⧉ como módulo complementario. Es compatible con Windows, Linux y macOS, muestra el identificador CVE de cada parche, puede bloquear parches concretos si interrumpen un flujo de trabajo y permite posponer el reinicio necesario. Para la distribución dentro de tu propia red, también se puede configurar un dispositivo con función de retransmisión como caché.

Con ESET, el módulo forma parte del nivel de paquete. Se incluye a partir de ESET PROTECT Complete ⧉, así como en ESET PROTECT Elite ⧉, que también incluye el componente de detección y respuesta. En los niveles «Entry» y «Advanced», se puede añadir como una función independiente. Abarca Windows, Linux y macOS, incluidas las aplicaciones de terceros, y la funcionalidad también se puede ampliar a los servidores, siempre que ejecuten las últimas versiones de los productos de servidor de ESET correspondientes.

Kaspersky ofrece ambas opciones: Kaspersky Vulnerability and Patch Management ⧉ como producto independiente y Kaspersky Vulnerability and Patch Management como complemento ⧉ para ampliar un paquete de Kaspersky ya existente. La opción disponible para usted depende del producto base y debe aclararse antes de realizar el pedido.

Base, Base Plus, complemento o renovación: qué significan estos términos.
Explica cómo interpretar los nombres de los paquetes disponibles en el mercado y cuáles de ellos requieren una licencia existente.

¿Es posible que ya disponga del módulo de parches?

Es posible, y vale la pena comprobarlo antes de realizar cualquier pedido. Varios proveedores han incluido la gestión de parches en sus paquetes de gama alta en lugar de venderla por separado.

En el caso de Kaspersky, la gestión de parches está incluida en el nivel Next EDR Optimum; en ESET, se incluye a partir de PROTECT Complete; y ThreatDown Advanced ⧉ también la incluye como parte del paquete. Quien ya disponga de una licencia para uno de estos niveles no necesita un producto adicional; simplemente tiene que activar y configurar la función, algo que, en la práctica, se pasa por alto con sorprendente frecuencia porque nadie se da cuenta de que está incluida.

Por el contrario, en el caso de Bitdefender, la gestión de parches no está incluida en ningún nivel de paquete, sino que es siempre un módulo adicional de pago. Una oferta de GravityZone que no incluya este elemento no cumple los requisitos del cuestionario.

¿Qué inconvenientes hay a la hora de realizar una compra?

Tres, que a menudo solo se detectan tras realizar el pedido.

El primero se refiere a ESET: según el fabricante, la gestión de vulnerabilidades y parches no está disponible en la versión de la consola de gestión que se ejecuta localmente, sino que requiere la consola en la nube. Las organizaciones que gestionan deliberadamente sus sistemas de forma interna —por ejemplo, debido a requisitos específicos de su ubicación— no pueden utilizar esta función en ese entorno. No se trata de un detalle menor, sino de una decisión fundamental que debe tomarse antes de la compra.

La segunda cuestión se refiere a la lista de software. Cada módulo actualiza únicamente lo que figura en su catálogo. Estos catálogos son muy amplios y se amplían continuamente, pero nunca lo abarcan todo. Bitdefender publica una lista descargable de proveedores y productos compatibles que se actualiza mensualmente. Antes de la compra, comprueba si tus aplicaciones más importantes están incluidas; el software específico del sector, en particular, rara vez aparece en la lista y, por lo tanto, debe gestionarse manualmente, lo que tendrás que documentar por separado.

El tercer punto se refiere a los servidores. Un módulo de parches que solo cubre las estaciones de trabajo responde solo parcialmente a la pregunta del cuestionario, ya que esta se refiere a toda la infraestructura. Aclara si las licencias para servidores incluyen la misma funcionalidad y si se requieren elementos independientes para ellos.

Protección de servidores, Exchange y servidores de archivos: por qué las licencias para terminales no son suficientes.
Explica por qué los servidores requieren sus propias licencias y productos, y qué funciones adicionales deben cubrirse.

¿Cómo gestiono los reinicios?

Utilice ventanas de mantenimiento programadas en lugar de solicitudes puntuales. Los reinicios son la razón por la que la gestión de parches falla en muchas organizaciones: nadie quiere reiniciar el servidor durante el horario laboral, y por la noche no hay nadie presente.

Los módulos resuelven esto mediante dos mecanismos. En primer lugar, el análisis puede separarse de la instalación: los análisis se ejecutan a diario, mientras que las instalaciones tienen lugar a una hora programada. En segundo lugar, el reinicio puede posponerse de modo que el parche se instale, pero no surta efecto hasta el siguiente reinicio periódico.

En lo que respecta a la verificación, hay un aspecto crucial que, sin embargo, se pasa por alto con facilidad: un parche que se ha instalado pero que aún no está activo no elimina la vulnerabilidad. Si su informe contabiliza estos casos como resueltos, está verificando un estado que no existe. Por lo tanto, define cuánto tiempo puede permanecer pendiente un reinicio y trata cualquier caso que supere este límite como una vulnerabilidad abierta.

¿Cómo ayuda la gestión de parches a cumplir con los requisitos de notificación en Suiza?

A partir del 1 de abril de 2025, los operadores de infraestructuras críticas deberán notificar los ciberataques a la Oficina Federal de Ciberseguridad en un plazo de 24 horas desde su detección, de conformidad con la Ley de Seguridad de la Información revisada y la Ordenanza sobre Ciberseguridad; la información que falte podrá presentarse en un plazo de 14 días. Esto se aplica a los organismos y organizaciones públicos tal y como se definen en el art. 74b de la Ley de Seguridad de la Información (ISG); existen excepciones para organizaciones más pequeñas e incidentes con repercusiones menores.

El estado de las actualizaciones no desempeña un papel directo en la notificación en sí. Sin embargo, cobra importancia inmediatamente después, concretamente a la hora de determinar cómo consiguió el acceso el atacante. Si resulta que se explotó una vulnerabilidad conocida desde hacía meses y que podía haberse corregido, esto presenta un escenario diferente al de un ataque a través de una vulnerabilidad desconocida en el momento del incidente. Por lo tanto, un informe que documente el estado de las actualizaciones del sistema afectado en ese momento es uno de los documentos más valiosos de todos, siempre que se haya generado y conservado antes del incidente.

Lo que no hace la gestión de parches: no determina si su organización está sujeta a requisitos de notificación, no detecta un ataque en curso y no sustituye a la responsabilidad designada de notificar los incidentes.

¿Qué exige la Directiva NIS 2 en relación con las vulnerabilidades?

La directiva incluye la gestión y la divulgación de vulnerabilidades como una de las categorías de medidas que deben aplicar las organizaciones afectadas. No prescribe ningún software específico ni un plazo concreto; lo que se exige es un procedimiento cuya aplicación pueda demostrarse.

Esto se ve respaldado por los análisis, la priorización y los informes generados por un módulo de parches. Los aspectos organizativos no quedan cubiertos: la definición por escrito de los plazos, las responsabilidades asignadas, la gestión de los informes externos sobre las vulnerabilidades descubiertas y la revisión periódica de si el procedimiento es realmente eficaz. Ningún producto puede abordar estos puntos.

Las organizaciones que deben cumplir tanto los requisitos suizos como los europeos se enfrentan a dos conjuntos de normativas que difieren en cuanto a plazos y terminología.

Una comparación de las obligaciones en materia de ciberseguridad en Suiza y la UE
compara los requisitos de notificación suizos con los de la Directiva NIS 2 y destaca en qué aspectos difieren.

¿Qué es lo que no cubre un módulo de parches?

Todo aquello que no sea un sistema operativo o una aplicación instalada —y eso es más de lo que podrías pensar—.

No están cubiertos el firmware de los dispositivos de red, los cortafuegos, los puntos de acceso, las impresoras y los sistemas NAS. Sin embargo, son precisamente estos dispositivos los que están conectados directamente a Internet y cuyas vulnerabilidades se explotan con especial frecuencia. También quedan excluidos los sistemas de control de máquinas, los servicios en la nube en los que el proveedor se encarga de las actualizaciones y el software que ha llegado al final de su ciclo de vida y para el que, sencillamente, ya no hay parches disponibles.

Para estas áreas, necesitarás un segundo proceso, normalmente manual, con su propia lista y calendario. Cualquiera que marque la casilla del cuestionario indicando que todos los sistemas están integrados en la gestión de parches —mientras que los cortafuegos y los dispositivos NAS se gestionan por separado— está proporcionando información que no resistirá un análisis minucioso.

¿Cómo puedo empezar en treinta días?

Durante la primera semana, establece la visibilidad: activa o adquiere el módulo, integra todos los dispositivos y realiza un análisis completo inicial. La experiencia demuestra que los resultados suelen ser inquietantes —y precisamente por eso son valiosos—, ya que revelan el inventario real por primera vez.

Durante la segunda y tercera semanas, pon al día el trabajo atrasado, empezando por todo lo accesible desde Internet, y documenta al mismo tiempo las directrices: quién es el responsable, qué plazos se aplican en función de la gravedad, cuándo realizar el análisis, cuándo instalar y cómo se aprueban las excepciones. Basta con una página; solo tiene que estar fechada y aprobada.

En la cuarta semana, se genera el primer conjunto de informes y se archivan. Es precisamente este informe archivado y fechado el que sirve como prueba que la gente solicita, y desde el momento en que se empieza a repetir este proceso mensualmente, una instantánea se convierte en un historial verificable. Esa es la verdadera diferencia entre una empresa que corrige vulnerabilidades y otra que puede demostrarlo.