lunes, 9 de diciembre de 2013

2a PARTE 4° PARCIAL

INTELIGENCIA DE NEGOCIOS


 Es el conjunto de estrategias y herramientas (ETL) enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización o empresa
• Se refiere al uso de datos en una empresa para facilitar la toma de decisiones.

ETL (Extract, Transform and Load)
• Es el proceso que permite a las organizaciones mover datos desde múltiples fuentes, reformatearlos y limpiarlos, y cargarlos en otra base de datos para analizar, o en otro sistema operacional para apoyar un proceso de negocio.

Ejemplos de transformacion
•Seleccionar sólo ciertas columnas para su carga (por ejemplo, que las columnas con valores nulos no se carguen).
•Codificar valores libres (por ejemplo, convertir "Hombre" en "H" o "Sr" en "1").
•Calcular totales de múltiples filas de datos (por ejemplo, ventas totales de cada región).
•Dividir una columna en varias (por ejemplo, columna "Nombre: García López, Miguel Ángel"; pasar a dos columnas "Nombre: Miguel Ángel", "Apellido1: García" y "Apellido2: López").

CARGAR (Load)
•Es el momento en el cual los datos de la fase anterior (transformación) son cargados en el sistema de destino. 

Este conjunto de herramientas y metodologías tienen en común las siguientes características:
-Accesibilidad a la información.
-Los datos son la fuente principal de este concepto. 
-Apoyo en la toma de decisiones.
-Se busca ir más allá en la presentación de la información, de manera que los usuarios tengan acceso a herramientas de análisis que les permitan seleccionar y manipular sólo aquellos datos que les interesen.
-Orientación al usuario fi
-Se busca independencia entre los conocimientos técnicos de los usuarios y su capacidad para utilizar estas herramientas.

SISTEMA DE SOPORTE A LA DECISIÓN (DSS)
•ALMACENES DE DATOS
•TABLEROS DE CONTROL
•CONSULTAS Y REPORTES PERSONALIZADOS

DSS (Decision Support System)
•Es un sistema informático utilizado para servir de apoyo, más que automatizar, el proceso de toma de decisiones.
•El apoyo a una decisión significa ayudar a las personas que trabajan solas o en grupo a reunir inteligencia, generar alternativas y tomar decisiones.
•Apoyar el proceso de toma de decisión implica el apoyo a la estimación, la evaluación y/o la comparación de alternativas.
•Los DSS son herramientas permiten realizar el análisis de las diferentes variables de negocio para apoyar el proceso de toma de decisiones de los directivos
•Permite extraer y manipular información de una manera flexible.
•Ayuda en decisiones no estructuradas.
•Permite al usuario definir interactivamente qué información necesita y cómo combinarla.
•Suele incluir herramientas de simulación, modelización, etc.
Puede combinar información de los sistemas transaccionales internos de la empresa con los de otra empresa externa.

ALMACENES DE DATOS (Data warehouse)
•Es una colección de datos orientada a un determinado ámbito (empresa, organización, etc.)
Integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. Se trata, sobre todo, de un expediente completo de una organización, más allá de la información transaccional y operacional, almacenado en una base de datos diseñada para favorecer el análisis y la divulgación eficiente de datos 

FUNCION
•El almacén de datos da respuesta a las necesidades de usuarios expertos, utilizando Sistemas de Soporte a Decisiones (DSS) o herramientas para hacer consultas o informes.
Los usuarios finales pueden hacer fácilmente consultas sobre sus almacenes de datos sin tocar o afectar la operación del sistema.

TABLEROS DE CONTROL
 Es una herramienta, del campo de la administración de empresas, aplicable a cualquier organización y nivel de la misma, cuyo objetivo y utilidad básica es diagnosticar adecuadamente una situación. Se lo define como el conjunto de indicadores cuyo seguimiento y evaluación periódica permitirá contar con un mayor conocimiento de la situación de su empresa o sector apoyándose en nuevas tecnologías informáticas.

Tipos de Tableros
Tablero de Control Operativo:
•Es aquel que permite hacer un seguimiento, al menos diario, del estado de situación de un sector o proceso de la empresa, para poder tomar a tiempo las medidas correctivas necesarias.
El Tablero debe proveer la información que se necesita para entrar en acción y tomar decisiones operativas en áreas como las finanzas, compras, ventas, precios, producción, logística, etc.
Tablero de Control Directivo:
•Es aquel que permite monitorear los resultados de la empresa en su conjunto y de los diferentes temas claves en que se puede segmentarse.
• Está más orientado al seguimiento de indicadores de los resultados internos de la empresa en su conjunto y en el corto plazo. Su monitoreo es de aproximadamente cada mes.
Puede incluir indicadores de todos los sectores para los directivos claves o sectorizado para un directivo.
Tablero de Control Directivo:
•Es aquel que permite monitorear los resultados de la empresa en su conjunto y de los diferentes temas claves en que se puede segmentarse.
• Está más orientado al seguimiento de indicadores de los resultados internos de la empresa en su conjunto y en el corto plazo. Su monitoreo es de aproximadamente cada mes.
Puede incluir indicadores de todos los sectores para los directivos claves o sectorizado para un directivo.
Tablero de Control Integral:
Información relevantes para que la alta dirección de una empresa pueda conocer la situación integral de su empresa. Engloba a las tres perspectivas anteriores

CONSULTAS Y REPORTES PERSONALIZADOS
Aunque las herramientas de inteligencia del negocio, los reportes estándar, las planillas de cálculo y las herramientas de consulta de SQL todos tienen su lugar importante dentro de una organización, muchos usuarios aún enfrentan brechas de funcionalidad con estas herramientas en tres áreas claves:
• Las necesidades de reporte y análisis involucran sistemas heredados y otros datos que no están en warehouses
•La aplicación no soporta los análisis deseados y volúmenes de datos
•Se
Se requieren significativos recursos de TI y preparación para soportar nuevas consultas a los datos

