Ni la Agencia Tributaria se libra del Phising

Circula hoy una noticia relacionada con el envío masivo de spam y su consecuente phising sobre el portal de la Agencia Tributaria.

Obviamente el ingenio va agudizandose cada vez más y el estafador pretende engañar mediante ingeniería social, reclamando los datos confidenciales desde fuentes de confianza contrastada. Para esos objetivos quien mejor que nuestra Agencia Tributaria, famosa en el mundo entero por sus logros en eso que llaman la "E-Administración".

La noticia solamente es curiosa por el hecho de que quien ha sido suplantado ha sido la propia Administración Pública. Ahora, coincido con el blog donde he encontrado la noticia respecto a que "pruebas" aporta la "Administración Pública" para ser digna de nuestra "ciber-confianza".

Tal como apunta la Bitácora de los Hermanos Carrero, el Estado debería empezar a pensar en una "politica" común sobre la publicación de servicios telemáticos, de manera que el ciudadano pueda sospechar a la primera de cambio cuando crea estar frente a una web falsa o suplantada. Para ello, deberían consensuarse una serie de aspectos:
- Unificar criterios respecto a los dominios y utilizar siempre nuestro .es
- Presentar el certificado de servidor para poder verificar mediante el certificado que estamos entrando en una Web no suplantada y correspondiente con el dominio correcto.

Parece no mucho pedir, pero viendo el poder de reacción y corrección de "otras Webs públicas" y en concreto, la Web con la información de quienes son los prestadores de servicios de certificación homologados por el Ministerio, pues no podemos esperar nada bueno de esto de la e-Administración.

Parecen no hacerse las cosas con la rigurosidad con las que quedan establecidas a nivel jurídico por la ley de Firma Digital, tal como ya denuncié en "La E-Administración dando mal ejemplo" que nueve meses despues sigue igual, con la novedad de que ahora Internet Explorer 7 presenta semejante cartel al acceder a una Web de la Administración Pública.



¡ Administradores del Ministerio de Cincia y Tecnología, hagan honor al Ministerio que dirigen! y sobre todo, no nos dejen sin poder verificar qué instituciones son prestadoras de certificados de confianza porque se están cargando ¡la RAIZ de la confianza a nivel de entidades de certificación!

Si no puedo verificar si un certificado RAIZ es o no legal, no podré confiar en NINGUNO (siempre desde el punto de vista jurídico).

¿Tendremos que acostumbranos a estar en Webs públicas con semejante aspecto?.



Esto no es un tema de navegadores, da igual que sea Firefox, IExplorer 7, el problema está en la no correspondencia entre el dominio y el certificado de servidor que tiene instalado el servidor Web.

El enlace a la noticia detallada del phishing de la Agencia Tributaria puede leerse en Ni la Agencia Tributaria se libra del Phising

Los retos de seguridad de la e-Adminstración

Ultimamente llevo publicando bastantes artículos y reflexiones sobre la Administración Electrónica. Estamos en un momento clave para el Estado, donde por primera vez se plantea el reto de utilizar eficientemente las tecnologías de la información para lograr productividad, agilidad, transparencia, ahorro económico y otras muchas ventajas más pero tengo la sensación de que estamos dejando pasar un tren que pagaremos muy caro en el siglo XXI. Este tipo de situaciones son únicas y hablar de la adecuada adaptación del Estado al uso de las tecnologías de la información tiene varios aspectos ineludibles que debieran plantearse y que quedaron reflejados en la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.

El problema es que la política no debe solamente preocuparse en recoger en la legislación unos preceptos sino también proporcionar recursos para que se hagan realidad. Todos los ciudadanos estamos cansados de leyes que se incumplen sistemáticamente o regulaciones que son sólo un brindis al sol. El examen real de la acción política debe ser la transformación de la realidad tras el establecimiento de la legislación. Tenemos claros ejemplos de éxito en las cifras de los accidentes de tráfico de estos últimos años. La legislación no se ha quedado en texto, ha logrado cumplir objetivos y las estadísticas (como medidoras de la realidad) demuestran con hechos la eficacia del regulador.

Leyendo el blog de Julián Valero y una noticia que me llegaba hoy por correo sobre la "inseguridad del DNI-E" se me acumulan reflexiones sobre el camino que lleva esto de la Administración electrónica.

Es curioso también ver como gremios no relacionados, como informáticos y juristas, empezamos a coincidir en el diagnóstico, cada uno desde su orilla.

• Los jurístas están preocupados porque la transición a lo digital no pierda la seguridad jurídica del proceso tradicional. Ningún juez tiene problemas a la hora de entender y valorar que ha podido pasar en un caso relacionado con la tramitación en soporte papel.


• Los informáticos estamos preocupados porque la transición a lo digital garantice la corrección en el procesamiento de los datos y la seguridad de la información.

Sin embargo tenemos síntomas de que esto no está siendo así en muchos casos. A ello se suma la complejidad de todo este mundo interconectado, donde por primera vez se requieren conocimientos de disciplinas muy distintas trabajando de forma conjunta para entre todos aportar una solución holística al problema.

El análisis desde la perspectiva del diseño de procesos que debe hacerse de la seguridad de la información requiere de un enfoque peculiar. Como ya comenté en su día en el post "Dentro de la Mente Torcida del Profesional de Seguridad" Bruce Schneier lo expresa muy claramente: "la seguridad requiere una mentalidad peculiar. Los profesionales de la seguridad -al menos los buenos- ven el mundo de manera diferente. No pueden caminar en una tienda sin notar cómo podrían robarla. No pueden usar una computadora sin preguntarse acerca de las vulnerabilidades de seguridad. No pueden votar sin imaginarse cómo votar dos veces. Simplemente, no lo pueden evitar. Esta manera de pensar no es natural para mucha gente. No es natural para los ingenieros. La buena ingeniería implica pensar sobre cómo las cosas están hechas para funcionar; la mentalidad en seguridad involucra pensar sobre cómo las cosas pueden estar hechas para fallar. Esto implica pensar como un atacante, un adversario o un criminal. No tienes que explotar las vulnerabilidades para encontrarlas, pero si no ves el mundo de esa manera, nunca notarás tantos problemas de seguridad."

Y con esta forma de razonar, estoy sinceramente preocupado como profesional por la situación que plantea la e-Adminsitración. Quizás por venir asesorando al sector banca puedo decir que "cuando veas las barbas de tu vecino pelar, pon las tuyas a remojar". Es ingenuo pensar que una vez que los procesos administrativos se canalicen por Internet no vaya a haber problemas. El ánimo de lucro es una poderosa motivación y el fraude será el origen de los males que acechen a la Administración electrónica, como ya lo es de los problemas que sufre la Administración tradicional.
¿Acaso no hay fraude en el IVA, la Renta, las subvenciones, en general en las gestiones administrativas habituales?

La Administración Electrónica puede contribuir en mucho a poner freno a estas situaciones pero tengo la sensación de que realmente parece que no queremos aprovechar estas ventajas. Es como si supieramos que estas medidas serán eficaces y que al sistema no le interese tanta efectividad. Sólo hay que ver, como prueba del éxito de los radares de tráfico cómo éstos han acabado siendo boicoteados. ¿Por qué? Porque son infalibles para el objetivo para el que han sido diseñados y por tanto, lo único que queda por hacer para vulnerar su seguridad es intentar destruirlos.

