jueves, 3 de mayo de 2018

Entrando al trapo con BlockChain

Desde que escribí mi anterior entrada, una breve reflexión sobre Blockchain, he seguido 'dándole vueltas' al tema, leyendo, asistiendo a eventos, etc.. Y creo que ya puedo plantear cuestiones que no son ni evidentes ni nimias, y a las que habrá que dar solución en breve. No tocaré aspectos técnicos, tranquilos.

Blockchain se encuentra ahora en un estado similar a como se encontraba la Web en 1994. Esta reflexión ya la he leído y oído más de una vez (a William Mougayar y a Pep Lluis de la Rosa), en el sentido de que aún no sabemos todo lo que la tecnología Blockchain va a permitirnos hacer, igual que casi nadie imaginaba en 1993 en el CERN hasta dónde iba a llegar la tecnología web que regalaron al mundo entero. Es evidente que su primera aplicación han sido las criptomonedas, pero no será la única. La trazabilidad, la seguridad y la transparencia que aporta Blockchain son unos activos muy útiles para muchas de las actividades actuales, como la fe pública, ahora en manos de determinadas personas o instituciones. Aspectos tan importantes para todos como la lucha contra el fraude, las elecciones (como se demostró en el excelente taller organizado por la Cátedra de Transparencia y Gestión de Datos de la UPV en la TechFest'2018)  o la trazabilidad alimentaria pueden apostar a que en el futuro (o en el presente) harán uso de esta tecnología (vía José Manuel Calabuig).

Leyendo este excelente artículo de Victor Almonacid, creo que debo puntualizar algunas de las cosas que menciona, y que, sobretodo, son importantes para el uso de esta tecnología en la Administración Pública.

Lo primero, debe quedar claro que habrá tantas Blockchain como se quieran crear, cada una con su protocolo y sus reglas de participación. Las Blockchain públicas, como aquellas que se usan para las criptomonedas, o para Interplanetary File System (IPFS), tienen algún mecanismo de recompensa para los nodos que intervienen en la validación de las transacciones y en el almacenamiento de las copias distribuidas de las mismas. Por ejemplo, en Bitcoin cada cierre de bloque se recompensa con 12 BTC. En una Blockchain para las AAPP (¿quizá corriendo sobre la Red SARA?) eso no puede ser así, dado que hay problemas, sin ir más lejos, de índole legal:
  • ¿Con quién firmará la AAPP el contrato de prestación de servicios para poder pagar esas recompensas si cualquiera puede ser un nodo de esa Blockchain y recibir recompensas por su trabajo, de acuerdo a las reglas establecidas en esa cadena de bloques?
  • ¿Cómo se calculará el coste estimado del servicio recibido, teniendo en cuenta que las transacciones que se validen se desconocen a priori y que si se paga el servicio en alguna criptomoneda ésta puede fluctuar?
  • ¿Puede una AAPP española pagar en una moneda diferente del euro estos servicios?
Por tanto, la primera conclusión es obvia: la Blockchain adecuada para las AAPP no debe estar basada en la recompensa, ni ser pública (en el sentido de que cualquiera pueda desplegar un nuevo nodo en la misma), sino que debe estar basada en el mutuo beneficio y apoyo entre las diferentes entidades que formen parte de la Blockchain.

Las posibilidades que traería consigo crear una Blockchain de las AAPP españolas (o incluso europeas) son enormes. Por ejemplo, cada una de esas AAPP podría ejecutar sobre la cadena de bloques los smart contracts que le hiciesen falta para su gestión, sin preocuparse de aspectos como la confidencialidad, la disponibilidad, la trazabilidad, la autenticidad y la integridad de los datos almacenados en la misma, ya que de eso se encarga la propia tecnología. También podría utilizarse para que los ciudadanos pudiesen votar tranquilamente (y de forma segura y válida) desde su teléfono móvil cualquier tipo de consulta, desde las orientadas a la participación ciudadana hasta las de elección de representantes al Parlamento Europeo. la excusa para no consultar a los ciudadanos del coste de organización se esfumaría, mejorando la Democracia, la transparencia y el buen gobierno. Sin embargo, como todo en esta vida, Blockchain (o mejor dicho, su uso) no está exenta de riesgos, que merecen ser estudiados y sopesados con tranquilidad. Pero no con mucha tranquilidad, o el tren nos volverá a dejar en el andén.

Hay cuestiones menores, casi filosóficas, sobre la ventaja de la desaparición de intermediarios. En realidad, en Blockchain no se "des-intermedia", sino que se "re-intermedia", merced al concepto de confianza distribuida que se consigue mediante los mecanismos de consenso. Y en este tema no hay que caer en errores conceptuales: lo que todos entendemos como consenso no es lo que se entiende como tal en Blockchain. Por ejemplo, en Bitcoin una transacción se valida si seis nodos de la red la validan, aunque la red tenga diez mil nodos. Es un mecanismo a mi juicio excesivamente simple para los enormes requerimientos legales que tiene la Administración. Por ello las reglas que se implementen en la Blockchain para las AAPP deberán ser más estrictas.

Hay otra cuestión típica sobre Blockchain y es la característica de inmutabilidad, que nada puede ser borrado en la cadena de bloques. En mi anterior post yo mismo lo afirmaba, viéndolo como un problema para el Derecho al Olvido. Sin embargo, en una Blockchain privada, desde el punto de vista de que sólo las AAPP tendrían el acceso adecuado, y creada con las reglas que se consensúen, sí podría implementarse un mecanismo de eliminación de información, siempre que ese mecanismo esté totalmente integrado y aceptado en las reglas de la cadena de bloques.

Sin embargo, y pese a sus múltiples ventajas, veo prácticamente imposible que actualmente una iniciativa como una Blockchain de las AAPP tuviese el más mínimo atisbo de ser un proyecto exitoso: desde hace unos años hay un afán recentralizador clarísimo en la Administración Central del Estado, que va en dirección contraria a la filosofía Blockchain. Sin embargo, en otras circunstancias sería una ventaja que desde la AGE se impulsara un proyecto así, y que fuese la AGE quien fuera 'activando' los nodos necesarios de esa Blockchain (en AAPP de tamaño adecuado, como Comunidades Autónomas, Diputaciones y/o Grandes Ayuntamientos) y luego asignara los 'wallet' a cada una de las Administraciones Públicas del país, delegando si es necesario en esas mismas administraciones autonómicas o locales esa tarea.

Finalmente, quiero dejar clara otra cuestión: en una Blockchain pública puede almacenarse y validarse información privada, de forma confidencial. Esto hay mucha gente que no lo entiende, porque sigue pensando en Blockchain como soporte de transacciones económicas. Pero en una transacción en una Blockchain puede almacenarse virtualmente cualquier cosa que se beneficie de las propiedades de trazabilidad, seguridad y transparencia que ofrece la tecnología. Por ejemplo, actas de tribunales de Tesis de Fin de Master ;-)

