Archivo de la categoría: Tecnología

La pandemia, el pasaporte covid y el teatro de seguridad

https://www.sandiegouniontribune.com/en-espanol/cultura/articulo/2020-12-14/una-pinata-del-coronavirus-para-desahogarse-del-2020

¡No dejemos que pase un año entero sin publicar siquiera una entrada! Desde luego, ha de ser sobre la pandemia.

Estamos casi todos con la pauta de vacunación completa (dos dosis los de Team Pfizer, Astra Zeneca, Sputnik, una los de Moderna y los CanSinos) y nuestros seniors ya van por el refuerzo. Eso es genial y está siendo crucial a la hora de controlar la pandemia.

En verano hemos vuelto a viajar y se ha estandarizado el uso de una cosa llamada «pasaporte COVID». En el caso de los residentes en la Unión Europea se trata de un documento estandarizado para todos los países de la Unión. En otros países se dispone de los certificados de vacunación, muchos manuscritos, pero en fin, nos hemos acostumbrado a viajar con el cachopapel en la mano (o con su versión PDF o fotografiada en el teléfono móvil). Qué les voy a contar que no sepan ya.

Bueno, pues yo vengo a hablarles de mi libro del concepto de teatro de seguridad ideado por Bruce Schneier y muy bien explicado por Versvs.

En campechano, se trata de montar un paripé para que la gente se quede con la idea de que se está haciendo algo al respecto de una situación que da miedito.

Pues ahí les va. Tenemos conocidos que han dado positivo por COVID19 y que son asintomáticos (recordemos que incluso sin síntomas pueden contagiar), que están confinados y, adivinen… cuyos pasaportes COVID salen más verdes que una lechuga del Mercadona. Vamos, que si salen a la calle y se van al cine, al bar, al restaurante, al IKEA, a donde les dé la absoluta gana, mostrando el QR, nadie los va a detener. No digo que lo estén haciendo, porque son gente responsable, pero que podrían, podrían.

Entonces ¿de qué sirve el cacho papel ese?

Teatro de seguridad.

Incendios, planes de contingencia y la pegatina

La #bonillista de hoy, escrita por Txetxu Velayos y tratando el tema del incendio del proveedor de servicio de almacenamiento OVH, los SLA (acuerdos de nivel de servicio) y qué diablos pasa cuando lo impensable sucede, me ha traido a la mente mis viejos tiempos de SysAdmin, así como esta pegatina. Agárrense, que vienen batallitas que ni las de la mili:

Vamos al tajo. Yo salí de la universidad como «computer scientist» de los de verdad: no me dejé ni una asignatura de matemáticas, ni de lógica, ni una de complejidad algorítmica, sistemas formales, inteligencia artificial. Me quité de encima la electrónica en cuanto me lo permitió el plan de estudios, aunque me chuté todas las de arquitectura de computadoras por lo flipante de la optimización de algoritmos que se explicaba, y la verdad sea dicha, las cosas en las que pensaba estaban muy distantes de la máquina o incluso de lo que se esperaba de un informático en el mercado laboral español de los años 90. Así que me fui… (insert other batallitas here…)

… y por azares del destino, ¡¡¡muy pronto me vi trabajando de administradora de sistemas!!! 200 servidores Windows NT distribuidos por toda Europa, medio centenar de ellos en el Data Center de la oficina.

¿Data Center en la oficina? Sí. De hecho el primer curso de formación que me dieron en esa empresa fue… ¡¡¡Halón!!! que era el gas que se liberaba en los data centers de aquella época en caso de incendio.

Eran unos tiempos muy curiosos. ¿Abrías una oficina o una fábrica en, pongamos por ejemplo, Hannover? Pues entonces tenías que deplegar al menos un servidor de ficheros y de impresión local, que además te servía de controlador de dominio. ¿Y cómo desplegabas? «Facilísimo». Hablabas por teléfono con tu proveedor de hardware (por ejemplo Compaq), acordabas con él la especificación del servidor y te mandaba el presupuesto. Lo imprimías, conseguías la firma de tu jefe y lo llevabas al departamento de Compras, que emitía el pedido. Un mes después más o menos te llegaba.

