The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

Archive for June, 2011

¡No quiero a mi DNS!

Pues sí, parece ser que el DNS es un bicho raro que nadie quiere y seguro que algunos se preguntarán qué es eso del DNS. Pues el DNS es un servicio encargado de resolver los nombres de las direcciones de Internet, es decir, que si usted pone en su navegador web www.google.es, él se encarga de decirle a su navegador que donde quiere usted ir es a la IP 1.2.3.4.

Como ven bajo esas tres letritas tan raras se esconde uno de los servicios más críticos para la infraestructura de su empresa. ¿Por qué? Pues porque es el encargado de que si un cliente pone http://www.suempresa.es vaya a su empresa y no a la de la competencia, porque también es el encargado de que si su servidor requiere una actualización la obtenga del sitio correcto y no de “pedazo-rootkit-te-voy-a-meter” y, como no, de que cuando un usuario se conecte a Facebook el lunes para comprobar qué planes hay para el sábado vaya realmente aFacebook y no a un falsa web que robe las credenciales del usuario (tenga en cuenta que quien dice Facebookpuede decir su entidad bancaria).

Una vez mostrado la importancia del DNS para su infraestructura, nos planteamos… ¿Por qué en ocasiones no se toman las medidas necesarias de arquitectura de red y de bastionado del servicio que realmente requiere este servicio? No hablo de restringir únicamente la petición de la versión empleada o las transferencias de zona, hablo de por qué permite que su DNS interno consulte directamente a un DNS externo, por qué el DNS de la red perimetral responde tanto a los servidores de la red perimetral como a las solicitudes de activos externos a su infraestructura, por qué permite que los activos de la red internan puedan solicitar cualquier dominio, por qué su servidor DNS público permite consultas recursiva a solicitudes externas… ¿Por qué? Mourinho, ahora te entiendo 🙂

Su infraestructura debe disponer de al menos tres DNS, los cuales se recomienda que estén replicados para alta disponibilidad (es decir, seis servidores DNS):

  • El primer DNS es el encargado de responder a las peticiones externas que pregunten sobre un dominio de nuestra infraestructura y por tanto es el encargado de resolver las IP públicas de nuestra red. Éste debe estar en una zona dedicada y propia de la infraestructura, y dicho DNS no debe permitir peticiones recursivas y por supuesto peticiones desde nuestra infraestructura.
  • El segundo DNS se encontrará en la red perimetral o DMZ. Contiene las IP privadas de los servidores de DMZ y a su vez será el encargado de consultar a los DNS externos de la infraestructura si recibe peticiones, si y solo si, de activos pertenecientes a la red perimetral o del DNS interno.
  • El tercer DNS será el interno, que responderá única y exclusivamente a peticiones de los activos de la red interna y en caso de no disponer de la respuesta, siempre deberá preguntar al DNS de la red perimetral de la infraestructura y jamás, repito, JAMÁS, a un DNS externo de Internet.

Con este entorno dispondremos de una arquitectura de red para los DNS segura, dentro de lo seguro que pueda ser un servicio que se comunica mediante UDP (si la petición es inferior a 512 bytes). Pero lógicamente este diseño debe ser acompañado por dos herramientas: un IPS que sea capaz de entender a nivel de aplicación el protocolo DNS y añadir la capacidad de Sinkhole al DNS interno.

En lo referido al IPS es crucial que éste sea capaz de entender a nivel de aplicación el protocolo DNS puesto que éste emplea un formato muy especifico para contener los dominios. Si por ejemplo queremos detectar conexiones hacia el dominio de malware “counter.yadro.ru” no se le puede decir al IPS que intente buscar esa cadena porque no la va a encontrar. Si vemos a bajo nivel una consulta de dicho dominio vemos que lo que se manda es lo siguiente: “0763 6f75 6e74 6572 0579 6164 726f 0272 7500”, es decir, por cada registro se indica primero el número de caracteres del subdominio y posteriormente se envían los valores ASCII del subdominio. Para terminar el dominio se emplea el carácter “00”:

07 63 6f 75 6e 74 65 72 05 79 61 64 72 6f 02 72 75 00
c o u n t e r y a d r o r u

