Security Art Work

Sabemos que las MIFARE Classic están totalmente rotas, como hemos podido comprobar en los posts anteriores de esta saga. Las claves de lectura y escritura de las zonas de memoria son fácilmente recuperables. Ahora nos queda enfrentarnos al último bastión de las tarjetas: el Unique Identification Number (UID).

En el Sector 0 Block 0 de la tarjeta, conocido como el Manufacturer Block es donde podemos encontrar almacenado el identificador único de la tarjeta o UID.

Ese UID es el número de serie de las MIFARE. Cada tarjeta tiene el suyo propio, consta de 4 bytes, y en principio es de sólo lectura.

Por eso las implementaciones que aún se basan en las MIFARE Classic confían en ese número para identificar los usuarios. Podemos fácilmente encontrar sistemas de ese estilo en puertas de acceso y en parkings por ejemplo.

[Read more…]

En esta entrada dentro de la serie de Fundamentos sobre Certificados Digitales nos vamos a centrar en uno de los requisitos fundamentales a tener en cuenta por cualquier Autoridad de Certificación (CA). Este requisito no es una opción, sino una obligación establecida para cualquier normativa o legislación aplicable relativa a la generación y tratamiento de certificados digitales. Estamos hablando de las Declaraciones de Prácticas de Certificación y de las Políticas de Certificación. Como siempre, vayamos paso a paso.

Una Declaración de Prácticas de Certificación (CPS) es un documento propio de cada CA en el que se declaran y establecen un conjunto de compromisos que adquiere la entidad respecto las prácticas para la gestión del ciclo de vida de los certificados digitales que emite, así como un conjunto de medidas de seguridad del entorno. Este documento es en sí un compromiso adquirido, que se referencia al mismo en todos los certificados emitidos en un campo establecido a tal efecto (en próximas entradas detallaremos la estructura estándar de los certificados).

Por otro lado, una Política de Certificación (CP) es del mismo modo un conjunto de compromisos adquiridos por la CA con los usuarios de sus certificados, aunque en este caso, este documento únicamente hace referencia a un tipo concreto de certificados dentro de la jerarquía. Por tanto la Política de Certificación únicamente afecta a una tipología concreta de certificado de CA Subordinada (este concepto se explica de forma detallada en otra de las entradas de esta serie, concretamente la que hace referencia a Cadena de Confianza). Este mecanismo le facilita a la CA la capacidad de establecer unas directivas de certificación globales y comunes mediante la Declaración de Prácticas de Certificación, así como la posibilidad de establecer requisitos concretos para tipos de certificado concreto cuando proceda.

Es importante destacar que en ningún caso es una obligación la implementación de Políticas de Certificación, por lo que se deja a elección de la CA su implementación en base a sus requisitos y necesidades.

El siguiente punto a abordar será, evidentemente, establecer o identificar los contenidos y requisitos que deben cumplir estos documentos. A este respecto, y comenzando por el ámbito Español, la Ley de Firma Electrónica (Ley Orgánica 59/2003) en uno de sus artículos menciona la obligación de construir y mantener publicada en un medio gratuito una Declaración de Prácticas de Certificación. Se puede obtener más información de la presente ley en pasadas entradas de esta serie Ley de Firma Electrónica I y II. Según dicho texto, el documento que debe cumplir al menos con los siguientes requisitos:

• Obligaciones del Prestador de Servicios de Certificación (CA) respecto a los datos de creación y verificación de la firma o certificados expedidos.

• Condiciones para la solicitud, expedición, uso, suspensión y extinción dela vigencia de los certificados.

• Medidas de seguridad técnica y organizativa.

• Roles y responsabilidades del personal implicado en el servicio.

• Condiciones y acceso a mecanismos de información sobre la vigencia de los certificados.

