Security Art Work

Recientemente han aparecido algunos estudios en los que se plantea la posibilidad de realizar GPS Spoofing en vehículos civiles no tripulados o “drones”. En éstos se ha conseguido controlar o alterar la secuencia de posicionamiento de un drone y como veremos, incluso la trayectoria de un barco. Sin embargo, antes de entrar en materia, explicaremos primero cómo funciona el sistema GPS.

Cada satélite GPS transmite dos señales, una señal militar y una señal civil. Sólo las señales de GPS código civil puede ser utilizadas por la gran mayoría de los usuarios de GPS (incluyendo los Departamentos de Defensa). El código civil se compone de dos componentes principales, la señal y la onda portadora, tal y como se puede observar en la Figura 1.

Los datos de NAV/System proporcionan al receptor GPS la información sobre la posición de los satélites, así como los datos de tiempo suministrados por los relojes atómicos que se encuentran a bordo de los satélites.

[Read more…]

Apenas faltan dos semanas para que tengan lugar las III Conferencias de Seguridad Navaja Negra. Tras el éxito de las dos ediciones anteriores, este año vuelven a la carga con un atractivo plantel de ponentes, algunos de los cuales -como indican los propios organizadores- han sido “engañados” para ir, y otros provienen del CFP.

Las charlas, centradas en Seguridad de la Información versarán sobre los siguientes temas:

• Adivina quién viene a Cedenear esta noche (@z0mbiehunt3r)
• Cool Boot: It’s Cool!!! (@NN2ed_s4ur0n)
• Cryptography: The mathematics of secret codes is a game (@kachakil)
• How I meet your botnet (@francruar) (@Groove)
• El lado oscuro de Tor: La Deep Web (@pepeluxx) (@tr1ana)
• El día a día de un pentester (@joseselvi)
• Forensic IOS with Low-Cost Tools (@lawwait)
• Where is my money? The evolution of Internet Fraud (@Seifreed)
• Economias Criptográficas (@trufae)
• Anteproyecto del código procesal penal: análisis técnico y legal del software para controlar de forma remota un ordenador (Javier Rodriguez y Cesar Lorenzana del GDT UCO Guardia Civil)
• DDOS Revisited (@lostinsecurity)
• Zeus-R-Us (@smvicente)
• ¿Nadie piensa en las DLL? (@winsock)
• Trash Robotic Router Platform (TRRP) (@taiksontexas)
• Fuzzing Browsers by generating malformed HTML/HTML5 (@florenciocano)
• De pacharanes por Raccoon city: cómo sobrevivir al día a día real de un pentester (@dan1t0)
• Telepathy: Harness the code (Juan Carlos Montes, @jcmontes_tec)

[Read more…]

Si recuerdan, la anterior entrada de la serie la dedicamos a las auditorías iniciales de selección de proveedores. En esta ocasión vamos a hablar acerca de las auditorías de evaluación de proveedores y seguimiento de su desempeño.

Como ya se indicó, el objetivo de las auditorías de evaluación de proveedores es el de verificar el grado de cumplimiento de todos los compromisos adquiridos por contrato, especialmente de todo aquello que tenga que ver con calidad y niveles de servicio, aspectos relacionados con la seguridad y cumplimientos de plazos.

El alcance de una auditoría de seguimiento de proveedores queda enmarcada dentro del objeto y alcance del contrato. Los criterios de auditoría los compondrán, por tanto, las disposiciones contenidas en la documentación de carácter contractual generada, es decir, en el contrato firmado por ambas partes (incluidos anexos y referencias) o en el tándem pliegos de contratación más propuesta ganadora, si se trata de una licitación abierta. También forman parte de los criterios de auditoría todas las disposiciones legales que resulten de aplicación en relación con el contrato y los bienes o servicios objetos de contratación. Ya dijimos que los requisitos legales deben formar parte de los criterios de auditoría de manera inexcusable y la evaluación de su cumplimiento debe abordarse sistemáticamente dentro del proceso de auditoría.

[Read more…]

Snowden, PRISM, NSA… palabras que en los últimos meses se escuchan mucho, muchísimo, en los medios de comunicación. Y es que no hay nada como unir tecnología, espionaje -con el prefijo ciber, of course– y unas cuantas siglas para generar una noticia de alcance… Me he mordido la lengua todo este tiempo, no quería escribir nada sobre esto, pero al final no he podido resistirlo: es lo que tienen las vacaciones, tanto tiempo libre para leer ciertas cosas que al final uno se pica ;)

