Incidente de Comodo, reflexiones sobre el uso de Entidades de Certificación.

Esta semana hemos tenido otro incidente de seguridad vinculado al prestador de servicios de certificación COMODO preocupante y que apunta hacia una posible futura tendencia que podrá seguir explotándose por parte del crimenware. La noticia técnica de lo ocurrido está muy detallada en las dos noticias Una-al-día de los días 24 y 25 de este mes.

Mi reflexión se orienta más hacia la perspectiva de la "gestión de la seguridad" y la necesidad de proteger todos los eslabones de la cadena. Para ello, con carácter previo, creo conveniente explicar la lógica de la protección en la que se basan las Infraestructuras de clave pública (PKI). Tal como se expresa en Wikipedia, una infraestructura de clave publica (o, en inglés, PKI, Public Key Infrastructure) es una combinación de hardware y software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transacciones electrónicas.

Por tanto, la robustez y seguridad del uso de estas tecnologías no se basan tan solo en la potencia o fiabilidad del hardware o software utilizado sino en la buena gestión operativa de los procedimientos de seguridad usados por el propio personal de la PKI más los procesos internos establecidos por las prácticas de certificación (CPS). En este caso, los procesos son tanto o más importantes que la tecnología. La siguiente figura ilustra las piezas de una PKI y su funcionamiento como mecanismo de generación de confianza. De hecho, parece que el problema de seguridad del incidente con la PKI Comodo se debe a una violación de las propias prácticas de certificación tal como explican en el blog Securitymusings.com. Comodo ha reconocido que el usuario y contraseña de una Entidad de registro había sido comprometido pero en sus propias prácticas de certificación se indica que el acceso se realiza mediante métodos de autenticación fuerte. Es decir, en casa de herrero cuchillo de palo. De nuevo otro ejemplo más de que el factor humano es habitualmente el punto de fallo más habitual. La tecnología es fiable pero cuando es mal utilizada por personas es cuando vienen los problemas.

Toda PKI siempre tiene las siguientes piezas operativas dando servicio:

Pensando en la propia seguridad del funcionamiento de una PKI hay varios "talones de Aquiles" que deben ser muy bien protegidos y controlados para garantizar la fiabilidad del proceso que serían los siguientes puntos:

• Certificado Raiz, dado que es el elemento que otorga confianza al resto de certificados al ser usado para firmar certificados generados con dicha entidad de confianza, es el corazón del sistema de confianza que se monta con una PKI.
• Autoridades de registro porque son los ojos y los verificadores reales de toda la información que posteriormente va a firmar la Autoridad de certificación. Habitualmente es el punto de control donde se coteja la información que acredita o autentica al Organismo o persona respecto de los datos que figurarán en el certificado digital que firmará la autoridad raíz. Por tanto, si esta pieza falla, se pueden generar certificados digitales que siendo validos, no se correspondan con datos veraces.
• Las CRL o Autoridades de Validación porque son el punto de chequeo en tiempo real de la validez o no de la información que se presenta en un certificado digital. Se supone que una de las importantes ventajas de las tecnologías PKI es que permiten en tiempo real las comprobaciones de veracidad de la información.

Sin embargo, el despliegue de estas tecnologías en la vida real ha ido mal acostumbrándonos a diferentes incidencias que son cotidianas y que ponen en riesgo la fiabilidad de las soluciones basadas en el uso de estas tecnologías PKI. Estos fallos de implantación serían los siguientes:

• Entidades de certificación "Juan Palomo" que ya fue objeto de un post en la entrada "Prestadores de servicios de certificación "Juan Palomo". El funcionamiento de las Entidades de certificación está avalado por la Ley 59/2003 de Firma Electrónica que establece desde el punto de vista legal quienes pueden ser "entidades de prestación de este tipo de servicios" y determinan ciertas condiciones a este tipo de Organismos que van a "generar confianza" para garantizar su fiabilidad. No se prohibe a nadie que lo sea pero "SI" se regula que deben como mínimo tener para poder dar estos servicios. Sin embargo, ha sido frecuente la instalación y uso de certificados "raíz" en sitios Web (para ahorrarse unos euros) que no están avaladas por nadie y que no aparecen dentro del conjunto de "Entidades Raiz" que por defecto vienen en los navegadores preinstalados. Algunos de estos casos también los documenté en su momento en los post "La e-Administración dando mal ejemplo aunque por suerte casi todos los casos ya se han ido solucionando (pero en su momento se podía acreditar que no era así como aparece en las capturas de pantalla del momento). La lista de prestadores autorizados figura en el Ministerio de Industria, Comercio y Consumo. Para los que en este momento se vean sorprendidos por esta afirmación, pueden acudir a la Web del Ministrrio y comprobar cómo la Ley 59/2003, de 19 de diciembre, de firma electrónica establece en su artículo 30, y disposición transitoria segunda, que los prestadores de servicios de certificación deberán comunicar al Ministerio de Industria, Turismo y Comercio, sus datos de identificación, los datos que permitan establecer comunicación con el prestador, los datos de atención al público, las características de los servicios que vayan a prestar, las certificaciones obtenidas para sus servicios y las certificaciones de los dispositivos que utilicen. Esta lista puede ser consultada en esta dirección.
• No verificación de la validez del certificado. Este es quizás el error más común y principalmente debido al modelo de negocio montado por la FNMT que en su momento, cuando todos los navegadores no hacían las comprobaciones pertinentes respecto a la validez del certificado pasaba completamente desapercibido pero que actualmente es origen de error en el acceso en casi todos los navegadores, obligando al usuario a generar una excepción. La esencia del buen funcionamiento de una PKI se basa en esa comprobación en tiempo real de la corrección del certificado. De hecho, estos mecanismos inicialmente se basaban en listas de certificados revocados que había que descargar y actualmente se implementan mediante el protocolo OCSP de verificación en tiempo real. Sin embargo, no todos los prestadores permiten el acceso a sus servidores OCSP (La FNMT no por ejemplo) y creo que cargarse eso es cargarse la mitad de los beneficios que aporta este mecanismo de seguridad y pone en riesgo la fiabilidad de estos sistemas.

El incidente de Comodo ha supuesto el compromiso de una entidad de registro que ha permitido generar certificados falsos. Si las comprobaciones de la validez se hicieran por defecto y en tiempo real, el problema se limitaría a detectar el incidente y revocar los certificados. Ya serían los navegadores los encargados de no ser engañados por esos certificados falsos una vez son éstos anulados. Sin embargo, las configuraciones por defecto de las versiones antiguas de los navegadores (los nuevos Firefox 4 e Internet Explorer 9, cuentan con OCSP activo por defecto).

De todo esto hay dos lecciones que debieran aprenderse:

• Las autoridades de registro tienen una responsabilidad altísima en el buen funcionamiento de la PKI y por tanto, debe tratarse como un punto crítico de la infraestructura. Su personal debe estar adecuadamente entrenado y debieran desplegarse las mínimas necesarias para dar un buen servicio dado que el compromiso de una de estas autoridades puede poner en peligro toda la infraestructura (Si llegado el caso no puede saberse cuales son certificados originales y cuales falsificados). Sin embargo, por lo que he podido vivir personalmente, no parece dársele la importancia que tienen por parte de las Prácticas de Certificación de muchos prestadores, cosa que no ocurre con el DNI-e que obliga a que las autoridades de registro estén en comisarías.
• Los mecanismos de validación en tiempo real deben estar accesibles y configurados por defecto para que sean utilizados. Es la manera de reducir la "ventana de exposición" una vez que hay problemas con los certificados y por tanto, cuanto más se trabaje en tiempo real menos serán los posibles agujeros a explotar. Pensar que estas entidades son también empleadas para verificar que los certificados no están caducados y que su no uso hace que tanto certificados revocados como caducados puedan seguir siendo usados (aunque originalmente no son ya legítimos).

Lo que ya es más preocupante es lo que apunta Chema Alonso en su post OCSP, el update de Windows Raúl y el ataque de Roberto Carlos pero eso supone un vector de ataque diferente que ya trataré otro día.

¿Fallo la seguridad en Fukushima? Un desgraciado ejemplo de "cisne negro".

"Cuando el carro se haya roto, muchos nos dirán por dónde no se debía pasar.
Proverbio turco"