Estas construcciones pueden complicarse cuando se emplean punteros, que permiten legítimamente al protocolo DNS ahorrar espacio al poder saltar a cualquier posición del payload, dificultando la obtención del dominio solicitado, así como pudiendo generar bucles infinitos. Los punteros se identifican porque el valor del número de caracteres que le preceden es superior a 63. Recuerden que un dominio y subdominio no pueden superar los 63 caracteres, por tanto, si el valor es superior a 63 (0×40 o superior) esto indica que es un puntero y tras él, se indica la posición del payload donde se desea saltar.

La segunda herramienta básica a la que hacíamos referencia es Sinkhole, de Guy Bruneau, necesaria y prácticamente obligatoria en cualquier infraestructura. Lo que hace esta herramienta es detener la actualización y comunicación del malware con su controlador si emplean para ello Fast Flux (la gran mayoría del malware actual).

Sinkhole es un servidor DNS (BIND) al cual se le ha añadido un listado de dominios conocidos que distribuyen malware; en lugar de apuntar a la IP real del malware, se apunta a un servidor interno vacio y de esta forma cuando los usuarios reciban un correo con un enlace a un dominio que contenga malware, si pincha en el enlace correspondiente, Sinkhole impedirá que se infecten al redireccionarle al servidor vacio, de la misma forma que impedirá que el malware se actualice y que el atacante obtenga el control del equipo. Una política acertada es monitorizar las conexiones al servidor vacio para emplearlo como una herramienta de detección de malware. Es importante tener claro que para que esta estructura funcione todos los equipos de usuarios sólo pueden resolver dominios pasando por el DNS Sinkhole y que el DNS Sinkhole debe redireccionar, una vez pasado el filtro, al DNS interno.

Existen muchas otras configuraciones a tener en cuenta, como por qué aceptamos respuestas de DNS con un TTL inferior a un día o por qué algunos DNS no seleccionan de forma aleatoria su ID y su puerto origen para evitar envenenamiento de la cache de tipo Kaminsky, pero esto ya requeriría más de una entrada 🙂

Para finalizar les muestro un diagrama básico de una arquitectura más o menos segura de implantación de un DNS, que seguro que a todos nos sonará por tenerla implantada en nuestra empresa al ser un requisito indispensable de la norma ISO 27002… ¿verdad? 🙂 Bromas aparte, ahí va:

DNS


Auditorías de cumplimiento con Nessus

Una de las características que ofrece la versión ProfessionalFeed (la de pago, vamos: $1200 al año cada licencia) de Nessus —entre otras— es la posibilidad de realizar auditorías de cumplimiento a sistemas Unix y Windows, aplicaciones o bases de datos SQL basadas en estándares ya predefinidos.

Así pues, podremos realizar auditorías de cumplimiento basándonos en las recomendaciones CERT, guías de buenas prácticas CIS o NSA, requerimientos de configuración PCI , e incluso Bandolier (proyecto de Digital Bond) proporciona políticas de cumplimiento (a través de ficheros .audit de los cuales hablaremos a continuación) para auditar sistemas SCADA, DCS y otras aplicaciones de sistemas de control industrial, entre otros.

El cumplimiento o no cumplimiento de dichas recomendaciones viene predefinido por los ya mencionados ficheros de extensión .audit que ofrece Tenable a través de su centro de soporte. Podemos descargarnos diversos ficheros .audit que nos definan por ejemplo políticas de auditorías desarrolladas por Tenable para auditar sistemas Windows, Linux, HP-UX, Solaris y AIX para comprobar el cumplimiento de unos requerimientos de configuración mínimos establecidos según el estándar PCI, políticas de cumplimiento basadas en las mejores prácticas según Cisco para la configuración de sus dispositivos o incluso políticas de auditoría que analizan la presencia de contenido “sensible” en los sistemas a auditar (contenido para adultos, información corporativa confidencial, números de tarjetas de crédito, etc.) por citar algunos ejemplos.

Por ejemplo si queremos auditar un dispositivo Cisco según las propias recomendaciones sobre buenas prácticas de Cisco usaríamos el fichero .audit correspondiente. Veamos una posible puesta en escena. El primer paso es crearnos nuestra política:

Descargamos el fichero .audit correspondiente del centro de soporte. En este caso a modo de ejemplo usaremos Cumplimiento_Cisco_Level_2.audit: fichero que implementa las recomendaciones de configuración de nivel 2 según el CIS Cisco IOS Benchmark v2.4.0. En la descripción del fichero .audit además indica que es necesario que toda la familia de plugins de Cisco esté habilitada, así que no debemos olvidarnos de habilitar el plugin correspondiente a Cisco dentro de la familia de plugins del cumplimiento de las políticas:

A continuación en Preferencias cargamos el fichero .audit que hemos descargado previamente seleccionando el plugin ‘Cisco IOS Compliance Checks’; como vemos permite incluir hasta cinco ficheros .audit de política de Cisco que permiten verificar si dispositivo con Cisco IOS está configurado conforme a los estándares de seguridad indicados en las políticas cargadas:

De este modo tan simple, ya tendríamos la política creada para auditar nuestro dispositivo y ver si cumple con las recomendaciones que el proveedor nos da.

Si nuestra empresa dispone de su propia política de seguridad en cuanto a configuraciones de servidores por ejemplo podemos editar nuestro propio fichero .audit para realizar la auditoría de cumplimiento de acuerdo a nuestra propia política. Asimismo, en el centro de soporte de Nessus se proporcionan también diversas Tools (i2a, c2a, p2a) para generar nuestros propios ficheros .audit a partir de otros ficheros. Así, por ejemplo podemos generar ficheros .audit a partir de ficheros .inf de Windows. por citar un ejemplo. Para aquellos interesados, Tenable proporciona información al respecto de la creación de ficheros .audit en su centro de soporte e invita a que los usuarios interesados visiten los foros de discusión del producto.

Por propia experiencia y para acabar, los ficheros .audit ayudan con el cumplimiento de estándares, o al menos dan una idea bastante aproximada de cuál es la situación al respecto, sin embargo creo que como con cualquier herramienta automatizada, es recomendable a posteriori realizar una verificación de los resultados.


SnoGE: Una interfaz de película

 La visualización de la información es tan importante como la información en sí misma. Demasiada información, sin la posibilidad de analizarla correctamente, no sirve de mucho. Por esto, quería dedicar esta entrada a mi chica unas herramientas que muestran, de una forma visualmente atractiva, alertas de seguridad generadas por Snort. No esperéis potentes interfaces gráficas haciendo data mining, agregando información, categorizándola, procesándola, correlándola y alertando de lo más importante que está ocurriendo en nuestra red. Para eso hay que recurrir a soluciones profesionales que conllevan un coste más o menos considerable.

En esta ocasión os voy a mostrar una herramienta de código libre que nos ofrece una interfaz visualmente atractiva, aprovechando la potencia de una herramienta del omnipresente Google. Esta herramienta se llamaSnoGE y está desarrollada por Leon Ward, un ingeniero de seguridad que trabaja en Sourcefire, empresa que está detrás del proyecto Snort. Este script procesa las alertas generadas por Snort en formato Unified2 y genera un fichero KML. ¿Qué es un fichero KML? Para quien no lo sepa, se trata de un fichero XML especialmente diseñado por Google para representar objetos en su GoogleEarth. Y es ahí donde está la gracia del proyecto SnoGE: con un sencillo script escrito en Perl, es posible montar una interfaz gráfica muy atractiva que nos permite ver desde dónde nos están atacando; ideal para cuando vengan periodistas ávidos de ver ataques informáticos en tiempo real u otra fauna no técnica, al estilo de la película “Juegos de Guerra” o las diseñadas por Mark Coleran.

De acuerdo, admito que no se trata de una herramienta imprescindible en la gestión de incidentes o en la respuesta temprana ante ellos; esta herramienta únicamente muestra la alerta y el origen. No muestra agregaciones, ni criticidades, ni más información que pudiera ser útil a la hora de detectar un ataque potencialmente crítico a nuestra infraestructura. Pero visualmente es muy atractiva y puede mostrar las alertas en el momento en el que se producen.

SnoGE cuenta con dos modos principales de operación: uno estático y otro en tiempo real. El estático se ejecuta una única vez, leyendo de uno o varios archivos Unified2, mientras que en tiempo real se le indica el directorio donde se guardan las alertas de Snort para que las vaya analizando, de forma similar a Barnyard2.

Utilizando esta última opción, se le puede indicar el tiempo de refresco y el número de alertas a mostrar. Esto es importante ya que, si se cuenta con muchas alertas, se puede volver algo lento.

Una vez generado el archivo KML, sólo nos quedaría representarlo. La forma más impactante es abrir el fichero KML directamente con GoogleEarth o utilizar este visor, que permite insertarlo en una página web y visualizarlo instalando el plugin para GoogleEarth desde el navegador. De esta forma, se consiguen una interfaz 3D muy potente y atractiva. Algo similar a esto:

GoogleEarth 3D

Otra opción más sencilla, la cual no requiere de complementos adicionales, es verla en 2D. Para verla en 2D sin necesidad de tener instalado GoogleEarth ni ningún plug-in, podemos utilizar las librerías de JavaScript geoxml.

GoogleEarth 2D

En ambas opciones se debe indicar el tiempo de refresco de la página. El sistema, de forma conceptual, lo componen los siguientes elementos:

  • El archivo Unified2, del que se leen las alertas.
  • El fichero KML, resultante de la ejecución del script.
  • El fichero del servidor, en caso de utilizar el refresco automático, que se encarga de leer el anterior según el tiempo indicado.
  • El código HTML que contiene el módulo o el código JavaScript que representa el archivo KML.

Esquema SnoGE

Bueno, simplemente quería presentar estas dos opciones, fáciles de implantar, aunque la instalación no se aborde aquí por no extenderme. He seguido las indicaciones de los respectivos desarrolladores y no he tenido problemas para instalarlos. Aunque no haya demasiada información al respecto, la que se incluye en cada proyecto es más que suficiente. Resumiendo, SnoGE: una solución sencilla, barata y atractiva para mostrar los ataques recibidos a personas no técnicas.

Por lo demás, pasen muy buen fin de semana.


Qué no hacer al gestionar incidentes de seguridad

En los últimos tiempos se han presentado distintos incidentes de seguridad que han puesto al mundo en alerta, a las compañías involucradas en la mira y a los datos personales y la privacidad en jaque. Gigantes de la Tecnología y el Entretenimiento se han visto afectados, datos personales robados, tus gustos, intereses y hábitos al descubierto.

El objetivo de presente artículo es analizar distintas acciones que se han llevado a cabo en alguno de los incidentes de las empresas descritas, para identificar en base a estas experiencias, ¿qué cosas no debemos hacer si tenemos que gestionar un incidente de seguridad en nuestra Organización?
1) Ocultar el incidente a los clientes

La primera medida que generalmente se encuentra asociada a un incidente de seguridad es el ocultamiento. Nada peor que esta acción si queremos demostrar que hemos sido diligentes con nuestros datos y con los datos de nuestros clientes. Debemos tener presente que los datos personales son de las personas, no son nuestros y que están a nuestro resguardo.

En algunos casos la situación podría tomar una gravedad extrema en la cual el nivel de exposición deje muy claro que no se estaban cumpliendo regulaciones o cuestiones legales, por ejemplo PCIDSS si dentro de la brecha están incluidos datos de medios de pago que se encontraban en plano.
2) Aumentar las cualidades del atacante

Otra situación que se está presentando frecuentemente es buscar de todas maneras omitir los errores que se hayan cometido por falta de diligencia, conocimiento o cualquier otro motivo. Cuando esto sucede lo primero que se busca es centrar la atención en las hipotéticas características que poseía el atacante, siempre haciéndolo mucho más sofisticado de lo que realmente ha sido. Es decir, aumentar el skill del atacante para minimizar nuestros errores. “Hemos sido víctimas de un ataque jamás visto”, “El atacante poseía conocimientos muy sofisticados”, “Fue Anonymous” etc, etc.

3) Describir medidas de seguridad básicas como “sofisticados” planes de mejora a raíz del incidente

Se presenta frecuentemente el hecho de nombrar como planes de acción asociados al incidente la implementación de medidas de seguridad que ya deberían haber implementado con anterioridad, y que son realmente básicas, por ejemplo: “Implementaremos un sistema de gestión de la seguridad basado en ISO/IEC 27001”, “Utilizaremos técnicas de encripción para los datos de carácter personal”, “Entrenaremos a todo nuestro personal para brindar respuesta a incidentes”. Respuestas de este estilo se pueden encontrar en los comunicados que publican las empresas afectadas, lo que no hace más que evidenciar las debilidades de seguridad y negligencia de quienes debían tomar otras acciones y en otros momentos. Está claro que cualquier Organización que deba cumplir leyes o regulaciones como PCIDSS, SOX, u otra similar, ya debía contar con este tipo de medidas de seguridad.

4) No aceptar las equivocaciones

