Sistemas de Gestión Seguridad de la Información

Ciberseguridad, minuto y resultado: Los malos 3, Los buenos 0.

noreply@blogger.com (Javier Cao Avellaneda) — Thu, 12 Jun 2014 06:56:00 +0000

Mucho se habla últimamente de ciberseguridad y la verdad es que la cuestión debería empezar a preocupar. Cuando ves a tanto experto comentar que la situación está empeorando con titulares como "el mayor ataque ciberterrorista es cuestión de tiempo" de Eugene Kaspersky hemos de suponer que las cosas deben estar muy feas. Tal como expresa el titulo del post quiero aportar mi visión de la situación partiendo de la realidad que me toca analizar día a día y teniendo en cuenta que quien escribe es un profesional de provincia que analiza la realidad de empresas que no están situadas dentro del Ibex 35. En cualquier caso al menos creo interesante comentar cómo se ven las cosas por estas tierras, aunque sean de segunda división.

En primer lugar creo muy relevante hacer constar que la ciberseguridad no es una moda sino más bien una amenaza invisible que no todo el mundo es consciente de que exista o lo que es peor aún, de que pueda impactarle. Obviamente no es cuestión tampoco de dramatizar porque todo este tipo de daños afecta a la información pero cada vez más las consecuencias de la inseguridad sobre los datos pueden alterar el mundo físico y provocar ya daños tangibles y concretos sobre el mundo real. Conscientes de la necesidad de hacer visible este tipo de amenazas, empresas del mundo de la seguridad han empezado a mostrar diferentes tipos de visualizaciones sobre el análisis de tráfico en tipo real que muestra como efectivamente estas cosas suceden. Aquí os presento 12 de ellas siendo la de Kaspersky de las más impactantes.

1 - Cyber Warfare Real Time Map by Kaspersky (Visualización que recomiendo)

2 - Real-time Web Monitor by Akamai

3 - IpViking Live Map by Norse

4 - Honeypots from the Honeynet Project

5 - Global Botnet Threat Activity Map by Trend Micro

6 - Top Daily DDoS Attacks Worldwide by Google

7 - Security Tachometer by Deutche Telekom

8 - Cyberfeed Live Botnet Map by AnubisNetworks

9 - Global Activity Maps by Arbor

10 - DDoS Attacks by ShadowServer

11 - Internet Malicious Activity Maps by TeamCymru

12 - Globe and WorldMap by F-Secure

Voy ahora a narrar, cual periodista deportivo cómo se han producido cada uno de los 3 goles que anunciaba en el titulo del post.

Primer gol (En los primeros minutos de partido).

El primer tanto lo marcan los malos en los primeros minutos cuando la industria del software en general no es casi penalizada por la generación de productos inseguros. Hablamos constantemente de los problemas ocasionados por los fallos software y la necesidad de gestionar la vulnerabilidad pero muy poco sobre la importancia de la seguridad en el diseño. En este tema solo las empresas muy castigadas por el malware fueron capaces de reorientar el proceso de fabricación de software y definir la Trusted Computing. Schneier insiste dentro de su visión económica de la seguridad que mientras sea más barato poner remedio que solventar el problema en el origen, nada motivará a la industria del software a hacer bien las cosas. Y teniendo en cuenta que ahora software tiene casi cualquier cosa, tenemos un problema gordo con la dispersión del software a todas las actividades humanas. En esencia lo que más preocupa actualmente es la seguridad del software orientado a la informática industrial que controla los automatismos en las grandes empresas y las infraestructuras críticas. Es un tema tan específico que en España se ha creado el Centro de Ciberseguidad Industrial y está centrándose en estos temas, es decir, seguridad de la información sobre entornos industriales donde es complejo aplicar las políticas de gestión de la seguridad que se aplican en otros sectores porque son entornos operativamente complejos que no pueden parar su actividad.

Segundo gol (A mitad de partido).

El segundo gol podríamos considerarlo que se ha metido en propia meta dado que está más causado por la falta de control del equipo que defiende que por los méritos del equipo que ataca. Ésta es por tanto una segunda ventaja del mundo del cibercrimen sobre las empresas y está ocasionado por la ausencia o carencia de recursos en el área TIC de las organizaciones para luchar contra estas cyberamenazas. Los departamentos de sistemas de información de las empresas están diseñados para aportar valor y ello se produce diseñando y desarrollando sistemas que amplíen u optimicen el modelo de negocio establecido. En este sentido, los departamentos tienen como misión construir cosas, no preservar los entornos para que los malos no puedan boicotearlos , robarlos o destruirlos. Por tanto, una primera desventaja es la falta de personal especializado que monitorice y vele por el control de la situación. Lo que no deja de resultarme paradójico es ver como las empresas si tienen clara la protección física para amenazas del entorno cercano (Siendo estas quizás poco frecuentes y con pocos agentes agresores) y no para Internet que es un escenario hostil, globalizado y con muchos agentes agresores. Supongo que la causa de ello debe ser la ausencia de percepción de peligro que nos genera la conexión a Internet. En las empresas medianas y pequeñas este tipo de cosas siguen viendose como "de película". El principal problema por tanto es que si nadie mira, cuando las cosas empeoren (Que es lo que está ocurriendo), nadie podrá dar aviso para reaccionar a tiempo. Todavía no nos hemos adaptado al cambio de mentalidad que supone Internet. Como comenta el ensayo titulado Ciberataques por Mikko Hypponen dentro del último libro de la serie BBVA “C@mbio: 19 ensayos clave acerca de cómo Internet está cambiando nuestras vidas”o los cambios son más grandes de lo que parecen.

"El mundo real no es como el mundo online. En el mundo real sólo hemos de ocuparnos de los delincuentes que

En el mundo real solo hemos de preocuparnos de los delincuentes que viven en nuestra ciudad. Pero en el mundo online tenemos que preocuparnos de delincuentes que podrían estar en la otra punta del planeta. La delincuencia online siempre es internacional, ya que Internet no conoce fronteras".

Por tanto, debemos entender que la amenaza existe y que no tiene porqué haber una motivación directa para que uno acabe siendo victima de un incidente. Ahí están las estadísticas que documentan las diferentes motivaciones en los casos más relevantes.

Además, los datos no van a mejorar porque tal como indica Mikko Hypponen, la presión policial sobre el cibercrimen es insuficiente.

"Cuando se ponen en un lado de la balanza los daños producidos por la ciberdelincuencia y en el otro la pérdida de vidas humanas, salta a la vista cuáles son más importantes. Adaptarse al rápido crecimiento de la delincuencia online resulta una tarea harto difícil para las fuerzas nacionales de policía y los sistemas legales, pues cuentan con capacidades y recursos limitados para sus investigaciones. Las víctimas, la policía, los fiscales y los jueces casi nunca descubren el auténtico alcance de estos delitos, que se suelen producir más allá de las fronteras nacionales. Los procesos penales contra los delincuentes son muy lentos, los arrestos, contadísimos y, con excesiva frecuencia, las penas impuestas resultan demasiado leves, en especial si se comparan con las de los delitos perpetrados en el mundo real. La baja prioridad que se concede a perseguir a los ciberdelincuentes y la demora en el establecimiento eficaz de penas por delitos cibernéticos transmiten un mensaje equivocado y es el motivo por el que la delincuencia online aumenta a gran velocidad. Ahora mismo, los delincuentes potenciales online son conscientes de que las probabilidades de ser descubiertos y castigados son mínimas y de que los beneficios son enormes."

