Matriz de referencia normativa BCRA sobre ciberseguridad, fraude, PSP y servicios financieros digitales

ℹ️ QUÉ ES ESTA MATRIZ

En los últimos años, el Banco Central de la República Argentina ha ido incorporando y actualizando distintas normas vinculadas a la gestión de riesgos tecnológicos, la seguridad de la información, los servicios financieros digitales, los proveedores de servicios de pago, las billeteras digitales, la prevención y gestión del fraude en pagos y transferencias, la continuidad operativa, la gestión de terceros y la respuesta ante ciberincidentes.

El resultado es un marco regulatorio cada vez más amplio, compuesto por Comunicaciones "A", Textos Ordenados y disposiciones complementarias que no siempre son fáciles de seguir de manera integrada.

Por eso, elaboramos de forma gratuita y abierta esta (super) Matriz de Referencia normativa BCRA, con el objetivo de ordenar las principales normas aplicables y facilitar una primera lectura.

ℹ️ METODOLOGÍA

La matriz fue elaborada a partir de Textos Ordenados (TO) del BCRA, Comunicaciones oficiales y el Boletín Oficial y permite identificar qué norma emitió o modificó una obligación, los sujetos alcanzados, cuáles son los objetivos y alcances de cada comunicación y la relación con la Ciberseguridad o la Prevención de Fraude con la interpretación técnica editorial sobre el impacto práctico en organizaciones como bancos, PSP, PSAV, servicios financieros y Fintech en general.

📑 Índice

1. Riesgos de tecnología y seguridad de la información (TI/SI)
2. Servicios financieros digitales (SFD)
3. PSP, billeteras digitales, pagos y fraude
4. Ciberincidentes y RRCI
5. Continuidad, resiliencia operacional y terceros
6. Textos Ordenados — referencia directa
7. Análisis: troncales, aplicabilidad y prioridad

Fuentes: La matriz fue elaborada a partir de Textos Ordenados del BCRA, Comunicaciones oficiales, Boletín Oficial e Infoleg. Las referencias marcadas como pendientes deben verificarse directamente en el buscador oficial del BCRA antes de su uso formal.
Criterio de inclusión: Incluye normas y Textos Ordenados vigentes o con efectos vigentes al momento de la revisión (22/06/2026). La vigencia debe verificarse al momento de uso. Las normas derogadas (A 4609, A 6354, A 6375, A 7370, A 7825, entre otras) fueron excluidas.
Sobre la interpretación: La columna "Relación con ciberseguridad / fraude" y las etiquetas de relevancia ("Troncal", "Relevante", "Complementaria", "Operativa") son clasificación e interpretación editorial, no denominaciones oficiales del BCRA.

⚠️ Aviso: Esta matriz tiene fines informativos y de orientación profesional. No constituye asesoramiento legal, regulatorio ni una opinión formal de cumplimiento. La normativa del BCRA puede modificarse, complementarse o ser reemplazada con frecuencia; por lo tanto, antes de utilizar esta información en auditorías, informes regulatorios, procesos de cumplimiento o decisiones legales, se recomienda verificar cada Comunicación y Texto Ordenado directamente en el sitio oficial del BCRA y/o con asesoramiento especializado.

Acceder a la Matriz

Por Lic. Bernardita Götte

Compliance Consultant en Segu-Info

Seguir leyendo...

Herramienta de Deep Fake amenaza KYC de plataformas cripto y bancos

Un actor de amenazas, conocido como "Jinkusu", está vendiendo un nuevo kit de fraude para engañar a los sistemas de verificación de identidad KYC (Conozca a su Cliente) en plataformas financieras mediante Deep Fakes generados por IA y alteración de voz en tiempo real.

La aparición de herramientas de deepfake es una llamada de atención para la industria, pues resalta las deficiencias de los sistemas de verificación KYC, según Deddy Lavid, CEO de la plataforma de seguridad de la blockchain Cyvers. La mejora de los algoritmos de IA será capaz de descifrar los sistemas de identidad KYC utilizando una sola imagen de la víctima.

La empresa de ciberseguridad Vecert Analyzer añadió que "Jinkusu" utiliza IA para intercambios de caras en tiempo real a través de InsightFace para "transferencias de gestos fluidas", junto con modulación de voz para evadir la biometría.

A medida que la IA reduce las barreras para el fraude de identidad sintética, la puerta principal siempre permanecerá vulnerable. Esto obliga a las plataformas a adoptar un enfoque de seguridad por capas que combine la verificación de identidad con el monitoreo de IA en tiempo real.

El autor del nuevo paquete de fraude, Jinkusu, es sospechoso de ser el mismo actor de amenazas que lanzó el kit de phishing Starkiller en febrero de 2026. A diferencia de los kits de phishing tradicionales basados en HTML, Starkiller crea un proxy inverso en tiempo real al generar un navegador Chrome sin interfaz gráfica dentro de un contenedor Docker, cargando la página de inicio de sesión genuina de la marca objetivo y retransmitiendo toda la entrada del usuario, incluidos el nombre de usuario y las contraseñas, al actor de amenazas, explicó la plataforma de ciberseguridad Abnormal, en un informe del 19 de febrero.

El nuevo kit de fraude también permite a los estafadores realizar estafas románticas, como el "pig butchering", sin necesidad de conocimientos técnicos.

Fuente: CoinAlertNews

Seguir leyendo...

VENON: primer RAT brasileño en Rust

Investigadores de ciberseguridad han revelado detalles de un nuevo malware bancario dirigido a usuarios brasileños, escrito en Rust, lo que representa una diferencia significativa con respecto a otras familias de malware conocidas basadas en Delphi y asociadas al ecosistema del cibercrimen latinoamericano.

Este malware, diseñado para infectar sistemas Windows y descubierto el mes pasado, ha sido bautizado como VENON por la empresa brasileña de ciberseguridad ZenoX. VENON destaca por compartir comportamientos similares a los de troyanos bancarios ya conocidos que operan en la región, como Grandoreiro, Mekotio y Coyote, especialmente en lo que respecta a características como la lógica de superposición bancaria, la monitorización activa de ventanas y un mecanismo de secuestro de accesos directos (LNK).

El malware no ha sido atribuido a ningún grupo o campaña documentada previamente. Sin embargo, se ha encontrado una versión anterior del artefacto, de enero de 2026, que expone rutas completas del entorno de desarrollo del autor del malware. Estas rutas hacen referencia repetidamente al nombre de usuario de la máquina Windows "byst4" (por ejemplo, "C:\Users\byst4\..."). "La estructura del código Rust presenta patrones que sugieren que el desarrollador estaba familiarizado con las capacidades de los troyanos bancarios latinoamericanos existentes, pero que utilizó IA generativa para reescribir y ampliar estas funcionalidades en Rust, un lenguaje que requiere una considerable experiencia técnica para alcanzar el nivel de sofisticación observado", afirmó ZenoX.

VENON se distribuye mediante una sofisticada cadena de infección que utiliza la carga lateral de DLL para ejecutar una DLL maliciosa. Se sospecha que la campaña aprovecha técnicas de ingeniería social como ClickFix para engañar a los usuarios y que descarguen un archivo ZIP que contiene las cargas útiles mediante un script de PowerShell.

Una vez ejecutada la DLL, realiza nueve técnicas de evasión, incluyendo comprobaciones anti-sandbox, llamadas al sistema indirectas, elusión de ETW y elusión de AMSI, antes de iniciar cualquier acción maliciosa. También se conecta a una URL de Google Cloud Storage para recuperar una configuración, instalar una tarea programada y establecer una conexión WebSocket con el servidor de comando y control (C2).

También se extrajeron de la DLL dos bloques de Visual Basic Script que implementan un mecanismo de secuestro de accesos directos dirigido exclusivamente a la aplicación bancaria Itaú. Estos componentes funcionan reemplazando los accesos directos legítimos del sistema con versiones manipuladas que redirigen a la víctima a una página web controlada por el atacante.

El ataque también incluye un paso de desinstalación para revertir las modificaciones, lo que sugiere que el atacante puede controlar la operación de forma remota para restaurar los accesos directos a su estado original y borrar las huellas.

En total, el malware bancario está diseñado para atacar a 33 instituciones financieras y plataformas de activos digitales mediante el monitoreo del título de la ventana y el dominio del navegador activo, activándose solo cuando se abre alguna de las aplicaciones o sitios web objetivo para facilitar el robo de credenciales mediante la visualización de superposiciones falsas.

Esta revelación se produce en medio de campañas en las que los atacantes están explotando la omnipresencia de WhatsApp en Brasil para distribuir un gusano llamado SORVEPOTEL a través de la versión web de escritorio de la plataforma de mensajería. El ataque se basa en el abuso de chats previamente autenticados para enviar señuelos maliciosos directamente a las víctimas, lo que finalmente resulta en la instalación de malware bancario como Maverick, Casbaneiro o Astaroth.

"Un solo mensaje de WhatsApp enviado a través de una sesión SORVEPOTEL comprometida fue suficiente para atraer a una víctima a una cadena de varias etapas que culminó con la implantación de Astaroth ejecutándose completamente en memoria", declaró Blackpoint Cyber. "La combinación de herramientas de automatización local, controladores de navegador sin supervisión y entornos de ejecución modificables por el usuario creó un entorno inusualmente permisivo, permitiendo que tanto el gusano como la carga útil final se establecieran con mínima fricción".

Fuente: THN

Seguir leyendo...

Bancos falsos (no phishing) explotan SEO y ofrecen servicios fraudulentos

Los investigadores de CTM360 han identificado una campaña de fraude a gran escala que involucra miles de sitios web bancarios falsos que atacan activamente a usuarios en Estados Unidos y el Reino Unido.

Durante el último año, se detectaron más de 11.000 dominios bancarios fraudulentos, con más de 8.000 en EE.UU. y más de 3.000 en el Reino Unido, todos operando sin autorización regulatoria ni presencia física.

No se trata de páginas de phishing desechables. Son plataformas optimizadas para SEO que se hacen pasar por instituciones financieras, reguladores y servicios de préstamo legítimos.

No es el típico fraude de phishing