Este proverbio puede ser el eje principal de las reflexiones que quiero compartir en relación al incidente de Fukushima. Parto de la base de que la secuencia de hechos en la que me voy a basar para valorar lo sucedido tiene como fuente lo publicado por Foro Nuclear y sus explicaciones. En concreto por la secuencia que relata este apartado:

¿Qué ha ocurrido en la unidad 1 de la central nuclear de Fukushima - Daiichi?

1. - La central paró inmediatamente cuando tuvo lugar el terremoto. Los sistemas eléctricos automáticos de emergencia funcionaron adecuadamente.
2. - Se perdió toda alimentación eléctrica exterior a la central.
3. - Los generadores diésel empezaron a proporcionar electricidad de respaldo para el sistema de refrigeración de emergencia de la central.
4. - Los generadores diésel de emergencia dejaron de funcionar aproximadamente 1 hora después debido a los daños producidos por el tsunami, por la falta de suministro de combustible.
5. - Se utilizó el condensado de aislamiento para extraer el calor residual del reactor.
6. - Aparentemente la central sufrió, después, una pequeña pérdida de refrigerante en el reactor.
7. - Se utilizaron las bombas del Sistema de Refrigeración de Aislamiento del Núcleo del Reactor (RCIC), que funcionan con vapor procedente del reactor para completar el inventario de agua del núcleo del reactor; sin embargo, las válvulas de control alimentadas por baterías perdieron la alimentación eléctrica en corriente continua después de un uso prolongado.
8. - En ese momento la central sufrió una pérdida total de suministro eléctrico.
9. - Después de varias horas con pérdida del inventario de agua del circuito primario, se produjo daño al del núcleo del reactor (por fallo de vainas de combustible).
10. - Se enviaron generadores diésel portátiles a la central y se restableció el suministro eléctrico en corriente alterna, lo que permitió que un sistema de bombeo de emergencia pudiera completar el inventario de agua dentro de la vasija del reactor.
11. - Se incrementó la presión en el pozo seco de contención por la subida de temperatura en el pozo húmedo. La contención del pozo seco se venteó hacia el edificio de la contención secundaria.
12. - El hidrógeno que se produjo por la oxidación del circonio se venteó desde la contención primaria hacia el edificio del reactor.
13. - Se produjo una explosión de hidrógeno en el edificio del reactor produciendo el hundimiento del techo y las paredes.
14. - La contención primaria y la vasija del reactor se han mantenido intactas.
15. - Se tomó la decisión de inyectar agua del mar y ácido bórico dentro de la vasija del reactor para continuar con el proceso de refrigeración, como medida adicional prevista en la central desde el inicio.
16. - Las emisiones controladas de radiación se produjeron por el venteo y posteriormente fueron disminuyendo. Esta misma secuencia de hechos parece que se ha producido en la unidad 3.

Por lo que aquí se cuenta parece que las medidas de seguridad funcionaron bien e incluso las medidas de respaldo también en un primer momento. Quizás los problemas han venido ocasionados porque las medidas han ido siendo superadas por las circunstancias para las que fueron implantadas.

Cuando toca establecer qué medidas de seguridad se van a implantar, lo habitual es hacer un análisis de riesgos y plantear qué vamos a proteger y para qué escenarios de contingencia. Por tanto, hay un diseño que establece unas decisiones respecto a riesgos aceptados y no aceptados. Las medidas deben solventar todo aquello que se decide gestionar. Sin embargo, cuando los problemas son ocasionados por ese tramo de los riesgos que decides no gestionar o decides no tratar, ¿Falla la seguridad o falla "el diseño de la seguridad? Porque creo que no es lo mismo aunque los resultados son igual de catastróficos.