Internet no cambia los problemas, solamente los medios necesarios para causarlos.
Los técnicos que sabemos de esto nos vemos entre la espada y la pared: por un lado no queremos transmitir miedo porque si las cosas se hacen bien no tiene que haber problemas pero por otro, odiamos el absurdo juego político de vender humo cuando detrás realmente no hay ni por asomo la seguridad que se intenta vender.
De esta primera situación ya tenemos la primera víctima, el DNI-e. Aparece cuestionado como "inseguro" cuando esa afirmación no es del todo exacta.
Confundimos el todo por la parte y el mecanismo por la utilización que se hace de él.
El "USO del DNI-E" supone la relación de tres piezas: [soporte electrónico]<->[aplicación]<->[ciudadano]. Los fallos de seguridad por ahora vienen de las interacciones soporte<->aplicación y aplicación<->ciudadano. En sí mismo, la tarjeta electrónica del DNI-e si es segura, tal como demuestra la certificación ISO 15408 otorgada por el CCN. Lo que no es seguro es cómo las aplicaciones usan el DNI-e. Ya hace un par de años se hacían demostraciones técnicas de estos hechos. El tema es muy sencillo: la firma electrónica no es para nada un proceso similar a la firma manuscrita. Cuando firmamos algo, el usuario lo único que hace es indicar un pin que da acceso al sistema operativo a la clave privada del certificado para que la aplicación firme unos datos. Si la aplicación da el cambiazo a los datos, el ciudadano ni se entera.
¿Solución?
Siguiendo el principio del eslabón más debil, la seguridad debe ser igual de consistente en las tres piezas que forman parte de este proceso. En ello se trabaja desde hace tiempo.
Lo primero que se hizo es garantizar que el soporte electrónico donde se iban a guardar los datos de firma electrónica sea seguro. Pero esto es solo garantizar el buen funcionamiento de una de las piezas. Lo siguiente es ahora garantizar que deben ser seguras son las aplicaciones y el transito de información con la tarjeta electrónica. Por ello el esfuerzo del INTECO por publicar los Perfiles de protección en castellano.
Todo esto fue objeto de una explicación más extensa en los dos post ISO 15408 y el DNI-e, PP para el desarrollo de aplicaciones Parte I y Parte II. Sin embargo, ¿Quién entonces se va a molestar en garantizar que su aplicación usará bien el DNI-e?

El último de los problemas se planteará cuando siendo las aplicaciones sean seguras y el soporte también. Entonces la picaresca pondrá su objetivo en el ciudadano que no ha sido debidamente informado y formado sobre la utilización de estos medios. ¿Por qué desde el principio no se repartieron los folletos indicando en qué consiste el DNI-e?

Llevamos tanto tiempo haciendo las cosas mal que ahora va a ser muy complicado cambiar la forma de trabajar. Ni siquiera el Esquema Nacional de Seguridad puede que lo consiga. A nivel teórico es perfecto y propone un buen modelo de seguridad pero la realidad es que no dejará de ser más que un brindis al sol, como lo es actualmente el R.D. 1720/2007 en el titulo VIII de medidas de seguridad. ¿Qué consecuencias tendrá para una Administración Pública el incumplimiento del Esquema Nacional de Seguridad? ¿No tiene también consecuencias el incumplimiento de la Ley de Protección de Datos y a pesar de ello sigue sin cumplirse?

Es frustrante ver cómo si las cosas se hacen bien desde el diseño se evitan los problemas pero las miras cortoplacistas de la política no entienden estas premisas y van a apagar fuegos siempre, arreglando las cosas sobre la marcha cuando los daños ya se han sufrido.

La e-Administración dando mal ejemplo: El Padre que no tiene padre

Como en otros post anteriores, hoy vamos a ver un ejemplo de cómo en esto de la seguridad las medias tintas no garantizan el cumplimiento de los objetivos planteados.

El caso de hoy tiene que ver con las garantías que la AEAT nos quiere dar sobre la fiabilidad del software PADRE que podemos descargar de su página Web para la realización de la declaración de la renta. Voy a plantear este ejemplo como si de un análisis de riesgos se tratara, para mostrar como al final, no se logra garantizar el objetivo por el cual se plantea la medida de seguridad.

• Objetivo de seguridad: Garantizar la integridad del programa Padre o lo que es lo mismo, que todo ciudadano pueda tener la certeza de que la aplicación Padre que está descargada en su PC y que va a instalar para hacer la renta es la aplicación legítima elaborada por la AEAT y no una aplicación maliciosa.


• Amenaza: Intentar engañar al usuario y colar una aplicación malware que robe datos dentro del PC del ciudadano. Para ello, podría aparecer un sitio Web falso que tratara de engañar a los contribuyentes y que pusiera a su disposición un ejecutable manipulado.


• Salvaguarda: En este caso, se publica el código MD5 de la aplicación ejecutable en la Web de la AEAT.


• Beneficio de seguridad: El usuario puede descargar el ejecutable y comprobar en su PC si la aplicación que se ha bajado coincide en su MD5 con la publicada por la AEAT en la Web www.aeat.es. Es una comprobación básica de la integridad del fichero que demuestra la no manipulación.

Ambas capturas corresponden a las garantías de integridad que actualmente proporciona la Web de la AEAT respecto al programa PADRE que podemos descargar de la Web.


Con esta solución parcial e incompleta, no se logra mitigar el riesgo planteado por la amenaza de suplantación. ¿Por qué?

Cualquier atacante que elabore una aplicación maliciosa que vaya a simular ser el programa Padre lo que hará seguramente será distribuirla probablemente desde una Web que suplante también a la Web de la AEAT. Ya en su momento la Agencia Tributaria sufrió un caso de phishing algo más simple donde solicitaban datos bancarios bajo el señuelo de que se devolvía antes la renta. Evidentemente este atacante lo que también haría sería colocar en la Web suplantada el correspondiente código MD5 de la aplicación maliciosa que quería hacer pasar por el programa PADRE y el ciudadano seguramente, aun comprobando la integridad, sería victima del engaño.

Para que esta hipótesis no pudiera ser planteada, la AEAT debería "demostrar" que su página Web se corresponde con el dominio www.aeat.es, utilizando como medio de seguridad la presentación de un certificado digital. Algo que la Banca electrónica ya tiene más que asumido parece que en las Administraciones Públicas no está todavía a la orden del día, y eso que ya admiten trámites electrónicos. Sin embargo, no está disponible el acceso bajo https a la Agencia Tributaria, como muestra esta captura donde el certificado de servidor apunta hacia un dominio akamai que es donde deben estar alojados los servicios Web para satisfacer la demanda de ancho de banda y balanceo de carga.



Alonso Hurtado ya planteo esta problemática en el post "La sede electrónica en el nuevo modelo de e-Administración".

Artículo 10. La sede electrónica.
1. La sede electrónica es aquella dirección electrónica disponible para los ciudadanos a través de redes de telecomunicaciones cuya titularidad, gestión y administración corresponde a una Administración Pública, órgano o entidad administrativa en el ejercicio de sus competencias.

Artículo 17. Identificación de las sedes electrónicas.
Las sedes electrónicas utilizarán, para identificarse y garantizar una comunicación segura con las mismas, sistemas de firma electrónica basados en certificados de dispositivo seguro o medio equivalente.

Por tanto, de nuevo tenemos como hay más de "sensación de seguridad" que de "protección real de la seguridad".

• Objetivo de seguridad: Garantizar la integridad del programa Padre o lo que es lo mismo, que todo ciudadano pueda tener la certeza de que la aplicación Padre que está descargada en su PC y que va a instalar para hacer la renta es la aplicación legítima elaborada por la AEAT y no una aplicación maliciosa.


• Objetivo no cumplido dado que la Web donde se coloca el HASH MD5 no realiza la autenticación de servidor. Engañar al ciudadano sería algo tan trivial como suplantar la Web de la AEAT, colocar el malware que se haría pasar por el programa PADRE y publicar el MD5 del troyano en la propia Web falsa.
  Si tenemos integridad sobre la aplicación software que descargamos, pero no tenemos autenticación sobre si el HASH que utilizamos para verificar la integridad es correcto o no, por tanto, el mecanismo pierde toda su eficacia.

Otro caso más donde se demuestra que las medias tintas no logran la protección deseada.

La e-Administración dando mal ejemplo

Esta semana he tenido la suerte de asistir a unas jornadas entorno a la e-Administración celebradas dentro del marco del SICARM que es la feria de las tecnologías de la información de la Comunidad Autónoma de Murcia. Las charlas están grabadas y todas pueden ser consultadas en
esta dirección. Recomiendo sobre todo las del jueves por la tarde.

Quizás por mi deformación profesional que está orientada sobre todo al análisis y la gestión del riesgo, cuando pienso en seguridad no busco que fronteras establecer sino cual es el agujero más probable por el que se puede entrar.

Desde que me dedico a esto, se habla del cambio de paradigma en la forma de hacer las cosas, pasando de lo tangible a lo intangible y de lo físico a lo digital, con la liberación de restricciones que eso supone respecto a espacio y tiempo.

Este cambio sobre todo cultural, debe forzar a trabajar con rigor y seriedad y en este nuevo mundo que estamos construyendo, dos gremios que no han convivido mucho están llamados a trabajar de la mano para establecer las reglas juridico-tecnológicas de este cambio de paradigma.

