domingo, 19 de enero de 2020

Reflexiones en torno al impacto de Blockchain y de la computación cuántica sobre los sistemas de certificación y firma electrónica

El Aperitivo

A estas alturas del partido, cualquiera que haya tenido el más mínimo contacto con los servicios de la Administración Electrónica española conoce la existencia de los certificados digitales. Cuando una persona quiere acceder a los servicios de la sede electrónica de una Administración Pública, es muy probable que lo haga con un certificado digital. Obviamente, hay más formas de identificar al usuario de la sede, como el sistema CL@VE, o los clásicos pares de usuario+contraseña. También la propia sede electrónica se identifica con un certificado digital, conocido en el mundillo como Certificado de Sede Electrónica, aunque en este caso, como ocurre con el certificado SSL de cualquier web, también se usa para asegurar las comunicaciones entre el cliente y el servicio al que conecta.

Otro uso habitual y muy conocido de los certificados digitales es la firma digital. Mediante un proceso de firma digital, y si se cumplen las condiciones técnicas y legales oportunas, se consigue identificar al firmante, asegurar la integridad de los datos firmados, y conseguir la característica de No Repudio de los documentos firmados digitalmente. Esta característica, en síntesis, sirve para que no pueda discutirse legalmente que quien firmó el documento no sea la persona a quien identifica el certificado con el que se firmó. Es decir, la firma digital permite obtener, respecto de un documento electrónico, 'las mismas' garantías que tenía un documento en papel con una firma manuscrita. Y digo 'las mismas', entre comillas, porque en realidad aporta más cosas. Una firma manuscrita se puede falsificar. Una firma manuscrita se puede discutir en el Juzgado, aduciendo que es falsa, para lo que haría falta un tercero de confianza (un perito grafólogo) para dilucidar esa situación. La fecha y hora de la firma manuscrita puede ser diferente de las indicadas en el propio documento, por lo que pueden hacerse firmas atrasadas o adelantadas en el tiempo, a conveniencia. En principio, una firma digital protege de estas situaciones en el plano electrónico de nuestra realidad.

Los sistemas de certificación digital, basados en conceptos como el cifrado asimétrico, los terceros de confianza, las autoridades de certificación, las infraestructuras de clave pública (PKI), etc, sirvieron de base para la arquitectura legislativa y técnica, desde finales del pasado milenio, para el diseño y despliegue de los servicios de la Administración Electrónica en España. Sin embargo, en los últimos años han aparecido (al menos) dos tecnologías cuyo impacto sobre la arquitectura mencionada aún está por ver: los sistemas basados en cadenas de bloques o Blockchain, y los sistemas de computación cuántica.

Blockchain: positivo, pero....

Sobre el primer concepto ya he escrito en este blog. Es un tema mainstream, que parece que vende confianza per se. Por el simple hecho de decir que un sistema está basado, o guarda sus datos en una Blockchain, parece que se esté vendiendo una seguridad del más alto nivel posible. Me reservo mi opinión, de momento, sobre el uso del concepto como gancho de marketing, porque creo que merece más la pena dedicar el espacio de este post a comentar cómo creo que puede impactar la implantación de sistemas Blockchain en los Sistemas de Administración Electrónica en España.
En primer lugar, hay que destacar que, sobre el papel, los sistemas Blockchain, también conocidos como Distributed Legder Technology (o de Libro Mayor Distribuído) presentan ventajas en lo que a confianza distribuída se refiere, es decir, que un hecho sea afirmado por diferentes participantes hace que 'sea cierto' para el sistema. Por ello, en la evolución de estas tecnologías siempre se ha manejado el concepto del consenso entre nodos de la cadena de bloques para hacer referencia al momento en que una mayoría de ellos contienen una determinada información (generalmente una transacción o bloque de ellas), creada y firmada digitalmente según las reglas del protocolo que rige esa cadena de bloques. Los entusiastas de los sistemas DLT afirman que estos mecanismos pueden eliminar la necesidad de que existan terceros de confianza centralizada, tales como notarios, registros de la propiedad, etc, ya que si esa información se soporta sobre una cadena de bloques, los participantes en la misma confían en la información en ella almacenada por la forma en que se han generado, almacenado, firmado y distribuído las transacciones. Maravilloso.
Sin embargo, el factor critico de diseño de una implantación basada en Blockchain es el número de nodos. Si un agente es capaz de controlar la mitad más uno de los nodos participantes, lo que se conoce como 'ataque del 51%', es capaz de manipular 'la verdad' de la cadena de bloques, ya que sus nodos pueden dar por buenas las transacciones que ese agente realice, y rechazar las que provengan de otros participantes. Si la Blockchain es pública, es cuestión de crear nodos artificialmente, aunque es costoso, para tomar control de la misma. Por eso, las organizaciones abogan por disponer de Blockchains privadas, donde sólo hay determinados agentes que han desplegado nodos, gracias a una distribución limitada del software y de los protocolos de la misma, y que a su vez distribuyen el software cliente para operar con la cadena de bloques. La seguridad de que nadie puede generar un ataque del 51% en estas infraestructuras parece merecer la pena, pero, de nuevo, si un agente malicioso consiguiera comprometer un determinado número de nodos, o pudiese desplegar nodos adicionales tras acceder al código fuente, etc., el reducido número de nodos de la cadena de bloques privada haría que ésta también cayera bajo el control del agente malicioso con facilidad.
Hemos citado el hecho de que las transacciones o los bloques se firman digitalmente, pero no hemos indicado que los clientes de la cadena se identifican a su vez mediante certificados digitales. Por tanto, las infraestructuras DLT se basan ampliamente en las infraestructuras de PKI, lo cual, desde mi punto de vista, les aporta determinadas propiedades de la seguridad, como la trazabilidad y la autenticidad, pero las deja a merced de los mismos problemas que a aquellas:

  • aún hay algoritmos de cifrado de certificados débiles o ya comprometidos
  • la Autoridad de Certificación que los emite, al ser única y centralizada, puede ser comprometida por parte de un agente malicioso

