Seguridad en las transacciones on line de comercio electrónico (página 3)

Encriptación: Proceso mediante el cual un conjunto de datos se transforman en un conjunto cifrado de datos mediante una función de transfor- mación y una llave de codificación.

Desencriptación: Proceso inverso a la encriptación, en el cual el conjunto cifrado de datos se convierte en el texto original mediante una segun- da función de transformación y una llave de desencriptación. La llave puede ser la misma para ambos procesos o distinta.

Figura P.: Ejemplo sencillo de encriptación y desencriptación.

En la Figura Q, se presenta un par de algoritmos de encriptación y des- encriptación que tiene dos inconvenientes:

• Es tan fácil encriptar como desencriptar. El éxito de la encriptación radica en que sea relativamente sencillo, barato y con poco tiempo de proce- samiento, el realizar el encriptado. Mientras que el desencriptado debe ser más complejo ya que eso asegurará que a un receptor que no posea autorización para leer el mensaje y por lo tanto el algoritmo desencriptador, le resulte más costoso deducir el algoritmo de desencriptación que la información que el men- saje encriptado contiene.

• El mensaje: "LOS PATOS SON 2" se encriptaría de la siguiente manera: "L4S P1T4S S4N 2" y sería desencriptado de la siguiente manera: "LOS PATOS SON E". Es decir este algoritmo pierde información si el mensaje original contiene números.

Pero aun así sirve a modo de ejemplo.

Algoritmos y funciones criptográficas

La criptografía tiene miles de años de antigüedad, los primeros usos de esta técnica se remonta n a las Guerras Helénicas en que los comandantes uti- lizaban el método de sustitución y transposición para enviar mensajes a los soldados en el campo de batalla, asegurándose así que la posible intercepción del mensajero no signifique que el enemigo supiera el contenido del mensaje interceptado.

La sustitución es un método que consiste en reemplazar una letra del mensaje por otro símbolo equivalente, como en el ejemplo antes citado. Esté método se llama también Método César ya que Julio Cesar lo utilizaba en sus campañas.

Figura Q.: Ejemplo de algoritmos de encriptación y desencriptación.

La transposición, en cambio se basa en intercambiar el orden de los ca- racteres para evitar que el mensaje sea legible. Un método es el matricial don- de el mensaje es escrito en una matriz y luego la misma se transpone. Ej:

Los algoritmos de encriptación actuales, utilizan los métodos de sustitu- ción y transposición combinados y transformaciones mediante funciones ma- temáticas. A continuación detallamos los más utilizados.

• Algoritmos de llaves simétricas

Son llamados así los algoritmos que usan la misma llave para encriptar y para desencriptar. Son más rápidos que los de llave pública y más sencillos de implementar. Un problema es que para poder intercambiar mensajes de forma segura, ambas partes deben primero intercambiarse la llave de forma segura ya que si un receptor no autorizado posee la llave podrá desencriptar los men- sajes.

Este tipo de algoritmo es aun muy utilizado debido a su rapidez.

La fortaleza13 de los algoritmos de llaves simétricas depende de los si- guientes factores:

Confidencialidad de la llave.

Dificultad de adivinar la llave.

Dificultad de forzar el algoritmo de encriptación.

Ausencia de puertas traseras, es decir huecos de seguridad que permitan desencriptar el mensaje sin tener la llave.

La posibilidad de desencriptar un mensaje si se conoce una parte de él (ataque de piedra roseta).

Lamentablemente es muy difícil probar la fortaleza criptográfica. Gene- ralmente se prueba la debilidad de un algoritmo que a veces ya se encontraba difundido como seguro. La verdadera seguridad criptográfica está en publicar el algoritmo y esperar a que no se le encuentren errores Los ataques más comunes que reciben este tipo de sistemas son alg u- nos de los siguientes:

Ataque de búsqueda de llaves (fuerza bruta): Si el violador de códigos tiene la capacidad de reconocer el resultado de utilizar la llave correc- ta, ento nces el método más simple de violar la encriptación es probar todas las llaves posibles. Casi todas fallarán pero al final alguna tendrá éxito, cómo se grafica en la Figura R. La forma de protegernos contra este tipo de ataques es que el universo de llaves posibles sea suficientemente grande para evitar que se prueben todas. Por ejemplo. En Internet se utilizan, generalmente llaves de 128 bits. Esto permite 2128 (3.4 x 1038) llaves posibles, un número suficiente- mente grande como para evitar que alguien se ponga probar de a una. Hasta con ayuda de procesadores que intenten violar el código se tomaría varios mi- les de años hasta descifrar el código.

Figura R.: Ataque de fuerza bruta.

Criptoanálisis: La mayoría de los algoritmos de encriptación pueden ser vencidos mediante la combinación de matemáticas y poder de cómputo. Por lo que casi nunca es necesario, para violar un código, el intentar el método de la fuerza bruta. Un criptoanalista (persona que rompe códigos) puede descifrar el texto encriptado sin necesidad de tener la llave y sin saber el código de encriptación. Un tipo de criptoanálisis es el ataque de piedra roseta en el que el violador tiene parte del mensaje desencriptado y la misma parte encriptada; con este tipo de ataque el violador obtendrá primero el algoritmo de encriptación, el que luego puede utilizar para intentar inferir el algoritmo de desencriptación para así descifrar el mensaje.

Ataques basados en el sistema: Esta forma de ataque se basa en buscar debilidades en el sistema que utiliza el algoritmo criptográfico sin atacar al algoritmo en sí. Un ejemplo es el caso de una violación en la seguri- dad de Netscape que utiliza una llave aleatoria14. Pero el generador de núme- ros aleatorios de Netscape no era un buen generador por lo que se podía alte- rar la semilla del generador y predecir el número aleatorio generado, pudiendo así adivinar la llave.

• Algoritmos de llave pública

En este tipo de algoritmos se utiliza una llave para encriptar y otra para desencriptar. De esta forma los sujetos que desean intercambiar mensajes pueden intercambiarse la llave pública encriptadora de forma no segura y con- servar la llave desencriptadora. Este principio es el mismo que se usa en las firmas digitales. El problema más grave de este sistema es que es muy lento, entre diez y cien veces más que el sistema de llaves simétricas.

Ha habido mucho menos desarrollo de algoritmos de llave pública que de llave simétrica ya que para crear un algoritmo de llave simétrica sólo hace falta idear una forma de hacer la revoltura de datos, de forma confiable y sufi- cientemente intrincada como para que no sea fácil deducir el algoritmo de des- encriptación. En cambio, los algoritmos de llave pública se basan en la teoría numérica por lo que el desarrollo de un algoritmo nuevo implica encontrar un paradigma matemático de características especiales.

Los ataques más comunes que reciben este tipo de sistemas son los si- guientes:

Ataques de factorización: Intentan derivar la llave secreta a par- tir de la llave pública, de la que el atacante tiene una copia. Este ataque necesita resolver problemas matemáticos de alta dificultad como la factorización de números grandes.

Ataques algorítmicos: Este tipo de ataque consiste en encontrar una falla o debilidad fundamental en el algoritmo en que se basa el problema matemático.

El problema con este tipo de algoritmos es que un defecto en los mismos no necesariamente tiene que ser publicado, lo cual no significa que no exista o no se conozca.

• Criptosistemas híbridos público / privado

Este sistema se basa en una llave de sesión, que es una llave pública aleatoria que se utiliza para crear un sistema de llaves simétricas. Cada vez que se inicie un intercambio de datos, la llave aleatoria habrá cambiado y se generará una nueva llave simétrica. Este sistema es uno de los más utilizados ya que combina las ventajas de ambos sistemas.

• Funciones de compendio de mensaje

Este tipo de encriptación genera un patrón de bits único para cada en- trada específica. Son como huellas digitales para archivos. Se ilustra en la Fi- gura S.

Figura S.: Función de compendio de mensajes.

Este tipo de algoritmo, no se utiliza para encriptar y desencriptar sino pa- ra crear firmas digitales, códigos de autorización de mensajes y llaves de en- criptación a partir de frases de acceso.

Estas funciones son más rápidas que las funciones criptográficas de lla- ves simétricas, conservando sus mismas propiedades criptográficas y no tienen restricciones de pate nte.

La criptografía en la Web

La encriptación es la única tecnología viable para proteger la transacción de datos mientras son transportados de una computadora a otra a través de la red pública.

Las funciones de la encriptación permiten brindar seguridad a un sitio Web mediante los siguientes conceptos:

Confidencialidad: la encriptación se usa para ocultar información enviada a través de Internet y almacenarla de forma que si alguien intercepta la comunicación no puede acceder al contenido de los datos ya que los mismos le resultan incomprensibles.

Autenticación: la encriptación es utilizada para realizar firmas digitales, para identificar al autor de un mensaje, comprobando su identidad.

Integridad: la criptografía sirve también para verificar que un mensaje no ha sido modificado mientras se encontraba en tránsito, ya sea por una voluntad de modificarlo o por un ruido accidental en la línea de comunica- ción.