En principio, no acabo de ver dónde está la noticia… Que Estados Unidos, a través de la NSA y de otras muchas agencias de inteligencia, espía todo lo que puede, es tan noticia como que los perros ladran. Ya, ¿y? Jamás he comprendido la aparente sorpresa de todo el mundo cuando sale a la luz el tema del espionaje de Estados Unidos. ¿De qué nos extrañamos? ¿De que un país con una gran capacidad tecnológica la use en beneficio propio? Vamos, hombre, que aquí nadie es una monjita de la caridad… Lo malo es que los españoles ni tenemos esa capacidad ni creo que la tengamos jamás; vamos, que como no esnifemos Tuenti, poco podemos hacer… Y eso, permítanme la expresión, es una soberana put^H^H^H faena; o, mejor dicho, son dos soberanas faenas. La primera porque nos hace depender de un tercero para adquirir información que posteriormente se transforme en inteligencia (sí, ese tercero es Estados Unidos… ¿quién si no, Andorra?) que hoy es nuestro amigo pero mañana puede serlo menos o simplemente puede tener intereses que no coinciden con los nuestros… La segunda faena es que nos hace completamente vulnerables: dicho de otra forma, tenemos que asumir que Estados Unidos nos espía cuando y como quiere, y por supuesto eso les proporciona sobre nosotros una ventaja envidiable en cualquier campo. ¿Que tenemos dudas si apoyar a los USA en una intervención militar en Chiquitistán? Antes de hablar con nosotros ellos saben lo que tenemos a favor y en contra de la intervención, y pueden adaptar su discurso a lo que queremos oir, por supuesto para apoyarles incondicionalmente en lo que sea… ¿Es esto una faena o no lo es? Y lo peor: si no estamos de acuerdo podemos desconectar cualquier cosa que tenga enchufe e irnos a plantar patatas, por supuesto dejando de usar productos Microsoft, no buscando nada en Google o similares, no enviando información a través de routers Cisco y, en definitiva, alejándonos de cualquier cosa que huela a americana. O mejor, sustituyéndola por Huawei y similares, que también puede ser una alternativa… así diversificamos nuestros riesgos y damos juego a otros países que, sin duda, respetarán nuestra privacidad como personas y nuestros intereses como nación… ¿verdad? :)

El problema, creo, no es que Estados Unidos nos espíe para defender sus intereses: podemos estar de acuerdo o no, y los abogados, periodistas, políticos y demás pueden hablar durante horas de ética, derecho internacional, privacidad y todo eso. Pero, con los pies en el suelo, es lo que hace cualquier país que puede hacerlo. Tan simple como eso, y nosotros, como decía antes, porque no podemos, porque si no, espero que lo hiciéramos… El problema de verdad es un uso particular de la información obtenida. Que un Servicio adquiera información para beneficiar a su país en general (entendido como gobierno, empresas, ciudadanos…) es comprensible, aunque nos perjudique, pero que lo haga para defender intereses de una empresa concreta, para beneficiar a un particular o incluso para proteger a un partido político determinado (ha habido casos), es decir, a actores que no pueden identificarse con un país, no debería tener justificación, IMHO. ¿Lo ha hecho Estados Unidos? No lo sé… ¿Alguien tiene más información al respecto? Si ha usado la información para este tipo de cosas, me parece mal; si la ha usado para beneficiarse como país frente a otros estados, ¿de qué nos quejamos? ¿De que ellos pueden y nosotros no? A ver, que somos mayorcitos y sabemos que la trinchera es mucho más dura que la LOPD, la privacy, la IT Governance, el compliance y todo eso… ¿Qué creemos, que Google nos permite usar GMail *gratis* por amor al arte, regalándonos gigas y gigas de espacio para nuestro correo, gigas que como se dice por ahí solo pueden almacenarse en una SAN, en una NAS o en una NSA :)? Venga, por favor…

