SEGURIDAD EN ENTORNOS WEB BANKING

[seguridadinformatica.es]

Este trabajo es parte de una tesis doctoral. En este artículo se reportan solamente algunas de las políticas principales. Este trabajo proporciona un estudio de la seguridad sobre el entorno de Internet Banking. La meta es proporcionar un conjunto de políticas de seguridad que toman en cuenta la mayoría de los controles del estándar ISO27001. Incluidas en tales políticas se definen: metodología de programación segura, implantación del Sistema Operativo, del Sevidor Web, etc; con el fin de poder implementar un sistema no vulnerable frente ataques de tipo phishing y pharming.

El proceso se ha estudiado para ser aplicado fácilmente con el mínimo impacto debido a la actualización del sistema actual de Internet Banking. El método propuesto, además de ser resistente a ataques de tipo phishing y pharming, es resistente a ataques “man in the middle” (MITM), ingeniería social, buffer overflow, SQL Injection, Cross Side Scripting (XSS), etc.

El método propuesto tiene la ventaja de proporcionar seguridad también en entornos hostiles, como puede ser el de una máquina del cliente infectada por troyanos bancarios, capaces de capturar los datos de acceso a la web del banco. En este proyecto se propone el uso de un proceso de mutua autentificación y subraya la ineficacia de los certificados digitales para autenticar la entidad financiera. El usuario en la mayoría de los casos no sabe distinguir entre uno válido y uno no válido, o también muchas otras veces el usuario ni siquiera se fija en estos detalles y acepta sin más el certificado. Además no es la mejor idea hacer residir la seguridad de las actividades bancarias on-line en certificados digitales, ya que el protocolo podría verse afectado (como lo fue en el pasado) por alguna vulnerabilidad que en condiciones particulares pondría en peligro al usuario.

1. Introducción

Diferentes técnicas y estándares se han desarrollado para proporcionar seguridad de la información en diversos usos, pero actualmente no existe ninguna para una aproximación metodológica a la seguridad de las actividades bancarias en Internet. Sin embargo, hay un aumento del número de nuevos ataques y de virus contra páginas Web de entidades financieras, tales como "fraudes phishing" y "pharming", los cuales habría que solventar para garantizar la confianza y seguridad de los clientes de los servicios bancarios on-line.

Este artículo describe políticas de seguridad relativas a los aspectos siguientes:

• Aplicación Web: Esta política contiene las especificaciones para el desarrollo y el ciclo de vida seguro (SDLC) del software y el análisis de riesgo. Esta política se compone de las secciones: Autenticación, sesión, autorización, gestión de logs y errores y validación de entrada y salida.
• Base de datos: Esta sección contiene las reglas para la seguridad de las bases de datos, y también proporciona una lista de comprobaciones para SQL Server.
• Sistema operativo: Esta política contiene las especificaciones para la implementación y configuración del sistema operativo, se han proporcionado reglas tanto para sistemas Windows como Linux/Unix.
• Web Server: Esta política contiene las especificaciones para la implementación y configuración del servidor web, aportando detalles para la implantación de Microsoft IIS y Apache.
• Backup: Esta política contiene las especificaciones para la gestión de las copias de seguridad. Algunos apartados contenidos en tal política se reportan a continuación:
  • Planificación temporal
  • Validez del Soporte
  • Responsabilidades
  • Información a incluir en el backup
  • Rotación del soporte
  • Testeo de las copias de seguridad
  • Recuperación de la información
  • Limpieza