No repudiación: mediante la encriptación se crean remitos de forma que un autor de un mensaje no pueda negar su autoría.

Aunque hay algoritmos de encriptación que cumplen más de una de es- tas funciones, en la mayoría de los casos se considera mejor utilizar métodos diseñados específicamente para cada función que se quiera lograr en vez de confiar en los beneficios colaterales de otros algoritmos.

Limitaciones de la criptografía

La criptografía en la Web es tan necesaria que muchos usuarios y lo que es peor hasta administradores de sistemas confunden criptografía con seguri- dad. En realidad, si bien es un elemento importante de la seguridad en la Web, la criptografía sólo nos protege de la intercepción de datos mientras están siendo comunicados entre computadoras,.

La criptografía no es la solución adecuada para muchos problemas, in- cluyendo los siguientes:

La criptografía no puede proteger los documentos no encrip- tados: si el servidor Web está configurado para enviar documentos encriptá n- dolos, pero los documentos originales residen en él. Se podría tener acceso a la información, violando el acceso al servidor.

La criptografía no puede proteger contra el robo de llaves de

encriptación: el sentido de la encriptación reside en que quienes poseen la llave criptográfica puedan desencriptar los archivos o mensajes. Con esto cua l- quiera que pueda robar, comprar o poseer de algún modo la llave para desen- criptar logrará acceder a la información.

La criptografía no puede proteger contra ataques de negación

de servicio15: por definición la criptografía intenta proteger la información de interceptores no autorizados. Si un atacante tiene un propósito por el cual no le sea de interés acceder al contenido de la información, la criptografía no será una defensa apropiada.

La criptografía no puede proteger contra el registro de un

mensaje ni contra el hecho de que el mensaje haya sido enviado: en el criptoanálisis el estudio de esta información se conoce como análisis de tráfico y significa que si bien se está ocultando el contenido de los mensajes no se está ocultando el rastro de los mismos y al hacer una auditoría se puede saber que un sujeto A ha estado intercambiándose mensajes con otro sujeto B.

La criptografía no puede proteger contra un programa de encriptación con trampas: es posible modificar los algoritmos de encriptación para hacerlos inútiles, esta posibilidad no se puede eliminar, aunque se reduce el riesgo, obteniendo los programas criptográficos de canales confiables y to- mar políticas de seguridad para evitar que los mismos sean modificados.

La criptografía no puede proteger contra un traidor o contra

un error: las personas son el eslabón más débil de cualquier sistema. Si una persona dentro de la organización altera o divulga la información protegida crip- tográficamente, el sistema no tiene manera de proteger la información.

Riesgos de una transacción en línea con encriptación

A continuación se enumeran aquellos riesgos que se corren al transmitir un mensaje en la Web contra los que la encriptación no nos protege. [L-9] [E-1]

Riesgo de que la información proporcionada para la transacción sea utilizada en un futuro para fines no deseados, ejemplo correo no deseado.

Riesgo de que el comerciante pueda obtener control del navega- dor del sujeto A.

Riesgo de que un tercero se infiltre en la comunicación y controle el navegador del sujeto A.

El sujeto A podría proporcionar al comerciante datos falsos y rea- lizar una compra fraudulenta.

Un tercero podría violar la computadora del comerciante robando el número de tarjeta de crédito de los clientes y hacer transacciones fraudule n- tas.

Un tercero podría entrar en la computadora del comerciante e in- troducir datos fraudulentos directamente en su base de datos de pedidos haciéndole creer de esta manera al sistema que ha realizado compras.

Un tercero podría alterar la base de datos del comerciante o su página Web o cualquier otro perjuicio imaginable para el comerciante.

Es por todo lo antedicho que la encriptación no es suficiente para asegu- rar una transacción en línea.

La criptografía en el comercio electrónico

A continuación se describen los protocolos criptográficos más utilizados para la protección de datos en las transacciones de comercio electrónico. Nos detendremos en detalle en el SSL y SET por considerarlos de mayor importa n- cia para los objetivos de este trabajo.

Protocolo de Nivel de conexiones seguro (SSL, Secure Sockets Layer)

Es un protocolo de criptografía que asegura la comunicación bidireccio- nal. Este protocolo se utiliza juntamente con TCP/IP 16. Ofrece confidencialidad mediante algoritmos de encriptación especificados por el usuario; integridad, mediante funciones hash17 criptográficas especificadas por el usuario, y no repudiación, mediante firma digital. La conexión SSL la inicia el cliente por medio de un prefijo especial en el URL; por ejemplo "https:" significa que se iniciará una conexión HTTP encriptada con SSL, mientras que "snews:" significa que se iniciará una conexión TNNP encriptada con SSL. [W-3] [W-9] El rasgo que distingue a SSL de otros protocolos para comunicaciones seguras, es que se ubica en la pila OSI, entre los niveles de transporte (TCP/IP) y de aplicación (donde se encuentran los conocidos protocolos HTTP para Web, FTP para transferencia de ficheros, SMTP para correo electrónico, Telnet para conexión a máquinas remotas, etc.) como puede observarse en la Figura T. Gracias a esta característica, SSL resulta muy flexible, ya que puede servir para asegurar potencialmente otros servicios además de HTTP para Web, sin más que hacer pequeñas modificaciones en el programa que utilice el protocolo de transporte de datos TCP.

Figura T.:Ubicación de SSL en la capa de transporte.

SSL proporciona sus servicios de seguridad cifrando los datos intercam- biados entre el servidor y el cliente y cifrando la clave mediante un algoritmo de cifrado de clave pública, típicamente el RSA. La clave de sesión es la que se utiliza para cifrar los datos que vienen del y van al servidor seguro. Se genera una clave de sesión distinta para cada transacción, lo cual permite que aunque sea rota por un atacante en una transacción dada, no sirva para descifrar futu- ras transacciones.

SSL ganó popularidad en principio porque se necesitaba servidores Web con facilidades criptográficas y un cliente gratuito que implemente los mismos protocolos. Si bien la iniciativa fue de Netscape fue incorporado rápidamente por otros servidores y navegadores Web convirtiéndose en el protocolo cripto- gráfico más popular de Internet.

SSL en el comercio electrónico

El propósito y el éxito de SSL es su transparencia para usuarios y des- arrolladores. Suponiendo que el servidor Web tenga facilidades criptográficas que soporten SSL y que el cliente esté accediendo con un navegador que re- conozca SSL (cualquiera de los navegadores popularmente difundidos), basta- rá reemplazar el "http" del URL por "https" de esta fo rma el cliente obtendrá de forma segura el contenido de la página y lo más importante, realizando este reemplazo al enviar información al servidor Web, se hará también de forma se- gura. Por ejemplo en un formulario CGI en lugar de poner :

el programador deberá poner La elección de algoritmos y longitudes de llaves la determinará el servi- dor SSL limitado por el cliente de acuerdo al intercambio de notas electrónicas antedichas.

Los navegadores muestran un pequeño icono cuando una página es descargada con SSL. En el Internet Explorer este icono es un candado que está cerrado si la página fue descargada con SSL y abierto de lo contrario o no aparece el candado, dependiendo de la versión. Lo graficamos en la Figura U.

Características de SSL

La encriptación y desencriptación no se repite para cada comuni- cación entre el cliente y el servidor, permitiendo que las nuevas conexiones SSL se inicien de inmediato aportando eficiencia al proceso.

Permite la autenticación tanto del cliente como del servidor mediante certificados digitales.

Aunque SSL fue diseñado para correr sobre TCP/IP, puede hacer- lo sobre cualquier protocolo confiable orientado a conexiones como X.2518 u OSI19.

Figura U.: Icono indicador de que la página usa un protocolo de encriptación para transfere ncia de datos.

Protege contra ataques conocidos como "hombre en el camino", explicado con anterioridad. Esto lo hace mediante certificados digitales para permitir al usuario de la Web conocer el nombre validado del sitio con el que se está conectando.

Disminuye notablemente la velocidad de transmisión de informa- ción. El desempeño se degrada, mayormente, en el inicio de la primera co- nexión ya que es cuando se produce la encriptación / desencriptación de la lla- ve pública. Debido a esto, muchas organizaciones tienden a encriptar sólo in- formación sensible, dejando la mayoría de la transacción vulnerable a un ata- que. Por ejemplo, al obrar de esta manera, un HTML no encriptado podría ser modificado por un programa de filtrado e inyección de paquetes que cambien el código del formulario HTML y en lugar de enviar el nro de tarjeta de crédito al servidor legal, lo haga a otro servidor en cualquier lado del mundo. Suponiendo que el pirata obtenga una identificación digital para su servidor SSL, sería muy difícil que un usuario engañado detecte la maniobra.

Es una capa entre el protocolo TCP/IP y la aplicación, que agrega a u- tenticación y no repudiación del servidor y autenticación, del cliente mediante firmas digitales.

Confidencialidad de los datos mediante encriptación.

Integridad de los datos mediante códigos de autenticación de mensajes.