Como último punto determinante, se establece que las Declaraciones de Prácticas de Certificación tendrán validez como Documento de Seguridad en el ámbito de la Ley Orgánica de Protección de Datos de Carácter Personal (Ley Orgánica 15/1999). Sin embargo, y como a más de uno le puede haber parecido, esta especificación es muy generalista, por lo que para alguien que no tenga experiencia en la confección de este tipo de documentos dentro del ámbito de la constitución de una CA puede llegar a ser muy complicado y ambiguo.

Adicionalmente a los requisitos legales establecidos en España, a nivel internacional se han establecido distintos estándares destinados a establecer requisitos mínimos de calidad y seguridad en la implementación y operación de una Infraestructura de Clave Pública (PKI), así como del establecimiento de una CA. Para el caso que nos ocupa, la confección de una Declaración de Prácticas de Certificación, se han establecido diversos estándares, se destacan los siguientes:

• RFC 3467 y RFC 2527: Estos documentos llamados RFC, establecen una guía estricta de los puntos que debe contener una Declaración de Prácticas de Certificación. El primero de ellos, la RFC 3467, se incluye dentro del denominado “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”, propuesto por el “Network Working Group”. Relata con un elevado nivel de detalle los contenidos y estructura que debe tener el documento, y se considera un estándar internacional para la construcción de CPS. El segundo de ellos (RFC 2527) es una versión anterior de la RFC 3467, de los que únicamente se identifican algunas modificaciones.

• WebTrust for Certification Authorities v1 CA Business Practices Disclosure Criteria: Del mismo modo que en el caso anterior, la especifiación establece un guión cerrado para los contenidos de una Declaración de Prácticas de Certificación, aunque en este caso se ha establecido por organismos distintos. Concretamente, los responsables de esta especificación son dos organismos estatales en primer lugar el “Canadian Institute of Chartered Accountants” (CICA), y en segundo lugar el “American Institute of Certified Public Accountants” (AICPA). A su vez, es importante destacar que estos organismos son responsables del estándar Webtrust, que marca directivas para la implantación de controles en las CA que regulan desde el ciclo de vida de los certificados digitales hasta las medidas de seguridad a aplicar en su entorno; entre otros puntos.

Nos vamos a centrar en la especificación establecida por la RFC 3467, que en mi humilde opinión, es la de uso más extendido en lo que a CPS se refiere. Dado que se trata de una especificación muy detallada y concreta, se va a abordar a grandes rasgos; así como finalmente, y con el fin de completar la información de esta entrada, se propondrá la lectura (o al menos el repaso), de un ejemplo real de Declaración de Política de Certificación. La especificación de la RFC 3467 se encuentra publicada en el siguiente enlace:

http://www.ietf.org/rfc/rfc3647.txt

En la próxima entrada detallaremos a grandes rasgos el contenido de la RFC, así como mostraremos un ejemplo real de CPS. Muchas gracias por leernos.

Hace ya un tiempo que estamos pensando alguna manera de mejorar en la detección de Malware y APTs y se nos ocurrió montar una sandbox que analizara ficheros automáticamente y nos generará un informe con los datos.

Esta idea no es nueva, es más algunas de las mejores marcas del sector ya ofrecen soluciones de este tipo. También existe una solución gratuita de sandbox.

Básicamente lo que hace este tipo de sandbox es ejecutar ficheros en una máquina virtual y generar informes de los cambios y conexiones que se realizan en este sistema. Una vez ejecutado el fichero la máquina virtual vuelve al estado inicial.

A continuación vamos a ver la instalación y configuración básica de esta sandbox.

[Read more…]

En múltiples ocasiones hemos hablado en este blog de tshark como herramienta de análisis forense de red. Esta herramienta proporciona una versatilidad que se va ampliando con cada nueva versión, donde se le añaden nuevos filtros y mejoras.

Supongamos que nos encontramos analizando un incidente de seguridad en el que tenemos tráfico hacia varios servidores ubicados detrás de una misma dirección IP. Debido a esto, no se puede filtrar por dirección IP así que hay que buscar otra solución. En este artículo voy a mostrar una manera de extraer únicamente aquellos paquetes que están relacionados con un servidor (host) y no con una dirección IP.