Hace unos días también se publicaba en El País un titular escandaloso al respecto, "El 95% de los ciberdelitos cometidos quedan impunes". Esta situación de aparente impunidad más el incremento en los réditos obtenidos por los ciberdelincuentes son el caldo de cultivo ideal para que esta "miel" atraiga a más abejas a comer. Las estadísticas dan miedo pero como no se genera alarma social suficiente (Al fin y al cabo solo afecta a información), los esfuerzos policiales se orientan hacia temás de menos envergadura pero más mediáticos (Recordemos que los recursos policiales se deciden desde la capa de la política).

Tercer gol (A final de partido).

Este es quizás el único gol que pueden apuntarse realmente los malos y que se corresponde con el esfuerzo que desarrollan realmente en buscar la forma de lucrarse a costa de los sistemas de información ajenos. En parte, como hemos visto en los dos goles anteriores, sobre un terrerno de juego que no les pone las cosas muy difíciles, han conseguido desarrollar una auténtica industria del malware que ya ha logrado superar las medidas de seguridad perimetral más comunes (Firewalls y antivirus).

Que es una industria no lo duda nadie con solo ver su capacidad de fabricación y el crecimiento esponencial del número de especímenes generados. No es posible semejante ritmo de producción sin organizaciones bien orquestadas que colaboran en la generación de aplicaciones cada vez más sofisticadas que trabajan de forma cada vez más silenciosa. Además, el concepto de malware ha evolucionado hacia el de APT donde la aplicación maliciosa se encuentra durante tiempo en los sistemas de información agazapada, recolectando datos hasta que decide atacar a la víctima. Sobre el tema de APT me parece interesante destacar la reciente revisión realizada por el blog Aeropago21 en el post "Operaciones APT famosas". El año 2013 fue el que dió a conocer esta nueva variante de malware cuando Mandiant hizo publico el informe "APT1: Exposing One of China's Cyber Espionage Units". Desde entonces mucho se habla del tema pero la noticia de hace unos días que más llama la atención ha sido la declaración de Symantec sobre la poca eficacia de los antivirus con el titular de cabecera Antivirus pioneer Symantec declares AV “dead” and “doomed to failure”.

Como muestra la siguiente gráfica, el crecimiento exponencial del número de muestras de malware hace predecible que las tecnologías basadas en la detección de patrones dentro de código no van por buen camino.

La gente de la industria lleva hablando de esto hace tiempo aunque no era políticamente correcto siendo creo los primeros la gente de Hispasec que en esto siempre han sido la referencia. Quizás el problema más grave que tiene este nuevo escenario es la existencia de clases también dentro del ciberespacio. Dado que las soluciones actuales no están frenando el malware, las empresas se van a segmentar en tres tipos:

Las que tienen buen presupuesto de seguridad y que adquirirán las nuevas tecnologías de protección basadas en el análisis del comportamiento del software y no en patrones. Estos dispositivos tienen un precio alto que no todo el mundo puede asumir.

Las que se refugiarán en bastiones bien protegidos subiendo a infraestructuras de nube bien protegidas, alojando sus sistemas dentro de ciudades bien amuralladas que si hayan podido hacer la inversión en protección para amortizarla vendiéndola como servicio de seguridad en nube.

Las que ni saben que los firewalls y antivirus ya no son efectivos y permanecerán de forma incosciente expuestas a la red y a sus sustos. Por desgracia en este segmento se van a situar el 90% de las empresas pequeñas o medianas que ven en la ciberseguridad todavía un tema de ciencia ficción.

El cambio de contexto del que pocas empresas se están dando cuenta respecto de la sofisticación del malware (Y ocasionado por la carencia de personal propio especializado que vaya analizando las amenazas existentes y actualizando los análisis de riesgos como se vió en el segundo gol) es que los malos han aprendido como saltarse las medidas de seguridad. El malware ahora no viene en forma de ejecutable catalogado por el antivirus sino como un software inofensivo que el antivirus no es capaz de detectar. En la ejecución inicial detecta que le faltan trozos y se conecta de forma cifrada hacia los host desde los que poder completarse. Todo ello hablando protocolos comunes como http y utilizando cifrado en el intercambio de información para que los firewalls más avanzados tampoco puedan analizar el contenido del tráfico. En el fondo los malos están utilizando las mismas técnicas que se emplean en la protección legítima de datos pero para unas finalidades diferentes. Por tanto, con este nivel de sofisticación las medidas tradicionales ya están siendo superadas.

Curiosamente además se produce un fenómeno perverso y es la siguiente paradoja:" Quien no puede invertir en seguridad puede tener que asumir mucho más coste ocasionado por la inseguridad". La gestión del riesgo nos lleva a cuatro opciones posibles: trasferir, evitar, reducir o aceptar. A menudo, las capas directivas no asumen que "No hacer nada" es tomar como decisión "aceptar el riesgo" y se arrepienten de la decisión sólo cuando tienen que afrontar los costes de la inseguridad asumida. En este sentido empieza a ser cada vez más necesario evaluar el "coste de la insegurida" y utilizar como métricas de valoración económica los conceptos "CAPEX" y "OPEX". Aun no siendo un experto en la materia, me voy a atrever a hacer un planteamiento económico de la gestión de la seguridad a ver que os parece. Espero que Antonio Ramos lea esto y me corrija si estoy enfocando mal estos conceptos económicos.

Pensemos en un supuesto real de gestión del malware. Sería el caso de un departamento TI que plantea la

adquisición de un equipo avanzado que puede detectar el 50% más de malware que el firewall tradicional.

Aunque la inversión inicial fuera alta (CAPEX o coste de capital), el coste operacional (OPEX o coste operativo) causado por el gasto en personal que tiene que solventar los incidentes detectados hace que a medio y largo plazo, la decisión basada en adquirir el equipo avanzado sea más rentable. Al final de un año cada decisión tendría los siguientes números suponiendo un coste de 30€ de mano de obra por cada acción de limpiar un equipo de malware:

Decisión de no hacer nada tendría estos números: CAPEX: 0€+ OPEX: 378.000€ = 378.000€

Decisión de gestionar el riesgo: CAPEX: 3.000€+ OPEX: 189.000€ = 279.000€