Ahora la pregunta del millón: ¿hay luz al final del túnel? Creo que sí, aunque sea un simple LED. Asumamos que Estados Unidos nos espía en beneficio propio… ¿Qué podemos hacer? Dos cosas: intentar que lo hagan lo menos posible -o que lo tengan un poco más complicado- e intentar que sólo nos espíen ellos. Lo que he defendido más de una vez en este blog: usemos tecnología y servicios españoles siempre que podamos -y esforcémonos para poder, que lo cómodo es, muchas veces, lo contrario-; usémoslos, sobre todo, si lo que estamos manejando es información clasificada, sensible o como le queramos llamar. Doy por hecho que servicios nacionales y de calidad siempre podremos contratar, en cualquier ámbito… mi única duda son los productos en casos muy concretos; en estos casos, si no podemos usar tecnología nacional, usemos tecnologías abiertas. Y si tampoco podemos y no queda más remedio que usar sistemas extranjeros, hagámoslo de países que sean estratégicamente cercanos a nosotros o tengan, al menos a día de hoy, unos intereses comunes con los españoles, aunque sea de forma parcial. Dicho de otra forma, prefiero usar Linksys antes que Huawei o Twitter antes que Weibo: ya que me van a espiar, que lo hagan los de siempre ;)

En la cadena de gestión de la información hay una serie de eslabones de cuya eficiencia y toma de decisiones van a depender los que le siguen. Desde el momento en el que un usuario de la información define la necesidad de procesarla hasta que dicho proceso se produce, se siguen una serie de etapas de cuya ejecución y toma de decisiones dependerá la calidad del resultado final presentado al cliente por el área de explotación de sistemas. Igualmente, el trabajo de este departamento será más o menos complejo dependiendo de cómo se ha diseñado y pensado la operación en el entorno de producción, los controles automatizados o manuales, la necesidad de introducir algunos parámetros de proceso, etc.

Con cierta frecuencia se ponen en producción herramientas de proceso en las que no siempre se tiene en cuenta que la explotación de éstas puede ser el origen de conflictos y errores que al final, van a repercutir en la calidad del servicio que se pretende dar al cliente y muchas veces. Incluso en la calidad de la información que se le proporciona. Pues bien, aquí conviene decir que “cuando la puerta está abierta siempre entra aire y si se deja abierta permanentemente, antes o después, habrá un vendaval”.

Llevo desde 1972 trabajando en la implantación y explotación de sistemas (sí, sí, bastante mayorcito) y mi larga experiencia me demuestra que el problema que no se previene durante el diseño y desarrollo de un sistema aparece en el momento de la explotación, porque es ahí donde el sistema está vivo y es ahí donde hace su trabajo. Explotación, junto con el de atención al usuario (Service Desk o Help desk) son los dos paganos de toda la problemática generada anteriormente, que llega tan solo en diferido y sin la intensidad del cabreo del usuario, a sus autores.

Recordemos por ejemplo, cuántos sistemas actualmente en producción conocemos en los que el operador debe introducir una fecha o un parámetro a mano, o debe decidir bajo cierta norma establecida pero siempre subjetiva, si el proceso se para o continúa. En estos casos, cuando cometa una equivocación, el mensaje claro será “Ha habido un error de operador”, en lugar de “Ha habido un error de diseño y una falta de control en la validación del sistema”. Cuando hay que introducir datos manualmente, antes o después, habrá un error humano. En el caso anterior y sólo como ejemplo, crear un calendario en el sistema, mantenido por un usuario experto y validado por el cliente, es mucho más eficiente, evita errores que afectan a la totalidad del proceso y sobre todo brinda mejor servicio al usuario y asegura la calidad de la información que obtiene (al menos en ese aspecto). Claro que esto requiere pararse a pensar y dedicar tiempo y recursos al diseño y desarrollo de los procesos, pero revierte un gran beneficio en el momento de procesar la información y asegurar la calidad del resultado.

Aquí es donde se presenta el primer problema claro del análisis de riesgos-coste-beneficio. Se puede desarrollar o seleccionar un sistema que ejecute las operaciones necesarias para obtener los resultados deseados, pero habrá una gran diferencia en dedicación de recursos entre un sistema de seguridad básico, medianamente completo o lo más completo posible. Cuando hablo de un sistema de seguridad, no me refiero solo a la seguridad de la información en sí misma (por ejemplo acceso lógico y físico a los sistemas), que es esencial, sino también a la seguridad de su tratamiento. Esto incluye minimizar las intervenciones manuales de operador, la identificación previa y prevención de fallos y errores de proceso, la recuperación de datos cuyo ciclo de proceso no se haya completado, el control de calidad de los datos obtenidos, etc. En esta etapa, los costes pueden dispararse y si al cliente se le ha prometido una solución económica (¡quién no la quiere!), y además vamos mal de tiempo en la fecha de entrega o pasados de horas en el desarrollo del sistema podemos encontrarnos frente a una decisión crucial: hasta dónde y cómo se dedican recursos y tiempo a implementar las herramientas de control y recuperación/re-arranque de los procesos a ejecutar.