P.D.: El artículo de Wikipedia en castellano sobre Cadena de Bloques es sencillito, pero clarito.

P.D. 2: Si asistís a alguna conferencia sobre criptomonedas quizá oigáis una afirmación sorprendente: "El dinero se crea de la nada". Y no es broma.

domingo, 22 de abril de 2018

Una pequeña reflexión sobre Blockchain

Tras unos meses de parón, por fin puedo escribir unas líneas en el blog, y en esta ocasión, sobre Blockchain. Esto viene a colación porque cayó en mis manos un libro (sí, un libro, de papel) titulado "La Tecnología Blockchain en los negocios", de William Mougayar, un experto de talla mundial en este tema, y cuyo blog recomiendo a todo aquel interesado en iniciarse en esta cuestión..

La verdad, Blockchain me parece un concepto que va a ser (si no lo es ya) clave en los usos tecnológicos más habituales hoy en día, más allá de ser el soporte para el desarrollo de criptomonedas. Obviamente, no es una tecnología que sirva para todo, pero sí me parece que va a tener una amplia repercusión en la forma en la que se desarrollan determinados sistemas y negocios on line. Podemos ver Blockchain (es común hacerlo así) como un libro mayor contable distribuido, en el que se lleva un registro de las transacciones merced a una red entre pares (P2P).