Para ilustrar el ejemplo voy a utilizar un archivo de captura de tráfico en formato PCAP descargado desde NETRESEC de una máquina infectada con W32/Sdbot, proporcionado por Russ McRee.

Cuando estamos analizando tráfico hacia un servidor web podemos ver los paquetes enviados por el cliente utilizando el filtro “http.host==” (p.e, http.host==www.age.ne.jp):

El problema es que únicamente se muestran los enviados hacia el servidor, ya que se basa en el parámetro Host de la cabecera HTTP. En el caso en el que queramos capturar también la respuesta podremos utilizar el filtro tcp.stream pero debemos hacer un paso previo; para ello recordaremos este filtro.

El filtro “tcp.stream” es un valor que tshark asigna a los paquetes en función del flujo TCP al que pertenecen, así aquellos paquetes que formen parte de una misma conversación o flujo TCP tendrán el mismo valor.

La idea que pretendemos llevar a cabo es identificar los flujos TCP que vayan dirigidos al host que queremos para, posteriormente, extraer todos los paquetes que sean de esos flujos TCP, no sólo las peticiones HTTP.

Primero listamos el flujo TCP de los paquetes dirigidos al host:

Ahora un poquito de Kung-Fu, y listo:

Lo que se ha hecho en la captura anterior es obtener el mismo listado y realizar otra búsqueda utilizando el filtro tcp.stream con esos valores, por tanto recorremos el archivo un número de veces igual al número de flujos anterior y creamos un archivo (stream{n}.pcap) por cada uno de ellos. Finalmente, se fusionan en un único archivo PCAP con mergecap, llamado www_age_ne_jp.pcap.

Para ver que no sólo tenemos las peticiones al servidor sino también las respuestas de éste, mostramos el contenido del archivo:

Para comprobar que las peticiones son hacia el servidor que queremos mostramos únicamente los campos de dirección IP origen y destino, el host al que va dirigida la petición HTTP y el flujo TCP al que corresponden (el valor tcp.stream varia porque es relativo al propio archivo PCAP, no obstante se puede comprobar que el número de flujos es el mismo):

Por último, como nota añadida a esta manera de extraer aquellos paquetes que nos interesan, recalcar que el archivo se procesa un número de veces igual al de flujos que devuelva la operación anterior. Esto, si el archivo con el que estamos trabajando es muy pesado, puede sobrecargar el sistema.

Para evitar esto, en lugar de utilizar el filtro para un único flujo, se encadenan todos los filtros con un OR y así sólo procesamos el archivo una única vez, aunque se hagan más comprobaciones.

Mientras que el tiempo para ejecutar el comando de la primera manera es:

Quizá éste archivo no sea el mejor ejemplo ya que su tamaño es pequeño, aunque se puede apreciar que se reduce en más de una quinta parte el tiempo real de proceso.

Por experiencia propia, en una búsqueda similar en un archivo de 4 GB la diferencia está entre tres minutos para su ejecución con la primera opción, y no terminar tras más de una hora con la segunda.

Espero que os sirva para futuras búsquedas.

Como bien indica el título, existen sistemas que nos pueden hacer la vida mucho más fácil, sobre todo a la hora de administrar múltiples equipos en lugares como universidades, centros públicos etc…

Este tipo de sistemas protegen nuestra máquina obligando a que sea “autista”, esto quiere decir que todo cambio que se produzca en la máquina volverá a ser subsanado tras su reinicio de forma inmediata.

Esto puede dar muchas ventajas, pero poca libertad al usuario que está usando el equipo. Poca libertad porque no va a poder guardar ningún cambio en el equipo, pero si en una unidad de almacenamiento propia, por ejemplo un pen drive USB.

Las ventajas son varias, ya que un usuario poco experimentado puede borrar un archivo de configuración que no debe, o puede infectar la máquina con un virus porque el pen drive que ha introducido estaba infectado, porque ha abierto un correo que no debía o porque ha visitado una URL que era de carácter malicioso y en cada uno de estos casos, se podrá restaurar el sistema inmediatamente.

