SuperBiometría o más bien biometría en el super(mercado); eso es lo que de casualidad he encontrado navegando (o buceando más bien) por Internet y gracias a FrikiEconomía.
Cuando aquí en España lo más novedoso en los establecimientos de los centros comerciales -al menos que yo haya podido ver, es una tableta gráfica en la que firmas el resguardo de pago con tarjeta de la compra realizada en las tiendas Opencor y Sfera por ejemplo, al otro lado del charco nos llevan la delantera hasta en esto y ahora allí pagan con el dedo.
Según parece una cadena norteamericana de supermercados, no contentos con dar la opción de metálico, tarjeta o cheque (recordemos que esta modalidad de pago está muy extendida por allí), ha decidido implantar en todas sus tiendas la posibilidad de pagar mediante identificación biométrica por huella dactilar.
El cliente que se adhiera a esta nueva forma de pago debe rellenar el siguiente formulario bien online o bien en la tienda más cercana, dar los datos personales y bancarios y aceptar el consiguiente contrato para el servicio. Una vez hecho esto ya podrá elegir una forma más de pagar: a dedo.
Para ello el cliente presiona con el dedo en un dispositivo encargado de escanear la huella, de la que según se indica se extrae un patrón basado en puntos relevantes que posteriormente es comparada con la huella "patrón" que introdujimos al darnos de alta en el sistema. Además es preciso introducir una clave numérica de 7 caracteres para que, una vez validados ambos datos, se nos cargue el importe de la compra en la cuenta bancaria asociada a nuestro identificador.
Si bien esto no deja de ser una novedad y pone al alcance de todo tipo de personas la posibilidad de autenticarse mediante sistemas biométricos de seguridad, no debemos olvidar que estos sistemas no son infalibles. De hecho el canal "Discovery Channel" publicó recientemente un documental dentro de su serie Mythbusters (cazadores de mitos), demostraron que era posible llegar a burlar algunos de estos sistemas mediante algo tan simple como una fotocopia de la huella dactilar. Pongo varios enlaces al vídeo por que he visto que a veces es retirado por temas de copyright, por lo que los enlaces son éste, éste y éste.
No debemos olvidar que uno de los problemas que tiene el uso de huellas digitales como clave biométrica, es que es sensible a cambios en la fisonomía debido a, por ejemplo, heridas o quemaduras. Además hay sistemas que también son sensibles a la presión ejercida o incluso a nuestra temperatura corporal, existiendo en muchos casos una tasa de error relativamente elevada.
Otro punto en contra de la medida en esta cadena de supermercados es que pese a que es necesario realizar una doble validación mediante un código numérico de 7 cifras, el propio establecimiento propone y promueve que éste sea el número de teléfono del usuario, lo que claramente hace que este código en la mayoría de los casos tenga poca validez en materia de seguridad.
En cualquier caso al tratarse de una cadena de supermercados, aún que la posibilidad de fraude existe y por tanto hay que tenerla en cuenta, dudo mucho que alguien invierta lo suficiente para conseguir y falsificar una huella dactilar para comprar dos cartones de leche, patatas y 3 kilos de filetes.
Para los más curiosos el FAQ que la empresa ha hecho público y por mi parte...
Luego más.
jueves, 26 de julio de 2007
(In)Seguridad: SuperBiometría
Publicado por
Javier Mendoza
a las
0:54
|
Etiquetas: (in)seguridad, compras, curiosidades, noticias del mundo, Tecnología
lunes, 23 de julio de 2007
Privacidad: ¿Un valor al alza en los buscadores?
Se ve que la privacidad es un tema de moda en ciertos sectores tecnológicos. Si antes del fin de semana publicaba una noticia en la que se veía que el buscador Ask había tomado buena nota de los problemas que acontecían a Google por temas de privacidad, en esta ocasión veremos que no ha sido la única empresa en seguir el ejemplo.
Gracias a TechCrunch (via Wall Street Journal) y a 901am.com nos enteramos de que en esta ocasión han sido los chicos de Redmond así como los de Yahoo! los que han mejorado la privacidad de los usuarios de sus servicios.
Dentro de las nuevas medidas llevadas a cabo por Microsoft para convertir en anónimas las búsquedas realizadas desde "Live Search" se incluye la eliminación de los posibles identificadores como son la IP de origen o los identificadores en las cookies entre otras.
Por su parte Yahoo! indica que llevará a cabo un proyecto que permitirá, una vez finalizado, eliminar los datos relativos al usuario dentro de los 13 siguientes meses a la búsqueda.
Pero esto no es todo, Microsoft además se ha aliado con Ask para liderar un movimiento de concienciación de las empresas de Internet, que busca desarrollar y establecer una serie de principios para el uso, protección y almacenamiento de datos relacionados con las búsquedas y la publicidad online.
Ciertamente esto es una medida que acogemos con alegría, pero no sin cierta atención. ¿Casualidad que todos se pongan de acuerdo ahora en cambiar sus políticas de privacidad? Sinceramente no tenemos que ser tan inocentes. Claramente el precedente marcado por Google puede hacerse extensible en un futuro cercano a otros grandes buscadores, por lo que una razón de esta rápida movilización sea evitarse problemas a corto plazo.
Además, en el caso de Ask y Microsoft, estas políticas pueden ser un intento de hacerse eco de la creciente concienciación y madurez de los usuarios de Internet en materia de privacidad y aprovechar la ocasión para conseguir arañar cuota de mercado, mientras que por su parte Yahoo! tampoco quiere quedarse atrás y si Google anuncia 18 meses antes de eliminar la información sensible del usuario ellos anuncian que lo harán antes de 13 meses.
Señores, esto es una carrera con un caballo destacado, otro siguiéndole a cierta distancia y dos más peleándose para entrar en puestos de pódium y por supuesto todos quieren ganar.
Luego más.
Publicado por
Javier Mendoza
a las
23:49
|
Etiquetas: (in)seguridad, Ask.com, Google, Microsoft, mundo empresarial, opinión, privacidad, Yahoo
viernes, 20 de julio de 2007
Privacidad: Cambios en Ask.com y Anonymizer.com
En esta ocasión voy a comentar dos noticias breves que afectan a cambios en las políticas de privacidad de dos compañías conocidas por todos: Ask.com y Anonymizer.
Para empezar gracias a Slashdot nos enteramos que Anonymizer ha decidido dejar de ofrecer el servicio online gratuito de navegación anónima, haciéndose este hecho efectivo desde el pasado 20 de Junio. Recordemos que esta empresa ofrecía tanto directamente a través de su portal a través de una barra de navegación, como a través de una barra de herramientas instalable en local, de un servicio básico de navegación anónima, ésto es, sin javascripts ni otras tecnologías web.
Por tanto la empresa ahora sólo dispone de productos de navegación anónima de pago y de instalación en local. El problema es que dichos servicios sólo están disponibles para Windows e incluso la versión para Windows Vista está en actual desarrollo, lo que pone a la empresa en clara desventaja frente otras alternativas de navegación anónima y gratuita como la red Tor.
Por otro lado y en lo referente al buscador Ask.com, gracias a 901am.com descubrimos que ha tomado claro ejemplo de los problemas que ha tenido Google por su política de privacidad e intentan sacar provecho. Para ello prevén lanzar un nuevo servicio denominado "AskEraser" que una vez activo nos permitirá navegar sin que nuestra sesión quede reflejada ni almacenada en el historial de Ask.com.
Si no se demoran mucho con el lanzamiento de este nuevo servicio, esta decisión puede suponer un incremento en su número de usuarios y por tanto arañarle un poco de terreno a sus grandes rivales como Google y Yahoo!.
Y por mi parte, luego más.
Publicado por
Javier Mendoza
a las
16:33
|
Etiquetas: (in)seguridad, mundo empresarial, privacidad
(In)Seguridad: El problema de las puertas traseras institucionales
Una puerta trasera en una aplicación es un mecanismo alternativo de acceso o salida por el cual, todo aquel que sepa los "pasos" necesarios para abrir dicha puerta puede acceder a o salir de la aplicación independientemente de los pasos estándar que se haya establecido para ello.
Ésto que bien usado es una potente ayuda en caso de contingencia, puede ser una peligrosa amenaza si cae o es descubierto por las manos equivocadas, tal y como ha quedado de manifiesto en el pasado caso que ha alarmado a la sociedad griega y que pone en entredicho la seguridad del binomio Vodafone-Ericsson.
"La Tejedora" se ha hecho eco de una noticia que ya apareciera en importantes medios como el "Wall Street Journal" o la publicación que posee el organismo IEEE y que hace referencia a las escuchas ilegales que se registraron en este país durante más de medio año a lo largo del 2004 y principios del 2005.
El escándalo saltó cuando a mediados de Marzo del 2005, un responsable de la compañía de telefonía móvil Vodafone, contactaba con el primer ministro griego para alertarle sobre una brecha crítica de seguridad. Según parecía, se habían detectado mecanismos en la red de Vodafone que permitían realizar escuchas ilegales y rastreando las líneas afectadas y uno de los primeros números en aparecer como afectados había sido el suyo. Finalmente más de 100 líneas de teléfono se detectaron intervenidas, incluyendo las de los políticos más importantes, altos cargos policiales, embajadores de otros países, etc.
Las investigaciones revelaron que al menos 14 teléfonos de prepago recibían una copia de las llamadas intervenidas además de recibir un mensaje de texto con información relativa a la llamada como duración, localización o participantes. Dichos teléfonos fueron encontrados abandonados tras parchear y sanear las arquitecturas afectadas, lo qué alertó a los delincuentes dándoles tiempo a huir y desaparecer.
Por su parte las empresas implicadas culpan a la otra del percance. Vodafone se excusa en que pese a conocer que los aparatos de Ericsson incluyen la posibilidad de comprar un set para permitir las escuchas legales, desconocía que dicho mecanismo se encontraba instalado por defecto en todos los equipos permaneciendo en estado latente hasta la aplicación de dicho set de herramientas. Ericsson indica por el contrario que por su parte si había notificado dicho asunto a Vodafone. Además asegura que los equipos instalados en el resto de operadoras de telefonía móvil del país están libres de riesgo y que para poder intervenir las lineas, tuvo que hacerse desde el interior, desde las oficinas de Vodafone.
Según parece, los atacantes estudiaron el código que permitía la intervención legal de llamadas desarrollado por Ericsson para encontrar vulnerabilidades del mismo. Una vez detectadas, bastaron 6500 líneas de código para conseguir el efecto deseado de manera casi invisible para la operadora, y lo hubiera sido de no ser porque estos "pinchazos" provocaron fallos en los terminales de las personas afectadas. Fué cuando la compañía investigaba estas incidencias y gracias a la colaboración de Ericsson que llegaron a la conclusión de que había algo que no cuadraba en el problema, lo que finalmente llevó a la detección del incidente comentado aquí.
Aparentemente y a día de hoy dicho problema está resuelto, pero ésto debería mantenernos alerta de los problemas que pueden traer las medidas antiterroristas que las instituciones muchas veces obligan a instalar en las grandes compañías, por lo que habría que examinar con lupa y hacer un balance lo más objetivo posible acerca de los pros y contras de la implantación de estas medidas.
Y por mi parte, luego más.
Publicado por
Javier Mendoza
a las
12:43
|
Etiquetas: (in)seguridad, mundo empresarial, noticias del mundo
miércoles, 18 de julio de 2007
Artículo: Evolución de los cortafuegos
Después de hablar en una de las últimas entradas acerca de los firewalls o cortafuegos de capa de aplicación, he recibido algún correo en el que me solicitan que explique ésto un poco más, en vista de lo cuál he recuperado y desempolvado un fragmento de un artículo que publiqué hace tiempo en el que se explica un poco la evolución y tipos de cortafuegos.
Comencemos.
Paso 1: Los comienzos.
··············································
Los primeros cortafuegos se desarrollaron a finales de los 80, principios de los 90. Éstos sistemas inicialmente estaban basados en el filtrado estático de paquetes. Dicho filtrado básicamente comprueba la red/puerto de origen y la red/puerto de destino, por lo que rápidamente se observó que no cubría todas las necesidades requeridas.
La primera ventaja de estos cortafuegos es su velocidad de proceso ya qué sólo se analizan las capas bajas de la pila OSI. Más exactamente las capas inspeccionadas en este caso son la 3 o capa de red (ip origen e ip destino) y la 4 o capa de transporte (puerto origen y puerto destino).
Más ventajas a comentar es que son transparentes para el cliente, no requieren de grandes prestaciones de las máquinas en las que se ejecutan y al ser un filtrado básico, la mayoría de los enrutadores y otros dispositivos de red lo implementan per se.
Sin embargo la implantación de reglas es larga y costosa ya que al ser un filtrado básico y no disponer de un mecanismo para realizar un seguimiento de las conexiones, es necesario un mayor número de reglas para cubrir la política deseada. Esto es así porque se hace necesario tener una regla para permitir un sentido de la comunicación y otra para permitir la respuesta de dicha comunicación, es decir, es necesario permitir implícitamente el sentido contrario.
Paso 2: "Ligeros" cambios.
······················································
Viendo el problema que se planteaba con el filtrado estático de paquetes, la siguiente evolución la introdujo el cortafuegos basado en el filtrado dinámico de paquetes o "Stateful Inspection" (Inspección de Estados).
Esta tecnología permite filtrar los paquetes por cualquier elemento existente en la cabecera ip. Además, incorpora una tabla de estados de conexión por lo que se añade potencia al poder usar estos estados como regla de filtrado. También modifica automáticamente la política de filtrado según dicha tabla de conexiones, con lo que se reducen la complejidad y el número de reglas necesarias para realizar el filtrado, puesto que ya no es necesario el uso de reglas adicionales para permitir la respuesta de las conexiones permitidas.
Pese a que hay fabricantes que se refieren a estos cortafuegos como de tercera generación, la tecnología usada en ellos se podría definir como una extensión de la tecnología anteriormente descrita. Como ya hemos visto mejora considerablemente los cortafuegos de filtrado estático de paquetes, pero carece todavía de la posibilidad de filtrar la parte de datos de los paquetes.
Paso 3: Una vuelta a la tortilla.
·······························································
La siguiente evolución se implementó en los llamados proxies. Estos elementos hacen de intermediarios entre el cliente y el servidor final haciendo las veces de pasarela. Básicamente lo que hacen es analizar los paquetes que conforman la sesión, reensamblarlos únicamente con datos validados y crear una nueva conexión al servidor por dónde se enviarán los nuevos paquetes creados.
Esto supone un cambio con respecto a los cortafuegos de filtrado de paquetes ya que recordemos que éstos no modificaban el paquete original y además creaban una conexión "directa" entre el cliente y el servidor, no hacían de intermediarios como ocurre en este caso.
Existen 2 tipos de estos elementos de seguridad: proxies de circuito y proxies de aplicación. Los primeros trabajan en la capas OSI 4 o capa de transporte y/o 5 o capa de sesión creando un circuito virtual entre el cliente y el servidor, sin analizar el contenido de dicho circuito.
Los proxies de aplicación trabajan en la capa OSI 7 o capa de aplicación. Éstos analizan la parte de datos del paquete, no su cabecera como en casos anteriormente analizados, tomando luego la decisión de aceptarlo o rechazarlo en función de ciertos parámetros previamente establecidos.
La ventaja de estas tecnologías es que se incrementa notablemente el nivel de seguridad. Por otro lado son dependientes de la aplicación, por lo que suele ser necesario utilizar varios proxies para proteger todos los servicios que un posible cliente pueda tener, mientras que generalmente con un cortafuegos de filtrado de paquetes se protege una red entera. Esto provoca que sea más costoso en términos de requerimientos su implantación. Además no suelen ser transparentes para el cliente y al tener que desensamblar el paquete en su totalidad, analizarlo y volver a ensamblarlo, tienen un rendimiento bastante inferior.
Paso 4: Estado actual.
·············································
La realidad es que a día de hoy hay pocos avances más en materia de cortafuegos y podemos encontrarnos elementos de red de todos los tipos enumerados anteriormente. De este modo es posible encontrarnos cortafuegos de filtrado estático en la mayoría de los elementos de electrónica de red (routers, switches, etc), llegando incluso al mercado residencial. Hoy en día la mayoría de los routers que las compañías de xDSL y cable instalan utilizan ésto para su módulo de filtrado.
A nivel comercial, los productos que actualmente se comercializan ofrecen todas las tecnologías anteriormente descritas, llegando incluso a permitirnos realizar tareas de proxy en múltiples protocolos al mismo tiempo sin utilizar varios cortafuegos para ello. Las diferencias entre unos productos y otros se refieren al rendimiento, las capacidades de gestión y tamaño de la base de datos de los patrones o firmas de los ataques reconocidos.
Y hasta aquí esta pequeña introducción al mundo de los cortafuegos. Por mi parte espero haber resuelto las dudas que había y como siempre,
Luego más.
Publicado por
Javier Mendoza
a las
1:37
|
Etiquetas: (in)seguridad, artículos, formación, proyectos
martes, 17 de julio de 2007
Google: Cookies y Cross Site Scripting (XSS) (II)
Los que hayan leido el post anterior, habrán visto que me he centrado en la segunda parte y he hablado acerca de la política que Google está llevando a cabo para proteger y asegurar sus aplicativos web de cara a ataques como XSS, dejando apartado el primer asunto del título.
En este post por tanto voy a continuar con la noticia y hacerme eco de las novedades en materia de privacidad que está acometiendo Google, que como os imaginareis hacen referencia al manejo de las cookies.
Por todos es sabido el revuelo que se produjo recientemente en Internet en general y en el mundo de las TI en particular acerca de que según su nueva política Google mantenía la información relativa al uso de sus productos, incluyendo IP y otro tipo de datos "personales" entre 18 y 24 meses.
Este hecho fue investigado por un grupo de expertos en la Unión Europea y tras una serie de conversaciones entre las partes, finalmente Google decidió fijar en 18 meses el tiempo máximo de retención de datos personales de sus usuarios.
Pues bien, según parece estos hechos han dado que pensar a la empresa acerca de dónde está el equilibrio entre privacidad y compromiso y ha rectificado en aras de recuperar algunos puntos perdidos con el gran público.
Según su blog oficial, trás estudiar las distintas impresiones al respecto, finalmente Google ha decidido reducir el tiempo de vida de las cookies que se almacenan en nuestros equipos. Ésto, que podría parecer prometedor parece más bien una acción de auto propaganda. Me explico: según ellos mismos dicen, inicialmente las cookies tenian el 2038 como fecha límite de validez (aquí hay una posible explicación para dicha fecha) mientras que ahora trás la nueva política, la validez de dichas cookies es de dos años máximo, lo cual, sigue siendo bastante.
En cualquier caso, que hayan dado este pequeño paso aún a pesar de que aparentemente es sólo promocional, debería ser significativo para el usuario, ya que actualmente la inmensa mayoría de las páginas y servicios web que visitamos nos dejan su huella y su pequeño espía en forma de cookie, que permanece ahí en muchos casos hasta que un problema de fuerza mayor nos obliga a formatear el disco...
Prefiero no seguir con el tema, que me da por pensar que cada vez nos parecemos más a un mundo orwelliano, en el que seguridad y privacidad son más metáforas que realidades.
Y por mi parte luego más.
Publicado por
Javier Mendoza
a las
3:33
|
Etiquetas: (in)seguridad, Google, opinión, proyectos, servicios Google
Google: Cookies y Cross Site Scripting (XSS) (I)
Tranquilos, no es que esté molesto con la gente de Google por no dejarme jugar a "The Ultimate Search For Bourne With Google" desde linux y por tanto vaya a revelar información sensible acerca de como usar las cookies de sesión para realizar un ataque de Cross Site Scripting (XSS).
Más bien al contrario, en esta ocasión voy a comentar dos noticias aparecidas en sendos blogs del gigante de Internet acerca de innovaciones y/o cambios en sus políticas de seguridad.
Por un lado, en el blog oficial de seguridad nos indican, tras una breve introducción de qué es un ataque de Cross Site Scripting y algunos consejos prácticos sobre como mitigarlos, las medidas que Google está tomando para securizar sus aplicativos web.
Según Srinath Anantharaju, autor de la noticia y miembro del equipo de seguridad, su equipo ha desarrollado un sistema de pruebas llamado "Lemon", el cual utilizan para inyectar peticiones a sus aplicativos web y ver las debilidades de éstos ante este tipo de ataques. Además según comenta, estas pruebas les han ayudado a encontrar otros fallos de seguridad.
En mi opinión, hay que aplaudir este tipo de medidas por parte de empresas de tan gran envergadura, si bien es cierto que considero que este tipo de medidas deberían ser de obligado cumplimiento para todas las empresas que ofrezcan desarrollos o servicios web. Ahora a ver si el resto de empresas se va concienciando poco a poco (o mucho a mucho) de la situación y problemática actual y empieza a poner medidas.
Además seria conveniente que se empezara a popularizar el uso de los denominados firewalls de [capa de] aplicación. Estos elementos también llamados firewalls de capa 7, realizan su labor en la capa 7 del modelo de referencia OSI. Para ello interceptan las peticiones de un protocolo determinado (en nuestro caso HTTP) a modo de proxy; examinan y filtran el contenido de dicha petición; en caso de no ser rechazada la re-encapsulan y reenvían al servidor que corresponda; una vez que éste responde, se analiza la página web resultante que se va a devolver para comprobar que no hay patrones sospechosos; se elimina todo el contenido "anómalo" de la respuesta y el resultado se le envía al usuario final.
Por supuesto esta medida no excluye la securización de código. Recordemos por ejemplo el caso de los ataques de Blind SQL, que resultan exitosos pese a no obtener información a través del aplicativo web, por lo que ambas soluciones deberían ser siempre complementarias la una de la otra.
Como este post se me está alargando un poco más de lo debido, lo continúo en el siguiente y así facilito la lectura.
En seguida más.
Publicado por
Javier Mendoza
a las
2:19
|
Etiquetas: (in)seguridad, Google, opinión, proyectos
jueves, 12 de julio de 2007
(in)Seguridad: vulnerabilidad en Windows Vista permite denegación de servicio remota
Según acabo de leer en Kriptópolis, se acaba de publicar una vulnerabilidad en SecurityFocus, según la cual es posible llegar a provocar un ataque DoS (Denial of Service, Denegación de Servicio) de manera remota. Por supuesto esto incapacita a usuarios válidos del sistema a iniciar sesión una vez que dicho ataque ha sido llevado con éxito.
Dicha vulnerabilidad fué expuesta por Justine Aitel en la conferencia de seguridad SyScan, realizada recientemente en Singapore. En dicha ponencia Justine terminaba la presentación con una captura de pantalla bastante impactante. La imagen era esta:
En palabras de Justine, esto es sólo la punta del iceberg por lo que, de ser cierto, deja un poco en entredicho todo lo que se ha venido comentando acerca de la seguridad y confiabilidad del nuevo sistema operativo de la empresa de Redmon, quién por su parte aún no se ha pronunciado al respecto. Habrá que esperar a ver como evolucionan los acontecimientos y ver finalmente quien está en lo cierto en sus afirmaciones.
Como último dato indicar que a día de hoy ni se ha confirmado ni desmentido públicamente la posibilidad de ejecución remota de código a través de esta vulnerabilidad, por lo que no se puede descartar que efectivamente se pueda.
En cualquier caso para los más curiosos que quieran ver la presentación, podéis conseguir el pdf íntegro aquí.
Y por mi parte, luego más.
Publicado por
Javier Mendoza
a las
12:48
|
Etiquetas: (in)seguridad, Microsoft
martes, 10 de julio de 2007
(In)Seguridad: Google apuesta por la seguridad corporativa y compra la empresa Postini
Ayer podíamos leer en varios de los blogs oficiales de Google, como el oficial y el enfocado a empresas, la noticia que hacía pública la compra de Postini, empresa con presencia internacional y enfocada a la seguridad online por un valor de 625 millones de dólares.
Postini es una empresa californiana con delegaciones en Norteamérica, Europa. África y Ásia y que actualmente cuenta con 35000 clientes empresariales y más de 10 millones de usuarios finales. Su negocio estriba en ofrecer soluciones on-line y bajo demanda para la seguridad de correo, mensajería y navegación, además de cifrado y almacenamiento.
Con este movimiento Google viene a consolidar su posición frente a la seguridad y es que hasta los productos del gigante de Internet sufren de problemas. Recientemente acusaron el golpe tras publicarse fallos de seguridad en Google Desktop, pero anteriormente otros productos como GMail y Google Talk también se habían visto comprometidos (noticias relacionadas aquí, aquí y aquí).
Debido a esto Google ha puesto en marcha una serie de proyectos con objeto de conseguir que sus productos sean cada vez más seguros y fiables. Ejemplos que se engloban en esta línea son, entre otros, la compra en mayo de este año de la empresa de virtualización de sistemas Greenborder (noticia aquí), la creación de un blog oficial destinado en exclusiva a la seguridad online, el patrocinio del proyecto de avisos sobre "badware" stopbadware.com o la extensión para el navegador Firefox "Google Safe Browsing", que nos avisa sobre posibles intentos de "phising" en nuestra navegación.
En este caso y tal y como se nos comunica en el propio comunicado de prensa que Google ha hecho oficial, este producto está centrado principalmente en su suite empresarial "Google Apps". Recordemos que esta suite está pensada para aquellas empresas que quieran iniciarse en el mundo de las nuevas tecnologías de una manera sencilla y obtener servicios de correo corporativo, agendas, mensajería corporativa o incluso creación de páginas webs a bajo coste. Esta nueva adquisición dotará de más servicios de valor añadido a estos programas ofreciendo capacidades avanzadas de identificación y eliminación de spam y malware, cifrado y almacenamiento (entre otras) a las empresas clientes, lo cual vuelve a ser un paso adelante en la política empresarial de Google.
En cualquier caso para los más interesados en la operación, podéis encontrar el FAQ con todos los datos sobre la misma aquí.
Y por mi parte y como siempre, luego más.
Publicado por
Javier Mendoza
a las
10:11
|
Etiquetas: (in)seguridad, Google, mundo empresarial, negocios, proyectos, servicios Google
sábado, 7 de julio de 2007
(In)Seguridad: Nuevo sitio de subastas on-line enfocado a las vulnerabilidades informáticas
Gracias a los chicos de Dark Reading nos enteramos de esta noticia sobre un nuevo portal en internet. Dicho portal es un sitio de subastas al estilo de eBay en el que expertos de seguridad pueden ssubastar sus descubrimientos, vulnerabilidades, exploits, bugs, etc.
Para los más impacientes, este proyecto ha sido desarrollado por "WabiSabiLabi", un laboratorio independiente de seguridad con sede en Suiza. Dicho proyecto pretende ser una vía pública, fiable y legal para el contacto entre empresas y expertos en seguridad, con el fin de que estos últimos puedan ver recompensados sus esfuerzos, investigaciones y descubrimientos.
Según la compañía, ellos guiarán a los vendedores en todo el proceso, consiguiendo de esta forma que el interesado obtenga los máximos beneficios posibles de la venta. Actualmente hay 3 formas de vender un "artículo". Por un lado está la opción tradicional de sacarlo a subasta durante un período de tiempo. Por otro está la posibilidad de vender el descubrimiento a un grupo de compradores, siendo está vez el precio fijo y prefijado. Y por último es posible vender a un único comprador a un precio fijo.
Por su parte, miembros de WSLabi aseguran que no pretenden que este portal se convierta en un hervidero de información para cyber-delincuentes y para ello informan de que todos los compradores serán meticulosamente investigados para verificar que en todo momento se cumpla legalmente.
Del mismo modo y para garantizar que los descubrimientos no son simplemente humo, el laboratorio asegura que analizará todos los artículos que se intenten subastar antes de que la subasta pueda llegar a hacerse efectiva. Además también se investigará al vendedor y el origen del descubrimiento para evitar que se intente vender información obtenida ilegalmente. De esta forma también se vela por los intereses de los posibles compradores.
Por supuesto toda la información sensible referente a compradores y vendedores es confidencial y según nos indican ningún dato aparte de los nicks serán almacenados en los servidores en los que se aloja esta iniciativa. Por contra, dicha información será almacenada en servidores seguros sin relación con dichos servidores web.
Resumiento la web en cuestión es la siguiente: WSLabi MarketPlace y actualmente están en subasta 4 vulnerabilidades, entre ellas un fallo de memoria en el kernel de linux.
Aún así mi opinión al respecto es la siguiente: el proyecto en si, sí realmente están contemplados y cubiertos todos los posibles problemas entre compradores y vendedores me parece una idea muy interesante.
Por supuesto la empresa se quedará con una comisión del importe total de la transacción por lo que queda clara la intención de lucro del proyecto.
Pero me sigue quedando una duda: todo esa iniciativa está siendo llevada a cabo, no lo olvidemos, por un laboratorio de seguridad informática independiente, que será el que en última instancia probará y verificará la autenticidad de los bugs, vulnerabilidades y fallos de software subastados, por lo que ¿tan descabellado es pensar que puedan utilizar esa información para, digamos por ejemplo, desarrollar sistemas de seguridad que poder vender posteriormente de forma "independiente"?
Ahí queda lanzada la pregunta, por mi parte y como siempre, luego más.
Publicado por
Javier Mendoza
a las
2:17
|
Etiquetas: (in)seguridad, compras, mundo empresarial, negocios, noticias del mundo, opinión, proyectos