Desde mi punto de vista, es un compendio de filosofía y tecnología, basado en dos conceptos:

  • Confianza distribuida
  • Consenso

La confianza distribuida va a cambiar negocios como la banca, la fe pública, o las transacciones financieras. En las Administraciones Públicas, una blockchain adecuadamente construida eliminaría la necesidad, por ejemplo, de ciertas Plataformas Centralizadas de uso muy habitual, así como las complejas cuestiones del uso de certificados y firmas digitales para la tramitación electrónica, que se basan en el establecimiento de la identidad de ambos participantes (ciudadano y Administración) por parte de terceras partes de confianza externas (las Autoridades de Certificación). pero, ¿qué pasa si esa confianza puede obtenerse directamente de la blockchain, sin necesidad de terceros? Habrá que repensar, y rápido, el modelo actual de identificación electrónica en la Administración.
 
A nivel tecnológico, en Blockchain se mezclan fuertemente aspectos criptográficos con cuestiones como la teoría de juegos. Sin embargo, y pese a que es obvio que no sirve para todos los casos de uso, detecto que se le avecinan dos cuestiones importantes para su aplicabilidad en muchos ámbitos:

  1. ¿Cómo se puede ejercer el Derecho al Olvido, o los derechos de cancelación de datos personales, si esos datos se distribuyen a través de la blockchain (pública, privada o híbrida)? Recientemente, en GigaTIC18 se trató este tema en una presentación. Deseoso estoy de poder ver el video de la misma.
  2. ¿Cuánto tiempo 'resistirá' una blockchain frente a un computador cuántico? Quizá habría que preguntarles a los expertos de la Quantum World Association. Quizá lo haga, en cuanto tenga un rato.

Seguro que hay más cuestiones por resolver en esta prometedora tecnología, y prometo escribir sobre ello cuando las conozca.

O si consigo respuestas a las dos preguntas planteadas.....

lunes, 6 de noviembre de 2017

Y ahora, .... Antifraude

Desde el 1 de noviembre de 2017 me he incorporado, como Jefe de Servicio de Sistemas de Información, a la Agencia para la Prevención y Lucha contra el Fraude y la Corrupción de la Comunitat Valenciana, una institución adscrita a las Cortes Valencianas.
Es un proyecto ilusionante, tanto desde el punto de vista profesional, como desde un punto de vista social, dada la repercusión que las lacras de la corrupción y el fraude suponen para el sistema democrático.
Como técnico, el reto que asumo es harto interesante por dos motivos:
  • porque me ofrece la oportunidad de planificar y desplegar desde cero toda la infraestructura de servicios y aplicaciones de la Agencia, aplicando marcos de referencia y buenas prácticas como MSP, PRINCE2, COBIT5 e ITIL.
  • porque me permite colaborar con excelentes empleados públicos dedicados a erradicar las malas prácticas en la Administración.
¡Deseenme suerte!

viernes, 22 de septiembre de 2017

Sobre la humedad y el papel: análisis (crítico) de los artículos 15 y 18 del Esquema Nacional de Seguridad