Te llevabas las cajas a tu mesa de trabajo, desembalabas la carcasa, los discos, el procesador, la memoria, otras tarjetas que necesitases (¡por ejemplo, una de fax!), pero normalmente eso era todo. Lo montabas todo (usando las manos, destornilladores,..), sacabas de tu cajón los CD’s y te ponías a instalar el sistema operativo, otros programas servidor (¡hola, MTA’s de MSMail y Schedule+!), lo dejabas todo listo para que en destino cambiases la direccion IP, conectases a la red y ¡todo listo!

Usar una imagen era impensable, el Ghost fallaba como escopeta de feria. Yo me automatizaba todo lo posible con DOS scripting (un conocimiento que muchos años después me ha hecho parecer una diosa nubia ante compañeros bastante buenos pero que en la vida habían visto una línea de comandos), todo y ello había muchísima componente manual en lo que hacíamos.

En destino (Hannover en este ejemplo) significaba: Si estabas a menos de 500 Km de distancia sin el Canal de la Mancha por el medio, metías tu servidor al coche, te pegabas un día conduciendo y al día siguiente montabas (si era el primero, también tenías que montar el rack). Si no, enviabas el servidor montado por paquetería, te pillabas un avión y allá ya acababas.

Esta última fase del trabajo podía durar de 15 minutos (colocar servidor en el rack, arrancar, cambiar la IP, conectar a la red, reiniciar) a 8 horas (hacer la instalación completa desde cero). El año 2000 me pilló con este trabajo, así que la cantidad de horas extra actualizando / sustituyendo servidores fue indecente. Idem la cantidad de puntos de línea aérea que acumulé y las ciudades que pude conocer cuando se alineaban los astros y la máquina arrancaba a la primera. De la complejidad algorítmica, ni rastro.

Dónde está el LISP, los sistemas expertos, la completitud de Turing y las gramáticas de Chomsky, que yo las vea.

Se imaginan los LOLZ que me pego yo sola cuando alguien jovencito se estresa por hacer un deploy de una máquina en AWS hoy en día 🙂 Ya en serio, esta experiencia me permite apreciar y agradecer todo lo que el IaaS, el PaaS, el SaaS, la nube, el DevOps y resto de siglas nos permiten hacer sin despeinarnos. La verdad, me quito el sombrero ante AWS, que inició todo esto, y resto de proveedores que no se quedan atrás .

Aparte de este trabajo eminentemente técnico y machacón, también nos encargábamos de la seguridad, los parches, el soporte, el diseño de la configuración de nuevos equipos y nuevas versiones de software… y las tareas que considerábamos administrativas y aburridas, no por ello menos importantes, al menos para nuestro management, que, quizás por aquello de que los servidores eran trastos con los que convivíamos, no entes virtualizados de varios niveles de abstracción, entendían lo que teníamos entre manos y podían ejercer sin problemas su sentido común.

Sentido común en este contexto es:

  • ¿Cómo diablos sigo operando mi negocio (vendiendo, produciendo, entregando, cobrando facturas, pagando proveedores y nóminas) si me quedo sin todo este trasterío?
  • ¿Cómo diablos recupero todo este trasterío, si se destruye, por ejemplo debido a un incendio? Recuperación de la información así como restauración del servicio.

A lo primero se le llama Business Continuity Plan. A lo segundo, Disaster Recovery Plan. Era nuestra obligación que ambos planes existiesen, estuviesen actualizados y fueran coherentes, aunque el primero lo compartíamos con las áreas operativas. Ellos sabían: ¿Cuál era el nivel de servicio que proporcionábamos a nuestros clientes? ¿Disponibilidad de atención a cliente, de tiempos de entrega, de stock de producto, todo ello por obligación contractual? En base a todo ello se escribía el plan y se tenía todo preparado por si había que utilizarlo. Eso significaba desde tener libretas de papel y bolígrafos para poder capturar pedidos, así como una preorden de oficina por si hay que mover allá el call center, poder enrutar las llamadas entrantes a unos cuantos teléfonos móviles, hasta tener los sistemas de información duplicados y poder hacer el cambio en caliente en caso de no disponibilidad del sistema principal.

