Regulada la obligación de reconocer los incidentes de seguridad en la reforma de la Ley General de Telecomunicaciones.

Llevamos estos últimos meses leyendo mucho sobre intrusiones en sistemas de información, grupos organizados de hackers que amenazan a Organismos y Empresas y demás noticias que empiezan a ser cotidianas. Quizás la más relevante sea el caso Sony aunque en España también el Inteco ha sido víctima de hechos similares, todos ellos recogidos en el artículo de El País titulado "Intensa temporada Hacker". 

Si bien ahora son populares, llevan fraguandose desde hace  mucho tiempo. Ya en la entrada "¿Qué elegir, gestionar vulnerabilidades o detectar ataques con IDS? comenté el cuadrante de amenazas que siempre hay que contemplar y que responde a esta frase que empleaba Joseba Enjuto mediante el juego de palabras "Lo que sé que sé, lo que sé que no sé, lo que no sé que sé y lo que no sé que no sé"

Quizás, la tónica general en materia de seguridad ha sido aplicar la filosofía "Ojos que no ven, corazón que no siente" hasta que viene un externo y te demuestra que por mucho que aprietes los ojos por no ver, "las vulnerabilidades están ahí fuera" como diría el Agente Malder de Expediente X. Lo que ya es notorio es el cambio general de tendencia respecto al objetivo y motivación de estos ataques que cada vez son más atractivos para los criminales que los perpetran y que generan unos (ingresos para el atacante/perdidas para el atacado) bastante significativos. La siguiente infografía representa el "Hall of fame" de los robos de datos más notorios de los últimos tiempos donde se aprecia el volumen de información robada en cada caso.

Esta otra infografía complementa a la anterior y hace un repaso rápido de la historia del Hacking, pudiendo verse aquí el incremento del coste económico de los ataques a lo largo del tiempo.

Esta tercera infografía relata en concreto el caso Sony PS3 donde al final de la misma podéis ver la estimación del coste del incidente de seguridad: 171millones de dolares gastados, una estimación de 24 Billones de dolares. El coste de las medidas de prevención no llega a 10.000 dolares. Por desgracia, este tipo de análisis del Return of Security Investment (ROSI) se hacen a posteriori y los financieros de las empresas no entienden de futuribles sino de hechos contrastados. En cualquier caso, la lección a aprender es clara.

Infographic by Veracode Application Security



Todo esto viene a colación por la introducción en la futura modificación de la Ley 32/2003, General de Telecomunicaciones de un par de apartados que merecen cierta mención porque aparece por primera vez la obligación de reconocer los incidentes de seguridad y de notificar a los potenciales afectados de estos hechos siendo sancionado el hecho de no hacerlo. Todo ello limitado por supuesto por el objeto de aplicación de esta ley aunque ya es un primer avance en el tema.

En los aspectos relativos al secreto de las comunicaciones y a la protección de datos de carácter personal, se hace una apuesta clara por un refuerzo de las obliga­ciones para alcanzar mayores niveles de seguridad en el tratamiento de los datos, extremando las cautelas en lo que se refiere al tratamiento y la protección de datos por parte de los operadores. En este sentido la nueva redacción dada al artículo 34 establece, además de la información a los usuarios de los riesgos potenciales de violación de sus datos personales, se introduce ahora la obligación, cuando se produzca una violación de datos personales, de informar a la Agencia Española de Pro­tección de Datos, que queda reforzada además como autoridad nacional de reglamentación para que pueda valorar el alcance de la violación e idoneidad de las medidas adoptadas por el operador.

Ello expresamente queda regulado por las modificaciones introducidas en la Ley General de Telecomunicaciones que en esta propuesta de Ley quedan redactadas como sigue:

«Artículo 34. Protección de los datos de carácter personal.

1. Sin perjuicio de lo previsto en el apartado 6 del artículo 4 y en el segundo párrafo del artículo anterior, así como en la restante normativa específica aplicable, los operadores que exploten redes públicas de comuni­caciones electrónicas o que presten servicios de comu­nicaciones electrónicas disponibles al público deberán garantizar, en el ejercicio de su actividad, la protección de los datos de carácter personal conforme a la legisla­ción vigente.

2. Los operadores a los que se refiere el apartado anterior deberán adoptar las medidas técnicas y de ges­tión adecuadas para preservar la seguridad en la explo­tación de su red o en la prestación de sus servicios, con el fin de garantizar los niveles de protección de los datos de carácter personal que sean exigidos por la Ley Orgánica 15/1999, de 13 de diciembre y su normativa de desarrollo y, en su caso, por la que se dicte en desa­rrollo de esta ley en esta materia. Dichas medidas incluirán, como mínimo:

a) La garantía de que sólo el personal autorizado tenga acceso a los datos personales para fines autoriza­dos por la ley.

b) La protección de los datos personales almace­nados o transmitidos de la destrucción accidental o ilí­cita, la pérdida o alteración accidentales o el almacena­miento, tratamiento, acceso o revelación no autorizados o ilícitos.

c) La garantía de la aplicación efectiva de una política de seguridad con respecto al tratamiento de datos personales.

3. En caso de que exista un riesgo particular de violación de la seguridad de la red pública o del servi­cio de comunicaciones electrónicas, el operador que explote dicha red o preste el servicio de comunicacio­nes electrónicas informará a los abonados sobre dicho riesgo y sobre las medidas a adoptar.

4. En caso de violación de los datos personales, el operador de servicios de comunicaciones electrónicas disponibles al público notificará sin dilaciones indebi­das dicha violación a la Agencia Española de Protec­ción de Datos. Si la violación de los datos pudiera afec­tar negativamente a la intimidad o a los datos personales de un abonado o particular, el operador notificará tam­bién la violación al abonado o particular sin dilaciones indebidas.

Lo previsto en el párrafo anterior será exigible una vez que mediante real decreto se establezca el conteni­do de las notificaciones dirigidas a los abonados o par­ticulares, así como los supuestos en que no será necesa­ria la misma. Asimismo, el real decreto podrá establecer los restantes requisitos de las notificaciones a las que se refiere el párrafo anterior en lo referente a su contenido y condiciones. Mediante real decreto podrá establecerse el formato y contenido del inventario. A los efectos establecidos en este artículo, se enten­derá como violación de los datos personales la viola­ción de la seguridad que provoque la destrucción, acci­dental o ilícita, la pérdida, la alteración, la revelación o el acceso no autorizados, de datos personales transmiti­dos, almacenados o tratados de otro modo en relación con la prestación de un servicio de comunicaciones electrónicas de acceso público.

5. Los operadores instaurarán procedimientos internos para responder a las solicitudes de acceso a los datos personales de los usuarios por parte de las autori­dades legalmente autorizadas. Previa solicitud, facilita­rán a las Autoridades competentes información sobre

esos procedimientos, el número de solicitudes recibi­das, la motivación jurídica aducida y la respuesta ofre­cida.»

Todo esto está muy bien, pero lo más interesante llega ahora, cuando se establecen las "motivaciones suficientes" para hacer que estas medidas se apliquen que como bien supondréis están justificadas bajo el concepto de ROSI (Return of Security Investment) o dicho de otra forma, por qué es más barato hacer las cosas bien que pagar las multas por no haberlas hecho.

Disposición final primera. Modificación de la Ley Orgánica 15/1999, de 13 de diciembre, de Protec­ción de Datos de Carácter Personal.

Uno. Se añaden dos párrafos al apartado 2 del artículo 45 de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal con la siguiente redacción:

«En el caso de que se trate de la infracción tipificada en el párrafo h) del apartado tercero del artículo 44 (Mantener los ficheros, locales, programas o equipos que contengan datos de carácter personal sin las debidas condiciones de seguridad que por vía reglamentaria se determinen) y una ley impusiese al responsable del fichero o el encar­gado del tratamiento la obligación de notificar al afec­tado o a la Agencia Española de Protección de Datos la existencia de un fallo en la seguridad, sin haberse dado cumplimiento a esta obligación, la cuantía mínima de la sanción será de 60.000 euros. Si el incumplimiento al que se refiere el párrafo anterior fuera reiterado, la cuantía mínima de la san­ción será de 100.000 euros.»

Dos. Se añade un apartado 9 al artículo 45 de la Ley Orgánica 15/1999, de 13 de diciembre, de Protec­ción de Datos de Carácter personal con el siguiente contenido:

«9. Lo dispuesto en los apartados 5 y 6 de este artículo será igualmente aplicable a las sanciones que la Agencia Española de Protección de Datos pudiera impo­ner de conformidad con lo dispuesto en la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Infor­

mación y de Comercio Electrónico y en la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones.»

Dicho de otra forma, el coste de la no seguridad puede ser de 60.000€ por incidente que no sea notificado ante al AEPD (Independientemente de la sanción por incumplimiento del Artículo 9 Seguridad de los datos o 10 Deber de Secreto de la Ley 15/1999 de Protección de Datos de Carácter Personal). Si además no informas de las violaciones y lo haces de forma reiterada, te pueden caer hasta 100.000€ lo que da para destinar recursos a la gestión de vulnerabilidades técnicas y la prevención frente a ataques que pudieran suponer una violación de la confidencialidad de los datos. Por tanto, ya se puede empezar a hablar del ROSI bajo dos premisas: el coste del incidente o el coste de las sanciones.

