Qué ocurrió realmente

La reconstrucción que ha surgido de las investigaciones periodísticas es sencilla, lo que la hace precisamente preocupante. Un atacante obtuvo el control de una cuenta de correo perteneciente a un organismo gubernamental real. Desde esa cuenta, envió a la fintech solicitudes de información de clientes haciéndose pasar por requerimientos de las fuerzas de seguridad. Las peticiones procedían de un dominio gubernamental legítimo, por lo que superaron los controles técnicos que suelen alertar sobre suplantaciones de identidad, y se tramitaron a través del procedimiento habitual de la empresa para gestionar requerimientos judiciales y gubernamentales.

La empresa trató las solicitudes como legítimas y facilitó los datos. Posteriormente describió el incidente como una estafa externa por suplantación de identidad en lugar de una brecha en sus propios sistemas, una interpretación que resulta sólida tras un análisis riguroso: no existen pruebas públicas de una intrusión en la red, y la compañía ha afirmado que ni los fondos de los clientes ni los sistemas centrales se vieron comprometidos en ningún momento. Lo que sí ocurrió fue una brecha de datos personales que, según la propia definición del RGPD, lo es con independencia de si un solo servidor se vio afectado. La revelación no autorizada a un tercero no legitimado constituye, en sí misma y sin ambigüedades, una brecha de seguridad.

Un remitente verificado no equivale a una solicitud autorizada

El trasfondo incómodo que subyace a este incidente es algo que la mayoría de las organizaciones no han ponderado plenamente: la autenticación y la autorización son problemas distintos, y la mayoría de los procesos de divulgación solo verifican el primero.

SPF, DKIM y DMARC existen para responder a una única pregunta: ¿procede realmente este mensaje del dominio que afirma proceder? Cumplen esa función con eficacia, pero no dicen nada sobre si la persona concreta que lo envía está autorizada para realizar esa solicitud específica, si la base jurídica que cita es realmente aplicable o si el volumen y la naturaleza de lo que solicita se ajustan a un requerimiento legítimo. Una cuenta comprometida dentro de un dominio gubernamental real supera los tres controles sin dificultad. El dominio es genuino; la persona que está detrás, en esta ocasión, no lo es.

Las solicitudes procedentes de organismos públicos y fuerzas de seguridad conllevan una confianza institucional específica que agrava este problema en lugar de mitigarla. Un requerimiento que parece oficial tiende a tramitarse con mayor rapidez y con menos cuestionamientos, que es precisamente la premisa con la que cuenta el atacante.

El aspecto que debería preocupar a los equipos de cumplimiento más que la propia brecha

Que un único correo fraudulento supere las verificaciones es un contratiempo grave. Lo que presuntamente ocurrió aquí es diferente: el mismo patrón de solicitudes se mantuvo, sin ser detectado, durante un periodo prolongado. No se trata de un correo aislado que burló un filtro, sino de un proceso de verificación que carecía de mecanismos para identificar una falsificación correctamente autenticada, incluso después de haber funcionado con éxito en repetidas ocasiones.

La mayoría de las organizaciones pueden exhibir una política que establece que las solicitudes gubernamentales se gestionan con rigor. Muchas menos pueden demostrar que dicha política incluya un paso obligatorio y específico, como confirmar el requerimiento a través de un canal de contacto obtenido de forma independiente —y no proporcionado en la propia solicitud— antes de revelar cualquier información. Sin este paso formalizado por escrito y aplicado de forma efectiva, la «gestión rigurosa» se convierte silenciosamente en un «tramitar como cualquier otra solicitud», sin que nadie lo advierta hasta que el incidente se ha repetido varias veces.

Lo que está confirmado y lo que sigue siendo solo una afirmación

Escribir de manera responsable sobre un incidente en curso exige rigor a la hora de delimitar qué detalles son sólidos y cuáles no lo son todavía. A fecha de redacción de este informe:

Hechos razonablemente contrastados: un atacante utilizó una cuenta de correo gubernamental comprometida para enviar solicitudes fraudulentas de datos de clientes. La empresa facilitó la información creyendo que las peticiones eran legítimas. Ni los sistemas de la empresa ni los fondos de los clientes sufrieron una brecha. Las autoridades están investigando los hechos.

Informado por medios de comunicación, sin confirmación oficial: el número exacto de clientes afectados y la oficina gubernamental concreta cuya cuenta fue comprometida.

Afirmado únicamente por el atacante, sin verificación por ningún organismo oficial: el volumen total de datos supuestamente obtenidos, el tiempo durante el cual la cuenta gubernamental estuvo comprometida y la cuantía del rescate exigido. Las buenas prácticas de gobernanza son claras al respecto: las afirmaciones de un ciberdelincuente sobre la información que posee constituyen una estrategia de marketing para la extorsión, no evidencias, mientras una fuente independiente no las confirme.

Qué significa esto si su organización recibe un requerimiento gubernamental

Casi todas las entidades reguladas —servicios financieros, sector sanitario, telecomunicaciones— disponen de un procedimiento para responder a requerimientos de información judiciales o gubernamentales, ya que la legislación suele exigirlo. La cuestión que plantea este incidente no es si existe dicho procedimiento, sino si cuenta con un control efectivo diseñado para este escenario específico: una solicitud que parece completamente legítima pero que podría no serlo.

Un control adecuado en este ámbito debe ser específico y no genérico. Una formulación adecuada sería: antes de revelar datos personales en respuesta a un requerimiento gubernamental, judicial o de las fuerzas de seguridad, verifique de forma independiente la identidad y autoridad del solicitante, la base jurídica del requerimiento y su alcance, utilizando datos de contacto obtenidos de fuentes independientes y nunca los facilitados en la propia solicitud. Las solicitudes de gran volumen o inusuales requerirán obligatoriamente una segunda revisión antes de enviar cualquier información.

Por escrito parece evidente. La razón por la que falla en la práctica es que rara vez se integra en la operativa diaria de los equipos de recepción y casi nunca se somete a prueba con solicitudes que parecen perfectamente legítimas.

Cómo te ayuda Formalize en este escenario

Este es un problema de control antes que de tecnología, y la función de Formalize es garantizar que el control exista realmente en algún lugar más allá de un documento de política que nadie consulta bajo presión. En la práctica, esto implica:

• Un control documentado para las revelaciones ante organismos gubernamentales y judiciales, integrado junto al resto de tus controles en lugar de guardado en un archivador independiente, y con un responsable asignado.

• Pasos de verificación integrados en el flujo de trabajo, de modo que cada solicitud se compruebe con criterios definidos antes de entregar la información, y no después.

• Un registro de quién aprobó la revelación y por qué motivos, garantizando que, si la solicitud se cuestiona más adelante, la justificación esté disponible sin tener que reconstruirla de memoria.

• El mismo control reutilizado en múltiples marcos normativos, ya que este riesgo de revelación afecta al RGPD y suele solaparse con obligaciones bajo marcos como DORA o la ISO 27001.

Nada de esto sustituye al criterio humano: asegura que el criterio se aplique de forma coherente, en cada ocasión, incluida la única vez en que más importa.