Por tanto, el sistema se podrá entregar al cliente para su explotación, tras unas pruebas en las que este verá unos resultados acordes a lo que necesita (es lo mínimo que se le puede pedir a un sistema), pero seguramente no podrá analizar (casi siempre porque no sabe cómo hacerlo) la seguridad del sistema que se le va a entregar, ni el riesgo de incidencias que pudieran afectar al proceso de su información y por tanto a la calidad de la misma y el impacto en sus negocios.

Estamos en una época que me parece la vuelta al pasado. Mi primer trabajo fue como programador en un “Centro de Cálculo”, como lo llamaban por los años 70, ya que se hacía el análisis, la programación y posteriormente el proceso de los datos del cliente y se le entregaba la información procesada. Como la empresa era responsable de todo el ciclo, se preocupaba bastante de su efectividad y rentabilidad, por lo que la calidad de los programas se vigilaba de cerca. Recuerdo que cuando probé mi primer programa en aquel Honeywell Bull “Gamma-10”, había un tribunal detrás de mí, compuesto por compañeros del departamento (yo era el novato), el analista y el jefe de explotación, que abrieron la panza del sistema (un armario enorme) para ver la circulación de las tarjetas de datos por la banda central de la CPU. Si iban todas seguidas, sin huecos entre ellas, es que el programa estaba bien diseñado y no perdía ciclos de procesador, si no, había que volver con él a la mesa y revisarlo. ¿Por qué se hacía esto? Porque el precio por minuto de uso de este sistema era alto y había que rentabilizarlo haciendo el máximo de procesos diario.

Después vinieron las computadoras para PYMEs y luego el tener cada uno su propio CPD, pero los costes de esta última solución solo fueron rentables un corto tiempo y hoy estamos de nuevo en la época de externalización de servicios provistos por terceras empresas. El gran problema que se presenta en estos casos es la diversificación de proveedores, ya que frecuentemente cuando quien diseña un sistema no va a explotarlo y pretende abaratar su coste y posterior mantenimiento, lo simplifica a tal punto que la operación del mismo asume riesgos que no debería. Cuando se producen incidencias o errores, el cliente suele apuntar al proveedor que explota el sistema y no al que lo ha diseñado.

Es por tanto vital establecer procedimientos y protocolos de validación y compromiso en la implantación y gestión de los sistemas cuya responsabilidad está repartida entre varias empresas. En estos casos, los intereses de los proveedores pueden ser incluso contrarios, lo que repercute en perjuicio del cliente, que debe asumir la nada fácil tarea de control y coordinación de los mismos. Para ello es conveniente una buena experiencia en ambas áreas: la de diseño y desarrollo y la de explotación de sistemas.

Parámetros de entrada. Ese gran agujero de seguridad por el que se cuelan dos de las vulnerabilidades más comunes en cualquier aplicación web: Inyección SQL y Cross-Site Scripting. No están por casualidad en los puestos número uno y tres del TOP 10 de OWASP de este año 2013.

Y es que es una batalla por la que los pentesters luchamos a diario. La formación sobre desarrollo seguro sigue siendo, a día de hoy, escasa. Por poner un ejemplo, de todo el material de un máster sobre desarrollo web al que he podido echar un vistazo, de un año de duración, las referencias sobre seguridad son una única sección, de un tema, de una asignatura, con un total de 9 páginas. La información sobre la correcta implementación de medidas de seguridad es obviamente insuficiente.

Pero el problema también se encuentra en nuestro lado de la mesa. Si después de haber entregado un informe de un test de intrusión a un cliente, las correcciones tomadas han sido insuficientes, es que no hemos sido capaces de transmitir la gravedad de la vulnerabilidad, ni la forma correcta de mitigarlas. La solución “filtrar correctamente los parámetros de entrada” necesita una explicación más extensa sobre lo que quiere decir “filtrar correctamente”.