Primeros roces con el Esquema Nacional de Seguridad: pros y contras.

Lo que hoy quiero contar son mis primeras impresiones ya algo más fundadas tras unos meses trabajando a diario con el R.D. 3/2010 de desarrollo del Esquema Nacional de Seguridad. Este post va a ser como contar el diario de una relación tras unos meses de convivencia. Bueno, empecemos.Los primeros contactos fueron ya hace un par de años con la publicación del borrador y las primeras impresiones fueron ya objeto de una primera impresiones en el post "Esquema Nacional de Seguridad, las Administraciones Públicas se ponen las pilas en la materia". Poniendo en contexto el ENS respecto a la legislación que regulaba la seguridad de la información para Administraciones Públicas, el R.D. 3/2010 es una auténtica R-evolución. Por un lado, establece un marco de trabajo correcto, alineado con las normas internacionales que se van publicando en la materia dentro de la serie ISO 27000 y por otro, establece unos criterios mínimos y esenciales que todo Organismo debe contemplar para tener sus sistemas de información en unas mínimas condiciones. Por tanto, el ENS es un impulso a la seguridad que afecta a Administraciones Públicas y a otras entidades de derecho privado que se relacionan con ellas. Dejando claro de antemano que supone una ayuda, ahora empiezo ya con las primeras reflexiones basadas en los esfuerzos de desarrollo e implantación del R.D. 3/2010.


Lo que me gusta.
Las primeras virtudes son existenciales y tienen que ver con la regulación de los denominados "Principios básicos". Estos se contemplan en el Capitulo II y se extienden desde el Artículo 4 al Artículo 10. Todos ellos son auténticas apuestas estratégicas de cuales deben ser los pilares que deben regir la gestión de la seguridad y determinan aspectos tan relevantes como:

• Seguridad como proceso holístico: todas las partes suman y por tanto, la seguridad debe verse como un proceso integral de protección que contemple todos los aspectos relacionados: físicos, lógicos, organizativos, jurídicos, de gestión y seguimiento, etc.
• Seguridad basada en la prevención, detección y reacción: Es básica la proactividad para evitar incidentes y mitigar más las vulnerabilidades que los daños.
• Gestión basada en riesgos: es necesario analizar los riesgos para determinar y decidir si las medidas son suficientes o requieren de mejoras. La gestión del riesgo debe ir proporcionando como beneficio el incremento de la madurez de los controles y la evolución lógica hacia la mejora continua. Todo ello con el soporte de otro principio básico que es la reevaluación periódica para verificar que el grado de control de los riesgos es el esperado y que las medidas de seguridad funcionan tal como se tiene previsto.
• Lineas de defensa: Las Administraciones Públicas ya contemplan como principio de diseño que deben ser capaces de resistir porque serán atacadas desde agentes externos o internos. Por tanto, la seguridad debe ser un principio a contemplar desde el diseño de los sistemas de información para contar con las medidas y controles adecuados que eviten posibles incidentes.
• Segregación de funciones en las tareas de operación y seguridad: Este principio es esencial para evitar la acumulación de privilegios y disponer de personal que pueda hacer labores de control interno sobre las áreas técnicas implicadas en el desarrollo y operación o explotación de los sistemas de información. Por tanto, aparece un área control interno que debe velar por el correcto funcionamiento de las cosas y el cumplimiento de la legislación vigente.

Todos estos principios se desarrollan en el Capitulo III a través de los "Requisitos mínimos". Estos van desde el artículo 11 al 30 y desarrollan diferentes aspectos esenciales para poder garantizar que los principios básicos se encuentran correctamente aplicados. De ellos, merecen ser destacados especialmente los siguientes artículos:

• Artículo 12- Organización e implantación del proceso de la seguridad, donde se indica que debe establecerse una política que debe identificar unos claros responsables de velar por el cumplimiento. Detras de todo esto debe haber "PERSONAS" que hagan cosas en relación con las "RESPONSABILIDADES" atribuidas. Si algo contribuye en mucho a la seguridad es determinar quién tiene que hacer qué para que no exista la sensación de que la seguridad se gestiona sola y que "alguien se encarga" aunque eso sea sólo una sensación que no se concreta en nadie físico.
• Artículo 15. Profesionalidad, donde viene a decir que quien se dedique a estos temas debe saber lo que tiene entre manos. Además, como puntilla se dice que las Administraciones Públicas deben exigir a sus terceros que cuenten con unos niveles de seguridad adecuados en relación a los servicios prestados, o sea, deben acreditar que gozan de ciertos niveles de seguridad.
• Artículo 19. Seguridad por defecto, otro elemento esencial que debe empezar a formar parte de la cultura de la seguridad que debe implantarse en las áreas TI de las AA.PP. Las cosas se protegen antes de ser expuestas en los entornos de producción.
• Artículo 23. Registro de actividad, donde determina la necesidad de disponer de trazas y registros de auditoría que permitan la investigación frente a incidentes y lo que es quizás más importante, la depuración de responsabilidades.
• Artículo 26. Mejora continua del proceso de seguridad. Este es quizás un guiño del ENS para que las AA.PP. se planteen establecer un SGSI como marco de gestión del cumplimiento del R.D. 3/2010 siendo la ISO 27001 la norma certificable que demuestra el cumplimiento de ese compromiso por la mejora.

Personalmente creo que el quíd de la cuestión respecto a cómo se cumplen estos requisitos mínimos queda establecido por el artículo 27 que voy a copiar integramente.

Artículo 27. Cumplimiento de requisitos mínimos.
1. Para dar cumplimiento a los requisitos mínimos establecidos en el presente Real Decreto, las Administraciones públicas aplicarán las medidas de seguridad indicadas en el Anexo II

1. Los activos que constituyen el sistema.
   
2. La categoría del sistema, según lo previsto en el artículo 43.
   
3. Las decisiones que se adopten para gestionar los riesgos identificados.

2. Cuando un sistema al que afecte el presente Real Decreto maneje datos de carácter personal le será de aplicación lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, y normativa de desarrollo, sin perjuicio de los requisitos establecidos en el Esquema Nacional de Seguridad.
3. Los medidas a las que se refieren los apartados 1 y 2 tendrán la condición de mínimos exigibles, y podrán ser ampliados por causa de la concurrencia indicada o del prudente arbitrio del responsable de la seguridad del sistema, habida cuenta del estado de la tecnología, la naturaleza de los servicios prestados y la información manejada, y los riesgos a que están expuestos.

Por tanto, todos estos requisitos son concretados en el Anexo II donde se encuentra el listado de medidas de seguridad que deben servir para garantizar dichos requisitos. Como se puede ver, el criterio de selección de "LO MÍNIMO" a aplicar queda establecido en el siguiente orden por:

1. El tipo de activo y su valoración de las dimensiones A-C-I-D-T
2. La categoría que corresponde al sistema de información como valoración global de los activos que contiene y que siempre será asignada atendiendo al máximo valor de los activos.
3. Las decisiones que se adopten en base a la gestión de los riesgos identificados en el proceso de análisis.

Toda esta parte filosófica y de establecimiento de las lineas estratégicas de trabajo me parecen perfectas y muy alineadas con la tendencia general que viene siendo consensuada como el marco de trabajo de la "gestión de la seguridad de la información".

Lo que no me gusta.
El primer gran problema es un tema de recursos. La seguridad por desgracia no se encuentra dentro de la cultura organizativa de las Administraciones Públicas (Al menos de las que conozco) y por tanto, este R.D. 3/2010 viene a sumar una serie de obligaciones que van a recaer sobre las áreas TI de las organizaciones que ya están bastante saturadas. Además, se añade el principio de la función diferenciada pero en general no existen "Responsables de seguridad" que tengan atribuida esa función como labor que suponga el 100% de su tiempo. Por tanto, la primera queja es que por desgracia este incremento de obligaciones no parece que venga con un incremento de los recursos y por tanto, va a costar ponerlo en marcha y más en los tiempos de crisis que han producido recortes en los presupuestos de todas las áreas TI.

El segundo gran problema son las categorías de los sistemas de información. En el ánimo de hacer sencilla la aplicación del R.D. se han establecido tres niveles de seguridad. Sin embargo, el hecho de tener que determinar un único valor para la categoría del sistema siendo éste el máximo valor de cualquiera de sus dimensiones "se carga" el principio de proporcionalidad. Si la intención es aplicar las medidas en base a los impactos o los riesgos, no tiene mucha coherencia que las medidas a aplicar se correspondan con un nivel Alto, Medio o Básico ignorando cuales son los valores de cada dimensión. Pongo un ejemplo para que se entienda claro. Si tenemos un activo que tiene una valoración Básica para la confidencialidad, integridad y disponibilidad pero Alto para la trazabilidad, ese activo tiene una valoración final de Alto. Según interpreto yo y establece así el Anexo I, la categoría final de este sistema de información será Alto. Por tanto, habrá que aplicar unas medidas de seguridad bastante fuertes a dimensiones del activo que realmente no tiene un valor de impacto alto, lo que contradice el principio de proporcionalidad que trata de poner más resistencia en las partes que son más importantes pero no generalizarlo para todo. Por tanto, esta necesidad de hacer sencilla la asignación de niveles contradice el aplicar más seguridad en las partes más importantes y puede incluso ir en contra de la filosofía basada en riesgo. Cuando un sistema tenga un activo de nivel alto, tendrá que aplicar TODAS las medidas del ENS y por tanto, será raro que además de ellas tenga que añadir alguna más para mitigar riesgos.