Lo que distingue a esta campaña es su madurez operativa. Los bancos falsos ofrecen servicios como préstamos, hipotecas, subvenciones y tarjetas de crédito con límites altos, a menudo prometiendo aprobación instantánea o sin verificación de crédito. Las víctimas son canalizadas a través de procesos de incorporación simplificados, procesos KYC falsos y "aprobaciones" simuladas diseñadas para generar confianza antes de la monetización.

Una vez que se involucran, los usuarios son presionados para pagar las tarifas de activación o procesamiento, generalmente a través de billeteras de criptomonedas o la opción "Amigos de PayPal"; ambos métodos reducen significativamente la trazabilidad y las posibilidades de recuperación.

El SEO como vector de ataque

En lugar de basarse en la distribución de spam o malware, los actores de amenazas manipulan los algoritmos de los motores de búsqueda. CTM360 observó un uso excesivo de palabras clave, términos financieros específicos de la región y el abuso de dominios aparentemente confiables como .com, .net y .live. El resultado: bancos falsos que aparecen en los resultados de búsqueda junto con, o incluso por encima de, instituciones financieras legítimas.

Este enfoque revoluciona la economía tradicional del fraude. En lugar de perseguir a las víctimas, los atacantes permiten que las víctimas los encuentren.

Operaciones de fraude a escala industrial

En segundo plano, la infraestructura está diseñada para escalar:

• Registros masivos de dominios con alta tasa de abandono
• HTML, metadatos y branding reutilizados en miles de sitios
• Entornos de alojamiento compartidos y gratuitos para combinar tráfico malicioso con servicios legítimos
• Más de 30 plantillas de fraude observadas, lo que permite una rápida redistribución cuando se desactivan los dominios

CTM360 mapea esta actividad utilizando su Framework Fraud Navigator, inspirado en MITRE, mostrando un ciclo de vida completo, desde el desarrollo de recursos y la distribución SEO hasta la recolección de información personal identificable (PII) y la monetización basada en criptomonedas.

Por qué es importante esto

Los bancos falsos están surgiendo a nivel mundial, y se esperan más casos en otras regiones.

Los bancos falsos ya no son un fraude excepcional. Representan un abuso sistemático de la confianza digital, explotando la imagen de marca de los organismos reguladores, los motores de búsqueda y las expectativas de los usuarios en torno a las finanzas en línea. A medida que los servicios financieros continúan digitalizándose, la superficie de ataque se expande no solo para los bancos, sino también para los consumidores, los organismos reguladores y las plataformas que facilitan el descubrimiento.

La idea principal es clara: si la visibilidad, la credibilidad y la conversión se pueden convertir en armas, el fraude aumentará. La defensa ahora requiere la monitorización continua de la superficie de ataque externa: dominios, resultados de búsqueda y abuso de marca, más allá de las bandejas de entrada y los endpoints.

Fuente: THN

Seguir leyendo...

Delincuentes detrás del robo de U$S 140 millones al Banco de Brasil ya lavan su botín en criptos

El 30 de junio, delincuentes informáticos robaron aproximadamente U$S 140 millones violando seis cuentas de reserva de instituciones financieras brasileñas, a través de la infraestructura proporcionada por el software C&M, un proveedor de servicios clave que conecta a los instituciones con el banco central de Brasil y su sistema PIX.

El ataque ocurrió en apenas dos horas y media y afectó a todo el sistema de pago PIX y a las infraestructuras digitales del Banco Central (BC). El ataque se llevó a cabo mediante una intrusión en los sistemas informáticos de C&M Software, una empresa tecnológica autorizada por el Banco Central para conectar bancos menores y fintech a los sistemas centrales del sistema bancario nacional.

El robo involucró a un grupo de delincuentes sobornando a un empleado para que revelara sus credenciales corporativas. Como resultado, seis instituciones financieras experimentaron accesos no autorizados a sus cuentas de reserva. El hombre arrestado sospechoso de participación es un operador de TI de 48 años que comenzó como electricista del edificio. Fue arrestado el jueves y, según la policía, recibió U$S 2.700 por su contraseña de acceso para ingresar comandos en el sistema C&M.

Según el analista en la cadena ZachXBT, el grupo delictivo ha comenzado a lavar una parte de los U$S 140 millones utilizando criptomonedas. Los delincuentes informáticos ya lavaron entre U$S 30 y 40 millones de los 140 millones robados del proveedor de servicios del Banco Central de Brasil utilizando cripto a través del uso de exchanges OTC latinoamericanos. ZachXBT reveló el viernes que los fondos robados se convirtieron a BTC, ETH y USDT a través de exchanges latinoamericanos.

ZachXBT, una figura principal en Blockchain Forensics, informó que ha estado colaborando activamente con la policía brasileña para rastrear los fondos robados y evitar un mayor lavado. Las declaraciones públicas de ZachXBT indican que planea ayudar a las autoridades a congelar activos criptográficos adicionales.

Tras el descubrimiento, el Banco Central de Brasil instruyó rápidamente a C&M a reducir sus conexiones, aislando efectivamente al proveedor de los sistemas bancarios. La violación condujo a la suspensión temporal de los servicios relacionados con la billetera PIX.

El método utilizado es similar al ataque reciente a Coinbase, donde 69.000 clientes se vieron afectados después de que personas de atención al cliente fueran sobornadas para revelar información de dichos clientes.

Si bien el ataque del Banco Central de Brasil involucró la moneda fiduciaria, el uso de la criptomoneda para ocultar y lavar los fondos es un ejemplo de la oscura verdad de la industria cuando se trata de hacks y estafas.

Seguir leyendo...

Multa a banco por autorizar transferencias fraudulentas

El banco BBVA deberá devolverle $140 millones a una PyME que sufrió una ciberestafa. Un Tribunal de La Plata concluyó que el fraude fue posible por una vulneración del sistema de seguridad de la entidad. De esa manera, resolvió que le cabe la responsabilidad del hecho y la condenó a pagar una suma inédita y ejemplar.

El juez determinó que la entidad bancaria incumplió con su deber de seguridad al no monitorear ni controlar adecuadamente las operaciones realizadas desde la cuenta de la empresa, y la condenó a pagar casi 140 millones de pesos a la víctima.

El monto, inédito en casos de seguridad bancaria, se compone, según el fallo, del equivalente a 100 canastas básicas (al día de hoy son $103.371.600) por incumplimientos en las medidas de seguridad de sus operaciones electrónicas, y agrega la devolución de las sumas sustraídas a la pyme por medio de transferencias fraudulentas ocurridas luego de la estafa.

El caso se remonta al 20 de marzo de 2023, cuando el socio gerente de Grupo Logística Uno SRL, José Luis Aronna, intentó realizar una transferencia a un proveedor a través del sistema de Homebanking del BBVA. Durante la operación, la pantalla se congeló y, minutos después, la empresa descubrió que se habían realizado 18 transferencias no autorizadas a cuentas de terceros por un total de 39.999.342,29 de pesos y se había solicitado un préstamo no autorizado por 3.500.000.

Las transferencias fueron dirigidas a cuentas bancarias de personas y empresas desconocidas, algunas de las cuales figuraban en una "lista negra" de cuentas fraudulentas mantenida por el propio banco. La empresa denunció el hecho ante la entidad y presentó una denuncia penal por defraudación informática, que aún está en trámite.

¿Qué pasó y cómo tuvo lugar la estafa?

En el fallo, el perito informático determinó que la computadora de la empresa estaba infectada con un malware. Al acceder al Homebanking para hacer una operación de rutina, Aronna ingresó sus claves y el token necesario, como lo hace habitualmente. Pero esa vez, la pantalla se le "tildó". A partir de ese momento, el malware instalado capturó las credenciales.

De manera remota, los ciberdelincuentes que tenían control del malware, obtuvieron la contraseña y token, y produjeron el vaciamiento de la cuenta corriente bancaria: en menos de 30 minutos los lograron desviar $39.999.342,29 mediante 18 operaciones fraudulentas a 17 cuentas bancarias distintas y solicitaron el préstamo, que también transfirieron a cuentas desconocidas.

Los argumentos del juez para dictaminar la responsabilidad del banco

En principio, el juez encuadró el caso dentro de una relación de consumo, amparada por la Ley de Defensa del Consumidor (Ley 24.240), ya que el servicio bancario no estaba destinado a integrarse en un proceso de producción, sino a facilitar operaciones financieras cotidianas, como el pago a proveedores.

Además, se refiere a la Circular "A" 7969 del Banco Central de la República Argentina, que establece estándares de protección para los usuarios de servicios financieros, sin distinción entre personas físicas y jurídicas.

Este último es uno de los pilares del fallo: la obligación de seguridad que pesa sobre el banco. El juez sostuvo que, al ofrecer servicios electrónicos como el Homebanking, la entidad asume la responsabilidad de garantizar que su sistema sea seguro y confiable.

El fallo señala que el banco no cumplió con esta obligación, ya que no monitoreó ni controló adecuadamente las operaciones: por medio de una acción de ingeniería social (en este caso un malware previamente instalado en la computadora), ajena a la relación contractual entre las partes, un tercero obtuvo los datos del actor y actuando con apariencia del titular de la cuenta, pudo realizar 18 transferencias en menos de 30 minutos, de las cuales solo dos fueron notificadas a través del sistema "challenge", que envía una alerta al correo electrónico del cliente después de que la operación ya se realizó. Este sistema no es preventivo, sino reactivo, lo que lo hace insuficiente para evitar fraudes.

Además, autorizó transferencias a cuentas fraudulentas, algunas incluidas en una "lista negra" de cuentas sospechosas. Esto demuestra una falta de control y supervisión por parte de la entidad financiera.

La sentencia también afirma que el banco no implementó medidas de seguridad adicionales: a pesar de conocer los riesgos asociados a los ciberdelitos, no adoptó protocolos suficientes para proteger a sus clientes. El fallo menciona que el banco no verificó adecuadamente la identidad del usuario antes de autorizar las transferencias y el préstamo, lo que facilitó el fraude.

En cuanto a la responsabilidad, el juez dijo que el banco ofrecía un servicio electrónico que, por su naturaleza, está expuesto a riesgos como el fraude y el malware. Por lo tanto, tenía la obligación de implementar medidas de seguridad adecuadas para prevenir estos riesgos. Al no hacerlo, incurrió en responsabilidad objetiva.