Algo que parece tan simple no se da frecuentemente, lo que el cliente espera más allá de excusas, ocultamiento, mentiras e hipótesis falsas, es que la organización que tuvo el incidente, lo comunique a tiempo, en forma sincera y aceptando los errores que pudiera haber cometido. Es así, “No supimos cuidar sus datos, hemos cometido errores, les pedimos perdón y tenemos todos nuestros recursos a su disposición para cubrir el error y mantenerlo como cliente”. ¿Cuántas empresas están dispuestas a comunicar esto a sus clientes?

5) Ofrecer compensaciones que no están a la altura del incidente

A todo lo que venimos comentando habría que agregar que en varios casos se han presentado planes de compensación para los clientes que realmente parecen una burla, “Welcome Again” “Free Content for Ever”, “Membership Gold”, etc. Al momento de establecer dichos planes se debe priorizar al cliente, no se debe seguir especulando sabiendo que no hicimos lo que debíamos y sumado a esto ofrecer lo que más cómodo nos queda para “mostrar” que estamos preocupados. Debemos estar preocupados y debemos ofrecer un plan de compensación que realmente esté a la altura del impacto provocado.

6) Seguir pensando que la Gestión de Incidentes es un tema menor o que corresponde sólo a IT

Las Organizaciones que mantienen esta postura son aquellas en las cuáles los Directivos aún no han interpretado que la Seguridad de la Información es una prioridad y les compete a ellos por la función que ocupan, gestionar el riesgo y conocer en todo momento la postura de seguridad de su Organización, en definitiva de su negocio.

De este tipo de Organizaciones podríamos recibir “acciones de mejora” tales como “Hemos nombrado un nuevo CSO (Chief Security Officer) que reportará al CIO (Chief Information Officer)”. Lo que demuestra errores conceptuales profundos y que afectan los principios básicos de la seguridad y el control interno.
¿Alguien puede seguir pensando luego de la brecha de la PlayStation Network que la gestión de incidentes es un tema netamente técnico y de IT?
¿Y las tarjetas de pago?

Otra cuestión que también llama la atención es que las Compañías involucradas en forma indirecta, como por ejemplo V1S4, M4st3rC4rd, 4m3r1c4n 3xpr3ss, etc. no emitan ninguna comunicación al respecto.

¿Acaso PCIDSS no surgió debido a las distintas brechas de seguridad que han involucrado datos de tarjetas de pago?
¿Acaso cumplir PCIDSS no hubiera minimizado el impacto de la brecha en el caso de 50NY?

¿Cómo se deberían tomar los incidentes?

A día de hoy, los incidentes se deberían tomar como algo que en algún momento va a suceder, no sigue siendo válido pensar que lo que hacemos o lo que haremos es para no tener incidentes, eso es imposible. Se presentarán incidentes y lo que debemos hacer es establecer los mecanismos, procesos y medidas de seguridad para dar respuesta en forma oportuna y diligente. Esa respuesta a incidentes no la dará únicamente ITOrganización. Así como se aprende de un error o equivocación en la vida cotidiana (o al menos deberíamos), en el caso de los incidentes es fundamental aprender y mejorar.

“Un incidente no se puede presentar 2 veces, sin haber hecho algo al respecto”.
La implementación de un sistema de gestión de la seguridad basado en los riesgos a los que está expuesta la Organización, contemplando en todo momento los requerimientos legales y regulatorios, podría ser el camino a seguir para iniciar la gestión continua y diligente que como Organización debemos brindar a la información propia al igual que la de los clientes.
“La Gestión de la Seguridad no es de única vez o porque debo cumplir, es un proceso contínuo”.

Referencias (no es necesario reinventar la rueda):


Herramientas para realizar un Análisis de Rendimiento en Windows 7 (I de III)

Una vez más, desde el sitio de SpringBoard Series, podemos descargar el Kit de Herramientas de Rendimiento, disponibles para plataformas Windows Vista y Windows Server 2008 y superiores (tanto en cliente como en servidor) en el SDK 7.1 de Windows 7. Este kit de herramientas puede ser utilizado por una amplia gama de usuarios, ya sea con un perfil de integradores de sistemas, como de fabricantes de hardware o desarrolladores de aplicaciones. La finalidad de este conjunto de herramientas es la de permitirnos realizar mediciones y análisis del rendimiento de nuestros sistemas. Como requisito previo, tendréis que descargaros el .Net Framework 4.0.