miércoles, 4 de diciembre de 2013

TRANSACCIONES ELECTRÓNICAS                                                                   
DEFINICIÓN:                                                                                                                                          “Una transacción electrónica es un proceso mediante el cual se abonan o debilitan fondos de las cuentas de ahorros o corrientes de los clientes del Banco, por operaciones originadas desde todas las entidades financieras afiliadas al sistema CENIT o ACH a través de los distintos canales como son; homebanking, Internet, cajeros automáticos, sistemas de audiorespuesta entre otros”.                                                        
“Debemos señalar que una transacción electrónica no es más que un contrato celebrado mediante medios electrónicos, a través de la red. En nuestra legislación el contrato, sea este de cualquier   naturaleza, es el acuerdo de voluntades destinadas a crear, regular, modificar, o extinguir una     relación jurídica patrimonial, entendida esta última como el vínculo legal de contenido económico   que va surgir entre los contratantes”                                                                                 
                                                                                                                                  
PROTOCOLOS DE SEGURIDAD                                              
                               
Los medios de pago online o gateways de pagos ofrecidos por las entidades bancarias están basadas en servidores seguros, que garantizan que la información que circula entre nuestra tienda virtual y el banco esté protegida, sea auténtica y no pueda ser utilizada por terceros, por ello se emplean algoritmos de protección como SSL.Un servidor seguro proporciona tres garantías de seguridad:
  • Autenticidad. Permite tener la certeza de que los datos del pago se están enviando al auténtico servidor del banco.
  • Confidencialidad. Asegura que los datos, en el caso de ser capturados por un tercero ajeno a la transacción, no podrán ser empleados ya que viajan cifrados.
  • Integridad. Garantiza que los datos que llegan al servidor del banco no se han alterado por el camino (Internet), detectándose a través de los mecanismos de seguridad de SSL cualquier alteración.
Para que un servidor sea seguro el banco debe disponer de un certificado emitido por una Autoridad de Certificación (como Verisign), quien analiza exhaustivamente los datos de la entidad solicitante y las normas de seguridad de su infraestructura.
Un internauta puede identificar un servidor seguro cuando en el navegador aparezca el símbolo correspondiente a un candado cerrado., y además en la URL el habitual http:// se convierte en https://.
Las pasarelas de pago emplean dos protocolos estándar de seguridad, SSL y SET que permiten encriptar los datos personales que viajan por la red, de forma que sólo puede ser interpretada por el sistema del cliente y el del servidor, evitando un acceso no autorizado.
El más empleado, por su simplicidad, es el SSL (Secure Sockets Layer) cuyo uso principal es cifrar el número de las tarjetas de crédito al realizar cualquier transacción online. El protocolo SSL ofrece servicio de cifrado de datos, autenticación del servidor, integridad de mensajes y, en menor medida, la identificación del cliente para conexiones TCP/IP (protocolo empleado en internet). SSL proporciona un canal electrónico seguro para realizar transacciones entre los servidores (banco, entidad emisora de la tarjeta y tienda online) y los navegadores a través del cual, cifrando los datos de compra, se pueden celebrar transacciones electrónicas con seguridad.
El SET (Secure Electronic Transaction), es un conjunto de normas de seguridad cuyo fin es asegurar la identidad de las personas que participan en una transacción electrónica, proteger la información que se envía y garantizar que esta no ha sido manipulada en este proceso. Para ello emplea certificados digitales y software de encriptado que lo hacen más complejo de usar y por lo tanto más difícil de implantar que el SSL.

Tarjetas securizadas

El proceso habitual de compra con una tarjeta de crédito implica el envío de algunos datos básicos como nº de tarjeta, titular o fecha de caducidad, que pueden estar a disposición de cualquiera con cierta facilidad.

Incluso el código CVV, 3 dígitos de comprobación visibles en la cara trasera de la tarjeta, que algunos sistemas de pago solicitan para confirmar la compra están disponibles para cualquiera que haya fotografiado o copiado la tarjeta. Este problema ha originado un elevado número de reclamaciones y supuesto importantes pérdidas para el comercio virtual que debe asumir el coste de las devoluciones de pagos.
Por esta razón, las entidades bancarias están empezando a solicitar en sus pasarelas de pago un código secreto, similar al empleado en un cajero automático, para autorizar cualquier proceso de compra con una tarjeta de crédito. Los bancos permiten aplicar dichos sistemas a las tarjetas habituales de crédito /débito, simplemente con una solicitud a través de la entidad bancaria del cliente e incluso empleando la banca electrónica, sin coste alguno. Las tiendas virtuales que exigen el uso de tarjetas securizadas se identifican mediante un logotipo de Visa (Verified by Visa) o MasterCard (MasterCard SecureCod).
Las ventajas de su uso tanto para compradores como para vendedores es clara, solamente el propietario de la tarjeta puede comprar online con ella, por lo que para los primeros se reducen los robos de identidad y, para los segundos, las reclamaciones por parte de clientes.


ATAQUES EN INTERNET (MEN IN THE MIDDLE)

El ataque ‘Man in the middle’, traducido a español como ‘El hombre en el medio’, es un ataque PASIVO, que se lleva a cabo tanto en redes LAN como WLAN. 
Pongamos un simple ejemplo para poner de manifiesto en qué consiste este ataque: 
Supongamos que tenemos 3 hosts dentro de una red, host A, host B, y host C. El host A quiere intercambiar información con el host B (éste host puede o no estar en la misma red), para ello, los paquetes deben enviarse a través del router que los dirige hacia B. Ahora, si el host C tiene intención de ‘escuchar’ el mensaje que A envía a B, sólo tiene que adoptar un papel de puente entre A y el router. 





PRETECCION FRENTE A FIRESHEEP Y A LOS ATAQUES DE SIDEJACKING CON SSL