Antes de explicar el Disaster Recovery Plan, déjenme hablar de backups o copias de seguridad. Antes de que se inventaran los backups por red, se hacían copias de respaldo de todos los servidores cada noche. Una vez a la semana hacíamos la copia completa, el resto de días solo la incremental. Y cada mañana enviábamos por paquetería los cartuchos de backup a la empresa que gestionaba los backups. Los cartuchos, por cierto, no se insertaban solos, había que empujarlos y a la mañana siguiente, sacarlos. Con las manos. En ubicaciones muy remotas contábamos con la valiosísima colaboración de la señora de la limpieza (que era la última persona en dejar la oficina por la tarde) para este menester.

Para el Disaster Recovery Plan, teníamos contratado un servicio con esa misma empresa que, caso de necesitarlo, ponía a nuestra disposición el hierro (servidores) y los CDs y los manuales que nosotros les hubiésemos proporcionado, así como la última versión de backup que habían recibido de nosotros. A esa ubicación se enviaba un equipo de técnicos (nosotros) para reconstruir todo y llevarlo a un punto que pudiera restablecerse el servicio de sistemas de información.

Lo más divertido es que en el plan incluíamos un ejercicio anual de prueba del propio plan (un quién vigila al vigilante, vamos). Me tocó participar una vez: coche en Manchester desde Londres a toda velocidad (nos cronometrábamos para ver cuán rápido podíamos restablecer el servicio), trabajar 16-20 horas seguidas hasta que todo quedase (y luego un fiestón mancuniano, una siestaza y de vuelta al sur). Y si no quedaba, pues entonces teníamos otra semana de trabajo garantizada identificando el por qué, corrigiendo los fallos en el procedimiento y volviendo a documentar.

Y vaya si son necesarios estos planes. Disaster Recovery no llegué a experimentar en vivo, Business Continuity Plan, sí. Nos explotó una empresa química en el polígono, nos evacuaron y se tuvo que montar sobre la marcha. Es una sensación increíble saber que tu pedantería a la hora de elaborar documentación ha significado que ningún paciente de EPOC de la campiña inglesa se ha quedado sin su entrega de oxígeno medicinal.

Volvamos a la actualidad: No existe ninguna razón por la cual tanto el Business Continuity Plan como el Disaster Recovery Plan hayan dejado de ser necesarios. Creo que las nuevas generaciones, especialmente las de management, están practicando el proverbial «ojos que no ven, corazón que no siente». Has migrado tu infraestructura a la nube. Cierto, ya no necesitas dos meses para aprovisionar hardware. Ya no necesitas pagarme el avión a Hannover, ni siquiera pagarme el sueldo. Pero la magia no existe. Solamente has externalizado la gestión de la infraestructura informática, eso significa que alguien más se ocupa de ella, pero no por ello es, por arte de contrato, irrompible: it’s someone else’s computer! Sigue siendo tu resonsabilidad estar preparado porque shit happens also on the cloud, tienes que saber cómo seguir dándole servicio a tus clientes (Business Continuity Plan) así como disponer de un Disaster Recovery Plan, o, en castellano común, cómo no perder irremediablemente lo más importante de una empresa del siglo XXI: tus datos, tu información, tu inteligencia. El poder echarle la culpa a otro con el contrato en la mano no te los va a devolver.

Enlace a la #bonillista de hoy: La Bonilista (mailchi.mp)

SolarWinds y Supernova, un fiasco de ciberseguridad