Es extensible y adaptativo, condición necesaria ya que la cripto- grafía es un campo que se transforma con gran rapidez y los protocolos no fun- cionan a menos que ambas partes de la comunicación utilicen los mismos algo- ritmos. Cuando un programa intenta comunicarse con otro utiliza ndo SSL se intercambian notas electrónicas para determinar el protocolo criptográfico más fuerte que tienen en común.

Implementación del protocolo

Durante el protocolo SSL, el cliente y el servidor intercambian una serie de mensajes para negociar las mejoras de seguridad. Como mostramos en la Figura V.

Figura V.: Intercambio de mensajes cliente – servidor en el protocolo SSL.

Este protocolo sigue las siguientes fases:

La fase Hello, usada para ponerse de acuerdo sobre el conjunto de algoritmos para mantener la intimidad y para la autenticación. El navegador le informa al servidor de los algoritmos que posee disponibles. No rmalmente se utilizarán los más fuertes que se puedan acordar entre las dos partes. En fun- ción de las posibilidades criptográficas del navegador, el servidor elegirá un conjunto u otro de algoritmos con una cierta longitud de claves.

La fase de autenticación, en la que el servidor envía al navegador su certificado x.509v3 que contiene su clave pública y solicita a su vez al cliente su certificado X.509v3 (sólo si la aplicación exige la autenticación de cliente).

La fase de creación de clave de sesión, en la que el cliente envía al servidor una clave maestra a partir de la cual se generará la clave de sesión para cifrar los datos intercambiados posteriormente haciendo uso del algoritmo de cifrado simétrico acordado en la fase 1. El navegador envía cifrada esta cla- ve maestra usando la clave pública del servidor que extrajo de su certificado en la fase 2. Posteriormente, ambos generarán idénticas claves de sesión a partir de la clave maestra generada por el navegador.

La fase Fin, en la que se verifica mutuamente la autenticidad de las partes implicadas y que el canal seguro ha sido correctamente establecido. Una vez finalizada esta fase, ya se puede comenzar la sesión segura.

De ahí en adelante, durante la sesión segura abierta, SSL proporciona un canal de comunicaciones seguro entre los servidores Web y los clientes (los navegadores) a través del cual se intercambiará cifrada la información releva n- te, como el URL y los contenidos del documento solicitado, los contenidos de cualquier formulario enviado desde el navegador, las cookies enviadas desde el navegador al servidor y viceversa y los contenidos de las cabeceras HTTP.

El protocolo SSL se divide en dos capas complementarias

• Protocolo Handshake. Realiza las siguientes funciones:

Autenticación de usuario y servidor.

Selección de los parámetros de la sesión y de la conexión.

Establece la conexión segura.

• Protocolo de registro (Record protocol). Se utiliza para la encrip- tación de los protocolos de las capas más altas: Handshake y aplicaciones.

El protocolo SSL se comporta como una máquina de estados, durante el intercambio de información siempre hay un estado de escritura activo y otro pendiente. Entre dos entidades cliente y servidor se pueden abrir varias sesio- nes SSL, aunque no es habitual, y dentro de cada sesión se pueden mantener varias conexiones SSL. Las conexiones se abren o cierran a través del protoco- lo de Handshake.

Evaluación del protocolo

Si bien SSL provee un enfoque práctico y fácil de implementar, no ofrece una solución comercialmente integrada ni totalmente segura. A medida que el comercio crece, esta arquitectura podría llegar a resultar difícil de expandir o de incorporar nuevas tecnologías y componentes a medida que vayan aparecien- do. Existen una serie de desventajas al utilizar exclusivamente SSL para llevar adelante ventas por Internet:

SSL ofrece un canal seguro para el envío de números de tarjeta de crédito, pero carece de capacidad para completar el resto del proceso co- mercial: verificar la validez del número de tarjeta recibido, autorizar la transac- ción con el banco del cliente, y procesar el resto de la operación con el banco adquiriente y emisor.

Es importante recalcar que SSL sólo garantiza la confidencialidad e integridad de los datos en tránsito, ni antes ni después. Por lo tanto, si se en- vían datos personales al servidor, entre ellos el ya citado número de tarjeta de crédito, el número de la seguridad social, el DNI, etc., SSL solamente asegura que mientras viajan desde el navegador hasta el servidor no serán modificados ni espiados. Lo que el servidor haga con ellos, está ya más allá de la compe- tencia de este protocolo. Los datos podrían ser manipulados irresponsablemen- te o caer en manos de un atacante que asaltara el servidor con éxito.

SSL permite realizar ataques sobre servidores de comercio crea- dos de forma poco confiable, para averiguar números de tarjeta reales. Un pro- grama escrito por un hacker va probando números de tarjeta válidos, pero que no se sabe si corresponden o no a cuentas reales, realizando compras ficticias en numerosos servidores. Si el número de tarjeta no sirve, el servidor devuelve un error, mientras que si es auténtico, el servidor lo acepta. El programa ento n- ces cancela la compra y registra el número averiguado, para seguir adelante con el proceso. De esta forma, el hacker puede hacerse en breve con cientos de números a uténticos.

Permite ataques a la versión del protocolo. Las nuevas versiones del protocolo van siendo mucho más seguras que las anteriores, por lo que un ataque común es hacer que los browsers y servidores que soportan SSL crean que deben utilizar versiones anteriores de SSL por cuestiones de compatibili- dad. Esto puede lograse mediante una intercepción en el handshake: El servi- dor "cree" que el cliente sólo soporta una versión anterior de SSL y utilizará este protocolo para encriptar los datos. Tomando todas las debilidades de esa versión.

SSL, también es permeable a ataques al algoritmo de encripta- ción. De forma similar que en el caso anterior, un atacante podría intervenir el handshake para forzar a ambas parte a utilizar un algoritmo de encriptación menos seguro o con una clave con pocos bits (que permite quebrar la seguri- dad fácilmente). Por suerte, este tipo de ataque puede ser detectado con téc- nicas especificas.

Ataque de "Hombre en el camino": Ciertas versiones de SSL utili- zan el método de encriptación Diffie-Hellman (DH) que es vulnerable a este tipo de ataques, por lo que no se recomienda su utilización bajo ninguna circuns- tancia.

Todos estos inconvenientes convierten a SSL en una solución deficiente desde el punto de vista del pago electrónico, lo cual no significa que no se deba utilizar ni que no sea útil en otras muchas facetas igualmente necesarias de la actividad empresarial. Al proporcionar un canal seguro de comunicaciones, el comerciante puede ofrecer al cliente de manera confidencial una serie de servicios para estrechar las relaciones de confianza: autenticación del cliente frente al comercio, trato personalizado, evitar que terceras partes espíen las compras de los clientes, intercambio de información privada, etc. Dado que SSL es un protocolo seguro de propósito general, que no fue diseñado para el comercio en particular, se hace necesaria la existencia de un protocolo específico para el pago. Este protocolo existe y se conoce como SET.

Protocolo de Transacciones Electrónicas Seguras (SET, Secure Electronic Transactions)

Este protocolo criptográfico ha sido diseñado especialmente para el en- vío de números de tarjetas de crédito por Internet. Consta de tres partes: una "billetera electrónica" que reside en la computadora del usuario; un servidor que se ejecuta en el sitio Web del comerciante; y un servicio de pagos SET que se ejecuta en el banco del comerciante. Para utilizar este sistema el usuario intro- duce su número de tarjeta de crédito en el software de billetera electrónica, el cual se almacena encriptado en el disco duro; se crea también una llave públi- ca y una privada para encriptar la información financiera antes de enviarla a través de Internet. Cuando un usuario desea comprar algo, su número de tarje- ta de crédito es enviado encriptado al comerciante quien firma digitalmente el mensaje de pago y lo envía al banco, donde el servidor de pagos desencripta la información y realiza el cargo a la tarjeta. [W-4]

Características de SET

El número de tarjeta de crédito pasa encriptado por las manos del comerciante disminuyendo enormemente las posibilidades de fraude, ya que, pese al imaginario popular, en su mayoría los fraudes con tarjetas de crédito en todo el mundo se deben más a los comerciantes y sus empleados que a los "maliciosos" hackers que aguardan agazapados detrás de nuestra computado- ra con el único fin de robarnos. Esta es su principal ventaja.

Encripta los números de tarjetas de crédito mediante el algoritmo RSA, brindando confidencialidad, proporciona además integridad, autenticación y no repudiación mediante funciones de compendio de mensajes y firmas digi- tales. Sin embargo SET protege sólo el número de tarjeta de crédito no bri n- dando confidencialidad y privacía a los demás elementos de la transacción.

Es un protocolo estandarizado y respaldado por la industria, dise- ñado para salvaguardar las compras pagadas con tarjeta a través de redes abiertas, incluyendo Internet. El estándar SET fue desarrollado en 1995 por Visa y MasterCard, con la colaboración de otras compañías líderes en el mer- cado de las tecnologías de la información, como Microsoft, IBM, Netscape, RSA, VeriSign y otras.