Es también adecuado leer el artículo "Las diez preguntas que todo el mundo se hace sobre la crisis nuclear en Fukushima". En concreto me quedo con lo dicho en la pregunta 4:

 4. ¿Por qué se construyó una central junto al mar en una zona de riesgo de tsumanis? Algunas primeras fuentes nos indicaban que las centrales nucleares necesitan la presencia abundante de agua y Japón tiene pocos ríos y no muy caudalosos. Esta versión, nos indica Ortego, no tiene sentido puesto que se pueden construir torres de refrigeración, si bien son más caras. Siendo "tsunami" una palabra japonesa, ¿por qué no se previó una circunstancia así? En opinión de Ortego, el problema es que este tsunami ha desbordado todas las previsiones. De hecho, los reactores estaban en una cota alta, preparados para una ola de seis metros, pero no de diez. "El tsunami también ha arrasado ciudades", explica Gallego, "la pregunta también sería entonces si es prudente vivir al lado del mar". Sin embargo los expertos sí creen que habría que reevaluar los parámetros de diseño para este tipo de centrales junto al mar.

Y la frase que creo es la clave "El ingeniero nuclear Eduardo Gallego entiende esa sensación que se ha extendido entre la opinión pública de que hubo imprevisión, pero insiste en que la clave está en el nivel de este terremoto. "Para eso no se diseña", asegura, "nunca se diseña para lo imposible". "Si diseñásemos para un terremoto nivel 10 sería todo tan caro y tan imposible que no se podría construir", explica. "Hay que definir que nivel de seguridad queremos".

De nuevo son aplicables  parte de las reflexiones que ya traté con el derrame de BP en el Golfo de México. Quizás el hecho de dejar rastro en cada catástrofes es un síntoma claro de que no aprendemos de los errores aunque Fukushima más que un problema de seguridad ha sido un problema de subestimación en el diseño de la seguridad. En este caso, quizás la principal lección a aprender es que cuando se trata de recursos tan críticos o peligrosos, los sistemas de respaldo y backup a su vez deben tener un plan de continuidad para evitar posibles fallos dado que estos sistemas son a su vez críticos para la recuperación o la contención del incidente. Es decir, debemos contar con medios de respaldo de los medios de respaldo principales utilizados en situaciones críticas. Es una doble protección que hace menos probable una posible cadena de fallo cuando ya se tiene una contingencia muy grave encima de la mesa. Obviamente estos esfuerzos sólo habrá que hacerlo con ciertas infraestructuras tan críticas que la inversión se encuentre justificada por las consecuencias que podría ocasionar un incidente severo sobre ellas. En el caso de Fukushima donde nos estamos jugando un incidente de contaminación nuclear obviamente sería de aplicación este razonamiento.

Y por último, otro análisis más psicológico del asunto. Esta catástrofe podría ser un desgraciado ejemplo de lo denominado como un "Cisne negro". Pero ¿qué es un cisne negro? Un cisne negro es un evento altamente improbable que puede alterar por completo las experiencias de las observacionse pasadas.Son teorías comentadas en el libro "El Cisne Negro. El impacto de lo altamente improbable" de Nassin Nicholas Taleb (versión original en Amazon, The Black Swan: Second Edition: The Impact of the Highly Improbable).


El ser humano tiene dificultades para hacer estimaciones cuando las probabilidades son confusas.  A su vez, también la gestión del cerebro de la incertidumbre y el peligro le puede jugar una mala pasada. Algo que ya comenté en el post "Los criterios de percepción del riesgo y el miedo". El cerebro tiene diferentes mecanismos que intervienen en el sistema nervioso a la hora de gestionar los eventos que detectan nuestros sentidos para garantizar nuestra supervivencia y que llamamos "Peligro". El peligro es la anticipación de un daño. El miedo es la anticipación de un peligro. La percepción del riesgo puede verse como la valoración sobre un peligro y la posibilidad de ocurrencia. A mayor percepción de miedo podemos sentir mayor riesgo y a mayor miedo podemos sentir que asumimos un mayor riesgo. El grado de control que tenemos sobre la situación que estamos valorando y lo voluntaria de dicha situación es lo que relaciona miedo y riesgo.
Los mecanismos de control que implantamos son utilizados por nuestro cerebro para masticar el peligro y transformarlo en un determinado nivel de riesgo que nos permite convivir con él.
Tal como aparecen en la última pregunta de las 10 que se plantea el artículo sobre Fukushima,

