Personas, confianza y cloud computing

La reflexión de hoy va a ser breve porque ha sido un día intenso. Ayer casi por casualidad leí en el muro de Facebook de un compañero una reflexión sobre cuales son los pilares que usamos las personas para construir la confianza en otras personas. En palabras de Jose María Gasalla, conferenciante, escritor y profesor de la Deusto Business School, la confianza que dan, depositan o generan las personas se sustenta sobre 7 pilares:

• Consciencia: entender a las partes implicadas y la situación en la que se encuentran.
• Claridad: compartir la realidad y obviar resto.
• Coherencia: predicar con el ejemplo, hacer a cabo aquello que piensas y dices.
• Consistencia: dar cuerpo a los valores que te representan.
• Cumplimiento: alcanzar con garantías los compromisos generados.
• Competencia: representar la profesionalidad, hacer las cosas bien.
• Coraje: ir más allá, hacer lo extraordinario. 

Hoy tocaba hablar con los compañeros de Isaca e Itsmf Valencia sobre la cloud en una mesa redonda y ayer pensaba si esto no sería aplicable también a la confianza en general que aplicamos sobre las cosas. En la mesa redonda la primera pregunta de Nuria Lago ha sido precisamente que qué pediríamos a una empresa en la cloud y mi instinto directamente ha respondido "Confianza". Aunque no se si he podido expresarlo bien, quiero compartir mi traducción de los pilares anteriores de la confianza cuando nos referimos a la cloud.

• Consciencia: entender a las partes implicadas y la situación en la que se encuentran, es decir, que tanto cliente como prestador del servicio de cloud sean conscientes del rol que representan cada uno y de las delimitaciones de responsabilidad que deben establecerse en la prestación del servicio. De esa forma en caso de conflicto se conocerá la linea que separa la responsabilidad de las partes y se juzgará con mayor precisión quién cometió el error.
• Claridad: compartir la realidad y obviar resto. Esto en este contexto debería ser traducido por transparencia y sería un ejercicio del prestador por informar e incluso poder representar los niveles de servicio mediante gráficas de forma que se pueda acreditar el cumplimiento. Algo como las gráficas de consumo a las que estamos tan acostumbrados en los recibos de luz, teléfono o gas pero llevado al contexto del SLA firmado con el proveedor de cloud.
• Coherencia: predicar con el ejemplo, hacer a cabo aquello que piensas y dices. Esto estaría relacionado con ser ejemplo también en materia de gestión TI y disponer de las acreditaciones en materia de buenas prácticas más adecuadas para demostrar a tus clientes que eres capaz de hacerlo bien y además estás comprometido con la mejora continua.
• Consistencia: dar cuerpo a los valores que te representan. En los temas de la cloud el término más adecuado podría ser resiliencia, es decir, la garantía de robustez del servicio para tener claro que si ocurriera algún incidente el proveedor dispone de un plan B para no dejarte tirado o al menos, que el RTO sea el pactado.
• Cumplimiento: alcanzar con garantías los compromisos generados. Esto estaría también vinculado a la transparencia y sería la demostración mes a mes de los cumplimientos en las gráficas anteriores de los acuerdos de nivel de servicio o bien asumir las consecuentes penalizaciones en caso de cualquier incumplimiento.
• Competencia: representar la profesionalidad, hacer las cosas bien. Fruto de la coherencia y de la aplicación de las buenas prácticas de Gobierno TI deberían llegar los resultados. Los sellos, si se cree en ellos y se aplican con rigor, deben lograr objetivos planteados y deben suponer una mejora progresiva de resultados.
• Coraje: ir más allá, hacer lo extraordinario. Este sería quizás el término más dificil de ajustar pero que podría estar relacionado con buscar la excelencia y podría enmarcarse dentro de ese compromiso de mejora continua. Además, dada la volatilidad de las tecnologías que se emplean, un proveedor debe garantizar los servicios que ofrece en el día a día y pensar en los que querrá ofrecer o podrá mejorar en el futuro. Aquellos proveedores cloud que estén mirando siempre al futuro serán seguramente los que mejor se adapten a los continuos cambios en el área TI. Esa plasticidad o elasticidad que hace al bambú ser resiliente, ser capaz de adecuarse en todos los contextos y permanecer siempre recto.

En breve postearé un Seguridad y las nubes II con un análisis de pros y contras que había anotado fruto de los distintos documentos que había leído para preparar la mesa redonda de hoy, pero eso será ya para  otro día que esté mas fresco.

Enlaces a mis cuatro webinars gratuitos de seguridad (Actualización 01-02-2012)

Llevo un par de meses participando en unos seminarios Web (webinars) gratuitos impartidos por Bureau Veritas Business School. En los tres casos he podido comentar aspectos relacionados con la seguridad de la información tanto en el ámbito de la norma ISO 27001 como en el del R.D. 3/2010 del Esquema Nacional de Seguridad. Los títulos y enlaces son los siguientes:

• Fases de implantación de un Sistema de Gestión de la Seguridad de la Información (SGSI)
• Elaboración del Plan de Adecuación al ENS 
• La continuidad de servicio en el Esquema Nacional de Seguridad (ENS)
• Cómo debe ser un Sistema de Gestión de la Seguridad de la Información conforme al Esquema Nacional de Seguridad. (Actualizado 01-02-2012)

También son muy recomendables los seminarios que ha grabado mi compañera Nuria Martínez (en Twitter @numarfer) sobre la problemática de protección de datos en problemas concretos y comunes. Sus seminarios y enlaces son:

• La protección de datos en la gestión de Recursos Humanos
• Protección de datos personales en las actividades de publicidad prospección comercial
• La protección de Datos en la gestión de los clientes

La duración aproximada de todos ellos es de unos 35 minutos y en su contenido tratamos de volcar nuestra experiencia y conocimiento sobre los temas en los que somos consultores.

Materiales de concienciación en seguridad de ENISA

Aunque ENISA publicó los materiales que hoy os comento hace tiempo, me parece interesante darlos a conocer para todos aquellos que os planteáis cómo mejorar la concienciación del personal de forma una forma sencilla y atractiva.

En la sección de Concienciación se han elaborado una serie de cómics y fotografías que permiten transmitir mensajes muy claros y directos sobre las pautas y hábitos que todo buen empleado debe seguir para la adecuada protección de la información.

• En Illustrations — ENISA podéis ver las viñetas que además están disponibles en castellano.
• En Posters-ENISA podéis ver las fotos y posters.

Estas referencias también os pueden ser de ayuda y ejemplo para pensar cómo elaborar vuestros propios materiales con las problemáticas propias de vuestras organizaciones.

Conocimiento inducido y la pandemia del "cut&paste"

Aunque últimamente no puedo publicar demasiado, hoy he podido sacar un hueco para hacer bloggerterapia. Lo que vengo a contar es una pandemia que tiene como consecuencia la poca valoración que se da al contenido y que hace pensar en si realmente somos la "sociedad del conocimiento". Vivimos inmersos en la sociedad más tecnificada que ha existido con acceso casi inmediato e independiente de dónde nos encontramos y sin embargo se produce una paradoja curiosa, justo en el momento en que más información tenemos disponible es cuando creo que peor la estamos procesando. Estamos tan saturados e inundados que la escala de procesamiento que empieza en los datos, se organizan como información, se transforman en conocimiento y supone adquirir sabiduría hace que no podamos masticar ni conocimiento ni información quedando solo como meros datos, lo que podemos denominar como "infoxicación".

¿A qué viene todo este rollo previo? Lo que trato de contar es la experiencia personal que sufro en ciertos proyectos donde participo como consultor de seguridad para el desarrollo de un marco normativo (normas y procedimientos de seguridad) basados en la ISO 27001. Parte de mi trabajo consiste en asesorar o recomendar la forma de hacer efectivas las medidas de seguridad que requieren los sistemas de gestión de la seguridad de la información. Hace ya mas de cuatro años participé en el proyecto de construcción de un SGSI y como mi experiencia y conocimiento se centra más en los aspectos formales de la gestión y de la formalización de las medidas, desarrolle un conjunto de normas básicas de seguridad (que establecen las restricciones o requisitos que la organización quiere cumplir) y un conjunto de procedimientos que los implantan (definen las tareas, actores y registros de ejecución que deben implantarse). Este tipo de proyectos se ha venido repitiendo en los últimos años y por tanto, la documentación inicial ha ido mejorando, evolucionando y completándose para hacer de ella un marco maduro y bastante completo de más de doscientos folios.

Sin embargo, lo que más me sorprende últimamente es el poco "valor percibido" que se dan a esos documentos por parte de nuestros clientes. Ellos no han tenido que enfrentarse al temible "folio en blanco" y por tanto, no pueden valorar lo complejo del proceso creativo que supone leer la norma ISO 27002 e imaginar cómo hacer algo real y ejecutable su cumplimiento. Ellos se limitan en muchos casos a cambiar logotipos, modificar las responsabilidades y con eso, suponen que adquieren y reciben el conocimiento inducido que cada documento tiene tras de sí. El algunos casos, la redacción de un solo documento ha podido costar más de dos semanas de trabajo y sin embargo, la adaptación en su organización es cuestión de horas. En parte este es el servicio que se proporciona en un proyecto así y es el valor que aporta la consultora.

Lo que falla por parte de los clientes es, en muchos casos, que ese conocimiento inducido no es procesado, no es adquirido ni asimilado y el desarrollo del marco normativo se limita al "cut&paste" de las "formas" sin procesar el "fondo". Nuestro conocimiento en forma de plantilla de documento requiere de un esfuerzo por integrar en la realidad de cada cliente cómo hacer las cosas. Es cierto que al basarnos en estándares, lo que hay que hacer está mas o menos definido y es lo que nos ha permitido formalizar con carácter general los controles, pero hay cierto margen de libertad que permite a cada cliente adecuar a su contexto los controles. Sin embargo, no hay en muchos casos esa reflexión madura de tratar de entender qué persigue el control, que plantea el documento-plantilla y qué finalmente será la redacción particular que deberá tener el procedimiento integrado en la organización.