Generalmente, cuando tenemos un problema de rendimiento, lo primero que solemos hacer es monitorizar el entorno con herramientas como el Administrador de tareas o el monitor de recursos y así, de una forma rápida poder tener una perspectiva visual de aspectos fundamentales como son la gestión de la CPU o de la memoria. Sin embargo, podemos obtener información más detallada con el citado conjunto de herramientas de rendimiento.

image

Imagen 1: Instalación de Windows SDK 7

Una vez descargado e instalado el SDK de Windows 7 podremos acceder a las siguientes herramientas de rendimiento:

  • Herramienta de línea de comandos para análisis y captura de trazas (Xperf.exe): Captura trazas para el análisis de las mismas.
  • Herramienta visual de análisis de trazas (Xperfview.exe): Presenta el contenido de traza en forma de gráficos interactivos y tablas de resumen.
  • Herramienta de encendido/apagado de transmisión de captura de trazas (Xbootmgr.exe):Automatiza el estado de encendido/apagado de la captura de trazas.

Herramienta de línea de comando para análisis y captura de trazas

Empecemos analizando la primera herramienta (Xperf.exe). Para ello, accederemos mediante línea de comandos a la ubicación de la instalación de las herramientas de análisis de rendimiento en la ruta C:\Program Files\Microsoft Windows Performance Toolkit y ejecutaremos el comando Xperf –on base, con el que indicaremos que se recopile el rendimiento del equipo.

image

Imagen 1: Comando para recopilar el rendimiento de Windows 7

Una vez recopilado el rendimiento del equipo, podemos proceder a su visualización a través de la generación de un informe mediante el comando Xperf –d C:\informe.etl.

image

Imagen 12: Generación del informe de rendimiento

El informe puede ser abierto (haciendo doble clic en el mismo o con el comando Xperft C:\informe.etl) para su monitorización y análisis, disponiendo de métricas de rendimiento clave, como recursos utilizados por la CPU, entrada/salida en disco, etcétera. A su vez, permitirá seleccionar un rango de datos del gráfico y hacer zoom sobre el mismo, para recabar información de detalle para determinado periodo de tiempo.

image

Imagen 3: Visualización y análisis de datos sobre el rendimiento

Recuerda que si quieres seguir actualizando tus conocimientos sobre esta herramienta y muchas otras, no te olvides de visitar el sitio de SpringBoard Series dedicado a la plataforma de Windows 7, o si lo prefieres, puedes suscribirte al canal RSS de Windows Técnico para mantenerte informado.

image


Alan Turing, criptólogo y padre de la computación

Alan Turing mathematician 001 400x240 Alan Turing, criptólogo y padre de la computación

Hoy 23 de junio, además de celebrar el final de solsticio de verano y la noche de San Juan, también recordamos el nacimiento de uno de los padres de las Ciencias de la Computación y uno de los grandes criptólogos que conoció el siglo XX: Alan Turing. Alan Mathison Turing, que nació el 23 de junio de 1912 en Londres y murió el 7 de junio de 1954 en Cheshire, fue un matemático, criptógrafo, filósofo y un teórico de la computación que trabajó, durante la Segunda Guerra Mundial, en el equipo que descrifró el código Enigma de la Alemania Nazi y que, tras la guerra, diseñó uno de los primeros computadores digitales programables y publicó uno de los primeros trabajos sobre inteligencia artificial.

Desde muy joven, Turing siempre mostro especial interés en las matemáticas y el cálculo, destacando estas habilidades en su época escolar frente al resto de disciplinas. Esta predilección por las matemáticas frente a otras disciplinas le llevó a suspender sus exámenes finales y a ingresar en la universidad que había elegido como segunda opción: el King’s College de la Universidad de Cambridge, lugar en el que se quedó y en 1935 obtuvo una plaza como profesor.

Al año siguiente, Turing editó un trabajo publicado por la Sociedad Matemática de Londres: On computable numbers, with an application to the Entscheidungsproblem, un trabajo que presentó un modelo formal de computador, la máquina de Turing, que trazaba una línea que dividía los problemas matemáticos en dos grupos, los que podían resolverse mediante un computador y los que no podían ser resueltos por una máquina. Este modelo teórico y su análisis de complejidad de algoritmos se sigue usando hoy en día, por ejemplo, en el mundo del Álgebra (los problemas P y NP). Durante 1937 y 1938, Turing realizó su doctorado en la Universidad de Princeton, gracias a que sus trabajos llamaron la atención de John von Neumann, momento en el que, durante la defensa de su tesis, introdujo el término hipercomputación.