Todas las partes implicadas en la transacción económica (el clien- te, el comerciante y los bancos, emisor y adquiriente) pueden autenticarse mu- tuamente mediante certificados digitales. De esta forma, el comerciante puede asegurarse de la identidad del titular de la tarjeta y el cliente, de la identidad del comerciante. Se evitan así fraudes debidos a usos ilícitos de tarjetas y a falsifi- caciones de comercios en Internet imitando grandes Web comerciales. Por su parte, los bancos pueden verificar así las identidades del titular y del comer- ciante.

La información de pago se cifra para que no pueda ser espiada. Es decir, solamente el número de tarjeta de crédito es cifrado por SET, de ma- nera que ni siquiera el comerciante llegará a verlo, para prevenir fraudes. Si se quiere cifrar el resto de datos de la compra, como por ejemplo qué artículos se han comprado, debe recurrirse a un protocolo de nivel inferior como SSL.

Garantiza que la información intercambiada no podrá ser alterada de manera accidental o maliciosa mientras viaja a través de la red. Para lograr- lo se utilizan algoritmos de firma digital.

Gestiona tareas asociadas a la actividad comercial de gran impor- tancia como registro del titular y del comerciante, autorizaciones y liquidaciones de pagos, anulaciones, etc.

Implementación del protocolo

El pago mediante tarjeta es un proceso complejo en el cual se ven impli- cadas varias entidades, graficadas en la Figura W.

• Comprador: Adquiere un producto utilizando la tarjeta de crédito de su propiedad.

• Banco o entidad financiera: Emite la tarjeta de crédito del comprador.

• Comerciante: Vende los productos.

• Banco del comerciante: Banco donde el comerciante tiene la cuenta.

• Pasarela de pagos: Gestiona la interacción con los bancos. Puede ser una entidad independiente o el mismo banco del comerciante.

Dos agentes relacionados pero que no actúan directamente en las tran- sacciones son:

• Propietario de la marca de la tarjeta: Avalan las tarjetas: Visa, Mas- terCard, American Expres, etc…

• Autoridad de certificación: Crea los certificados que se utilizan en las

transacciones de la pasarela, el vendedor y el comprador. Pueden ser los ban- cos, los propietarios de la marca de la tarjeta o entidades independientes.

Para poder utilizar el SET se deben incorporar unos módulos de softwa- re que adaptan los programas existentes al protocolo. Se han definido 4 módu- los:

• Cartera: Es una aplicación que se instala en el navegador del compra- dor como plug-in.

• De venta: Se conecta a la Web del vendedor, similar a un Punto de

Venta (POS, Point Of Sale) para tarjetas de crédito.

• Pasarela de pagos: Cumple las funciones de este agente.

• Autoridad de certificación: Crea certificados de clave pública adapta- dos al estándar SET.

Una transacción SET típica funciona de forma muy parecida a una tran- sacción convencional con tarjeta de crédito y consta de los siguientes pasos:

• Decisión de compra del cliente. El cliente está navegando por el sitio web del comerciante y decide comprar un artículo. Para ello llenará algún formulario a tal efecto y posiblemente hará uso de alguna aplicación de carrito de compras, para ir almacenando diversos artículos y pagarlos todos al final. El protocolo SET se inicia cua ndo el comprador pulsa el botón de Pagar.

• Arranque del monedero. El servidor del comerciante envía una descripción del pedido que despierta a la aplicación monedero del cliente.

• El cliente comprueba el pedido y transmite una orden de pago de vuelta al comerciante. La aplicación monedero crea dos mensajes que envía al comerciante. El primero, con la información del pedido; el segundo con las ins- trucciones de pago del cliente (número de tarjeta de crédito, banco emisor, etc.) para el banco adquiriente. En este momento, el software monedero del cliente genera un firma dual, que permite juntar en un solo mensaje la información del pedido y las instrucciones de pago, de manera que el comerciante puede acce- der a la información del pedido, pero no a las instrucciones de pago, mientras que el banco puede acceder a las instrucciones de pago, pero no a la informa- ción del pedido. Este mecanismo reduce el riesgo de fraude y abuso, ya que ni

el comerciante llega a conocer el número de tarjeta de crédito empleado por el comprador, ni el banco se entera de los hábitos de compra de su cliente.

• El comerciante envía la petición de pago a su banco. El software

SET en el servidor del comerciante crea una petición de autorización que envía a la pasarela de pagos, incluyendo el importe a ser autorizado, el identificador de la transacción y otra información relevante acerca de la misma, todo ello convenientemente cifrado y firmado. Ento nces se envían al banco adquiriente la petición de autorización junto con las instrucciones de pago (que el comer- ciante no puede examinar, ya que van cifradas con la clave pública del adqui- riente).

• El banco adquiriente valida al cliente y al comerciante y obtiene una autorización del banco emisor del cliente. El banco del comerciante desci- fra y verifica la petición de autorización. Si el proceso tiene éxito, obtiene a con- tinuación las instrucciones de pago del cliente, que verifica a su vez, para ase- gurarse de la identidad del titular de la tarjeta y de la integridad de los datos. Se comprueban los identificadores de la transacción en curso (el enviado por el comerciante y el codificado en las instrucciones de pago) y, si todo es correcto, se formatea y envía una petición de autorización al banco emisor del cliente a través de la red de medios de pago convencional.

• El emisor autoriza el pago. El banco emisor verifica todos los da- tos de la petición y si todo está en orden y el titular de la tarjeta posee crédito, autoriza la transacción.

• El adquiriente envía al comerciante un testigo de transferencia de fondos. En cuanto el banco del comerciante recibe una respuesta de autoriza- ción del banco emisor, genera y firma digitalmente un mensaje de respuesta de autorización que envía a la pasarela de pagos, convenientemente cifrada, la cual se la hace llegar al comerciante.

• El comerciante envía un recibo al monedero del cliente. Cuando el comerciante recibe la respuesta de autorización de su banco, verifica las firmas digitales y la información para asegurarse de que todo está en orden. El softwa- re del servidor almacena la autorización y el testigo de transferencia de fondos. A continuación completa el procesamiento del pedido del titular de la tarjeta, enviando la mercancía o suministrando los servicios pagados.

• El comerciante usa el testigo de transferencia de fondos para co- brar el importe de la transacción. Después de haber completado el procesa- miento del pedido del titular de la tarjeta, el software del comerciante genera una petición de transferencia a su banco, confirmando la realización con éxito de la venta. Como consecuencia, se produce el abono en la cuenta del comer- ciante.

A su debido tiempo, el dinero se descuenta de la cuenta del cliente (car- go).

El protocolo definido por SET especifica el formato de los mensajes, las codificaciones y las operaciones criptográficas que deben usarse. No requiere un método particular de transporte, de manera que los mensajes SET pueden transportarse sobre HTTP en aplicaciones Web, sobre correo electrónico o cualquier otro método. Como los mensajes no necesitan transmitirse en tiempo real, se puede realizar implementaciones basadas en correo electrónico u otros sistemas asíncronos.

Otros protocolos para asegurar la información en tránsito

A continuación, enunciamos un conjunto de protocolos que si bien son menos utilizados en el comercio electrónico tienen aplicabilidad.

Protocolo Privacía Bastante Segura (PGP, Pretty Good Priva- cy): es un sistema de encriptación híbrido que utiliza encriptación de llave pú- blica RSA para la administración de llaves y un código simétrico para la encrip- tación de datos. PGP es un desarrollo de PGP Inc que comercializa este pro- ducto como un programa integrado de correo electrónico o como un agregado para los sistemas de correo más populares, permitiendo enviar y recibir mensa- jes encriptados con PGP. PGP tiene problemas en la administración y certifica- ción de sus llaves públicas ya que las mismas nunca expiran; la habilidad de PGP para certificar la identidad en forma confiable es muy limitada ya que no tiene una infraestructura de llaves públicas para validar la autenticidad de las llaves.

Protocolo de Extensiones Multipropósito de Correo de Inter- net Seguro (S/MIME, Secure Multipurpose Internet Mail Extensions): este sistema ofrece confidencialidad mediante algoritmos de encriptación especifi- cados por el usuario, integridad mediante una función de hash, autenticación mediante certificado de llave pública X.509 v3 y no repudiación mediante firma digital. Para enviar un correo electrónico encriptado con S/MIME es necesario tener una copia de sus llaves privadas, las que se pueden obtener en VeriSign y otras autoridades certificadoras. Se espera que los sistemas de correo elec- trónico adopten S/MIME en lugar de PGP debido a que las principales empre- sas ya tienen una relación de negocios con RSA que es la autora de este sis- tema de encriptación.

Protocolo de Seguridad de Capa de Transporte (TSL, Trans- port Secure Layer): Intento de estandarización de protocolos de seguridad en la capa de transporte muy similar a SSL 3.0.

