La ruta de emergencia

La guía distingue escenarios. El parcheo rutinario es el de calendario regular, la inmensa mayoría. El parcheo de emergencia atiende una vulnerabilidad grave o explotada activamente cuando ya hay parche. La mitigación de emergencia es el procedimiento para crisis parecidas cuando el parche todavía no existe o cuando el parche falla, tiene un defecto o rompe otro software. Aparte están los activos no parcheables.

Para decidir qué ruta usar hace falta una evaluación de riesgo definida de antemano, que además diga cuándo cambiar de plan al cambiar lo que se sabe. Como orientación externa, el catálogo de vulnerabilidades explotadas conocidas de la agencia de ciberseguridad de EE. UU. sirve a muchas organizaciones para elevar un caso, y la directiva BOD 22-01 exige a las agencias federales remediar en dos semanas lo que entra en él. Vitalcor lo usa de forma voluntaria. La tabla aviso trae el aviso de este ejercicio y la tabla escenarios, las rutas.

La guía recomienda que el parcheo de emergencia siga el mismo enfoque que el rutinario, pero con un calendario muy acelerado. Y aun con prisa conviene probar primero en un número pequeño de activos canarios, para confirmar que el parche no está corrupto y no rompe el software. Ese periodo puede durar desde minutos hasta unas horas. La misma lógica vale para una mitigación: se aplica primero en un activo de prueba y se verifica.

La tabla activos_afectados marca cuál es el canario entre los activos que usan el producto del aviso.

Un plan de emergencia vale lo que tarda en ejecutarse. La política de Vitalcor fija un plazo máximo para terminar la mitigación de emergencia, que consta en la tabla escenarios, y la bitácora deja las horas reales.

Calcula, con las horas de la bitácora del día del aviso, cuánto transcurrió entre que se recibió el aviso y que la mitigación quedó completa en los activos expuestos. Responde en minutos.

La guía pide planear el reemplazo de las mitigaciones de emergencia por arreglos permanentes. Cuando el parche existe, hay que desplegarlo y retirar la mitigación, y las dos acciones deben tener un calendario fijado y cumplido. Una mitigación que se queda sin fecha de retirada termina siendo parte permanente del sistema, con efectos que nadie recuerda, como un módulo desactivado que alguien necesitará algún día.

La tabla retiro_de_mitigacion muestra lo planeado para este aviso.