El tercer gran problema que además agrava mucho mas el tema de las categorías está en cómo se han establecido los criterios de valoración de los activos. En el Anexo I, punto 3 se determina que la valoración de los activos se realiza atendiendo al daño causado a la organización para:

• alcanzar objetivos.
• proteger activos a su cargo
• cumplir con las obligaciones diarias de proporcionar servicios.
• respetar la legislación vigente.
• respetar los derechos de las personas.

Es lógico que en la valoración se contemplen aspectos legales, operativos, económicos o de carácter organizativo. Sin embargo, el gran problema está en la descripción que ha sido redactada para estas escalas de valoración en los tres niveles establecidos.
Por poner un ejemplo, a un responsable de servicio o responsable de información se le deberá preguntar qué consecuencias tiene un incidente que afectara a la confidencialidad. Por tanto, debe determinar si supone un perjuicio limitado, grave o muy grave. Sin embargo, la justificación de estos tres grados se corresponde con las siguientes frases:

• BAJO: El incumplimiento formal de alguna ley o regulación, que tenga carácter subsanable.
• MEDIO: El incumplimiento material de alguna ley o regulación, o el incumplimiento formal que no tenga carácter subsanable.
• ALTO: El incumplimiento grave de alguna ley o regulación.

Estas frases abiertas y poco concretas por ser ausentes de contexto pueden dar lugar a diferentes interpretaciones y dificultan de forma extrema el seleccionar un valor que no dependa del criterio personal de quien valora. Además, los valores establecidos en las diferentes escalas deberían ser similares para que el nivel alto represente un tipo de incidente de gravedad similar en todas las escalas. Para representar esto segundo imaginemos que sobre un activo se diera un incidente que supusiera una infracción grave de la LOPD. Según el criterio de valoración sería un activo de nivel ALTO. Sin embargo, si miramos qué valores tiene el nivel alto en el resto de escalas tenemos la anulación de la capacidad de la organización para atender sus obligaciones o el perjuicio grave a un individuo de difícil reparación. No parecen del mismo rango los daños en las tres escalas y si a eso sumamos que por un problema de confidencialidad. Aun así, si consideramos que el hecho es grave, por el razonamiento anterior para proteger la confidencialidad del activo, se van a tener que aplicar medidas muy duras relacionadas con el resto de dimensiones.

El cuarto y quizás también muy relevante es que no se ha definido un organismo supervisión que vele por garantizar el cumplimiento ni se atribuye un régimen sancionador debido al incumplimiento. Al menos, para consuelo de todos, el Artículo 41. Publicación de conformidad establece lo siguiente:

Artículo 41. Publicación de conformidad.

Los órganos y Entidades de Derecho Público darán publicidad en las correspondientes sedes electrónicas a las declaraciones de conformidad, y a los distintivos de seguridad de los que sean acreedores, obtenidos respecto al cumplimiento del Esquema Nacional de Seguridad.

Según  se puede ver, todos los Organismos debieran decir en su sede electrónica cual es su declaración de conformidad respecto al cumplimiento del ENS y cualquier otro distintivo que acredite gestión de la seguridad como pudieran ser las certificaciones ISO 27001. En la Web del CCN-CERT hay incluso colgado un documento a modo de ejemplo de la redacción que debería tener esa declaración y que os animo a consultar en este enlace.  La base por la que se declara la conformidad con los requisitos esenciales del ENS, es la superación en conformidad de la evaluación efectuada, realizada por el Responsable de Seguridad, mediante la elaboración de un dictamen técnico en el que se señale, de forma expresa, que el sistema a que se refiere es conforme al Esquema Nacional de Seguridad.Esta información debiera estar colgada en la sede para que el ciudadano pueda comprobar que la Web de ese organismo goza de las medidas de protección adecuadas y por tanto, le genere la confianza que es el fin último por el que se ha desarrollado el ENS. Por tanto, no existe una Agencia supervisora que determine quién está en condiciones de dar servicios telemáticos y quien no pero al menos obliga a todas las AA.PP. a publicar una declaración donde digan que superan las medidas de seguridad. Por tanto, si hubiera un incidente se podría saber quién es el responsable en base a detectar qué medidas de las aplicadas fallaron.