Leo el artículo de Bruce Schneier sobre el hackeo masivo a la administración estadounidense y hasta el tato en realidad (Microsoft también) debido a una vulnerabilidad en el protocolo de seguridad del omnipresente producto Orion de la empresa Solar Winds. Da qué pensar lo frágil que es la sociedad actual a este tipo de soluciones, y pensando talebianamente, me pregunto qué podemos hacer a modo personal ya no para ser robustos (a la Sara Connor) sino para ser antifrágiles a este tipo de situaciones.

(2011) iPad: ¿éxito abrumador o fenómeno preocupante?

Publicado en periódico El Azotador (Xochimilco, Ciudad de México) en 2011:

Nuestros lectores recordarán el entusiasmo con el que les hablamos en ocasiones anteriores sobre el lanzamiento de productos de Apple que consideramos tan innovadores, que de hecho representaron un antes y un después en su categoría, como su famoso teléfono iPhone. Hace unos meses, Apple volvió a sacudir el mercado con la introducción de su dispositivo “tablet”, el iPad, una especie de computadora portátil sin teclado, del tamaño de un papel tipo carta, y cuya pantalla proporciona una resolución y calidad de imagen no vista hasta la fecha en aparatos para el consumo masivo, pero este hecho no produjo un artículo entusiasta por nuestra parte. Esto no es un hecho fortuito.
Efectivamente, el iPad incorpora tecnología no vista hasta la fecha. Su lanzamiento comercial en abril de 2010 fue un éxito, provocando el pánico habitual y las coloridas y pintorescas filas nocturnas a la puerta de sus establecimientos, puesto que todos los auténticos fans de Apple quieren ser los primeros en poseer sus inventos, y el índice de ventas no deja de subir, colocándose por encima de los 20 millones a nivel mundial desde su lanzamiento hasta fin de año. ¿Por qué, pues, no nos gusta a los expertos?
Los “tablets”, u ordenadores estilo pizarra, sin teclado, suponen un cambio de paradigma en la computación personal y en el uso de Internet. La red de redes, la Web, nació como una plataforma para compartir información (científica en su origen, pues se inventó en el Laboratorio Europeo de Física de Partículas en Suiza, pero de toda índole una vez todos comenzamos a utilizarla), las computadoras domésticas han servido para que millones de personas generen contenidos: ya sea haciendo la tarea de la escuela, escribiendo los eventos del mes en el boletín enviado a sus familiares que viven lejos, compartiendo una foto de los sobrinos para la tía que vive en otro continente. Todo ello acciones que requieren de un mecanismo cómodo para introducir información, para escribir, es decir: un teclado. El iPad también se podría definir como una laptop a la que precisamente le han arrancado dicho dispositivo. El resultado: una bellísima y capaz computadora que sirve principalmente para convertir a su propietario en un objeto pasivo, en un mero consumidor de entretenimiento. Si tienen ocasión de convivir con personas que posean un iPad, obsérvelos: en un 95% de las ocasiones estarán viendo una película.
Si esta tendencia prospera, y las personas solamente usan la Red para idiotizarse, perderemos una oportunidad única para la generación y compartición de conocimiento. Internet se convertirá en una burda copia de los sistemas tradicionales de comunicación masivos (radio y principalmente televisión) en cuanto unos pocos son los que deciden los contenidos que pueden ver los demás. Perderemos la libertad de decidir qué queremos y qué no queremos ver, de qué manera nos queremos informar… y además quitaremos el potencial de poder de la información que la estructura variada y distribuida de Internet nos podría conceder, y se la devolveremos a los grandes grupos de la comunicación, que gustosamente continuarán ejerciéndola.
Es por esto que el éxito de un nuevo producto novedoso que incorpora innumerables desarrollos tecnológicos como es el iPad se nos antoja un fenómeno preocupante.

Del InterNot of things (IøT) al We put a chip on it!

Esto sí es una fiebre incontrolable, la Internet de las Cosas. La semana que viene tendremos el congreso mundial aquí en Barcelona. Espero que la ciudad se llene de carteles y que esto crezca más que el Mobile World Congress.

