Una alegación no es una brecha
Muchas alegaciones publicadas se reciclan de incidentes anteriores, se arman a partir de fuentes públicas o se inventan para presionar a una organización a pagar. Algunas son reales. La tarea consiste en distinguirlas con rapidez y decirlo con un nivel de confianza expresado.
Trabajar con lo que es público
Quienes formulan la alegación suelen publicar una descripción, un listado de archivos o un pequeño extracto en apoyo de ella. Capturamos la publicación tal como la vería un visitante cualquiera, calculamos el hash de la captura y trabajamos únicamente con lo que se muestra públicamente. No descargamos conjuntos de datos completos, no nos unimos a grupos cerrados ni contactamos con el autor de la alegación.
Comparar estructuras, no personas
Las preguntas útiles son estructurales. ¿Coinciden con sus sistemas los nombres de campo, los formatos y los patrones de identificadores? ¿Encajan las fechas de los registros con el momento de acceso alegado? ¿Contiene el extracto publicado valores que sus sistemas nunca generarían? Estas comprobaciones se realizan sobre las estructuras de datos de su organización, sin que nadie trate los datos personales del extracto.
Tres respuestas posibles
Una verificación concluye con una de tres afirmaciones: coherente con sus datos, incoherente con sus datos o todavía no evaluable. Cada una se acompaña de los motivos, las fuentes y los límites de lo comprobado. Un resultado coherente no prueba una brecha, y uno incoherente no prueba que la alegación sea falsa.
Qué ocurre después
Si la alegación es coherente, sus equipos de respuesta a incidentes y jurídico deciden qué hacer, incluidas las obligaciones de notificación. Conservamos las capturas con su hash para que el análisis pueda comprobarse más adelante. Nunca anunciamos públicamente una brecha; los hallazgos se comunican primero a la organización afectada y, cuando sea exigible, a las autoridades.