• Auditoría: Esta política contiene las especificaciones y requerimientos para efectuar un test de intrusión (externo e interno).
• Soporte al cliente: Esta política contiene las especificaciones para la gestión de usuarios.
• Logs: En esta política se definen los requerimientos para la información a incluir en los logs, eventos por auditor, requerimientos de seguridad, etc.
• Monitorización: En esta política se definen los requerimientos para la monitorización de red y sistemas.
• Red: En esta política se define la estructura y requerimientos para la implantación y configuración de la red, con el fin de proporcionar una óptima tolerancia a fallos.
• Password: En esta política se definen los requerimientos, en términos de seguridad (estructura, caducidad, etc.) para las contraseñas.
• Plan de contingencia y respuesta a incidentes: En esta política residen todos los detalles para actuar ante un problema de seguridad, como puede ser un incidente o un ataque informático.
• Cifrado: Esta política contiene las especificaciones para encriptación y para los controles de integridad.
• Áreas y equipamiento: Esta política contiene las especificaciones para la implantación de áreas seguras y gestión de equipos.
• Gestión de usuarios: Esta política contiene las especificaciones para la gestión de las cuentas de los usuarios.
• Sensibilidad de la información: Esta política contiene la clasificación de la información pertinente a la entidad bancaria y además se proporcionan detalles de cómo tiene que borrarse, enviarse, protegerse, etc.
• Documentación: Esta política contiene las especificaciones a seguir por toda la documentación pertinente a la entidad bancaria. Se definen detalles como apariencia, protección contra lectura/escritura según la clasificación de confidencialidad del documento, y otros.
• Contratación de personal: Esta política contiene las reglas a seguir durante los procesos de recursos humanos.
• Desempleo: Esta política define las acciones a tomar en caso de una baja voluntaria o por despido.
• Uso de recursos: Esta política define el uso permitido de los recursos de la entidad bancaria
• Antivirus: En esta política se definen los requerimientos para implementar un completo sistema antivirus.

2. Estado del arte

Muchas instituciones financieras ofrecen diferentes servicios bancarios on-line a sus clientes, con diferentes niveles de funcionalidad. La protección de la información en estos servicios también se implementa con diferentes técnicas, y puede que sea más vulnerable frente a un ataque que otro.

En un nivel general, la mayoría de los sistemas de gestión de la seguridad de la información siguen las directivas especificadas en el estándar ISO/IEC 27001 [1]. Esta especificación proporciona las reglas generales para la selección de los controles apropiados de la seguridad para proteger nuestro activo más importante: la información.

En el nivel específico de la seguridad de las actividades bancarias de Internet, la situación es diferente. No hay un estándar establecido para los servicios bancarios en entorno Web, pero hay algunos manuales orientados a este particular entorno. Algún ejemplo de estos puede ser el Payment Card Industry (PCI) Data security Standard (DSS) [2]. Además algunas organizaciones del gobierno han publicado sus propios manuales, por ejemplo en el caso de América, “the electronic banking guides” manuales creados por el Office of the Comptroller of the Currency (OCC) [3], los procedimientos “e-banking examination” creados por el Federal Financial Institutions Examination Council (FFIEC) [4], o las especificaciones creadas por el Federal Trade Commission (FTC) [5].

Nuestro trabajo pretende proporcionar un estudio completo de las vulnerabilidades y posibles medidas de salvaguarda presentes en entorno de Web Banking.

3. Modelo Lógico

Nuestra aproximación al estudio de seguridad para web banking se basa en el siguiente modelo lógico:

• Navegador y red cliente
• Internet
• Servidor del Banco y red bancaria privada

Entre estos elementos, el menos configurable es Internet. En este entorno consideramos no poder imponer medidas de salvaguarda o especificaciones. En el caso del entorno del cliente tenemos que tomar en consideración el caso peor. Esto nos permitiría el lujo de poder efectuar movimientos bancarios de forma “segura” en cualquier entorno, afectados por troyanos, keyloggers, sniffers, virus, etc.

Por último, en el caso del servidor de la entidad bancaria, aquí se necesita un gran nivel de seguridad, ya que es nuestro entorno de confianza (no para el usuario, ya que la entidad bancaria podría ser suplantada) y es donde podemos forzar e implementar medidas de seguridad. Nuestro modelo considera ambas partes mutuamente de no confianza, implicando la necesidad de la mutua autenticación y de la necesidad de las máximas medidas de salvaguarda.

Nuestro modelo se basa en los siguientes aspectos: seguridad de la aplicación bancaria web, servidor web del banco, red del banco, contraseñas, y otras políticas de seguridad.

4. Principios de Seguridad

Nuestro modelo se basa en el teorema principal:

• Nada es 100% seguro.

De este teorema se deducen los corolarios [7]:

• No confíes.
• Deniega por defecto
• Permitir sólo lo permitido
• No basar la seguridad en la ofuscación
• La seguridad global es igual al mínimo de las seguridades
• Promover seguridad por defecto
• Respeta el principio de defensa en profundidad.
• Minimiza el área expuesta a ataques
• Que sea todo lo más simple posible
• Valida siempre entrada y salida
• Usa componentes de confianza
• Separa privilegios: Un atacante puede combinar operaciones lícitas para poder lograr operaciones no permitidas
• Aplica siempre el principio del menor privilegio o conocimiento según necesidad, nunca más de lo mínimo requerido
• Fallar de manera segura. Si un servicio falla tiene que rechazar las sucesivas llamadas al servicio.
• Sistemas externos son inseguros

5. Políticas de seguridad

1. Aplicación web

5.1.1 Autenticación

Los sistemas Web banking, como todos los servicios web, usan el protocolo HTTP. Sólo se debe de usar HTTPS y las variables tienen que pasarse por método POST. Es muy importante que sólo se acepte POST, ya que un usuario malicioso podría crear una página y enviar conjuntamente POST y GET.

Para nuestro entorno el mejor método de autenticación es la mutua autenticación, esto nos permite evitar o por lo menos detectar el phishing y pharming sin comprometer la integridad de la cuenta web bancaria. El orden en el cual se efectúa la autenticación, como muchos otros factores, es importante y hay que implantar muchas medidas de salvaguarda en cuanto se trata de un proceso muy delicado; una simple falta de un detalle llevaría a un resultado catastrófico.

Buena parte de la investigación efectuada se ha dedicado a la definición de vulnerabilidades, al análisis de riesgo y la búsqueda de medidas de seguridad capaces de satisfacer nuestras necesidades; ha sido necesario definir muchas medidas de salvaguarda para que el método de mutua autentificación propuesto sea robusto frente a las actualmente conocidas amenazas en entorno web.

El sistema de mutua autenticación propuesto detecta intentos de suplantación y bloquea el atacante (IP y/o cuentas web del atacante y/o del atacado). Además nuestro sistema promociona la seguridad también cuando el entorno cliente está comprometido (virus, “man in the middle”, troyanos bancarios) y también en el caso de phishing y pharming.

5.1.2 Sesión

La sesión es un elemento muy importante en entorno web, ya que a menudo se usa para identificar el usuario después del proceso de login; si la sesión es vulnerable la cuenta podrá ser comprometida. Algunos requerimientos de seguridad definidos para la sesión son: la sesión tiene que ser cifrada, validada, tiene que tener una longitud igual o superior a 64 dígitos, tiene que tener un time out de 15 minutos, etc.

5.1.3 Validación de datos

La validación de datos de entrada y salida es un factor determinante para la seguridad de la aplicación: cualquier deficiencia en el proceso de validación podría ser letal y hacernos vulnerables.

Antes de efectuar la verdadera validación se pasa la entrada por filtros detectores de ataques y posteriormente se efectúa la canonicalización (UTF-8 para URLs) y a continuación es posible validar según longitud, rango, tipo, caracteres permitidos, no permitidos, etc. Durante el proceso de definición de los requerimientos es importante respetar las filosofías básicas como denegar por defecto, permitir sólo lo permitido y otorgar el mínimo privilegio.

Cuando ocurre un fallo de validación (si no se reconoce como ataque) se gestiona como una sospecha de ataque, un ataque con peso reducido.

5.1.4 Logs

Los logs son importantes para muchos fines como la detección de ataques y errores, verificación de la correcta funcionalidad, realización de análisis forenses y otros. En esta política se ha definido la información y eventos por auditar y los requerimientos de seguridad.

Un ejemplo de información a rastrear son los intentos de inicio de sesión realizados correctamente e incorrectamente, la actividad de usuario, etc.

5.1.5 Gestión de errores

Un usuario malicioso podría tomar ventaja de un mensaje de error y usarlo en un futuro ataque. Es muy importante efectuar una correcta y completa gestión de errores y excepciones y redirigir los errores a la página que gestiona los errores.

5.5 Seguridad de plataforma

Este conjunto de políticas gestiona la seguridad de la plataforma bajo diferentes aspectos como seguridad del servidor, del sistema operativo y sistema de ficheros, base de datos, red, etc. Requerimientos generales y detallados se han proporcionado para los diferentes entonos, tal y como entorno Windows y Unix.

5.5.1. Seguridad en el Sistema Operativo

Seguridad en Windows

