Nos han pedido cumplir con el marco NIST para respuesta a incidentes: ¿lo adaptamos o creamos nuestro propio plan?

Sin gestión de logs, la adaptación NIST no pasa la auditoría. Monta una estructura sencilla que pase los logs de servidor, accesos de administración y eventos del firewall a un almacenamiento separado y de solo lectura. Si no puedes probar que el atacante no borró los registros, la fase de análisis se queda totalmente en el aire.

Al redactar el documento, deja clarísimos tres puntos: 1) ¿Cómo se determinan los niveles de incidente (bajo, medio, crítico)? 2) ¿Cuántas horas se comprometen para notificar al cliente y a las autoridades? 3) Si quien decide no está disponible, ¿en quién se delega la autoridad? El auditor irá directo a estos tres aspectos.

Los auditores de grandes clientes corporativos suelen venir con listas de verificación estándar. Tú intentas hacer un plan perfecto porque dijeron "NIST", pero el auditor solo va a marcar las casillas del formulario. No te quemes: crea un borrador sencillo que cumpla los requisitos mínimos y confírmalo antes con el cliente.

El año pasado pasamos por una auditoría parecida. Pasamos la inspección a la primera con un documento simple de 12 páginas y el acta de un simulacro de escritorio de dos horas que hicimos seis meses antes. Sin consultores externos; todo lo preparó el equipo interno en dos semanas de trabajo.

Lo primero es definir los roles del equipo por cargo y no por nombre propio. Si pones que "Ahmet apaga el servidor", cuando se vaya de la empresa el plan ya no sirve. Si defines "el Administrador de Sistemas inicia la contención" y "el Gestor de Cuentas notifica", actualizarlo será facilísimo.

¿Cómo se hace exactamente eso del simulacro de escritorio? ¿Nos juntamos todos en una sala a discutir el escenario o hay que apagar servidores de verdad y hacer pruebas técnicas?

Ojo con los plazos de notificación de incidentes respecto al contrato principal y acuerdos de confidencialidad que tengáis firmados. El plazo de tu plan NIST no puede ser mayor que el comprometido en el contrato, o podrías asumir responsabilidades legales.

Por lo que veo, la clave no es escribir tomos de documentación: es definir roles, asegurar los logs, trazar un flujo sencillo de contención y documentarlo al año con un simulacro de escritorio. A nivel de pyme no se necesita más.

ha sido una buena idea abrir este hilo pero tomar notas durante dos semanas da mejores resultados que estimar seis meses.

una copia de seguridad no probada no es una copia de seguridad. pues ánimo.

Este hilo es para archivar. Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después.

Todo lo que no está por escrito, ambas partes lo recordarán de forma distinta en el futuro.

Yo no me apresuraría. Si obtienes tres respuestas distintas sobre un tema, la pregunta está mal formulada.

Yo seguiría por ese camino.

Hay tres cosas que revisar al hacer esto. Empezad con una pequeña prueba, no lo integréis todo de golpe.

Que todo el mundo haga algo no significa que sea lo correcto. Si tenéis dudas, escribid, os responderé en la medida de lo posible.

No sabía eso.

Es correcto en general, pero falta un detalle. Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

Yo también pienso lo mismo. Si decidimos sin medir, siempre acabamos en el mismo punto.

Eso es todo, disculpa si me he extendido demasiado.

Tiene razón.

Me pasó lo mismo.

En su momento, nosotros también nos atascamos ahí. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Comprobado por experiencia.