Introducción 
Tras la reciente aparición de Firesheep, una herramienta que permite atacar redes Wi-Fi, ahora tanto los usuarios como los ciberdelincuentes son más conscientes del riesgo que 
suponen las conexiones HTTP desprotegidas. Los usuarios de redes abiertas que visitan sitios web mediante conexiones HTTP estándar se exponen a ser vigilados y ponen en peligro su información. Con Firesheep, un atacante conectado a una red local puede ver las sesiones web de otros usuarios de dicha red y apropiarse de ellas para actuar en el contexto de los usuarios legítimos. El objetivo de Firesheep suelen ser redes Wi-Fi abiertas, pero las redes Ethernet tradicionales por cable también corren peligro. Todo esto no es nuevo: hace años que estos problemas son bien conocidos, al menos dentro del sector de la seguridad. 
Lo que ocurre es que con Firesheep los ataques resultan más fáciles e incluso los hackers con poca experiencia pueden llevar a cabo robos de identidad de efectos catastróficos.
Tal como han declarado los expertos tras la aparición de Firesheep, la mejor solución consiste en usar tecnología TLS/SSL para todas las conexiones a sitios web, incluso cuando se visita la página de inicio. Hasta ahora, numerosos sitios web de gran tamaño han limitado al mínimo el uso de esta tecnología, tal vez porque exige una mayor potencia de procesamiento. Sin embargo, debido a la gravedad de las amenazas y a los costes que implican los ataques, esta postura cada vez es más injustificable. El problema de las redes Wi-Fi abiertas 
Las redes inalámbricas 802.11 siempre han presentado problemas en lo que se refiere a la seguridad. El primer mecanismo de protección, llamado WEP o privacidad equivalente por cable, era difícil de usar y resultó tener fallos graves, con lo que las redes que usaban este sistema podían ser atacadas incluso con herramientas gratuitas. Además, como era un método complicado, se tendió a dejar totalmente desprotegidos los puntos de acceso Wi-Fi, sin ningún tipo de cifrado ni autenticación. Aunque en la actualidad está muy extendido el acceso protegido Wi-Fi 2 o WPA2, un sistema eficaz y fácil de usar, sigue habiendo bastantes redes Wi-Fi abiertas, incluso en instalaciones aparentemente seguras. Por ejemplo, al acceder a una red Wi-Fi pública, los usuarios suelen conectarse a la red local y, a continuación, autenticarse en una página web proporcionada por un enrutador local para obtener acceso a Internet. Aunque se cifren los datos que se transmiten del enrutador a Internet (lo cual no suele ocurrir), la red local del espacio público y sus inmediaciones sigue estando totalmente desprotegida. Así, todo el tráfico que se produce entre los clientes e Internet carece de cifrado, con lo que la única forma que tienen los usuarios de protegerse por completo en estos casos es usar una red privada virtual. La mayor parte del tráfico de las redes Wi-Fi públicas (y de muchas privadas) es HTTP, que nació como protocolo de 
aplicaciones de Internet pero tiene muchos más usos. A menos que las aplicaciones locales y del servidor cuenten con algún tipo de protocolo de cifrado privado, lo cual es infrecuente, el protocolo HTTP carece de cifrado: en la red local, el texto se transmite sin cifrar, con lo que cualquiera que se conecte a ella puede leerlo. El problema se agrava debido al uso de cookies en muchos sitios web. El protocolo HTTP no tiene en cuenta el estado ni la sesión, lo que significa que cada comando es independiente y no está conectado al servidor. De este modo, el seguimiento de los usuarios y de los datos de su sesión (como el documento que están viendo y las tareas que están realizando) queda en manos de las aplicaciones que se 
ejecutan en el servidor. Para hacer un seguimiento de este tipo de elementos, lo habitual es usar cookies (datos asociados a un dominio o servidor concreto que el cliente almacena de forma local). El servidor envía estas cookies al cliente, que a su vez las transfiere de nuevo al servidor sin ningún cambio. Las cookies a veces contienen datos personales confidenciales u otro tipo de información que permite al servidor identificar al cliente. Las que se usan concretamente para controlar las sesiones de usuario se llaman «cookies de sesión».
Las cookies pueden llevar una marca de seguridad que indica al navegador que se deben enviar mediante una sesión HTTPS (TLS/SSL). Con frecuencia, los sitios web cifran el proceso de inicio de sesión pero prescinden de este tipo de marcas en las cookies de sesión. Si un ciberdelincuente consigue vigilar una red abierta, no sólo verá los datos que se transfieran entre el servidor y el cliente, sino también los presentes en las cookies desprotegidas. A continuación, podrá usar la información de las cookies para hacerse pasar por el usuario mediante un ataque denominado sidejacking, que es un tipo de secuestro de sesión. Esto es precisamente lo que permite hacer Firesheep.
Autoprotección 
Un usuario que cuente con los conocimientos y recursos necesarios y quiera evitar este tipo de amenazas dispone de numerosas soluciones técnicas que se han creado tras la aparición de Firesheep. Sin embargo, ninguna de estas opciones está al alcance del usuario medio ni ofrece una buena protección de forma predeterminada. Por ejemplo, la organización Electronic Frontier Foundation ha creado un complemento para Firefox llamado HTTPS 
Everywhere, un programa que convierte las solicitudes HTTP del navegador en solicitudes HTTPS y que funciona (a veces) con los sitios web que disponen de tecnología SSL pero usan de forma predeterminada el protocolo HTTP. Como se explica en la propia página de HTTPS Everywhere, este sistema presenta ciertos problemas. Por ejemplo, sólo funciona con Firefox, impide la conexión a algunas redes inalámbricas y no permite acceder a numerosos servicios de Google. Además, aunque el usuario acepte estas limitaciones, es posible que el sitio web use JavaScript para transmitir las cookies en HTTP sin cifrar. En redes Wi-Fi abiertas, sería mucho más prudente implantar el protocolo WPA2 con una contraseña compartida e indicarla en un cartel o usar la frase «La contraseña del local es xxxxxxx» como nombre de red. De este modo, cualquiera podría acceder a la red como si fuera abierta, pero no sería posible usar analizadores de paquetes, ya que el sistema WPA2 aísla a los usuarios. Sin embargo, desgraciadamente no se puede dar por hecho que los administradores de las redes abiertas tomen estas precauciones.