Para solucionar estos problemas, dejo una pregunta en el aire: ¿sería posible crear una Autoridad de Certificación Distribuída, sobre una Blockchain, cuyos certificados digitales dispusieran de un tipo de cifrado más robusto?

Sin embargo, y dejando de lado la problemática mencionada, ¿puede un sistema Blockchain, o un conjunto de ellos, sustituir a la necesidad de que en los sistemas de Administración Electrónica se requieran firmas electrónicas por parte de los ciudadanos o de la propia Administración. Muy probablemente, para el ciudadano, sea necesario aún durante bastante tiempo el uso de este mecanismo de autentificación de la manifestación de la manifestación de su voluntad frente a determinados actos con relevancia jurídica. Sin embargo, hay sistemas internos de las propias Administraciones españolas, disponibles a través de la Plataforma de Intermediación de Datos, o de otros colectivos, como los Notarios, o los Colegios Profesionales en profesiones reguladas, que podrían ser reemplazados por un sistema de confianza distribuida basado en Blockchain, con grandes ventajas tanto para los ciudadanos como para otras AA.PP. Y se me ocurren varios ejemplos:

  • la consulta de títulos universitarios, si las universidades mantuvieran un registro compartido y distribuído de los títulos que emiten y de los expedientes asociados.
  • el Registro de la Propiedad, lo que eliminaría la necesidad de la figura del Registrador de la Propiedad, y de los costes asociados a sus tareas
  • las revisiones ITV de un vehículo, que evitaría problemas en la adquisición de vehículos entre particulares
  • etc...
En definitiva, nuevos servicios, o nuevas formas de prestarlos, a una fracción de los costes actuales.

Computación Cuántica: riesgo a corto, oportunidad a largo

En un artículo relativamente reciente, el New York Times afirmaba que "Para China y Estados Unidos (la computación cuántica) es un asunto de seguridad nacional". Es, sin lugar a dudas, la próxima frontera en materia tecnológica, una frontera que unos pocos elegidos, como IBM o Google, ya están cruzando. Operaciones que tardarían años ejecutándose en un computador digital como los actuales, pueden tardar segundos en realizarse en un computador cuántico. No es mi intención entrar a explicar en qué consiste esta tecnología, ni los retos que aún afronta, ni las grandes ventajas que puede tener para la investigación o el desarrollo tecnológico futuro. Si está Ud. interesado, en este vídeo está bastante bien explicado.
Por lo que respecta al tema que nos ocupa, está claro que la computación cuántica sería capaz de romper en poco tiempo el cifrado de la mayoría de los certificados digitales actuales. Durante las jornadas RootedCon Valencia 2019, tuve la oportunidad de preguntar esta cuestión a uno de los grandes expertos en criptografía de España, el Dr. Alfonso Muñoz, investigador de BBVA Next Technologies y fundador de CriptoCert. Su respuesta, a grandes rasgos, dibujaba la necesidad de implantar criptografía post-cuántica. Evidentemente, este tipo de mecanismos de cifrado se implanta(rá) primero en sistemas críticos, top secret, y es muy probable que tanto la tecnología como los algoritmos se definan como secretos de Estado y no puedan ser utilizados masivamente como ha ocurrido con los sistemas PKI. Aunque no siempre ha sido así, ya que hasta finales del milenio pasado estaba prohibido exportar los sistemas de criptografía fuera de los EE.UU., algo que puede chocar en la actualidad, pero que no sería raro que volviésemos a ver en el caso de la criptografía post-cuántica.
Pero, independientemente de cómo podemos intentar proteger los sistemas de firma digital para el futuro, ¿qué efectos tendría que un computador fuera capaz de romper los actuales sistemas de certificación digital en un tiempo razonable? Por ejemplo, ser capaz de descifrar el tráfico SSL en tiempo real entre los dos extremos de esa comunicación pondría en riesgo varias de las propiedades de la seguridad para los datos que se estén comunicando:
  • Confidencialidad, al poder ver la conversación un agente que no forma parte de la misma
  • Integridad, al poder modificar los datos en tránsito
  • Autenticidad, al poder hacerse pasar por cualquiera de los intervinientes en la conversación
  • Trazabilidad, al no quedar constancia de la intervención de la comunicación
 Otro ejemplo, el de la firma digital de documentos. Poder descifrar los metadatos cifrados del documento, los que contienen los datos de la firma, permitirían poder poner en circulación un documento modificado, tanto en su contenido, como en esos metadatos de firma. Pienso en una Administración Pública totalmente digitalizada, en la que un agente malicioso que dispusiera de esa capacidad, podría poner en circulación, por ejemplo, títulos universitarios falsos en formato digital autocontenido (como un PDF firmado), cuya firma digital parecería legítima, pero que se habría elaborado ad hoc para el falseamiento del documento oficial. ¡Una auténtica pesadilla!
Por todo lo dicho, es fácil considerar a la computación cuántica una amenaza para la Administración Electrónica tal y como está conceptuada en la actualidad. Pero tal vez debamos enfocarlo como una oportunidad para mejorar antes de que dicha amenaza se materialice. ¿Tal vez una combinación de Blockchain y cifrado post-cuántico en el menú futuro de la tecnología al servicio de las Administraciones Públicas?




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.