¿Se deben revisar los protocolos de seguridad nuclear?
“Entiendo que haya que hacer unos test de estrés como los que se han hecho a la banca”, admite Ortego. “Me parece perfecto y vamos a colaborar todos a que se haga y estoy bastante seguro del resultado”. “Desde luego lo que habrá que hacer es reevaluar la seguridad para ver si tenemos que mejorar algo, pero no cuestionarlas, porque son seguras y lo eran hace una semana”. Hay muchas voces que creen que no.

Está claro que Fukushima establecerá un antes y un después en cuanto a la seguridad de las centrales nucleares como ya ocurrió con Chernobil. El diseño de las medidas actuales es bueno para las circunstancias y amenazas valoradas para las que se habían diseñado mecanismos de protección pero ahora queda demostrado que las amenazas pueden superar esas estimaciones y por tanto, son vulnerables cuando se superan esos límites de contención. Sin embargo también debemos ser conscientes de que aun mejorando las medidas, vamos a tener que aceptar y convivir con ciertos riesgos si decidimos utilizar este tipo de fuente de energía. Tienen sus pros y contras pero siempre pueden suceder circunstancias que creen una crisis nuclear a resolver. Siempre pueden aparecer "cisnes negros" y desbordar toda previsión de riesgos. ¿Qué hubiera ocurrido si en vez de ser la catástrofe causada por un terremoto+ tsunami estuvieramos hablando de un accidente de aviación sobre la central? ¿Juzgaríamos de insuficientes las medidas actuales?

Sinceramente tenemos que aprender a vivir con riesgos y ello supone saber y conocer gestionar nuestros miedos porque siempre van a estar ahí, por mucho avance de la ciencia y la tecnología que queramos utilizar como escudo o parapeto.

De todas formas, de ser cierta la noticia "Fukushima nuclear plant owner falsified inspection records" el análisis sería completamente diferente pero eso ya será en otro post.

Administración electrónica II: Cuando la legislación afecta al diseño de los sistemas de información

Como comenté en el post anterior, estos primeros meses del año laboralmente me ha tocado profundizar mucho más en la regulación de desarrollo de la Ley 11/2007. El vencimiento del plazo para la elaboración del plan de adecuación al R.D. 3/2010 está moviendo un poco el tema aunque la implantación del Esquema Nacional de Seguridad se va a ver seguramente muy afectada por la situación económica que atraviesan las Administraciones Públicas en materia presupuestaria.

Dicho esto, voy a centrarme en el objeto del post que viene a reflexionar sobre el profundo cambio de mentalidad que debe empezar a darse en los departamentos de tecnología e informática de las Administraciones. Tal debe ser el cambio que ya no deberían estar solamente formados por personal técnico sino que debieran ser equipos mixtos con perfiles técnicos y jurídicos.

Es cierto que hasta la fecha, la Informática había contado con pocas restricciones o regulaciones jurídicas. La legislación, como siempre, por detrás de los tiempos que corren, va regulando las problemáticas una vez éstas ya aparecen o en otros casos, aparecen para precisamente establecer unos mínimos que deben ser garantizados para el desarrollo de las actividades habituales dentro de un plano de seguridad jurídica adecuado. Valga como referencia la Ley 15/1999 de Protección de Datos de Carácter Personal que en su inicio, cuando se denominaba LORTAD afectaba al tratamiento automatizado de datos de carácter personal y que fue la primera gran restricción en el diseño de sistemas de información que trataran datos de carácter personal.

Cuando yo estudié la carrera de Ingeniero en Informática, el título carecía de asignaturas relacionadas con legislación. Actualmente esto ya se ha solucionado pero los responsables de los servicios de informática de muchas organizaciones, con años de experiencia profesional sufren dichas carencias porque en sus planes de estudio estas asignaturas brillaban por su ausencia. Además se suma a ello que la legislación tecnológica no es algo muy atractivo para personal de perfil técnico. Sin embargo, como se suele decir, "el desconocimiento de la ley no exime de su cumplimiento" y ciertas regulaciones ya entran de lleno en criterios de diseño que deben ser tenidos en cuenta por parte de analistas funcionales de aplicaciones, responsables de departamentos de sistemas, responsables de servicios de informática, etc y que actualmente permanecen ignorados.