La solución: 

Tecnología TLS/SSL en todo el sitio web Los sitios web que usan tecnología TLS/SSL en todas sus páginas son inmunes al sidejacking. De hecho, se trata de la única forma de resolver este problema, tal como declara el propio Eric Butler: «La única solución eficaz es el cifrado completo, que en Internet se denomina HTTPS o SSL». Usar tecnología TLS/SSL en todo el sitio web equivale a utilizar siempre marcas de seguridad en las cookies. En la práctica, este sistema garantiza la inmunidad a los ataques basados en análisis de paquetes.Los sitios web que adopten la tecnología TLS/SSL para garantizar la seguridad de los usuarios tendrán que recurrir a una autoridad de certificación (CA) de confianza, pues la 
autenticación HTTPS completa con una CA fiable es la única forma de que los usuarios sepan a ciencia cierta con quién están tratando. Vale la pena destacar que la nueva función SSL de Facebook es una opción del usuario y, por lo tanto, no se puede aplicar hasta que se haya iniciado una sesión. Como no se usa tecnología SSL de forma predeterminada en la página de inicio, ésta es vulnerable a las interceptaciones o ataques de spoofing. Relación entre el coste y las ventajas de la tecnología TLS/SSL.  La tecnología TLS/SSL es compatible prácticamente con todo tipo de software y hay muchos profesionales con los conocimientos necesarios para usarla, así que el único motivo para prescindir del protocolo HTTPS en un sitio web podría ser el coste. Para saber a cuánto puede ascender, hay que valorar principalmente dos aspectos. En primer lugar, los certificados no son gratis, pero tienen 
un precio fijo y previsible. En cambio, los costes del hardware adicional necesario son difíciles de calcular a priori. Al usar tecnología TLS/SSL, todos los datos que se transfieren se tienen que cifrar y descifrar, con lo que se añade una carga de trabajo adicional que, en un sitio web de grandes dimensiones, podría suponer un coste de hardware considerable.






COMO FUNCIONA SSL Y EVOLUCIÓN



  1. El cliente envía el mensaje "hello" que lista las posibilidades criptográficas del cliente (clasificadas por orden de preferencia del cliente), como la versión de SSL, los grupos de programas de cifrado soportados por el cliente y los métodos de compresión de datos soportados por el cliente. El mensaje también contiene un número aleatorio de 28 bytes.
  1. El servidor responde con el mensaje "hello" del servidor que contiene el método criptográfico (conjunto de programas de cifrado) y el método de compresión de datos seleccionados por el servidor, el ID de sesión y otro número aleatorio.

Nota:
El cliente y el servidor deben dar soporte como mínimo a un conjunto de cifrado común; de lo contrario, el protocolo de enlace dará error. Generalmente, el servidor elige el conjunto de programas de cifrado común más potente.

  1. El servidor envía su certificado digital. (El servidor utiliza certificados digitales X.509 V3 con SSL.)
  1. El servidor envía el mensaje "hello done" de servidor y aguarda una respuesta del cliente.
  1. Al recibir el mensaje "hello done" del servidor, el cliente (el navegador web) verifica la validez del certificado digital del servidor y comprueba que los parámetros del mensaje "hello" del servidor son aceptables.
  1.  El cliente envía el mensaje "client key exchange". Este mensaje contiene el secreto pre-maestro, un número aleatorio de 46 bytes utilizado en la generación de las claves de cifrado simétrico y las claves de código de autenticación de mensajes (MAC), cifradas con la clave pública del servidor.

Nota:
No es necesario un proceso adicional para verificar el certificado digital del servidor. Si el servidor no tiene la clave privada que pertenece al certificado digital, no podrá descifrar el secreto pre-maestro y crear las claves correctas para el algoritmo de cifrado simétrico y el protocolo de enlace dará error.

  1.  El cliente utiliza una serie de operaciones criptográficas para convertir el secreto pre-maestro en un secreto maestro, del que se deriva todo el material de clave necesario para el cifrado y la autenticación de mensajes. A continuación, el cliente envía el mensaje "change cipher spec" para que el servidor conmute al conjunto de programas de cifrado recién negociado. El siguiente mensaje enviado por el cliente (mensaje "finished") es el primer mensaje cifrado con este método y estas claves de cifrado.
  1. El servidor responde con mensajes propios "change cipher spec" y "finished".
  1. El protocolo de enlace SSL finaliza y los datos de aplicación cifrados se pueden enviar.
SSL es un protocolo que proporciona privacidad e integridad entre dos aplicaciones de comunicaciones utilizando HTTP. El Protocolo de transferencia de hipertexto(HTTP) para World Wide Web utiliza SSL para que las comunicaciones sean seguras.
Los datos que circulan en un sentido y otro entre el cliente y el servidor se cifra mediante un algoritmo simétrico como DES o RC4. Un algoritmo de clave pública -generalmente RSA- se utiliza para el intercambio de las claves de cifrado y para las firmas digitales. El algoritmo utiliza la clave pública en el certificado digital del servidor. Con el certificado digital del servidor, el cliente también puede verificar la identidad del servidor. Las versiones 1 y 2 del protocolo SSL sólo proporcionan autenticación de servidor. La versión 3 agrega la autenticación del cliente, utilizando los certificados digitales de cliente y de servidor.

