Claude Bucle de Hardening Post-Incidente

Referencias oficiales: Best Practices · Hooks · Security · GitHub Actions

Por qué importa este bucle

La respuesta a incidentes restaura el servicio. El hardening reduce la repetición del incidente.

Sin bucle de hardening, cada incidente vuelve a costar caro.

Línea de tiempo de hardening

Modelo de backlog de hardening

Clasifica acciones en tres buckets:

• Detección más rápida: umbrales de alerta, pistas de dashboard, ruteo de pager
• Prevención de recurrencia: pruebas, checks estáticos, hooks de política
• Recuperación más rápida: confiabilidad de rollback, plantillas de handoff, mapa de owners

Cada ítem debe tener un owner y una fecha límite.

Ejecución en tres lanes

• Lane de controles: agrega hooks, checks y guardrails de CI
• Lane de calidad: agrega cobertura de regresión para la clase raíz
• Lane de operaciones: actualiza runbook y protocolo de comunicación

Mantén independencia entre lanes para reducir fricción de merge.

Scorecard de preparación

Usa score 0 o 1 por fila:

• clase raíz cubierta por prueba
• rollback ensayado
• owner de escalación documentado
• dashboard/alertas actualizados
• runbook actualizado y confirmado

Si el score es < 4, el hardening está incompleto.

Regla de cierre

Cierra solo cuando todo sea verdadero:

• scorecard en objetivo
• guardrails nuevos en uso real
• owners de seguimiento confirman adopción
• no queda acción de alto riesgo sin resolver

Plantilla de paquete de evidencia

Al cerrar hardening, archiva:

• id del incidente + resumen
• controles implementados
• enlaces a evidencia de pruebas
• diff del runbook
• owners + fechas de trabajo residual

Anti-patrones avanzados

Retro escrita, controles no enviados

Aprender sin controles no cambia el riesgo.

Prueba añadida sin actualización de ownership

El sistema mejora, pero el contrato del equipo sigue débil.

Cierre antes de verificar adopción

Un guardrail no usado en el flujo real no protege producción.

Checklist rápido

Antes de cerrar el bucle:

• mínimo 1 guardrail automatizado mergeado
• mínimo 1 prueba de regresión mergeada
• actualización de runbook publicada
• confirmación de owners registrada

Claude acelera la recuperación. El hardening es lo que acumula confiabilidad.

Matriz de priorización de hardening

Prioriza acciones con dos ejes:

• Magnitud de reducción de riesgo
• Tiempo hasta adopción operativa

Cierra P0/P1 antes de optimizar redacción.

Diseño de experimentos de hardening

Gestiona cada acción como experimento:

1. Hipótesis: "Si añadimos X, la clase Y baja Z%."
2. Medida: métrica + ventana de observación.
3. Guardrail: condición de rollback del propio control.
4. Owner: uno de ejecución y otro de verificación.
5. Fecha de revisión: fecha fija.

Ejemplo

• hipótesis: rehearsal obligatorio de rollback reduce varianza de MTTR SEV-1
• medida: p95 MTTR en próximos 4 incidentes/simulacros
• guardrail: si lead time empeora >20% en 2 ciclos, recalibrar gate

Ritmo operativo de ownership

Standup semanal de confiabilidad (20 min)

• revisar items vencidos
• revisar items sin evidencia sólida
• reasignar bloqueados en la sesión
• prohibir cierre sin enlace de evidencia

Auditoría mensual de controles

• validar que controles siguen activos
• validar owners vigentes
• retirar controles sin impacto medible

Rúbrica de calidad de hardening (0–2)

Mínimo de aprobación: 7/10. Si no, el loop sigue abierto.

Plantilla de backlog

### Hardening Item
- Incident reference:
- Failure class:
- Proposed control:
- Priority band: P0/P1/P2/P3
- Execution owner:
- Verifier owner:
- Due date:
- Evidence link(s):
- Adoption check date:
- Status: open | in_progress | verified | retired

Fallos comunes del programa

• se cierran items sin efecto en métricas
• se agregan controles sin socialización operativa
• se actualiza runbook pero no checklist on-call
• ownership queda en persona no disponible

Resuélvelo con auditoría mensual explícita.

Mapeo hallazgo → diseño de control

Este mapeo mantiene hardening concreto.

Plantilla sprint de hardening (14 días)

• Día 1–2: priorizar por riesgo y reversibilidad
• Día 3–5: implementar controles P0/P1
• Día 6–8: añadir cobertura de verificación y links
• Día 9–11: validar adopción en flujo real
• Día 12–14: publicar resumen + owners de riesgo residual

Si hay retraso, reduce alcance pero no recortes verificación.

Formato de registro de riesgo residual

### Residual Risk
- Risk statement:
- Why not fully solved yet:
- Temporary control in place:
- Trigger for re-prioritization:
- Owner:
- Target resolution date:

Riesgo residual sin trigger/fecha es riesgo sin gestión.

Marco económico de controles

Cada control de hardening tiene costo. Haz explícitos los trade-offs.

Prioriza primero mejor relación riesgo-reducción/esfuerzo.

Checklist de adopción

Un control no termina al merge.

• owners pueden ejecutarlo sin conocimiento implícito
• ruta de fallo del propio control documentada
• checklist on-call actualizado
• logs/dashboard prueban ejecución real del control

Control mergeado pero no usado = confianza falsa.

Gate QA de hardening

Antes de verified, exige:

1. evidencia de implementación (diff + salida de comandos)
2. evidencia de comportamiento (señal en simulacro/replay)
3. evidencia de ownership (signoff de owner + verifier)

Si falta uno, permanece in_progress.

Protocolo de retiro de controles

No todos los controles deben vivir para siempre.

Retira cuando:

• no mejora métricas objetivo
• duplica un control más fuerte
• costo operativo supera reducción de riesgo medida

Retirar requiere nota de reemplazo o justificación.

Secuenciación de rollout de controles

Despliega controles en tres fases:

1. Shadow mode — observar sin bloquear
2. Warn mode — exponer violaciones con ownership
3. Enforce mode — bloquear en condiciones de alto riesgo

Esto eleva seguridad sin romper operación abruptamente.

Score de adopción de hardening

Gestiona adopción con score 0–5:

• control habilitado en entorno objetivo
• owners entrenados y confirmados
• runbook actualizado con pasos ejecutables
• señal de dashboard confirma ejecución real
• al menos un incidente/simulacro usó el control

Menos de 4 significa adopción incompleta.

Ledger de deuda de confiabilidad

Mantén ledger dedicado para trabajo diferido:

Trabajo diferido sin fecha de revisión se vuelve riesgo permanente.