Hace años se habla de un mecanismo de seguridad que puede (tecnicamente tiene el potencial suficiente) proporcionar garantías sobre la autenticidad, integridad y confidencialidad llamado FIRMA DIGITAL. Pero este Aquiles de la seguridad tiene
también su talón y en el caso de la Firma digital y su uso en forma de certificados la debilidad es no cumplir escrupulosamente con las reglas que hacen que el mecanismo sea digno de confianza.
Además, precisamente para garantizar que esto no ocurra lo primero que se hizo fue definir un marco jurídico robusto que estableciera unas reglas MINIMAS sobre su uso, creación y utilización en la Ley 59/2003 de Firma Digital.


Pues creo que el ser una ley de ámbito tecnológico lleva a que el superman de turno en la organización (el informático) tenga que meterse en donde no nos llaman sin saber la trascendencia de sus actos. Un principio básico de la ley es que su desconocimiento no exime de su cumplimiento. Eso creo que lo sabemos todos.

Sin ánimo de convertir este blog en un foro de denuncia, hay cosas que me preocupan porque precisamente en estos momentos de transición es cuando no podemos hacer mal las cosas y que acostumbremos al usuario a ver como normal la ausencia de medidas de seguridad tales como la no validez de certificados en sitios importantes y mucho más si son de la Administración que es quien regula. Por tanto, he decidido que voy a REGISTRAR los eventos relacionados con la E-Admin en donde NO SE PREDICA CON EL EJEMPLO.

Lo que voy a postear a continuación trae cola...
Primer caso: Ministerio de Ciencia y Tecnología

En esta Web, sección asociada a la Prestación de Servicios de Certificación ocurre la situación (a día 27-05-2006) que a continuación he podido capturar.


Compruebelo usted mismo aquí.

La Web en donde todo usuario debe consultar para saber si una entidad prestadora de servicios de certificación es LEGAL tiene un certificado de servidor que no autentica la url del navegador. O sea, dibuja un candado pero el navegador comienza avisándote que no puede verificar la validez del certificado. Si desconfiamos y no seguimos navegando NO podemos consultar quienes son los prestadores legales en vigor. La primera en la frente. El motivo técnico es simplemente porque han modificado la ubicación del web y se han pasado por alto que la url no se corresponde con la asignada en el certificado. En la captura puede verse como el certificado fue expedido a www10.micyt.es y la url se encuentra situada en www11.micyt.es/prestadores/. Un desliz técnico menor pero de trascendencia grave para el significado del certificado que lo hace carente de valor.

Segundo caso: Real Observatorio de la Armada

El Real Observatorio de la Armada tiene como misión principal el mantenimiento de la unidad básica de Tiempo, declarado a efectos legales como Patrón Nacional de dicha unidad, así como el mantenimiento y difusión oficial de la escala "Tiempo Universal Coordinado" (UTC(ROA)), considerada a todos los efectos como la base de la hora legal en todo el territorio nacional (R. D. 23 octubre 1992, núm. 1308/1992).



Compruebelo usted mismo aquí.

En esta Web (a día 27-05-2006) , en la sección Acceso ROA se proporciona un acceso https con un certificado de servidor "casero", sin registrar. Tal como dice la web anterior del Ministerio de Industria, Turismo y Comercio, 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 información deberá ser convenientemente actualizada por los prestadores de servicios de certificación y será objeto de publicación en la dirección de Internet del citado Ministerio con la finalidad de otorgarle la máxima difusión y conocimiento.

Tercer caso: Dirección General de la Policía
El acceso a la web segura de la Policía, en la url https://www.policia.es también presenta en el navegador un aviso respecto a que el certificado raíz es de una entidad emisora de confianza. Como conocedor de estas tecnologías, uno se va entonces al Registro de prestadores y tras aceptar que este certificado tampoco es válido por lo comentado anteriormente, consulta la lista de prestadores de servicios de certificación autorizada por el Ministerio.

Pues bien, la Dirección General de la Policía se encuentra en trámite pero no sale en la consulta de los prestadores ya autorizados (a día 27-05-2006).


Compruebelo usted mismo aquí.


La misión y objetivo de este blog es simplemente mostrar y concienciar respecto a la seguridad de la información. El post de hoy evidencia el acceso a tres sitios de la e-Administración en donde antes de poder acceder, el navegador me indica que la validez del certificado con la que se inicia la sesión https no puede ser comprobada o no reúne los requisitos.

¿Vamos a acostumbrar ya al usuario a usar "siguiente-siguiente-siguiente" sobre los avisos respecto a la validez del certificado cuando por otro lado desde el CATA se indica que toda la seguridad de la navegación está en la comprobación de dicho certificado?

Más rigurosidad y responsabilidad cuando manejemos la seguridad porque la confianza es un activo muy fragil. No la destruyan tan pronto.

Fuente:Web del Ministerio de Industria, Comercio y Turismo

"El desarrollo de la Sociedad de la Información y la difusión de los efectos positivos en términos de competitividad que de ella se derivan exige la generalización de la confianza de los ciudadanos, empresas y Administraciones en las comunicaciones telemáticas.

La firma electrónica es una herramienta fundamental para la mejora de la seguridad de la información y la generación de confianza, dado que permite efectuar una comprobación de la identidad del origen y de la integridad de los mensajes intercambiados en Internet."


Pues que así sea.

La Informática es ley

Este post lleva unos meses ya cocinándose en mi cabeza desde que en una reunión de amigos informáticos nos pusimos ha hablar del rol de nuestra profesión en el siglo XXI. Las discusiones filosóficas sobre si la informática es un arte, una ingeniería, una ciencia derivaron en comentarios respecto al papel regulador de la actividad humana en nuestro día a día. A quien no le suena familiar ya la frase de "Disculpe pero el programa informático no me deja hacer esto o lo otro". 

Y realmente empieza a ser cierto que en muchas situaciones mandan los criterios de un ordenador que muestra un resultado o una decisión en una pantalla salvo que olvidamos o ignoramos que la máquina no toma decisiones, las tomó en su momento el desarrollador del código que programó esa aplicación para presentar esos resultados.

Como ya he comentado antes, estos meses ando liado con temas vinculados al Esquema Nacional de Seguridad y por ende la Administración electrónica. En estos momentos en los departamentos de TI de todas las Administraciones Públicas se andan cocinando proyectos que tienen por objetivo facilitar al ciudadano su relación con la Administración permitiendo interactuar telemáticamente con ella. Algo que ya vemos natural en el sector financiero es ahora un derecho establecido por la Ley 11/2007 que supuestamente debe suponer un impulso a la introducción de las tecnologías de la información en la Administración Pública.

Sinceramente debo ver este avance con cierta preocupación porque al menos por lo que voy encontrando a mi paso parece que ahora el derecho quedará definido por el código de programación de las aplicaciones con las que vayamos a tener que tramitar. Es cierto que los reales decretos de desarrollo de la Ley 11/2007 se han ido publicando de forma tardía pero ello no debiera justificar la ausencia de cumplimiento de todos ellos. Siempre hemos oído que el desconocimiento de la ley no exime de su cumplimiento. Sin embargo, parece que la Informática como tal, está por encima del bien o del mal y que puede obrar con libertad saltándose las restricciones que el mundo del derecho ha establecido mediante las regulaciones oportunas. De nada sirve que la legislación hable de cosas tan concretas como la firma electrónica, el expediente electrónico, regule cómo debe ser un documento electrónico para que sea considerado una copia auténtica de uno equivalente en papel, etc si no se le hace ningún caso. Y reflexionando al respecto creo que estas circunstancias se dan principalmente por cuatro factores:

• Las áreas TI y sobre todo, el mundo del desarrollo no incorpora siempre los requisitos legales establecidos porque ignora en muchos casos cual es la reglamentación que afecta a la aplicación en concreto que se está desarrollando. Es cierto que en estos años el número de leyes y reales decretos es abundante pero nuestra profesión, como las demás, no es ajena al cumplimiento de la ley. En el caso del ingeniero en informática además la cosa se agrava cuando es precisamente el que debe tomar las decisiones respecto a la implementación de programas que obviamente también deben garantizar ese cumplimento legal. En consultoría en materia de seguridad uno de nuestros ejes sobre el que orientar lo que se debe garantizar es el cumplimiento de la legislación respecto a la protección de información. Y el espectro de leyes que pisan ya muy seriamente al área TI no es pequeño. Por nombrar las más relevantes, tenemos al menos estas leyes y reales decretos que tener en mente en todo momento:
• Directiva 1999/93/CE del Parlamento Europeo y del Consejo, de 13 de diciembre de 1999, por la que se establece un marco comunitario para la firma electrónica.
• Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.
• Ley 59/2003, de 19 de diciembre, de firma electrónica.
• Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.
• Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.
• 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úblico.
• Real Decreto 3/2010, de 8 de enero, por el se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.
• Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.