Como muestra el gráfico, una decisión técnica de apuesta por la mejora operacional tiene a medio y largo plazo un resultado más rentable que la decisión de no hacer nada. Además, la aceptación del riesgo está expuesta también a la aleatoriedad del entorno y a la evolución de la tendencia. Es decir, si la agresividad del malware se incrementa, los costes operativos aumentan significativamente siendo entonces la separación entre ambos enfoques mayores. Esto ha sido simplemente un ejemplo sencillo para intentar hacer ver que "no hacer nada" es ya hacer algo y que pensando en rentabilidad económica, puede incluso ser una decisión peor que la que no se quiere asumir por costes iniciales.

Análisis detallado de la nueva ISO 27001:2013

noreply@blogger.com (Javier Cao Avellaneda) — Mon, 14 Oct 2013 20:41:00 +0000

Tras unos días de vigencia de la nueva ISO 27001:20013 y tras haber realizado ya una lectura más reposada y meditada del nuevo estándar y los cambios introducidos solo puedo decir que esta me gusta mucho el texto de esta versión y que ahora está “mejor enfocada” hacia la valoración del funcionamiento del SGSI por los resultados operativos relacionados con el cumplimiento de los objetivos de seguridad.

En un mundo donde cada vez más la gestión TI es externalizada o delegadas ciertas partes a sistemas que no son propiedad de la organización, es necesario al menos tener identificados los riesgos y garantizar sobre todo que a pesar de eso, podemos proporcionar protección de información a “nuestras partes interesadas” (clientes y los propios departamentos de la Organización).

Como esta revisión ha sido exhaustiva y completa he preferido crear un documento completo con los comentarios sobre la nueva norma para que sea descargable y más manejable que el texto incrustado en el blog.

Podéis proceder a la descarga del documento con licencia Creative Common en este enlace:

Análisis detallado de la nueva ISO 27001:2013

La nueva norma va a tener como consecuencia que empecemos todos a hablar del ansiado "cuadro de mando" de la seguridad de la información. Algo en lo que ya he empezado a investigar y cuyo origen parte de las reflexiones colgadas en el post Ciberdefensa: taxonomía de eventos de seguridad.

Las dificultades del ser humano para la percepción del riesgo TI

noreply@blogger.com (Javier Cao Avellaneda) — Mon, 11 Jul 2011 06:26:00 +0000

En el blog de Inteco he dejado algunas reflexiones sobre el por qué creo que sigue costando tanto ver la necesidad de la seguridad de la información por parte de los perfiles de Dirección. El artículo completo se puede leer en esta dirección del Observatorio del Inteco. A continuación resumo los principales puntos:

1. Modelos de negocio de las organizaciones: Toda organización puede ser vista como un gran proceso que recibe ciertas entradas y genera ciertas salidas. En este sentido, la cadena de valor de la organización viene dada por los procesos de transformación de las materias primas (sean bienes tangibles o intangibles) en resultados económicos. Fruto de la evolución hacia la sociedad de la información y el conocimiento, cada vez son más las organizaciones cuyo modelo de negocio se basa en el procesado de información como materia prima para la entrega de productos que son resultado de aglutinar o procesar dicha Información. Pensemos en las empresas de servicios TI como Google, Facebook, Linkedin o en fabricantes de productos software como Microsoft o Apple. En estos casos, el valor está asociado al coste de producción o construcción de servicios y muy vinculado con la propiedad intelectual necesaria para poderlos elaborar. Primera dificultad para nuestra mente en relación a juzgar el valor de la información.

2. Modelo económico del valor: Vivimos en una sociedad capitalista donde el valor de las cosas debe ser materializado por el criterio monetario de su coste o de su estimación económica. Por tanto, la percepción del valor de las cosas utiliza un criterio basado en el precio o valor económico de los objetos. Ante la pregunta de qué vale más, si un servidor o un llavero USB, nuestro instinto juzgara que será más valioso el objeto más grande o el más complejo. Este modelo instaurado es quizás uno de los factores por los que no se valora de forma adecuada la “propiedad intelectual”, porque seguimos juzgando el precio por la valía de los objetos. Segunda dificultad de nuestra mente en relación a juzgar el valor de la información.

3. Modelo operativo de las organizaciones: Las organizaciones recurren cada vez más al uso de las Tecnologías de la Información para dar soporte a sus actividades principales o primarias de negocio. Por tanto, el área TI es una actividad secundaria o de soporte según el modelo de valor de la cadena de Porter. Ello significa que existe una dependencia entre las actividades que generan valor y el buen funcionamiento de las piezas necesarias que están por debajo dando soporte a esos procesos productivos. Para las áreas directivas y no técnicas, las herramientas son las diferentes aplicaciones o sistemas como el correo electrónico que son necesarias para su día a día. Dadas sus carencias en conocimientos técnicos no son capaces de pensar en la cantidad de elementos técnicos que deben funcionar correctamente para que ellos no tengan ningún problema. Se abstraen completamente de la infraestructura TI que necesita su organización para poder funcionar. Y esta forma de ver al área técnica ahora se ha consolidado como un área creciente de negocio bajo las siglas "Cloud Computing" que viene a ofrecer un pago por servicios y uso de aplicaciones siendo un tercero el que asume el coste y la gestión de la infraestructura TI. Tercera dificultad para nuestra mente en relación a valorar la complejidad subyacente que da soporte al tratamiento de la Información.

4. Modelo humano de gestión del miedo: Nuestra mente es un dispositivo esencial para garantizar nuestra supervivencia. La evolución ha entrenado a nuestro cerebro para que sea capaz de sobrevivir pero bajo un contexto basado en garantizar el alimento y la protección frente a depredadores. Nuestros antecesores tenían como actividades básicas el comer o subsistir y nuestros mecanismos de alerta o detección del peligro están vinculados a hechos físicos visibles, tangibles y sensitivos. Por tanto, nos da miedo aquello que fundamentalmente se produce por situaciones o escenarios de amenaza física como puedan ser terremotos, riadas, explosiones, incendios, etc. ¿Qué pasa entonces con las amenazas sobre la información?. Pensar en miedo ante una situación de hacking informático, un robo de datos o una suplantación de identidad es algo que al ser humano le cuesta bastante sentir. Solo son adecuadamente juzgadas estas situaciones cuando podemos establecer una relación directa causa-efecto entre los siguientes elementos: amenaza, activo, daño, consecuencias económicas o de otra naturaleza. Solo en aquellas situaciones donde tengamos cierta estimación del daño que supone un incidente relacionado con la información podremos sentir miedo y disparar por tanto los mecanismos de gestión del riesgo. Un hecho significativo que puede ilustrar esta cuestión es que muchas de las temáticas de ficción en cine ahondan sobre tramas donde el personaje principal sufre las consecuencias físicas debido a problemas sobre sistemas de información. Quizás el mejor ejemplo de este tipo de películas puedan ser “La jungla de cristal 4” o “Firewall”. Cuarta dificultad para nuestra mente respecto a la percepción del peligro en amenazas que afectan a la información dado que raramente somos capaces de valorar las consecuencias de un incidente con elementos que generen miedo sobre nuestra supervivencia.

