Respuesta a incidentes de seguridad para un equipo pequeño: un procedimiento mínimo

Objetivo

Gestionar un presunto compromiso (credencial filtrada, dependencia explotada, inicio de sesión de administrador inesperado, página desfigurada) de modo que el daño quede limitado, la evidencia sobreviva y el equipo aprenda de ello, sin contar con una función de seguridad dedicada.

Requisitos previos

NIST SP 800-61 Rev. 3 (abril de 2025) sitúa la respuesta a incidentes dentro de la gestión continua de riesgos de ciberseguridad de una organización bajo el Cybersecurity Framework 2.0: preparada de antemano, no improvisada. La hoja de referencia de OWASP sobre diseño seguro de productos incluye entre sus recomendaciones de configuración un plan de respuesta a incidentes de seguridad practicado. Preparar de antemano: una lista de contactos (quién decide, quién puede revocar credenciales, proveedor de alojamiento, registrador de dominios, proveedor de pagos), un inventario de secretos con sus pasos de rotación, registros enviados fuera de los hosts que describen, y una regla de evidencia por escrito.

Pasos

1. Declarar: una persona lo designa como incidente, abre un documento de cronología y registra a partir de ese momento cada acción con marca de tiempo. Dos roles como máximo: encargado de la respuesta y encargado de la comunicación.
2. Delimitar el alcance: ¿a qué credenciales, hosts y datos podría haber llegado el atacante? Asumir el peor caso plausible hasta que la evidencia lo acote.
3. Contener antes de erradicar: revocar o rotar las credenciales expuestas, cortar la vía del atacante (deshabilitar la cuenta, eliminar la clave, desconectar el endpoint) y rotar todo secreto que el componente comprometido pudiera leer. Preferir acciones reversibles.
4. Preservar la evidencia antes de destruir el estado: tomar instantáneas de discos o contenedores, exportar los registros, anotar los procesos y las conexiones en ejecución; luego reconstruir en lugar de limpiar in situ.
5. Erradicar y recuperar: reconstruir los sistemas afectados a partir de imágenes y código fuente conocidos como correctos, aplicar la corrección, restaurar los datos desde copias de seguridad tomadas antes del compromiso allí donde la integridad esté en duda, y confirmar que toda credencial rotada está en uso.
6. Comunicarse de forma objetiva con los usuarios y socios afectados; qué obligaciones de notificación aplican depende de la jurisdicción y de los contratos, y debe verificarse con alguien cualificado para determinarlo.
7. Cerrar con un post mortem sin búsqueda de culpables: cronología, causa raíz, qué detección lo habría detectado antes, acciones con responsables asignados.

Resultado esperado

La primera hora sigue una lista de verificación en lugar de un debate; el post mortem cuenta con evidencia sobre la que trabajar; toda credencial que el atacante pudiera haber visto ha sido rotada; el incidente produce cambios concretos en la detección y la configuración.

Límites y base de verificación

Esto es una síntesis de las directrices citadas, reducida a la escala de un equipo pequeño, no un procedimiento legal o normativo; las obligaciones no se especifican aquí. Ensayarlo una vez con una clave filtrada ficticia: un plan que nunca se ha ejecutado es un documento, no una capacidad.