Una conexión SSL siempre es iniciada por el cliente. Al principio de una sesión SSL, se realiza un protocolo de enlace SSL. Este protocolo de enlace produce los parámetros criptográficos de la sesión. Una visión general simplificada de cómo se procesa el protocolo de enlace SSL se muestra en la. En este ejemplo se supone que se está estableciendo la conexión SSL entre un navegador web y un servidor web.

  1. Si el servidor utiliza SSL V3 y si la aplicación de servidor (por ejemplo, el servidor web) requiere un certificado digital para la autenticación de cliente, el servidor envía el mensaje "digital certificate request". En el mensaje "digital certificate request", el servidor envía una lista de los tipos de certificados digitales soportados y los nombres distinguidos de autoridades de certificación aceptables.
  1. Si el servidor ha solicitado un certificado digital del cliente, el cliente envía un certificado digital o, si no hay ningún certificado digital adecuado disponible, el cliente envía la alerta "no digital certificate". Esta alerta sólo es un aviso, pero la aplicación de servidor puede hacer que la sesión sea anómala si la autenticación del cliente es obligatoria.
  1. Si el cliente ha enviado un certificado digital al servidor, el cliente envía un mensaje "digital certificate verify" firmado con la clave privada del cliente. Al verificar la firma de este mensaje, el servidor puede verificar explícitamente la propiedad del certificado digital del cliente.
TLS no es propietario como si lo es SSL (Netscape), con lo cuál TLS podría tomarse como un estándar al desarrollar software. Durante el armado del cálculo MAC (código de autenticación del mensaje dónde se introduce información como numero de secuencia, etc) para iniciar la conexión, SSL no incluye a los campos de tipo de compresión y versión, dejánolos libres para el ataque. En TLS se toman los campos dentro del cálculo MAC, sin dejar datos insegurosSSL usa el algorítmo Fortezza Kea como uno de los algorítmo de intercambio, que tiene los valores públicos fijos contenidos en los certificados. Como este es inseguro, TLS directamente no lo soporta, evitando el uso de este. Es una buena medida, si no me da la seguridad necesaria, directamente lo dejo fuera……
Durante el primer cálculo del algorítmo de intercambio, TLS suma una nueva función llamada PRF, formando un nuevo campo y haciendo este intercambio más seguro. El función matemática es media compleja y amplia, pero si a alguno le interesa, pregunte en el blog que les paso la información de los algorítmos que usa SSL y el mismo usado por TLS con PRF para la mejora. Durante el intercambio SSL, cuando el servidor pedía un certificado al cliente, este le podía contestar con un no_certificate, TLS no permite este tipo de respuesta por parte del clientelogrando una transmisión segura entre CLIENTE-SERVIDOR, haciendo que el CLIENTE se autentiqueEn esta mejora entra en juego la parte de desarrollo o mantención del servidor, ya que si el servidor está a cargo nuestro y necesitamos que este seguro, una buena medida es que al momento de que el cliente pida conectarse, el servidor pida los certificados del usuario para ver a quien le permite la entrada.
TLS recibe una modificación para soportar autenticación Kerberos. Las credenciales Kerberos se usan para llevar a cabo una autenticación mutua y para establecer un master secret usado subsecuentemente para asegurar la comunicación CLIENTE-SERVIDOR. 

TRANSACCIONES ELECTRÓNICAS                                                                   
DEFINICIÓN:                                                                                                                                          “Una transacción electrónica es un proceso mediante el cual se abonan o debilitan fondos de las cuentas de ahorros o corrientes de los clientes del Banco, por operaciones originadas desde todas las entidades financieras afiliadas al sistema CENIT o ACH a través de los distintos canales como son; homebanking, Internet, cajeros automáticos, sistemas de audiorespuesta entre otros”.                                                        
“Debemos señalar que una transacción electrónica no es más que un contrato celebrado mediante medios electrónicos, a través de la red. En nuestra legislación el contrato, sea este de cualquier   naturaleza, es el acuerdo de voluntades destinadas a crear, regular, modificar, o extinguir una     relación jurídica patrimonial, entendida esta última como el vínculo legal de contenido económico   que va surgir entre los contratantes”                                                                                 
                                                                                                                                  
PROTOCOLOS DE SEGURIDAD                                              
                               
Los medios de pago online o gateways de pagos ofrecidos por las entidades bancarias están basadas en servidores seguros, que garantizan que la información que circula entre nuestra tienda virtual y el banco esté protegida, sea auténtica y no pueda ser utilizada por terceros, por ello se emplean algoritmos de protección como SSL.Un servidor seguro proporciona tres garantías de seguridad:
  • Autenticidad. Permite tener la certeza de que los datos del pago se están enviando al auténtico servidor del banco.
  • Confidencialidad. Asegura que los datos, en el caso de ser capturados por un tercero ajeno a la transacción, no podrán ser empleados ya que viajan cifrados.
  • Integridad. Garantiza que los datos que llegan al servidor del banco no se han alterado por el camino (Internet), detectándose a través de los mecanismos de seguridad de SSL cualquier alteración.
Para que un servidor sea seguro el banco debe disponer de un certificado emitido por una Autoridad de Certificación (como Verisign), quien analiza exhaustivamente los datos de la entidad solicitante y las normas de seguridad de su infraestructura.
Un internauta puede identificar un servidor seguro cuando en el navegador aparezca el símbolo correspondiente a un candado cerrado., y además en la URL el habitual http:// se convierte en https://.
Las pasarelas de pago emplean dos protocolos estándar de seguridad, SSL y SET que permiten encriptar los datos personales que viajan por la red, de forma que sólo puede ser interpretada por el sistema del cliente y el del servidor, evitando un acceso no autorizado.
El más empleado, por su simplicidad, es el SSL (Secure Sockets Layer) cuyo uso principal es cifrar el número de las tarjetas de crédito al realizar cualquier transacción online. El protocolo SSL ofrece servicio de cifrado de datos, autenticación del servidor, integridad de mensajes y, en menor medida, la identificación del cliente para conexiones TCP/IP (protocolo empleado en internet). SSL proporciona un canal electrónico seguro para realizar transacciones entre los servidores (banco, entidad emisora de la tarjeta y tienda online) y los navegadores a través del cual, cifrando los datos de compra, se pueden celebrar transacciones electrónicas con seguridad.
El SET (Secure Electronic Transaction), es un conjunto de normas de seguridad cuyo fin es asegurar la identidad de las personas que participan en una transacción electrónica, proteger la información que se envía y garantizar que esta no ha sido manipulada en este proceso. Para ello emplea certificados digitales y software de encriptado que lo hacen más complejo de usar y por lo tanto más difícil de implantar que el SSL.