5. Modelo humano de gestión del riesgo: Nuestra mente es un dispositivo esencial en garantizar nuestra supervivencia. La evolución ha entrenado a nuestro cerebro para que capaz de sobrevivir pero bajo un contexto basado en garantizar la supervivencia física. Por tanto, el elemento esencial a la hora de tomar decisiones está fundamentado en el miedo que es una fuerza poderosa y con temor la toma de decisiones puede producir resultados nefastos. Por lo que parece, nuestro cerebro procesa el riesgo de dos maneras diferentes y complementarias:

La primera es intuitiva, emocional y basada en la experiencia. Este parece ser un mecanismo de supervivencia evolutiva. En presencia de incertidumbre, el miedo es una valiosa defensa. Nuestro cerebro reacciona emocionalmente pero sin realizar un análisis objetivo del riesgo potencial.
La segunda forma en mediante el análisis de riesgos: la utilización de probabilidad y estadística para anular, o por lo menos priorizar nuestro temor. Es decir, nuestro cerebro juega de abogado del diablo con su primera reacción intuitiva, y trata de justificar las probabilidades reales de que pase algo para tomar una decisión final.

Lamentablemente para nosotros el análisis de riesgos no es la parte que gana. La intuición o el miedo pueden abrumar fácilmente a la parte analítica, especialmente cuando nuestro cerebro en situaciones de miedo recupera imágenes grabadas en la memoria sobre catástrofes, accidentes o experiencias desagradables que quedan más fácilmente almacenadas por la memoria emocional. Por tanto, nuestro cerebro tiende a ignorar los riesgos que son difíciles de comprender o de percibir. Pero eso no hace que las probabilidades de ocurrencia disminuyan sino que simplemente nuestra percepción del riesgo cambie.

Como ejemplo de reflexión pensemos en cualquier organización. En general siempre nos encontramos con unas medidas básicas de seguridad física como son tener puertas y ventanas, disponer de alarmas presenciales, video vigilancia, etc. Si pensamos en los primeros tipos de engaño en relación a la percepción del valor, las organizaciones ya no solo tienen los puntos "físicos" de entrada a sus instalaciones sino que ahora hay medios lógicos de acceso como puede ser la página web, el correo electrónico, las conexiones remotas, etc. ¿Cómo están protegidos esos puntos de acceso a la Organización, de igual forma que los puntos de acceso físico? La respuesta común es que no. Las medidas de protección que nadie discute son aquellas que garantizan el valor tangible de los activos tangibles de las Organizaciones, es decir, sus edificios, sus instalaciones, sus oficinas, todo aquello que tiene un valor económico tangible y fácilmente estimable que justifica la ecuación de la seguridad en relación al coste de la protección y la inversión en prevenir daños.

Sin embargo, en los aspectos de seguridad lógica las cosas no están ni por asomo tan controladas. Quizás será necesario que la evolución se encargue de hacernos aprender a base de malas experiencias para que evolucionemos nuestros miedos con el fin de adecuarlos a las nuevas situaciones y circunstancias del siglo XXI.

Viernes, toca humor y seguridad

noreply@blogger.com (Javier Cao Avellaneda) — Fri, 26 Feb 2010 07:57:00 +0000

Vía el twitter de Eddasec he llegado a este video que no deja de ser una parodia pero que revela cuales son los conflictos bélicos que se pueden plantear en el futuro y las dificiles relaciones de las empresas con sus proveedores TI.
En situaciones como esta es donde los controles de ISO 27002:2005 en relación a los objetivos de control .6.2 y 10.2 es donde demuestran si se está a la altura o no.

Feliz fin de semana.

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

noreply@blogger.com (Javier Cao Avellaneda) — Mon, 22 Feb 2010 22:26:00 +0000

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 de 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

noreply@blogger.com (Javier Cao Avellaneda) — Thu, 14 Jan 2010 08:20:00 +0000

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.

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

noreply@blogger.com (Javier Cao Avellaneda) — Fri, 30 Oct 2009 11:29:00 +0000

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

noreply@blogger.com (Javier Cao Avellaneda) — Mon, 15 Jun 2009 15:32:00 +0000

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".
Como complemento a lo dicho en él, hay unas sencillas reglas que debe cumplir una buena métrica:

Ser objetivas:Debe aportar un criterio de recogida de datos medible y objetivo, que no dependa de valoraciones subjetivas.

Ser fáciles de obtener:Los datos sencillos, simples de calcular y poco costosos de recoger son buenos candidatos a ser métricas. Al respecto, lo más sencillo es recurrir a datos proporcionados por herramientas o procesados de forma automatizada.

Expresables de forma numérica o porcentual. No deben estar basados en etiquetas cualitativas tales como "alto", "medio" o "bajo".
Expresable usando algún tipo de unidad de medida: Siempre deben estar vinculadas a algo tangible basado en escalas como el tiempo, número de defectos, a cuantías económicas.

Significativas: Toda buena métrica debe ser significativa, debe ser relevante para el hecho o circunstancia que se desea medir y debe aportar criterio. Una métrica que no aporta información no es una buena métrica y debe ser desechada.

Problemáticas de los proyectos de implantación de SGSI

noreply@blogger.com (Javier Cao Avellaneda) — Fri, 22 May 2009 13:01:00 +0000

Patricia Vanaclocha, de S2 Grupo tiene dos entradas excelentes que describen perfectamente la problemática que se plantea cuando uno se embarca en esto de construir un SGSI. Podéis leerlas en

Errores comunes en la Implantación de un SGSI

Cosas a tener en cuenta en la implantación de un SGSI

Publicada ISO 27011:2008

noreply@blogger.com (Javier Cao Avellaneda) — Mon, 20 Apr 2009 21:33:00 +0000

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

noreply@blogger.com (Javier Cao Avellaneda) — Sat, 07 Mar 2009 08:40:00 +0000

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.

Diez años de seguridad de la información

noreply@blogger.com (Javier Cao Avellaneda) — Mon, 09 Feb 2009 20:45:00 +0000

Tal día como hoy, mi director de proyecto de fin de carrera me ofrecía participar en un proyecto piloto de la Universidad relacionado con el "Análisis de los riesgos de seguridad de la Información" para la Dirección General de Informática de la Comunidad Autónoma de la Región de Murcia.
Aquella oferta de trabajo era mi primera actividad profesional tras la finalización de la carrera y me puso entre las manos la versión 1.0 de MAGERIT junto con el software desarrollado por Sema Group para dar soporte a la metodología. El año 1999 fue, en temas de seguridad, bastante movidito. Todo el mundo iba como loco con las pruebas para superar el año 2000. Algunas aplicaciones de gestión económica empezaban la migración hacia el Euro. Además, en verano de ese año se publica el R.D. 994/1999 con las medidas de seguridad para los sistemas automatizados de tratamiento de datos de carácter personal.
Aunque este post no pretende ser un resumen de batallas de un abuelo cebolletas, recuerdo que las primeras referencias por aquel entonces en "gestión de la seguridad" venían establecidas por las Guias NIST y los libros conocidos como Rainbow Series de la NSA, en concreto el famoso libro naranja.