Protocolo de Tecnología de Comunicaciones Seguras (PCT, Private Communications Technology): Es un protocolo de seguridad de ni- vel de transporte similar a SSL pero propietario de Microsoft que surgió como respuesta a problemas asociados con SSL 2.0 que fueron luego corregidos en la versión SSL 3.0; si bien Microsoft soporta SSL, continúa manteniendo PCT por cuestiones políticas.

Protocolo de HTTP Seguro (S-HTTP, Secure HTTP): Es un sis- tema para firmar y encriptar información enviada mediante el protocolo HTTP.

Este sistema es precursor de SSL y actualmente cae en desuso al verse reem- plazado por el mismo. Fue desarrollado por Tecnologías de Integración Empre- sarial (EIT, Enterprise Integration Technologies).

Permite el intercambio seguro de archivos en la Web, mediante el en- criptado y la certificación digital. La mayor diferencia con SSL es que el servidor solamente es autenticado mientras que en este protocolo el cliente también envía un certificado.

La implementación se realiza a través de la extensión de las cabeceras HTTP. En el momento que se establece la conexión para enviar el archivo se acuerda el sistema a utilizar.

Generalmente un mensaje S-HTTP consiste de tres partes:

• El mensaje HTTP

• Las preferencias criptográficas del emisor

• Las preferencias criptográficas del receptor

La desventaja esencial de este protocolo es que el envío de certificados / autenticación debe realizarse por cada archivo que se desea transmitir, lo que puede producir una sobrecarga de transacciones en el servidor si se envían muchos archivos seguros por conexión, además de que la implementación de aplicaciones de comercio electrónico es mucho más compleja ya que deben considerarse aspectos como certificados de cliente, método de encriptación a utilizar, etc.

Protocolo de Kerberos: Sistema de seguridad de red desarrolla- do por el MIT (Instituto de Tecnología de Massachussets, Massachusetts Insti- tute of Technology). A diferencia de los otros sistemas mencionados no posee tecnología de llaves públicas ya que en el momento en que se lo desarrolló (1985) los procesadores eran muy lentos y no soportaban la encriptación y desencriptación por medio de llaves públicas. Este sistema se basa en códigos simétrico y en secretos compartidos entre el servidor Kerberos y cada usuario quien tiene su propia clave de acceso. El servidor Kerberos encripta los mensa- jes enviados por el usuario de forma que no puedan leerlos nadie más. Es un sistema difícil de configurar y de administrar y que no cuadra con los actuales estándares de seguridad. Aunque se encuentra bastante generalizado en los servicios Telnet, FTP, POP y RPC.

Protocolo de Interprete de Comandos Seguro (SSH, Secure Shell): Es un protocolo de terminal remota encriptada.

Seguridad del Sistema de Nombre de Dominio (DNSSEC, Do- main Name System Security):Proporciona seguridad al sistema de nombres de dominio de Internet

Protocolo de Internet Seguro (IPsec, Internet Protocol Secu- re): Protocolo de bajo nivel para encriptar paquetes IP utilizado para crear re- des virtuales privadas a través de Internet.

Como proteger un sitio Web

La seguridad en la Web comienza por la computadora donde se ejecuta el servidor Web. No se puede construir una receta genérica de como debería ser un sitio seguro, en lugar de eso, analizaremos los problemas más comunes de seguridad que afectan a Internet y las prácticas que permiten aumentar la seguridad, para luego describir las arquitecturas de servidores Web que redu- cen los riesgos.



Sorprendentemente, los problemas de Internet identificados por los pio- neros, siguen siendo los más comunes [L-9]. En 1973 Bob Metcalfe, escribió la RFC 602 (Solicitud de comentarios, Request For Comments, informes elabora- dos por el grupo de trabajo de redes ARPA). En este documento, transcripto en la Figura X se identifican tres problemas de la red de aquella época:

Los sitios no estaban asegurados contra ingresos remotos.

Había gente no autorizada utilizando la red.

Algunos malhechores irrumpían en las computadoras y en oca- siones bajaban los sistemas sólo por diversión.

La mayoría de estos problemas de seguridad identificados en 1973 per- duran hoy en nuestros días:

Muchos sitios de Internet aun no aseguran sus servidores contra ataques externos.

Los usuarios continúan eligiendo claves sencillas de deducir con la dificultad de que ahora existen programas que pueden montar un ataque de adivinación de claves probando miles de claves en unos segundos

Algunos individuos aun derriban sistemas por diversión, y lo se- guirán haciendo, pero hay que agregar que otros lo hacen para obtener impor- tantes beneficios financieros. El problema mencionado por Metcalfe de los ac- cesos no autorizados por módems irrestrictos, no se solucionó pero cambio de forma. Para ingresar a la red hoy es necesario un nombre de usuario y contra- seña provistos por un proveedor oficial, pero su obtención es muy sencilla y hasta gratuita en muchos casos.

RFC 602

Grupo de trabajo de redes ARPA Bob Metcalfe (PARC-MAXC) Solicitud de comentarios 602 DIC 1973 NIC #21021

Las medias estaban cuidadosamente colgadas junto a la chimenea20

La red de computadotas ARPA es susceptible a violaciones de seguridad por lo menos por las tres siguientes razones:

• Los sitios individuales, acostumbrados a las restricciones físicas sobre el acce- so de las máquinas, aún no ha tomado suficientes precauciones para asegurar sus sistemas contra el uso remoto no autorizado. Por ejemplo, muchos usuarios aún utilizan claves de acce- so fáciles de adivinar: sus nombres de pila, sus iniciales, el nombre de la máquina deletreado a la inversa, una cadena de caracteres fáciles de teclear en secuencia (por ejemplo, ZXCVBNM).

• El TIP21 permite el acceso a ARPANET a un público mucho mayor del supues- to o deseable. Los números de teléfono de los TIP son enviados a grupos de discusión, como si estuvieran garabateados en paredes de casetas telefónicas y baños de hombres. El TIP no requiere ninguna identificación del usuario antes de dar servicio. Por ello, muchas personas, incluidos quienes solían desperdiciar su tiempo robando a la compañía telefónica, obtienen acceso a nuestra media: en forma extremadamente anónima.

• Existe una tendencia innata en algunas personas a romper el sistema de al- guien. Esta tendencia permanece a pesar de que es bien sabido que es fácil quebrantar siste- mas –y aún más fácil tirarlos-.

Todo esto sería bastante gracioso y causa de guiños de ojo y codeos si no fuera por el hecho de que hace poco fueron tiradas por lo menos dos máquinas servidoras principales bajo circunstancias sospechosas, por personas que sabían a que se arriesgaban; en un tercer sis- tema se divulgó la clave de acceso de Súper Usuario –nada menos que por dos estudiantes de bachillerato de Los Ángeles -.

Sospechamos que el número de violaciones peligrosas a la seguridad es mayor de lo que ninguno de nosotros cree y que está creciendo. Por ello hay que recomendar no sentarse "en espera de que llegue Santa Claus".

RMV: mv

Figura X.: Trascripción de la RFC 602

Prácticas que permiten aumentar la seguridad

Aunque es imposible protegerse contra todas las amenazas existen mé- todos muy difundidos en la Internet actual, que hacen que la seguridad del ser- vidor sea menos vulnerable. A continuación se tratan algunos de ellos.

Definir políticas en tiempo de diseño

La seguridad se define mediante políticas. Las mismas no son una rece- ta aplicable a todas las empresas por igual ya que dependerán de los tipos de datos que manejan los sistemas de información. Así en algunos ambientes cualquier usuario puede acceder a los servidores Web e instalar o modificar cualquier página, apagar o reinicializar el sistema mientras que en otros am- bientes sólo algunos usuarios podrán acceder con permiso de sólo lectura a algunas páginas y si desearan modificar un archivo necesitarán una autoriza- ción firmada por el director del área de sistemas. Estas son distintas políticas.

Las políticas de seguridad son un tema complejo, su función es guiar a los usuarios hacia el conocimiento de las acciones permitidas y a la elección en cuanto a la configuración y uso del sistema. [E-1] En el momento de crear una política de seguridad, los administradores deberían hacerse las siguientes preguntas:

¿Quiénes tendrán acceso?

¿Qué tipos de accesos se otorgarán?

¿Quién autorizará los accesos? ??????¿Quién será el responsable de la seguridad, de las actualizacio- nes, de los respaldos y del mantenimiento?

¿Qué tipo de material es permitido en las páginas? ???¿A qué sitios y usuarios externos se les permitirá acceso a las páginas e información? ????¿Qué tipos de pruebas y evaluaciones deben hacerse al software antes de instalarlo? ???¿Cómo se manejarán las incidencias acerca del servidor y de la información?

¿Cómo se reaccionará ante un incidente de seguridad?

¿Cómo y cuándo debe actualizarse la política? ???¿Quién es el representante ante miembros externos a la organi- zación ante un incidente de seguridad?

