Se denomina “brecha de parche” y describe el tiempo que tarda una solución para que una vulnerabilidad conocida se filtre desde el proveedor de software hasta los fabricantes de dispositivos individuales. Meses después de que un proveedor emitiera una corrección, los fabricantes de dispositivos Android posteriores aún no han parcheado, lo que destaca una tendencia […]
Se denomina “brecha de parche” y describe el tiempo que tarda una solución para que una vulnerabilidad conocida se filtre desde el proveedor de software hasta los fabricantes de dispositivos individuales.
Meses después de que un proveedor emitiera una corrección, los fabricantes de dispositivos Android posteriores aún no han parcheado, lo que destaca una tendencia preocupante.
Según Project Zero de Google, después de que su equipo descubriera cinco errores separados en el controlador de GPU ARM Mali, ARM “inmediatamente” emitió un parche en julio y agosto. Sin embargo, Project Zero informó que todos los dispositivos de prueba que observaron esta semana siguen siendo vulnerables.
Hasta que haya una mejor solución para reducir el retraso entre el momento en que se emite un parche y llega al ecosistema más amplio, depende de los equipos de seguridad permanecer “vigilantes”, aconsejó el equipo de Google Project Zero.
“Así como se recomienda a los usuarios aplicar parches lo más rápido posible una vez que esté disponible una versión que contenga actualizaciones de seguridad, lo mismo se aplica a los proveedores y empresas”, explicó el informe de brecha de parches. “Minimizar la ‘brecha de parches’ como proveedor en estos escenarios es posiblemente más importante, ya que los usuarios finales (u otros proveedores posteriores) están bloqueando esta acción antes de que puedan recibir los beneficios de seguridad del parche”.
Algunas definiciones indican que un incidente corresponde a “una violación o inminente amenaza de violación a las políticas de ciberseguridad de una organización… ”. Hoy en día he observado que las organizaciones se refieren a ello como “un evento” a pesar que el mismo estándar (NIST 800-61r2) define a esto último como “una ocurrencia observable […]