Tarjetas securizadas

El proceso habitual de compra con una tarjeta de crédito implica el envío de algunos datos básicos como nº de tarjeta, titular o fecha de caducidad, que pueden estar a disposición de cualquiera con cierta facilidad.

Incluso el código CVV, 3 dígitos de comprobación visibles en la cara trasera de la tarjeta, que algunos sistemas de pago solicitan para confirmar la compra están disponibles para cualquiera que haya fotografiado o copiado la tarjeta. Este problema ha originado un elevado número de reclamaciones y supuesto importantes pérdidas para el comercio virtual que debe asumir el coste de las devoluciones de pagos.
Por esta razón, las entidades bancarias están empezando a solicitar en sus pasarelas de pago un código secreto, similar al empleado en un cajero automático, para autorizar cualquier proceso de compra con una tarjeta de crédito. Los bancos permiten aplicar dichos sistemas a las tarjetas habituales de crédito /débito, simplemente con una solicitud a través de la entidad bancaria del cliente e incluso empleando la banca electrónica, sin coste alguno. Las tiendas virtuales que exigen el uso de tarjetas securizadas se identifican mediante un logotipo de Visa (Verified by Visa) o MasterCard (MasterCard SecureCod).
Las ventajas de su uso tanto para compradores como para vendedores es clara, solamente el propietario de la tarjeta puede comprar online con ella, por lo que para los primeros se reducen los robos de identidad y, para los segundos, las reclamaciones por parte de clientes.


ATAQUES EN INTERNET (MEN IN THE MIDDLE)

El ataque ‘Man in the middle’, traducido a español como ‘El hombre en el medio’, es un ataque PASIVO, que se lleva a cabo tanto en redes LAN como WLAN. 
Pongamos un simple ejemplo para poner de manifiesto en qué consiste este ataque: 
Supongamos que tenemos 3 hosts dentro de una red, host A, host B, y host C. El host A quiere intercambiar información con el host B (éste host puede o no estar en la misma red), para ello, los paquetes deben enviarse a través del router que los dirige hacia B. Ahora, si el host C tiene intención de ‘escuchar’ el mensaje que A envía a B, sólo tiene que adoptar un papel de puente entre A y el router. 




PRETECCION FRENTE A FIRESHEEP Y A LOS ATAQUES DE SIDEJACKING CON SSL