Ante una falla, ¿se seguirá brindando servicio? ???¿Se tomará el criterio de negación preestablecida (lo que no está permitido está expresamente prohibido) o de permiso preestablecido (lo que no está prohibido expresamente está permitido)? Las políticas de seguridad deben estar al alcance y disposición de todas las personas asociadas a la organización y en algunos casos es aconsejable difundirlas externamente para generar confianza en los usuarios exter- nos.

Si se pone especial cuidado en el desarrollo de las políticas es posible evitar muchos problemas potenciales. Pero para constituir las políticas de segu- ridad se debe ir contra la cultura de muchas organizaciones que ponderan el hacer sobre el planificar. Para cambiar esta situación se debe comprender la importancia de los planes y los beneficios en tiempo, costo y calidad de los procesos planificados sobre los improvisados. No es fácil pero nunca debemos perder de vista que una organización es la suma de los miembros que la com- ponen.

Prevenir la intercepción de claves de acceso

El envío de claves de acceso reutilizables en texto llano a través de re- des internas y externas, es tal vez el riesgo de seguridad más importante que se corre en Internet. Por ejemplo al utilizar el servicio FTP para actualizar pági- nas Web, el nombre de usuario y la clave viajan por la red sin ser encriptados de modo de que si alguien está monitoreando la red obtendrá acceso al servi- dor ya que la clave es reutilizable hasta que el propietario la cambie.

La única forma de prevenirse contra la intercepción de claves es no en- viar las mismas en texto llano y que las mismas no sean reutilizables.

Utilizar herramientas de seguridad

Son programas que se utilizan para evaluar o mejorar la seguridad de un sitio. Las podemos dividir en cuatro categorías:

Herramientas de instantánea: estos sistemas toman una foto del servidor y buscan debilidades potenciales notificándolas a la persona que la ejecuta, se caracterizan por hacer muchas revisiones en poco tiempo. También se las conoce como herramienta de auditoría estática. Estos programas deben ejecutarse con regularidad y se debe evaluar con mucho cuidado la salida que producen, ya que en ellos se pueden encontrar los agujeros de seguridad del sistema.

Herramientas de detección de cambios no autorizados: cuan- do un atacante ingresa en un sitio restringido lo primero que suele hacer es crear puertas traseras que le faciliten futuros ingresos al sistema y también modificar el mismo para ocultar evidencia de intrusión. Dejando a su paso cambios no autorizados en el sistema. El hecho de encontrar estos cambios no evita la irrupción pero puede indicar que el sistema ha sido violado.

Herramientas que escudriñan la red, buscando debilidades en ella: estas herramientas buscan errores de programación conocidos relaciona- dos con la seguridad. Es sabido que los crackers escudriñan la red con estas herramientas, así que lo mejor es utilizar uno mismo estos programas para mantenerse consciente de las falencias de nuestro sistema.

Herramientas que monitorean el sistema y la red buscando ataques en progreso: estas herramientas funcionan como alarma antirrobo registrando la computadora mientras opera, en busca de señales de una irrup- ción.

Evitar fallas y errores de programación

"La mayoría de los problemas de seguridad son errores o trampas de progra- mación." [L-9] Una de las cosas más peligrosas que se puede hacer estando conecta- do a Internet es descargar y ejecutar un programa ya que la mayoría de los sistemas operativos no controla lo que un programa puede hacer una vez que se está ejecutando. Por lo tanto al ejecutar un programa descargado de Inter- net ponemos toda nuestra computadora y hasta nuestra red en manos del autor del programa. Aunque la mayoría de estos programas se comportan como se espera; muchos tienen errores de programación, son hostiles, buscan la infor- mación almacenada y la transmiten a algún lugar de Internet o realizan algún otro tipo de fraude.

Es imposible determinar lo que hará un programa antes de ejecutarlo y a veces es imposible determinar qué ha hecho un programa después de ejecutar- lo, ni siquiera NT, W2K o UNIX que son sistemas operativos con extensos mecanismos de seguridad, ofrecen a los usuarios una seguridad real contra los programas descargados y ejecutados ya que una vez que se corre el programa éste hereda todos los privilegios y derechos de acceso del usuario que lo ha invocado y la mayoría de los usuarios de Internet descargan y ejecutan pro- gramas como una tarea diaria.

Los atacantes buscan hurgar documentos confidenciales para transmitir- los a otros sistemas, dañar la información o el hardware del usuario, crear agu- jeros en la seguridad de los sistemas, realizar fraudes.

Mediante aplicaciones auxiliares es posible extender las funciones del navegador. Estas brindan una forma flexible y extensible de mostrar la informa- ción, pero también pueden crear problemas de seguridad.

Existen también varios lenguajes de programación (Java, JavaScript, Vi- sual Basic Script) que se utilizan para escribir programas que se incluyen en las páginas Web para descargarse en el navegador del usuario y ejecutarse en su máquina los cuales también crean problemas de seguridad.

El 5 de julio de 2002 la compañía Euro Trust 112 difundió el descubri- miento de un agujero de seguridad que afecta a todas las versiones del nave- gador Internet Explorer de Microsoft [L-9]. Debido a esta vulnerabilidad, al pre- sionar la tecla 'Ctrl' mientras se navega por Internet se corre el riesgo de que intrusos bajen contenidos de la computadora del usuario. Internet Explorer po- sibilita al usuario para usar la tecla 'Ctrl' en combinación con otras para ejecutar funciones de uso corriente, al igual que sucede con otros programas. Así, para imprimir una página se puede presionar 'Ctrl+P' y para abrir una nueva ventaja se puede hacer lo propio con 'Ctrl+N'. El agujero se produce por un 'script'22 en una página HTML, que se puede ejecutar con menos restricciones que lo nor- mal, al inducir al usuario a iniciarlo presionando la tecla 'Ctrl'. De este modo, el 'script' puede ser usado para acceder al disco ríg ido de la víctima, sin que ésta sospeche lo que está ocurriendo. Según Euro Trust 112, Microsoft señaló que el problema descripto no le compete según su política de seguridad, por lo que no tiene contemplado crear un parche o código reparador para su navegador. 23

A continuación se enumeran algunos factores a tener en cuenta a la hora de comprar software:

La reputación del proveedor en producir software exento de erro- res y bien documentado.

Si el proveedor responde en forma oportuna y abierta a reportes de fallas de seguridad relativas a sus productos.

Pruebas de buenas prácticas de ingeniería de software en el di- seño, codificación y evaluación.

Documentación de pruebas relativas a la seguridad.

Políticas de respuesta a fallas en el producto del proveedor.

Garantía de notificación a los clientes de fallas de seguridad des- cubiertas en sus productos.

Cuando una falla de seguridad o error de programación es descubierto en un sistema comercial suele enviarse rápidamente la información por todo el mundo por lo tanto el administrador de un servidor debe leer todos los boletines emitidos por los proveedores e instalar parches tan pronto como estén disponi- bles ya que es posible que un atacante pueda enterarse de que la puerta está sin llave antes que el dueño de la casa. Existen grupos de correo para mantenerse informado de fallas y correcciones en los sistemas, estos foros se llaman FIRST (Foro de Equipos de Respuesta a Incidentes y Seguridad, Forum of Incident Response and Security Teams) para suscribirse a algunos de ellos se debe enviar, por ejemplo un mail en blanco a nt-security@iss.net o fire- walls@greatcircle.com.

Antes de instalar un parche, debe asegurarse de que el mismo es auté n- tico, esto es posible gracias a la firma digital. Ya que al instalarlos, si no son auténticos, corremos el riesgo de agregar vulnerabilidad.

Una tecnología de firma digital de código, como el Authenticode, permite saber si el programa fue escrito por quien dice ser, de forma que podemos de- cidir en que firmas confiamos y el navegador las bajará automáticamente mien- tras que si en una firma no confiamos no se instalará el programa.

No todos los programas tienen las mismas implicancias de seguridad ya que los mismos pueden estar compilados en código de máquina nativo, el cual se descarga y ejecuta en la máquina del cliente o pueden estar en código byte de Java y ser ejecutado dentro de una máquina virtual.

Para los programas distribuidos como código de máquina la firma de Authenticode se utiliza para decidir si se descarga o no el control, en el caso de los distribuidos como código de byte de Java también puede usarse para de- terminar qué permiso de acceso se le otorga al ejecutable.

Si una página posee código de máquina y de Java el acceso controlado por capacidades que permite el sistema de Java se anula. Las firmas de Aut- henticode sólo se verifican al descargar el control de la red con un mensaje como el de la Figura Y. Una vez instalado el control en el disco duro tiene ac- ceso irrestricto.



Figura Y.: Mensaje de advertencia cuando no se ha encontrado la firma Authenticode de un soft que se está instalando desde Internet.

La seguridad mediante firma de código tiene muchos problemas, alg u- nos de ellos son los siguientes:

Los rastros de auditoría pueden ser borrados por los mismos pro- gramas.

El daño causado puede no ser visible de inmediato.

El Authenticode no protege al usuario contra errores de progra- mación ni contra virus, ni contra el uso incorrecto de programas benignos.

Las rutinas de validación que utiliza el sistema Authenticode es vulnerable.