• En los equipos de desarrollo normalmente no participan áreas de perfil jurídico que puedan asesorar o apoyar al área de programación a entender o interpretar correctamente las regulaciones establecidas. Esta ausencia de criterios por parte de personal especializado se suple con la buena intención o hacer del personal técnico de desarrollo que "interpreta a su manera" lo que la ley expresa, siendo muchas veces una visión distorsionada o no ajustada al objeto de protección establecida por la legislación. A ello también contribuye bastante que la redacción de la legislación anteriormente nombrada es en muchos casos ambigua e imprecisa en las definiciones de términos o en la propia redacción permitiendo todo tipo de licencias a la hora de programar lo regulado. Es necesario que estos proyectos son multidisciplinares y al menos en las fases de diseño y análisis de requisitos es necesario la visión del ingeniero en informática que sabe lo que se puede programar, la del jurísta que entiende lo que la ley pretende salvaguardar y la del bibliotecónomo que conoce bien los entresijos de la gestión y organización de la información para hacer un uso eficiente de los datos. Todos con un objetivo único y común, hacer que la aplicación proporcione la funcionalidad deseada con la máxima eficiencia posible, el menos consumo de recursos y sobre todo y fundamentalmente, garantizando la seguridad jurídica de la gestión en base a la robustez de la implementación por el nivel de cumplimiento de las regulaciones del ámbito tecnológico.
• La gestión de proyectos TI cuando las decisiones técnicas se ven condicionadas por factores políticos son un lodazal que pringa a los buenos profesionales y donde ven a diario como son ignorados sus consejos o criterios. Para ejemplificar esta situación quiero recomendar leer el post Como el agua: ¿son las TICs una utility? de alguien que habla con conocimiento de causa y desde dentro de la casa.
• La ausencia de supervisión y verificación del cumplimiento mínimo de garantías. A nadie nos sorprende que el más vulgar electrodoméstico o producto deba superar unas pruebas mínimas que  verifiquen la seguridad industrial del proceso de fabricación. Algo que exigimos a cualquier tipo de objeto ni por asomo se nos pasa por la cabeza que sea atribuible al mundo del software. ¿Y por qué no? Obviamente enlentecería el proceso de desarrollo pero ¿para que queremos hacer las cosas rápido si las hacemos mal y luego hay que rehacerlas y empezar de nuevo? 

Y aunque el tono del post sea algo pesimista, quiero destacar que si hay gente que está haciendo las cosas bien, gente que piensa mucho primero, diseña y define lo que es necesario establecer, lo documenta y después se pone manos a la obra a poner ladrillo tras ladrillo hasta lograr el resultado final. El problema es que esos ejemplos son "poco conocidos" y su labor poco entendida. Es necesario tener completamente identificado cual es el problema a solucionar para poder resolverlo de forma correcta. Y como lo mejor siempre es un buen ejemplo, quiero referenciar el excelente trabajo de Nacho Alamillo en lo que denomina su "gestión documental segura" donde ha establecido un mapa conceptual con todas las piezas del puzzle que hay que resolver para poder hacer real que las aplicaciones efectivamente garanticen la seguridad jurídica establecida por las leyes. Tal como pinta en su Web, las elementos que hay que relacionar con cohexión y consistencia son los siguientes:

Nacho, creyente del modelo de licencia Creative Common, ha colgado su formalización de la política de gestión documental segura en este enlace y nos permite a todos consultar cada una de las piezas que forman parte de la complejidad regulatoria y técnica que hay que definir para tener un puzzle consistente y robusto, de forma que no quede ninguna duda de cumplimiento legal. Las piezas del puzle que toda solución de e-Administración debe implementar debe definir, documentar y resolver cuestiones de diferentes ámbitos y dominios, vinculados a la seguridad, a la criptografía, a la gestión documental, al derecho administrativo de forma que en su conjunto, todos los mecanismos proporcionen el cumplimiento legal y la garantía de que el trámite en soporte electrónico proporcionará un nivel de confianza similar al trámite en soporte papel. 

Os animo a recorrer el mapa conceptual que he referenciado en el enlace y a leer las normas e instrucciones técnicas que lo componen. Y aquellos que leáis esto y estéis metidos en proyectos de e-Admin, hacedse la siguiente pregunta ¿Cuantas piezas del puzzle habéis identificado y definido?

 Como he leído hoy en un blog, "“Si no puedes pagar el coste de hacer las cosas bien, espera a que te llegue la factura por hacerlas de forma mediocre”. 

Manual sobre la factura electrónica

Estamos inmersos en un proceso general de transición del soporte papel al soporte digital. Uno de los principales motores de este cambio está siendo el esfuerzo de la Administración General del Estado por introducir la "e-Administración" o "Administración electrónica"

Como máximo exponente tenemos en España el Plan Avanza que es uno de los ejes del Ingenio 2010, la estrategia para acelerar la convergencia tecnológica con Europa.

Red.es pone en marcha una colección de manuales para divulgar aspectos que se consideran clave en la Sociedad de la Información. En concreto, el presente post tiene por objetivo enlazar con el Manual sobre la Factura Electrónica.

Aunque solo he podido mirarlo por encima (porque lo tengo en formato papel), el contenido es del tomo imprescindible e interesante para estar preparado para los tiempos que se avecinan. Como ocurre en los nuevos temas de la Administración electrónica, la seguridad de la información es un pilar horizontal que debe garantizar la correcta ejecución de los procesos, aunque también aparece como otro pilar los temas jurídicos relacionados con el uso de las tecnologías de la información, en concreto, la firma electrónica.

El contenido del manual es el siguiente:

• El ABC de la factura electrónica


• Trabajar con la factura electrónica de manera fácil


• Proyectos avanzados de factura electrónica


• Interacción con la factura papel


• Formatos de factura y firma


• Anexo I.Introducción a la firma electrónica y certificación digital


• Anexo II.Marco jurídico de la firma y de la factura electrónica

Para los que solo quieran al menos informarse sobre los conceptos básicos de la firma electrónica, deben leer los anexos I y II nada mas. El documento puede descargarse en Manual sobre la Factura Electrónica.

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.

La irresponsabilidad del Estado en materia de e-Administración.

En el argumentario de todos los anuncios y publicaciones en materia de Administración electrónica siempre aparece la palabra "Confianza". Incluso en la redacción de la Ley 11/2007 como en los desarrollos reglamentarios, las medidas y mecanismos de seguridad se imponen por esa necesidad de crear las condiciones adecuadas para que la tramitación electrónica tenga el marco adecuado de forma que goce de las garantías suficientes para crear confianza por parte de los ciudadanos.

La confianza en los sistemas de información se construye de varias formas: por un lado con la regulación de unas medidas mínimas de protección y por otro, con la creación de aplicaciones y procesos de gestión que garanticen los requisitos de seguridad necesarios para poder evidenciar dicha "confianza". En este sentido y afectando a las aplicaciones, el Inteco elaboró en castellano los perfiles de protección para el uso del DNI-e de forma que toda aplicación que vaya a usar este potente mecanismo de identificación y autenticación lo haga con las premisas y garantías necesarias para acreditar un uso correcto y eficiente. Estas acciones se encarcan, auditan y certifican con la norma ISO 15408 conocida vulgarmente como "Criterios Comunes" de los que ya he hablado anteriormente.

Cual es mi sorpresa estos días cuando descargando el cliente del programa PADRE para la Renta 2010 me encuentro en la necesidad de descargar también el cliente @Firma.

Para un "Ingeniero en Informática" en relación a un producto software es muy duro leer cosas como las que aparecen en la dichosa cláusula del cliente @Firma y que por deformación profesional suelo mirar por curiosidad.
No sería la Informática una Ingeniería si todos los desarrollos realizados gozaran de esta impunidad para asumir responsabilidades por las líneas de código creadas. Sin embargo, t
tal como muestra la captura de pantalla que adjunto a modo de evidencia y citando literalmente, se establecen las siguientes premisas en este módulo denominado "cliente @Firma" utilizando para firmar digitalmente:

• " El cliente @Firma se provee en su  estado actual y sin garantías de ningún tipo".
• " El Gobierno de España y su personal no tendrá responsabilidad alguna que surja del uso del cliente @Firma o que se relacione con su uso. Su único derecho o recurso legal ante cualquier problema o disconformidad con el cliente @Firma es dejar de usarlo de inmediato".