En esta sección se definen los requerimientos de seguridad para el sistema operativo Windows, algunos de ellos son: usar sólo software original, estar al corriente en términos de parches, eliminar todo lo viejo y lo no necesario, cambiar o quitar los banners, revisar periódicamente privilegios y fortaleza de passwords, cifrar el fichero SAM, tener actualizado el antivirus, restringir las sesiones nulas, filtrar puertos de NetBios, etc.

Seguridad en Unix/Linux

En esta sección hemos definido las medidas de salvaguarda a implantar para sistemas Unix, hemos promocionado seguridad bajo diferentes aspectos como: auditar periódicamente las contraseñas y cuentas y privilegios de usuarios, asegurar el Lilo/Grub, usar fichero shadow para almacenar las contraseñas, permitir sólo contraseñas seguras, no permitir conexión con usuario root de forma remota, cambiar los banners, asegurarse contra ataques de enlace simbólico, etc.

5.5.2 Base de Datos

La base de datos es un elemento muy sensible y necesita de un nivel alto de seguridad; confidencialidad e integridad tienen que proporcionarse por defecto. Toda la información almacenada en la base de datos se ha clasificado según niveles de sensibilidad y por cada nivel se han definido unas reglas de comportamiento para almacenaje, envío, eliminación, etc.

Además se han definido los requerimientos de seguridad a cumplir, tales como implementar ACL, efectuar copias de seguridad, cifrar la información sensible, habilitar logs, borrar configuraciones y cuentas por defecto, que la base de datos sea normalizada a la 5ª forma normal, etc.

5.5.3 Servidor Web

En esta política se han proporcionado reglas generales, a nivel de seguridad, para la implantación y configuración del servidor web de la entidad bancaria. Particulares procedimientos han sido definidos para los servidores web más usados: Microsoft IIS y Apache. Alguna de las reglas generales definidas son: estar al corriente en términos de parches, separar partición de sistema y partición de datos, ejecutar los servicios con el mínimo privilegio posible, no permitir listado de directorios, etc.

5.5.4 Seguridad de Red

Se propone la implantación de una DMZ, donde estará ubicado el servidor web de la entidad bancaria, la parte frontend y la backend tienen protección perimetral proporcionada por un firewall. Además se requiere el uso de sistemas detectores de intrusos (IDS). Por razones de eficiencia se aconseja implantar dos IDS, uno en la frontend y el otro en la backend.

Se propone la implantación de un sistema redundante y muy tolerante a fallos que hace uso de warm site, discos de tipo RAID, redundancia de los dispositivos y configuraciones en fail-over.

5.6 Política de contraseñas

En esta política se definen los requerimientos para las contraseñas. Se definen límites como longitud mínima, espacio de caracteres a usar, bloqueo por número de intentos fallidos, tiempo de bloqueo y también se proporciona un listado de acciones no permitidas como la de compartir la contraseña que la contraseña pertenezca a palabras de diccionario o sea similar al nombre de usuario, almacenar la contraseña de usuario en un formato reversible, el uso de contraseñas débiles, etc.

5.7 Soporte

Esta política define los procedimientos y requerimientos para peticiones de servicios por parte de los clientes. Se gestionan tareas como petición de cambio de contraseña entrega de tarjeta, denuncia y anulación de claves/tarjetas comprometidas/perdidas/robadas y solicitudes de cambio de límites o datos personales.

6 Conclusiones

Nuestro objetivo era el de proponer medidas de salvaguarda para lograr un entorno de web banking resistente a las condiciones más adversas, como pueden ser ataques de tipo phishing y pharming y entornos comprometidos del cliente por troyanos bancarios, virus, etc.

El objetivo ha sido alcanzado y el sistema propuesto resulta ser robusto gracias a la implantación de diferentes medidas de salvaguarda que proporcionan seguridad bajo diferentes entornos hostiles tales como ataques Man in the Middle, inyecciones de SQL, Cross Side Scripting, presencia de malware en el lado cliente, desbordamiento de buffer y obviamente bajo ataques de tipo phishing y pharming.

Tal y como se ha mencionado anteriormente, el sistema propuesto ha sido pensado para poderse adaptar a la infraestructura actualmente usada por las entidades bancarias que implique el mínimo impacto y coste.

Referencias