En este sentido, uno de los mejores ejemplos es la Ley 11/2007, de 22 de junio, de acceso electrónico de  los ciudadanos a los Servicios Públicos.  Esta Ley que tiene por objetivo la transición de la Administración Electrónica hacia el formato digital está regulando aspectos muy concretos que los sistemas de información deben satisfacer para dotar al funcionamiento de estos nuevos sistemas de información de las garantías jurídicas necesarias para otorgar validez jurídica al proceso automatizado de forma que sea equivalente al proceso de administración tradicional en soporte papel.

En este sentido, los técnicos deben entender que la adecuación a la legislación no es algo "a contemplar" o "tener en cuenta" sino que forma parte de los requisitos funcionales de diseño que tiene que ser garantizados "SI" o "SI". De lo contrario, el tramite administrativo en soporte electrónico podría tener problemas legales en el futuro y la organización afectada podría ver, a través de recursos, tumbadas sus actuaciones o diligencias por defectos de forma.

¿Y qué cosas concretas está regulando la Ley 11/2007?

Esta legislación está formalizando todos los aspectos que tienen que ver con el ciudadano y la Administración. Cosas tales como:

• Sede electrónica: es la ventanilla Web de atención al ciudadano y a través de la cual se accede al catálogo de procedimientos administrativos que se pueden realizar. Esta ley y sus reglamentos establecen cómo se da a conocer la sede, qué mecanismos de seguridad debe tener para autenticar el dominio Web donde se situa la sede, cuales son sus condiciones de disponibilidad, etc.
• Registro electrónico: es la ventanilla de entrega de documentación en soporte electrónico para dar fe de la misma y que quede constancia tanto al ciudadano como a la propia Administración de la recepción. Se arbitra en esta legislación cómo debe acreditarse esta entrega, cómo se garantiza el momento de la entrega mediante referencias temporales válidas como los sellos de tiempo, cómo se accederá a este registro, dónde debe encontrarse ubicado (que será dentro de la sede electrónica), que acuse de recibo deben entregar al ciudadano, etc.
• Comunicaciones y notificaciones electrónicas: serán las maneras que tendrá la Administración de comunicarse con el ciudadano, garantizando la validez de las mismas a efectos de cómputo de plazos.
• Documentos electrónicos: serán todos los documentos administrativos que puedan ser generados durante la fase de tramitación y que deberán preservar las condiciones de seguridad para que sean válidos jurídicamente durante todo el trámite administrativo. 
• Copias electrónicas: Es la forma de poder crear copias de documentos en soporte electrónico con garantías jurídicas y técnicas suficientes que permitan verificar a las partes que un documento es una copia electrónica auténtica de otro, ya sea del propio ciudadano o de la propia Administración. En este caso, es importante que se pueda garantizar la integridad y autenticidad de dicho documento dado que podría impugnarse su validez legal en caso de cualquier incidencia técnica o provocar el repudio por parte de una de las partes.
• Archivo electrónico: El archivo electrónico será la versión en formato digital de las grandes habitaciones donde se depositaban las ingentes cantidades de papel que forman parte de los expedientes administrativos. Lo que antes eran habitaciones de papel ahora pasan a ser servidores de almacenamiento con bases de datos que almacenan los documentos administrativos que forman los expedientes electrónicos.
• Expediente electrónico: Es el conjunto de documentos relacionado con la ejecución de un trámite administrativo y será la unidad de gestión dentro de los procedimientosverificación temporal de en qué momento el expediente ha ido cambiando de estado a efectos de justificación ante el ciudadano del vencimiento de plazos, etc.

Todos estos conceptos que vienen regulados y definidos en la Ley 11/2007 además gozan de desarrollos reglamentarios que concretan mucho más otros aspectos que deben ser tenidos en cuenta en la implementación de los sistemas de información que den soporte a los procedimientos administrativos en soporte electrónico. Destaca entre ellos el Real Decreto 1671/2009, de 6 de noviembre, por el que se desarrolla parcialmente la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los servicios públicos. En este Real Decreto se establecen restricciones en aspectos como:

• Características técnicas y de seguridad que debe tener la sede electrónica.
• Identificación y autenticación del Organismo mediante la Sede electrónica y de las comunicaciones y notificaciones que ésta realice al ciudadano.
• Requisitos técnicos de los registros electrónicos.
• Características de los documentos electrónicos.
• Cómo debe realizarse el proceso de digitalización del soporte papel para obtener un documento electrónico que pueda ser considerado "copia electrónica auténtica".
• Qué pruebas debe tener un documento electrónico impreso para permitir al ciudadano verificar su validez.
• Qué metadatos deben incorporar los documentos electrónicos y cómo y cuándo pueden ser alterados estos metadatos.
• Etc.

El objetivo del post es hacer ver a los responsables de los departamentos de informática que la Legislación actualmente está condicionado de forma muy clara el proceso de diseño de los sistemas de información y por tanto, todas estas restricciones deben ser tenidas en cuenta desde el inicio o durante el desarrollo porque en ello está la validez jurídica del procedimiento administrativo que pasa a realizarse en soporte electrónico. No estaría ya demás que los departamento de informática de las Administraciones Públicas contaran en su personal con algún perfil jurídico o bien, lograran involucrar a los servicios jurídicos de sus organizaciones porque lo que actualmente se está litigiando sobre el soporte papel, pronto empezará a litigiarse sobre el soporte electrónico y de no haber hecho las cosas bien, se darán muchos problemas que puedan comprometer la validez de los actos jurídicos realizados por el organismo.

Desde mi profundo desconocimiento del derecho administrativo, puedo imaginar el siguiente ejemplo:

"Nos llega a casa un impuesto y descubres que el documento que recibes en tu carpeta del ciudadano no está firmado digitalmente. Atendiendo a las definiciones de la Ley 59/2003, podemos afirmar que dicho escrito no es un "documento electrónico administrativo" y que carece de validez". En soporte papel sería como si te llegara a casa una fotocopia del recibo que envía un organismo o un fax solicitando un cobro. 

¿Pagaría el ciudadano en esas circunstancias? Yo creo que no... aunque por desgracia en estas circunstancias nos estamos empezando a acostumbrar a tramitar. Es la propia Administración la que está maleducando al ciudadano y la que está haciendolo vulnerable en el futuro a posibles fraudes online. Le está pasando a la Administración electrónica lo mismo que a la Banca electrónica hace 10 años cuando se la trataba de convencer de la necesidad de autenticación fuerte. No hicieron mucho caso debido al coste de las medidas y ahora han pagado sus consecuencias.

Por tanto, como decía al comienzo de este texto, "El desconocimiento de la ley no exime de su cumplimiento". En materia de Administración electrónica, toda la seguridad jurídica del proceso administrativo recae en la corrección y escrupulosa corrección técnica de la implementación que se le haya dado al trámite en soporte electrónico. Por tanto, si la informática falla, la validez legal del proceso corre peligro. Por eso es tan relevante hacer las cosas bien y a la primera. No es concebible que se pongan en marcha procesos administrativos bajo la etiqueta de "Administración electrónica" sin tener en cuenta las consideraciones que la propia legislación ha establecido porque no deja de ser un escaparate que pretende vender una falsa sensación de modernidad y que se encuentra vacía de validez jurídica. En este caso, los que deben validar el diseño del sistema de información son los abogados que deben verificar que los requisitos jurídicos del trámite administrativo son perfectamente garantizados por los mecanismos tecnológicos puestos al servicio del Organismo para llevar a cabo estas tareas en soporte electrónico. Y estamos hablando de valoraciones jurídicas sobre la corrección de la gestión de una base de datos, del sistema de notificación electrónica, del proceso de firma digital de documentos dentro de una aplicación, de la autenticación del personal funcionario en la ejecución de ciertos trámites, etc. 

Para otro post queda cómo deben gestionarse los logs de estos sistemas de información dado que son las evidencias de si las cosas se han hecho bien o mal, si hay posibles fraudes, etc... pero eso es otra pesadilla que ya no me da tiempo a contar. El mundo electrónico tiene innumerables ventajas y aporta agilidad, movilidad y productividad para hacer las cosas. Lo malo es que vivir en Matrix tiene ciertas reglas y controles que no pueden ser menospreciados si no se quieren pagar facturas muy caras en el futuro.