Para terminar, os planteo un reto. Del directorio de Sedes que se publica en la Web del 060.es, mirar cuantas dan cumplimiento al citado artículo 41 y disponen de la publicación de conformidad. El listado está accesible aquí. Si encontráis alguna, indicarlo en los comentarios porque yo por más que busco, no encuentro...

Cumplimiento del Esquema Nacional de Seguridad con tecnologías Microsoft

Hoy tengo buenas noticas. Vía el twitter de Hector Montenegro me he enterado que Microsoft, como viene siendo tradicional respecto al cumplimiento legal, ha publicado un excelente libro (Descargable de forma gratuita en la Red en este enlace ) sobre cómo garantizar el cumplimiento del R.D. 3/2010 de desarrollo del Esquema Nacional de Seguridad mediante tecnologías Microsoft.

A falta de poder realizar una lectura en profundidad que ya es mi primera tarea en el To-do de estos días, por lo que he podido mirar por encima, tiene muy buena pinta. Precisamente llevo este último mes completamente sumergido con el ENS elaborando un plan de adecuación y hoy habíamos terminado el diagnóstico diferencial del grado de cumplimiento siguiendo la guía 808 - Verificación del cumplimiento de las medidas en el Esquema Nacional de Seguridad. Este libro va a ser de gran ayuda seguro porque muchas de las medidas que son completamente razonables siempre plantean problemas de implementación. Suele ser habitual encontrarse en AA.PP. también que la gestión de usuarios y equipos esté delegada en Directorio Activo por lo que el libro va a resolver muchas cuestiones técnicas a muy bajo nivel.

En mi caso, entiendo que para elaborar el informe de deficiencias es necesario que la Organización valore, siguiendo la guía de auditoría y no la guía de implantación, cual es el porcentaje de cumplimiento, con el objetivo de generar un plan de actuación que logre implantar las medidas al 100% generando así las evidencias suficientes para justificar el cumplimiento. La sensación general cuando hablamos de seguridad de la información en AA.PP. es que falta un largo camino por recorrer. En general, cuando cuentas las medidas de seguridad todo el mundo las valora como razonables, deseables, etc... pero son consideradas más deseos que requisitos. Además, por desgracia, la seguridad de la información no cuenta como área con personal propio y estas movidas o caen a la gente de sistemas o a la gente de comunicaciones, personas que ya de por si tienen a sus espaldas bastante trabajo. A ello se suma la actual coyuntura económica que pone bastante dificultades a la viabilidad de los proyectos necesarios para que el cumplimiento sea garantizado.

En cualquier caso, hoy toca alabar a Microsoft por esta excelente iniciativa que va a facilitar mucho a los responsables de TI de muchas organizaciones el resolver la problemática relacionada con el cumplimiento. Por desgracia los consultores les decimos lo que habría que hacer y les asesoramos en cuales son los motivos y los objetivos a lograr. Microsoft como fabricante además les va a decir en este libro cómo lograrlo y hacerlo real.

Quien a estas alturas no tenga muy localizado de qué estoy hablando, os dejo también el enlace a la Web del Centro Criptológico Nacional donde se están publicando las diferentes guías de ayuda a la puesta en marcha del CCN.

Al Centro Criptológico Nacional también hay que alabarle el esfuerzo por concretar y asesorar a las AA.PP. en el duro camino de implantar seguridad de la información. En este caso además, el CCN no ha permitido con la publicación de estas guías que exista ambigüedad interpretativa y ha marcado unas directrices claras respecto al qué hacer y por qué. En algunas organizaciones se ven estos temas como de otra galaxia pero al igual que la LOPD, esto es legislación y por tanto, de obligado cumplimiento.

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.

Incidentes de seguridad y su gestión mediática.

Tal como podía imaginar, la llegada al mundo de mis dos hijos ha limitado y reducido a la mínima expresión el tiempo libre que puedo dedicar a mi "yo online" siendo este blog y twitter sus máximos exponentes. Comentado esto a modo de disculpa por la latencia entre post de estas últimas semanas, vamos al grano con la reflexión de hoy.

Esta semana los medios de comunicación se han hecho eco de noticias suculentas sobre incidentes y accidentes de seguridad que han afectado a Sony (El caso del supuesto hacking a la base de datos de la Playstation) o Apple (la polémica con el almacenamiento de datos de geoposicionamiento).