Introducción 
Tras la reciente aparición de Firesheep, una herramienta que permite atacar redes Wi-Fi, ahora tanto los usuarios como los ciberdelincuentes son más conscientes del riesgo que 
suponen las conexiones HTTP desprotegidas. Los usuarios de redes abiertas que visitan sitios web mediante conexiones HTTP estándar se exponen a ser vigilados y ponen en peligro su información. Con Firesheep, un atacante conectado a una red local puede ver las sesiones web de otros usuarios de dicha red y apropiarse de ellas para actuar en el contexto de los usuarios legítimos. El objetivo de Firesheep suelen ser redes Wi-Fi abiertas, pero las redes Ethernet tradicionales por cable también corren peligro. Todo esto no es nuevo: hace años que estos problemas son bien conocidos, al menos dentro del sector de la seguridad. 
Lo que ocurre es que con Firesheep los ataques resultan más fáciles e incluso los hackers con poca experiencia pueden llevar a cabo robos de identidad de efectos catastróficos.
Tal como han declarado los expertos tras la aparición de Firesheep, la mejor solución consiste en usar tecnología TLS/SSL para todas las conexiones a sitios web, incluso cuando se visita la página de inicio. Hasta ahora, numerosos sitios web de gran tamaño han limitado al mínimo el uso de esta tecnología, tal vez porque exige una mayor potencia de procesamiento. Sin embargo, debido a la gravedad de las amenazas y a los costes que implican los ataques, esta postura cada vez es más injustificable. El problema de las redes Wi-Fi abiertas 
Las redes inalámbricas 802.11 siempre han presentado problemas en lo que se refiere a la seguridad. El primer mecanismo de protección, llamado WEP o privacidad equivalente por cable, era difícil de usar y resultó tener fallos graves, con lo que las redes que usaban este sistema podían ser atacadas incluso con herramientas gratuitas. Además, como era un método complicado, se tendió a dejar totalmente desprotegidos los puntos de acceso Wi-Fi, sin ningún tipo de cifrado ni autenticación. Aunque en la actualidad está muy extendido el acceso protegido Wi-Fi 2 o WPA2, un sistema eficaz y fácil de usar, sigue habiendo bastantes redes Wi-Fi abiertas, incluso en instalaciones aparentemente seguras. Por ejemplo, al acceder a una red Wi-Fi pública, los usuarios suelen conectarse a la red local y, a continuación, autenticarse en una página web proporcionada por un enrutador local para obtener acceso a Internet. Aunque se cifren los datos que se transmiten del enrutador a Internet (lo cual no suele ocurrir), la red local del espacio público y sus inmediaciones sigue estando totalmente desprotegida. Así, todo el tráfico que se produce entre los clientes e Internet carece de cifrado, con lo que la única forma que tienen los usuarios de protegerse por completo en estos casos es usar una red privada virtual. La mayor parte del tráfico de las redes Wi-Fi públicas (y de muchas privadas) es HTTP, que nació como protocolo de 
aplicaciones de Internet pero tiene muchos más usos. A menos que las aplicaciones locales y del servidor cuenten con algún tipo de protocolo de cifrado privado, lo cual es infrecuente, el protocolo HTTP carece de cifrado: en la red local, el texto se transmite sin cifrar, con lo que cualquiera que se conecte a ella puede leerlo. El problema se agrava debido al uso de cookies en muchos sitios web. El protocolo HTTP no tiene en cuenta el estado ni la sesión, lo que significa que cada comando es independiente y no está conectado al servidor. De este modo, el seguimiento de los usuarios y de los datos de su sesión (como el documento que están viendo y las tareas que están realizando) queda en manos de las aplicaciones que se 
ejecutan en el servidor. Para hacer un seguimiento de este tipo de elementos, lo habitual es usar cookies (datos asociados a un dominio o servidor concreto que el cliente almacena de forma local). El servidor envía estas cookies al cliente, que a su vez las transfiere de nuevo al servidor sin ningún cambio. Las cookies a veces contienen datos personales confidenciales u otro tipo de información que permite al servidor identificar al cliente. Las que se usan concretamente para controlar las sesiones de usuario se llaman «cookies de sesión».
Las cookies pueden llevar una marca de seguridad que indica al navegador que se deben enviar mediante una sesión HTTPS (TLS/SSL). Con frecuencia, los sitios web cifran el proceso de inicio de sesión pero prescinden de este tipo de marcas en las cookies de sesión. Si un ciberdelincuente consigue vigilar una red abierta, no sólo verá los datos que se transfieran entre el servidor y el cliente, sino también los presentes en las cookies desprotegidas. A continuación, podrá usar la información de las cookies para hacerse pasar por el usuario mediante un ataque denominado sidejacking, que es un tipo de secuestro de sesión. Esto es precisamente lo que permite hacer Firesheep.
Autoprotección 
Un usuario que cuente con los conocimientos y recursos necesarios y quiera evitar este tipo de amenazas dispone de numerosas soluciones técnicas que se han creado tras la aparición de Firesheep. Sin embargo, ninguna de estas opciones está al alcance del usuario medio ni ofrece una buena protección de forma predeterminada. Por ejemplo, la organización Electronic Frontier Foundation ha creado un complemento para Firefox llamado HTTPS 
Everywhere, un programa que convierte las solicitudes HTTP del navegador en solicitudes HTTPS y que funciona (a veces) con los sitios web que disponen de tecnología SSL pero usan de forma predeterminada el protocolo HTTP. Como se explica en la propia página de HTTPS Everywhere, este sistema presenta ciertos problemas. Por ejemplo, sólo funciona con Firefox, impide la conexión a algunas redes inalámbricas y no permite acceder a numerosos servicios de Google. Además, aunque el usuario acepte estas limitaciones, es posible que el sitio web use JavaScript para transmitir las cookies en HTTP sin cifrar. En redes Wi-Fi abiertas, sería mucho más prudente implantar el protocolo WPA2 con una contraseña compartida e indicarla en un cartel o usar la frase «La contraseña del local es xxxxxxx» como nombre de red. De este modo, cualquiera podría acceder a la red como si fuera abierta, pero no sería posible usar analizadores de paquetes, ya que el sistema WPA2 aísla a los usuarios. Sin embargo, desgraciadamente no se puede dar por hecho que los administradores de las redes abiertas tomen estas precauciones.


La solución: 
Tecnología TLS/SSL en todo el sitio web Los sitios web que usan tecnología TLS/SSL en todas sus páginas son inmunes al sidejacking. De hecho, se trata de la única forma de resolver este problema, tal como declara el propio Eric Butler: «La única solución eficaz es el cifrado completo, que en Internet se denomina HTTPS o SSL». Usar tecnología TLS/SSL en todo el sitio web equivale a utilizar siempre marcas de seguridad en las cookies. En la práctica, este sistema garantiza la inmunidad a los ataques basados en análisis de paquetes.Los sitios web que adopten la tecnología TLS/SSL para garantizar la seguridad de los usuarios tendrán que recurrir a una autoridad de certificación (CA) de confianza, pues la 
autenticación HTTPS completa con una CA fiable es la única forma de que los usuarios sepan a ciencia cierta con quién están tratando. Vale la pena destacar que la nueva función SSL de Facebook es una opción del usuario y, por lo tanto, no se puede aplicar hasta que se haya iniciado una sesión. Como no se usa tecnología SSL de forma predeterminada en la página de inicio, ésta es vulnerable a las interceptaciones o ataques de spoofing. Relación entre el coste y las ventajas de la tecnología TLS/SSL.  La tecnología TLS/SSL es compatible prácticamente con todo tipo de software y hay muchos profesionales con los conocimientos necesarios para usarla, así que el único motivo para prescindir del protocolo HTTPS en un sitio web podría ser el coste. Para saber a cuánto puede ascender, hay que valorar principalmente dos aspectos. En primer lugar, los certificados no son gratis, pero tienen 
un precio fijo y previsible. En cambio, los costes del hardware adicional necesario son difíciles de calcular a priori. Al usar tecnología TLS/SSL, todos los datos que se transfieren se tienen que cifrar y descifrar, con lo que se añade una carga de trabajo adicional que, en un sitio web de grandes dimensiones, podría suponer un coste de hardware considerable.




COMO FUNCIONA SSL Y EVOLUCIÓN



  1. El cliente envía el mensaje "hello" que lista las posibilidades criptográficas del cliente (clasificadas por orden de preferencia del cliente), como la versión de SSL, los grupos de programas de cifrado soportados por el cliente y los métodos de compresión de datos soportados por el cliente. El mensaje también contiene un número aleatorio de 28 bytes.
  1. El servidor responde con el mensaje "hello" del servidor que contiene el método criptográfico (conjunto de programas de cifrado) y el método de compresión de datos seleccionados por el servidor, el ID de sesión y otro número aleatorio.