Obviamente esta redacción casi seguro tiene como origen el famoso "Copia y pega" que seguro habrá hecho el Departamento Técnico que desarrolla la aplicación. Digo esto porque cualquier abogado que se precie sabe que esta redacción posiblemente no respete la legislación vigente dado que el Estado no puede  proporcionar servicios sin garantía. Además, si tuviera que actuar como perito de parte en un problema con este cliente, como la cláusula también deja bien claro que la propiedad intelectual corresponde al Gobierno de España, no creo que sea dificil también atribuirle la responsabilidad civil subsidiaria que pudiera derivarse de los resultados desastrosos de esa "propiedad intelectual" puesta en ejecución sobre un servidor. Además, como estas dichosas cláusulas no las lee nadie, seguro debieron pensar que algo así pasaría o pasa completamente desapercibido.
Sin embargo, resulta paradógico ver cómo por un lado tratan de hacerse las cosas bien y exigir a las aplicaciones la certificación ISO 15408 para demostrar "confianza" y por otro, para algo ciertamente importante y que supone uno de los procesos telemáticos más utilizados por los ciudadanos, vemos como se desarrollan aplicaciones que lo primero que te dicen es que no se hacen responsables de nada. Además, este módulo se supone que es con el que se garantiza la autoría, lo que lleva a pensar en manos de qué código fuente estamos al realizar una de las actividades más relevantes como es la notificación telemática del impuesto sobre la renta. Otro ejemplo más de la "deuda técnica" con la que seguramente tendremos que enfrentarnos en unos años.

¿Cómo queremos crear "confianza" en la Administración electrónica con estas incoherencias? Es un hilo que dejo abierto a comentarios. Espero que al dar cierta difusión a esa aberración de EULA, al menos se preocupen en modificar el texto y maquillarlo un poquito.

Jornadas SYTE 10.09 en Murcya sobre e-Administración

En Murcia andamos muy activos con los retos jurídicos y tecnológicos de la e-Administración y una asociación a la cual pertenezco, Murcia, Control y Auditoría (www.MURCYA.org) organiza un evento que puede ser de interés para todos los que os podáis desplazar a la Región.



Para más información o inscripciones, se pueden seguir los siguientes enlaces:

• Triptico


• Inscripción

Esto de la e-Administración es todavía para cogerlo con pinzas...

Acabo de sufrir mi primera experiencia telemática de trato con la e-Administración. Como buen ciudadano acabo hace unos minutos de enviar mi declaración de la renta a través del programa PADRE. Estoy impresionado y aqui agarrado a la silla. Simplemente acojonado.

Acabo de firmar digitalmente la declaración de la renta y para mi sorpresa en ningún momento me ha solicitado eso que "yo solo se y que da acceso a mi clave privada" para firmar. ¿Quién es entonces el enanito escondido en mi PC que ha sido capaz de acceder a mi clave privada sin mi permiso?

Por que lo que si se es que jurídicamente soy responsable de todo aquello que esté firmado con el dichoso certificado. En fin, creo que voy a eliminar el certificado en fichero y hasta que no tenga la dichosa tarjeta y el lector, no voy a arriesgarme a dejar mi certificado en mano de las aplicaciones.

Mal empezamos y mal nos estamos acostumbrando. Esto de firmar digitalmente, si tiene identica repercusión con la firma manuscrita debe ser algo más transparente para el usuario final no entendido en la materia. Debe dar la sensación de control absoluto sobre la potestad de firmar porque en papel cuando uno coge el boli sabe lo que está haciendo (aunque no sea consciente del contenido de lo firmado). Aqui cuando uno instala un certificado no tiene claro qué hacen con "el boli" las aplicaciones y cuando se estampa una firma digital y cuando no. Al menos, cuando el certificado esté en un dispositivo físico si tendremos esa sensación de "boli en la mano".

EU2010.es, Mr Bean y la gestión de la seguridad

Estaba cocinando varios post sobre la revisión del año 2009 y los pronósticos del año 2010 pero la actualidad informativa obliga hoy a saltarse la planificación previa. Nos hemos levantado con la noticia del señor Mr. Bean como portada de algunos de los periódicos en relación al incidente sucedido ayer con el portal de la presidencia de la Unión Europea. Los hechos salen a la luz en los medios de comunicación tradicionales seguramente haciéndose eco de algunos comentarios que corrían ya por otros canales de difusión más populares en la Red como son menéame.net y el propio Twitter.

Parece que siempre aprendemos más por "lo sufrido" que por "lo avisado" y el presente post quiere ser una reflexión sobre varios aspectos que hay que meditar en relación a los hechos acontecidos. Más vale prevenir que curar, pero siempre acabamos con las tiritas en la mano. Lo secuenciaré por escenarios.

Los hechos.
Durante el día de ayer, y según lo que he podido leer en la prensa técnica y no técnica, durante cierto tiempo la Web de la Presidencia Española de la Unión Europea albergada en el dominio www.eu2010.es permitía Cross-Site Scriptings que hacía que cierto enlace creado a tal efecto fuera visualizado por los navegadores de los usuarios que lo pulsaban con la presencia de Mr. Bean en vez de Zapatero. Hay dos blogueros que explican con precisión lo sucedido:

• Securitybydefault.com
• 
  MMadrigal.com

Noticia una-al-dia Hispasec

Los daños.
En relación a la seguridad de la información pura y dura de la Web, realmente este incidente supone un "cero zapatero" dado que el supuesto problema de seguridad no afectaba ni a la confidencialidad de los datos, ni a la disponibilidad (inicialmente, luego veremos que sí) ni a la integridad (dado que en el lado servidor no hay alteración alguna). Por tanto, los daños calificables como operativos son CERO. Sin embargo, atendiendo a otras valoraciones que siempre han de hacerse sobre todo "activo de información", si se ha producido un impacto o daño. El hecho de que hoy aparezca en prensa una noticia sobre un fallo de seguridad, se cuestione la inversión en el portal y la diligencia de la empresa encargada de gestionarlo es en sí mismo un daño en imagen. Una Web institucional es el escaparate de una Organización y por tanto SI tiene asignada una valoración en relación al daño a la imagen corporativa de la organización que representa. En este sentido, este incidente de seguridad mancha la imagen institucional que la presidencia europea ha querido dar y arranca su andadura con una noticia negativa. Además y de forma colateral (y me atrevo a aventurar que también atrevida) se está cuestionando la diligencia de la empresa contratada a tal efecto sin haber todavía asistido a un análisis técnico detallado de los hechos. Este quizás haya sido también el fallo de los responsables del portal que no han sabido dar quizás unas explicaciones técnicamente clarificadoras a los hechos (Mal porque todo plan de contingencia/continuidad de negocio debe contemplar también los aspectos mediáticos del incidente y controlar la información que se proporciona a prensa para aclarar los hechos).
En este sentido, es muy criticable también el papel desempeñado por los medios de comunicación. Reconozco que lograr llamar la atención en la actual sociedad de la información es el hito que todos los medios (y sobre todo los online) buscan a diario. Pero dado que la principal misión del periodismo es contar la verdad, el rigor informativo, la precisión de los datos y el contraste de las fuentes son pilares que deben sostener todo trabajo. La noticia publicada ayer por "El Mundo" decía textualmente:

"Los hackers consiguieron saltarse los sistemas de seguridad de la web de la Presidencia española el lunes, bloquear la página y colocar una imagen de Mr. Bean, sonriente, con los ojos muy abiertos y con cara de sorpresa, que saludaba con un "Hi there" ("Hola a todos", en un inglés coloquial)."

Como bien nos han contado MMadrigal.com y Securitybydefault.com, podemos afirmar que realmente el problema se sitúa más en el lado cliente que en el lado servidor. Por intentar hacer un símil con la seguridad física que sea entendible, sería algo como decir que por pintar la fachada del muro exterior del Palacio de la Moncloa se ha vulnerado la seguridad del Palacio de la Moncloa. Un poco exagerado, ¿no? El supuesto ataque ha consistido en que se ha empleado una captura de una página de búsqueda del sitio para hacer un fotomontaje al que se ha asignado una dirección (url o enlace) que luego se ha distribuido en Internet, a través de redes sociales y blogs. El Instituto Nacional de Tecnologías de la Comunicación (INTECO), adscrito al Ministerio de Industria, Turismo y Comercio, confirma en su auditoría de seguridad sobre http://www.eu2010.es que “el supuesto ataque ha consistido en aprovechar una vulnerabilidad del código fuente denominada XSS (cross site scripting) dirigida a los usuarios de la web y no a la web en sí misma”. Según Inteco “este tipo de ataques, para resultar efectivos, deben combinarse con alguna técnica adicional que engañe al usuario de la web para que pinche en un enlace modificado malintencionadamente, por ejemplo, con ingeniería social”. Sin embargo, el incidente inicial tuvo un efecto colateral no deseado pero algo más serio que acabó afectando a la disponibilidad de la Web. Una noticia llamativa y una Web de relevancia que presentaba un aspecto gracioso hizo que muchos internautas, picados por la curiosidad quisieran en un breve espacio de tiempo consultar la página y ello acabo (de forma improvisada) generando una denegación de servicio en toda regla.