En el fondo, a nuestro marco normativo le ocurre como a otras muchas cosas de esta cultura del "cut&paste". Quiere ser publicado y utilizado rápidamente pero no es masticado, generando un marco normativo que no es ni siquiera conocido por el área responsable de su difusión y ejecución. Y es que comprar un documento no es comprar conocimiento, es simplemente adquirir una base bastante desarrollada que permite tomar rápidamente las decisiones más oportunas para poder lograr implantar un control. Sin ese esfuerzo de moldear y particularizar el documento al contexto y a la realidad de cada cliente, las cosas quedan muy cojas, produciéndose cierta "infoxicación" en materia de seguridad. El marco documental está constituido por 11 normas (una por bloque para tener claro en qué documento se regula qué aspecto de la seguridad, de acuerdo con lo establecido por ISO 27001) y unos 30 procedimientos (con las tareas operativas que hay debajo de muchos de los 133 controles de la norma). Un total de unos 200 folios que se ven como un ladrillo si no se tiene claro que se quiere hacer con ellos y por qué. Sin embargo, para quien tiene claro qué necesita, permite formalizar y documentar perfectamente el marco normativo que quiere aplicarse a la información y hacerlo en relativamente muy poco tiempo (a tiempo completo, en un mes se puede tener todo adaptado). La documentación ha sido desarrollada basándose en la norma (pero sin ser un copia y pega de la misma sino una interpretación práctica) bajo un criterio de máximos (Se redactó pensando en disponer de las mejores y más restrictivas medidas de seguridad para que los clientes borren o eliminen aquello que no pueden cumplir o no van a implantar). Sin embargo, este potente armamento necesita de un soldado hábil que conozca lo que la norma dice y lo que él quiere hacer real. De lo contrario, se transforma en un texto que se interpreta como ley y del que da miedo borrar cosas siendo visto más como un obstáculo que como una ventaja competitiva. Y esa distorsión de la percepción es causada principalmente por no haber tenido que sufrir la dura batalla de luchar contra el folio en los primeros momentos y no saber cuanto hay que sudar la camiseta para tener una norma o procedimiento en condiciones.

Casualmente poco después de haber posteado este artículo, he podido ver en la televisión el nuevo anuncio del Audi A7 que viene a expresar algo parecido, el poder de la hoja en blanco.



Nuestra sociedad va tan deprisa que apenas valora lo complejo que es producir o crear y sólo se limita a localizar o utilizar. Sin embargo, para "generar" o "crear" se requiere talento y conocimiento. Para "localizar" o "utilizar" sólo se requiere habilidad. El camino de la creación siempre conduce hacia la sabiduría. El de la utilización o uso puede que acabe en el mismo sitio pero no tiene porqué ocurrir siempre.

Para terminar en positivo, creo interesante que veáis las reflexiones de Alfons Cornellá sobre qué es la "Infoxicación".

Cómo sobrevivir a la Infoxicación, por Alfons Cornella

.

Como recomendación, creo interesante que leáis también a Berto Pena y sus dos magníficos post sobre "la Dieta de información" (Leer en ThinkWasabi los post I y II).

Este verano, como parte de las tareas de mejora de mi productividad personal pasé varios días reordenando mis subscripciones RSS en Google Reader agrupándolas en los 5 temas que más me interesan y poniendo además la etiqueta LD (lectura diaria) y LS (Lectura semanal) como sufijos. Además, decidí que una vez que la etiqueta caduca, doy el contenido por procesado, marcando como leído esos contenidos y eliminando esa tarea semanal de mi agenda. Si no lo puedo procesar, no puede figurar entre mis asuntos como pendientes. Tampoco es viable o posible estar al tanto de todo y prefiero, cuando tengo un momento, dedicarle un rato a lo que considero imprescindible antes que andar buceando en miles de entradas pendientes que no voy a poder masticar como es debido. Prefiero la "calidad del procesamiento" a la "cantidad" aunque pueda sacrificar el estar al tanto al menos de oídas de cómo van las cosas. He cambiado el hojear por el procesar, de acuerdo también al tiempo máximo que estoy dispuesto a dedicarle a esa tarea dentro de mi día a día. Es importante para mi pero no es mi trabajo ni mi máxima prioridad.

Publicada la norma ISO/IEC 27003, Guía de implantación de un SGSI

Tenemos otra norma nueva dentro de la serie 27000. Esta vez se trata de una de las importantes dado que ISO/IEC 27003,Information technology -- Security techniques -- Information security management system implementation guidance es la guía de implantación de un SGSI.

Esta norma viene bien tanto para aquellos que quieren lanzarse a montar un SGSI por su cuenta como a nosotros los consultores , dado que resuelve algunas de las cuestiones que hasta la fecha carecían de un criterio normalizado.

ISO / IEC 27003:2010 se centra en los aspectos críticos necesarios para el éxito del diseño e implementación de un Sistema de Gestión de Seguridad de la Información (SGSI) de acuerdo con la norma ISO / IEC 27001:2005. Se describe el proceso de especificación del SGSI y el diseño desde el inicio hasta la elaboración de planes de ejecución. En él se describe el proceso de obtener la aprobación de la gestión para implementar un SGSI, se define un proyecto para implementar un SGSI (denominado en la norma ISO / IEC 27003:2010 como el proyecto de SGSI), y da pautas sobre cómo planificar el proyecto de SGSI, resultando en una SGSI proyecto final de ejecución del plan. La publicación se realizó a primeros de este mes y a continuación detallo la estructura del contenido que recoge la norma.

1. Scope

2. Normative references

3. Terms and definitions

4. Structure of this international standard

5. Obtaining management approval for initiating an ISMS project

6 Defining ISMS scope, boundaries and ISMS policy

7 Conducting information security requirements analysis

8 Conducting risk assessment and planning risk treatment

9 Design the ISMS

Annex A: An ISMS implementation checklist

Annex B: Roles and responsibilities for information security

Annex C: Information about internal auditing

Annex D: Information security policy structure

Annex E: Monitoring and measuring the ISMS

Sin duda, una norma que hay que comprar y tener como referencia técnica ahora que por fin tenemos un criterio internacional sobre algunos aspectos algo difusos del proceso de diseño e implantación de todo SGSI.

Formación online del INTECO sobre SGSI

El INTECO acaba de publicar información sobre un Curso introductorio a los Sistemas de Gestión de la Seguridad de la Información (SGSI) según la norma UNE-ISO/IEC 27001. En él se darán a conocer los conceptos básicos necesarios para introducir al usuario en la gestión de la Seguridad de la Información, así como conocer la dimensión y alcance que suponen la implantación, certificación y mantenimiento de un Sistema de Gestión de Seguridad de la Información en una Organización, en base a la norma ISO/IEC 27001.
La duración del mismo es de 20 horas y el coste gratuito.


También se puede acceder a información online entre la que destaca una acción formativa basada en flash donde se puede poco a poco ir profundizando sobre la norma y la implicación de aventurarse a montar un SGSI. Aunque no me ha dado tiempo nada mas que a verlo por encima, tiene una pinta excelente, con gráficos muy claros y una extensión suficiente para ser un buen arranque en esta materia. A continuación podéis identificar enlaces a las partes de este material.

• Acceso a los conceptos más importantes: Conceptos de un SGSI.
  El Sistema de Gestión de la Seguridad de la Información (SGSI) en las empresas ayuda a establecer estas políticas, procedimientos y controles en relación a los objetivos de negocio de la organización, con objeto de mantener siempre el riesgo por debajo del nivel asumible por la propia organización. Para los responsables de la entidad es una herramienta, alejada de tecnicismos, que les ofrece una visión global sobre el estado de sus sistemas de información, las medidas de seguridad que se están aplicando y los resultados que se están obteniendo de dicha aplicación. Todos estos datos permiten a la dirección una toma de decisiones sobre la estrategia a seguir.


• Acceso al videotutorial: formación.
  Para la concienciación y sensibilización de las PYMES en los Sistemas de Gestión de la Seguridad de la Información (SGSI) se han elaborado una serie de materiales que ayudarán a las PYMES a conocer mejor este tipo de sistemas y qué conlleva su implantación y certificación.
  
  En primer lugar, se ha elaborado un video-tutorial que ayudará a los usuarios a comprender de manera sencilla qué es un SGSI y las fases que contempla su implantación y su certificación.
  
  La duración total del video-tutorial es de, aproximadamente 1 hora, dando la posibilidad al usuario de su visualización total o parcial, en módulos de unos 5 minutos.

Microsoft dando ejemplo en la nube mediante ISO 27001

Leo vía Joseba Enjuto una noticia sobre la implantación por parte de Microsoft de un sistema de gestión de la seguridad de la información sobre sus servicios en la nube.

Es una buena noticia por varios motivos. El primero es la consolidación de la norma ISO 27001 como una referencia en materia de seguridad de la información. Los estándares internacionales son buenas intenciones que normalizan un conjunto de criterios en base al conocimiento de los expertos que colaboran en su desarrollo. Sin embargo, su éxito debe darlo el mercado. Hasta que no se transforma en una herramienta de valor o de diferenciación y no goza del reconocimiento por parte de los demás, no son una referencia o estandar "de facto". En materia de seguridad es cierto que no existen códigos de buenas prácticas que sean tan generales o tan aplicables, pero que las grandes empresas apuesten por ellos siempre son un catalizador para el mercado. Esta vez España no queda atrás, dado que las principales empresas que lograron con éxito sus certificaciones ISO 27001 han sido los servicios TI de las grandes empresas de administración y gestión de sistemas de información bajo servicios de outsourcing. Por poner varios ejemplos, tenemos entre las grandes las siguientes referencias:

• Telefónica Empresas, como una de las primeras.


• El centro de operaciones de Oesía.


• T-Systems ITC Iberia S.A.U.


• Siemens AG


• Unitronics Comunicaciones S.A.U.


• IBM IT Delivery Spain

El resto de empresas que lo han logrado se pueden consultar en la Web ISO27001 Certificates aunque esta no es una Web oficial.

El segundo es ver cómo Microsoft desde hace ya algunos años (quizás desde la catarsis que supuso Milenium) ha decidido siempre apostar por la coherencia y contar las cosas desde el ejemplo. He asistido a presentaciones técnicas donde siempre muestran cómo lo hacen ellos primero y luego resuelven el problema en un cliente concreto. Creo que es una muy buena apuesta, dado que al ser los primeros en sufrir los problemas, son también los primeros en detectarlos y corregirlos. También es interesante ver cómo se abre a los nuevos tiempos y comparte una ingente información de gran calidad tanto a nivel técnico como a nivel estratégico. Y en esto de la nube no quieren quedarse tampoco atrás. En este nuevo escenario, como ya hemos comentado en este blog, la confianza es un elemento que aporta clientes, mostrar y sobre todo demostrar diligencia y seriedad son siempre un buen argumento comercial.
La noticia original, para aquellos que quieran investigar o buscar argumentos anti-Microsoft puede leerse en Microsoft seeks ISO security certification for its cloud services y para los más exigentes, incluso pueden revisar los post de este blog o leer este excelente whitepaper sobre cómo han logrado implantar la ISO 27001 donde también se dan muchos más detalles, incluso del alcance del SGSI.



Con dos cojones (con perdon), han publicado los alcances de todos los centros certificados en relación a los servicios de la nube. Esto si es tenerlos bien puestos.

Estas son las políticas de transparencias que requiere la nube. Que sean los demás, un tercero quien establezca qué confianza mereces. Es mejor una revisión independiente. Lo "open..." puede o no ser transparente. Yo sinceramente, entre tener acceso al código o tener acceso a los planos, prefiero esto segundo. Me proporciona más información y me da más confianza. Estos documentos pueden ser revisados y entendidos sin grandes esfuerzos. Lo otro por ahora, que me demuestren que es una ventaja real porque cuando "mil ojos miran, ninguno examina". Hace tiempo leyendo el libro "The Tipping Point" comentaban una situación paradójica en relación al poder del contexto. Cuando ante una situación de emergencia hay varias personas presentes, ninguna socorre porque consideran que irá "el otro". Sin embargo, en la misma situación si estás solo, sales al rescate. ¿Por qué? Porque siempre queremos que los valientes sean otros... y con el acceso al código y la seguridad creo que pasa lo mismo. Es seguro porque se puede mirar, auditar y revisar, pero que lo haga otro. Yo sinceramente prefiero en estos casos, ver que existen certificaciones del tipo ISO 15408 donde se que alguien, que seguramente además sabe mucho, ya ha hecho ese trabajo.

Ya es oficial, ISO 27004 nueva norma vinculada a la medición de la seguridad

Paloma Llaneza, con gran alegría por ser en parte madre de la criatura nos anuncia que ya tenemos oficialmente una nueva norma dentro del marco ISO 27000.

La nueva norma, oficialmente denominada "Information technology -- Security techniques -- Information security management -- Measurement" viene a sofocar uno de los grandes abismos que existen en el proceso de construcción de un SGSI. Ya he comentado muchas veces que certificarse con ISO 27001 es establecer que las cosas se vigilan dentro de un marco de gestión y que existen procesos de mejora continua sobre el funcionamiento de las medidas de seguridad. Sin embargo, gestionar bien no implica tener buena seguridad. Obviamente ayuda mucho tener un marco de gestión y revisión continua pero es sólo una condición necesaria, no suficiente.

Esta nueva norma establece criterios para la medición del estado de la seguridad. Es aquí donde los datos y las evidencias deben poner al SGSI en su sitio. Es cuando los resultados nos proporcionan información sobre cual es la situación real de las medidas y si están o no funcionando de acuerdo a los objetivos planteados. Por eso es tan importante la publicación de esa norma. Es la única manera de valorar si tanta gestión de la seguridad está sirviendo para algo, y esos hechos avalados por resultados y datos concretos que se están midiendo.

Por tanto, un SGSI certificado y todo que no logre unos buenos resultados en sus indicadores será solo un adorno, dado que habrá una bonita gestión pero con ello no se estará logrando satisfacer los objetivos planteados.



Estas reflexiones ya las plantee de forma más extensa en el post SGSI virtuales en su momento. Os resumo lo que en aquel momento comentaba respecto a las métricas.

La medición debe servir para cuestionarnos continuamente en base a logs, datos y registros si las medidas de seguridad están funcionando bien. Hemos visto que es esencial establecer unos objetivos relevantes para la seguridad de la organización. Pues igual de crítico es establecer un buen conjunto de indicadores que sirvan para evidenciar que las cosas funcionan y podemos dormir tranquilos. Esta información, desde la perspectiva de la gestión, es la más crítica dado que es la base de la retroalimentación del sistema, los datos que se utilizan para hacer ajustes. Por tanto, debemos disponer de sensores de diferente naturaleza y con diferentes objetivos: medir la evolución de la ejecución del plan, valorar el rendimiento y funcionamiento de las medidas de seguridad, vigilar el entorno por si se vuelve más hostil y es necesario modificar la valoración de las amenazas, etc. Cuando se audita, al revisar el análisis de riesgos, mirar qué objetivos tiene el SGSI y en qué indicadores se basa ya te puedes hacer una idea de si tienes delante un SGSI real o virtual. ¿Por qué? Muy sencillo, si la información utilizada por las actividades de gestión es mala, la propia gestión es mala. Si las decisiones no están enfocando los verdaderos problemas y no se está vigilando lo que es importante, el ciclo PDCA da vueltas pero no aporta valor a la Organización. Tener un SGSI dando vueltas de mejora continua produce beneficios pero si quien tiene el timón del barco no sabe dónde tiene que ir, dificilmente podrá lograr llegar a puerto. Serán las incidencias que se vayan registrando las que nos pongan de manifiesto estos hechos pero de nuevo se reacciona en base a fallos, y esa no es la idea principal.

Estableciendo el rumbo de un SGSI

En el Blog del Observatorio de Seguridad del INTECO dejo varias reflexiones sobre qué son, cómo se definen y para qué sirven los indicadores y métricas dentro de la estructura de un SGSI. Podéis entrar a través del enlace "Estableciendo el rumbo de un SGSI".

Publicada ISO 27011:2008

Conforme vayan siendo publicadas, iré comentando algunas otras normas que van a empezar a ir viendo la luz como extensión del marco ISO 27000 relativo a la seguridad de la información.

Los proyectos en proceso y publicados por el Subcomité 27 se pueden consultar en el siguiente enlace.

El pasado mes de diciembre vió la luz la norma ISO 27011:2008 que es un desarrollo del marco de controles ISO 27002 diseñado específicamente para el sector de las telecomunicaciones. El título de esta nueva norma es Information technology - Security techniques - Information security management guidelines for telecommunications organizations based on ISO/IEC 27002.

ISO 27011:2008 como la norma ISO 27799:2008 desarrollada para el sector sanitario son extensiones de la norma ISO 27002:2005 contemplada como un catálogo básico de controles que puede ser utilizado para implantar un SGSI. Tal como establece la norma ISO 27001:2005, a la hora de seleccionar controles se pueden elegir aquellos que figuran como Anexo A y que se corresponden con ISO 27002 o bien aquellos controles que la organización entienda que pueden ser interesantes o de aplicación. Por tanto, vamos a ir viendo aparecer normas de seguridad que son extensiones a medida de los diferentes sectores que están intentando establecer un conjunto de medidas de seguridad acordes con sus necesidades específicas.

SGSI virtuales

La proliferación de subvenciones y la motivación que proporciona el coleccionar certificaciones a nivel de organizaciones está generando un pequeño "boom" dentro del mundillo de la seguridad de la información y en concreto, la certificación bajo la norma ISO 27001:2005.

Esto que en teoría es viento favorable y debería generar cada vez más concienciación y producir mejoras en la gestión puede entrar en un círculo vicioso nada deseable. Por parte de las consultoras siempre se comenta que lograr la certificación es el premio al buen trabajo y el esfuerzo realizado en materia de seguridad. Sin embargo, se empieza ya a detectar una tendencia algo más peligrosa que es cuando el esfuerzo se dirige exclusivamente a lograr la medalla tratando de pasar la auditoría de certificación de cualquier forma, aun cuando ello no suponga disponer de una verdadera "gestión de la seguridad de la información".

Quiero comentar qué cosas son imprescindibles para que una organización tenga un SGSI real, y no uno virtual y certificado.

• Primero: Es necesario tener claro cuales son nuestros objetivos de seguridad. Cada organización tiene un por qué en relación a sus necesidades de seguridad. Esta información se obtiene en la fase de análisis de riesgos, donde por cada proceso debemos pensar qué consecuencias puede tener la inseguridad. De esta forma hallamos qué es lo que tiene valor para la organización, atendiendo a requisitos de disponibilidad, integridad y confidencialidad. Obtener estos requisitos es también el por qué es necesario hacer el análisis de riesgos.



