Un incidente no se maneja solo con herramientas.
También necesita roles, evidencia, decisiones rápidas y comunicación clara.
Cuando no hay proceso, cada minuto se va en decidir quién hace qué. Por eso el manejo de incidentes debe prepararse antes de la crisis, no durante el momento de mayor presión.
1. Preparación
La preparación ocurre antes del incidente.
Incluye definir responsables, activos críticos, contactos, respaldos, fuentes de logs, canales de comunicación y criterios para escalar.
También implica practicar escenarios. No necesitas esperar una crisis real para detectar huecos en el proceso. Un simulacro pequeño puede revelar que nadie sabe quién autoriza aislar un servidor, dónde están los respaldos o qué evidencia debe conservarse.
2. Identificación
La identificación busca confirmar si una alerta es un incidente y cuál podría ser su alcance.
Aquí se revisan señales como accesos extraños, actividad anómala, cambios no autorizados, malware, tráfico inusual, reglas de correo desconocidas o reportes de usuarios.
Tip práctico: define niveles de severidad. No todos los eventos requieren la misma respuesta, pero todos deben tener un criterio claro.
3. Contención
La contención busca limitar el impacto.
Puede incluir aislar equipos, deshabilitar cuentas, bloquear tráfico, revocar sesiones, preservar evidencia o pausar servicios afectados.
Estas acciones deben tomarse con cuidado porque pueden afectar operación. Por eso conviene tener criterios definidos antes: qué se puede contener de inmediato, qué requiere aprobación y quién debe ser informado.
4. Erradicación
Después de contener, el equipo debe eliminar la causa del incidente: credenciales comprometidas, malware, configuraciones débiles, accesos indebidos o vulnerabilidades explotadas.
La erradicación requiere entender causa raíz. Si solo se atiende el síntoma, el incidente puede repetirse.
5. Recuperación
La recuperación busca regresar servicios a un estado confiable.
Esto puede incluir restaurar respaldos, validar integridad, monitorear comportamiento, reforzar controles y confirmar que el entorno no sigue comprometido.
No basta con que el sistema vuelva a encender. Debe volver con evidencia razonable de que el riesgo inmediato fue atendido.
6. Lecciones aprendidas
Cuando la operación vuelve, todavía queda trabajo.
Documenta línea de tiempo, impacto, decisiones, controles faltantes, acciones correctivas y responsables.
Esta fase convierte el incidente en mejora real. Si no hay aprendizaje, el mismo patrón puede aparecer otra vez con otro nombre.
Qué debe incluir un plan mínimo
Un plan de respuesta no necesita ser enorme para ser útil. Debe responder preguntas prácticas:
- Quién coordina el incidente.
- Qué activos son prioritarios.
- Qué canales se usan si el correo está comprometido.
- Dónde se guarda evidencia.
- Cómo se decide contención.
- Cómo se valida recuperación.
- Qué se comunica internamente.
Un proceso conectado con tu operación
El manejo de incidentes debe adaptarse a tu empresa. No es lo mismo proteger una aplicación, una red interna, correo, endpoints o infraestructura cloud.
En Syscore podemos ayudarte con gestión de incidentes, monitoreo y análisis de seguridad y preparación práctica para responder con menos improvisación.
Métricas que sí ayudan
No necesitas medir todo desde el primer día. Empieza con indicadores que muestren si el proceso funciona:
- Tiempo para confirmar si una alerta era incidente.
- Tiempo para contener el primer activo afectado.
- Número de decisiones bloqueadas por falta de responsable.
- Evidencia faltante durante la investigación.
- Acciones correctivas cerradas después del incidente.
Estas métricas no son para castigar al equipo. Sirven para encontrar fricción y mejorar antes del siguiente evento.
Errores que debes evitar
El primer error es borrar evidencia por intentar limpiar demasiado rápido. Contener no significa destruir el rastro que necesitas para investigar.
El segundo es comunicar tarde. Si dirección, TI y operación no tienen la misma versión, el incidente se vuelve más difícil de coordinar.
El tercero es cerrar el caso cuando el servicio vuelve. Si no revisas causa raíz, el riesgo puede seguir activo aunque el sistema parezca normal.