¿Sabes qué porcentaje de tus equipos tiene instaladas las actualizaciones de seguridad que ya deberían tener? La mayoría de los directores de TI no pueden responder esa pregunta con un número, y no porque no les importe, sino porque nadie revisa manualmente cada servidor y estación de trabajo para confirmarlo.
Dentro del módulo de Protección de TecnetSOC vive justamente la capacidad de Parcheo, pensada para eso: mide compliance por dispositivo, prioriza lo pendiente por severidad y documenta cada parche que ya se aplicó, todo bajo un SLA definido de antemano.
El problema de fondo es que un equipo sin parchar no se distingue a simple vista de uno actualizado. Sigue encendido, sigue funcionando, sigue procesando lo que le corresponda. La brecha solo se nota cuando alguien explota la vulnerabilidad que ese parche hubiera cerrado, y para entonces ya no es un tema de mantenimiento sino de incidente.
El problema no es parchar, es saber qué falta y desde cuándo
Ninguna empresa mediana o grande aplica el cien por ciento de sus parches el mismo día que salen. Eso tampoco es realista, ni siempre es lo prioritario. El problema real es otro: sin un número de compliance y un SLA por severidad, no hay forma de distinguir un parche de rutina que puede esperar de uno crítico que lleva semanas expuesto.
Sin visibilidad centralizada, la única forma de saber qué falta es revisar equipo por equipo, algo que ningún equipo de TI sostiene de forma constante. El resultado es que los parches críticos (los que corrigen vulnerabilidades con explotación activa o día cero) se mezclan en la misma lista que actualizaciones menores, sin que nadie distinga cuál lleva más tiempo fuera de su ventana de remediación.
El módulo de parcheo convierte esa pregunta abierta en un número verificable: cuántos endpoints están al día, qué les falta, con qué urgencia y qué se les aplicó ya.
Cómo funciona el módulo de parcheo de TecnetSOC
1. El estado general en cuatro cifras
Al entrar al módulo, el portal muestra de inmediato el compliance de parches (qué porcentaje de tus endpoints está al día), los parches críticos que requieren atención inmediata, el total de parches pendientes desglosado por prioridad (críticos, importantes y rutina) y el número de dispositivos bajo gestión activa.
En un entorno recién incorporado a monitoreo, con deuda técnica acumulada, ese compliance puede empezar en 0%, como punto de partida real antes de que el proceso de parcheo se ponga en marcha.
Debajo, una tabla lista cada dispositivo con su sistema operativo, el conteo de parches críticos, importantes y de rutina pendientes, la fecha del último parche aplicado y un estado (urgente o pendiente).
Al hacer clic sobre cualquier hostname, el portal lleva directo a la ficha de ese equipo en el módulo de activos, con su postura de protección completa, su historial de dueño y sus indicadores de salud. El parcheo nunca se evalúa en abstracto: siempre está anclado al dispositivo específico que lo necesita.
2. Parches pendientes, ordenados por urgencia real
Esta vista es la lista de trabajo que un equipo de TI revisa día a día. Cada fila muestra el identificador del boletín (KB), el título de la actualización, su severidad, el hostname afectado, cuántos días lleva pendiente y su fecha de publicación original, con búsqueda por KB, título o hostname y filtro por severidad.
El campo de días pendiente es el que marca la diferencia. Un parche crítico de Windows con 41 días pendiente no es lo mismo que uno con 7; ambos están sin aplicar, pero el primero lleva mucho más tiempo fuera del SLA que le corresponde. Esta vista existe justamente para que esa distinción no se pierda entre decenas de actualizaciones acumuladas.
3. Historial de lo ya instalado
El módulo lleva registro de cada parche aplicado en los últimos 30 días: KB, título, severidad, hostname y fecha y hora exacta de instalación. Es el respaldo que responde la pregunta que surge en cualquier auditoría o revisión de postura: ¿esto realmente se instaló, cuándo y en qué equipo? Tener este historial disponible sin depender de un ticket o un correo perdido es lo que convierte el parcheo en un proceso auditable en lugar de una promesa.
4. Reglas del proceso, documentadas y no supuestas
La pestaña de configuración deja por escrito cómo opera el ciclo completo, no qué falta por aplicar. El calendario de parcheo sigue una ventana de mantenimiento fija (segundo y cuarto sábado de cada mes, de 10 PM a 2 AM hora local), pensada para no interferir con horario productivo.
Para que el parche se aplique en esa ventana, el único requisito es que el equipo esté encendido y conectado a la red durante ese horario.
El SLA de remediación se define por severidad: 48 horas para vulnerabilidades críticas con día cero o explotación activa, 7 días para las importantes con riesgo de escalamiento de privilegios, 30 días para actualizaciones de rutina y 60 días para funcionalidad, como actualizaciones menores de aplicaciones y drivers no críticos (a diferencia de las actualizaciones de versión del propio sistema operativo o los drivers de hardware específico, que quedan fuera del servicio, como se detalla más abajo).
Esta escala sigue la misma lógica que ya usa el módulo de vulnerabilidades para priorizar remediación por CVSS: aquí se traduce en una fecha límite concreta para aplicar el parche correspondiente.
También queda documentado qué cubre el servicio (actualizaciones de seguridad de Windows, acumulativas mensuales, .NET Framework, Microsoft Office y M365, navegadores como Edge y Chrome, y software crítico de terceros como Adobe, Java y Zoom) y qué no (feature updates de Windows, firmware y BIOS, drivers de hardware específico, software de línea de negocio como ERP o CRM, y reinicios de servicios productivos sin coordinación previa). Esa línea evita ambigüedad sobre qué entra en el SLA y qué requiere una conversación aparte.
5. Un proceso de cinco pasos, no un botón de "aplicar todo"
Cada parche pasa por escaneo, clasificación, prueba, despliegue y verificación. La aprobación es automática para críticos dentro de 48 horas, con revisión del SOC en 7 días para importantes y validación previa en el piloto para rutina. Los reinicios se aplican en la ventana de mantenimiento, salvo en servidores críticos, donde se coordinan directamente con el cliente.
Cómo se integra con el resto de TecnetSOC
El módulo de parcheo no funciona aislado. El módulo de vulnerabilidades identifica qué CVEs afectan a cada equipo y con qué severidad; el parcheo es el mecanismo que cierra esa brecha aplicando la actualización correspondiente dentro del SLA que le toca según esa misma severidad.
Y cada dispositivo que aparece en la tabla de parches es, el mismo activo que ya tiene su ficha completa en el módulo de activos: su postura de protección, su historial de dueño, su clasificación de criticidad. Por eso el clic en el hostname no es un atajo cualquiera, sino la forma natural de moverte entre "qué le falta a este equipo" y "quién es este equipo y qué tan importante es".
El costo de no tener un SLA de parcheo
Cuando no hay un SLA definido, "vamos a parchar pronto" significa cosas distintas para cada persona del equipo, y esa ambigüedad es justo la que un atacante aprovecha. El día "Exploit Wednesday", como se conoce en la industria al día siguiente de que Microsoft libera sus actualizaciones mensuales, los atacantes ya están haciendo ingeniería inversa de los parches para construir exploits contra quien todavía no los aplicó. Sin un tiempo máximo de remediación por severidad, esa ventana de exposición no tiene fin definido.
Con un SLA visible por dispositivo, la conversación cambia de "¿ya se parchó?" a "¿cuántos días le quedan a este equipo antes de salirse del SLA crítico?". Eso convierte el parcheo de una tarea reactiva en un compromiso medible, con una fecha límite concreta detrás de cada parche pendiente, no solo una intención de aplicarlo cuando haya tiempo.
Checklist: cinco preguntas sobre tu proceso de parcheo
- Sabes qué porcentaje de tus equipos está al día con parches de seguridad ahora mismo, sin pedirle a nadie que lo revise.
- Puedes distinguir con datos qué parches críticos llevan más tiempo pendiente y cuáles acaban de salir.
- Tienes un SLA definido por severidad, no un "se aplica cuando se pueda".
- Puedes confirmar qué parche se instaló, cuándo y en qué equipo, sin buscar en un ticket viejo.
- Sabes qué queda fuera del servicio de parcheo (firmware, drivers, feature updates) antes de que se convierta en una sorpresa.
Esta visibilidad es la que TecnetSOC integra de forma nativa junto con la gestión de vulnerabilidades, el inventario de activos y el resto de los módulos que lo conforman.
Cómo empezar con el módulo de parcheo
Si ya eres cliente de TecnetSOC, el módulo de parcheo está disponible dentro de tu portal: ahí consultas tu compliance actual, revisas qué parches críticos siguen pendientes y confirmas el historial de lo ya aplicado.
Si todavía no eres cliente, esta es la pregunta que vale la pena hacerse: si te pidieran ahora mismo el porcentaje de compliance de parches de tu empresa, ¿podrías darlo con un número o tomaría días armarlo a mano? Si la respuesta no te convence, agenda una sesión con uno de nuestros especialistas para revisar el estado real de tu proceso de parcheo hoy.