El banco argumentó que la empresa había actuado con negligencia al no proteger su computadora con un antivirus y al facilitar sus datos a terceros. Sin embargo, el juez rechazó estos argumentos. “El banco no tiene la obligación de controlar las computadoras de los clientes, ni verificar si cuentan o no con antivirus; pero sí está obligado con el usuario de un servicio financiero de cuenta corriente bancaria a prevenir un daño en caso de vaciamiento de una cuenta. Y la prevención no se brindó”, consideró.

En su respuesta, el banco brindó los siguientes argumentos:

• No hay pruebas de que la víctima haya facilitado sus datos: no se demostró que la empresa hubiera compartido sus claves de acceso o que hubiera actuado con ligereza. El juez destacó que el banco no aportó pruebas concretas para sostener esta defensa.
• No puede trasladar su responsabilidad al cliente: aunque reconoce que la entidad advierte activamente a sus clientes sobre la importancia de proteger sus dispositivos, esto no la exime de su obligación de garantizar la seguridad de sus sistemas y no puede desentenderse de los riesgos asociados a su actividad y hacer recaer toda la responsabilidad en el cliente.

El perito informático designado en el caso determinó que el banco no cumplió con dos deberes clave:

• Deber de monitoreo: el banco no supervisó adecuadamente las operaciones realizadas desde la cuenta de la empresa, lo que permitió que se llevaran a cabo transferencias a cuentas no habituales y sospechosas.
• Deber de control: el banco no implementó mecanismos eficaces para detectar y prevenir operaciones fraudulentas, como la verificación de la identidad del usuario antes de autorizar transferencias o préstamos.

Un fallo ejemplificador y su impacto en la banca

El juez estableció una multa sin precedentes con el objetivo de incentivar a las entidades bancarias a reforzar sus políticas de ciberseguridad. "El banco ofrecía un servicio electrónico que, por su naturaleza, está expuesto a riesgos como el fraude y el malware. Por lo tanto, tenía la obligación de implementar medidas de seguridad adecuadas para prevenir estos riesgos", sostuvo De Oliveira.

Fuente: TN

Seguir leyendo...

Troyanos #Mekotio, #Grandoreiro y Red Mongoose acosan a bancos y usuarios de América Latina

Las instituciones financieras de América Latina están siendo "acosadas" por los troyanos bancarios llamados Mekotio (también conocido como Melcoz) y Grandoreiro. 

Según los hallazgos de Trend Micro, recientemente observó un aumento en los ataques cibernéticos que distribuyen el malware de Windows. Se sabe que Mekotio, que se utiliza activamente desde 2015, apunta a países latinoamericanos como Argentina, Brasil, Chile, México, España, Perú y Portugal con el objetivo de robar credenciales bancarias.

Documentado por ESET y Kaspersky, Mekotio es parte de una tetrada de troyanos bancarios dirigidos a la región Guildma, Javali y Grandoreiro, este último de los cuales fue "desmantelado" por las autoridades a principios de este año pero cuya red sigue en funcionamiento.

"Mekotio y Grandoreiro comparten características comunes a este tipo de malware, como estar escrito en Delphi, utilizar ventanas emergentes falsas, contener funcionalidad de puerta trasera y apuntar a países de habla hispana y portuguesa".

La operación de Mekotio sufrió un duro golpe en julio de 2021 cuando las fuerzas del orden españolas arrestaron a 16 personas pertenecientes a una red criminal en relación con la orquestación de campañas de ingeniería social dirigidas a usuarios europeos que entregaban Grandoreiro y Mekotio.

Las cadenas de ataques implican el uso de correos electrónicos de phishing con temas fiscales que tienen como objetivo engañar a los destinatarios para que abran archivos adjuntos maliciosos o hagan clic en enlaces falsos que conducen a la implementación de un archivo de instalación MSI, que, a su vez, utiliza un script AutoHotKey (AHK) para iniciar el malware.

Vale la pena señalar que el proceso de infección marca una ligera desviación del detallado anteriormente por Check Point en noviembre de 2021, que utilizó un archivo BAT ofuscado que ejecuta otros script de PowerShell para descargar un archivo ZIP de segunda etapa que contiene el script AHK. Una vez instalado, los troyanos recopilan información del sistema y establece contacto con un servidor de comando y control (C2) para recibir más instrucciones.

Su principal objetivo es desviar credenciales bancarias mostrando ventanas emergentes falsas que se hacen pasar por sitios bancarios legítimos. También puede realizar capturas de pantalla, registrar pulsaciones de teclas, robar datos del portapapeles y establecer persistencia en el host mediante tareas programadas.

Los actores de amenazas pueden utilizar la información robada para obtener acceso no autorizado a las cuentas bancarias de los usuarios y realizar transacciones fraudulentas.

Estos troyanos bancarios son amenazas persistentes y en evolución para los sistemas financieros, especialmente en los países latinoamericanos. Utilizan correos electrónicos de phishing para infiltrarse en los sistemas, con el objetivo de robar información confidencial y al mismo tiempo mantener un fuerte control en las máquinas comprometidas.

El desarrollo se produce cuando la firma mexicana de ciberseguridad Scitum reveló detalles de un nuevo troyano bancario latinoamericano con nombre en código Red Mongoose Daemon que, similar a Mekotio, utiliza cuentagotas MSI distribuidos a través de correos electrónicos de phishing disfrazados de facturas y notas fiscales.

"El objetivo principal de Red Mongoose Daemon es robar la información bancaria de las víctimas falsificando transacciones PIX a través de ventanas superpuestas", dijo la compañía. "Este troyano está dirigido a usuarios finales brasileños y empleados de organizaciones con información bancaria".

"Red Mongoose Daemon tiene capacidades para manipular y crear ventanas, ejecutar comandos, controlar la computadora de forma remota, manipular navegadores web, secuestrar portapapeles y hacerse pasar por billeteras Bitcoin reemplazando billeteras copiadas con las utilizadas por los ciberdelincuentes".

Fuente: THN

Seguir leyendo...

"Los fraude bancarios son cada vez más sofisticados" [Informe]

El 76% de los bancos hacen esta afirmación: "los casos de fraude y estafas son cada vez más como sofisticados".

Los datos provienen del último informe de Mitek Systems. Realizado en enero de 2024, el Identity Intelligence Index 2024 [PDF] encuestó a 1.500 profesionales de innovación y riesgo de servicios financieros en el Reino Unido, Estados Unidos y España.

Entre los hallazgos, los bancos se enfrentan a una amplia gama de amenazas de fraude, incluidas cuestiones tradicionales como el lavado de dinero y la apropiación de cuentas, así como desafíos emergentes como el fraude generado por IA y los deepfakes. Cabe destacar que el 32% de los profesionales de riesgos estima que hasta el 30% de las transacciones pueden ser fraudulentas.

El aumento del fraude de identidad generado por IA, como los deepfakes, es alarmante: en EE.UU. el 37% de las organizaciones experimentan fraudes de voz deepfake y el 29% son víctimas de vídeos deepfake, según una encuesta realizada por Regula, un desarrollador global de dispositivos forenses y verificación de identidad (IDV). La creciente accesibilidad de la tecnología de inteligencia artificial para crear deepfakes está haciendo que los riesgos aumenten, lo que plantea un desafío importante tanto para las empresas como para los individuos.

Además, la investigación destaca el grave riesgo asociado con la incorporación de nuevos clientes, ya que el 42% de los bancos identifican esta etapa como particularmente susceptible al fraude. A pesar de la implementación de regulaciones globales Conozca a su Cliente (KYC), casi 1 de cada 6 bancos tiene dificultades para verificar las identidades de los clientes de manera efectiva durante todo el recorrido del cliente.

Los encuestados también enfatizaron la necesidad de inteligencia regulatoria y tecnologías optimizadas para mejorar la protección del cliente. Mientras que el 41% de los profesionales de fintech cuentan con medidas de verificación de identidad, solo el 33% de los bancos maduros las hacen. Además, tecnologías como la detección de vida y la biometría se emplean cada vez más para prevenir actividades fraudulentas.

Chris Briggs, vicepresidente senior de identidad de Mitek Systems, subrayó la urgente necesidad de colaboración entre sectores para abordar el creciente panorama de amenazas. "Las instituciones financieras están bajo ataque. En el mundo bancario actual, sabemos que nuestros clientes están abrumados por un panorama de fraude cada vez más complejo, que va desde fraude generado por IA y deepfakes a nivel mundial hasta aumentos récord en el fraude con cheques en EE.UU.", advirtió el ejecutivo. "Necesitamos unir al gobierno, las empresas y la tecnología para mantener a las personas seguras en línea".

Los servicios financieros están haciendo lo suficiente para proteger a sus clientes?

La mayoría de los bancos (85%) confían en que brindan la seguridad adecuada a sus clientes. Sin embargo, cuando se analizan las diferentes edades de los bancos comparadas con sus niveles de confianza, la historia es diferente.

• Sorprendentemente, sólo el 78% de los encuestados de bancos de más de 50 años sienten que están haciendo lo suficiente hoy. Esta falta de confianza podría deberse a la complejidad de sus sistemas de TI de décadas de antigüedad y a la dificultad para incorporar nuevas tecnologías de verificación de identidad en los sistemas tradicionales evitando al mismo tiempo el tiempo de inactividad.
• Sin embargo, las empresas con menos de 50 años confían en su capacidad para proteger a los clientes; con un 91% seguro de sus capacidades. Los bancos o fintechs más jóvenes, quizás libres de la camisa de fuerza tecnológica de los sistemas bancarios heredados, tienen más fe en su ecosistema de banca digital.
• El 37% de los bancos más antiguos señalan que la capacidad de responder en tiempo real a las solicitudes de los clientes es el área principal que requiere mejoras.

Fuente: MitekSystems

Seguir leyendo...

Vacían cuentas de Payoneer y no dan explicaciones a los clientes

Usuarios argentinos de Payoneer reportaron el vaciamiento de sus cuentas desde este fin de semana. La plataforma es una popular app de pagos online que permite enviar y recibir dinero en varias monedas, razón por la cual es muy usada por quienes cobran por trabajos afuera y es popular entre trabajadores freelance.