• Segundo: Definir los objetivos que el SGSI debe perseguir. Una vez que acaba la fase de análisis de riesgos, conocemos cuales son los peligros potenciales que podrían generar mucho daño a la organización y por tanto, tenemos identificados todos aquellos eventos que bajo ningún concepto queremos que sucedan. El SGSI debe ser valorado y revisado al menos anualmente, para verificar que todo el esfuerzo que se está realizando en la materia se está logrando rentabilizar. Este concepto significa para el caso del SGSI que las medidas de seguridad funcionan y que los incidentes no visitan nuestra organización. Para ayudarnos en estas cuestiones es para lo que deben establecerse los objetivos del SGSI y sus correspondientes indicadores. ¿Cuantos son necesarios? Personalmente creo que los suficientes para valorar si todas las directrices dadas en la "Política de seguridad" se están cumpliendo. Cuantos más sensores del estado de la seguridad mejor, siempre que su gestión y mantenimiento sea algo llevable. A más información, más criterio para tomar decisiones. Los indicadores son una parte muy importante en el proceso de feedback que todo SGSI realiza para ajustarte a los objetivos planteados.



• Tercero: Realizar el despliegue de medidas de seguridad para gestionar los riesgos y ejecutar el plan de tratamiento de riesgos que se haya planteado. Esta norma en esencia tiene como estrategia base de seguridad la prevención. El mérito de un buen SGSI es que evita daños. Por tanto, pervertir este funcionamiento elimina la esencia del beneficio que la gestión de la seguridad debe proporcionar a la organización. ¿Qué significa esto? Pues que no hay que hacer las cosas para superar la certificación sino para mitigar riesgos. Tengo la sensación de que muchos procedimientos se escriben para que queden bonitos el día de la auditoría pero en el fondo no está detrás la búsqueda de un buen mecanismo de eliminación de vulnerabilidades. El SGSI debe prevenir o detectar lo más tempranamente posible. De lo contrario, los daños se producen y aunque luego en la fase de revisión del sistema se pueden producir ajustes, el impacto ya se ha producido y la revisión sólo sirve para intentar no caer dos veces en la misma piedra.



• Cuarto: Gestionar y monitorizar el funcionamiento de las medidas de seguridad. Una vez que el sistema está en marcha, la gestión de incidentes y de no conformidades son el nuevo pilar en el que se basa el SGSI. La mejora continua crea un proceso de retroalimentación que realiza los ajustes necesarios al funcionamiento establecido en base a detectar fallos que generan o bien acciones correctoras o bien acciones preventivas o bien sugerencias de mejora. El mantenimiento del SGSI se basará en solucionar las pegas del día a día y en la revisión del sistema que se realiza cada vuelta del ciclo donde se valoran también los resultados obtenidos en el seguimiento de indicadores y cumplimiento de objetivos.



• Quinto: Formación y concienciación en la materia. Como me apunta "Deincógnito" en los comentarios, la formación de las personas que vayan a gestionar el SGSI sobre esta disciplina de la seguridad de la información es esencial. Dificilmente se puede gestionar "algo" sobre lo que se desconoce su funcionamiento, conceptos y criterios. Además de esta formación de las personas que operan el SGSI, es necesario que los actores principales de la protección, los usuarios del sistema estén entrenados para que la protección sea una cosa de todos.

Dicho esto, voy a tratar de identificar los sintomas principales de un "SGSI virtual".

• Los objetivos de seguridad no son proporcionados por la Dirección: Nadie sabe mejor lo que se juega que quién es dueño del negocio. Por tanto, de cara a establecer los objetivos, deben surgir de dentro para solucionar los potenciales problemas que más daño podrían producir a la organización que se quiere certificar. Las consultoras en estos aspectos podemos asesorar pero no decidir. No es lo mismo plantear opciones en relación a objetivos en forma de propuestas que deben seleccionarse que darlos por escrito como si fueran ya decisiones definitivas.


• La metodología de análisis y gestión del riesgo no se entiende por parte de la Organización: Esta situación es un auténtico cáncer para un SGSI. Esta fase es el corazón del SGSI dado que es donde se realiza el diagnóstico de situación. Un mal diagnóstico implica un mal tratamiento y unos malos resultados. Por eso es importante que este proceso sea realizado por parte de profesionales adecuadamente formados y con criterio y conocimientos de "seguridad de la información". Es la barrera de entrada que existe para profesionales dedicados actualmente a otras certificaciones de sistemas de gestión y que algunos no parecen percibir. Ponerse a realizar un plan de tratamientos de riesgos sin haber leido al menos la norma ISO 27002 me parece muy osado y sobre todo, poco profesional pero allá cada organización en relación a las manos en las que quiera ponerse.
  Por otro lado, la dinámica utilizada por la Organización para ir realizando el diagnóstico de sus deficiencias y necesidades debe ser sencilla de gestionar por parte de la Organización y en la medida de lo posible, para estas tareas deben ser autónomos. Es cierto que en el inicio de todo proyecto de construcción de un SGSI muchas empresas se ven sobrepasadas dado que son muchos conceptos específicos sobre esta materia. Pero cuando el SGSI empieza a funcionar y da su primera vuelta, la Organización debe poder seguir con el ciclo de mejora continua y debe afrontar la primera revisión del análisis de riesgos con suficientes armas como para poder ajustar todos aquellos matices y aspectos que fallaran o pasaran ignorados en la primera fase. En este sentido, también detecto una peligrosa tendencia que ya he comentado alguna vez. Hay consultoras que no entienden la verdadera importancia del análisis y gestión del riesgo y se lanzan a inventar su propia metodología. No critico que esto se haga, pero si alguien se lanza, que lo haga bien. ¿Qué significa? Al menos la metodología debe cumplir con los puntos especificados por la norma 27001 y debe generar resultados razonables y repetibles. Para ello por suerte, ya disponemos de ISO 27005 que deja asentados ciertos conceptos base que toda metodología debe contemplar. Como organización, para plantearse si la metodología es buena o no el mejor diagnóstico es seleccionar un control y preguntarse por qué es necesario. Algo como esto qué hago qué sentido tiene. Si la metodología es robusta, debe identificar esa medida dónde debe aplicarse, en base a qué tengo que hacerla (gestiona un riesgo, satisface un requisito legal o es un objetivo de negocio), en qué situación se encuentra y a qué situación debo acabar llevándola, y por último, cómo valoro que está funcionando y ayuda al cumplimiento de los objetivos del SGSI.


• No existen tareas de seguridad: Esto de la certificación 27001 y disponer de la medalla de la seguridad es muy bonito pero el premio hay que sudarlo. Otro síntoma de un SGSI virtual es que no se definen las tareas que por seguridad deben ir realizándose a diario para evitar, detectar o remediar las incidencias que se van produciendo. Antes ya dije que la estrategia de la norma es siempre que sea posible la prevención o detección temprana. Para ello, es necesario que existan ciertas rutinas que proporcionen datos que sirvan para valorar nuestra situación, sensores o termómetros que nos avisen de cómo están funcionando nuestros sistemas de información y de cuándo pueden estar produciéndose situaciones potencialmente peligrosas. Esto obedece a la famosa frase de Lord Kelvin "si no puedes medirlo, no puedes mejorarlo" para la que Google ahora tiene un nuevo enunciado "Si puedes medirlo, puedes mejorarlo".La seguridad se debe basar fundamentalmente en la monitorización constante. Como toda área de control, es necesario vigilar que las cosas están en orden. Para ello, los mecanismos de seguridad deben servir para detectar, prevenir o predecir potenciales peligros de manera que podamos estar reaccionando al posible incidente antes de que este ocurra. Con esta filosofía de trabajo o bien somos capaces de hacer que la amenaza no nos afecte o bien disminuimos mucho su daño si la reacción arranca de forma muy temprana. No es necesario caer dos veces en la misma piedra para saber que si hay un obstáculo y no lo esquivamos, podemos caer. Por tanto, el SGSI se fundamenta en un despliegue de termómetros de seguridad distribuidos por toda la organización de manera que cuando se superan ciertos niveles salten alarmas que nos pongan manos a la obra a trabajar. Es todo lo contrario de lo que se venía haciendo hasta ahora en seguridad: apagar fuegos.


• Los indicadores de seguridad son irrelevantes: La medición debe servir para cuestionarnos continuamente en base a logs, datos y registros si las medidas de seguridad están funcionando bien. Hemos visto que es esencial establecer unos objetivos relevantes para la seguridad de la organización. Pues igual de crítico es establecer un buen conjunto de indicadores que sirvan para evidenciar que las cosas funcionan y podemos dormir tranquilos. Esta información, desde la perspectiva de la gestión, es la más crítica dado que es la base de la retroalimentación del sistema, los datos que se utilizan para hacer ajustes. Por tanto, debemos disponer de sensores de diferente naturaleza y con diferentes objetivos: medir la evolución de la ejecución del plan, valorar el rendimiento y funcionamiento de las medidas de seguridad, vigilar el entorno por si se vuelve más ostil y es necesario modificar la valoración de las amenazas, etc. Cuando se audita, al revisar el análisis de riesgos, mirar qué objetivos tiene el SGSI y en qué indicadores se basa ya te puedes hacer una idea de si tienes delante un SGSI real o virtual. ¿Por qué? Muy sencillo, si la información utilizada por las actividades de gestión es mala, la propia gestión es mala. Si las decisiones no están enfocando los verdaderos problemas y no se está vigilando lo que es importante, el ciclo PDCA da vueltas pero no aporta valor a la Organización. Tener un SGSI dando vueltas de mejora continua produce beneficios pero si quien tiene el timón del barco no sabe dónde tiene que ir, dificilmente podrá lograr llegar a puerto. Serán las incidencias que se vayan registrando las que nos pongan de manifiesto estos hechos pero de nuevo se reacciona en base a fallos, y esa no es la idea principal.