Puede ser difícil o imposible reconstruir un ataque después de ocurrido.

A continuación se enumeran reglas generales para la codificación segu- ra de programas que deben ser tenidas en cuenta por los desarrolladores de sitios web de comercio electrónico:

• Diseño: Se debe comprender claramente lo que se intenta cons- truir, considerar el ambiente en que se ejecutará, el comportamiento de entrada y salida, los archivos utilizados, los parámetros reconocidos. Utilizar herramien- tas adecuadas de diseño y procesos de calidad. Hace no mucho tiempo, el hi n- capié puesto en el diseño era mínimo. Los recursos fuertes de un proyecto eran puestos en la codificación. Hoy la visión ha cambiado de forma diametral, y el diseño y la arquitectura de un proyecto conforma su parte esencial.

• Verificar los valores proporcionados por el usuario: la mayo-

ría de errores de seguridad ocurren cuando el programa recibe un valor o for- mato inesperado. Esto es evitable verificando los parámetros. Se debe prestar especial atención en el filtrado a que los caracteres sean los adecuados, la longitud sea la permitida y que el valor sea legal.

• Verificar los parámetros enviados al sistema operativo: como

se explicó anteriormente al darle acceso al sistema operativo al usuario se de- be tener especial cuidado de que las funciones ejecutadas sean las que se es- peran.

• Verificar los códigos de retorno del sistema operativo: cuando

una llamada al sistema operativo falla se debe registrar en una bitácora el valor inesperado, proporcionando una salida limpia.

• Incluir código de verificación de consistencia interna: si una variable dentro de un programa sólo se supone que tome una número finito de valores, se debe comprobar que así sea, generando un error en caso contrario.

• Incluir mucha información en las bitácoras: es mejor que sobre

información y no que falte, además de la bitácora del servidor Web se deben reportar los errores en bitácoras dedicadas a cada sistema, esto facilitará la localización de problemas.

• Dividir el programa: la modularidad y unicidad van asociadas a

la simplicidad y facilidad de mantenimiento y detección de errores. "Divide y vencerás"

• Atacar el código: debe pensar como un atacante y buscar las fa-

llas de seguridad que un atacante buscaría.

9. Probar el programa a profundidad.

• No confiar demasiado en al dirección IP de origen de los pa- quetes ya que la misma puede ser falsificada o alterada.

• Imponer límite de tiempo de ejecución: si el programa rebasa éstos tiempos es posible que esté bloqueado.

• No utilizar nombre de usuario y clave de acceso en texto lla- no: si se emplea esta manera de autenticación debe hacerse con facilidades criptográficas.

En 1975 Jerome Saltzer y M. D. Schroeder describieron siete criterios para construir sistemas de cómputos seguros, los cuales son notables aún hoy. Los mismos aparecen entre los procedimientos del Instituto de Ingenieros Elec- tricistas y Electrónicos (IEEE, Institute of Electrical and Electronics Engineers) bajo el nombre de "La Protección de Información en los Sistemas de Cómpu- tos" (The Protection of Information in Computer Systems) que transcribimos a continuación [L-9]

• Mínimo privilegio: cada usuario y proceso debe tener el conjunto mínimo necesario de derecho de acceso. El mínimo privilegio limita el daño que

puedan causar tanto los atacantes como los errores. Los derechos de acceso deben solicitarse explícitamente, no otorgándose de manera preestablecida.

• Economía de mecanismo: el diseño del sistema debe ser pequeño y sencillo, de forma que pueda revisarse e implementarse correctamente.

• Mediación completa: en todo acceso se debe verificar la autoriza-

ción adecuada.

• Diseño abierto: la seguridad no debe depender de la ignorancia del atacante. Este criterio evita las puertas traseras en el sistema, las cuales otor- gan acceso a quienes las conocen.

• Separación de privilegios: siempre que sea posible, el acceso a los recursos del sistema debe depender de satisfacer más de una condición.

• Mecanismo de mínimo común: el sistema debe aislar a unos usua-

rios de otros. Esto limita tanto el monitoreo encubierto como los esfuerzos co- operativos para saltar los mecanismos de seguridad del sistema.

• Aceptabilidad psicológica: los controles de seguridad deben ser fáciles de utilizar de forma de que en verdad se usen y no sean pasados de largo.

Utilizar Firewalls

El firewall es un dispositivo que aísla una red interna del resto de Inte r- net, permitiendo pasar conexiones específicas y aislando otras. Si bien los fire- walls son parte de la estrategia global de seguridad de una organización no deben tomarse como la única, debe emplearse sólo para obtener seguridad adicional junto con controles internos, ya que el mismo no protege de ataques internos. [L-5] [L-8] Existen tres formas de proteger la red interna de ataques externos me- diante un firewall:

• Colocar el servidor Web fuera del firewall. (Figura Z)

En caso que el servidor sea violado el atacante no podrá ingresar al re- sto de la red. Por otro lado el servidor Web no cuenta con la protección del fi- rewall.

• Colocar el servidor dentro del firewal. (Figura AA)

De esta forma se evita que los usuarios externos utilicen servicios para los que no están autorizados, pero si se logra subvertir el servidor mediante un ataque se tiene acceso completo a la red interna.

• Colocar el servidor entre dos firewalls. (Figura BB)

Combina las ventajas de los dos sistemas anteriores pero también las restricciones a los servicios.



Figura Z.: Servidor Web fuera del firewall.

Los firewalls protegen los datos aportando a su confidencialidad (evitan que los datos se conozcan), integridad (impiden que los datos se cambien) y disponibilidad (permite que los datos se usen cuando se los requiere).

Sin embargo los firewalls no pueden proteger contra personas malicio- sas dentro de la empresa, no defiende las conexiones que no pasan por él, ni brinda seguridad contra amenazas desconocidas ni contra virus.

Utilizar bitácoras

Las bitácoras, son registros de las actividades de los sistemas, la mayo- ría de los sistemas operativos pueden configurarse para llevarlas, escribiéndo- las en archivos, distribuyéndolas a través de la red, imprimiéndolas o almacenándolas en algún otro dispositivo.

Son invaluables a la hora de la recuperación después de un incidente de seguridad ya que nos pueden dar pistas de como entró el atacante y hasta ayudarnos a identificarlo. A veces pueden presentarse como evidencia en un juicio. Sin embargo si alguien entra en un sistema lo primero que hará será bo- rrar sus huellas en las bitácoras ya sea eliminándolas o modificándolas. Esto se puede evitar con un servidor de bitácoras seguro que recolecta las bitácoras de otras computadoras en la red. Este servidor no soporta cue ntas de usuario para evitar que un atacante pueda entrar al mismo.

Las bitácoras pueden ser examinadas con regularidad, existe un softwa- re llamado analizador de bitácoras que descarta los eventos esperados dejan- do sólo aquellos inesperados que merecen atención. La desventaja de las bitá- coras es que generan mucha información en corto tiempo y es importante res- paldar las bitácoras históricas ya que podemos necesitarlas cuando se descu- bre el ataque y puede que haya pasado un tiempo considerable desde que el mismo se produjo.

Utilizar respaldos

El respaldo, es una copia de los datos, escritos en un medio de almace- namiento duradero. Protegiendo contra fallas del equipo, borrado accidental de datos, irrupciones (ya que los archivos borrados o modificados por un atacante pueden ser restaurados), ayudan a detectar cambios en el sistema.

Sin embargo los sistemas de respaldo no están exentos de problemas: se debe verificar que los datos respaldados sean correctos y que puedan em- plearse para restaurar el sistema, si los archivos respaldados se transmiten a través de la red sin encriptación, se corre el riesgo de que un atacante pueda acceder a su contenido, los medios de almacenamiento de respaldo exigen protección especial contra robo o destrucción ya que las mismas por definición contienen los datos históricos del sistema.

Minimizar servicios

Una forma fundamental de reducir las amenazas a un servidor Web es minimizar los servicios que ofrece la computadora donde este se ejecuta [L-9]. Al quitar los servicios no esenciales se eliminan entradas potenciales al siste- ma. Una buena práctica es: si un servicio no es necesario, deshabilitarlo. En la Figura CC se detallan los servicios que se recomienda restringir y el motivo de esta recomendación.



Figura CC.: Servicios que se deben deshabilitar o restringir para que un servidor Web sea con- siderado seguro [L-9]

Restringir el acceso a servidores Web

Algunas veces no se desea que la información publicada en Internet se encuentre visible para todo el universo de personas; esto puede ser porque el servidor Web contiene información exclusiva para un grupo de personas ya sea, que son miembros de una organización, clientes que pagan para ver la información, clientes que hayan firmado acuerdos de confidencialidad.

Existen varias técnicas para controlar el acceso a la información coloca- da en la Web, a continuación veremos algunos de ellos:

URL ocultos:

Consiste en no publicar y mantener secreto el URL de acceso a una pá- gina. Son los más fáciles de implementar aunque la seguridad que proporcio- nan es la equivalente a tener una llave escondida debajo del felpudo en la en- trada de una casa. Se basa en el concepto de que nadie puede acceder a da- tos que no sabe dónde están, pero de la misma manera cualquiera que cono z- ca como acceder a ellos, tendrá toda la información. Además esta información es transitiva ya que esta URL puede divulgarse de boca en boca, vía e-mail o de alguna otra manera. Otra forma de divulgación de la URL son los programas "araña" que buscan por toda la red agregando las palabras claves de cada pá- gina que encuentran a una base de datos central, como por ejemplo Lycos y AltaVista que son dos buscadores24 muy conocidos que utilizan este método para completar sus bases de datos con información de los contenidos de la Web.

Restricciones basadas en la dirección:

Se permite el acceso al servidor Web a un grupo específico de computa- doras basándose en sus direcciones de Internet mediante la dirección IP espe- cífica o un rango dentro de una subred. Es una técnica de limitar el acceso a la información en la Web. Este sistema no es perfecto ya que se pueden utilizar engaños de IP para enviar paquetes que aparente provenir de una computado- ra distinta de la que en verdad provienen. A aquellos que tengan permiso explí- cito de acceso se les mostrará la página correspondiente y a los usuarios que no tienen permiso de acceso se les mostrará el mensaje de la Figura DD.



Figura DD.: Mensaje de advertencia cuando se intenta acceder a un sitio restringido y no se

tienen los privilegios necesarios.

Control de acceso basado en identidad:

Este sistema se basa en restringir la entrada a un servidor Web utiliza n- do nombres de usuario. Es una de las formas más efectivas de controlar el ac- ceso. A cada usuario se le da un nombre que lo identifica y una clave de acce- so que lo autentica. También se puede corroborar la identidad con algunos de los métodos antes visto de llave pública o prendas físicas.

Utilizar seguridad física

La seguridad física de un sitio Web intenta defender las máquinas com- prometidas con el mismo contra cualquier ataque o accidente, contra personas internas y externas; a continuación se enumeran recomendaciones útiles a la hora de elaborar un plan de seguridad física:

Elaborar un detalle completo de qué es lo que se protege y contra qué o quién.

Proteger contra incendio, humo, explosiones, humedad y polvo.

Proteger contra desastres naturales.

Proteger contra ruidos eléctricos y rayos.

Proporcionar ventilación adecuada.

Alejar los alimentos y bebidas de las computadoras de misión crí- tica.

Restringir el acceso físico a las computadoras.

Asegurar físicamente las computadoras de forma que no puedan ser robadas ni transgredidas. Usar marcas indelebles de control de inventario.

Proteger el cableado de red contra destrucción, escucha e inter- cepción.

Crear una lista de procedimiento estándar de operación para el si- tio.

Auditar la seguridad

La auditoria permite que controlemos los desvíos entre lo que en un momento se pretendió hacer y lo que se está haciendo dentro de la empresa. Es decir como los procedimientos y políticas que se han establecido, se van modificando en el accionar del día a día.

Al auditar la seguridad de un sistema informático deben tenerse en cue n- ta factores como la posibilidad de fraude interno que es cometido por el mismo personal en el desarrollo de sus funciones, las violaciones al sistema de segu- ridad de acceso que se puedan realizar, los defectos y errores evitables, fallas en los sistemas, etcétera.

Esto nos permite saber donde nos encontramos, si tenemos que trabajar en el cumplimiento de los procedimientos y políticas o la posible necesidad de actualizarlas.

Hay algunos puntos a tener en cuenta, para evaluar un sistema de se- guridad informática:

Uso de la computadora: se debe observar el uso adecuado de la com- putadora y su software dentro de la organización. Evitar copias de programas de la organización para fines de comercialización y acceso a bases de datos con fines que dañen los conceptos de privacidad de los datos.

Sistema de acceso: para evitar los fraudes computarizados se debe contemplar de forma clara los accesos a las computadoras de acuerdo al nivel de seguridad de cada usuario y de sus privilegios. Evaluar la seguridad con- templando la relación costo, ya que a mayor tecnología de acceso mayor costo.

Control de programación: se debe conocer que las fallas más comu- nes están presentes en el momento de la programación, ya que pueden ser introducidas intencionalmente o no, para lo cual se debe controlar que los programas no contengan bombas lógicas; los programas deben contar con fuentes y sus ultimas actualizaciones; los programas deben contar con documentación técnica, operativa y de emergencia.

Personal: se debe observar este punto con mucho cuidado, ya que hablamos de las personas que están ligadas al sistema de información de for- ma directa y se deberá contemplar principalmente la dependencia del sistema a nivel operativo y técnico, el grado de capacitación del grupo en cuanto a proce- sos de seguridad informática, contemplar el conocimiento y respeto de las polí- ticas de seguridad informática. Es importante el perfil del personal relacionado con el sistema, ya que pueden surgir malos manejos de administración, negli- gencia o ataques deliberados.

Medios de control: se debe contemplar la existencia de medios de con- trol para conocer cuando se produce un cambio o un fraude en el sistema.

Instalaciones: es muy importante no olvidar las instalaciones físicas y de servicios, que significan un alto grado de riesgo. Para lo cual se debe verifi- car la continuidad del flujo eléctrico, efectos del flujo eléctrico sobre el software y hardware, evaluar las conexiones físicas de los sistemas; verificar si existe un diseño, especificación técnica, manual o algún tipo de documentación sobre las instalaciones.

Establecer las áreas y grados de riesgo: es muy importante el crear una conciencia en los usuarios de la organización sobre el riesgo que corre la información y hacerles comprender que la seguridad es parte de su trabajo. Para esto se deben conocer los principales riesgos que acechan a la función informática y los medios de prevención que se deben tener, para lo cual se de- be establecer el costo del sistema de seguridad teniendo en cuenta el factor costo – beneficio y el riesgo – impacto.

Para realizar estos estudios se debe considerar lo siguiente:

clasificar la instalación en términos de riesgo (alto, mediano, pe- queño).

identificar las aplicaciones que tengan alto riesgo.

cuantificar el impacto en el caso de suspensión del servicio aque- llas aplicaciones con un alto riesgo.

formular las medidas de seguridad necesarias dependiendo del nivel de seguridad que se requiera.

justificación del costo de implantar las medidas de seguridad.

Cada uno de estos puntos es de mucha importancia por lo que se sugie- re clasificar estos elementos en áreas de riesgo que pueden ser:

Riesgo computacional: se debe evaluar las aplicaciones y la depen- dencia del sistema de información, para lo cual es importante considerar res- ponder las siguientes cuatro preguntas:

¿Qué sucedería si no se puede utilizar el sistema? ¿Qué consecuencias traería la negación de servicio? ¿Cuál es el costo de no dar servicio? ¿Existe un procedimiento alternativo y que problemas ocasionaría? ¿Qué se ha hecho en casos de emergencia hasta ahora? Cuando se ha definido el grado de riesgo se debe elaborar una lista de los sistemas con las medidas preventivas que se deben tomar y las correctivas en caso de desastre, señalando la prioridad de cada uno. Para que así, se tra- bajen los sistemas de acuerdo a sus prioridades.

Cultura y capacitación del personal: cuando hablamos de información, su riesgo y su seguridad siempre se debe considerar al elemento humano, ya que podría definir la existencia de los más altos grados de riesgo. Por lo cual es muy importante considerar la elaboración del plan observando el comporta- miento con respecto al sistema, que lleve a la persona a:

Asumir riesgos

Cumplir promesas

Innovar Para apoyar estos objetivos se debe cumplir los siguientes pasos:

Motivar: se debe desarrollar métodos de participación reflexio- nando sobre lo que significa la seguridad y el riesgo, así como su impac- to a nivel empresarial e individual.

Capacitación general: en un principio a los ejecutivos con el fin de que conozcan y entiendan la relación entre seguridad, riesgo y la in- formación, y su impacto en la empresa. El objetivo de este punto es que se podrán detectar las debilidades y potencialidades de la organización frente al riesgo.

Este proceso incluye como práctica necesaria la implantación de planes de contingencia y la simulación de posibles delitos.

Capacitación de Técnicos: se debe formar técnicos encargados de mantener la seguridad informática como parte de su trabajo y que es- tén capacitados para transmitir a otras personas las medidas preventivas y correctivas.

Ética y Cultura: Se debe establecer un método de educación es- timulando el cultivo de elevados principios morales, que tengan repercu- sión a nivel personal e institucional.

Mantener la relación Costo – Beneficio

Resulta imprescindible a la hora de elaborar un plan de seguridad, ya sea definiendo políticas o implementando seguridad física, conocer completa- mente donde se encuentra ubicado nuestro sitio. Ya que no es lo mismo prote- ger una página con nuestras fotos familiares que un sitio de venta de servicios o artículos con medios electrónicos de pago.

"El costo de la seguridad no debe superar el valor de los datos pero el costo de obtener y descifrar esos datos debe ser superior a su valor"

Partes: 1, 2, 3, 4