Bombe wh.700px Alan Turing, criptólogo y padre de la computación

Al estallar la Segunda Guerra MundialAlan Turing fue reclutado, junto a otros matemáticos, por el ejército británico para descifrar los códigos criptográficos alemanes, que procedían de la famosamáquina Enigma. Durante estos años, Turing colaboró en el diseño de una máquina, construida a base de relés, denominada Bombe cuya función era descifrar los códigos alemanes. Además, con el objeto de mejorar las máquinas descifradoras, sentó las bases para poder construir la primera computadora electrónica, Colossus, realizada con válvulas de vacío y de la que se construyeron diez unidades desde 1943. Tras finalizar la guerra y por los servicios prestados (que salvaron muchas vidas en el Atlántico), le fue concedida la Orden del Imperio Británico en 1946.

Al terminar la guerra, Alan Turing se integró en las filas del Laboratorio Nacional de Física en el diseño del ACE (Motor de Computación Automática), un proyecto para competir contra el EDVAC americano (dirigido por von Neumann). En 1947, Turing concibió la idea de las redes neuronales, el concepto de subrutinas y las bibliotecas de software. En 1949 fue nombrado director del laboratorio de computación de la Universidad de Mánchester y trabajó en el diseño del lenguaje de programación de una de las primeras computadoras del mundo, laManchester Mark I. Fue en esta época, en 1950, cuando publicó uno de sus artículos más importantes, que sentó las bases de la inteligencia artificial, Computing Machinery and Intelligence, que comenzaba con una pregunta:

Propongo considerar la siguiente cuestión: ¿Pueden pensar las máquinas?

En este artículo, Alan Turing abordó el problema de la inteligencia artificial y propuso un experimento, conocido como la prueba de Turing, que definía una prueba estándar con la que poder catalogar si una máquina era “sensible” o “sintiente” y llegando a pronosticar que en el año 2000 las máquinas serían capaces de imitar tan bien a los humanos que, en un 70% de los casos, sería muy complicado averiguar si estábamos hablando con una máquina o con un ser humano (algo que no llegó a ocurrir pero que a todos nos recuerda a Blade Runner).

Turing6 Alan Turing, criptólogo y padre de la computación

En 1952, en plena cúspide de su carrera, Alan Turing fue procesado por ser homosexual (que en esa época era delito en Inglaterra) y fue condenado o bien a la castración química o a un año de prisión. Optó por la castración química que le acarreó graves secuelas físicas y, en 1954, murió tras ingerir una manzana envenenada con cianuro, acto que fue considerado como suicidio en aquella época, si bien hay teorías que apuntan al asesinato.

Un triste final para todo un genio que sentó las bases de gran parte de nuestra actual tecnología y que, tal día como hoy, hubiese cumplido 99 años.

Imágenes: The GuardianWan Link Sniper y Wikipedia

Alan Turing, criptólogo y padre de la computación escrita en Bitelia el 23 June, 2011 por jjvelasco
Enviar a Twitter | Compartir en Facebook


Windows XP sigue reinando en las empresas

Transcurrida una década desde que Microsoft lanzara oficialmente Windows XP, el longevo Sistema Operativo aún sigue reinando en las empresas.

Así lo comprueba un estudio realizado por la consultora Forrester entre 2.500 compañías, en el que se comprueba que Windows XP mantiene casi un 60% de participación a nivel empresarial.

Claro que de a poco el reinado de Windows XP comienza a verse amenazado por la arremetida de Windows 7, el último Sistema Operativo de Microsoft que ya se encuentra presente en el 20% de las compañías consultadas y que sigue mostrando un crecimiento sostenido.

 

De esta manera los Sistemas Operativos de Microsoft son utilizados en un 87,6% de las empresas consultadas; mientras que Mac OS X ocupa el segundo lugar con un 11% y Linux, Sistema Operativo que no logra despegar manteniendo un 1,4% de uso al interior de las compañías.

Hay que dejar en claro que el estudio se basó en el uso de los Sistemas Operativos de escritorio al interior de las empresas, ya que si se tomara en cuenta el mercado de los servidores otros serían los resultados.

Link: Corporate Desktop: Windows 7 gaining ground, XP still at 60 percent (Neowin)