Tema
Para crear esta guía, hemos colaborado con socios de NinjaOne con el fin de comprender cómo utilizan las capacidades de gestión de parches de NinjaOne y hemos combinado su experiencia con la nuestra. En esta guía, compartimos esos conocimientos para que los nuevos socios puedan sacar el máximo partido a la gestión de parches.
Entorno
Plataforma NinjaOne
Gestión de parches
Descripción
- Cómo configuran los usuarios de NinjaOne la aplicación de parches en Windows
- Programaciones de análisis
- Programaciones de actualización
- Programaciones omitidas
- Aprobaciones de parches
- Perfiles de parches comunes
- Comportamiento de reinicio
Cómo configuran los usuarios de NinjaOne la aplicación de parches en Windows
La gestión de parches es una de las tareas más importantes que lleva a cabo un equipo de TI. Las empresas dedican importantes recursos a mantener su infraestructura actualizada, pero más de la mitad de las brechas de seguridad se podrían haber evitado instalando los parches disponibles para el software y el sistema operativo.
Además de las implicaciones de seguridad, una estrategia de aplicación de parches eficaz garantiza que los usuarios finales dispongan del software más actualizado y con más funciones para realizar su trabajo.
Sin embargo, si algunas de las organizaciones más grandes y con mayor financiación del mundo tienen dificultades con la gestión de parches, ¿qué posibilidades tienen las pequeñas y medianas empresas con un soporte de TI limitado? Sin las herramientas adecuadas, el proceso es lento, complicado, disruptivo para los usuarios finales y propenso a errores.
El software de gestión de parches, como el incluido en NinjaOne, ofrece a los usuarios una visión completa y centralizada de su tasa de cumplimiento de parches y automatiza la identificación, descarga e implementación de parches en todos los dispositivos gestionados.
NinjaOne le ofrece un control minucioso sobre su proceso de aprobación de parches, mejora su tasa de éxito de parches en la primera aplicación y reduce el tiempo que sus técnicos dedican a la aplicación de parches.
Programación de análisis
Las políticas de NinjaOne permiten a los usuarios programar análisis de parches de forma independiente del proceso de actualización. El análisis identifica todos los parches aún no instalados en un dispositivo y los clasifica en las categorías «Aprobado», «Pendiente» o «Rechazado» según la configuración de aprobación basada en políticas.
Al realizar el escaneo horas o días antes de ejecutar una actualización, puede ajustar manualmente el estado de aprobación de un parche, que el proceso de actualización respetará posteriormente. Esto resulta increíblemente útil para los parches aprobados manualmente o para evitar parches problemáticos que normalmente se aprobarían automáticamente.
Cuándo programar los análisis
Día de la semana
La mayoría de los socios de NinjaOne programan sus análisis de parches una vez a la semana. Los viernes son, con diferencia, el día más habitual para el análisis de parches. La siguiente opción más común es realizar un análisis todos los días. Los análisis diarios de parches consumen más recursos, pero maximizan el tiempo que tienen los socios para realizar cambios ad hoc en los parches.
| Dom | Lun | Mar | Mié | Jue | Vie | Sáb | Diario |
|---|---|---|---|---|---|---|---|
| 3 % | 3 % | 5 % | 10 % | 7 % | 40 % | 7 % | 25 % |
Hora del día
La hora más habitual para realizar análisis de parches es entre las 17:00 y las 18:00, hora del dispositivo. Muchos usuarios programan los análisis después de las 18:00 para evitar afectar a los usuarios finales que trabajan hasta más tarde. Aunque el análisis de parches no consume muchos recursos, la mayoría de los análisis se programan fuera del horario laboral habitual para evitar afectar a los usuarios finales. Los usuarios que programan análisis durante el horario laboral pueden hacerlo para capturar el mayor número posible de dispositivos conectados.
| 00:00 – 8:50 | 9:00 – 16:59 | 17:00 – 23:59 |
|---|---|---|
| 16 % | 24 | 60 % |
Duración del escaneo
La mayoría de los usuarios de NinjaOne no establecen una duración para el escaneo, lo que permite que estos duren el tiempo que sea necesario. Para aquellos que sí limitan la duración, las opciones más comunes son 9 horas, 6 horas y 3 horas. La duración de los escaneos puede utilizarse cuando se toma el control de una nueva infraestructura o cuando usuarios de múltiples zonas horarias necesitan acceder a un servidor, y es necesario que la ventana de aplicación de parches sea más corta para minimizar el impacto en el usuario final.
| 1 hora | 2 horas | 3 horas | 4 horas | 5 horas | 6 horas | 7 horas | 8 horas | Más de 9 horas | ∞ |
|---|---|---|---|---|---|---|---|---|---|
| 0 % | 0 % | 1 % | 1 % | 1 % | 3 % | 0 % | 0 % | 10 % | 85 % |
Programas de actualización
La programación de actualizaciones de NinjaOne primero busca los parches disponibles, luego descarga y aplica tanto los parches recién descubiertos como los ya identificados mediante un análisis de parches basado en las configuraciones de aprobación de la política y cualquier anulación aplicable. A continuación, la gestión de parches de NinjaOne realiza un análisis adicional para finalizar el proceso.
El estado de aprobación aplicado por la política se puede anular para dispositivos individuales o para políticas completas, siempre que un análisis lo identifique antes de que se aplique.
Una vez que se ha intentado instalar un parche durante un ciclo de actualización, se clasificará en el panel de control de parches del sistema operativo como «Instalado» o «Fallido».
Cuándo programar las actualizaciones
Día de la semana
Los parches se aplican con mayor frecuencia los fines de semana para evitar interrumpir a los usuarios finales. Los viernes —normalmente después del horario laboral— también son habituales. Tras la incorporación inicial del dispositivo, muchos usuarios también aplican parches a diario para minimizar el tiempo en que los endpoints son vulnerables.
| Dom | Lun | Mar | Mié | Jue | Vie | Sáb | Diario |
|---|---|---|---|---|---|---|---|
| 19 % | 4 % | 5 % | 9 % | 10 % | 15 % | 19 % | 19 % |
Hora del día
La hora más habitual para iniciar el proceso de aplicación de parches es entre las 17:00 y las 18:00, hora del dispositivo. Muchos usuarios programan sus actualizaciones después de las 18:00 para evitar afectar a los usuarios finales que trabajan hasta más tarde. Dado que la aplicación de parches consume más recursos y a menudo requiere un reinicio, la mayoría de las actualizaciones se programan fuera del horario laboral.
| 00:00 – 8:50 | 9:00 – 16:59 | 17:00 – 23:59 |
|---|---|---|
| 33 | 18 | 48 % |
Duración de la actualización
La mayoría de los usuarios de NinjaOne no establecen una duración para la aplicación de parches, lo que permite que las actualizaciones duren todo el tiempo que sea necesario. En el caso de aquellos que sí limitan la duración, la mayoría la limita a 4 horas o menos.
| 1 hora | 2 horas | 3 horas | 4 horas | 5+ horas | ∞ |
|---|---|---|---|---|---|
| 3 % | 5 % | 4 % | 5 % | 10 % | 74 % |
Programaciones perdidas
NinjaOne permite a los usuarios recuperar escaneos o actualizaciones si se han perdido. Esto suele ocurrir si el dispositivo está apagado cuando está programado que comience el escaneo o la actualización.
Las opciones de análisis y actualización se pueden habilitar por separado.
Los análisis y las actualizaciones omitidos se ejecutan tan pronto como el agente de NinjaOne se conecta con el servidor.
Recuperación de análisis y actualizaciones omitidos
Escaneos omitidos
Casi la mitad de los usuarios de NinjaOne recuperan automáticamente cualquier análisis de parches que se haya omitido. Esta función resulta especialmente útil para aquellos que suelen realizar análisis fuera del horario laboral, cuando es probable que haya más dispositivos apagados.
| Recuperar análisis | No recuperar el análisis |
|---|---|
| 51 % | 49 |
Actualizaciones perdidas
Recuperar las actualizaciones perdidas es menos habitual que recuperar los escaneos. Las actualizaciones fuera de horario suelen interrumpir más a los usuarios finales debido a la utilización de recursos o a la necesidad de reiniciar el dispositivo tras la actualización.
| Recuperar la actualización | No recuperar la actualización |
|---|---|
| 60 % | 40 |
Aprobaciones de parches
NinjaOne te permite configurar flujos de trabajo de aprobación para cada una de las cuatro clasificaciones de gravedad de las actualizaciones de seguridad de Microsoft y las siete categorías de actualizaciones de Microsoft. Puedes aprobar o rechazar automáticamente, o bien aprobar o rechazar manualmente los parches en función de su categoría.
En las siguientes secciones, compartiremos los perfiles de aplicación de parches más comunes que los usuarios de NinjaOne aplican a sus dispositivos.
Aprobaciones de actualizaciones de seguridad
| Gravedad | Descripción ( de Microsoft) |
|---|---|
| Crítica | Una vulnerabilidad cuya explotación podría permitir la ejecución de código sin la interacción del usuario. Estos escenarios incluyen malware que se propaga por sí mismo (por ejemplo, gusanos de red) o situaciones de uso común inevitables en las que la ejecución de código se produce sin advertencias ni avisos. Esto podría significar navegar por una página web o abrir un correo electrónico. |
| Importante | Una vulnerabilidad cuya explotación podría comprometer la confidencialidad, la integridad o la disponibilidad de los datos del usuario, o la integridad o disponibilidad de los recursos de procesamiento. Estos escenarios incluyen situaciones de uso común en las que el cliente recibe advertencias o mensajes, independientemente de la procedencia, la calidad o la usabilidad de estos. |
| Moderada | Factores como los requisitos de autenticación o su aplicabilidad únicamente a configuraciones no predeterminadas mitigan significativamente el impacto de la vulnerabilidad. |
| Bajo | Las características del componente afectado mitigan de forma exhaustiva el impacto de la vulnerabilidad. Microsoft recomienda a los clientes que evalúen si deben aplicar la actualización de seguridad a los sistemas afectados. |
Categorías de actualizaciones
| Gravedad | Descripción ( de Microsoft) |
|---|---|
| Crítica | Una corrección de amplia distribución para un problema específico que soluciona un error crítico no relacionado con la seguridad. |
| Normal | Una corrección de amplia distribución para un problema específico que soluciona un error no crítico y no relacionado con la seguridad. |
| Paquete acumulativo | Conjunto acumulativo y probado de revisiones, actualizaciones de seguridad, actualizaciones críticas y actualizaciones que se agrupan para facilitar su implementación. |
| Paquetede servicio | Conjunto acumulativo y probado de todas las revisiones, actualizaciones de seguridad, actualizaciones críticas y actualizaciones. Además, los Service Packs pueden contener correcciones adicionales para problemas detectados internamente desde el lanzamiento del producto. |
| Paquete de características | Nueva funcionalidad del producto que se distribuye por primera vez fuera del contexto de una versión del producto y que, por lo general, se incluye en la siguiente versión completa del producto. |
| Paquete de definiciones | Actualización de software frecuente y de amplia distribución que contiene adiciones a la base de datos de definiciones de un producto. Las bases de datos de definiciones se utilizan a menudo para detectar objetos que tienen atributos específicos, como código malicioso. |
| Controladores | Software que controla la entrada y salida de un dispositivo. |
| Actualización de características | Especifica una actualización de las características y funcionalidades de Windows 10. |
Perfiles de parches comunes
Seleccione un tipo de perfil para obtener más información:
- Perfil de parches predeterminado
- Perfil de automatización de aprobación total
- Perfil de automatización equilibrado y de bajo riesgo
- Perfil de bajo riesgo y baja automatización
- Perfil totalmente manual
Perfil de aplicación de parches predeterminado
Muchos de nuestros socios aprovechan el perfil de aplicación de parches predeterminado de NinjaOne, que se centra en equilibrar la automatización que ahorra tiempo con la reducción de riesgos.
Casi todas las aprobaciones en este perfil están automatizadas. Se aprueban las actualizaciones importantes y se rechazan las opcionales para maximizar el ahorro de tiempo. Los parches opcionales y de baja prioridad se rechazan automáticamente para mantener un alto nivel de automatización, pero evitando el riesgo operativo.
Las actualizaciones de controladores y funciones están desactivadas en este perfil, ya que este tipo de actualizaciones son más propensas a causar problemas a los usuarios finales.
| Aprobaciones de actualizaciones de seguridad | Estado de la aprobación |
|---|---|
| Bajo | Rechazar |
| Moderado | Manual |
| Importante | Aprobar |
Crítico | Aprobar |
| Aprobaciones | Importante | Opcional |
|---|---|---|
| Actualizaciones críticas | Aprobar | Rechazar |
| Actualizaciones periódicas | Aprobar | Rechazar |
| Paquetes de actualizaciones | Aprobar | Rechazar |
| Paquetes de servicio | Aprobar | Rechazar |
| Paquetes de definiciones | Aprobar | Rechazar |
| Aprobacionesavanzadas | |
|---|---|
| Conductores | Desactivado |
| Actualizaciones de funciones | Desactivado |
Perfil de automatización total de aprobaciones
El perfil de automatización total es el segundo perfil más utilizado por los socios de NinjaOne. Este perfil aprueba automáticamente todos los parches de Microsoft.
Este perfil garantiza que todos los dispositivos asociados a la política estén siempre actualizados, pero expone a los dispositivos a cierto riesgo operativo debido a parches problemáticos.
Combinar este perfil con análisis frecuentes de parches permite a los técnicos evitar el riesgo operativo rechazando los parches problemáticos cuando surgen y antes de que se apliquen.
Combinar este perfil con dispositivos de prueba también permite observar el resultado de la aplicación de parches antes de implementarlos en los equipos de producción.
| Aprobaciones de actualizaciones de seguridad | Estado de la aprobación |
|---|---|
| Bajo | Aprobar |
| Moderado | Aprobar |
| Importante | Aprobar |
| Crítico | Aprobar |
Aprobaciones | Importante | Opcional |
|---|---|---|
Actualizaciones críticas | Aprobar | Aprobar |
Actualizaciones periódicas | Aprobar | Aprobar |
Paquetes de actualizaciones | Aprobar | Aprobar |
Paquetes de servicio | Aprobar | Aprobar |
Paquetes de definiciones | Aprobar | Aprobar |
Aprobaciones avanzadas | ||
|---|---|---|
Conductores | Habilitado | Aprobar |
Actualizaciones de funciones | Habilitado | Aprobar |
Perfil de automatización equilibrado y de bajo riesgo
Este perfil da prioridad al cumplimiento del 100 % de los parches, al tiempo que intenta minimizar el riesgo operativo equilibrando la automatización con las aprobaciones manuales.
Este perfil requiere una mayor intervención manual para alcanzar el cumplimiento total de los parches, pero con la ventaja añadida de que se pueden evitar los parches problemáticos que no son críticos para la seguridad o el funcionamiento de un dispositivo.
Para aprovechar las ventajas de este perfil, los técnicos deben revisar y aprobar o rechazar manualmente los parches con regularidad.
Aprobaciones de actualizaciones de seguridad | Estado de la aprobación |
|---|---|
Bajo | Manual |
Moderado | Manual |
Importante | Aprobar |
Crítico | Aprobar |
Aprobaciones | Importante | Opcional |
|---|---|---|
Actualizaciones críticas | Aprobar | Manual |
Actualizaciones periódicas | Aprobar | Manual |
Paquetes de actualizaciones | Aprobar | Manual |
Paquetes de servicio | Aprobar | Manual |
Paquetes de definiciones | Aprobar | Manual |
Aprobaciones avanzadas | ||
|---|---|---|
Conductores | Habilitado | Manual |
Actualizaciones de funciones | Habilitado | Manual |
Perfil de bajo riesgo y baja automatización
Este perfil también equilibra la automatización con la intervención manual.
En este caso, los parches opcionales se rechazan automáticamente, mientras que las actualizaciones de seguridad y las importantes requieren aprobación manual.
Este perfil intenta automatizar la eliminación de los parches menos importantes, al tiempo que minimiza los riesgos operativos derivados de los parches problemáticos.
Los socios de NinjaOne que utilicen este perfil deberán revisar y aprobar periódicamente los parches pendientes para garantizar la seguridad de los endpoints.
Aprobaciones de actualizaciones de seguridad | Estado de la aprobación |
|---|---|
Bajo | Manual |
Moderado | Manual |
Importante | Manual |
Crítico | Manual |
Aprobaciones | Importante | Opcional |
|---|---|---|
Actualizaciones críticas | Manual | Rechazar |
Actualizaciones periódicas | Manual | Rechazar |
Paquetes de actualizaciones | Manual | Rechazar |
Paquetes de servicio | Manual | Rechazar |
Paquetes de definiciones | Manual | Rechazar |
Aprobacionesavanzadas | ||
|---|---|---|
Controladores | Habilitado | Manual |
Actualizaciones de funciones | Habilitado | Manual |
Perfil manual completo
El perfil de aplicación de parches totalmente manual permite a los técnicos controlar por completo qué parches se aplican y cuáles no.
Todos los parches disponibles para un dispositivo aparecerán como pendientes hasta que se aprueben o se rechacen.
Aunque sigue siendo mucho más eficiente que la aplicación de parches tradicional, este perfil será el que requiera más trabajo en NinjaOne. Podría exponer a los usuarios a riesgos tanto de seguridad como operativos si los parches no se aplican con la suficiente rapidez.
Los usuarios que utilicen este perfil deben contar con procedimientos operativos estándar (SOP) para comprobar periódicamente su cadencia de aplicación de parches.
Aprobaciones de actualizaciones de seguridad | Estado de aprobación |
|---|---|
Bajo | Manual |
Moderado | Manual |
Importante | Manual |
Crítico | Manual |
Aprobaciones | Importante | Opcional |
|---|---|---|
Actualizaciones críticas | Manual | Manual |
Actualizaciones periódicas | Manual | Manual |
Paquetes de actualizaciones | Manual | Manual |
Paquetes de servicio | Manual | Manual |
Paquetes de definiciones | Manual | Manual |
Aprobacionesavanzadas | ||
|---|---|---|
Controladores | Habilitado | Manual |
Actualizaciones de funciones | Habilitado | Manual |
Comportamiento al reiniciar
Para completar las actualizaciones de Windows, a menudo es necesario reiniciar los dispositivos.
Conseguir que los usuarios finales reinicien sus dispositivos es casi imposible, por lo que NinjaOne te permite automatizar este proceso.
Las políticas de NinjaOne permiten aplicar diferentes acciones y programaciones dependiendo de si un usuario ha iniciado sesión o no.
Usuario conectado
Acciones de reinicio
La mayoría de los usuarios de NinjaOne no utilizarán políticas para forzar un reinicio en los usuarios finales tras la aplicación de parches; en su lugar, solicitarán al usuario que reinicie el equipo. Muchas políticas no reinician automáticamente en absoluto. Un pequeño porcentaje de políticas sí fuerza los reinicios.
Acción | Descripción | Frecuencia |
|---|---|---|
Solicitar al usuario | Solicitar al usuario que reinicie hasta que acepte el reinicio | 65 % |
Notificar al usuario | Notificar al usuario y, a continuación, reiniciar tras un periodo de tiempo | 10 |
Reinicio automático | Reiniciar automáticamente tras un periodo de tiempo | 4 |
Ninguno | No hacer nada | 20 |
Reinicio / Tiempo de espera de la solicitud
El intervalo de tiempo más habitual entre avisos, entre el aviso y el reinicio, o entre la finalización de la aplicación del parche y el reinicio es de 5 minutos. A medida que la acción de reinicio se vuelve más agresiva, también lo hace el plazo.
Duración | Aviso | Notificar | Reinicio automático |
|---|---|---|---|
5 minutos | 65 % | 41 % | 76 % |
5 – 59 | 9 % | 37 % | 18 % |
60 – 239 | 14 | 13 % | 4 |
240+ | 12 % | 9 % | 6 % |
Usuario no conectado
Acciones de reinicio
La mayoría de las políticas de NinjaOne reinician los dispositivos tras la aplicación de parches según un calendario. Dado que no hay ningún usuario conectado, los reinicios inmediatos son más habituales que cuando los usuarios están conectados.
Acción | Descripción | Frecuencia |
|---|---|---|
Reinicio programado | Notificar al usuario y, a continuación, reiniciar tras un periodo de tiempo | 67 % |
Reiniciar inmediatamente | Reiniciar el dispositivo inmediatamente | 18 % |
Ninguna | No hacer nada | 14 % |
Programa de reinicio (semanal)
El 12 % de las políticas que se reinician semanalmente lo harán en los siguientes días:
Dom | Lun | Mar | Mié | Jue | Vie | Sáb |
|---|---|---|---|---|---|---|
46 % | 5 % | 5 % | 3 % | 5 % | 8 % | 27 % |
Programación de reinicio (diario)
El 85 % de las políticas que se reinician a diario lo harán durante los siguientes horarios:
00:00 – 8:50 | 9:00 – 16:59 | 17:00 – 17:59 | 18:00 – 23:59 |
|---|---|---|---|
19 % | 2 | 57 % | 22 % |