[1] ISO/IEC 27001 (2005): Tecnología de la información -- Gestión de un sistema de seguridad de la información [2] http://www.pcisecuritystandards.org/
[3] http://www.occ.treas.gov/
[4] http://www.ffiec.gov/
[5] http://www.ftc.gov/
[6] http://www.sqlsecurity.com/FAQs/SQLSecurityChecklist/tabid/57/Defau...
[7] http://www.owasp.org/

Autor: Antonio San Martino, Xavier Perramon

[Seguridad de la Informacion]

Se puede acceder a leer la tesis doctoral completa?

[seguridadinformatica.es]

El autor del informe pasa por aquí, así que es probable que ponga un enlace a toda su tesis doctoral.

[localhos1]

Xavier Perramon, asi se llamaba uno de mis profes de la uni :P

[José Ricardo García]

Realmente es unb estudio muy interesante y útil para todos.
José Ricardo

[Antonio San Martino]

Hola, pido disculpa por la tardanza pero no relaicé que el articulo ya se habia publicado.
Pasaré por aqui periodicamente, los que deseenn por favor pasarme vuestros email y os dare informaciones. Para poder disponer del documento final habria que esperar que se publique. Pronto espero efectuar la censeña y si la aceptan, el documento será publicamente consultable.

[pedro]

Muy Interesante. Gestionas también el problema de phishing? Como lo gestionas?
Podria envirme infromaciones al respecto?

[sergio]

Estaria bueno acceder al DOC completo, ya que veo que es un trabajo bastante extenso donde se tocan muchos aspectos de la seguridad en Internet. El autor podria indicar si se tocan aspectos y como implementar la criptografia asimetrica en un entorno WEB?

[Antonio San Martino]

Hola a todos,
Primero: gracias por el interés.

Respondiendo a Pedro:
>Gestionas también el problema de phishing? Como lo gestionas?
>Podria envirme infromaciones al respecto?

en el proyecto de Tesi se gestiona el tema de phishing. Se definió un modelo de autenticación que si respectado, el portal de la entidad financiera no resulta ser vulnerable frente a intentos de phishing o pharming. Para proporcionar una breve explicación, el phishing explota unas deficiencias presente en el proceso de autenticación.
Si quieres y me pasas tu email, dejando un comentario a mi usuario en este portal, te envió más información.

Un saludo.
Antonio San Martino

[marc]

Dear buddy, you are right!!!
Pensandolo un poco entiendo hacia donde van los tiros....
Es posible lograr y aplicar el metodo que propones?
POR CIERTO: MUY MUY BIEN!!!

[Antonio San Martino]

Hola a todos,


Respondiendo a la pregunta de Sergio:
>El autor podria indicar si se tocan aspectos y como implementar la criptografia asimetrica en >un entorno WEB?

La pregunta es muy interesante, claro que se tocas aspectos de cryptografia asimetrica, aunque esta es solo una forma para poder proporcionar confifencialidad, integridfad y no repudio. El modelo propuesto puede aplicarse con la tecnologia que cada entidad disponga. De hecho el todo ha sido pensado con el fin que sea facilmente aplicable a los entornos E-Banking actuales, con el minimo impacto posible.
La Tesi Doctoral tiene como objetivo deefinir politicas de seguridad y en las politicas se definen procesos y requerimientos, no detalles de como efectuar implementaciones. Las politicas de seguridad, a lo contrario de las buenas practicas o guidelines, son de muy alto nivel y tienen que ser aplicables con diferentes tecnologias y por esto las politicas de seguridad normalmente no se veen afectadas por cambien de tencologias, cosa que en lugar ocurre con las buenas practicas. Además una Tesi docutoral tiene que aportar investigación inovadora, algo que no exista ya y hoy en dia ya hay mucho material sobre como implementar la cryptografia asimetrica.

Por otro lado si realmente necesitas usar cryptografia asimentrica, considera que es bastanter mása costosa de la simetrica y además en el lado cliente, si no quieres muchos problemas de que si Activex o exe o... tienes que ser javascript - html (y el codigo fuente se ve en claro) y la verdad en javascript no lo veo muy vieble, menos para una entidad financiera.
De todasds formas si quieres podemos hablarlo.
Espero haber respondido a tu pregunta, si desea más informaciones, ya sabes, pasame tu correo dejandome un mensaje en la intranet de este sitio.
Un cordial saludo.
SM

PD: Caro Señor Marc, es un honor por mi parte recibir sus cumplidos!!! Muchas gracias