Las reflexiones.
La primera reflexión es un tirón de orejas contra los medios de comunicación tradicionales que han caído en el sensacionalismo tecnológico. O bien por su ignorancia técnica no suplida por asesoramiento específico, o bien por sus dobles intenciones de otra índole, finalmente el verdadero "incidente de seguridad" ha sido el causado por la noticia y no en sí mismo por el hecho contado en la misma.


Además, bastante mal se están haciendo las cosas en seguridad como para meter más leña al tema. El pie de página de la captura de página de la noticia dice "La presidencia ha invertido 11,9 millones de euros en la seguridad de su web". Por favor, seamos serios. Esa cuantía no se corresponde con la seguridad solamente y antes de afirmarlo, informense porque los pliegos de contratación son públicos y se puede saber perfectamente qué se licita. Lo hace www.securitybydefault.com, qué mínimo que un periodista. Además, san Google lo localiza todo rápidamente pero hay que tener interés por contrastar la información.

La segunda tiene que ver con la importancia no cuantitativa de algunos activos de información. Es cierto que en la Web Eu2010.es no hay quizás información confidencial o datos de carácter personal pero sin embargo, tiene un peso simbólico que debe ser protegido. Por tanto, cualquier amenaza que pudiera afectar a su contenido, aspecto o disponibilidad debe ser bien valorada. Si además, es un "activo muy expuesto" y este lo es porque está accesible por Internet, ciertas medidas de seguridad deben ser cuidadosamente implantadas, auditadas y posteriormente vigiladas. Los hechos han demostrado que no ha sido el caso. La valoración final de los hechos es que no hay daño de seguridad pero si impacto para la imagen de la Presidencia Europea representada por España, dado que otros medios se hacen eco hoy del incidente, sin entrar en la gravedad. La noticia es el hecho, no los daños.

La tercera tiene que ver con la gestión de la seguridad y más específicamente con la gestión de la vulnerabilidad. No es de recibo que una Web que va a ser visitada a lo largo del mandato de España en la Presidencia Europea y que cuenta con un presupuesto bastante cuantioso no haya sido convenientemente protegida. La gestión de la vulnerabilidad no es una actividad estática, no es realizar un chequeo de vulnerabilidades, generar un informe y solventar las deficiencias. Es un proceso porque las vulnerabilidades nacen, crecen, se reproducen y finalmente se mitigan, como las cucarachas. Por tanto, su vigilancia no es simplemente cada cierto tiempo hacer una revisión, es una tarea continua de investigar si se conocen para los productos que tenemos instalados nuevas vulnerabilidades, si hay que aplicar parches, programar las tareas para mitigarlas y vuelta a empezar. Queda muy bien explicado por el siguiente dibujo.



En este sentido, ya empiezan a aparecer en el mercado de este segmento de medidas de seguridad soluciones donde su principal valor añadido es precisamente esta gestión asistida. A mí personalmente me encanta el enfoque que le han dado la gente de Outpost24 y que podéis ver en esta presentación. También es importante considerar la monitorización de servicios y noticias. Si por lo que parece, en varias Webs ya se iba comentando que en el dominio había problemas de "cross site scripting" lo prudente habría sido haber auditado si algo podía fallar. Tan sencillo como usar los servicio de Google Alerts y establecer cadenas como el nombre del dominio y podríamos al menos advertir que Google empieza a indexar demasiadas cosas sobre nuestros recursos. Yo lo hago sobre mi blog para detectar quién me referencia.

La cuarta tiene que ver con la auditoría de seguridad como evidencia de haber atado cabos. La seguridad no existe nunca al 100% y siempre toca asumir riesgos. Sin embargo, no es lo mismo no haber hecho nada que haber hecho algo aunque no haya evitado el incidente. Lo primero demuestra NEGLIGENCIA, lo segundo, GESTIÓN DEL RIESGO. Las auditorias siempre tienen un doble objetivo. El primero y fundamental es encontrar deficiencias pero el segundo es evidenciar una situación en un momento dado. En este caso, contar con una auditoría de vulnerabilidades sirve para saber si se revisaron los sistemas y no se encontró el fallo o bien, el problema era conocido pero no se había "gestionado".

Lo inquietante.
De todo esto, la cosa que más me inquieta es ver cómo los servicios online caen ante la consulta masiva de usuarios. Es razonable que no se pueda dar servicio a demasiados usuarios simultáneos pero , ¿cuántos son la cifra razonable?. En el caso de un portal con información dirigida a ciudadanos de la Unión Europea situados en unas franjas horarias similares, ¿cuantas peticiones es razonable atender?. Lo razonable podría ser un ratio entre la población a la que se dirige el servicio y la probabilidad de que lo hagan de forma simultánea. En su momento se vendió la atención telemática como ese factor que permite servicios 24x7x365 de forma continua. Sin embargo y en los inicios de la e-Administración, ¿va a ser esto verdad? ¿Tendremos que acabar haciendo de nuevo cola ante los servidores Web?. Mucho me temo que cuando estemos al final de un plazo de recaudación, muchos ciudadanos olvidadizos o descuidados van a querer hacer sus trámites en el último momento y supuestamente la e-administración permite trabajar hasta las 23:59:59 del día antes del plazo.


Seamos positivos, miremos adelante pero aprendiendo de los errores del pasado.

Mucho ya he hablado en este blog sobre la inocencia que a veces demuestran tanto Administraciones Públicas como empresas en esto de la seguridad de la información. El peligro está ahí fuera porque siempre hay riesgos. Otra cosa es que no se manifiesten pero ello puede deberse simplemente a un "factor suerte" o a la no existencia de una motivación clara para producir daño.

En este sentido, ya comenté en su momento la aparición en escena del famoso "Esquema Nacional de Seguridad" que será una R.D. que establezca los mínimos necesarios en la materia exigibles a la e-Administración. Solo hay que leer el artículo primero para ver cuales son sus intenciones.

Artículo 1. Objeto.
1. El presente real decreto tiene por objeto regular el Esquema Nacional de Seguridad establecido en el artículo 42 de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, y determinar la política de seguridad que se ha de aplicar en la utilización de los medios electrónicos a los que
se refiere la citada ley.
2. El Esquema Nacional de Seguridad está constituido por los principios básicos y requisitos mínimos requeridos para una protección adecuada de la información. Será aplicado por las Administraciones Públicas para asegurar el acceso, integridad, disponibilidad, autenticidad, confidencialidad, trazabilidad y conservación de los datos, informaciones y servicios utilizados en medios electrónicos que gestionen en el ejercicio de sus competencias.

Más adelante, entre sus principios básicos de protección, tenemos joyas como el artículo 7, 19 y 20.

Artículo 7. Prevención, reacción y recuperación.
1. La seguridad del sistema debe contemplar los aspectos de prevención, detección y corrección, para conseguir que las amenazas sobre el mismo no se materialicen, no afecten gravemente a la información que maneja, o los servicios que se prestan.
2. Las medidas de prevención deben eliminar o, al menos reducir, la posibilidad de que las amenazas lleguen a materializarse con perjuicio para el sistema. Estas medidas de prevención contemplarán, entre otras, la disuasión y la reducción de la exposición.
3. Las medidas de detección estarán acompañadas de medidas de reacción, de forma que los incidentes de seguridad se atajen a tiempo.
4. Las medidas de recuperación permitirán la restauración de la información y los servicios, de forma que se pueda hacer frente a las situaciones en las que un incidente de seguridad inhabilite los medios habituales.
5. Sin merma de los demás principios básicos y requisitos mínimos establecidos, el sistema garantizará la conservación de los datos e informaciones en soporte electrónico.

De igual modo, el sistema mantendrá disponibles los servicios durante todo el ciclo vital de la información digital, a través de una concepción y procedimientos fiables que generen objetos digitales auténticos y estables, que sean la base para la preservación del patrimonio digital.