Nota:
El cliente y el servidor deben dar soporte como mínimo a un conjunto de cifrado común; de lo contrario, el protocolo de enlace dará error. Generalmente, el servidor elige el conjunto de programas de cifrado común más potente.
  1. El servidor envía su certificado digital. (El servidor utiliza certificados digitales X.509 V3 con SSL.)
  1. El servidor envía el mensaje "hello done" de servidor y aguarda una respuesta del cliente.
  1. Al recibir el mensaje "hello done" del servidor, el cliente (el navegador web) verifica la validez del certificado digital del servidor y comprueba que los parámetros del mensaje "hello" del servidor son aceptables.
  1.  El cliente envía el mensaje "client key exchange". Este mensaje contiene el secreto pre-maestro, un número aleatorio de 46 bytes utilizado en la generación de las claves de cifrado simétrico y las claves de código de autenticación de mensajes (MAC), cifradas con la clave pública del servidor.
Nota:
No es necesario un proceso adicional para verificar el certificado digital del servidor. Si el servidor no tiene la clave privada que pertenece al certificado digital, no podrá descifrar el secreto pre-maestro y crear las claves correctas para el algoritmo de cifrado simétrico y el protocolo de enlace dará error.
  1.  El cliente utiliza una serie de operaciones criptográficas para convertir el secreto pre-maestro en un secreto maestro, del que se deriva todo el material de clave necesario para el cifrado y la autenticación de mensajes. A continuación, el cliente envía el mensaje "change cipher spec" para que el servidor conmute al conjunto de programas de cifrado recién negociado. El siguiente mensaje enviado por el cliente (mensaje "finished") es el primer mensaje cifrado con este método y estas claves de cifrado.
  1. El servidor responde con mensajes propios "change cipher spec" y "finished".
  1. El protocolo de enlace SSL finaliza y los datos de aplicación cifrados se pueden enviar.
SSL es un protocolo que proporciona privacidad e integridad entre dos aplicaciones de comunicaciones utilizando HTTP. El Protocolo de transferencia de hipertexto(HTTP) para World Wide Web utiliza SSL para que las comunicaciones sean seguras.
Los datos que circulan en un sentido y otro entre el cliente y el servidor se cifra mediante un algoritmo simétrico como DES o RC4. Un algoritmo de clave pública -generalmente RSA- se utiliza para el intercambio de las claves de cifrado y para las firmas digitales. El algoritmo utiliza la clave pública en el certificado digital del servidor. Con el certificado digital del servidor, el cliente también puede verificar la identidad del servidor. Las versiones 1 y 2 del protocolo SSL sólo proporcionan autenticación de servidor. La versión 3 agrega la autenticación del cliente, utilizando los certificados digitales de cliente y de servidor.

Una conexión SSL siempre es iniciada por el cliente. Al principio de una sesión SSL, se realiza un protocolo de enlace SSL. Este protocolo de enlace produce los parámetros criptográficos de la sesión. Una visión general simplificada de cómo se procesa el protocolo de enlace SSL se muestra en la. En este ejemplo se supone que se está estableciendo la conexión SSL entre un navegador web y un servidor web.

  1. Si el servidor utiliza SSL V3 y si la aplicación de servidor (por ejemplo, el servidor web) requiere un certificado digital para la autenticación de cliente, el servidor envía el mensaje "digital certificate request". En el mensaje "digital certificate request", el servidor envía una lista de los tipos de certificados digitales soportados y los nombres distinguidos de autoridades de certificación aceptables.
  1. Si el servidor ha solicitado un certificado digital del cliente, el cliente envía un certificado digital o, si no hay ningún certificado digital adecuado disponible, el cliente envía la alerta "no digital certificate". Esta alerta sólo es un aviso, pero la aplicación de servidor puede hacer que la sesión sea anómala si la autenticación del cliente es obligatoria.
  1. Si el cliente ha enviado un certificado digital al servidor, el cliente envía un mensaje "digital certificate verify" firmado con la clave privada del cliente. Al verificar la firma de este mensaje, el servidor puede verificar explícitamente la propiedad del certificado digital del cliente.
TLS no es propietario como si lo es SSL (Netscape), con lo cuál TLS podría tomarse como un estándar al desarrollar software. Durante el armado del cálculo MAC (código de autenticación del mensaje dónde se introduce información como numero de secuencia, etc) para iniciar la conexión, SSL no incluye a los campos de tipo de compresión y versión, dejánolos libres para el ataque. En TLS se toman los campos dentro del cálculo MAC, sin dejar datos insegurosSSL usa el algorítmo Fortezza Kea como uno de los algorítmo de intercambio, que tiene los valores públicos fijos contenidos en los certificados. Como este es inseguro, TLS directamente no lo soporta, evitando el uso de este. Es una buena medida, si no me da la seguridad necesaria, directamente lo dejo fuera……
Durante el primer cálculo del algorítmo de intercambio, TLS suma una nueva función llamada PRF, formando un nuevo campo y haciendo este intercambio más seguro. El función matemática es media compleja y amplia, pero si a alguno le interesa, pregunte en el blog que les paso la información de los algorítmos que usa SSL y el mismo usado por TLS con PRF para la mejora. Durante el intercambio SSL, cuando el servidor pedía un certificado al cliente, este le podía contestar con un no_certificate, TLS no permite este tipo de respuesta por parte del clientelogrando una transmisión segura entre CLIENTE-SERVIDOR, haciendo que el CLIENTE se autentiqueEn esta mejora entra en juego la parte de desarrollo o mantención del servidor, ya que si el servidor está a cargo nuestro y necesitamos que este seguro, una buena medida es que al momento de que el cliente pida conectarse, el servidor pida los certificados del usuario para ver a quien le permite la entrada.
TLS recibe una modificación para soportar autenticación Kerberos. Las credenciales Kerberos se usan para llevar a cabo una autenticación mutua y para establecer un master secret usado subsecuentemente para asegurar la comunicación CLIENTE-SERVIDOR.