El segundo factor de autenticación por SMS, el peor de todos por consenso unánime en la comunidad de ciberseguridad, fue el protagonista de esta semana: hubo un aluvión de vaciamiento de cuentas de Payoneer fue reportado por usuarios en Argentina.

El caso arrancó en un sub de Reddit del fin de semana, pero empezó a tomar grosor cerca del miércoles, cuando empezó a tener peso en Twitter (X) y otro posteo advertía, ya en español, sobre la situación.

El tipo de ataque que sufrieron está relacionado al segundo factor de autenticación vía mensajes de texto (SMS), esto es, el sistema que tienen las aplicaciones para verificar la identidad de los usuarios. Según reportaron, los damnificados empezaron a recibir SMS con códigos de verificación y notificaciones de pagos y, al querer entrar a sus cuentas, tenían las contraseñas cambiadas. Luego de recuperar el acceso, veían sus saldos en cero.

Las primeras versiones comenzaron a circular el fin de semana, cuando usuarios de la red social Reddit armaron un sub (posteo) en el que reportaban que sus fondos habían sido vaciados. Los comentarios comenzaron a aparecer y el mensaje original comenzó a circular a medida que iban apareciendo nuevos casos.

El segundo denominador común que reportaron los usuarios afectados es que tienen Movistar o Tuenti, ambas compañías de Telefónica, aunque hubo reportes de usuarios que tenían otras empresas.

Movistar emitió un comunicado en el que aseguran que la empresa "tomó conocimiento por publicaciones en redes sociales de que clientes de la compañía que poseen cuentas en la plataforma Payoneer habrían sido estafados a través de la recepción de SMS que, mediante maniobras de smishing, capturaron sus credenciales". SMiShing es, básicamente, phishing vía SMS.

"En este sentido, informamos que Movistar no es responsable de los mensajes (ni de su contenido) que terceros cursen utilizando su red. No obstante lo anterior, hemos tomado medidas preventivas con aquellos números desde los cuales algunos clientes han reportado haber recibido dichas comunicaciones", cerró la compañía, propiedad de Telefónica.

El segundo factor de autenticación (2FA) es un paso extra de seguridad que se usa en la validación de identidad online. En general, se trata de combinar algo que el usuario sabe (una contraseña, un pin, un patrón), con algo que tiene o es: un token, un teléfono celular para aprobar de manera exitosa el logueo, su pulgar o cara o, como sucedió en este caso, el envío de un SMS a una línea telefónica.

En el caso de las cuentas vaciadas, los usuarios recibieron diversos SMS llamativos: desde pagos recibidos desde la plataforma Airbnb hasta códigos de verificación que nunca especificaban si eran para restablecer una contraseña o para autorizar una nueva transacción, lo cual es confuso desde el diseño de la experiencia de usuario de la app. Los mensajes venían del número 80066.

Más allá de esto, el principal problema de Payoneer es que permite este tipo de segundo factor cuando, en el mundo de la ciberseguridad y de las empresas tech, es sabido que es el más débil que existe. El tipo de ciberataque más común es el SIM Swapping, donde un atacante intercambia la tarjeta SIM legítima del usuario por otra y, cuando la pone en otro teléfono, puede recibir un SMS para resetear una contraseña y así tomar control de la cuenta (account takeover).

Sin embargo, no fue esto lo que pasó en este caso. Todos los usuarios pudieron volver a entrar a sus cuentas tras resetear su clave. Y aseguran no haber entrado en ningún link extraño como para haber sido víctimas de phishing o SMiShing.

Y, además, hay un dato clave: para restablecer una contraseña, Payoneer no pide confirmación por mail, sino simplemente el código de verificación que envían por SMS, lo que la hace todavía más vulnerable al ahorrarle un paso al atacante. Lo que sí reportaron muchos usuarios fue recibir mensajes de SMiShing, a pesar de que aseguran que no cayeron en la trampa.

Payoneer, empresa con sede en Nueva York, no contestó preguntas puntuales al ser consultados por este medio, pero sí compartieron un comunicado: "Tenemos conocimiento de casos recientes en los que estafadores engañaron a los clientes a través de mensajes SMS para que hagan clic en enlaces a páginas de phishing y faciliten las credenciales de sus cuentas. Algunos clientes hicieron clic en estas páginas falsas y compartieron los datos de acceso a sus cuentas con los estafadores". La mayoría de los afectados insiste, de todos modos , en que no hizo clic en sitios fraudulentos.

"Nos tomamos el fraude muy en serio y colaboramos estrechamente con los organismos reguladores y las fuerzas de seguridad para combatir la delincuencia financiera", cerró Payoneer vía correo electrónico.

Las hipótesis del ataque

A pesar de que tanto en Reddit como en la comunidad de ciberseguridad local especularon sobre distintas causas, lo cierto es que la reconstrucción exacta del ataque todavía no se conoce (lo que se conoce en el ambiente como hacer ingeniería inversa).

En la red social circula la información de una base de datos de Movistar filtrada y especulaban con que esa pudiera ser la causa del leak, aunque algunos investigadores cruzaron información entre esa base de datos y el incidente y no encontraron evidencia.

Lo que sí se pudo confirmar es que había una campaña activa de SMiShing que apuntaba a Payoneer alojada en el mencionado dominio "alertaspayoneer.com" que ya está dado de baja. Incluso en el código fuente de ese sitio podía verse que apuntaba hacia un "peticiones.php", en español. Y, a su vez, los dominios que listaba la campaña estaban relacionados a entidades bancarias argentinas.

"La plata fue transferida a otra cuenta payoneer, creo que fue el mismo caso para todos, esta era gwqa42 @ 163.com", explicó un usuario en Discord, donde los afectados abrieron un servidor específico para ordenar la discusión.

De acuerdo a Julio Lopez (aka julitolopez), el procedimiento fue el siguiente:

• El atacante comprometió el SMS gateway usado para enviar el 2FA a los clientes de Movistar (plataformas que se utilizan para ahorrar costos)
• El atacante veía pasar los mensajes de 2FA desde Payoneer hacia un numero de teléfono de Movistar pero tenía el problema de no saber el mail del usuario de Payoneer para cambiarle la contraseña y hacer las transacciones.
• El atacante para descubrir que mail había detrás de cada teléfono creo un sitio de Phishing/SMShing para tratar de conocer solo el correo. Luego, con este email mail, el número de teléfono y el 2FA (obtenido del SMS del gateway) podía acceder en tiempo real a la cuenta y cambiar la contraseña del usuario.
• Es por eso que las víctimas vieron varios SMS reales con 2FA venir durante la noche que les vaciaron la cuenta.
• Si los clientes de Payoneer sólo hubiesen caído en el phishing, solo le hubieran robado el 2FA, y no a todos los datos que necesitan para entrar, agregar una cuenta y transferir fondos.
• Esta necesidad hace evidente el compromiso del gateway SMS.

Qué hacer si se tiene plata en Payoneer

Al día viernes de esta semana, lo concreto es que la cadena exacta del ataque no está explicada de manera clara ni por Payoneer, ni Movistar ni los usuarios: son todas hipótesis, pero porque hay varios elementos en juego y un rompecabezas que espera ser armado.

Pudo haber sido una base de datos filtrada, a partir de la cual el o los atacantes aprovecharon el 2FA por SMS, un phishing dirigido -aunque los usuarios niegan haber caído en la trampa-, o que, simplemente, debido a que Payoneer no solicita contraseña para cambiar clave, el atacante haya conseguido código de verificación para poder entrar y ejecutar las transacciones. Esto se sabrá luego de la investigación, debido a que armar el rompecabezas de todos los elementos que hacen a un ataque es algo que puede llevar tiempo.

La recomendación general es retirar o bloquear (vía email) el dinero de Payoneer, por lo menos hasta que se conozcan más detalles de qué sucedió y a cuántos pueda afectar. Si se decide dejar el dinero, intentar desactivar el segundo factor por SMS (muchos reportaron no tener la opción) y, además, cambiar el mail asociado a la cuenta o la línea telefónica. En caso de detectar movimientos extraños, elevar un reclamo a través del soporte técnico de la aplicación.

A nivel global, entidades como el Instituto Nacional de Estándares y Tecnología (NIST) recomiendan no usar SMS como segundo factor de autenticación. A nivel local, en el mundo bancario, este tipo de métodos se usa cada vez menos porque es sabido que son inseguros.

Actualización 23/01: Payoneer acaba de publicar un comunicado con lo que ellos entienden que es la verdad de lo sucedido. Por supuesto responsabilizan a los clientes y según ellos no son responsables del uso de un método inseguro de SMS como 2FA.

Fuente: Juan Brodersen | Clarin

Seguir leyendo...

Sigue el crecimiento del troyano bancario Grandoreiro o #Mekotio

El malware bancario brasileño conocido como "Grandoreiro" o "Mekotio" ha cruzado el charco, con una nueva campaña de TA2725 dirigida a clientes de España, además de Brasil, Argentina y México.

La actividad de la Dark Web en América Latina ha aumentado en los últimos dos años y se concentra en gran medida en dos países. Según el reporte de SOCRadar "Brazil Threat Landscape", 360 mil millones de intentos de ciberataques azotaron la región en 2022, de los cuales 187 mil millones y 103 mil millones afectaron a México y Brasil, respectivamente.

Ahora hay cada vez más evidencia de que el cibercrimen en América Latina se está extendiendo hacia afuera. En lo que va de 2023 se detectaron más de 70 variantes de este troyano bancario. En América Latina, las detecciones de los sistemas de ESET muestran que Argentina (52%) es el país con más actividad de este Mekotio, seguido por México (17%), Perú (12%), Chile (10%) y Brasil (3%).

La empresa Proofpoint ha rastreado a TA2725 desde marzo de 2022. Se sabe que oculta malware para robar cuentas bancarias y tarjetas de crédito dentro de correos electrónicos de phishing, dirigidos principalmente a organizaciones en su país de origen, Argentina o México. Y según una nueva publicación de blog de Jared Peck, investigador senior de amenazas en Proofpoint, el grupo actualizó recientemente su malware característico para incluir instituciones en ambos lados del Atlántico.