No hay problema porque siempre que ocurra algo así con solo reiniciar el sistema queda como al principio, es como si se clonara el disco, o discos duros, justo cuando está todo instalado y en perfecto funcionamiento y cada vez que reiniciamos esa imagen se restaurase de nuevo, pero sin esperar.

Estos sistemas se venden en el mercado y los hay de diversos tipos, ya que pueden funcionar únicamente por software, pero los hay que también funcionan por hardware.

¿Dónde es conveniente usar este tipo de sistemas? Pues en universidades, colegios, centros públicos etc…, zonas donde los ordenadores están expuestos a todo tipo de personas.

Existen productos como Custodius:

Este tipo de tarjetas, con conexión PCI, permite la restauración instantánea al reiniciarse el equipo (sólo en sistemas Windows). Para poder hacer cambios en el sistema, sólo hace falta pulsar las teclas ctrl+enter al inicio e introducir la contraseña de administración, entonces se entra en modo supervisor para poder guardar los cambios necesarios.

La restauración no tiene por qué ser sólo instantánea, también puede ser desde un backup o respaldo, y aquí sí que se incluyen sistemas UNIX, Linux y Windows.

La protección se puede hacer sólo de una partición o disco determinado o de todos los discos y particiones que tenga el sistema (soporta hasta 48 particiones y hasta 3 discos). Además es capaz de proteger la BIOS para que no se produzcan cambios en ella.

Obviamente toda esta protección no vale de nada si alguien con un simple destornillador puede extraer la tarjeta, por lo tanto esto tiene que ir acompañado de un sistema de sellado del equipo que impida que se abra la torre del equipo de forma sencilla.

Otra función que contempla es la de SNCOPY, donde un equipo ya configurado es capaz de funcionar conjuntamente con la tarjeta de red y clonarse en otros equipos con las mismas tarjetas, configurando así muchos equipos clonándose la configuración del anfitrión.

Otro producto de características parecidas es Deep Freeze. Funciona sólo por software y de forma parecida a Custodius, ya que al reiniciar el sistema vuelve a restaurar todo. Éste software “congela” la configuración del sistema, pero deja que los cambios por parte del usuario se produzcan por ejemplo en una unidad de red remota o en un espacio “descongelado”.

Esta empresa además presume de poder proteger el MBR (Master Boot Record), de inserciones de rootkits.

Aunque, esto no es del todo cierto, ya que según un artículo publicado en la página http://securitylabs.websense.com/ se hace un análisis sobre una variante de un malware llamado Robot Dog (malware destinado sobre todo a atacar a China y en concreto a cibercafés). Que es capaz de hacer que el software de recuperación no actúe correctamente.

El proceso es algo largo de explicar pero se puede ver en este link.

Con lo cual queda en evidencia la posible efectividad, de este tipo de herramientas que funcionan únicamente vía software, ya que pueden ser vulnerables a los kernel rootkits.

Esto surgió entre el año 2006 y 2008, se buscaron medidas para solucionar el problema en este tipo de software. Entre estas medidas están las llamadas AE: anti-execution., que en resumen vienen a decir que la responsabilidad de lo que se ejecuta en la máquina recae sobre el usuario, con lo cual estamos en las mismas.

De todas maneras este tipo de malware es efectivo si se llega a ejecutar con permisos de administrador, con lo cual es difícil que en un aula o colegio pueda suceder, ya que la mayoría de las veces se estará ejecutando con una cuenta de usuario limitada.

En el caso de tarjetas como Custodius, no deberían ser vulnerables a los kernel rootkits, pero si a los BIOS rootkits. A pesar de que en su web aseguran que protegen la BIOS, existen comentarios en foros de gente que ha actualizado la BIOS del equipo con la tarjeta puesta y que los cambios se han hecho efectivos.

La existencia de BIOS root kits es una realidad, y existen ejemplos como Mebromi (or MyBios), que ataca a BIOS AWARD (Phoenix Technologies).