Como se puede observar de los artículos de este blog, no soy precisamente un entusiasta del marco normativo que nos toca sufrir en temas TIC en la Administración Local. No es que no me parezcan bien ciertas Leyes o normas, muchas muy lógicas y loables, sino que centro mis reticencias en su aplicabilidad real en el entorno general actual. Quede claro que no voy a discutir temas legales, sino las cuestiones prácticas que se desprenden de la interpretación de las normas.
En esa ocasión, motivado por una conversación que tuve el otro día con una experta consultora en estos temas y algunos compañeros, al respecto del artículo 15, y sobretodo, del artículo 18 del Esquema Nacional de Seguridad. Parece lógico comenzar este análisis reproduciendo cómo quedan los artículos a los que aludiré tras la aprobación del Real Decreto 951/2015, de 23 de octubre, por el que se modificaba el RD 3/2010, de 8 de enero.

Artículo 15. Profesionalidad.

1. La seguridad de los sistemas estará atendida, revisada y auditada por personal cualificado, dedicado e instruido en todas las fases de su ciclo de vida: instalación, mantenimiento, gestión de incidencias y desmantelamiento.

2. El personal de las Administraciones públicas recibirá la formación específica necesaria para garantizar la seguridad de las tecnologías de la información aplicables a los sistemas y servicios de la Administración.

3. Las Administraciones públicas exigirán, de manera objetiva y no discriminatoria, que las organizaciones que les presten servicios de seguridad cuenten con profesionales cualificados y con unos niveles idóneos de gestión y madurez en los servicios prestados.
[...]
Artículo 18. Adquisición de productos de seguridad y contratación de servicios de seguridad.

1. En la adquisición de productos de seguridad de las tecnologías de la información y comunicaciones que vayan a ser empleados por las Administraciones públicas se utilizarán, de forma proporcionada a la categoría del sistema y nivel de seguridad determinados, aquellos que tengan certificada la funcionalidad de seguridad relacionada con el objeto de su adquisición, salvo en aquellos casos en que las exigencias de proporcionalidad en cuanto a los riesgos asumidos no lo justifiquen a juicio del responsable de Seguridad.

2. La certificación indicada en el apartado anterior deberá estar de acuerdo con las normas y estándares de mayor reconocimiento internacional, en el ámbito de la seguridad funcional.

3. El Organismo de Certificación del Esquema Nacional de Evaluación y Certificación de Seguridad de las Tecnologías de la Información, constituido al amparo de lo dispuesto en el artículo 2.2.c) del Real Decreto 421/2004, de 12 de marzo, y regulado por la orden PRE/2740/2007, de 19 de septiembre, dentro de sus competencias, determinará el criterio a cumplir en función del uso previsto del producto a que se refiera, en relación con el nivel de evaluación, otras certificaciones de seguridad adicionales que se requieran normativamente, así como, excepcionalmente, en los casos en que no existan productos certificados. El proceso indicado, se efectuará teniendo en cuenta los criterios y metodologías de evaluación, determinados por las normas internacionales que recoge la orden ministerial citada.

4. Para la contratación de servicios de seguridad se estará a lo dispuesto en los apartados anteriores y en el artículo 15.