Por este motivo, me he decidido a enumerar unas recomendaciones generales, pero un poco más precisas, sobre el filtrado de parámetros de entrada. Empecemos:

• En primer lugar, una pregunta recurrente: ¿Dónde deben validarse los datos de entrada? ¿En el lado del cliente? ¿O en el del servidor? Seguramente os habréis dado cuenta de que es una pregunta trampa porque la respuesta correcta es en los dos lados ;) . Es imprescindible que toda validación y filtrado de datos de entrada se realice en el lado del servidor, ya que el lado del cliente es ejecutado por el usuario, y las restricciones se pueden evadir. Pero también es recomendable añadir validación en el lado del cliente, no por temas de seguridad, pero si por usabilidad. A pesar de que el servidor va a comprobar que todo lo que reciba es correcto, viene bien que un javascript compruebe también que se están escribiendo datos correctos, por ejemplo en un formulario. Ahorras tiempo al usuario, y ahorras ancho de banda al servidor.
• Filtrar TODA la entrada. No se debe limitar a los datos que escribe el usuario en la barra del navegador, o los campos de un formulario. También los campos ocultos HTML de un formulario, las cookies, cabeceras HTTP. No presuponer que el usuario no va a tocar esos datos porque la aplicación no dispone de esa funcionalidad. Con un proxy HTTP, o con una simple extensión del navegador, como tamper data, es posible modificar cualquier cosa que se vaya a enviar de nuestro navegador al servidor.
• No reinventar la rueda: no complicarse la vida. No es recomendable crear desde cero una implementación propia, ya que probablemente no contemple todos los casos posibles. Mejor usar funciones ya testeadas y maduras como las disponibles en prácticamente cualquier lenguaje de programación o framework. También se puede usar la librería ESAPI de OWASP, con APIs para Java, Python, .NET, PHP, ASP, entre otros.
• Comprueba tipos de variables: si un parámetro de entrada solo espera recibir un entero, comprueba si lo que recibe es efectivamente un entero. En datos como IDs de objetos suele ser bastante útil, del estilo de http://a/index.php?id=400
• Como complemento al punto anterior, usa listas blancas de datos permitidos, y deniega todo lo demás. Es mucho más sencillo definir lo permitido, que enumerar todo lo prohibido. Por ejemplo, para una cadena de texto, se puede definir que sea válida toda cadena que contenga a..z, A..Z, 0..9 y todo lo demás eliminarlo. Con esto se evita el uso de caracteres especiales.
• Si no se desea filtrar caracteres especiales, por requerimientos de la aplicación, usa codificación de salida a la hora de representar los datos. Por ejemplo, codificación HTML para caracteres especiales, como “>” que pasa a ser “>” o “&” “&amp”.
• Antes de filtrar, codifica. Los datos de entrada pueden venir de muchas formas codificadas. Siguiendo el ejemplo del anterior punto, el carácter “>” se puede representar también como “&gt”, “%3E”, o “&#x3E”. Es conveniente normalizar todo el texto, antes de aplicar los filtros. La librería ESAPI dispone de la función canonicalize() para pasar una cadena directamente a ASCII.
• Controla el tamaño de la entrada: no sólo es recomendable controlar que entra, si no también cuanto. Con esto, se evita cualquier problema de denegación de servicio, por saturar al servidor con una entrada enorme, y también de los peligrosos de desbordamientos de buffer.

Como veis, son bastantes las consideraciones que hay que tener en cuenta para que nuestra aplicación sea robusta de cara a los datos que entren. No obstante, una vez comprendida la posible vulnerabilidad y su riesgo, es fácil aplicarle la medida correcta.

Como muchos de nuestros lectores ya sabrán, Security Art Work nació en Abril de 2007 y en mayo de 2011 nació su hermano pequeño, Hijos Digitales.

Desde él intentamos informar de las novedades tecnológicas que van llegando al mercado, de nuevos descubrimientos que llegan a nuestra vida, nuevas opciones para configurar nuestro correo, aplicaciones para nuestro smartphone, Whatsapp, noticias relaciondas con ciberbullying… Intentamos abarcar todos los temas relacionados con el mundo digital que puedan ayudar, informar y entretener a familias enteras: abuelos y abuelas, padres y madres y sus hijos y nietos digitales.