A pesar de que es difícil que un equipo se infecte con este tipo de rootkit, siempre es conveniente usar sistemas reboot and restore, a modo de complemento.

Por ejemplo si el uso es en un aula universitaria, sólo el encargado del aula debe tener y usar la clave de administrador, la cual solo se usará en caso estrictamente necesario. Por otro lado, solo se usará modo supervisor en caso de necesidad absoluta de instalar un software determinado y a poder ser sin estar conectado a internet (sí en el caso de las actualizaciones de adobe, java o del propio sistema operativo), y por supuesto complementar toda esta seguridad conjuntamente con un firewall personal / antivirus. Además se deberá proteger la entrada en la BIOS mediante un password, así como la entrada en el modo supervisor de nuestro sistema de recuperación, y tener la caja del equipo totalmente sellada para impedir que nos sustraigan la tarjeta PCI o que hagan un clear CMOS.

En caso de que sea estrictamente necesario actualizar la BIOS del equipo, deberá hacerse con sumo cuidado y sólo conseguir el software de la página oficial del fabricante.

Otros sistemas conocidos, son por ejemplo Rollback RX PC que usa un sistema de instantáneas que se pueden recuperar en cuestión de segundos y no consumen casi recursos del sistema. Tiene la posibilidad de cifrar estas instantáneas con cifrado AES 256, para que en caso de robo del equipo, protegernos de que un extraño pueda hacer una restauración.

Otra herramienta conocida es Shadow Defender, que ejecuta el sistema en modo “Shadow mode”, que básicamente lo que hace es virtualizar parte del sistema, justo donde se realizan cambios. En caso de querer volver a un estado anterior, basta con reiniciar el sistema.

Otra opción interesante es Sandboxie actúa de forma parecida a los anteriores, es un sistema tipo sandbox que hace algo parecido a la virtualización por aislamiento, pero en este caso se crea “un contenedor”, donde se ejecutan los programas de aplicación. Además evita la inyección en el kernel de Windows.

En este enlace de YouTube se pueden ver diversas pruebas con varios de los programas mencionados antes, donde se ponen a prueba con virus de diversa índole.

Hoy vamos a hablar de una herramienta gratuita que puede servirnos de alternativa al conocido Splunk para realizar análisis de logs de forma rápida y sencilla.

Logstash es una aplicación de Java que podemos lanzar en cualquier equipo con una versión actual de Java, y que gracias al servidor de búsqueda ElasticSearch que incorpora, puede ampliarse y desplegarse en infraestructuras complejas con múltiples nodos trabajando en paralelo.

Para mostrar su funcionamiento no necesitamos hacer un despliegue tan complejo, y vamos a aprovechar la funcionalidad autocontenida en el paquete descargable, para analizar un conjunto de ficheros de Apache en busca de patrones sospechosos.

[Read more…]

Si los mecanismos de seguridad son complejos de usar, pierden su efectividad, ya que nadie los usará. Si se fuerza su uso, se intentarán otros canales para conseguir la misma funcionalidad.

La ciberseguridad ha sido, desde sus comienzos, una auténtica carrera armamentística. Si la entendemos como la protección de la información que una organización mantiene, tanto en su custodia como durante su transmisión, podemos incluir desde los primeros intentos de ocultar mensajes secretos a ojos de los no autorizados, cifrándolos u ocultándolos, hasta los mecanismos de los gobiernos para espiar las transmisiones de los enemigos, tanto en la guerra como en la paz.

Así, siempre que un cerebro humano ha pensado en una forma de proteger una información, otro cerebro igualmente inteligente, ha sido capaz de encontrar el medio de saltarse la protección. Al final, se trata de una cuestión de economía, como casi todo. ¿Vale la información que se puede robar el esfuerzo necesario para romper los mecanismos que la protegen? Este hecho económico básico es, a veces, intuitivamente engañoso. Muchas personas piensan que su información tiene poco valor (cosa en la que, normalmente, aciertan) y que, dado que la protección utilizada requiere un esfuerzo no trivial para romperla, están a salvo del acceso no autorizado.

