Respuesta directa
En pocas palabras
Un SLA de remediación de vulnerabilidades para sistemas de IA debe separar al menos cuatro relojes: confirmar aplicabilidad, contener exposición, implementar una corrección y verificar el estado efectivo. Los objetivos se asignan según explotación conocida, exposición, impacto, criticidad y controles, no únicamente por CVSS. Cada caso conserva inicio, pausas válidas, responsable, autoridad, vencimiento, excepción temporal y evidencia de cierre. Los plazos de CISA BOD 22-01 aplican a agencias federales civiles de Estados Unidos; otras organizaciones pueden usarlos como referencia, no como obligación universal.
Define qué compromiso mide el SLA
Un SLA útil no dice solo corregir críticas en cierto número de días. Define el servicio de remediación: qué sistemas, ambientes, componentes, equipos y tipos de vulnerabilidad entran; qué evento inicia cada reloj; qué resultado lo detiene; y quién puede aceptar una excepción. Separa obligaciones contractuales, políticas internas, objetivos operativos y métricas de observación para no presentar todos como la misma promesa.
Fija producto, release, digest, ambiente, región, propietario y recorridos incluidos. Considera aplicación, runtimes de IA, parsers, imágenes, notebooks, pipelines, drivers, herramientas de build y servicios administrados. Un caso fuera de producción puede seguir dentro si firma artefactos o accede a secretos. Publicar un SLA sin frontera crea incumplimientos invisibles y permite excluir trabajo difícil después de medir.
Separa detección, triage, contención, corrección y verificación
Registra cuándo la organización pudo conocer el caso, cuándo lo ingirió, cuándo confirmó identidad y aplicabilidad, cuándo redujo la ruta, cuándo desplegó el fix y cuándo verificó el cierre. Estos eventos permiten distinguir retraso del feed, cola de análisis, dificultad operativa y ausencia de validación. Un único tiempo hasta cierre oculta dónde se acumula la exposición.
Usa estados explícitos: nuevo, correlacionando, en triage, aplicable, no aplicable con evidencia, contención en curso, mitigado temporalmente, corrección en prueba, desplegado, verificando, resuelto o excepción vigente. Cada transición conserva timestamp, actor, fuente y comentario estructurado. Reabrir no borra el ciclo anterior. Si cambia el advisory o el release, crea una nueva evaluación relacionada.
| Criterio | Resultado | Prueba de término |
|---|---|---|
| Triage | Aplicabilidad y prioridad asignadas | Componente, release, ruta y decisión |
| Contención | Exposición reducida | Control activo probado en la ruta |
| Remediación | Causa técnica tratada | Fix, rebuild, reemplazo o retiro desplegado |
| Verificación | Estado efectivo conciliado | Digest, retest, residuos y evidencia actualizados |
Inicia el reloj con una señal registrable y una política versionada
Define si el reloj de triage comienza al publicar el advisory, al recibirlo una fuente aprobada o al relacionarlo con inventario. Elige una regla que tu sistema pueda demostrar y mide aparte el retraso de ingesta. Para alertas internas, empieza cuando una herramienta o persona autorizada registra evidencia suficiente. No reinicies el reloj al mover el ticket entre equipos.
Guarda advisory, fuente, published y modified time, componente, release, primer seen at, policy version y datos faltantes. Una alerta duplicada se relaciona con el caso original sin alterar el inicio. Si un proveedor comunica después una fecha anterior, conserva ambas. La política aplicable es la vigente al evento y cualquier cambio posterior queda visible; no reescribas objetivos históricos para mejorar la métrica.
Asigna objetivos desde prioridad contextual
Usa la prioridad ya decidida sobre un release aplicable. CVSS aporta severidad técnica; EPSS puede aportar probabilidad estimada; CISA KEV, explotación observada; SSVC, una salida de acción. Añade exposición, privilegios, datos, consumidores, misión, controles, fix y detectabilidad. No conviertas un CVSS alto en un plazo automático si el componente no aplica, ni uses un EPSS bajo para aplazar una ruta crítica.
Crea pocos niveles, por ejemplo actuar, atender, preparar y vigilar, con criterios legibles. Cada nivel asigna objetivos distintos a triage, contención, corrección y verificación. Establece condiciones de escalamiento: explotación confirmada, internet exposure, acceso sin autenticación, secretos, múltiples tenants, ransomware, seguridad humana o control fallido. La prioridad puede subir mientras el caso está abierto y el nuevo objetivo no elimina la deuda anterior.
Construye una matriz de tiempos basada en capacidad y riesgo
Diseña tiempos con datos de tu operación: cobertura de inventario, guardias, ventanas, automatización, ambientes, pruebas, dependencia de proveedores y capacidad de rollback. Usa percentiles históricos en vez de promedios que ocultan colas largas. Primero establece objetivos que reduzcan exposición y luego invierte para hacerlos más exigentes; publicar plazos imposibles solo incentiva cierres administrativos.
Una matriz puede exigir triage en horas para explotación conocida, contención el mismo día y corrección tan pronto como exista una ruta segura; otros casos pueden trabajar por ciclos. Son ejemplos, no obligaciones universales. Especifica unidad de tiempo, calendario, zona, horario continuo o hábil, feriados, severidad, ambiente y evento de inicio. Evita palabras como inmediatamente sin una definición medible.
Usa fechas regulatorias o directivas sin generalizarlas
CISA BOD 22-01 obliga a las agencias federales civiles del poder ejecutivo de Estados Unidos a remediar vulnerabilidades del catálogo KEV según las fechas indicadas. CISA anima a otras organizaciones a priorizar KEV, pero eso no convierte la directiva en una obligación universal ni en una regla jurídica para empresas de México o América Latina.
Registra la fuente de cada plazo externo, jurisdicción, entidad cubierta, producto, fecha efectiva y método de cumplimiento. Contratos, sectores, clientes o autoridades pueden imponer otros tiempos. Valida obligaciones con asesoría competente. Una referencia pública puede informar diseño y benchmarking, pero la política interna debe distinguir claramente requerido, acordado y voluntario.
Reconoce la contención sin confundirla con corrección
Una mitigación puede cortar la ruta antes de que exista o se pruebe un patch. Deshabilitar uploads, bloquear un formato, retirar un endpoint, rotar secretos, aislar una imagen, reducir privilegios o limitar egress puede satisfacer el objetivo de contención si la prueba demuestra cobertura. Registra qué escenario reduce, desde cuándo, dónde y con qué riesgo residual.
El reloj de remediación continúa salvo que la política autorice otro resultado, como retiro permanente o reemplazo. Una regla temporal que nunca vence se convierte en arquitectura no evaluada. Monitorea bypass, deriva de configuración y degradación operativa. Si la contención falla, reabre el reloj de exposición y escala. Contener protege tiempo; no modifica el advisory ni borra la causa.
Incluye adquisición, prueba, despliegue y rollback en el objetivo
La remediación puede actualizar, reconstruir, reemplazar, configurar, retirar o eliminar una ruta. Planifica adquisición del fix, verificación de procedencia, build reproducible, pruebas de seguridad y regresión, evaluación de comportamiento de IA, aprobación, rollout y rollback. Un cambio de parser, runtime o driver puede corregir una vulnerabilidad y a la vez cambiar calidad, compatibilidad, rendimiento o consumo.
Define un carril de emergencia con controles reducidos pero explícitos, no una ruta sin identidad ni evidencia. Prueba el escenario relevante, incompatibilidades y recuperación. Despliega por etapas cuando la urgencia lo permita; observa errores y exposición. El rollback no debe reinstalar automáticamente la versión vulnerable. Prepara una versión anterior corregida, modo limitado o pausa segura.
Gestiona bloqueos de proveedor sin detener el reloj en silencio
Si un servicio administrado, modelo, imagen o paquete depende de un tercero, registra solicitud, compromiso, evidencia, alternativas y próxima revisión. Esperando proveedor es un estado de dependencia, no una pausa automática. El propietario interno conserva la decisión sobre exposición, datos, uso, sustitución y continuidad.
Define criterios para aceptar una pausa: no existe fix, se probó una contención, hay monitoreo, autoridad y fecha límite. Escala por contrato o soporte; evalúa versión alternativa, fork, wrapper, aislamiento o retiro. Si el proveedor no expone versión o estado, conserva el límite como incertidumbre. Un SLA externo puede respaldar coordinación, pero no reemplaza tu objetivo frente al negocio.
Trata cada excepción como una decisión temporal de riesgo
Una excepción contiene sujeto, vulnerabilidad, motivo, nivel, impacto, evidencia, control compensatorio, propietario, autoridad, inicio, vencimiento y condición de salida. No cierres el caso; relaciónalo con la excepción vigente. Si el alcance cambia, la excepción no se extiende por herencia. Una aprobación para staging no cubre producción ni otro release.
Exige revisión antes del vencimiento y alerta con margen suficiente. La renovación usa evidencia nueva, no copia la explicación anterior. Limita quién puede aprobar según nivel y conflicto de interés. Mide excepciones activas, edad, renovaciones, controles fallidos y exposición acumulada. La excepción vencida vuelve a incumplimiento y escalamiento, no a un limbo sin dueño.
Asigna dueño operativo, autoridad de riesgo y escalamiento
Distingue quién correlaciona, quién analiza, quién contiene, quién construye el fix, quién prueba, quién aprueba y quién verifica. Un responsable de ticket sin acceso o autoridad no controla el resultado. Usa roles y suplencias, guardias para niveles urgentes y un incident commander cuando exista explotación o efecto observado.
Escala antes del vencimiento según riesgo y bloqueo: owner, líder técnico, seguridad, negocio, privacidad, proveedor y autoridad ejecutiva cuando corresponda. El escalamiento aporta decisión o recursos, no solo más destinatarios. Conserva cuándo se solicitó ayuda y qué se resolvió. Seguridad no debe ser dueña de reparar todos los productos; el propietario del sistema conserva mantenimiento y continuidad.
Detén el reloj solo con cierre verificado
El cierre requiere demostrar que el componente corregido o la respuesta aprobada está en el estado efectivo. Confirma digest, versión, ambiente y porcentaje de rollout; repite correlación, scan y prueba de la ruta; busca workers, notebooks, cachés e imágenes residuales. Actualiza AI/ML-BOM, provenance, lineage, VEX y registro de riesgo.
Separar deploy y verify muestra cuánto tarda la organización en saber que está protegida. Un pipeline exitoso, ticket cerrado o imagen publicada no bastan. Si hubo indicios de explotación, la corrección técnica no cierra investigación ni conciliación de efectos. Conserva evidencia de cada ciclo y permite reapertura sin perder la primera fecha.
Mide cumplimiento, exposición y calidad sin incentivar atajos
Mide por nivel y etapa: tiempo de ingesta, triage, contención, fix y verificación; porcentaje dentro del objetivo; backlog; edad; tiempo en bloqueo; días de exposición; excepciones; reaperturas; fallas de fix y releases residuales. Publica mediana y percentiles 75, 90 y 95, además del volumen. Un promedio puede mejorar mientras los casos críticos envejecen.
Añade indicadores de calidad: conclusiones no aplicables muestreadas, controles probados, casos sin inventario, fuentes vencidas, cierres sin digest, violaciones repetidas y cobertura por producto. No recompenses cerrar como false positive ni cambiar nivel cerca del vencimiento. Audita transiciones y compara capacidad demandada con disponible. La métrica debe impulsar menor exposición, no una cola más bonita.
Mejora el SLA reduciendo trabajo y variabilidad
NIST plantea patch management como mantenimiento preventivo y recomienda simplificar decisiones. Estandariza imágenes, versiones soportadas, manifests, ownership, ventanas, pruebas y rollback. Automatiza correlación, canary y verificación; reduce componentes abandonados y variantes innecesarias. Cuanto más homogéneo el fleet, más rápido puede responder sin aumentar riesgo de cambio.
Revisa trimestralmente la matriz y después de incidentes o incumplimientos relevantes. Ajusta criterios con resultados: casos explotados, falsos positivos, fallas de parche, tiempo de proveedor y capacidad. Endurece objetivos solo cuando controles y personal puedan sostenerlos. Si el volumen supera capacidad, reduce superficie, prioriza productos críticos y comunica la deuda; no escondas el problema cambiando definiciones.
Aplica el SLA a releases y límites de Cerravi
En Cerravi, cada caso se vincula con release, digest, AI/ML-BOM, provenance, registry, lineage, admisión, pruebas y runtime. El flujo separa triage, contención, corrección y verificación; conserva backup, release anterior permitido y journal. La promoción ocurre mediante gates y readiness; el cierre confirma el artefacto público y el estado efectivo sin incluir secretos en evidencia.
Este proceso no amplía las capacidades públicas del producto. Cerravi organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente desde los recorridos públicos. Las propuestas usan productos y precios conocidos y solicitan revisión si falta un importe. Forecast usa reglas transparentes del CRM, no un modelo predictivo entrenado o calibrado, y no garantiza cierres. Un SLA cumplido, un scan o un parche tampoco certifican seguridad, cumplimiento ni ausencia de riesgo residual.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué debe medir un SLA de remediación de vulnerabilidades?
Debe medir por separado el tiempo para confirmar aplicabilidad, contener exposición, implementar la respuesta y verificar el estado efectivo. También conserva inicio, pausas válidas, prioridad, responsable, excepción, vencimiento y evidencia. Un único tiempo hasta cerrar el ticket oculta los retrasos reales.
¿Cuántos días hay para corregir una vulnerabilidad crítica?
No existe un plazo universal para toda empresa. Depende de obligación aplicable, explotación, exposición, impacto, controles, fix y capacidad. La organización define objetivos medibles por etapa y nivel. Los plazos de CISA BOD 22-01 obligan a agencias FCEB de Estados Unidos, no automáticamente a empresas de México o LATAM.
¿Una mitigación detiene el SLA de remediación?
Puede satisfacer un objetivo separado de contención si reduce la ruta y fue probada. El objetivo de remediación continúa salvo que una política aprobada acepte retiro, reemplazo u otra respuesta final. La mitigación necesita propietario, cobertura, monitoreo, vencimiento y riesgo residual.
¿Se puede pausar el SLA mientras responde un proveedor?
Solo si la política define una pausa válida y existe evidencia, contención, responsable, autoridad, próxima revisión y fecha límite. Esperando proveedor no debe detener el reloj en silencio. La organización conserva decisiones sobre exposición, continuidad, sustitución y aceptación temporal.
¿Cuándo se considera cerrada una vulnerabilidad?
Cuando la respuesta aprobada está en el ambiente correcto, el digest o versión efectivos se confirmaron, la ruta fue probada, no quedan despliegues residuales relevantes y se actualizaron BOM, lineage, VEX y riesgo. Si hubo posible explotación, la investigación puede continuar después del fix.