Los ataques Grandoreiro/Mekotio comienzan con una URL maliciosa en un correo electrónico de phishing. Los señuelos pueden presentarse en forma de un documento compartido falso, una factura de servicios públicos, un formulario de impuestos, etc.

La URL conduce a un archivo ZIP que contiene un instalador que, cuando se ejecuta, descarga una aplicación y/o una DLL donde viene la carga útil final (el troyano).

Grandoreiro puede recopilar datos a través de un registrador de teclas, un capturador de pantalla o una superposición (overlay) de la página de inicio del home-banking. Estas superposiciones imitan a los bancos populares brasileños, argentinos y mexicanos y, en dos campañas observadas a finales de agosto, a los bancos ubicados en España. Los señuelos de phishing de TA2725 también se diversificaron para imitar a las organizaciones con sede en España.

Esta no es la primera vez que los troyanos brasileños cruzan el Atlántico. A principios de este año, por ejemplo, los actores de amenazas hicieron hicieron algo similar, atacando a los clientes de los bancos portugueses en una campaña llamada "Operación Magalenha". Esta última actividad sólo promueve una tendencia emergente: que el malware brasileño ya no está contenido en un solo continente.

Donde antes parecían dominio exclusivo del hemisferio norte, los troyanos bancarios han prosperado en Brasil en los últimos años. Según Peck, hay varias razones para ello.

"Es posible que la población general en muchas partes del mundo, como Brasil y otras partes de América del Sur y América Latina, no haya tenido el mismo acceso a educación en ciberseguridad y tecnología de protección que otras partes del mundo, pero continúa aumentando su acceso en línea. Esta situación conduce a una falta de concienciación de los usuarios sobre las amenazas de phishing y malware, lo que, a su vez, conduce a un mayor número de víctimas que hacen clic y se ven afectadas", explica, añadiendo que "esta población general tiene una movilidad ascendente, lo que lleva a una clase media más grande, por lo que hay más oportunidades de victimizar a un grupo más grande de población".

Según Proofpoint, las familias de malware más comunes, incluidas Grandoreiro, pero también Casabeniero, Javali y Mekotio, poseen un linaje compartido: un ancestro basado en Delphi a partir del cual los componentes del código fuente se han transmitido y modificado de generación en generación.

Las organizaciones de los países afectados pueden buscar programas sospechosos con estos mismos elementos. O, como subraya Peck, pueden centrarse en el lado humano de tales compromisos.

Fuente: Dark Reading

Seguir leyendo...

Zanubis: troyano bancario para Android ataca aplicaciones en América Latina

Los investigadores de Kaspersky alertan sobre Zanubis, un troyano bancario para Android que ha atacado a cerca de 40 aplicaciones de bancos y otras entidades financieras en Perú, por su alto potencial de convertirse en una amenaza para el resto de América Latina.

Los investigadores han informado reiteradamente sobre cómo los troyanos de acceso remoto (RATs) realizan ataques tipo "mano fantasma" que permiten a los ciberdelincuentes realizar fraudes bancarios utilizando el smartphone de la víctima para burlar las defensas en la banca móvil.

Este modelo de cibercrimen está dominado por los troyanos brasileños, de la mano de #MEKOTIO hasta la aparición de Zanubis en agosto de 2022. Con varios indicadores que sugieren que es de origen peruano, este malware ya lidera el ranking de intentos de ataque y representa casi el 50% de los bloqueos realizados por Kaspersky en ese país en lo que va del año.

Esta nueva amenaza financiera llamó la atención de los expertos de la compañía por su complejidad. El nivel técnico de Zanubis está a la par de los troyanos brasileños y emplea la misma táctica, centrándose en las apps de bancos e instituciones financieras con el fin de robar las credenciales de acceso y secuestrar los mensajes SMS enviados a la víctima por las instituciones bancarias.

Este es un troyano bancario basado en superposición que abusa de la accesibilidad, el método de infección es el estándar y almacena una lista de aplicaciones en shared_preferences. Está enfocado en bancos de Latinoamerica, esta muestra se enfoca especialmente, en bancos de Perú.

El principal modo de infección de Zanubis ocurre cuando el usuario baja una aplicación maliciosa, la cual simula ser de una marca, empresa u organización legítima, fuera de la tienda oficial. El malware revisa si es la primera vez que se ejecuta en el dispositivo y si cuenta con permisos para ingresar al Menú de Accesibilidad del teléfono. De lo contrario, es capaz de mostrar mensajes con alertas de "es necesario actualizar la app" para lograrlo.

Se sabe que el troyano se hace pasar por una aplicación del sistema de la Superintendencia Nacional de Aduanas y Administración Tributaria (Sunat), para que los usuarios no puedan identificarlo y terminen descargándolo en sus teléfonos. "Lo más probable es que el cibercriminal envía este troyano a través de correos electrónicos señalando un problema con los impuestos e invita a la víctima a hacer clic para descargar la app de Sunat. Es posible que utilice otros temas para generar en los usuarios cierto temor y esto conlleva a la descarga. Una vez que ya está instalado en el teléfono, este te mostrará la página real de la entidad, pero por debajo ya se instaló Zanubis", explican desde la empresa.

Es importante señalar que esta función está presente en todos los dispositivos Android, pues su objetivo es ayudar a personas con alguna discapacidad a configurar el teléfono con tecnologías de asistencia. Sin embargo, los ciberdelincuentes explotan esta herramienta legítima para manipular las aplicaciones en el equipo infectado con comandos remotos. Sin este acceso, Zanubis no podría llevar a cabo el fraude en las apps bancarias.

El malware también solicita ser la aplicación predeterminada para la validación de mensajes SMS. Esta configuración le permite robar los códigos de activación o verificación que las instituciones financieras envían a la víctima vía mensajes de texto. Es importante mencionar que cuando la amenaza intercepta uno de estos mensajes, el malware lo elimina para borrar evidencia del fraude.

Una vez en operación (con ejecución en segundo plano y permiso para operar otras apps), Zanubis muestra la página web legítima de la institución bancaria que utiliza el usuario para realizar pagos. Esta fase es importante ya que sirve para evitar que la persona sospeche que ha sido víctima de un ataque.

La estafa empieza cuando el troyano identifica que la víctima utiliza aplicaciones específicas. La lista está compuesta por casi 40 apps de instituciones financieras, así como las de Gmail y WhatsApp, estas últimas para robar o monitorear la información de sus víctimas. En esta etapa, Zanubis registra todos los textos digitados en el equipo y graba la pantalla con el fin de robar las credenciales de ingreso a las apps.

Según los expertos, el robo de dinero a través de las apps financieras o de la banca móvil se realiza cuando la víctima del dispositivo infectado no lo está utilizando, o no pueda hacerlo, ya que Zanubis puede bloquear el uso del teléfono mediante actualizaciones falsas de Android.

La excepción es cuando el dueño del dispositivo infectado haya configurado la verificación biométrica para ingresar a sus cuentas. En este caso, el fraude se produce durante el segundo acceso a la aplicación bancaria para que el programa malicioso pueda forzar la verificación facial o mediante la huella digital. En ambos casos, el malware podría oscurecer la pantalla del teléfono infectado para imitar el bloqueo del teléfono y engañar a la víctima para que use el desbloqueo biométrico.

Aunque no se puede hacer una atribución definitiva con la información actualmente disponible, existen varios indicadores que sugieren que Zanubis es de origen peruano y que podría expandirse por la región. En primer lugar, el idioma utilizado por los desarrolladores es el español con un gran conocimiento de la jerga y frases comunes. Además, muestra gran afinidad por los bancos y entidades financieras peruanas, siendo estas apps su único objetivo por el momento.

Otra señal inesperada es que mientras los expertos de Kaspersky y Fernando Diaz realizaban el análisis de este malware, notaron varios envíos a la plataforma del VirusTotal. Según la telemetría y los IoCs, todas esas nuevas muestras enviadas aparecían provenir de un remitente en Perú.

Fuente: Kaspersky | EntDark

Seguir leyendo...

Introducción a la norma BCRA A7724 de Riesgos de Tecnologías y Seguridad de la Información

Por Marcela Pallero (@Marce_I_P) Ex-analista en la Gerencia Principal de Normas de Seguridad de la Información para Entidades.

Directora de Seguridad en TIC en la Fundación Sadosky

La Comunicación BCRA A 7724 [PDF], publicada el 10 de marzo de 2023 por el Banco Central de la República Argentina, derogó el texto ordenado anterior, que constituía un compendio de normas en la materia conformando un documento con todas las actualizaciones. Entre dichas normas, se encontraba la Comunicación A 4609 [PDF] de 2006. Muchas veces se referenciaba al texto ordenado completo con esta norma, lo que resultaba ciertamente confuso. La comunicación define su entrada en vigencia a los 180 días desde su difusión.

El texto ordenado que se derogó [PDF] tenía un abordaje obsoleto en cuanto al tratamiento de la tecnología en una entidad financiera. Además, ciertos temas relevantes, hoy en día, como la gestión de los datos, los ciberincidentes y la gestión del ciclo de vida del desarrollo, entre otras, no se abordaban o tenían un alcance muy limitado.

Para cambiar esta situación, la nueva comunicación aprueba los "Requisitos mínimos para la gestión y control de los Riesgos de tecnología y seguridad de la información" y fue elaborada bajo el área de regulación del BCRA, en conjunto con la de Supervisión.

Contiene 10 secciones, la sección 11 es sobre canales electrónicos y la 12 es un glosario. Aborda nuevos aspectos y temas que requerían necesariamente de una actualización para reflejar el estado de arte actual en las entidades bancarias y financieras.

Si bien cada sección se aboca a un tema en particular, podría decirse que hay múltiples referencias cruzadas entre los temas porque así es como funciona en la práctica. La norma toma algunas referencias en el marco de gobierno y gestión de las tecnologías y la información conocido como COBIT 2019, elaborado por ISACA; referencias de las publicaciones del NIST y; también otros estándares actualizados, como la ISO 27001 de 2022.