Artículo 19. Seguridad por defecto.
Los sistemas deben diseñarse y configurarse de forma que garanticen la
seguridad por defecto:
a) El sistema proporcionará la mínima funcionalidad requerida para que la organización sólo alcance sus objetivos, y no alcance ninguna otra funcionalidad adicional.
b) Las funciones de operación, administración y auditoría del sistema serán las mínimas necesarias, y se asegurará que sólo son accesibles por las personas autorizadas.
c) En un sistema de explotación se eliminarán o desactivarán, mediante el control de la configuración, las funciones que no sean de interés, sean innecesarias e, incluso, aquellas que sean inadecuadas al fin que se persigue.
d) El uso ordinario del sistema ha de ser sencillo y seguro, de forma que una utilización insegura requiera de un acto consciente por parte del usuario.

Artículo 20. Integridad y actualización del sistema.
1. Todo elemento físico o lógico requerirá autorización formal previa a su instalación en el sistema.
2. Se deberá conocer en todo momento el estado de seguridad de los sistemas, en relación a las especificaciones de los fabricantes, a las vulnerabilidades y a las actualizaciones que les afecten, reaccionando con diligencia para gestionar el riesgo a la vista del estado de seguridad de los mismos.

Y luego, dentro del Anexo referido a las medidas de seguridad a aplicar tenemos soluciones que de haberse aplicado, podrían evitado lo sucedido:

• 4.1.1 Análisis de riesgos [op.pl.1].


• 4.3.3 Gestión de la configuración [op.exp.3].


• 5.6.2.Aceptación y puesta en servicio [mp.sw.2].

De todas formas, es el problema de siempre. Lo importante en seguridad no es saber qué hay que hacer sino hacerlo y mucho me temo que pasará igual que con la protección de datos, que el cumplimiento de la Ley no es suficiente motivación.

Por cerrar este extenso post y como conclusión final, que cada cual aguante sus riesgos. Nos vemos en el siguiente incidente. Buenas tardes y buena suerte ZP.

Administración electrónica: la "deuda técnica" que se nos avecina.

La entrada en vigor el año pasado del R.D. 3/2010 se anunciaba como un impulso al mercado de la seguridad de la información. Como suele ser habitual en Administraciones Públicas, la legislación solo preocupa cuando vencen los plazos de adecuación.

Llevo desde principios de año buceando más profundamente sobre el cumplimiento de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos que es la columna vertebral de la que emanan tanto el Esquema Nacional de Interoperabilidad como el Esquema Nacional de Seguridad y la situación que se vislumbra es preocupante, al menos en el ámbito en el que yo me estoy moviendo.

El titulo del post va a ser el eje de la reflexión que pretendo plantear. Estamos ante un momento crucial para la Administración Pública Española. Parece muy trascendental la afirmación pero es que creo que así es. La Ley 11/2007 es, además de una declaración de intenciones sobre la modernización de la Administración, una regulación que establece "el proceso de migración del soporte papel al soporte electrónico". Por tanto, es una legislación que sirve para regular y normalizar cómo debe producirse la conversión desde la tramitación presencial hacia la tramitación telemática. En todas las aproximaciones que he presenciado hacia Organismos Públicos que están abordando este tema, se plantean una serie de situaciones repetitivas que a continuación paso a comentar:

• El proyecto de adecuación a la Ley 11/2007 cae sobre el área tecnológica: esto es un sintoma claro del desconocimiento de la trascendencia de la propia legislación. Lo que pretende la legislación es adecuar los procedimientos administrativos al entorno digital preservando las "garantías jurídicas" de dicho proceso. Por tanto, involucrar sólo al área tecnológica ya supone un grave error desde el diseño puesto que la naturaleza del proceso y su problemática no puede ser conocida por el área TI sino por el área de negocio que habitualmente ejecuta esos procedimientos administrativos.
• Desconocimiento del marco legal por parte del area tecnológica y jurídica: otro de los factores recurrentes que me encuentro es el desamparo que sienten las áreas tecnológicas respecto a los requisitos legales y sus consecuencias técnicas que ya han sido regulados por reglamentos derivados de la Ley 11/2007. Los servicios jurídicos de las organizaciones no vienen responsabilizándose de la cobertura legal que deben dar a la organización en materia tecnológica. Es cierto que la legislación ha estado muy convulsa  y en 5 años se han publicado leyes y reales decretos que por nuevos son desconocidos, pero son muy relevantes porque dan las pautas para la realización y el diseño de unos sistemas de información robustos y lo que es más importante, dotados de los requisitos jurídicos necesarios para garantizar la validez jurídica de los tramites administrativos. Por tanto, el área técnica debe implantar los diferentes servicios establecidos por la Ley de forma completa y correcta, satisfaciendo los requisitos que la regulación marca. Hay que destacar que existen directrices claras respecto a cómo debe ser la sede electrónica, el archivo y expediente electrónico, las comunicaciones y notificaciones telemáticas, el registro electrónico, etc.

Creo que un equipo de proyecto de Administración electrónica debe estar formado por un personal jurídico y técnico que comparten un fin común: resolver técnicamente las necesidades jurídicas del procedimiento administrativo a adecuar. Informáticos y abogados trabajando conjuntamente para comprender la naturaleza técnica de los requisitos jurídicos que la legislación ha plasmado en los diferentes reales decretos ya publicados. Y para sorpresas de técnicos e informáticos, la legislación a veces concreta tanto como hasta definir qué metadatos debe tener un documento electrónico, cómo debe realizarse el proceso de digitalización del papel, qué requisitos debe tener la sede electrónica o cómo deben plantearse los calendarios de conservación de los documentos electrónicos.

En las charlas de presentación de la problemática sobre Administración Electrónica siempre empiezo por tratar de contextualizar a los oyentes sobre los grandes cambios que hay entre gestionar papel y gestionar documentos electrónicos. Las diferencias son bastante notables y se centran en estos aspectos:

• Un documento en soporte papel está limitado por las restricciones físicas del mundo real, espacio y tiempo. La información que recoge es el contenido plasmado sobre el soporte utilizado para su representación y no hay más. En cuanto a la capacidad de procesamiento, está limitado también dado que su almacenamiento ocupa lugar físico y su transporte supone el desplazamiento físico por el mundo real del soporte y por tanto restringido a la velocidad que pueda alcanzar el soporte en su traslado de un origen a un destino. El envío de información por las redes de telecomunicaciones siempre supone la generación de una copia puesto que el original siempre permanece en el punto origen emisor de la información. En cuanto a la seguridad del documento, se limita a la protección física del soporte. Teniendo vigilado el soporte se tiene vigilada la información.
• Un documento electrónico es mucho más. La información intangible es almacenada en un soporte tangible pero también puede trasladarse a través de las redes de telecomunicaciones sin perder ninguna propiedad. La información del documento está compuesta por el contenido, los metadatos del archivo donde esa información se encuentra y en los logs o registros de los sistemas y aplicaciones informáticas que han tratado esa información. Por tanto, una primera y sustancial diferencia es que pasamos a tener Datos y Metadatos, siendo ambos información relevante respecto al contenido del documento. La segunda gran diferencia sustancial es que en un documento electrónico no se pueden presuponer ciertos conceptos sin pruebas previas. No existe original o copia a no ser que éstas se acrediten técnicamente mediante firma digital. Respecto a los metadatos que establecen las fechas de creación o modificación, el tiempo es un parámetro del sistema que habrá que acreditar. Esto quiere decir que para poder demostrar el momento en el que se producen ciertas acciones, habrá que dar fe de ello de forma técnica siendo el sellado de tiempo la forma de producir dicha garantía. Por tanto, desde la perspectiva de la seguridad de la información creo que ya se vislumbra que la cosa se complica y que las necesidades de protección aumentan. 

En este contexto, la legislación relacionada con la aplicación de la Ley 11/2007 ha pretendido dar garantías jurídicas al documento electrónico para que no se produzcan problemas y sea posible la tramitación en soporte electrónico. Sin embargo, estas necesidades tecnológicas de aportar protección técnica para que los procesos administrativos sean equivalentes en un formato o en otro no están siendo puestas en marcha por parte de las Administraciones lo que equivale a estar migrando los procesos presenciales hacia procesos telemáticos desamparados jurídicamente, lo que implicará problemas en el futuro. Esta situación se justifica en parte por la lentitud con la que han ido apareciendo los Reales Decretos. Hay que pensar que la Ley 11/2007 establecía hasta finales del 2009 como plazo de adecuación y sin embargo los Esquemas Nacionales de Interperabilidad y Seguridad fueron publicados en el 2010.