Toda esta reflexión sólo tiene un motivo que es hacer ver que tener una organización certificada bajo ISO 27001 no va a servir de nada si no creemos en la necesidad de gestionar bien la seguridad de la información. Cuando uno se certifica en ISO 9001, se esfuerza por lograr la "calidad de sus servicios/productos". De no lograrlo es posible que la satisfacción del cliente no mejore y los resultados de la empresa no crezcan. Estas situaciones se controlan puesto que las cifras de resultados se vigilan continuamente de forma que cualquier fallo en la "calidad" puede ser identificado y se pueden realizar rápidamente ajustes.

Pues cuando uno se certifica en ISO 27001 se esfuerza por lograr la "seguridad de la información" de sus procesos productivos. De no lograrlo puede suceder que se presente una amenaza importante y que la organización no supere el incidente, y por tanto, la empresa no sobreviva. La seguridad sólo es vigilada por el SGSI de forma que no hay una segunda oportunidad para hacerlo bien. Si el incidente se presenta y falla por ejemplo el plan de continuidad de negocio, podremos tener unos magníficos procedimientos que no servían para nada y lucir nuestro maravilloso "sello 27001" pero la información de la empresa habrá desaparecido para siempre.
El hombre es un animal inteligente que no debe caer dos veces en la misma piedra. Debería ser suficiente con aprender de los demás pero no tener que sufrirlo en las propias carnes para reaccionar.

Cuando trabajaba en Madrid, hice varios cursos de Microsoft y seguridad en la Torre Windsor. Era un edificio gigante con 8 ascensores que se llenaban hasta arriba en las horas puntas. Me pregunto de las más de trescientas empresas cuantas superaron aquel incidente. Al menos he podido encontrar dos que si hicieron bien los deberes pero ¿2 de 200 es un buen ratio?.
Dada la edad de este blog, aquellos acontecimentos fueron ya comentados en su momento y las reflexiones sobre lo que ocurrió, lo que se perdió, los que hicieron bien las cosas y lo que debería hacerse ya han sido publicados.

La función de auditoría como mecanismo de seguridad

Aunque ultimamente ando muy saturado de trabajo, en el Blog del Inteco dejo unas reflexiones sobre la importancia de la función de la auditoría en los actuales sistemas de información. Os extracto algunas partes y os invito a pasar por el Blog del Inteco para leer el texto completo.

En estos últimos tiempos se viene hablando de la necesidad de mejorar los mecanismos de control sobre diferentes actividades, en general, de gestión económica dentro de las grandes compañías y empresas, para generar confianza y evitar el fraude. Las organizaciones han incorporado a su funcionamiento las ventajas de las tecnologías de la información, modificando sus procesos de negocio para mejorar el rendimiento y la productividad. Sin embargo, en el diseño de estos sistemas de información, desde el comienzo, ha primado el rápido funcionamiento y la puesta en marcha de los servicios sin parar mucho a pensar en la fase de diseño, en mecanismos de control y auditoría sobre los procesos. Llega actualmente el momento en el que esas desconsideraciones sobre la importancia de garantizar la fiabilidad de los procesos que han sido automatizados están poniendo de manifiesto una gran preocupación por la gestión y control de las tecnologías de la información, ya que han dado lugar a la aparición de nuevos riesgos no identificados debido principalmente a la complejidad de la infraestructura, la alta dependencia de la organización sobre los sistemas de información y los abusos de privilegios por parte de usuarios legítimos.

Fruto de esta preocupación puede entenderse el interés y la demanda que actualmente tienen las normas, recomendaciones y estándares considerados buenas prácticas de gestión de la tecnología, como pueden ser la norma ISO 27001, que especifica los requisitos para la construcción de Sistemas de Gestión de la Seguridad de la Información (SGSI) y la norma ISO 20000, que establece los requisitos para la construcción de Sistemas de Gestión de Servicios de Tecnologías de la Información (SGTI).

En términos técnicos, una auditoría viene definida por el establecimiento de cuatro aspectos relacionados con la actividad auditora:

• Objetivo.


• Evidencias.


• Independencia.


• Conclusiones.

Estos cuatro conceptos establecen los pilares de una posible definición de auditoría que sería “el proceso sistemático, independiente y documentado para obtener evidencias y evaluarlas de manera objetiva con el fin de determinar la extensión en que se cumplen los criterios de auditoría.”

La Auditoría de Sistemas de Información tiene como misión ser un mecanismo de control interno para evaluar la CONFIANZA que se puede depositar en los sistemas de información basada en evidencias.

La auditoría de sistemas de seguridad es una medida de seguridad que debe ser considerada por su importancia, dado que permite detectar deficiencias antes de que éstas puedan ser utilizadas o puede servir para averiguar si se han producido o no irregularidades en el uso de los sistemas de información. Es un mecanismo que evita los abusos de poder.

Al igual que es un tópico de seguridad el tema del conocido post-it con la contraseña al lado del equipo al que permite el acceso, los logs que no son nunca consultados son otro que suele repetirse cuando se revisan sistemas de información. Estas trazas auditables informan de situaciones anómalas en el momento en que se producen y proporcionan pruebas electrónicas que puedan ser utilizables en caso de finalmente llevar al campo jurídico la denuncia correspondiente. Sin embargo, la práctica habitual es la de no mirar los logs y además, no conservarlos con garantías jurídicas suficientes para que puedan ser utilizados como evidencia en juicio. Es otro tópico más en el que se demuestra que la "sensación de protección" no se corresponde para nada con la seguridad efectiva que realmente se tiene ni con el objetivo que justifica el esfuezo económico que se hace para disponer de espacio para su almacenamiento. Los logs cuestan dinero pero si no cumplen con el objetivo por el que se recogen y almacenan, mejor no hacer nada.

Respecto a la normalización de la prueba electrónica, habrá que estar atentos a los trabajos de la Asociación Española de Evidencias Electrónicas (AEDEL) que nace con el objetivo de ser referente técnico y jurídico en aquello que las evidencias y pruebas electrónicas afecten a los ciudadanos, queriendo hacer posible con su actividad que la sociedad española – ciudadanos, padres, jóvenes, entidades públicas y privadas, sin distinción de tamaño o sector- puedan disfrutar de un marco de seguridad y confianza en los entornos digitales y en Internet.

¿Funcionan los analisis de riesgos?

Interesantes reflexiones de Joseba Enjuto sobre la problemática del "análisis y gestión del riesgo en materia de seguridad de la información".
Ni una sola coma tiene desperdicio. También es muy interesante el artículo inicial que genera su reflexión.
Más información en Seguridad y Gestión: ¿Funcionan los analisis de riesgos?

Esto va muy en la línea de un próximo post que se plantea el por qué hacemos las cosas, en materia de seguridad.

PD: Gracias a los ahora más de 1.000 suscriptores vía RSS que ya seguís a diario este humilde blog. Intentaré estar a la altura de las circunstancias con post algo más meditados y reflexivos sobre la "cuestión de la seguridad".

Estado de situación de la serie ISO 27000 a fecha 10 de diciembre 2008

A continuación voy a listar el conjunto de normas publicadas o en proceso de elaboración de la serie ISO 27000 a fecha 10 de diciembre de 2008. Estos resultados son fruto de una consulta a la Web de ISO.org en relación al área de trabajo del Subcomité 27 del JTC 1 - IT Security techniques.

El estado de las normas se codifica en base a unos acrónimos que ISO tiene identificados y que son:

• 1.PWI = Preliminary Work Item - initial feasibility and scoping activities


• 2.NP = New Proposal (or study period) - formal scoping phase


• 3.WD = Working Draft (1st WD, 2nd WD etc.) - development phase


• 4.CD = Committee Draft (1st CD, 2nd CD etc.)- quality control phase


• 5.FCD = Final Committee Draft - ready for final approval.


• 6.DIS = Draft International Standard - nearly there. Stage 40.


• 7.FDIS = Final Draft or Distribution International Standard - just about ready to publish. Stage 50.


• 8.IS = International Standard - published. Stage 60.


• 9. Under revisión. Stage 90.

Como podréis comprobar en la siguiente relación de normas, hay bastantes ya en el Stage 40 y 50 lo que indica que pronto pueden ver la luz. La situación actual del marco internacional de normas ISO 27000 es:

• ISO/IEC FCD 27000.
  Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary. Stage:40.99


• ISO/IEC 27001:2005.
  Information technology -- Security techniques -- Information security management systems -- Requirements. Stage:60.60


• ISO/IEC 27002:2005
  Information technology -- Security techniques -- Code of practice for information security management. Stage:90.92


• ISO/IEC FCD 27003
  Information technology -- Information security management system implementation guidance. Stage:40.20


• ISO/IEC FCD 27004.2
  Information technology -- Security techniques -- Information security management -- Measurement. Stage:40.20


• ISO/IEC 27005:2008
  Information technology -- Security techniques -- Information security risk management. Stage:60.60


• ISO/IEC 27006:2007
  Information technology -- Security techniques -- Requirements for bodies providing audit and certification of information security management systems. Stage:60.60


• ISO/IEC WD 27007
  Guidelines for Information security management systems auditing. Stage:20.60


• ISO/IEC FDIS 27011
  Information technology -- Information security management guidelines for telecommunications organizations based on ISO/IEC 27002. Stage:50.60


• ISO/IEC NP 27012
  Information technology - Security techniques -- ISM guidelines for e-government services. Stage:10.99


• ISO/IEC NP 27032
  Guidelines for cybersecurity. Stage:10.99


• ISO/IEC NP 27033
  Information technology -- IT Network security.Stage:10.99