Para resaltar los grandes cambios que trae esta nueva norma, podemos abordarlos desde varios enfoques. Por ejemplo, tomando los avances tecnológicos, el texto actual sigue el principio de neutralidad tecnológica para evitar que pueda volverse obsoleta en muy poco tiempo al atarse a una tecnología en particular, lo que ocurría con el texto anterior que tenía referencias a "Cintas o CD para hacer respaldos".

Cuando se establecen requisitos para el intercambio de datos entre entidades, la norma refiere a controles con objetivos a cumplir como principio general, más allá de cualquier tecnología o canal y de otros requerimientos que luego se establecen en otras secciones. Estas secciones son abordadas desde el enfoque de procesos como los de infraestructura tecnológica y procesamiento o desarrollo, adquisición y mantenimiento de software.

El texto actual sigue los estándares y adelantos en materia de buenas prácticas sobre varios temas que si bien se vinculan entre sí, representan áreas de trabajo diferentes y niveles de relevancia diferentes para las entidades y para el regulador.

De un conjunto de actividades sobre un tema como se realizaba en el texto ordenado anterior, la nueva norma requiere marcos de gestión, término que en este contexto refiere a un conjunto coordinado de procesos de planificación, implementación, operación, monitoreo y la mejora continua, a partir de la información de gestión.

Se requieren a las entidades la adopción de marcos de gestión para los siguientes temas:

1. Riesgos de tecnologías y seguridad de la información (Sección 3)
2. Tecnología, y gestión de proyectos (Sección 4)
3. Seguridad de la información (Sección 5)
4. Continuidad del Negocio (Sección 6)
5. Ciberincidentes (Sección 8)
6. Adquisición, desarrollo y mantenimiento de software (Sección 9)
7. Relación con terceras partes (Sección 10)

Se incorpora y en algún sentido se formaliza, el modelo de 3 líneas, antes llamado 3 líneas de defensa, que se refiere a los diferentes niveles de responsabilidad en la gestión de riesgos y controles en una organización.

• La primera línea la forman empleados y los gerentes de la organización, que son responsables directos de la gestión de los riesgos operativos y la implementación de los controles internos.
• La segunda línea se refiere a las funciones de gestión de riesgos y control interno, que se encargan de monitorear y supervisar los controles internos implementados por la primera línea de defensa. Estas funciones pueden incluir la gestión de riesgos, la conformidad, la seguridad, el cumplimiento y la calidad.
• La tercera línea se refiere a la función de auditoría interna, que evalúa la eficacia de los controles internos y la gestión de riesgos en toda la organización. La auditoría interna también brinda asesoramiento y recomendaciones para mejorar la eficacia de los controles internos y la gestión de riesgos en la organización.

Este modelo de 3 líneas ayuda a asegurarse de que hay una estructura clara de responsabilidad y rendición de cuentas para la gestión de riesgos y control interno en toda la organización, además de identificar y abordar los riesgos de manera más efectiva. De ahí, su importancia y la relevancia de la auditoría para evaluar la efectividad de los controles. (Ver punto 1.2. de la Comunicación A 7724).

Se definen desde procesos del gobierno o gobernanza en tres temas fundamentales (ver puntos 2.1.2 y 2.1.3), que son el de tecnologías de la información, el de seguridad de la información y el de gestión de riesgos, a los procesos de gestión, llegando inclusive al nivel operativo, con la identificación de responsabilidades y el establecimiento de objetivos para los distintos niveles. Por otro lado, no define estructuras organizacionales, sino que identifica procesos de gestión y especifica principios para la relación entre los procesos y algunas funciones.

Asimismo, considera nuevas prácticas y temas para los que se establecen requisitos, como la inteligencia artificial o modelos de machine learning, la gestión de datos, la gestión de proyectos y nuevas modalidades de desarrollo de sistemas, entre otros.

La nueva normativa tiene un enfoque de gobernanza de tecnologías y seguridad de la información, asignando responsabilidades e incluyendo la gestión de ciberincidentes. Asimismo, la norma tiene un enfoque en riesgos, para todas las entidades, si bien existen algunos controles que se implementan cuando hay mayores riesgos. Además, se vinculan los riesgos de tecnología y seguridad de la información con los riesgos operacionales y con los reportes, de acuerdo a lineamientos internacionales, señalándose especialmente algunos riesgos como los relacionados con la protección de datos personales. (Ver Sección 3).

La Sección 4, de Gestión de Tecnología de la Información, trata el tema de la gestión del dato, su clasificación, así como la arquitectura empresarial y la gestión de activos de información. Contiene además un apartado de requisitos para la Inteligencia Artificial (ver punto 4.6) para luego abordar la gestión de Seguridad de la Información en la sección siguiente.

Esta sección 5, de Gestión de Seguridad de la Información, contiene normas y procedimientos para temas específicos y se relacionan con el resto de las secciones, con controles para realizar seguimiento de amenazas del entorno y gestión de vulnerabilidades, entre otros. También establece requisitos sobre programas de capacitación y concientización para distintos segmentos de públicos tanto internos como clientes y en riesgos específicos. (Ver Punto 5.5).

Alineado con la Comunicación A 7266 sobre respuesta y recuperación ante ciberincidentes, publicada en abril de 2021, la Sección 8 trata de la gestión y su integración con otras secciones para la preservación de las entidades para la continuidad del negocio, así como el cuidado de la información referida a las quejas de clientes. (Ver punto 8.1.1).

En otro de sus apartados, aborda la seguridad física y medioambiental (Ver punto 5.7) y es también la sección que aborda las medidas de control de acceso y métodos de autenticación, con requisitos para los factores de autenticación, con definiciones y requisitos para el uso de datos biométricos por su carácter probabilístico (Ver punto 5.7.2.3) y para la autenticación multifactor. También establece controles para las operaciones de seguridad, que abarca la detección, el monitoreo y el análisis de eventos, que luego se vinculan con la sección de ciberincidentes.

En la sección 6, referida a la Gestión de la Continuidad del negocio, se abordan los procesos necesarios para atender eventos de disrupción basado en riesgos, y el análisis de impacto, promoviendo la capacitación y los ejercicios como elemento importante para probar los planes de continuidad y su actualización.

La sección 9 aborda el desarrollo, adquisición y mantenimiento de software. Incluye además aspectos puntuales para los aplicativos que registran información de interés para el BCRA, la vinculación con la gestión de proyectos, y las especificaciones para que el ciclo de vida del desarrollo conforme las prácticas actuales de seguridad, como el modelado de amenazas, las pruebas y la gestión de vulnerabilidades, por mencionar puntos relevantes.

En la relación con las terceras partes, Sección 10, se aborda los controles para asegurar la resiliencia, la seguridad y la continuidad del negocio. En cuanto a la seguridad, se tuvieron en cuenta las amenazas de la cadena de suministros, por lo que se incluyeron requisitos para la gestión de ciberincidentes. Esta sección refiere, en gran medida, a controles que deben ser incorporados en la formalización (contratos) de los servicios brindados por terceros, con algunas exclusiones puntuales.

Finamente, la sección 11, de canales electrónicos, es la antigua sección 6 del texto derogado, y la Sección 12 es un glosario que permite interpretar algunos conceptos. Es probable que en algún futuro esa sección sea actualizada. ¡Habrá que estar pendiente!

Por Marcela Pallero (@Marce_I_P) Ex-analista en la Gerencia Principal de Normas de Seguridad de la Información para Entidades.

Directora de Seguridad en TIC en la Fundación Sadosky

Seguir leyendo...

Nueva BCRA Comunicación "A" 7724: Requisitos mínimos de seguridad de la información

En vista de los crecientes fraudes a clientes, el Banco Central de Argentina dictó una nueva Comunicación "A" 7724 [PDF] sobre ciberseguridad para los bancos, denominada "Requisitos mínimos para la gestión y control de los riesgos de tecnología y seguridad de la información".

La nueva comunicación "A" 7724 impulsa una actualización de las exigencias vinculadas con la gestión de los riesgos de la tecnología y seguridad de la información, la continuidad del negocio, la tecnología, la infraestructura informática y la gestión de ciberincidentes y tendrá vigencia a partir del 10 de septiembre próximo (180 días).

De acuerdo a Marcela Pallero (aka Marce_I_P), la comparación entre la "vieja" Comunicación "A" 4609 y la reciente 7724 es la siguiente:

Y, según Agustín Allende, socio de Crearis Latam, los recaudos más relevantes que impone esta Comunicación pueden resumirse como sigue.

Gobierno de tecnología y seguridad de la información

El gobierno de la tecnología y seguridad de la información a ser establecido por las entidades deberá ser hecho a medida conforme sus operaciones, procesos y estructura. Pero deben asegurar supervisión adecuada de las actividades de tecnología de la información y gestión de los riesgos relacionados con la tecnología y seguridad de la información.

Si bien establece obligaciones al directorio y a la alta gerencia, la norma omite considerar entre sus objetivos la protección de los datos personales.

Gestión de riesgos de tecnología y seguridad de la información

Los riesgos relacionados con la tecnología y seguridad de la información a ser incluidos en la evaluación son, especialmente, los que siguen:

• Escenarios que afecten la resiliencia tecnológica.
• Obsolescencia de la tecnología y los sistemas.
• Gestión de la relación con terceras partes.Desarrollo y utilización de algoritmos de inteligencia artificial o aprendizaje automático.
• Adopción de tecnología nueva o emergente.
• Software o aplicaciones utilizadas por usuarios que no fueron formalmente autorizados.
• Aspectos de protección de datos personales en el uso de tecnologías asociadas a blockchain.
• Escenarios de ciberincidentes relacionados con datos personales.

Inteligencia artificial, bancos y derechos del usuario

La comunicación incorpora el análisis de la inteligencia artificial (IA) y machine learning (ML) debiendo identificar y documentar el objetivo del uso, por sí o por terceros, de software que utilice algoritmos de IA o ML en sus proyectos o procesos.

Exige establecer roles y responsabilidades para la definición del contexto en que operan los sistemas de IA, la identificación de los modelos, algoritmos y los conjuntos de datos utilizados, y la definición de métricas y umbrales precisos para evaluar la confiabilidad de las soluciones implementadas.

Estos análisis de riesgos deberán considerar, como mínimo lo siguiente:

• Los modelos adoptados, su entrenamiento y las posibles discrepancias con la realidad del contexto.
• Los datos utilizados para el entrenamiento, su volumen, complejidad y obsolescencia.
• La privacidad y la afectación a los usuarios en su calidad de consumidores.
• El nivel de madurez de los estándares de pruebas de software y las dificultades para documentar las prácticas basadas en IA.

Adicionalmente, se deberán implementar procesos que promuevan la confiabilidad en el uso de este tipo de algoritmos e incluyan al menos:

• Medidas para evitar la existencia de sesgos o discriminación contra grupos o segmentos de clientes o usuarios de los productos y/o servicios financieros.
• Documentación respecto de la transparencia, la explicabilidad de los modelos utilizados y la interpretabilidad de los resultados.
• La ejecución de revisiones periódicas de los resultados respecto de la tolerancia al riesgo definida.
• La comunicación al cliente cuando utilice servicios soportados por este tipo de tecnología.

Gestión de seguridad de la información

El BCRA establece los requisitos generales para los factores de autenticación mediante el uso de datos biométricos: En la implementación de métodos de autenticación que utilicen datos biométricos, se deberán evaluar y mitigar los riesgos derivados de las siguientes características:

• Las limitaciones para asegurar la autenticación del suscriptor debido al carácter probabilístico del método, la tasa de falsos positivos (FMR) y la falta de secreto del dato biométrico.
• La necesidad de establecer un proceso para la revocación de credenciales de este tipo.
• Las posibles vulnerabilidades en los dispositivos y sistemas utilizados para la captura y validación de las credenciales.
• El impacto en la privacidad de los usuarios.

Gestión de ciberincidentes

La nueva norma define a un ciberincidente como aquel evento cibernético que:

• Pone en peligro la ciberseguridad de un sistema de información o la información que el sistema procesa, almacena o transmite.
• Infringe las políticas de seguridad, los procedimientos de seguridad o las políticas de uso aceptable, sea o no producto de una actividad maliciosa.

Las políticas para la gestión de ciberincidentes deben definir, al menos, lo siguiente:

• El alcance y las áreas participantes de la respuesta ante ciberincidentes para la entidad, indicando los roles y responsabilidades de cada área.
• Los objetivos y prioridades de la respuesta alineados a la gestión del riesgo y la continuidad del negocio.
• Los principios para priorizar y escalar ciberincidentes.
• Las métricas para realizar los controles para una gestión efectiva.

Fuente: Iprofesional

Seguir leyendo...

Inédito fallo a favor de un jubilado víctima de #phishing: el banco deberá indemnizarlo con $600 mil

Un jubilado de 68 años oriundo de Berisso y víctima de una estafa virtual logró un fallo sin precedentes en el que la justicia de La Plata condenó al Banco Provincia de Buenos Aires al pago de una multa de $600 mil, a la devolución del monto de adelanto de haberes de $22.500 tomado por los estafadores y declaró la nulidad del crédito de $650 mil que éstos habían sacado.

Cristian Borghello y Marcelo Temperini explican este tipo de accionar y conductas delictivas en un paper publicado en 2012.

La sentencia, que fue dictada por la jueza María Cecilia Tanco, titular del Juzgado Civil y Comercial Nro. 19 de La Plata, no solo es considerada la primera en materia de phishing que se realiza en el Departamento Judicial La Plata sino también a nivel nacional.

En ese caso, el jubilado fue llevado a entregar mediante engaños sus claves y otros datos sustanciales que les permiten a los estafadores apropiarse de los fondos de su cuenta bancaria con la excusa de que había ganado $50 mil en un sorteo y dos celulares 4G. Ocurrió el 21 de septiembre de 2020.

Los delincuentes le dijeron que la suma sería depositada en su cuenta por lo cual debía concurrir a un cajero, lugar en el cual ellos le dieron un PIN y obtuvo un número de Token que supuestamente les serviría a ellos para entregarle el dinero.

Cuatro días después los estafadores le manifiestan que no habían podido hacer la totalidad del depósito y que necesitaban otra tarjeta bancaria, la cual podía ser de un allegado. Tras cumplir con este requerimiento, el jubilado concurre al cajero y advierte que su tarjeta estaba bloqueada.

Frente a esta situación el hombre concurre a la sucursal de Berisso del Banco Provincia en los movimientos de su cuenta no figuraba el depósito prometido. Por el contrario, figuraba la acreditación de $650 mil en concepto de un crédito que había tomado y la transferencia de esa plata a varias cuentas desconocidas.

El fallo emitido por la jueza Tanco sacó a la luz la responsabilidad bancaria en este hecho delictivo ya que el Banco Provincia no advirtió que su cliente había sido víctima de una maniobra fraudulenta y empezó a cobrarle el crédito.

Según el perito informático que intervino en el caso, el banco no cumplió con las medidas de seguridad exigidas por el Banco Central ya que no logró detectar que las operaciones y transacciones realizadas desde la cuenta del jubilado se hacían desde un IP que correspondían a la provincia de Córdoba, jurisdicción ajena a la demandada.

Además, los montos involucrados en dichas operaciones tampoco recibieron el tratamiento que correspondía por su carácter de sospechosas o potencialmente fraudulentas. Otro punto a favor del denunciante fue que el banco debería haber verificado fehacientemente la identidad de la persona que solicitó la acreditación del crédito preaprobado a través del canal electrónico y no lo hizo.

La justicia entendió que la falta de medidas hábiles para sumar sistemas de alerta por la existencia de movimientos inusuales por fuera de los patrones habituales del consumidor permitieron que se concretara el delito. Aclaró que la facilitación de las claves por parte de la víctima fue la condición del hecho pero no la causa. "La causa es la falta de seguridad en el sistema que el banco demandado puso a disposición del accionante", precisó la jueza en el fallo al que accedió este medio.

Por otra parte la magistrada prestó especial atención en que el actor es un cliente "hipervulnerable" y el cual "había sido víctima de maltrato por parte de la entidad al que ni siquiera habían respondido su reclamo en término".

Es decir, "el banco fue el responsable porque firmó un contrato con un estafador y le aprobó un crédito", concluyó el abogado, quien tiene en curso otras 50 demandas de phishing contra el Banco Provincia.

Fuente: Infobae

Seguir leyendo...

El Banco de España aprueba la guía de implementación de TIBER-ES basada en TIBER-EU

El pasado 27 de diciembre de 2021, el Banco de España aprobó la "Guía de Implementación TIBER-ES – Threat Intelligence Based Ethical Red-Teaming – España", publicada este mes de enero de 2022.

En respuesta al incremento de ataques cibernéticos a nivel mundial en los últimos años, cada vez son más las entidades que optan por someter sus infraestructuras a pruebas como auditorías web y ejercicios de pentesting. En base a esto, las instituciones gubernamentales han ido optando, poco a poco, por desarrollar marcos de trabajo a los que, tanto la parte contratante como quien realiza el servicio, puedan acogerse y definir al máximo posible el alcance de las pruebas a realizar.

Siguiendo esta línea, el Banco Central Europeo (ECB, por sus siglas en inglés) publicó en mayo de 2018 el documento «TIBER-EU Framework – How to implement the European framework for Threat Intelligence-based Ethical Red Teaming» y, posteriormente, en agosto de ese mismo año, una guía para los proveedores de servicio llamada «TIBER-EU Framework – Services Procurement Guidelines«. En el caso del primer documento, el ECB lo define como un marco de trabajo común que «proporciona una serie de pruebas controladas, personalizadas y guiadas por un marco de inteligencia contra sistemas críticos en producción de las entidades», tratándose de una serie de pautas aplicables a un contexto jurisdiccional variado. En cuanto a la guía para proveedores de servicios, ésta pretende servir de apoyo a las entidades del sector financiero (entre otros) para proporcionar servicios de inteligencia de amenazas y ejercicios de Red Team.

En las siguientes secciones del artículo, explicaremos quiénes participan en un ejercicio basado en TIBER-ES y cuáles son sus roles, así como las distintas fases y tareas en las que se dividen las pruebas.

¿Quiénes son los participantes y cuáles son sus funciones?

1. TIBER Cyber Team (TCT).

• Revisar periódicamente el marco TIBER-ES y aplicar las medidas de implementación y test realizados, además de proponer actualizaciones.
• Participar en el TIBER Knowledge Centre (TKC) del ECB y proponer actualizaciones del marco TIBER-ES. En este foro común colaboran todas las jurisdicciones que han adoptado TIBER.
• Invalidar las pruebas si no se realizan de acuerdo a TIBER-ES y TIBER-EU.

El TCT no desempeña un papel supervisor, no es responsable de las acciones de la entidad que se somete al test ni de sus proveedores, ni tampoco de los riesgos de las pruebas. Por cada test, el TCT nombrará un Team Test Manager (TTM), quien debe:

• Realizar un seguimiento de la prueba.
• Representar al TCT y coordinar sus acciones de apoyo a las pruebas, actuando como punto de contacto.

2. Entidad que se somete al test.

• White Team: para cada test, la entidad que se somete a él ha de establecer un White Team (WT), que será el responsable último de la definición del alcance y de la ejecución efectiva del test. Asimismo, si existen razones que lo justifiquen, el WT podrá poner fin a las pruebas. El número de miembros será reducido y no deberán informar al resto de áreas de la empresa sobre los ejercicios a realizar. Se nombrará un White Team Lead (WTL), y los requisitos sobre su composición, actividades y responsabilidades son recogidos en la guía TIBER-EU White Team Guidance del ECB.

• Blue Team: el Blue Team (BT) estará formado por todos los demás miembros de la entidad objeto de la prueba y no deberá ser informado sobre la misma hasta la fase de cierre.

• Proveedores: la entidad y los proveedores que participan deben acordar, antes del ejercicio, aspectos como las condiciones económicas y el alcance de las pruebas, entre otros puntos. Los proveedores deben ser independientes respecto de la entidad sometida al test para garantizar la objetividad de los resultados. Por último, un mismo proveedor podrá prestar simultáneamente las funciones de TI y de Red Team (RT). Los requisitos se encuentran establecidos en la guía TIBER-EU Services Procurement Guidelines del ECB.

• Threat Intelligence: el proveedor de Threat Intelligence (TI) recopilará información, replicando la investigación que realizaría un ciberatacante y proporcionará a la entidad que se someterá al test un informe sobre las amenazas específicas.