Hemos pasado dos años contando ideas, trucos y consejos para que el uso de las Nuevas Tecnologías y, sobre todo, el uso que hacen vuestros hijos de éstas sea seguro. Ahora, desde Hijos Digitales lanzamos el concurso ¿Estás seguro? para que nos digáis qué precauciones tomáis a la hora de usar Internet y las Nuevas Tecnologías.

[Read more…]

Hace bastantes años (1971) que me dio por aprender informática, materia entonces apenas conocida por el gran público. Me encantaba pararme a mirar cómo giraban los carretes de cinta magnética en sus unidades encristaladas o cómo se leía una caja de tarjetas perforadas en un instante, aquel tremendo bicho que se veía en las oficinas de IBM en la plaza de la Porta al Mar (Valencia), con un centro de proceso de datos que tenía una fachada de cristal que daba a la acera de la plaza. Desde allí, veía un IBM 360 con su lector de tarjetas y cinta perforada, sus unidades de disco más grandes que una lavadora sus unidades de cinta magnética, tremendos carretes de cinta de 9 milímetros de ancho y también una impresora enorme, que se comía las cajas de papel continuo a una velocidad endiablada. Todo aquello, atendido por dos operadores que vestían su bata blanca y gestionaban el sistema a través del teclado y el papel impreso de una máquina de escribir IBM eléctrica, de bola. Todos los caracteres estaban moldeados en una bola de plástico que giraba sobre dos ejes para poner el carácter solicitado frente a la cinta entintada y ¡zas! le arreaba al papel y allí quedaba impreso.

El caso es que me inscribí en un curso de programador de aplicaciones para el sistema IBM citado que daban en una escuela privada, en lenguaje ensamblador, de la que conservo el diploma correspondiente. La casualidad hizo que mi primer y único programa hecho durante ese curso lo fuese a compilar y probar en el citado ordenador que tanto tiempo había admirado. Cuando me senté junto al operador de bata blanca y la gente me veía desde la calle, me sentí privilegiado por manejar aquella nueva cosa: la informática, consiguiendo crear un programa para aquella enorme máquina siguiese y ejecutase mis instrucciones. Ahí terminó inicialmente mi relación con el IBM que tanto admiraba.

Después de hacer otros tres cursos de programador, cada uno en su propio ensamblador, otra casualidad me llevó a trabajar justo en la oficina de al lado de donde estaba IBM, en el primer piso del mismo edificio. Allí estaba Nixdorf Computer, una empresa creada por el señor Heinz Nixdorf en Alemania con sucursales en España y que fabricaba y comercializaba sus propios computadores. En realidad el que yo comencé a gestionar era más bien una gran facturadora, pero tenía su sistema operativo, su lenguaje ensamblador propio y sus dispositivos de entrada y salida de información. La consola de la Nixdorf 820/15 era una máquina de escribir IBM idéntica a la del sistema 360 y esto lo aprovechaban los comerciales de la casa para convencer al cliente de que aunque compraban un computador de su marca, en realidad era un IBM más económico (cosas de aquellos tiempos). La verdad es que se lo merecían porque cuando entraban por la puerta o llamaban por teléfono, decían que querían información para comprar “una IBM”. La palabra ordenador o computadora no era fácil para ellos, era más sencillo hablar de una IBM.

Ha pasado mucho tiempo desde aquello y ahora, en la sala Idea de las oficinas de S2 Grupo en Valencia, junto a los viejos equipos que allí se exponen, hay dos cajas metálicas de tamaño folio y unos cinco centímetros de grosor que contienen el sistema operativo de la Nixdorf 820/15 en una y la definición de la base de datos del cliente en la otra. Esta última lleva dos bandejas con orificios alrededor de los cuales se hacía pasar un hilo, bien por arriba o por abajo, para que una vez situadas las bandejas en la placa, los núcleos de ferrita que pasaban por los orificios hicieran su trabajo al generar un cero o un uno binario según el pulso de corriente que pasaba alrededor.

Así funcionaba este sistema y a esta “memoria cableada” la llamaban “memoria fija” y su capacidad máxima era de 1024 bits (no bytes) ya que además las instrucciones en lenguaje máquina que el sistema gestionaba tenían un formato como este:

|_,_,_|_,_,_,_|_|_,_,_|_,_,_,_|_,_,_,_|

|Comando...|I| Dirección de memoria|

Es decir, 3 + 4 bits para el comando (0.0 a 7.F), 1 bit de índice (0 o 1), y 3 bits + 4 bits + 4 bits para la dirección de memoria (0.0.0 a 7.F.F)

Los programas se escribían en un ensamblador propio, se perforaban en tarjetas de cartulina de 80 columnas, se compilaban y depuraban los errores y finalmente se pasaban a fichas de banda magnética (tamaño A4 con perforaciones para el arrastre en ambos lados y una banda magnética impresa en su derecha), donde se almacenaban programas y datos de clientes, productos, etc. Es decir, la base de datos estaba en registros y cada registro en una ficha física. La seguridad de los ficheros (se llaman así porque se componían de “fichas”) dependía de quién custodiaba la llave del archivador de fichas.

La base de datos se definía manualmente: se perforaba en tarjeta de 80 columnas, se compilaba y una vez correcta, se perforaba en una cinta perforada, que era un carrete de cinta de papel donde se perforaban las imágenes de los cableados de las placas que he citado. Se ponía la cinta en un proyector con luz interior, se ponía la placa encima y donde pasaba la luz, se cableaba un uno, donde no había luz, se cableaba un cero, pasando el hilo de cobre por encima o por debajo del orificio correspondiente. Es difícil de concebir para alguien que no haya tenido relación directa con ello.

Lo bueno del sistema es que la estructura de los ficheros (iba a decir la base de datos, pero no, no lo era), quedaba cableada para siempre o hasta la siguiente modificación, así que había que afinar mucho en su definición. Lo malo era que si fallaba un cable había que parar la máquina hasta volver a soldarlo.

El acceso a los registros de los ficheros era directo: el operador buscaba la ficha en cuestión y la introducía en el lector a mano. Se leía, se imprimía el movimiento correspondiente sobre ella y se actualizaba la banda magnética, luego se devolvía a su sitio. Otro acceso era el secuencial, para obtener un balance o un listado de clientes, productos, etc. En este caso se iban introduciendo en secuencia una a una.

Bendito invento fueron los cassettes de cinta magnética, donde cabían un montón de fichas, peeeeeero… no había posibilidad de acceso directo, solo secuencial. Al final aparecieron los discos magnéticos, pero esa fue otra historia.

A continuación hay algunas de las fotos de las placas que mantenemos en la sala Idea como parte de la historia de la informática que hoy es otra cosa; un smartphone tiene 100 veces más capacidad de proceso y memoria que el módulo de alunizaje del Apolo 11. Todo el mundo pretende saber mucha informática, pero normalmente no han visto una tarjeta perforada ni las han leído mirando las perforaciones contra la luz de la ventana, ni tampoco han depurado programas leyendo vuelcos de memoria en papel, en hexadecimal binario, ni tampoco van con bata blanca. Pues eso, que es otra cosa.

Hace tiempo que se sabía que la NSA y algunas organizaciones de similar naturaleza tenían desplegados sistemas cuyo objetivo es velar por la seguridad y protegernos del maligno (Chema Alonso no, otro maligno). A pesar de ello, la NSA siempre prefirió mantenerse en secreto para no verse obligada a rechazar el premio Nobel de la Paz. Sin embargo, tras conocer los casos de Snowden, Manning, Assange y otros rebeldes, es evidente que la situación se ha vuelto insostenible y no les ha quedado otra que salir del armario.

Por suerte, la certeza de que la NSA escucha nuestras conversaciones, lee nuestros correos, espía nuestra actividad en las redes sociales y básicamente sabe todo lo que hacemos no ha generado ningún movimiento reseñable a nivel político ni social, porque lo hacen por nuestro bien (ahora que lo escribo, recuerdo con claridad haber oído eso en más de un momento de mi infancia). No sería deseable que por culpa de las ansías de justicia y libertad de unos pocos (literalmente) el resto nos viésemos abocados al infierno y el caos existencial.

Seguramente en breve recibirán el Nobel de la Paz.

Algunos Hombres Buenos. En la sala de juicios el teniente Daniel Kaffee (Tom Cruise) ha subido al estrado al Coronel Jessep (Jack Nicholson):

(A partir del minuto cinco, aproximadamente)