• ISO/IEC CD 27033-1
  Information technology -- Security techniques -- IT network security -- Part 1: Guidelines for network security. Stage:30.60


• ISO/IEC WD 27033-2
  Information technology -- Security techniques -- IT network security -- Part 2: Guidelines for the design and implementation of network security. Stage:20.60


• ISO/IEC WD 27033-3
  Information technology -- Security techniques -- IT network security -- Part 3: Reference networking scenarios -- Risks, design techniques and control issues. Stage:20.60


• ISO/IEC NP 27033-4
  Information technology -- Security techniques -- IT network security -- Part 4: Securing communications between networks using security gateways - Risks, design techniques and control issues. Stage:10.99


• ISO/IEC NP 27033-5
  Information technology -- Security techniques -- IT network security -- Part 5: Securing Remote Access - Risks, design techniques and control issues. Stage:10.99


• ISO/IEC NP 27033-6
  Information technology -- Security techniques -- IT network security -- Part 6: Securing communications across networks using Virtual Private Networks (VPNs) -- Risks, design techniques and control issues. Stage:10.99


• ISO/IEC NP 27033-7
  Information technology -- Security techniques -- IT network security -- Part 7: Guidelines for securing (specific networking technology topic heading(s) to be inserted3) -- Risks, design techniques and control issues. Stage:10.99


• ISO/IEC NP 27034
  Guidelines for application security. Stage:10.99


• ISO/IEC NP 27037
  Information technology - Security techniques -- on Information security management: Sector to sector interworking and communications for industry and government . Stage:10.99

El detalle de los diferentes escalones dentro de cada nivel o stage lo podéis consultar en Stages ISO.

El ciclo de desarrollo seguro del software (SDLC)

Desde hace unos días y con lo agitado del mundillo informático por el tema de mañana, la manifestación 19-N, parece que está llegando el momento de "tirar de la manta" y destapar los trapos sucios que deja la industria del software y su ausencia de regulación.

No quiero defender en ningún momento la "titulitis", pero hay una evidencia clara que todos los días pagamos caro, el software es inseguro. No voy a entrar en profundizar mucho sobre las causas dado que otros blogs amigos ya lo han hecho con gran calidad (Security at Work) y profundidad (Hispasec).

Mi aportación viene más a contar la R-(evolución) de Microsoft en este tema. Ni que decir tiene que saben de lo que hablan. Han pasado de conocerse a sí mismos a intentar conocer a su enemigo (siguiendo la filosofía de Sun Tzu). Y ahora, fruto de ese esfuerzo y de la madurez de su estrategia para robustecer el software, van a la raíz del asunto: las metodologías del desarrollo software.

Esta r-(evolución) no es nueva: lleva ya algunos años en marcha y Vista creo que es el primer producto con este enfoque desde su nacimiento. Pero no contentos con eso, explican al resto cómo deben hacerse las cosas.
Para quien no tenga claro de que va esto, recomiendo ver este video What is Microsoft Application Threat Modeling?
Los resultados de este proceso son un conjunto de requisitos de seguridad necesarios para lograr que la aplicación sea robusta. En este video se pueden consultar los resultados de usar esta herramienta.

Como habréis podido observar quienes hayáis visto los videos, ¡Esto sí es SEGURIDAD en el DISEÑO de la solución SOFTWARE!.

Para quien tenga más hambre de conocimientos, puede saciar su sed en Microsoft Application Threat Modeling. También es destacable que todo este material es de acceso libre y que no cabe duda que es una gran contribución al mundo de la Ingeniería del Software.
La herramienta puede ser descargada en Microsoft Threat Analysis & Modeling v2.1.2

La seguridad de la informacion en el sector sanitario: ISO 27799:2008

Ya he comentado alguna vez que la serie 27000 va a servir como marco normativo para todo lo relacionado con la seguridad de la información.

Pues bien, hemos de recibir una nueva norma de este marco, "ISO 27799:2008 Health informatics -- Information security management in health using ISO/IEC 27002". He dado con ella gracias a ISO 27002.es
Tal como aparece en la Web de ISO, su resumen es:

ISO 27799:2008 defines guidelines to support the interpretation and implementation in health informatics of ISO/IEC 27002 and is a companion to that standard.

ISO 27799:2008 specifies a set of detailed controls for managing health information security and provides health information security best practice guidelines. By implementing this International Standard, healthcare organizations and other custodians of health information will be able to ensure a minimum requisite level of security that is appropriate to their organization's circumstances and that will maintain the confidentiality, integrity and availability of personal health information.

ISO 27799:2008 applies to health information in all its aspects; whatever form the information takes (words and numbers, sound recordings, drawings, video and medical images), whatever means are used to store it (printing or writing on paper or electronic storage) and whatever means are used to transmit it (by hand, via fax, over computer networks or by post), as the information must always be appropriately protected.

Su estructura es:

• Alcance


• Referencias (Normativas)


• Terminología


• Simbología


• Seguridad de la información sanitaria


• Objetivos; Seguridad en el gobierno de la información; Infomación sanitara a proteger; Amenazas y vulnerabilidades


• Plan de acción práctico para implantar ISO 17799/27002


• Taxonomía; Acuerdo de la dirección; establecimiento, operación, mantenimiento y mejora de un SGSI; Planning; Doing; Checking, Auditing


• Implicaciones sanitarias de ISO 17799/27002


• Política de seguridad de la información; Organización; gestión de activos; RRHH; Fisicos; Comunicaciones; Accesos; Adquisición; Gestión de Incidentes; Continuidad de negocio; Cumplimiento legal


• Annex A: Amenazas


• Annex B: Tareas y documentación de un SGSI


• Annex C: Beneficios potenciales y atributos de herramientas


• Annex D: Estándares relacionados

La norma tiene stage 60.60 (Publicada) con fecha de 12 de Junio de 2008. Podéis adquirirla en ISO 27799:2008 - Health informatics -- Information security management in health using ISO/IEC 27002

Estos movimientos serán también continuos en años próximos dado que es intención de ISO extender la norma ISO 27002 con contenidos específicos en aquellos sectores que plantean una problemática especial.

Modelos de "políticas" de seguridad

Vía ISO27002.es he podido dar con la Web
Open Directory - Computers: Security: Policy: Sample Policies que contiene un buen catálogo de documentos sobre políticas de seguridad.

En Guía para la elaboración del marco normativo de Seguridad ISO 27002 ya comenté las diferencias entre Política, Norma y Procedimiento aunque en ingles el término "policy" suele tener un carácter más general. Es habitual encontrar "policies" para todo, aunque muchas veces estos documentos tienen el objetivo de establecer regulaciones y por tanto deberían entenderse como normas.

Aumenta esta confusión además que en la norma ISO 27002 aparezca como control en el punto 5.1.1. la famosa "política de seguridad de la información".
En cualquier caso, el catálogo de documentación contiene una buena recopilación de diferentes enfoques a la hora de establecer un marco normativo, lo que suele venir bien cuando se anda intentando escribir estas cosas.

Como reflexión final, todo documento que intenta ser una política, norma o procedimiento tiene que tener un objetivo base "Que pueda ser algo cumplible".No se trata por tanto de hacer algo que quede bien o que sea completo, sino algo que sea real, asumible y cumplido por el área regulada.

La subcontratación del riesgo

Tenía pendiente desde hace unos días elaborar esta entrada. Tras unos comentarios en relación al post de Joseba Enjuto sobre la caracterización de los Servicios TI, quería hablar sobre la " subcontratación del riesgo". Lo primero que quiero justificar es el titulo. La gestión del riesgo sólo permite cuatro decisiones posibles:

• Aceptarlo


• Evitarlo


• Reducirlo o


• Transferirlo a un tercero

En general, se suele entender por transferencia del riesgo cuando éste se tiene identificado y se decide que un externo sea quien lo gestione a cambio de cierta contraprestación: habitualmente puede ser la externalización de servicios, la contratación de seguros, etc.

Es habitual, como bien apuntaban en los comentarios de "Seguridad y Gestión" que el término para definir este proceso sea la "externalización del riesgo" pero ahora voy a justificar un poco por qué prefiero no llamarlo así.

Yo concibo la idea de la externalización de un riesgo cuando una Organización identifica claramente qué necesita y establece una relación contractual de prestación de servicios que permite al cliente quedarse tranquilo respecto a cómo va a gestionar el tercero ese riesgo. Para ello, evidentemente, los servicios prestados por el tercero deberían poder acreditar ciertas garantías respecto a la seguridad con la que van a ser proporcionados. La existencia de unos adecuados "Acuerdos de nivel de servicio" ( o su término en ingles Service Level Agreement, SLA) centrados exclusivamente bajo la perspectiva de la seguridad podrían ser suficiente garantía. La Organización que traslada el riesgo sabe que en caso de problemas, podrá arremeter contractualmente contra la empresa a la que transfiere el riesgo siendo recompensada adecuadamente en caso de una gestión no adecuada de ese riesgo. Para ello, aparece el control 6.2.3 de la norma ISO 27002 que indica que "Los acuerdos que comporten el acceso de terceros a recursos de tratamiento de información de la Organización deben basarse en un contrato formal que tenga o se refiera a todos los requisitos de seguridad que cumplan las políticas y normas de seguridad de la Organización."

Si atendemos a la guía de implantación de la norma, que es la forma más completa de implantar el control, este tipo de ANS o SLA de seguridad deben cubrir cosas como:

• 1.-La política sobre seguridad de la información del tercero.
• 2.-Los controles para asegurar la protección de los activos que el tercero tiene implantado, incluyendo:
• procedimientos para proteger los activos de la organización, incluida la información, el software y el hardware.
• cualquier control o mecanismo de protección física requeridos.
• controles para asegurar la protección contra el software malicioso
• procedimientos para determinar si ha ocurrido algún incremento del riesgo de los activos, por ejemplo, pérdida o modificación de información, software o hardware;
• controles para asegurar la recuperación o destrucción de la información y los activos, al terminar el contrato o en algún momento acordado dentro del periodo de vigencia del contrato;
• la confidencialidad, integridad, disponibilidad, y cualquier otra propiedad importante de los activos
• restricciones en la copia o revelación de la información; junto con la utilización de acuerdos de confidencialidad
• 3.- Una clara estructura de los informes y de los formatos de informe acordados.
• 4.- Un proceso especificado y claro de la gestión del cambio.
• 5.- Disposiciones para informe, notificación e investigación de los incidentes de seguridad de la información e infracciones de seguridad, así como violaciones de los requisitos establecidos en el acuerdo.
• 6.- Una descripción del producto o servicio que se va a proporcionar, y una descripción de la información que se hará accesible, con su clasificación de seguridad.
• 7.- El nivel objetivo de servicio y los niveles de servicio inaceptables.
• 8.- La definición de los criterios de verificación del comportamiento, su control e informe.
• 9.- El derecho a controlar, y revocar, cualquier actividad relacionada con los activos de la organización.
• 10.- El derecho de auditar las responsabilidades definidas en el acuerdo, teniéndose que llevar a cabo tales auditorías por una tercera parte, y de enumerar las obligaciones y derechos legales de los auditores.
• 11.- El establecimiento de un procedimiento de escalado para la resolución de los problemas.
• 12.- Requisitos de continuidad de servicio, incluyendo las medidas de disponibilidad y fiabilidad, de acuerdo con las prioridades de negocio de la organización.
• 13.- Las responsabilidades respectivas de las partes del contrato.
• 14.- Las responsabilidades con respecto a temas legales y como se garantiza que se cumplen los requisitos legales, por ejemplo legislación de protección de datos, teniendo en cuenta sobre todo los distintos sistemas legales nacionales si el contrato implica la cooperación con organizaciones de otros países.
• 15.- Etc.

El primer problema con el que nos solemos encontrar en las Organizaciones es que se externalizan servicios pero no se definen, desde la perspectiva de la seguridad, en qué condiciones se transfiere el riesgo. Llegado a estas alturas del texto, cabe pensar si realmente conocéis a alguna empresa que "externalice su riesgo" o si en general todas "subcontratan servicios de riesgo" entendiendo por esto segundo, un término menos formalizado de dar a un tercero un riesgo. Quiero destacar que el riesgo SI se puede transferir, pero no así la responsabilidad. Por tanto, que las cosas no estén bien definidas, explícitamente documentadas y contractualmente reflejadas solo hace que perdamos "control" sobre nuestro riesgo que además, no vamos a gestionar nosotros mismos.

Dependerá de cómo entienda e interprete ese tercero el riesgo que asume al prestar el servicio el tipo de garantías que pudiera proporcionarnos en caso de un incidente de seguridad. Y lo que me parece más preocupante es que la "externalización de servicios TI" está muy de moda y si bien tenemos normas como ISO 20000 o ITIL que definen bien cómo debe hacerse este proceso y cómo deben establecerse los SLA y ANS, es importante que los aspectos relacionados con la seguridad queden perfectamente definidos. Es cierto que para los servicios TI el factor más importante a considerar suele ser la disponibilidad, pero debemos contemplar qué ocurriría si la naturaleza del incidente o error afecta a la integridad o confidencialidad de nuestra información.

Toda externalización supone pérdida de control si no se establecen mecanismos de regulación y seguimiento que permitan aportar evidencias, por parte del externo, de estar haciendo las cosas bien. A esta problemática general, todavía cabría añadir la complejidad que surge cuando se manejan cadenas de subcontratación. Si la empresa A transfiere un servicio a la empresa B, que a su vez utiliza a las subcontratas C y D para proporcionar el servicio final al cliente A. Si estos eslabones de subcontratación no están claramente identificados y bien atados, la empresa A puede ver comprometida su seguridad y no tener muy claro cuál ha podido ser la cadena de fallos y por tanto, la cadena de responsabilidades.

Y decía al principio que los acontecimientos siempre nos ponen de manifiesto estas reflexiones por el incidente este fin de semana en los hospitales madrileños. El titular de "El País" que se hace eco de la noticia es Siete hospitales se quedan seis horas sin sistema informático.

Cuando hacemos el análisis de riesgos y estamos en la fase de valoración de activos, siempre usamos una escala denominada "laboral" donde precisamente se tiene en consideración si un incidente de seguridad puede costar "vidas humanas". Normalmente nuestros entrevistados suelen hacer alguna broma al respecto, pero es cierto que en ciertos "modelos de negocio", los servicios TI son críticos pudiendo causar la muerte de personas. Además, el proceso de digitalización que tantos beneficios genera y que tan bien venden nuestros políticos en relación a la atención sanitaria, tiene requisitos de seguridad que requieren hacer las cosas bien desde el principio. Sin entrar a valorar en concreto estos hechos, dado que no tenemos información suficiente que pudiera servir para valorar técnicamente que ha fallado, las evidencias son un cese de servicios de seis horas, algo posiblemente "intolerable" para un sector sanitario donde mucha información se requiere "en tiempo real". Merece la pena destacar frases como "La caída del programa la provocó una bajada de tensión eléctrica en la zona de Tres Cantos, donde está el centro tecnológico que aloja el servidor central de los nuevos hospitales".

¿Un sólo servidor para un activo de información tan crítico? ¿Ningún plan de contingencia para recuperarse frente a una situación así en menos de una hora?

El blog APISCAM parece proporcionar más información sobre lo sucedido, aunque quizás con una versión menos imparcial (seguramente muy justificada). Parece que toda la gestión informática hospitalaria está subcontratada y en los diferentes pliegos y concursos se habían contemplado requisitos respecto a la continuidad de servicio.

De los hechos se deduce, al menos, un fallo grave en el plan de continuidad de negocio o planes parciales de contingencia. En sistemas de información como los del entorno hospitalario, con cada vez más dependencia de la tecnología para obtener información relativa al diagnóstico, hablamos de sistemas críticos que requieren información en tiempo real ("Fue el servicio de urgencias el que más sufrió las consecuencias de las demoras. "Tenemos que ir corriendo de un lado para otro para llevar historias, análisis...", explicaba ayer una enfermera de este departamento del hospital de Vallecas").

Quizás en el pliego las condiciones del servicio pudieran estar bien contempladas, pero para nada se ha garantizado la correcta supervisión de la ejecución del mismo y el adecuado cumplimiento del ACUERDO DE NIVEL DE SERVICIO. Además se suma que el supuesto Plan de Contingencias o de Continuidad de Negocio no ha funcionado, dado que la parada de seis horas es excesivo tiempo en el entorno hospitalario si se hubiera hecho el correspondiente BIA (Bussines Impact Analysis).

Y por último y como reflexión final, quisiera destacar que el nuevo Reglamento de desarrollo de la Ley 15/1999 de Protección de Datos, ha incluido importantes y significativas reformas en torno a la figura del "encargado de tratamiento", que desde la perspectiva de la seguridad van en la línea de mejorar el control y la externalización del riesgo sobre los terceros.

Artículo 20. Relaciones entre el responsable y el encargado del tratamiento.
1. El acceso a los datos por parte de un encargado del tratamiento que resulte necesario para la prestación de un servicio al responsable no se considerará comunicación de datos, siempre y cuando se cumpla lo establecido en la Ley Orgánica 15/1999, de 13 de diciembre y en el presente capítulo. El servicio prestado por el encargado del tratamiento podrá tener o no carácter remunerado y ser temporal o indefinido. No obstante, se considerará que existe comunicación de datos cuando el acceso tenga por objeto el establecimiento de un nuevo vínculo entre quien accede a los datos y el afectado.

2. Cuando el responsable del tratamiento contrate la prestación de un servicio que comporte un tratamiento de datos personales sometido a lo dispuesto en este capítulo deberá velar por que el encargado del tratamiento reuna las garantías para el cumplimiento de lo dispuesto en este Reglamento.

3. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato al que se refiere el apartado 2 del artículo 12 de la Ley Orgánica 15/1999, de 13 de diciembre, será considerado, también, responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente.
No obstante, el encargado del tratamiento no incurrirá en responsabilidad cuando, previa indicación expresa del responsable, comunique los datos a un tercero designado por aquél, al que hubiera encomendado la prestación de un servicio conforme a lo previsto en el presente capítulo.

Artículo 21. Posibilidad de subcontratación de los servicios.
1. El encargado del tratamiento no podrá subcontratar con un tercero la realización de ningún tratamiento que le hubiera encomendado el responsable del tratamiento, salvo que hubiera obtenido de éste autorización para ello. En este caso, la contratación se efectuará siempre en nombre y por cuenta del responsable del tratamiento.

2. No obstante lo dispuesto en el apartado anterior, será posible la subcontratación sin necesidad de autorización siempre y cuando se cumplan los siguientes requisitos:

1. Que se especifiquen en el contrato los servicios que puedan ser objeto de subcontratación y, si ello fuera posible, la empresa con la que se vaya a subcontratar.  Cuando no se identificase en el contrato la empresa con la que se vaya a subcontratar, será preciso que el encargado del tratamiento comunique al responsable los datos que la identifiquen antes de proceder a la subcontratación.
2. Que el tratamiento de datos de carácter personal por parte del subcontratista se ajuste a las instrucciones del responsable del fichero.
   
3.  Que el encargado del tratamiento y la empresa subcontratista formalicen el contrato, en los términos previstos en el artículo anterior.
   