En aquel momento, los criterios de seguridad de la información americanos eran la referencia aunque ya empezaba a ser famosa la norma BS-7799 con las buenas prácticas para la gestión de la seguridad de la información.
Recuerdo que había dos visiones enfrentadas donde por un lado, los americanos establecían sus criterios propios para todo lo suyo y por otro, se hablaba de gestión de la seguridad de la información en base al cumplimiento de buenas prácticas. Este mismo choque de enfoques se producía en los criterios de certificación de productos de seguridad, donde los americanos defendían los TCSEC y los europeos los criterios ITSEC. Finalmente ambos criterios acabaron unificados bajo los "Common Criteria" o ISO 15408.

Al finalizar el proyecto con Magerit no tuve más opción que desplazarme a Madrid para seguir currando con esa nueva y apasionante disciplina conocida como "análisis de riesgos de la seguridad de la información". Por suerte, tuve la oportunidad de entrar en la empresa Innosec, una empresa dedicada a seguridad informática donde Gustavo San Felipe, hoy CISO de Acens apostó por un profesional con experiencia en análisis de riesgos dado que eso del diseño de la seguridad basado en el análisis de riesgos lo veía como algo esencial en el futuro. Era la época de la venta masiva de firewalls, de los primeros antivirus perimetrales y del inicio de las redes privadas virtuales. Y en medio de tanto cacharro estaba yo por allí purulando y dando el follón respecto a lo importante que era escribir políticas de seguridad y el cumplimiento de la LOPD. Fruto de aquella época son dos artículos en la revista SIC sobre "análisis de riesgos" e ISO 15408.
Posteriormente Innosec fue adquirida por el Grupo Satec y pasé a formar parte del departamento de seguridad. Allí más de lo mismo. Empresa muy tecnológica que vendía tanto productos como instalación y configuración de equipamiento de seguridad pero que me tenía como recurso dedicado a los temas burocráticos de la seguridad, el papeleo inutil que eran las políticas, normas y procedimientos. Recuerdo intensamente las discusiones en las comidas sobre la importancia del análisis de riesgos para el diseño de las necesidades de seguridad aunque era un entorno muy técnico que no podía entender como podía haber cosas más importantes que un buen firewall o antivirus. Incluso muchas veces cuando me ponía radical y comentaba que algún día las empresas se certificarían en seguridad igual que se hacía para la calidad con ISO 9000, me veían como el freaky de las políticas y normas de seguridad que nunca sirven para nada.
De aquella época, muy a mi pesar, me llevé puestas también algunas certificaciones de producto (CCSA de CheckPoint, TSCE de TrendMicro, MCP de Microsoft). Todo esto transcurrió entre el año 2000 a 2004. En materia de gestión de la seguridad de la información, ya estaba publicada ISO 17799:2000 y era una verdadera referencia respecto a qué era necesario considerar cuando se hablaba de "gestión de la seguridad de la información". Una vez cansado de hacer ofertas sobre diseño de políticas de seguridad y análisis de riesgos y tras finalizar un proyecto de diagnóstico del cumplimiento de la LOPD para un servicio de salud de una comunidad autónoma, decido que tenía que ejercer y bajar a la arena de los proyectos concretos relacionados con lo mio (gestión de la seguridad de la información) y un compañero de curso de seguridad me ofrece la oportunidad de dar un paso hacia Murcia y me bajo a Almería a trabajar para una empresa de servicios de una Entidad Financiera que tenía también un área de consultoría de seguridad de la información. El primer trabajo en esta nueva empresa consistió en la realización de un análisis diferencial contra ISO 17799:2000 y el desarrollo de una política corporativa de seguridad que sirviera de marco normativo para un conjunto de normas y procedimientos concretos. En esta empresa también tuve que currar bastante en materia de LOPD dado que la parte de medidas de seguridad intentábamos cubrirla como actividades integradas dentro de ISO 17799:2000 de la época. También, casi al final de esta época, se publica UNE 71502:2004 y me toca entrar ya de lleno en los sistemas de gestión de la seguridad de la información. Estuve impartiendo un cursos sobre UNE 71502 y la importancia de esto que ahora se podía certificar y que era la "gestión de la seguridad de la información". Todo esto transcurrió entre el año 2004 a comienzos del 2007. La verdad es que la publicación de ISO 27001:2005 nos pilló por sorpresa a todos, incluido AENOR. Se hablaba de una futura norma internacional certificable pero lo que en aquel momento se conocía es que cada país trabajaría con su propia norma dentro de su esquema interno de certificación para posteriormente hacer una norma común e internacional certificable. BS tenía su 17799-2, Aenor su UNE 71502 y otros países las suyas. Sin embargo, en 2005 se publica ISO 27001 que deja claro que debido a la importancia y las necesidades de normativa en esta materia, la norma internacional no podía esperar al 2008 que era para cuando se esperaba. Esto en España ha tenido como consecuencia los guisaguisados de los certificados UNE 71502 e ISO 27001 conviviendo un tiempo, hasta que se ha elaborado ya la UNE-ISO/IEC 27001:2007.

Finalmente (la historia ya está acabando), a mediados del 2006 me vuelvo a casa a trabajar en la consultora Firma, Proyectos y Formación S. L. dedicada en aquel momento a "protección de datos" que con mi incorporación, abre el área de "seguridad de la información". Y desde entonces hasta ahora, todos los proyectos han estado relacionados o bien con partes de un SGSI (sobre todo el análisis de riesgos, estudios diferenciales ISO 27002 o el desarrollo de marcos normativos de seguridad de la información) o bien con la construcción e implantación de SGSI, siendo actualmente la referencia más importante la lograda hace un par de años por la Consejería de Agricultura de la Región de Murcia, primera Administración Pública que logró una certificación acreditada bajo esquema UKAS.

Espero que este breve repaso a estos diez años de trayectoria profesional hayan servido para pintar unas breves trazas de cómo ha ido evolucionando esto de la "gestión de la seguridad de la información" hasta alcanzar ya su cuota de relevancia dentro de las organizaciones.

Solo espero y deseo que el ansia y la motivación que supone "certificarse bajo ISO 27001" no acabe prostituyendo a la propia seguridad de la información. Montar la documentación necesaria para establecer un sistema de gestión de lo que sea es fácil (Sólo son necesarios los procedimientos generales que establece todo SG) pero gestionar un SGSI requiere de conocimientos de seguridad de la información (si no sabes de aquello que quieres gestionar, dificilmente podrás controlarlo). En próximos días escribiré un post sobre "SGSI enfermos desde el diseño" que extracta unas primeras impresiones/conclusiones basadas en mis experiencias de estas últimas semanas auditando como auditor interno a varias empresas que han montado su propio SGSI. Mis impresiones no son buenas aunque aquí la principal responsabilidad la tienen las entidades de certificación respecto a su criterio para otorgar o no una certificación. Yo, como auditor/consultor percibo que las nuevas versiones de ISO 27001:2005 tienen que establecer de forma más contundente requisitos formales respecto a:

Criterios para que una metodología de análisis de riesgos sea correcta, fiable y completa.

Unos mínimos criterios sobre la gestión de la eficacia que hay que hacer para conocer qué y cuanto hay que medir.

Una nueva versión de la ISO 27002:2005 que incorpore nuevos objetivos de control y aglutine o agrupe controles dado que hay áreas que tienen relativamente pocos controles y otras que disponen de demasiados.

Por lo que estoy encontrándome al auditar, las cosas más comunes son:

Metodologías de análisis de riesgos que suponen lo mismo que sacar el dedo y decidir al azar los principales problemas de seguridad.

SGSI sin objetivos de seguridad o con unos indicadores que no sirven para nada para evaluar el cumplimiento de objetivos

Hacer el análisis de riesgos de forma exhaustiva y detallada pero no volverlo a mirar más ni siquiera para elaborar el plan de tratamiento de riesgos

Y estoy seguro que luego muchas empresas lucirán con esplendor su magnífico sello "ISO 27001". De todas formas, aquí creo que es tonto autoengañarse y que el tiempo podrá a todo el mundo en su sitio. Quien gestione bien la seguridad evitará o detectará incidentes y no tendrá problemas reales con impactos reales. Aquellos que tengan un SG-SGSI (un sistema de gestión para engañar al sistema de gestión de la seguridad de la información) tendrá unos indicadores preciosos, unos procedimentos cojonudos pero andarán todo el día apagando fuegos y perdiendo datos, cuando no siendo multados por incumplir la LOPD. En este segundo caso, el sello no servirá para nada, dado que los incidentes seguirán produciéndose de igual manera y por tanto, no se beneficiarán de lo que supone una verdadera "gestión de la seguridad de la información". No saldrán de la cultura apagafuegos que tradicionalmente venía utilizándose en esta materia y para la que el SGSI se supone que es el mejor antídoto.

¿Funcionan los analisis de riesgos?

noreply@blogger.com (Javier Cao Avellaneda) — Wed, 14 Jan 2009 12:23:00 +0000

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 análisis 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.

Novedades sobre ISO 27033-IT network security

noreply@blogger.com (Javier Cao Avellaneda) — Mon, 22 Dec 2008 16:47:00 +0000

Ya está en modo borrador la nueva ISO 27033 que es la revisión de la ISO/IEC 18028-1:2006 destinada a la seguridad de redes de comunicaciones. Y por lo que se anuncia en ISO27001security.com parece que va muy avanzado el proceso de revisión. ISO 27033 pretende ser un complemento exhaustivo para todos los aspectos relacionados con la seguridad en redes que vienen definidos en ISO 27002. Por ahora ya se encuentran en proceso los siguientes documentos:

ISO/IEC 27033-1: Guidelines for network security (FCD)

ISO/IEC 27033-2: Guidelines for the design and implementation of network security (WD)

ISO/IEC 27033-3: Reference networking scenarios -- Risks, design techniques and control issues (WD)

ISO/IEC 27033-4: Securing communications between networks using security gateways -- Risks, design techniques and control issues (NP)

ISO/IEC 27033-5: Securing Virtual Private Networks -- Risks, design techniques and control issues (NP)

ISO/IEC 27033-6: IP convergence (NP)

Más información detallada de cada uno de estos documentos en ISO27001security.com

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

noreply@blogger.com (Javier Cao Avellaneda) — Wed, 10 Dec 2008 17:44:00 +0000

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.

Little Bighorn y las ingenierías informáticas

noreply@blogger.com (Javier Cao Avellaneda) — Fri, 14 Nov 2008 11:01:00 +0000

Quería hacer un post especial en relación al 19 de noviembre, pero como adelanto, sirva esta excelente reflexión.Little Bighorn y las ingenierías informáticas (Fernando Llopis Pascual)

Para aquellos que aún no estén enterados dejo aquí una batería de enlaces necesarios para entender todo este embrollo desde diferentes puntos de vista y por supuesto para cualquier duda pasaros por la web iniciadora www.huelgainformatica.es.

Manifiesto (lectura obligada para saber por qué se convoca)

Boloniaiifordummies.blogspot.com resume bastante bien todos los conceptos de fichas, competencias.

enriquebarreiro.blogspot.com/

RITSI (diptíco informátivo completo)

www.fiv.upv.es (lectura del comunicado del decano)

blogs.ua.es/domingo/

En resumen, creo que al menos si eres un ingeniero/ingeniero técnico en Informática o estás relacionado con el tema merece la pena que inviertas un poco de tu tiempo en informarte y que así puedas tomar una decisión clara respecto a si ves o no necesario movilizarte y por qué.

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

noreply@blogger.com (Javier Cao Avellaneda) — Fri, 07 Nov 2008 09:04:00 +0000

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

noreply@blogger.com (Javier Cao Avellaneda) — Wed, 22 Oct 2008 16:09:00 +0000

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

noreply@blogger.com (Javier Cao Avellaneda) — Mon, 20 Oct 2008 21:35:00 +0000

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:
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.
Que el tratamiento de datos de carácter personal por parte del subcontratista se ajuste a las instrucciones del responsable del fichero.
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

noreply@blogger.com (Javier Cao Avellaneda) — Thu, 02 Oct 2008 06:47:00 +0000

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" or "impenetrable".

Nuevo grupo Linked-In sobre SGSI

noreply@blogger.com (Javier Cao Avellaneda) — Thu, 25 Sep 2008 07:46:00 +0000

He creido interesante, dado lo novedoso e incipiente de este mundillo de la construcción y operación de los SGSI's, el crear un grupo Linked-in que permita unir a profesionales o responsables en el manejo de este tipo nuevo de sistemas de gestión.

Creo que dado su inmaduro estado todavía, es necesario compartir aproximaciones y experiencias para que en general, todos los responsables de seguridad de las organizaciones que implanten un SGSI obtengan su máximo rendimiento aprovechando las infraestructuras que proporciona la Web 2.0 y sus correspondientes "Valores 2.0".

Se trata de compartir experiencias para no fracasar, de plantear cuestiones para entre todos, lograr de verdad la mejora continua. Sería deseable no caer en el juego de los "sellos certificados" que no significan nada, porque en calidad nos jugamos la "satisfacción del cliente" pero en ISO 27001 nos jugamos "la seguridad y continuidad de nuestros sistemas".

Quien quiera tener un sello decorativo que diga que alguien certifica que parece que gestiona bien la seguridad allá el, pero quien quiera tener un sistema que sirva para minimizar el impacto de los incidentes estará haciendo bien su trabajo.

Animo por tanto a los usuarios de Linked-in a unirse al grupo "ISO 27001-SGSI Spanish Group".