• Red Team: su objetivo será comprometer las capacidades de seguridad de la entidad haciendo uso de técnicas, tácticas y procedimientos (TTP) y métodos de hacking ético. Sus ataques se basarán en la información del proveedor de TI y en los escenarios diseñados. Al igual que en el caso anterior, al finalizar las pruebas se realizará un informe sobre la ejecución de los escenarios y las debilidades detectadas.

¿En qué consiste un proceso de test bajo el esquema TIBER-ES?

Podemos distinguir tres fases:

1. Fase de preparación: se establecen los equipos responsables de la gestión integral del test y su alcance (focalizado en las funciones críticas de negocio), y se seleccionan los proveedores de TI y de RT que lo llevarán a cabo. Esta fase dará comienzo tras el acuerdo entre la entidad que se somete al test y el TCT. Tiene una duración de entre cuatro y seis semanas sin incluir el tiempo necesario para contratar a los proveedores.

• Prelanzamiento: la entidad designará a un WTL y establecerá la composición del WT, que el TTM deberá validar, utilizando la guía TIBER-EU White Team Guidance. Tendrá lugar una reunión de prelanzamiento y se tratarán los requisitos respecto a las partes involucradas y sus responsabilidades, protocolos de seguridad y confidencialidad. El WT adoptará las medidas necesarias para la gestión de los riesgos derivados del test.

• Contratación de proveedores: el TCT solo validará la prueba bajo el esquema TIBER-ES si esta se lleva a cabo por proveedores externos que cuenten con una adecuada independencia respecto a la entidad, debiendo acreditar los proveedores su experiencia en ese campo. La selección se basará en la guía TIBER-EU Services Procurement Guidelines. Durante la formalización de los contratos se incluirán, entre otros, aspectos como las condiciones económicas y el alcance de las pruebas.

• Lanzamiento: una vez seleccionados los proveedores de TI y de RT, el WT completará la planificación de las pruebas y la agenda de reuniones con los participantes. Se celebrará una reunión en la que se detallará el proceso del test, las expectativas de la entidad, la planificación y un cronograma con las reuniones y puntos de control básico.

• Definición del alcance: el WT definirá el alcance preliminar de la prueba, que deberá incluir funciones críticas de la entidad y los sistemas y servicios que soportan dichas funciones. Si las funciones críticas están total o parcialmente externalizadas, la entidad valorará la posibilidad de incluir a un representante del proveedor como miembro del WT, para desarrollar la prueba de la misma manera que si no existiera dicha externalización. El WT establecerá los objetivos que deberá lograr el RT durante la prueba, los cuales podrán ir actualizándose durante las pruebas. Aunque la prueba deba ser realizada en un entorno de producción, los objetivos específicos podrán realizarse sobre entornos de producción, por ejemplo. El WT compartirá con el TCT y con los proveedores de TI y de RT el documento de alcance preliminar (TIBER-EU Scope Specification Template), con el fin de incorporar sus aportaciones. El documento del alcance deberá ser validado por el TCT, los proveedores de TI y de RT, y deberá ser firmado por el consejo de administración de la entidad.

2. Fase de testing: en base a un informe proporcionado por el proveedor de TI sobre la entidad objetivo del ejercicio, el equipo de RT usará los escenarios planteados para el ataque para intentar comprometer los sistemas informáticos en producción, así como los procesos y personas que forman parte del alcance de la prueba. La consecución del objetivo se demostrará logrando, a su vez, superar una serie de pruebas. En el caso de TIBER-ES, estas pruebas se definen como «captura de banderas», un concepto conocido al menos por aquellos que participan comúnmente en competiciones CTF (Capture the Flag). Tiene una duración aproximada de entre dieciséis y dieciocho semanas.

• Recopilación de información y ciberinteligencia: se pretende emular la tarea de recopilación de información previa a un ataque, que un ciberatacante real desarrollaría como fase de reconocimiento. En este primer paso de ciberinteligencia es importante reflejar las amenazas más importantes a las que se enfrenta, así como conseguir una visión lo más detallada posible de los mecanismos de defensa y de la superficie de exposición de la entidad. Este paso suele durar unas cinco semanas. En base a esta fase se desarrollarán los escenarios de ataque. Este informe será realizado por el proveedor de TI y será facilitado al WT, RT y TCT, quienes lo revisarán y validarán.

• Plan de test del Red Team: suele durar unas dos semanas. El plan de la prueba se realizará en base al informe mencionado en el punto anterior. La entidad podrá proveer al Red Team de información relevante para simular mejor las condiciones de un ataque real. El plan de test del RT estará formado por una serie de escenarios que representarán objetivos concretos a lograr. Tras esto se llevará a cabo una reunión entre el WT y los proveedores de TI y Red Team y TCT para discutir los detalles operacionales.

• Ejecución del test: suele durar entre diez y doce semanas. El RT deberá desarrollar técnicas alternativas de ataque en caso de encontrar obstáculos para lograr los objetivos o capturar las banderas asignadas. En ocasiones, el RT puede requerir al WT asistencia para deshabilitar barreras internas y/o controles de seguridad de la entidad, con el fin de facilitar el progreso del test; esta petición deberá quedar reflejada en los informes. El RT mantendrá continuamente informado al WT de los progresos, y deberá informar al menos semanalmente al TCT del avance de la ejecución del test. En caso de reuniones, el Blue Team (BT) no debe estar al tanto.

3. Fase de cierre: el proveedor de RT elaborará un informe de las actividades realizadas (proceso, recomendaciones y observaciones), que será analizado por el equipo de seguridad defensiva de la entidad. Se elaborará, a su vez, un informe-resumen de la prueba y se desarrollará un plan de acción para implementar las recomendaciones.

• Elaboración del informe del RT y del BT: el primero enviará al WT y al TCT su borrador del informe del test en un plazo máximo de dos semanas después de finalizarlo. El WT informará sobre el test realizado a los miembros clave del BT, quienes usarán el informe del RT para elaborar su propio informe.

• Recreación del test, lecciones aprendidas y plan de acción: el test será recreado por el RT y el BT y ambas partes revisarán los pasos dados, aunque no será estrictamente necesaria la recreación completa ni en entornos de producción; el fin es el aprendizaje. El RT deberá dar su opinión sobre lo que un atacante real con más tiempo podría haber logrado. Opcionalmente, se puede crear un Purple Team (PT), compuesto por miembros del RT y del BT, con el objetivo de trabajar conjuntamente en analizar qué opciones podría haber tomado el RT en el test y cómo podría haber respondido el BT ante ellos. Posteriormente, el WT llevará a cabo una reunión de evaluación entre todas las partes que intervienen en el test. La entidad deberá elaborar un plan de acción (acordado entre los proveedores de TI y RT) para la implementación de las recomendaciones de mejora acordadas, el cual se enviará a la autoridad supervisora de la entidad, ya sea nacional o supranacional.

• Informe-resumen del test: la entidad elaborará un informe-resumen del test basándose en documentos como los informes anteriormente realizados. No se incluirá información técnica detallada sobre las debilidades y vulnerabilidades encontradas debido a su confidencialidad. Este informe será compartido con el TCT y será enviado a la autoridad supervisora de la entidad, ya sea de ámbito nacional o supranacional.

• Validación del test: una vez acordado el plan de acción para implementar las recomendaciones, los proveedores de TI, Red Team y el TCT deberán validar que el test se ha hecho de acuerdo a los requisitos del marco TIBER-ES.

Cómo proceder con la gestión de riesgos durante las pruebas.

En primer lugar, resulta esencial llevar a cabo una identificación y un análisis detallado de los riesgos que podrían materializarse al ejecutar el test, y tomar acciones apropiadas para mitigarlos antes, durante y después de éste, lo que se traduce en un plan de contingencias, siendo esto responsabilidad del WT.

Los contratos con los proveedores deberán incluir cláusulas de confidencialidad y cubrir aspectos como los requisitos de seguridad, las responsabilidades, las indemnizaciones, los límites en la ejecución y las actividades que no están permitidas durante la realización del test.

Respecto a la confidencialidad en la realización de las pruebas, se debe asegurar que nadie en la entidad, salvo el WT, esté al tanto del test, y para ello podrán firmarse acuerdos de confidencialidad (non-disclosure agreements) con los proveedores.

El WT deberá gestionar el escalado de los ciberincidentes relacionados con el test para que no se ejecuten acciones que se llevarían a cabo de manera obligatoria en caso de ocurrir un ciberincidente real, como comunicarse con terceros, entre ellos las Fuerzas y Cuerpos de Seguridad del Estado. Si el se sospecha que el BT está al tanto del test y de que trata de manipular sus resultados, la prueba podría quedar invalidada.

Resultados y su uso en los procesos de supervisión.

Los detalles del resultado de un test realizado bajo el esquema TIBER-ES son única y exclusivamente propiedad de la entidad que se somete a él, debido a su carácter altamente confidencial. La excepción se presenta en el caso del plan de acción para la implementación de las recomendaciones de mejora y del informe-resumen del test, dado que en ellos no se incluirán los detalles técnicos.

No obstante, el TCT puede compartir con el TKC información relativa a las vulnerabilidades encontradas o lecciones aprendidas, en cuyo caso dicha información se anonimizará y se intercambiará usando siempre canales seguros, esto con el objetivo de prmitir al TKC conformar una imagen del estado de la ciberresiliencia del sector financiero europeo.

El equipo encargado de la supervisión estará involucrado tan solo en las fases de preparación y cierre del proceso. Durante la fase de preparación se le comunicará, a título informativo, el comienzo de las pruebas y se le podrá consultar sobre si el alcance definido cubre las funciones críticas de la entidad, y, durante la fase de cierre, se le enviará el informe-resumen y el plan de acción para implementar las recomendaciones de mejora.

Más información:

• GUÍA DE IMPLEMENTACIÓN TIBER-ES Threat Intelligence Based Ethical Red-Teaming – España
• El Banco de España aprueba la guía de implementación de TIBER-ES
• TIBER-EU Services Procurement Guidelines
• TIBER-EU FRAMEWORK

Fuente: Hispasec.

Seguir leyendo...