Reportar solo cuando hay daño comprobado: el error que retrasa la respuesta a incidentes

Un correo que parece de tu banco. Una memoria USB olvidada en la sala de juntas. Un archivo compartido con alguien que ya no trabaja en la empresa. Cualquiera de estas situaciones podría no ser nada, o podría ser el inicio de un incidente de seguridad de la información. La reacción más común, en casi cualquier organización, es la misma: esperar. Esperar a estar seguro antes de decirle a alguien. Ese instinto, tan razonable en apariencia, es uno de los errores que más retrasan la respuesta a incidentes y uno de los que ISO/IEC 27001 pide corregir directamente en la cultura de la organización, no solo en el procedimiento.

Qué pide ISO/IEC 27001 sobre el reporte de incidentes

ISO/IEC 27001 es la norma internacional para sistemas de gestión de seguridad de la información. Uno de sus controles pide un proceso claro y conocido por todo el personal para reportar eventos de seguridad de la información, entendidos de forma amplia: cualquier situación que pudiera indicar una brecha, no solo la confirmación de que ya ocurrió. La norma no espera que cada persona sepa diagnosticar un incidente. Espera que sepa avisar, y que avisar sea sencillo, rápido y sin consecuencias negativas para quien lo hace de buena fe.

El error: reportar solo cuando el daño ya es evidente

En casi todas las organizaciones donde revisamos el proceso de respuesta a incidentes aparece el mismo patrón: la política de reporte existe, la gente la conoce en general, pero en la práctica el reporte llega tarde. Llega cuando el daño ya es visible —el sistema está caído, el cliente ya llamó, la cuenta ya fue usada de forma indebida— y no cuando la señal de alerta apareció por primera vez, mucho antes. Entre esos dos momentos se pierde exactamente el tiempo que un equipo de respuesta necesita para actuar bien: contener el problema antes de que crezca, conservar evidencia digital antes de que se sobrescriba, y cumplir plazos de aviso a clientes o autoridades que en muchos marcos legales corren desde el conocimiento razonable del hecho, no desde su confirmación total.

Por qué pasa

La razón de fondo es el miedo: a equivocarse, a que lo señalen como quien «levantó la alarma por nada», a interrumpir a un equipo ocupado con una sospecha que después resulta ser una falsa alarma. Nadie quiere ser esa persona. Y como reportar y confirmar suelen quedar mezclados en la cabeza de quien detecta la señal —«si reporto, tengo que estar seguro de que es grave»— la decisión se pospone hasta que ya no hay duda posible. Para entonces, el margen de maniobra ya se redujo mucho.

Cómo se hace bien

La corrección no es exigir más certeza antes de actuar; es exactamente lo contrario. Se trata de bajar el costo de reportar algo que termina no siendo nada:

• Separar reportar de investigar. El trabajo de la persona que detecta la señal es avisar una situación razonable, no diagnosticarla. El proceso de respuesta a incidentes es quien confirma si fue algo o no.
• Un canal simple y conocido. Un solo lugar para reportar, sin formularios largos ni preguntas que exijan ya saber qué pasó.
• Cero consecuencias por un reporte de buena fe. Ninguna organización debería tener casos donde alguien se arrepintió de haber reportado.
• Medir la velocidad, no solo el volumen. El indicador que importa es cuánto tiempo pasa entre la primera señal y el primer reporte, no cuántos incidentes reales hubo en el año.

Un ejemplo: la USB de la sala de juntas

Alguien encuentra una memoria USB sin etiqueta en la sala de juntas después de una reunión con proveedores externos. No sabe de quién es, no sabe qué contiene, y conectarla para revisarla suena a mala idea. La reacción más común es guardarla «por si alguien la reclama» y no decir nada, porque reportar «una USB» suena exagerado. En una organización con la cultura correcta, esa misma persona reporta el hallazgo en cuanto lo tiene, sin necesidad de saber si es grave. El equipo de seguridad decide qué hacer: aislarla, analizarla en un entorno controlado o simplemente resguardarla con registro. El costo de reportar fue mínimo. El costo de no hacerlo, si la memoria hubiera tenido software malicioso listo para ejecutarse al conectarla a cualquier equipo de la red, habría sido mucho mayor.