Mientras tanto yo me río con la contra-cultura que surge:

InterNot of Things (IøT) del cual un célebre precursor fue ProtecciónRFID, ehem…

El divertidísimo «We put a chip in it» para medir las tonturas que se están haciendo en el área. ¡Todo ello es cierto!

Quantified self en manos de tu jefe, no es una buena idea

Ojo, que por aquí nos viene un peligro más que evidente de control del individuo por parte de su empleador, siempre a favor del segundo.

http://www.bloomberg.com/news/articles/2015-08-12/wearable-biosensors-bring-tracking-tech-into-the-workplace

Ojo, yo uso wearables para auto controlar mi estrés y saber retirarme a tiempo de una reunión / conversación que le esté haciendo daño a mi mente y a mi cuerpo. Estoy muy lejos de ser una neo ludita. Pero estas tecnologías en manos de los empleadores son para tratar a los empleados como «recursos humanos» y optimizarlos a corto y tirarlos a la basura cuando se rompan.

Mucho ojo, por tercera vez.

Cuttlefish en Ubuntu 14.04

Andaba haciendo algo de limpieza en el hosting y me di cuenta que años ha había instalado MyTinyTodo como gestor de tareas libre y autogestionado. Ya saben que hace un par de años nos dio por la Indie Web. No crean que dicha herramienta cayó en desuso por haberme pasado a EverNote y su simpático elefantito. Más bien se ha tratado de una mezcla de vorágine laboral (y en ese contexto no puedo usar ninguna de las dos opciones sino una corporativa que no funciona) y de uso de libretas tangibles y analógicas. En fin, sorpresas da la vida y en este caso me he encontrado al menos dos en forma de tareas pendientes de realizar. Una de ellas ha sido la película 55 days in Peking (1963), pendiente de ver y totalmente olvidada más de 600 días. La otra ha sido una tarea críptica y misteriosa que rezaba:»Instala Cuttlefish».

Picada por tal misteriosa instrucción, me he puesto a hacer un par de búsquedas.

Cuttlefish es una deliciosa herramienta para Ubuntu que sirve para implementar «reflejos», entendiendo por estos a los pares «estímulo – reacción». Piensen en el martillito que golpea la rodilla que hace que se mueva el pie. Una especie de If This Then That pero para el ordenador.

Lo he instalado siguiendo estas instrucciones. Me he inspirado en este post y por supuesto en el vídeo introductorio de Alex vBK (el creador de la herramienta) y en cuestión de segundos he podido crear unas cuantas recetas curiosas.

Selection_005

Lo recomiendo encarecidamente.

No existe la nube. Simplemente estás usando el ordenador de alguien

Hoy me he encontrado esta pegatina súper bonita y totalmente cierta.

there is no cloud

La traducción es el título de este post.

Estoy por pedirme unas cuantas. Es algo que todo el mundo debería comprender. Y los que ya lo comprendíamos, deberíamos tenerlo siempre presente. Antes de postear algo, antes de compartir algo en una red social, deberíamos reflexionar: ¿Estoy segura que quiero regalar esta información a alguien más?

Libro: Contra la seguridad. Nos estamos equivocando en aeropuertos, transporte público y otros lugares con riesgo ambiguo

He leido la revisión de la revisión de este libro y tiene pinta de que va a ser interesante.

Against Security: How We Go Wrong at Airports, Subways, and Other Sites of Ambiguous Danger trata el tinglado de seguridad (o teatro de la seguridad en palabras de Bruce Schneier) pero desde el punto de vista de la psicología.

Resumen en una frase: a los no iniciados todos esos scanners les hacen sentir más seguros, lo cual es malo, pero peor es cuando los agentes de seguridad se acaban creyendo ellos mismos su mentira y dejan de usar mecanismos de investigación más efectivos.

A la lista de lectura de estas vacaciones de Semana Santa