¿Y qué conceptos y legislación es relevante en materia de Administración Electrónica?

Lo que un responsable de tecnología debe entender es que su misión, al abordar un proyecto de adecuación a la Ley 11/2007 es garantizar la identica protección legal se tramite en papel o en soporte electrónico. Para ello, en el año 2003 se publicó la Ley 59/2003 de firma digital que sienta los cimientos y conceptos esenciales para que la equivalencia jurídica entre papel y soporte electrónico sea idéntica. Esta ley en su artículo 3 define qué es un documento electrónico, la pieza esencial de cualquier gestión administrativa. A continuación podéis ver la redacción de dicho artículo.

Artículo 3. Firma electrónica, y documentos firmados electrónicamente.

1. La firma electrónica es el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante.

2. La firma electrónica avanzada es la firma electrónica que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados, que está vinculada al firmante de manera única y a los datos a que se refiere y que ha sido creada por medios que el firmante puede mantener bajo su exclusivo control.

3. Se considera firma electrónica reconocida la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma.

4. La firma electrónica reconocida tendrá respecto de los datos consignados en forma electrónica el mismo valor que la firma manuscrita en relación con los consignados en papel.

5. Se considera documento electrónico la información de cualquier naturaleza en forma electrónica, archivada en un soporte electrónico según un formato determinado y susceptible de identificación y tratamiento diferenciado.

Sin perjuicio de lo dispuesto en el párrafo anterior, para que un documento electrónico tenga la naturaleza de documento público o de documento administrativo deberá cumplirse, respectivamente, con lo dispuesto en las letras a o b del apartado siguiente y, en su caso, en la normativa específica aplicable.

6. El documento electrónico será soporte de:

• Documentos públicos, por estar firmados electrónicamente por funcionarios que tengan legalmente atribuida la facultad de dar fe pública, judicial, notarial o administrativa, siempre que actúen en el ámbito de sus competencias con los requisitos exigidos por la ley en cada caso.
• Documentos expedidos y firmados electrónicamente por funcionarios o empleados públicos en el ejercicio de sus funciones públicas, conforme a su legislación específica.

• Documentos privados.

7. Los documentos a que se refiere el apartado anterior tendrán el valor y la eficacia jurídica que corresponda a su respectiva naturaleza, de conformidad con la legislación que les resulte aplicable.

8. El soporte en que se hallen los datos firmados electrónicamente será admisible como prueba documental en juicio. Si se impugnare la autenticidad de la firma electrónica reconocida con la que se hayan firmado los datos incorporados al documento electrónico se procederá a comprobar que se trata de una firma electrónica avanzada basada en un certificado reconocido, que cumple todos los requisitos y condiciones establecidos en esta Ley para este tipo de certificados, así como que la firma se ha generado mediante un dispositivo seguro de creación de firma electrónica.

La carga de realizar las citadas comprobaciones corresponderá a quien haya presentado el documento electrónico firmado con firma electrónica reconocida. Si dichas comprobaciones obtienen un resultado positivo, se presumirá la autenticidad de la firma electrónica reconocida con la que se haya firmado dicho documento electrónico siendo las costas, gastos y derechos que origine la comprobación exclusivamente a cargo de quien hubiese formulado la impugnación. Si, a juicio del tribunal, la impugnación hubiese sido temeraria, podrá imponerle, además, una multa de 120 a 600 euros.

Si se impugna la autenticidad de la firma electrónica avanzada, con la que se hayan firmado los datos incorporados al documento electrónico, se estará a lo establecido en el apartado 2 del artículo 326 de la Ley de Enjuiciamiento Civil.

9. No se negarán efectos jurídicos a una firma electrónica que no reúna los requisitos de firma electrónica reconocida en relación a los datos a los que esté asociada por el mero hecho de presentarse en forma electrónica.

10. A los efectos de lo dispuesto en este artículo, cuando una firma electrónica se utilice conforme a las condiciones acordadas por las partes para relacionarse entre sí, se tendrá en cuenta lo estipulado entre ellas.

Estas definiciones de la Ley 59/2003 son de vital importancia dentro de las AA.PP. porque establecen qué es un "documento público en soporte electrónico" y como se puede ver, la necesidad de la firma digital es un requisito de la propia definición. Todo documento en soporte electrónico sin firma digitalmente es papel mojado. Además, en rojo he marcado las partes del artículo donde la legislación atribuye las equivalencias jurídicas entre el papel y el soporte electrónico. El artículo 4 también de la Ley 59/2003 se encarga de establecer cómo debe emplearse la firma electrónica dentro de las AA.PP.

Partiendo de las definiciones de la Ley de Firma digital, la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos ha ido regulando otros requisitos necesarios para que se produzca el proceso de transición de forma correcta. Ello queda perfectamente reflejado en los siguientes Reales Decretos:

• 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.
• Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.
• Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.

A este marco jurídico desarrollado específicamente para extender la Ley 11/2007 hay que añadir, y es de suma importancia, que cuando se habla de tramitación administrativa siempre hay detrás un ciudadano. Por tanto, es de gran relevancia considerar en todo momento el cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal y su desarrollo reglamentario en el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal. Hay que recordar que el Titulo VIII de dicho reglamento establece las medidas de seguridad que debe garantizar todo tratamiento de estos tipos de datos.

Ya para terminar y tras esta enumeración de legislación que establece  requisitos y condicionantes tecnológicos concretos que habrá que implantar, quiero también recomendar y enlazar al blog Microlopez, toda una referencia en materia de Administración Electrónica al que ya nombré con su magnífico manual de supervivencia de la @Administración Electrónica.

Su última reflexión habla de la "deuda técnica: la Burbuja de las TIC" y la define en el siguiente párrafo:

La deuda técnica es una metáfora de Ward Cunningham que describe como hacer las cosas rápido y mal va generando, con mecanismos propios de las burbujas financieras, una deuda similar a nivel técnico. En realidad el problema no es nuevo en absoluto en el mundo del software, se puede ver como una variante de lo que ya fue denominado en los años 60 como la “crisis del software”.

La deuda técnica tiene asociado el pago de intereses que se concretan en el esfuerzo extra necesario en el futuro por una elección rápida y mala de diseño, la cosa va creciendo y se vuelve cada vez más insostenible. Al igual que en el mundo financiero, si te pasas, el exceso acabará en un gran desastre del cual, en el mejor de los casos, se “sale” con un costoso rescate que conlleva una nueva deuda como lo puede ser en las TIC la sustitución apresurada de un sistema o conjunto de sistemas ante un problema inminente e insalvable, fruto de errores pasados, por otros nuevos que tampoco se han examinado lo suficiente.

En otros casos el desastre a nivel informático puede ser más sutil, pero no menos importante: se puede manifestar en una estructura de costes que al haber perdido control va creciendo poco a poco hasta un punto que pone en duda el sentido de las aplicaciones en cuestión o dicho de otro modo: que la supuesta mejora de productividad que se logra con la utilización de estas aplicaciones corporativas se vuelve negativa.

El propio autor lo explica en este video colgado en Youtube.





En esta página tenéis la transcripción del video.

Aquellos proyectos de Administración Electrónica que no implanten con rigurosidad todos los requisitos establecidos por la legislación anteriormente nombrada estarán generando en sus correspondientes organismos una "deuda tecnica" que pasará factura en el futuro. Si se gestionan documentos electrónicos que no son firmados digitalmente o se recogen en los registros electrónicos documentación que no dispone de una referencia temporal válida, dichos documentos en soporte electrónico podrían tener dudosa validez jurídica y dar como resultado la nulidad del trámite administrativo dado que siempre quedará al ciudadano la posibilidad del repudio de dicha información. No se dispondrán de garantías técnicas suficientes para afirmar la autenticidad e integridad de dicha información y por tanto, el conflicto está servido.
El primer problema es que el ciudadano común desconoce también la necesidad de garantizar estos requisitos técnicos y tendrán que ser los abogados más puestos en la materia los que usen como argumento estas deficiencias técnicas en sus alegatos.
El segundo problema será que el juez entienda el meollo de la cuestión, aunque si el abogado cuenta con un buen perito informático, este podrá mostrarle al juez que es posible generar información en soporte electrónico con idénticas propiedades a las presentadas por la Administración cuando esta no está firmada digitalmente ni sellada en tiempo. La evidencia digital es así de frágil cuando no se la dota de las medidas de seguridad adecuadas.