Archivo
Ciberseguridad en tiempos de Coronavirus (Parte 2)
En el post anterior revisamos algunos de los Ciberataques a nivel global, pero esta claro que en el Perú los Ciberatacantes están mas activos que nunca, de hecho un articulo emitido por el Organismo Técnico de la Administración de los Servicios de Saneamiento – OTASS en Perú se han registrado mas de 433 millones de intentos de Ciberataques. El articulo completo lo pueden encontrar aquí
Pero de que forma están atacando en Perú ?
A) Correos Electrónicos engañosos (Phishing)
Esta es la forma clásica, mas antigua y sencilla de realizar valga las verdades, según el diario Gestión de Perú el envío de emails con información engañosa en Perú aumento un 25% en cuarentena y se espera aumento mediante campanas de phishing bastante elaboradas a ciertos públicos objetivos.
B) Mensajes de texto SMS engañosos (SMS Phishing)
Esta forma de envío ha crecido significativamente también, enviando direcciones de internet o URL haciendo pasar por alguna entidad bancaria o empresa, esto es porque aprovechan que las personas hacen clic en los enlaces y no verifican si la dirección de internet es verdadera desde los teléfonos celulares o dispositivos móviles, de esta forma recogen no solo información bancaria si no también información personal que puede ser usada luego en ataques mas focalizados, aquí unos ejemplos:
Es necesario verificar, verificar, verificar mediante los siguientes pasos como se muestra a continuación :
C) Publicidad engañosa en redes sociales.
Como se podría esperar las redes sociales no están ajenas a este tipo de engaño , campañas donde que aprovechan la coyuntura también están a la orden del día siendo focalizadas en las que se leen desde dispositivos móviles (celulares) donde no es usual verificar si son paginas web o direcciones de internet validas.
Es altamente necesario verificar siempre las direcciones de internet como en este caso :
Conclusiones
Es evidente que los medios de banca digital y comercio electrónico sean convertido en estos tiempos de cuarentena y aislamiento social en un medio vital y no es la intensión de esta nota indicar que son malos y no se tienen que usar, todo lo contrario, el uso de estos medios representa un nuevo desafío para todos, en usar de manera correcta estas tecnologías y no caer en engaños como los que se han mostrado. Es así que así como el CODIV-19 nos toca ser muy precavidos para no caer en las redes de los ciberdelincuentes.
En el siguiente post veremos justamente recomendaciones a tener en cuenta para generar protección ante estos evento.
SWIFT SWIFTNet Hacking en Redes Bancarias
Luego de ver la noticia del hackeo del banco de chile, lean la publicación de la nota de Cesar Farro que lo detalla desde su perspectiva externa, me animé a escribir algo referente a ello, ya que es casi un año que vengo involucrado en realizar análisis de seguridad y vulnerabilidades a redes SWIFT justamente.
Como detrás de este tipos de servicios existen NDA vigentes, voy a ser bastante pragmático al respecto, emitiendo lineamientos que desde mi punto de vista personal, y que tendrían que ser de sentido común para este tipo de redes y al final conclusiones al respecto.
Al grano, normalmente siempre se tiene la perspectiva por fuera y no necesariamente por dentro, ya que como se entenderá son arquitecturas muy cerradas y no en lo tecnológico necesariamente ( si no pregunten el al banco de Chile 😀 ) digo esto por que al final terminamos hablando de los mismos componentes de siempre, como sistema operativos Windows, Unix, estaciones de trabajo, aplicaciones web, bases de datos, es decir nada que en una red empresarial deja de tener, empecemos desmenuzando la idea.
1.- QUE ES SWIFT ?
De pronto lo que uno mas conoce es el famoso código SWIFT para realizar transferencias internacionales, detrás de ello esta la “Society for Woldwide Interbank Financial” la cual provee hardware/software que articula mediante programas y regulaciones en general toda esta actividad a la cual están afectas las entidades bancarias.
Dentro de los lineamientos se establecen arquitecturas de uso que pueden tener las entidad bancarias que se detallan a continuación :
Arquitectura A1 Full Stack
La interfaz de mensajería como la de comunicación están dentro del entorno del usuario. Este tipo de arquitectura también incluye soluciones alojadas donde el usuario tiene las licencias para la interfaz de mensajería y la interfaz de comunicación.
Arquitectura A2 Partial Stack
La interfaz de mensajería está dentro del entorno del usuario, pero un proveedor de servicios (para ejemplo, una agencia de servicios, SWIFT Alliance Remote Gateway o un centro de grupo) es licencia y administra la interfaz de comunicación. 
Arquitectura A3 – Connector
La aplicación de software (por ejemplo, Alliance Lite2 AutoClient, soluciones de transferencia de archivos) es utilizado en el entorno del usuario para facilitar la comunicación de aplicación a aplicación con una interfaz en un proveedor de servicios. 
Arquitectura B – No local user footprint
No se utiliza ningún componente de infraestructura específico de SWIFT dentro del entorno del usuario.
Fuente : https://www.accesspay.com/wp-content/uploads/2017/09/SWIFT_Customer_Security_Controls_Framework.pdf
2.- LOS CONTROLES
Dentro de las regulaciones a nivel de gestión de SWIFT solicita y obliga a cumplir los 27 controles ( obligatorios y recomendados) los mismos que están indicados en el “SWIFT Customer Security Controls Framework” al cual se puede acceder públicamente y además los empleados cursos como por ejemplo el “Customer security programme” entre otros.
Un detalle que se puede identificar en este contexto, es que las entidades tienen que cumplir todos los controles y no solo los obligatorios ya que el común es pensar con eso ya están aprobando, cuando es todo lo contrario.
Sobre el cumplimiento de los controles, desde mi punto de vista, si bien es cierto en general la especificación de los controles es buena, sin embargo también muchos de los controles son muy ambiguos y poco precisos.
Basado en ello, un auditor/empleado que solo conoce la parte de gestión, puede interpretar de manera muy ligera los mismos, por ejemplo hacer cumplir un control determinado con solo con un procedimiento general, por el contrario alguien que maneja de parte de ingeniería/técnica la va interpretar de manera mas puntual, por ejemplo con una captura de pantalla del sistema o componente técnico, donde se muestra que se hace efectivo el control.
Para finalizar este punto indicar que la red SWIFT de la entidad va ser tan antigua como la misma lo permita en funcion a lo de siempre, no actualizar su arquitectura.
3- Evaluaciones de Cyberseguridad
Dentro de los controles de SWIFT se exige que es necesario hacer una evaluación de Ciberseguridad / Ethical Hacking a todos los componentes que involucran la arquitectura SWIFT. Por otro lado también a nivel de regulador bancario en el caso del Perú por ejemplo es la SBC que también lo exige, entonces tienen por lo menos dos servicios que tienen que ejecutar en diferentes ámbitos.
En ese sentido, es clave definir bien los activos a evaluar, sistemas involucrados, las actividades contempladas y horarios de ejecución, es decir es necesario definir bien el alcance, de lo contrario como en otros ámbitos, este punto solo será un puro formalismo a cumplir en el informe como desarrollar un escaneo o un análisis de vulnerabilidades automatizado que pasa a los informes.
4.- CONCLUSIONES Y RECOMENDACIONES
– Contar con la zona segura exclusiva/aislada de todo y textualmente de TODO sin ningún tipo de enlace hacia la red empresarial y hacia internet, esto es fundamental pero es muy difícil sobre todo por temas en primera instancia de flexibilidad, recordar el viejo dicho “mientras mas mas seguro menos flexible” y por otro lado de presupuesto, ya que estamos hablando para comenzar de tener toda la parte de switching, firewall, controladores de dominio y demás dispositivos de la arquitectura, exclusivos para la red SWIFT totalmente separado y con una función única.
– PC de operador de uso exclusivo, es decir solo para uso de SWIFT, evitar uso de servidores de salto, maquinas virtuales, citrix, escritorios remotos y demás elementos, como sabemos la mayor brecha de seguridad la producen los usuarios finales e inevitablemente se tiene que usar Windows (ojo aquí con las actualizaciones de seguridad), es recomendable primero que las PC de operador que acceden a los aplicativos SWIFT sean de uso exclusivo para ello y estén dentro de la zona segura , evidentemente siguiendo estándares de aseguramiento muy rígidos (Que normalmente no lo aplican no solo a nivel del sistema operativo, si no a nivel físico, ejemplo, contraseña de bios, desactivar USB, no tener software innecesario, no tener salida a internet entre otras.
– Uso de doble factor de autenticación, uso de tokens RSA para no solo autenticar hacia las aplicaciones, si no también a nivel de sistema operativo de los PC operador, reduce la brecha de riesgo.
– Servidores de producción SWIFT , Desde mi punto de vista usar servidores Windows para los servidores de producción y respaldo que exige SWIFT, es un error, cuando es sabido que Solaris/Unix ofrecen una menor brecha de seguridad en cuanto a vulnerabilidades reportadas.
– Software de Mensajería SWIFT y arquitectura general SWIFT va ser tan actualizada o no, como la entidad bancaria lo decida, SWIFT provee actualizaciones bastante constantes por ejemplo para el software de mensajería, mediante boletines y es labor de los responsables estar capacitados para realizar ello.
Finalmente basado en lo que he visto la mayor brecha de seguridad esta en no tener una red segura, usuarios operadores con estaciones Windows multiproposito y el y uso Windows en los servidores de mensajería.
Espero les sirva.
Saludos
Juan Oliva
Juan Oliva 