Pues bien, comencemos la disección. Al artículo 15 le encuentro las siguientes 'debilidades':

  1. Sobre la 'cualificación' del personal que debe atender a la seguridad de los sistemas: si bien es cierto que el CCN organiza desde hace años los cursos STIC para formar al personal de las AAPP en el despliegue y gestión de infraestructuras y programas de forma segura, así como en la propia gestión de la seguridad de la información. ésta es una formación a todas luces insuficiente, por dos motivos: su fase presencial se realiza sólo en Madrid, y el número de plazas anuales es muy reducido. Por tanto, esta formación llega a pocos afortunados. Existen otras opciones, como la cualificación en base a certificaciones 'privadas', tales como másteres en ciberseguridad o certificaciones internacionales como las de oganizaciones como ISACA, por ejemplo, pero cuyos costes son elevados para que una gran parte de las AALL consideren gastarse ese dinero en su personal TIC (si lo tienen). Y obviamente, aún es más complicado que sea el propio personal TIC quien asuma esos costes de formación y certificación. Por tanto, pese al voluntarismo, la cuestión de la cualificación profesional del personal al servicio de la mayoría de AAPP, sobretodo en las AALL, es PAPEL MOJADO.
  2. Respecto de las organizaciones que prestan servicios de seguridad, ocurre algo radicalmente diferente: las empresas proveedoras de estos servicios sí exigen a sus empleados disponer de determinadas certificaciones o conocimientos con caracter previo a su contratación, o reciclan a personal preexistente para obtenerlas, de cara a poder presentar un elenco de profesionales adecuado para optar a los contratos que surjan de las AAPP o del sector empresarial. Pero el ENS se queda corto al no fijar cuáles de esas certificaciones o titulaciones son las que se consideran adecuadas para garantizar que un profesional es adecuado y que el servicio que se va a prestar tiene el nivel de madurez pertinente. Posiblemente se deja al libre albedrío de cada Administración el exigir determinadas certificaciones a las empresas licitantes (de las ISO series 14000 y 27000, por ejemplo) y/o a los profesionales que van a ejecutar de forma efectiva el servicio (ISACA CISA, CISM o CISS, por ejemplo). Pero ello exige que la AAPP conozca qué le aporta cada una de estas certificaciones, lo cual tampoco es demasiado habitual. Por tanto, esta cuestión del ENS es PAPEL CERCANO A MOJARSE.

Analicemos ahora el artículo 18, que se presenta mucho más chispeante al meterse de lleno en el tema de la certificación de sistemas, ya que para los servicios se remite al artículo 15:

  1. Este artículo es claramente un brindis al Sol. Con buenas intenciones, con referencias a estándares o normas internacionales reconocidas (como los Common Criteria), pero que no puede ser aplicado. En un entorno estático se puede pensar en certificar sistemas, porque van a durar muchos años. Por ejemplo, en entornos industriales o críticos conviene que los sistemas se certifiquen. Se pueden certificar servicios de emisión de certificados digitales, o software embebido en sistemas militares. Pero, ¿qué ocurre realmente en el mercado tecnológico habitual, al que no son ajenas las AAPP? Pues que va a toda velocidad. No me voy a referir al software. Pero ¿el hardware no se actualiza? Si. Pero la certificación se habrá obtenido por un hardware para una versión de firmware (o se sistema operativo) concreta, por lo que tras cada revisión de éste habría que recertificar. ¿Y eso quien lo asume? Nadie. Por tanto, la certificación de sistemas, por este motivo es PAPEL MOJADO. Puede consultarse una lista actualizada de productos certificados según los Common Criteria en este enlace.
  2. Suponiendo que no hubiera que recertificar tras cada actualización (lo cual no tendría sentido), la lista oficial de sistemas certificados llevaría un retraso considerable respecto al mercado, por lo que las AAPP estarían adquiriendo productos prácticamente obsoletos, ya que al retraso por la certificación habría que añadirle el retraso por el proceso de contratación pública. Por este motivo, también es PAPEL MOJADO.
  3. La obligatoriedad de adquirir sistemas certificados queda supeditada a la "proporcionalidad en cuanto a los riesgos asumidos", a juicio del Responsable de Seguridad. Obviamente, había que dejar una escapatoria a las AAPP para poder funcionar. Ello simplemente resulta en que hay que justificar que, o bien no hay equipos certificados que tengan las funcionalidades que se requieren en la AAPP concreta, o bien el Responsable de Seguridad informa de que no hace falta que lo estén. Ya sabemos que el papel es muy sufrido. Y en este caso, además, es PAPEL MOJADO.
  4. La certificación de productos sólo pueden realizarla empresas de tamaño considerable, por motivos económicos. Ello deja fuera de esa posibilidad, por ejemplo, a proyectos de software libre, en general, algunos tan importantes como OSSIM en temas de seguridad informática. ¿Restricción de la competencia? ESTE PAPEL LO MOJO YO.