En este caso, el subcontratista será considerado encargado del tratamiento, siéndole de aplicación lo previsto en el artículo 20.3 de este reglamento.

3. Si durante la prestación del servicio resultase necesario subcontratar una parte del mismo y dicha circunstancia no hubiera sido prevista en el contrato, deberán someterse al responsable del tratamiento los extremos señalados en el apartado anterior.

En los aspectos de seguridad del R. D. se tiene:
Artículo 82. Encargado del tratamiento.

1. Cuando el responsable del fichero o tratamiento facilite el acceso a los datos, a los soportes que los contengan o a los recursos del sistema de información que los trate, a un encargado de tratamiento que preste sus servicios en los locales del primero deberá hacerse constar esta circunstancia en el documento de seguridad de dicho responsable, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento. Cuando dicho acceso sea remoto habiéndose prohibido al encargado incorporar tales datos a sistemas o soportes distintos de los del responsable, este último deberá hacer constar esta circunstancia en el documento de seguridad del responsable, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento.

2. Si el servicio fuera prestado por el encargado del tratamiento en sus propios locales, ajenos a los del responsable del fichero, deberá elaborar un documento de seguridad en los términos exigidos por el artículo 88 de este reglamento o completar el que ya hubiera elaborado, en su caso, identificando el fichero o tratamiento y el responsable del mismo e incorporando las medidas de seguridad a implantar en relación con dicho tratamiento.

3. En todo caso, el acceso a los datos por el encargado del tratamiento estará sometido a las medidas de seguridad contempladas en este reglamento.

Es de destacar lo apostillado en el artículo 22, donde obliga de alguna manera al responsable de los datos a ejercer como tal y controlar el cumplimiento de sus prestadores en la frase "Cuando el responsable del tratamiento contrate la prestación de un servicio que comporte un tratamiento de datos personales sometido a lo dispuesto en este capítulo deberá velar por que el encargado del tratamiento reuna las garantías para el cumplimiento de lo dispuesto en este Reglamento." sobre todo, en lo referente a la seguridad de la información. Así que de nuevo, el cumplimiento de la protección de datos puede ser una buena escuela para hacer las cosas como Dios manda. Está muy bien eso de ceder el marrón a un tercero, pero esa delegación no exime de responsabilidad. Si eres el que cede o transfiere el riesgo, la adecuada gestión es verificar que ese tercero estará a la altura de las circunstancias y que los servicios que presta, reunen las garantías mínimas necesarias para salvaguardar tus intereses. 

Por que de lo contrario, cuando el Responsable de Seguridad vaya a comprobar qué ha pasado, podrá encontrarse al Steve Urkel de turno diciendo ¿he sido yo? y la cabeza a cortar será la que quien contrató un servicio inadecuado.

La importancia del análisis del riesgo dentro del SGSI

Desde junio de este año, ya contamos con una nueva norma dentro de la serie ISO 27000. Se trata de quizás, una de las normas más estructurales de la serie ya que establece un criterio sobre la gestión del riesgo y proporciona un marco normalizado que nos puede ayudar a definir nuestra propia metodología y que tiene por título
ISO/IEC 27005:2008, Information technology -- Security techniques -- Information security risk management.

El análisis del riesgo es crucial para el desarrollo y operación de un SGSI. Aunque se habla mucho del tema, en esta fase la organización debe construir lo que será su "modelo de seguridad", una representación de todos sus activos y las dependencias que estos presentan frente a otros elementos que son necesarios para su funcionamiento (edificios, suministros, sistemas informáticos, etc.) y su mapa de amenazas (una hipótesis de todo aquello que pudiera ocurrir y que tuviera un impacto para la organización).

Es habitual, dada todavía la poca experiencia que existe en empresas sobre la seguridad que el análisis de riesgos lo realice la consultora externa que apoya en el proceso de implantación. Sin embargo, es muy importante que la empresa se involucre en esta actividad y entienda cómo se ha realizado este análisis. Sobre todo porque en el segundo ciclo del SGSI, se debe revisar éste análisis por si han habido cambios. Por hacer un simil que se entienda, el análisis de riesgos es como la visita al doctor para que nos identifique una enfermedad. Se realizan una serie de actividades como son: identificación de activos, identificación de amenazas, estimación de impactos y vulnerabilidades y con todo ello ya se puede calcular el riesgo. Pero éste diagnóstico es válido sólo para ese momento puntual en el tiempo. No es algo estático sino que va a cambiar a lo largo del tiempo: nuevos activos, nuevas amenazas, modificación en la ocurrencia de las amenazas (pensar por ejemplo en el caso del phishing como esta amenaza ha pasado a ser extremadamente frecuente en este último año). Por tanto, cada año la organización debe replantearse su diagnóstico y cuestionarse si tiene nuevos sintomas o si los sintomas detectados han sido ya mitigados y se pueden tratar otras carencias de menor importancia. La mejora continua afecta también al riesgo ya que si los niveles más altos se han solucionado, lo lógico es plantearse para el siguiente año atacar los siguientes.

Es curioso además comprobar como la "gestión del riesgo de la seguridad " empieza a ser vista con buenos ojos por otras áreas que se dedican a gestionar el riesgo. Hablo por ejemplo del caso de las entidades financieras que en virtud a Basilea II deben tratar el riesgo operacional. La tecnología es un riesgo operativo, y en algunas organizaciones el área de seguridad ha entrado a formar parte de la gerencia de riesgos, así como ahora el área de seguridad está entrando a formar parte en las empresas del compliance.

En este área nueva, existe un gran interés estudiar y comprender mejor el concepto del riesgo. Yo tengo un especial cariño a esta actividad porque fue por la que me introduce en esto de la seguridad hace ya casi diez años probando la primera versión de MAGERIT. Desde entonces el enfoque y la madurez de esta actividad ha cambiado y mejorado mucho, tratando de huir de la subjetividad de las valoraciones para llegar a un proceso formal, metódico y racional de valoración del riesgo.
Gracias a www.iso27000.es he podido dar con FAIR. Esta aproximación trata de ofrecer las bases fundamentales del proceso, una descripción de los conceptos a utilizar, así como un marco para la realización de análisis de riesgos. Es importante señalar que gran parte del marco FAIR puede utilizarse para reforzar, en lugar de sustituir, los procesos de análisis de riesgos basados en metodologías tan conocidas como OCTAVE, MAGERIT, MEHARI. Esta documentación se puede descargar en FAIR.

La Agencia Europea para la Seguridad de la Información (ENISA) dispone en el siguiente enlace de un inventario de las metodologías más conocidas que existen en torno a este tema que se puede consultar en este enlace.

Otra de las cosas más atractivas de esta actividad, el análisis y la gestión del riesgo es su faceta psicológica. El riesgo se define en el diccionario como la proximidad a un daño. Formalmente sería el factor que pondera la vulnerabilidad frente a una amenaza y el impacto que puede ocasionar. Navegando he podido encontrar un texto curioso sobre esa gestión inconsciente que hacemos los humanos del riesgo.

Fuente: Teoría de compensación del riesgo.

La causa de esta aparente contradicción fue desvelada hace más de veinte años por varios psicólogos especializados en tráfico, especialmente en Canadá y en los países escandinavos, mediante la teoría conocida como la “Compensación del riesgo” 1. Según esta teoría, cualquier persona situada en un entorno de riesgo adapta su comportamiento a los cambios del nivel de riesgo que percibe. Si detecta un riesgo creciente, actuará de forma más cautelosa, y si por el contrario detecta un riesgo decreciente, se comportará de un modo más despreocupado. De este modo “compensa” los cambios del nivel de riesgo, volviendo a situarse en el nivel de riesgo que considera aceptable, que normalmente es variable para cada persona.

En el caso concreto del tráfico, ello supone que si los conductores son conscientes de que llevan un coche con más equipamiento de seguridad, o de que circulan por vías más seguras, muchos de ellos tenderán a utilizar más el automóvil, y sobre todo, a realizar una conducción más arriesgada. Estos conductores “aprovecharán” la reducción del riesgo que han percibido para satisfacer algún deseo personal: ganar tiempo, practicar una conducción más excitante, probar las prestaciones del automóvil, etc..

Puede ocurrir que algunos de estos conductores sobrevaloren la reducción de riesgo que les ofrece un nuevo automóvil o una nueva carretera. En tal caso, se puede dar la paradoja de que estos conductores se acaben situando en niveles de riesgo efectivo más elevados que en la situación anterior. La influencia de estos grupos de riesgo incrementado puede hacer que, estadísticamente, los resultados globales de seguridad vial no mejoren, aunque la sociedad haya realizado grandes inversiones en viario, o en nuevos automóviles. Esto es lo que, en términos muy generales y orientativos, puede estar pasando en España y en otros países en los últimos años.

Estos hechos podrían ser encajados dentro de algunas de las Máximas de Seguridad que Bruce Schneier ha posteado hace unos días y que también ha comentado Sergio Hernando. Me quedo con la misma que se queda Sergio y otra mas:
Backwards Maxim: Most people will assume everything is secure until provided strong evidence to the contrary--exactly backwards from a reasonable approach. (la mayoría de la gente asumirá que todo es seguro hasta que se les muestren evidencias significativas de lo contrario, justo lo contrario de lo que sugiere una aproximación razonable)

Arrogance Maxim: The ease of defeating a security device or system is proportional to how confident/arrogant the designer, manufacturer, or user is about it, and to how often they use words like "impossible" or "tamper-proof". (La facilidad de atacar un dispositivo o sistema de seguridad es proporcional a la confidencialidad/arrogancia del diseñador, fabricante o responsable de seguridad y a la frecuencia con la que éstos usan palabras como "imposible" o "impenetrable".