Microseguridad y macroseguridad, dos frentes de una misma batalla

noreply@blogger.com (Javier Cao Avellaneda) — Sun, 14 Sep 2008 09:39:00 +0000

Paloma Llaneza dispone de una sección titulada "Aqui un amigo" y he tenido el honor de poder postear algo en ella. Para quien a estas alturas no la conozca, aqui tenéis una pequeña reseña de su intenso curriculum en materia de seguridad:

Abogado en ejercicio, colegiada en Madrid (41.821) y socio de LLaneza y Asociados, Abogados.

Es Auditora de Sistemas de Información (CISA) certifcada por ISACA.

Es Coordinadora del GT 1 del Subcomité 27 de AENOR (Comité espejo del internacional de ISO JTC 1/SC 27/WG 1 de gestión de la seguridad TI), donde se estudian y aprueban las normas NE en esta materia. Es también Coordinadora del WG6 del SC37, sobre legislación en materia de biometría. Incorporada desde su consitución al WG25 sobre ITIL.

Es desde 2004 co-editora de la norma internacional ISO de Métricas de Seguridad de Gestión de Sistemas de la Información (ISO/IEC 27004).

El resto se puede consultar aquí.

El texto que aparece en su sección es una reflexión en torno a las diferentes perspectivas con las que analizamos la seguridad y que de alguna manera, siendo complementarias, pertenecen a mundos diferentes si nos centramos en los elementos que barajan o gestionan.

Hace unos días pude leer en Taosecurity una reflexión entorno a las similitudes que se pueden hacer entre el mundo de la economía y el de la seguridad de la información.
Esta disciplina divide sus áreas de estudio entre la microeconomía y la macroeconomía. El autor del blog comenta cómo este enfoque es también válido para nuestro mundillo de la protección de activos.

La microseguridad de la información trata los problemas del día a día, la protección en cada uno de los frentes tangibles que toda organización siempre tiene abiertos: usuarios, comunicaciones, servidores, dispositivos móviles, etc. Por tanto la microeconomía se centra en la tecnología que utilizamos para solucionar problemas, los controles que implantamos para hacer la seguridad gobernable en cada una de las situaciones o entornos donde encontramos problemas. Son aspectos tácticos y operativos de seguridad, elementos tangibles y sólidos que todo el mundo entiende ya necesarios para afrontar el día a día.

La macroseguridad de la información trata los problemas globales, la coordinación y gestión de todas las actividades necesarias para alcanzar los objetivos, la planificación y diseño de estrategias para lograr tener los riesgos bajo control. Estaríamos al nivel del diseño de políticas de seguridad, del establecimiento de relaciones contractuales que garanticen el cumplimiento. La macroseguridad ha adquirido relativa importancia en estos últimos años cuando la microseguridad abre tantos frentes que la Organización debe tomar decisiones para poder establecer una estrategia basada en la proporcionalidad de las medidas y sobre todo, la gestión del riesgo para el negocio. Por tanto, la macroseguridad es la responsable de hacer que las decisiones y restricciones se encajen dentro de la organización y sobre todo, sirvan para garantizar el cumplimiento de los objetivos de negocio y el buen funcionamiento de los procesos productivos.

Desde mis comienzos profesionales siempre me he dedicado, por así decirlo, a la macroseguridad. He convivido en áreas y departamentos destinados a la microseguridad y las discusiones eran muy frecuentes siempre cuando cuestionabamos la efectividad real de las medidas. Siempre he creido que sin macroseguridad la microseguridad tiene un efecto limitado y corto en el tiempo porque las amenazas cambian y lo que hoy te protege, mañana es un elemento más de la infraestructura que hay que gestionar.

La carencia o falta de criterio a la hora de tomar decisiones sobre qué proteger primero es lo que ha producido que la macroseguridad se defina como disciplina, apareciendo la norma ISO/IEC 27001:2005 para establecer que los procesos de dirección de la macroseguridad deben estar fundados en la gestión del riesgo y la mejora continua. El ciclo de Demming logra coordinar la microseguridad y la macroseguridad. Establece los controles tangibles que hay que aplicar pero también los indicadores o métricas que deben registrarse para valorar si están o no funcionando.

El artículo completo que referencia a su vez Taosecurity se puede leer en Information Security and Business Integration

ISO 27002.es y la integración de sistemas de gestión

noreply@blogger.com (Javier Cao Avellaneda) — Tue, 09 Sep 2008 07:44:00 +0000

Desde iso27000.es lanzan un nuevo proyecto en la URL iso27002.es como ampliación y complemento para la difusión de la seguridad de la información, ahora mediante una plataforma wiki colaborativa.

El objetivo de iso27002.es es recoger diferentes propuestas y posibles soluciones prácticas para cada uno de los 133 controles que indica la norma y que aparecen aquí resumidos en formato de ficha práctica.

Desde cada control se accede por enlaces directos a otros relacionados y la barra de búsqueda permite localizar rápidamente aquellos relacionados con posibles palabras clave, entre otras ventajas.

También se explica con formatos de video y ejemplos prácticos los puntos básicos claves a considerar en la implantación de un SGSI en relación al estándar ISO 27001.

La explicaciones recorren un esqueleto de SGSI que ya ha sido utilizado con éxito en implantaciones desde tiempos de la BS 7799-2 y en pymes de varios países.

El site permite además aportar preguntas y respuestas a los usuarios que se den de alta así como información completa sobre cada una de las normas de la serie ISO 27000 publicadas hasta el momento.

Enlace al wiki disponible en modo lectura en iso27002.es o también en iso27000.wik.is para los interesados en iniciar sesión y comentarios como anonimo/anonimo.

Además, Agustín Lopez ISO27000.es ha traducido un excelente artículo de David Brewer, Michael Nash y William List sobre la integración de un SGSI con otros sistemas de gestión.

Podéis acceder a él a través del enlace "Explotando un sistema de gestión integrado."

Políticas, normas, procedimientos de seguridad y otros documentos de un SGSI

noreply@blogger.com (Javier Cao Avellaneda) — Thu, 31 Jul 2008 10:48:00 +0000

Como resumen al documento que ya indiqué en el post Guía para la elaboración del marco normativo de Seguridad ISO 27002 en este texto que he redactado para el Blog del INTECO, comento los principales documentos que aparecen en un SGSI.

Cuando se trata de documentar las decisiones y acciones relacionadas con la seguridad de la información o la construcción de un SGSI (Sistema de Gestión de la Seguridad de la Información), aparecen diferentes tipos de documentos que contribuyen a lograr ese objetivo. En este texto trataré de poner algo de luz en relación a los diferentes documentos que pueden ser utilizados para tratar de establecer, definir y documentar las necesidades en Seguridad de la Información.

Todo intento por formalizar cualquier tarea o aspecto relacionado con la seguridad debe tratar como mínimo de responder a tres preguntas:

* Qué: objetivo, requisito o regulación que se quiere satisfacer o cumplir (lo que hay que lograr).
* Quién: responsable de la tarea o encargado de que se cumpla (el encargado de hacerlo posible).
* Cómo: descripción de las actividades que darán con la consecución del objetivo o requisito (lo que haya que hacer para conseguirlo).

Las preguntas cuándo y dónde muchas veces no tienen por qué ser respondidas aunque suelen ser tratadas en los procedimientos. Basándose en lo anterior, los documentos que se elaboran para formalizar la seguridad tratan, a diferentes niveles, de responder a esas preguntas, relacionándose de manera jerárquica unos con otros:

* Una política de seguridad debe establecer las necesidades y requisitos de protección en el ámbito de la organización y es la guía o marco para la creación de otro tipo de documento más detallado que denominamos norma de seguridad. Formalmente describe qué tipo de gestión de la seguridad se pretende lograr y cuáles son los objetivos perseguidos. Definen qué quiere la organización a muy alto nivel, de forma muy genérica, quedando como una declaración de intenciones sobre la seguridad de la Organización. A su vez, una política de seguridad puede apoyarse en documentos de menor rango que sirven para materializar en hechos tangibles y concretos los principios y objetivos de seguridad establecidos. Hablamos entonces del marco normativo que puede estar constituido por documentos de rango inferior, como pueden ser las normas, políticas de uso, procedimientos de seguridad e instrucciones técnicas de trabajo. Vamos a ver en qué consisten cada una de ellas.
* Una norma de seguridad define qué hay que proteger y en qué condiciones, pero para situaciones más concretas. Sirven para establecer unos requisitos que se sustentan en la política y que regulan determinados aspectos de seguridad. Una norma debe ser clara, concisa y no ambigua en su interpretación. Se pueden agrupar en base a las diferentes áreas de la seguridad dentro de la organización: normas de seguridad física, normas de control de acceso a sistemas, normas de gestión de soportes, normas de clasificación de información, etc.
* Un procedimiento de seguridad determina las acciones o tareas a realizar en el desempeño de un proceso relacionado con la seguridad y las personas o grupos responsables de su ejecución. Son, por tanto, la especificación de una serie de pasos en relación la ejecución de un proceso o actividad que trata de cumplir con una norma o garantizar que en la ejecución de actividades se considerarán determinados aspectos de seguridad. Un procedimiento debe ser claro, sencillo de interpretar y no ambiguo en su ejecución. No tiene por qué ser extenso, dado que la intención del documento es indicar las acciones a desarrollar. Un procedimiento puede apoyarse en otros documentos para especificar, con el nivel de detalle que se desee, las diferentes tareas. Para ello, puede relacionarse con otros procedimientos o con instrucciones técnicas de seguridad.
* Una instrucción técnica de seguridad determina las acciones o tareas necesarias para completar una actividad o proceso de un procedimiento concreto sobre una parte concreta del sistema de información (hardware, sistema operativo, aplicación, datos, usuario, etc.). Al igual que un procedimiento, son la especificación pormenorizada de los pasos a ejecutar. Una instrucción técnica debe ser clara y sencilla de interpretar. Deben documentarse los aspectos técnicos necesarios para que la persona que ejecute la instrucción técnica no tenga que tomar decisiones respecto a la ejecución de la misma. A mayor nivel de detalle, mayor precisión y garantía de su correcta ejecución.
* Una política de uso es un documento destinado a usuarios finales con la intención de establecer una regulación específica sobre la utilización de un sistema, tecnología o recurso. En este caso, deben documentarse las normas de comportamiento que deben cumplir los usuarios en el uso de los sistemas de información o los aspectos generales que se desean regular, así como los usos que son considerados autorizados y los usos no aceptables.

Lo importante de este conjunto de documentos que forman el marco normativo es, por un lado, documentar de forma clara y concreta las decisiones establecidas por la organización en materia de seguridad y, por otro, que sean utilizados por todas las personas de la organización para saber qué hacer en cada circunstancia en relación con la protección de la información.

Más información sobre ISO 27005:2008

noreply@blogger.com (Javier Cao Avellaneda) — Wed, 11 Jun 2008 12:01:00 +0000

Buscando sobre algo de información en torno a la nueva norma he podido hallar una presentación bastante interesante sobre el contenido de la misma y sus objetivos. Va a ser interesante puesto que fija los cimientos de quizás la actividad más crítica para garantizar la seguridad de la información (que no para lo que supone su gestión).
El documento está en francés y descargable en la siguiente dirección.

Pensar en aplicar la "mala" filosofía ISO 9001 sobre la ISO 27001 tiene su peligro. Si bien la mala gestión de la calidad tiene consecuencias en la balanza de resultados y buscar la mejora continua tiene una motivación económica clara, pensar en gestionar la seguridad sólo por poder poner un sello más es un riesgo mayor.

Lo que se puede conseguir con tener una certificación ISO 27001 que realmente no implique un buen funcionamiento de las medidas de seguridad es disponer de una "sensación de seguridad" que no se aproxime a la "seguridad real" de la que se disfruta.
Es por eso tan importante que en la construcción de SGSI participen profesionales del mundo de la seguridad de la información o la seguridad informática. Son los técnicos capaces de valorar si las medidas que se están recomendando son adecuadas, podrán ofrecer alternativas en los planes de manera que se de tanta importancia al proceso de gestión de la seguridad como a la propia "seguridad de la información". No es importante que haya un buen plan de seguridad sino que éste funcione y logre sus objetivos.
Utilizo la siguiente imagen para explicar las relaciones entre ISO 27001 e ISO 27002 y también para contar las diferencias entre gestionar la seguridad y la propia seguridad.

En la norma ISO 27002, se establecen procesos y procedimientos de seguridad donde se incorporan una serie de medidas sobre los activos. Estas actividades deben generar los registros de seguridad. El correcto funcionamiento del SGSI se basa en que hay ciertos responsables que velan porque los procesos de seguridad estén operativos y dejando registros que permitan posteriormente su evaluación. Fruto de esa gestión dejan los registros propios del SGSI.

Por tanto, si quien gestiona el SGSI va evaluando lo que mantiene y opera la seguridad de los activos va generando, se tiene la certeza de que las medidas están operativas y sus resultados son los esperados. De esa manera tenemos "seguridad de la información" sobre nuestros activos. La labor de gestión del SGSI es velar por el funcionamiento correcto de los procesos de seguridad definidos para proteger a los activos.

Reflexiones similares se plantean en los post de los siguientes blogs:
- Blog S21Sec.
- Mejora continua de un SGSI según ISO 27001.

Esperemos que el efecto pernicioso que tiene ya la ISO 9001, donde se busca la certificación por el sello y no por los beneficios que produce, no se extienda hacia la ISO 27001, donde obtendríamos un reconocimiento a la gestión de la seguridad de la información aunque ésta no se manifieste. Esperemos también que las entidades de certificación no contribuyan a ello, otorgando el reconocimiento a quien no lo merece.