En resumen, nos encontramos ante dos artículos de un Real Decreto que son (casi) imposibles de aplicar, y que el legislador podría directamente habérselos ahorrado. Abundaré en la percepción general de que este RD se creó pensando en la AGE y en las CCAA, no en las AALL que son la mayoría.
En mi modesta opinión, lo único aprovechable de ambos son los puntos 1 y 2 del artículo 15, si no fuera porque con el apartado 3 tiene un tufillo privatizador importante, ya que continuamos sin poder contratar personal ampliando plantilla en las AALL.
Es obvio que hace falta un PLAN MASIVO DE FORMACIÓN en temas de seguridad para el personal TIC de las AAPP españolas. Por ejemplo, con ediciones de los cursos STIC en todas las provincias, con varias ediciones anuales proporcionalmente al número de empleados públicos TIC de cada una de ellas. O con subvenciones para que las AALL formen a esos empleados en la materia a través de centros de formación previamente certificados para ello.
Porque si no, el ENS responde al conocido dicho de 'Mucho ruido y pocas nueces', y los derechos de los ciudadanos y las actuaciones de las AAPP corren peligro si la seguridad de la información en el ámbito de la Administración (Electrónica, hubiéramos dicho antes de las Leyes 39/2015 y 40/2015) no tiene el nivel adecuado.
Lo dicho: PAPEL MOJADO.

sábado, 9 de septiembre de 2017

Una reflexión rápida sobre el ENS y la Administración Local

El pasado viernes, 8 de septiembre, acudí a la primera sesión de un curso que la Diputación de Valencia organizaba sobre la Aplicación Práctica del Esquema Nacional de Seguridad, dirigido a personal TIC de las Administraciones Locales de la provincia. El interés de la materia se detecta fácilmente sabiendo que sólo había 20 plazas y hubo más de 250 solicitudes para asistir al curso, y no sólo de personal TIC, sino de Habilitados Nacionales y otros perfiles.
El curso, a cargo de profesionales altamente experimentados en la materia de una consultora, y pese al interés y el buen hacer de los mismos, por su contenido es un pelín árido, y, sobretodo, sirve para demostrarnos a todos lo mal que nos encontramos en esta materia a menos de dos meses de su entrada en vigor completa.
Si algo quedó claro para todos, asistentes y docentes, es que el ENS no es una normativa que tuviese en cuenta a la Administración Local, que es la que representa a la inmensa mayoría de las Administraciones afectadas por el mismo. Está claramente pensado para las Administraciones Central y Autonómica (ni siquiera tengo claro que pensaran en las Diputaciones). EL CCN-CERT ha tenido desde el primer día el interés, y ha realizado el esfuerzo, en aclarar muchos de los aspectos del Decreto 3/2010 por el que se aprobó el ENS (y de su modificación de Octubre de 2015) en forma de guías de la Serie 800. Sin embargo, nadie se ha molestado en hacer un downgrade de esa norma para facilitar su aplicación en las Administraciones Locales, básicamente, en los Ayuntamientos. ¿Cómo definir los diferentes roles obligatorios del ENS en un Ayuntamiento con sólo un técnico TIC? ¿Qué papel han de jugar aquí las Diputaciones (por cierto, lo mismo ocurrirá en breve con la figura del DPO obligatoria según el GDPR)? ¿Cómo conseguir los fondos para la realización de los Planes de Adaptacion? ¿Y cómo conseguir personal para mantener actualizado el nivel de cumplimiento y entrar en el ciclo de mejora continua de la seguridad, dado el marco legal actual? Lo dije en 2015: este es un plomo más en el fondo del bote de las AA.LL. destinado a facilitar su hundimiento.

Por esa razón, desde ATIAL creamos un grupo de trabajo sobre esta materia, con el objetivo de ayudar a nuestros asociados a definir claramente la hoja de ruta a seguir para implantar el ENS, y apoyarles en la realización de la misma en la medida de las posibilidades de nuestra Asociación. Espero que los resultados sean de utilidad para nuestra comunidad...