En ambos casos, lo que me sorprende es esa errática estrategia del avestruz que trata de esconder la cabeza hasta que es tan notoria la noticia y de tal cobertura que parece les obliga a salir a informar de los hechos acontecidos. Digo que me sorprende por el siguiente motivo: cuando se habla de "continuidad de negocio" y el análisis de impacto, uno de los criterios de valoración de daños suele ser precisamente el deterioro en imagen o daño reputacional.  Muchas veces es peor lo que se comenta sobre un incidente que los propios hechos acontecidos. Tenemos aquí el celebre caso de Mr Bean en el portal de la presidencia española como un claro ejemplo que ya comenté en su momento.

Sin embargo, la lentitud en salir a comunicar o al menos, a informar sobre la información que en esos momentos se encuentre circulando creo particularmente que agrava el problema y más en los tiempos que corren donde la velocidad de transmisión de noticias a través de foros, redes sociales y Webs obligan a trabajar casi en tiempo real.

Y lo empeora porque el silencio parece a veces (o casi siempre) que trata de evitar o encubrir el reconocimiento de un fallo de seguridad o un error de programación. Esa manía por no ver un tropiezo como una oportunidad de mejora o un aprender de los errores hace que la opinión pública entienda como más responsable o negligente a la empresa u organización afectada.

La transparencia en estos casos creo que es la mejor solución. Y si hay errores, el reconocimiento y la petición de disculpas una estrategia que puede aliviar o limitar el grado de enfado de los clientes o potenciales clientes que puedan verse afectados por el incidente.

¿Qué tiene esto que ver con la gestión de la seguridad o la continuidad de negocio?

La continuidad de negocio tiene por objetivo garantizar el funcionamiento normal de la empresa cuando se sufre un incidente. Sin embargo, creo que es una herramienta útil también para este tipo de casos donde hay un "impacto reputacional" que aun no afectando a la operación de los sistemas, si debe al menos, desencadenar una "Gestión de la crisis" previa a la decisión de activar el plan de continuidad. Cuando una organización ha sufrido un incidente, de repente tiene activos diferentes frentes de trabajo donde debe tratar de volver a la normalidad. Las áreas suelen ser la logística si hay daños en instalaciones, los servicios TI si el incidente afecta a los sistemas de información, la gestión del personal si este debe modificar sus rutinas diarias y la gestión mediática.

Es precisamente este aspecto el más relevante porque como he dicho ya antes, a veces es mayor el ruido que las nueces. La contención mediática debe procurar informar rápido, ser origen de la información para evitar especulaciones o rumores e ir aclarando los hechos con la máxima transparencia que sea posible, a fin de demostrar al menos una diligencia en la comunicación del incidente. Por tanto, el equipo de comunicación de una gran empresa como las que se han visto afectadas deben saltar a las primeras de cambio y proporcionar información aún cuando todavía se desconozcan los detalles de lo acontecido para demostrar que no se esconden y que darán las explicaciones que sean oportunas conforme se vayan esclareciendo los hechos. Las áreas de comunicación y las áreas afectadas por el incidente que suelen ser TI deben colaborar y trabajan conjuntamente para suministrar casi en tiempo real todos aquellos aspectos o datos que vayan siendo conocidos de forma que se vayan tranquilizando las versiones o rumores sobre los hechos. No hay mejor medida de seguridad frente a rumores que ser fuente de la información. Pero eso es ya "Gestión del riesgo reputacional" y pertenece a otras áreas de conocimiento menos tecnológicas.

También como apunta de forma certera y ácida Sir Chema Alonso esta semana, depende de quién seas, ciertos incidentes o problemas se disculpan. El público es más bondadoso con las empresas "cool" o "guays" y despiadado con las empresas que vienen del lado del mal. Diferente rasero para idénticos incidentes... pero supongo que detrás de eso también están los equipos de comunicación de esas empresas que usarán esa estrategia a modo de "airbag". Venden una imagen que aguanta más impactos reputacionales porque los clientes le atribuyen otras bondades que contrarrestan los daños sufridos. Como siempre, Dilbert dispone de una viñeta apropiada al respecto.

Lo que está claro es que la "reputación" es también un activo de la empresa a proteger porque detrás de él se refugia la confianza de nuestros clientes. Y como dice el proverbio, "La confianza viene en tortuga y se va en el galope de un caballo".

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.

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.

Los errores informáticos, ¿Deben pagarse?