Pues bien, probablemente, no valga la pena hacer el esfuerzo para romper el mecanismo que protege esa información, pero, como resulta que el mismo mecanismo (relativamente débil) es utilizado por muchas personas, el coste unitario se reduce a niveles risibles y, por poco que sea el provecho obtenido, el rendimiento obtenido es alto.

Así pues, ¿debemos usar mecanismos más complejos? Sin duda, si nos importa algo la información protegida. Ahora bien, si estos mecanismos no se hacen más fáciles de usar, pueden pasar dos cosas:

Una: que no se utilicen, con el consiguiente riesgo que, seguro, acabará materializándose y reducirá fuertemente la confianza en las transacciones en la red.

Dos: que, al ser incómodo, sólo se usen para casos muy especiales, con lo que disminuye drásticamente la funcionalidad de Internet, reduciéndolo casi a un sistema de consulta de información y compartición de información banal.

En resumen, si queremos que Internet permita un amplio conjunto de funcionalidades y transacciones, de manera segura, que realmente facilite nuestra vida, tenemos que diseñar mecanismos de protección tan usables como eficaces.

Es preciso acabar con la creencia de que la seguridad está reñida con la funcionalidad.

En ocasiones, en el transcurso del análisis forense de un sistema Windows, puede resultarnos de utilidad conocer el nivel de parcheado del equipo que estamos analizando. En la presente entrada veremos cómo llevar a cabo esta tarea con ayuda de la herramienta Microsoft Baseline Security Analyzer (MBSA).

Cabe aclarar que esta herramienta se aplica sobre sistemas en ejecución (“en vivo”), y no sobre imágenes offline del sistema de ficheros, por lo que en primer lugar será necesario levantar una copia de la máquina objeto del análisis forense. A tal efecto podemos utilizar herramientas como Live View (que nos permitiría desplegar una imagen del disco duro de la máquina obtenida, por ejemplo, con el comando dd, en forma de máquina virtual) o Clonezilla (con la que podríamos obtener una imagen del disco duro del equipo analizado, que luego podríamos desplegar en una máquina virtual u otra máquina física), entre muchas otras opciones.

En lo que sigue, asumiremos que ya tenemos lista y en ejecución esta copia del equipo a analizar. Puesto que el supuesto de partida es que estamos llevando a cabo un análisis forense, asumiremos que tampoco podemos conectar esta copia del equipo a Internet, de modo que utilizaremos el programa MBSA de una forma completamente offline.

Podemos descargar MBSA, en su versión 2.3, a través del siguiente enlace:

http://www.microsoft.com/en-us/download/details.aspx?id=7558

El programa no requiere ningún componente extra (como .NET) y se instala a través del típico asistente, sin mayores complicaciones:

Tras iniciar el programa, llevaremos a cabo un primer escaneo de prueba sobre el equipo, a través de la opción “Scan a computer”:

El objetivo de este primer análisis, que no podrá completarse correctamente, es que MBSA genere los directorios donde almacena la caché con el catálogo de actualizaciones de Windows. Para la versión 2.3, este directorio es "Configuración local \ Datos de programa \ Microsoft \ MBSA \ Cache" (a partir del perfil del usuario administrador con el que estemos ejecutando la herramienta) y, puesto que vamos a llevar a cabo todo el proceso con la máquina que estamos analizando desconectada de Internet, será necesario descargar el catálogo de Windows Update (Microsoft lo denomina “archivo de examen sin conexión”) desde otra máquina y copiarlo a la anterior ruta.

Podemos descargar este archivo (su nombre es wsusscn2.cab) a través del siguiente enlace:

http://go.microsoft.com/fwlink/?LinkId=76054

A continuación, lo copiamos en el directorio caché de MBSA:

En sistemas realmente desactualizados, podría suceder que la versión del agente de Windows Update sea tan vieja que MBSA no pueda llevar a cabo el análisis. En este caso, el programa presenta el siguiente mensaje de error: “Computer has an older version of the client and security database demands a newer versión. Current version is and minimum required version is…”, tal como puede observarse en la siguiente captura:

Si la máquina estuviera conectada a Internet, el propio MBSA actualizaría el agente de Windows Update, pero en nuestro caso deberemos descargar el instalador desde otra máquina e instalarlo en el equipo sobre el que estamos llevando a cabo el análisis forense. Microsoft documenta este procedimiento en el siguiente artículo:

http://technet.microsoft.com/en-us/library/bb932139.aspx

Para sistemas x86, podemos descargar el instalador desde la siguiente URL:

http://go.microsoft.com/fwlink/?LinkID=100334

De nuevo, la instalación se lleva a cabo vía asistente y no presenta mayores complicaciones:

Una vez contamos con una versión reciente del agente de Windows Update, ya podremos lanzar la herramienta contra el catálogo de actualizaciones que hemos descargado. Podemos marcar las opciones de escaneo de interés (en nuestro caso “Check for security updates”) y llevar a cabo el análisis:

Este sería el resumen de resultados para un equipo Windows XP SP3 “dejado caer”, sin ningún parche aplicado:

Mediante la opción “Result details” podemos obtener el detalle de los parches concretos que no han sido aplicados:

También podemos copiar los resultados del análisis en el portapapeles (opción “Copy to clipboard”) y guardarlo en un fichero de texto, que luego podremos utilizar para la confección del informe forense:

Por último, cabe señalar que el programa también cuenta con interfaz de línea de comandos, con la que podemos lanzar los análisis de forma automática con las opciones requeridas:

Esperamos que la entrada haya resultado de vuestro interés.

¿Cuál es la organización que más sabe sobre nuestra vida en la red? Sí, yo también pienso que es Google, por delante de nuestro gobierno, hacienda o nuestra propia familia. Si, además, somos usuarios de Google Apps, probablemente, la compañía del buscador tenga casi tanta información digital como nosotros mismos.

Pero la cosa no acaba ahí. Siempre es divertido elucubrar sobre la estrategia de dominación mundial de las grandes compañías multinacionales y me gustaría abrir la discusión sobre las posibles intenciones de Google, a la luz de sus últimas adquisiciones. Analicemos las tres últimas conocidas:

La primera, una empresa llamada Nest, dedicada a la fabricación de termostatos inteligentes – así se ha contado en la prensa – o, más precisamente, de dispositivos que permitan desarrollar la idea de la “casa conectada”, enchufando los sistemas de calefacción, iluminación, electrodomésticos, etc. a Internet para poder controlarlos y gestionarlos de manera más eficiente. Muy en la línea de la “Internet of Things”. En ese proceso, la compañía puede recoger mucha información acerca de los hábitos de consumo y comportamiento de los habitantes, por supuesto.

La segunda, Impermium Security, dedicada a proteger a sus clientes frente al robo y suplantación de identidades digitales, utilizando modelos estadísticos y de aprendizaje automático, para proporcionarles protección en tiempo real.

Por último, la más reciente, DeepMind Technologies, utiliza algoritmos de aprendizaje universal para aplicaciones como simulaciones, comercio electrónico y juegos. En sus propias palabras, la tecnología de DeepMind intenta conseguir que los ordenadores piensen como humanos y ha sido demostrada en demostraciones de ordenadores jugando videojuegos.

Lo curioso de este último caso es que, DeepMind, que estaba en tratos con Facebook, ha acabado decantándose por Google, incorporando una curiosa condición a su acuerdo: la creación de un comité de ética que “definirá reglas para indicar cómo Google podrá y no podrá hacer uso de esta tecnología”.

Es decir, que Google quiere tener más información sobre mi comportamiento en casa, conocer más sobre el robo y la suplantación de identidades y está interesado en técnicas de AI que hacen que las máquinas puedan pensar y comportarse como personas.

Y, además, se ve en la necesidad de establecer un comité de ética para vigilar el uso que le da a esta tecnología.

Inquietante.