¡Horror! Hace ya más de un año ...

Veo con horror que hace ya más de un año que publiqué la última entrada de este blog (julio de 2016). ¡Vaya tela!
En este tiempo, y siguiendo la temática del último post, hemos terminado la segunda temporada del programa de radio Tecnología y Sentido Común, temporada movidita, ya que cambiamos de emisora y comenzamos a emitir desde el hotel The Westin Valencia para CV Radio.
Iniciada el pasado 3 de septiembre de 2017 la tercera temporada, en esta ocasión emitiremos en la frecuencia local de Capital Radio en la Comunidad Valenciana.
Deseo que esta tercera temporada tenga la misma o mejor aceptación que las dos anteriores, y que me resulte tan enriquecedora, a nivel humano, como aquellas.
También durante este año he finalizado la serie de artículos para la web de ATIAL, con las dos últimas entregas en Abril y Agosto de 2017, con las que dí por cerrada la misma.
Espero mejorar la dedicación al blog, sobretodo, ahora que se acercan varios deadlines importante para el personal TIC de la Administración, como son:

  • el 2 de octubre de 2017, porque entran en vigor ciertos aspectos de las Leyes 39/2015 y 40/2015
  • el 5 de noviembre de 2017, porque finaliza el plazo de 24 meses establecido para adaptar los sistemas de las AA.PP. a lo exigido por las modificaciones del ENS aprobadas en octubre de 2015 
  • el 25 de mayo de 2018, porque entra en vigor plenamente el GDPR (y se espera que antes se apruebe la nueva LOPD)
  • y el 2 de octubre de 2018, donde serán plenamente vigentes las Leyes 39/2015 y 40/2015

Como ya dije anteriormente, en el marco legal actual se avecina un auténtico desastre para la Administración Local, o mejor dicho, para la mayor parte de ella.

lunes, 1 de agosto de 2016

Final de temporada

Anoche, 31 de julio de 2016, finalizó la primera temporada del programa de radio "Tecnología y Sentido Común" (@tysentidocomun), que se emite a través de Gestiona Radio Valencia, y en el que he colaborado como tertuliano en esta su andadura inicial.

En el programa de ayer contamos con el Director General de TIC de la Generalitat Valenciana, D. Vicente Aguiló (@Aguilo_DGTI), y, a modo de resumen de la temporada, con los presidentes o vicepresidentes de algunas de las entidades y asociaciones que han aprovechado nuestra sección "Sin Ánimo de Lucro" para dar a conocer sus actividades.

Mi resumen personal de la experiencia no puede ser más positivo. Gracias a mi participación en el programa, he conocido aspectos de la sociedad que me eran totalmente ajenos, como las start-ups o el ecosistema emprendedor; he aprendido importantes lecciones de auténticos expertos en sus respectivas materias, como la seguridad, la protección de datos o la privacidad; y, sobretodo, he compartido ese tiempo de los domingos por la noche con ese tipo de personas que merece la pena conocer en la vida. Anoche, muchos de los intervinientes en el programa nos felicitaban por la iniciativa, por cubrir un hueco necesario y habernos convertido en un referente del sector. Estoy totalmente convencido que esto ha sido así, en su mayor parte, por la categoría humana y profesional de los directores del programa, Javier Peris (@javierperis) y Jesús López Pelaz (@jlpelaz), y del resto del equipo (actual y pasado), Juan Carlos Muria (@juancarlosmt), Juanfran Barberá (@jfran76), Ricard Martínez (@ricardmm) y Teresa Domenech (@teredomenech), así como de colaboradores habituales como Marlon Molina (@marlonmolina) o Luis Morán (@luismoran2014).

Gracias a todos por permitirme participar con vosotros de esta aventura y soportar mis tonterías. ¡Nos oímos en septiembre!