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.