"Nadie es perfecto: los errores de los cocineros se tapan con mayonesa, los errores de los albañiles se tapan con cemento y los errores de los médicos se tapan con tierra". Esta frase atribuida a Frank Lloyd Wright va a ser el origen del post de esta semana.

Todo parte de una noticia que guardé hace unos días (vía Instapaper que recomiendo usar a aquellos que quieren mejorar su productividad y no verse arrastrados por la navegación compulsiva) donde David Rice, nuevo responsable de seguridad de Apple plantea un impuesto sobre vulnerabilidades como idea para la mejora de la seguridad del software.

Esta propuesta no es nueva y forma parte del discurso de Bruce Schneier que siempre habla de la "economía de la inseguridad". Su planteamiento viene a explicar que la filosofía con la que la industria en general trabaja es el pago por los efectos de la inseguridad, sin atajar la esencia del problema.

Lo curioso del tema es que realmente no se sabe si este enfoque resulte económicamente más rentable que intentar fortalecer la seguridad desde el diseño. Microsoft a base de sufrirlo en sus propias carnes decidió cambiar radicalmente su filosofía y paso a una "seguridad por defecto" como planteamiento de diseño. Y las cosas se hicieron bien desde el principio, atacando el problema desde la raíz, en el proceso de construcción del software. Fruto de aquello, hoy utilizan y aplican la metodología de desarrollo seguro SDLC de la que ya he hablado en este blog en más de una vez.

Lo que sí creo es que empieza a llegar un momento en donde debiera plantearse el proceso industrial de la Ingeniería en Informática, estableciendo unos requisitos mínimos a cumplir y unas garantías mínimas exigibles a los productos hardware o software que se lanzan al mercado. Y no garantías físicas respecto a la seguridad industrial del producto (consumo, rendimiento eléctrico, etc.) sino garantías respecto a los aspectos programados por el software, atribuibles al código que se ejecuta en el dispositivo.

Porque hay una cosa clara, mientras el error o fallo no afecte directamente a la cuenta de resultados de la Empresa que lo causa o genera, la Industria no cambiará. Esa "cláusula comodín" del software que lo primero que dice es que se encuentra ante un producto del que no es exigible ningún tipo de responsabilidad se tiene que acabar. En otras áreas de la Industria se realiza un esfuerzo enorme por garantizar la robustez y fiabilidad de los productos y la Informática no está todavía por desgracia a esa altura. Sólo hay que pensar en las disciplinas asociadas a la seguridad de los materiales de construcción, la seguridad del automóvil, etc... para darse cuenta de lo importante que es el diseño seguro. Las cifras de Gartner estiman que costará alrededor de $ 1 millón al año en promedio para una empresa con entre 2.500 y 3.000 máquinas la aplicación de parches de software.

Las noticias recogidas en prensa dan tal sensación de cotidianidad a este tema que tenemos más que asumido el "error informático" como parte del precio que hay que pagar por el alto desarrollo industrial. Obviamente la complejidad de los sistemas va en aumento y la torre de cartas es cada vez más alta, lo que hace que cualquier problema en una de ellas tenga consecuencias. En cualquier caso, la dificultad no debe ser nunca excusa para no abordar el problema. Hay incidentes que sí tienen una culpabilidad clara y que si debieran penalizar a la empresa que lo genera. Esta semana también ha sido conocido el problema de seguridad de los "Cargadores USB Energizer" que incluyen de regalo un troyano.
No nos damos cuenta pero hay software por todos lados, incrustado sobre hardware o desarrollado sobre sistemas operativos pero casi todo los electrodomésticos están transformándose en "inteligentes" debido al software de control que llevan embebido. Y pronto cada uno de estos cacharros tendrá una IP. ¿Tendremos que ver cómo una oleada de malware inutiliza los frigoríficos de medio mundo para tomarnos en serio esto de considerar como fase indispensable del diseño a la "seguridad".

"Nadie es perfecto: los errores de los cocineros se tapan con mayonesa, los errores de los albañiles se tapan con cemento y los errores de los medicos se tapan con tierra". En el futuro habrá que añadir, "Los informáticos lo tienen más facil, basta con apagar y volver a encender para solucionarlo". Así nos ve la sociedad y así nos paródia como se puede ver en la serie "Los Informáticos". Es triste pero es nuestra realidad. Lo que más duele es que en otras áreas y disciplinas jamás se habría dado lugar a esta situación, pero como la "Informática" no es una "Ingeniería real" como el resto y no tiene atribuciones profesionales, pues así estamos. Sabemos que "la informática es una ciencia", "un arte" y en el futuro "una religión". Habrá que creer y tener fe en ella para que las cosas funcionen.