21 diciembre 2009

Publicada ISO/IEC 27004:2009

Después de tanto tiempo esperándola, por fín se ha publicado la ISO 27004. Desde el día 7 de este mes está disponible esta norma sobre métricas de seguridad. No obstante, me gustaría recalcar, ya que parece que hay cierta confusión al respecto, que esta norma lo que establece principalmente es el ciclo de vida de las métricas, es decir, cómo se deben definir y articular las métricas de seguridad para lograr medir la efectividad de los controles de seguridad establecidos en un SGSI. Lo digo porque hay gente que piensa que esta norma es un catálogo de métricas de seguridad, y aunque sí incluye una sugerencia de métricas en el anexo, su objetivo es que cada organización aprenda a establecer sus propias métricas, más que proponer una lista cerrada de métricas a utilizar. Para que no haya malos entendidos...

02 diciembre 2009

El valor de una certificacion ISO 27001

Cada día es más habitual encontrarse con organizaciones certificadas en ISO 27001 o con intenciones de hacerlo. Y ya no son sólo las pequeñas o medianas empresas que quieren incrementar el valor de su marca con una certificación de este tipo, sino que inmensas organizaciones cuyo nombre prácticamente eclipsa el brillo de cualquier certificado también están empezando a ver su valor. O al menos es lo que parece al leer la noticia de que Microsoft quiere certificar su plataforma Business Productivity Online Suite bajo ISO 27001. Visto lo visto, parece que cada vez hay más organizaciones que aprecian el valor de una certificación de este tipo.

No obstante, hace unos días tenía una conversación acerca del valor de esta certificación con una persona cuya organización acaba de certificarse en ISO 27001 (en realidad, todavía ni siquiera es oficial la concesión del certificado) en la que se cuestionaba el valor real que el SGSI había aportado a su organización. No se ponía en duda el valor comercial y de negocio que aporta "el sello", pero sin embargo sí que se cuestionaba, al menos en parte, la utilidad real del SGSI en una organización madura en términos de seguridad. ¿Qué aporta un SGSI a una compañía cuyo "nivel de seguridad" es elevado?

Desde mi punto de vista, el principal argumento de un SGSI para empresas maduras tanto en gestión como en seguridad se centra en la utilidad del análisis y gestión de riesgos como herramienta para racionalizar las inversiones en materia de seguridad. No obstante, también es cierto que en muchas ocasiones si las medidas de seguridad ya están implantadas y se determina que son excesivas, como puede pasar, su eliminación puede ser más costosa que su mantenimiento, de modo que los ajustes asociados pueden no ser tan rentables a la hora de la verdad. También existe una serie de elementos clave que aporta un SGSI que pueden suponer un salto cualitativo diferencial en la gestión de la seguridad de una organización, aunque ese diferencial se verá atenuado en función de los elementos que la organización ya posea debido a su madurez.

En definitiva, creo que el valor de un certificado ISO 27001 no está sólo en su reconocimiento comercial, sino que existe una buena cantidad de factores clave de un SGSI que aportan valor a la organización por sí mismos, más allá del valor del certificado. No obstante, cuanto mayor sea el nivel de madurez de la organización en relación a la gestión de la seguridad menor valor diferencial aportará el SGSI, ya que ciertas prácticas ya estarán interiorizadas. ¿Puede ser este un argumento válido para que una organización madura en seguridad descarte una certificación de este tipo? ¿Qué prima en las organizaciones, el valor comercial aportado por un "sello" o los beneficios internos que proporciona? Y por último... ¿Se os ocurren más elementos que proporcionen valor a una certificación ISO 27001?

26 noviembre 2009

Consejos para la ISO 20000

Probablemente, en estas fechas muchas empresas del sector TIC puedan estar pensando en si meterse o no en un proyecto de implantación de un Sistema de Gestión de Servicios TI (SGSTI) certificable bajo ISO 20000. Si esa es vuestra situación, aquí van unos consejos que os pueden servir como ayuda para tomar esa decisión:

  • No te metas en un proyecto de ISO 20000 si no estás dispuesto a "hacer ruido" en toda la organización. La ISO 20000 en una empresa que venda servicios TI afecta directamente al negocio de la organización, toca de lleno las actividades productivas y de venta. Por tanto, un SGSTI según ISO 20000 no es un sistema de gestión que se pueda implantar "con vaselina". Si no estás dispuesto a remover los cimientos de la organización, este no es tu sistema de gestión.


  • No te metas en un proyecto de ISO 20000 si no vendes servicios. Si tu modelo de negocio está basado en la venta de productos o proyectos, este no es un sistema de gestión para ti. No estoy hablando de que la organización no realice proyectos (de hecho, el proceso de gestión de la entrega es el enlace con ellos), pero esos proyectos deben estar encaminados a la prestación de un servicio continuado. Si a día de hoy tu organización no vende servicios TI, o estás dispuesto a hacer un cambio radical en (al menos) parte del modelo de negocio o este sistema de gestión no es el más adecuado para ti.


  • No te metas en un proyecto de ISO 20000 si no eres partidario de la estandarización de tus servicios. Si tu modelo de negocio se basa en la provisión de soluciones llave en mano, diseñadas exactamente al gusto del cliente, este sistema de gestión no te conviene. La ISO 20000 permite personalizaciones, por supuesto, pero dentro de unos parámetros acotados. Su filosofía se basa en la normalización de los servicios y en su "industrialización", de modo que el margen de actuación que permite es limitado. Si eres partidario de la prestación de servicios diseñados completamente a medida es muy probable que el modelo no te encaje.


  • No te metas en un proyecto de ISO 20000 si tu modelo de negocio se centra en el consumo de los servicios prestados. La ISO 20000 se centra en la calidad de los servicios TI prestados, no en la cantidad de servicios consumidos (independientemente de que dicho consumo se mida por ancho de banda, tiempo de procesador o de dedicación de recursos humanos). La ISO 20000 se centra en fijar y garantizar el cumplimiento de unos niveles de servicio determinados, acordados con el cliente en un SLA (Service Level Agreement), de modo que la cantidad de servicio consumido pasa a un segundo término. Está claro que ese es un parámetro clave para el servicio prestado, y por eso existe un proceso específico encargado de gestionar la capacidad del servicio, pero si tu preocupación principal es el consumo del servicio probablemente la ISO 20000 no sea una referencia apropiada para ti.


  • No te metas en un proyecto de ISO 20000 si no eres partidario de la transparencia hacia el cliente. Si no eres partidario de ofrecer información detallada al cliente acerca del nivel de servicio que realmente le estás prestando, de los problemas internos que haya podido tener el servicio o del consumo del servicio que realmente está realizando el cliente, posiblemente este sistema de gestión no sea el modelo apropiado para ti. La ISO 20000 tiene un proceso específico de gestión de informes del servicio cuyo objetivo es, en definitiva, ser más transparente de cara al cliente, y puede que proporcionar tanta información no encaje con la filosofía de negocio de la organización, por múltiples motivos. Por tanto, si no estás dispuesto a "enseñar tus vergüenzas" al cliente, este modelo probablemente no te encaje.

Podría extenderme más en otro tipo de consejos más asociados a la implantación de un sistema de gestión genérico tipo ISO (disposición a dedicar recursos extra a nuevas actividades, disposición a ser auditado, disposición a mantener un programa de formación específico, etc.), pero creo que estos puntos pueden resumir las principales consideraciones de negocio que nos hemos encontrado en este tipo de proyectos. De todas formas, seguro que cualquiera que conozca suficientemente el modelo es capaz de ampliar esa lista a la hora de pensar en su propia organización...


Y no quería terminar el post de hoy sin hacer una reflexión final:



Si no tienes miedo a remover los cimientos de tu organización, si vendes servicios TI, si quieres estandarizar internamente esos servicios, si tu principal preocupación es su calidad, si eres partidario de la transparencia con el cliente... No tengas ninguna duda: la ISO 20000 es tu modelo a seguir. ¿a qué esperas para empezar?

24 noviembre 2009

Cuantos errores de seguridad cometes?

Es muy habitual que, hablando de seguridad, la gente trate de encontrar un método sencillo para saber, de forma rápida y medianamente fiable, cuánta es la seguridad de su organización. A poder ser, de forma autónoma y obteniendo un resultado cuantitativo. Por eso, cuando el otro día leí en ComputerWorld un artículo en el que hablaban de Los diez errores más comunes de los administradores de redes, me resultó muy sencillo hacer una propuesta de auto-evaluación rápida. ¿Cuántos de estos errores evita tu organización de manera sistemática (sin que evitarlos dependa de la iniciativa personal de un administrador de redes preocupado por la seguridad)? El número de errores evitados sería, directamente, la "nota" en seguridad. ¿Cuántos de estos errores se evitan en tu organización?:
  1. No cambiar las claves por defecto de los equipos (servidores, routers, switches, etc.).
  2. Compartir una misma contraseña en múltiples dispositivos
  3. No buscar vulnerabilidades de inyección SQL en las aplicaciones web
  4. No definir listas de control de accesos en los dispositivos de red
  5. Permitir accesos remotos y software de administración inseguros
  6. No probar las aplicaciones no críticas frente a vulnerabilidades básicas
  7. No proteger apropiadamente los servidores frente al malware
  8. No configurar los routers para prohibir tráfico saliente no deseado
  9. No saber dónde se almacenan los datos críticos de la organización (todas sus ubicaciones, considerando todas las copias existentes de los mismos)
  10. No seguir estándares de seguridad básicos (en el artículo se habla de PCI DSS, pero me vale cualquier estándar de mínimos de seguridad).

¿Cuál es tu nota? ¿Apruebas en seguridad? ¿Echas en falta alguna medida de seguridad básica de red? Si quieres hablar de ello, los comentarios están a tu disposición.

23 noviembre 2009

Si no cumples con tu perfil

Es cierto, las redes sociales cada vez están más de moda. Es más, yo creo que es el momento de dejar de pensar que son una moda y empezar a pensar en que, sencillamente, nuestras vidas se están "digitalizando". Es un proceso lento, muy irregular y muy poco homogéneo, pero creo que es un proceso imparable. Poco a poco, todos tendremos que ir aprendiendo a convivir con nuestras "dos vidas", la física (la de toda la vida, o la real, como dirían algunos) y la digital, virtual o como quiera que se acabe llamando la vida que "vive" nuestra identidad digital, que queramos o no también es parte de nosotros.

¿Cuál es el problema de llevar esta "doble vida" (real y virtual)? Sencillamente, que esa duplicidad es una falacia. En realidad esa doble vida no existe, son sólo dos visiones de una vida única, la nuestra. Dos visiones distintas, desde perfiles diferentes, pero de una única realidad.

El problema de la "doble vida" no es nuevo. De hecho, es tan antiguo como la sociedad en la que vivimos. Todos tenemos distintos perfiles en la vida real: el profesional, el personal, el familiar... Perfiles distintos, en los que tratamos de potenciar distintas características, pero que normalmente siempre tratamos de que sean coherentes entre sí. Al fin y al cabo, no es tan difícil que los distintos perfiles acaben mezclándose, y si algo tenemos claro es que detrás de cada perfil siempre está uno mismo.

El problema con nuestros perfiles digitales es que a veces nos olvidamos de que nos siguen representando a nosotros. Y de que son perfiles mucho más ubicuos, persistentes y permeables, con muchas más posibilidades de mezclarse y expandirse. Y claro, si no son coherentes entre sí y con los de la "vida real", podemos tener un problema...

Ese problema de falta de coherencia entre perfiles es el que ha tenido la protagonista de la noticia que acabo de leer, acerca de una chica que ha perdido la pensión por depresión por estar alegre y de fiesta con sus amigas. Parece que su perfil "profesional real" (de baja por depresión) no era coherente con su perfil "personal virtual" (fotos en facebook de fiesta con las amigas), y debido a esa incoherencia la empresa aseguradora ha decidido suspender la remuneración que tenía asignada.

No voy a entrar en la pertinencia o no del hecho, y menos voy a analizar la legalidad o no de la decisión, sobre todo desde el punto de vista de las leyes españolas. Prefiero quedarme sólo con el fondo del asunto: ¿estamos preparados para gestionar adecuadamente nuestros perfiles digitales? ¿Hasta qué punto puede ser "la seguridad" la herramienta para llevar a cabo esta gestión? Y lo que es más importante: ¿Existen los medios para hacerlo? ¿O estamos intentando ponerle puertas al campo? Si alguien quiere hacer comentarios al respecto, ya sabe que aquí puede hacerlo.

19 noviembre 2009

Publicada ISO/IEC TR 20000-3:2009

Lo sé, hace más de un mes que no publico ningún post. La verdad es que últimamente ando envuelto en una vorágine profesional bastante agotadora... Aunque ya se empieza a ver la luz al final del tunel.

Hoy sencillamente quiero destacar la publicación hace un mes del estándar ISO/IEC TR 20000-3:2009, la tercera parte de la cada vez más conocida ISO 20000. Esta parte, cuyo título oficial es Information technology -- Service management -- Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1, es un "informe técnico" en el que se dan pautas sobre cómo se puede definir el alcance de un SGSTI (Sistema de Gestión de Servicios TI) en línea con las exigencias de la ISO 20000. Habla de la aplicabilidad de la ISO 20000 y de los principios generales para la definición de alcances, y sobre todo proporciona distintos ejemplos y escenarios para la definición de alcances válidos.

Para terminar, y en línea con este tema, para todo aquél que quiera profundizar en la definición de alcances para un SGSTI según ISO 20000 también puede consultar el documento "itSMF ISO/IEC 20000 Certification Scheme - Scoping Guidelines", que aunque date de 2006 sigue siendo perfectamente válido, y tiene la ventaja de que está redactado en un tono mucho más divulgativo que el documento anterior.

19 octubre 2009

Peligros en la nube

La verdad es que hoy no estoy demasiado inspirado. Me cuesta escribir, no consigo que me salga algo fluido y medianamente motivador, al menos como para que alguien quiera seguir leyendo hasta el final del post... Sin embargo, me he decidido a escribir algo más que nada por no dejar pasar la oportunidad de comentar muy brevemente un par de artículos que me han gustado.

El primero de ellos, en dos partes, es del que he sacado el título del post: Hack in the Box, el peligro está en la nube. Un artículo en el que su autora nos cuenta cómo el ciber-crimen se está orientando hacia la nube, a la par del incremento de popularidad de este tipo de soluciones. Era algo previsible, que no nos permite olvidarnos de una de las principales premisas en esto de la seguridad: las mayores amenazas siempre serán aquellas que siguen los devenires del negocio. O lo que es lo mismo, visto desde el lado contrario: allí donde se concentre un mayor volumen de negocio es el lugar óptimo para centrar los ataques intencionados. Obvio, pero no está de más recordarlo de vez en cuando, no sea que las típicas discusiones Windows Vs Linux vayan a transformarse, en su versión 2.0, en una discusión Nube Vs Local, y acabemos cayendo en los mismos fundamentalismos...

El segundo, sobre el que no he investigado demasiado pero que me parece muy interesante por su aproximación innovadora, es la idea de luchar contra las ciber-amenazas mediante el uso de hormigas digitales. La verdad es que no me queda muy claro si eso de crear tipos concretos de hormigas para luchar contra amenazas específicas puede ser una solución apropiada (me recuerda a la filosofía de los antivirus del uso de firmas, aunque es una interpretación totalmente personal), pero el simple hecho de buscar soluciones alternativas a un problema que actualmente no está siendo apropiadamente resuelto me parece una idea estupenda, más allá del éxito real que vaya a tener la solución concreta. Y yendo un poco más allá... ¿Habría más modelos de la naturaleza susceptibles de ser aplicados para solucionar el problema del malware? Al fin y al cabo, los animales llevan millones de años estableciendo mecanismos de lucha contra sus propios virus, bacterias y demás "malware"... ¿Serán estas hormigas los glóbulos blancos electrónicos que estamos buscando? El futuro lo dirá.

15 octubre 2009

Integrando Sistemas de Gestión

En este blog he hablado muchas veces de los requisitos comunes a cualquier sistema de gestión "tipo ISO", y de las ventajas que puede tener la integración de todos ellos. Sin embargo, últimamente me he encontrado con algunos casos que, usando la integración como slogan, lo único que pretendían era aprovechar la existencia de un sistema de gestión (normalmente de calidad, ISO 9001) para reutilizar algunos de sus elementos en el nuevo sistema de gestión que estaban montando, ya sea de gestión medioambiental (ISO 14001), de seguridad de la información (ISO 27001) o cualquier otro. No es que me parezca mal (de hecho, me parece algo lógico y recomendable, dado que sirve para optimizar recursos), pero con lo que no estoy en absoluto de acuerdo es con que a éso se le llame Sistema de Gestión Integrado. Y como no me ha gustado que en un blog me hayan eliminado un comentario esbozando este planteamiento (aunque lo entiendo, ya que es un blog corporativo, y puede ser comprensible que la organización no quiera que aparezcan posturas críticas en una herramienta de marketing), he decidido presentarlo aquí.

Como decía, existen ciertas prácticas que pueden ser recomendables a la hora de solapar o superponer (creo que cualquiera de estos dos términos sería más apropiado) sistemas de gestión. Es conveniente reutilizar las prácticas de gestión desarrolladas, lo que a nivel tangible se convierte en reutilizar la documentación, usando, por ejemplo, los mismos procedimientos de gestión documental y/o de registros o los mismos procedimientos de auditoría. No obstante, no hay que olvidar la especificidad de cada sistema de gestión, y por tanto habrá que ampliar el ámbito de actuación de dichas prácticas a los diversos entornos, de la forma que corresponda en cada caso. Eso nos puede llevar, entre otras cosas, a fusionar en un único documento textos equivalentes en distintos sistemas de gestión, consiguiendo, por poner un ejemplo, un documento único que recoja la política de calidad y seguridad de la información. Del mismo modo podremos acabar teniendo documentos únicos para ambos sistemas de gestión en los que se hable de responsabilidades de la dirección, mejora continua, gestión de no conformidades, ... Si pensamos en el apartado de roles y responsabilidades, algo que también suele ser habitual a la hora de solapar sistemas de gestión es intentar aprovechar las estructuras de gestión existentes (Responsable, Comité, etc.) para el nuevo sistema de gestión. Aunque claro, aquí puede no ser tan sencilla la reutilización, dado que en cada caso se requieren una capacitación y conocimientos específicos y diferenciados, y saber gestionar, por ejemplo, la calidad, no implica saber hacerlo con el medioambiente o la seguridad de la información.

Llegados a este punto es cuando hay que ver qué hemos conseguido al solapar distintos sistemas de gestión: tener una manera común de gestionar cosas distintas. Y ese creo que es precisamente el problema. Si buscamos el término integrar en el diccionario, vemos que hace referencia a la constitución de un todo, de algo global que sintetice las partes. Por lo tanto, creo que no basta con "integrar" la sistemática de gestión (que en realidad ya era la misma), sino que la clave para conseguir un sistema de gestión integrado es ser capaz de integrar aquello que se gestiona, es decir, poder gestionar de manera integrada la calidad, la seguridad o lo que corresponda en cada caso.

Para mí el primer requisito (necesario, pero no suficiente) de un Sistema de Gestión Integrado es, sin duda, que el alcance de ambos sea coincidente. Es más, no creo que se pueda hablar de que cosas distintas puedan estar integradas si su ámbito de aplicación no coincide. A partir de ahí, creo que para hablar de integración de verdad (permitidme que me centre en calidad y seguridad de la información, que es lo que mejor domino) tenemos que ser capaces de considerar de forma simultánea la calidad y la seguridad, y poder entender la una como parte de la otra (y viceversa). No creo que se pueda hablar de integración entre ambos sistemas de gestión si no consideramos la seguridad de la información en en nuestros procesos productivos, si la seguridad no es un factor intrínseco en la selección de proveedores, o si en nuestros análisis de riesgos no consideramos factores de riesgo relacionados con la calidad. En definitiva, creo que para hablar de un Sistema de Gestión Integrado tenemos que centarnos fundamentalmente en integrar aquello que se gestiona (que es lo difícil, obviamente). Y creo que esto es mucho más importante que tratar de que el responsable de calidad y el de seguridad sean la misma persona, ya que incluso se podría hablar de sistemas de gestión integrados en el caso de que sean distintos responsables.

En definitiva, creo que a veces las organizaciones pierden un poco el norte con tanto sistema de gestión normalizado, y se olvidan de que las empresas lo que deberían tener es un único sistema de gestión, el de la organización, independientemente de que el sistema cumpla o no los requisitos de más o menos sistemas de gestión normalizados, o de que ese cumplimiento esté o no certificado por alguien. La preocupación de cualquier organización debe ser el negocio, y negocio no sólo es calidad, o seguridad, sino la suma de todo ello y de mucho más. Así que estaría bien pensar un poco más en tener un sistema de gestión del negocio, que integre la gestión de todos los elementos que lo componen, y no preocuparnos tanto por modas o certificaciones que, si hacemos las cosas bien, se acaban integrando "solas"...

13 octubre 2009

Continuidad de Negocio en la practica

Aunque debo reconocer que últimamente mi agenda está más apretada de lo que a mí me gustaría, también es cierto que a veces esa agenda me da la oportunidad de participar en foros muy interesantes y hablar con verdaderos profesionales de nuestro sector.

La semana pasada tuve la suerte de participar en un foro sobre Continuidad de Negocio en la Universidad de Deusto, donde algunos tratamos de exponer nuestras experiencias y puntos de vista sobre la continuidad de negocio desde un punto de vista práctico. No voy a hacer un resumen de las ponencias que allí se presentaron, pero sí destacar algunos comentarios que allí se hicieron, y que creo que puede ser interesante recordar:
  • Negocio, Negocio, y Negocio: esa es la palabra clave de la continuidad. Lo siento por los tecnófilos, pero la tecnología es un medio, no un fin (aunque a veces sea un medio importantísimo).
  • En un análisis de riesgos de continuidad, el impacto es más importante que la probabilidad, y por tanto su escala debería ser ponderada al alza (es decir, impacto alto y probabilidad baja supone mayor riesgo que probabilidad alta e impacto bajo).
  • La clave de la continuidad de negocio es la eficacia, pero es desde la eficiencia desde donde conseguiremos "vender" los planes de continuidad e incluso encontrar el ROI.
  • Si una organización es lo suficientemente madura no hace falta "vender" la continuidad, la propia dirección de la organización será quien se preocupe de que el negocio continúe y de sacar partido a los foros de continuidad desarrollados.
  • Los incidentes son las pruebas de continuidad más perfectas que podemos encontrarnos: no perdamos la oportunidad de aprender de ellos.
  • La comunicación es un factor clave en la gestión de la crisis, si no controlamos la imagen transmitida todos nuestros esfuerzos pueden verse abocados al fracaso.

Estos son sólo algunos de los mensajes que me vienen a la memoria. De todas formas, seguro que tanto los que estuvisteis allí como los que no tuvisteis la oportunidad tenéis otros mensajes igual de importantes que añadir a la lista. ¿Estáis dispuestos a compartirlos? Espero vuestros comentarios.

29 septiembre 2009

Matices de ISO 20000

En el último post prometía explicar la fórmula que sirve para entender la ISO 20000, o al menos aclarar los importantes matices que tiene. La fórmula en cuestión es la siguiente:
  • ISO 20000 = ISO 9001 + ITIL + Desarrollo de los servicios
La primera parte, comentada en el citado artículo, es ver las analogías entre la ISO 20000 y la ISO 9001. El elemento común es, como ya se ha comentado en este blog en más de una ocasión, el núcleo del sistema de gestión: la filosofía PDCA que subyace en ambas y los requisitos mínimos que se plantean en torno a dicha filosofía para montar un sistema de gestión certificable (responsabilidades de la dirección, gestión documental, formación, revisión por la dirección, auditoría, mejora contínua, etc.). A partir de ahí las diferencias radican en el espíritu de cada norma: mientras que la ISO 9001 fue concebida pensando en la gestión de la calidad de los productos, y generalizando dichas ideas para ser aplicables a servicios de manera genérica, la ISO 20000 fue concebida específicamente para la gestión de la calidad de los servicios TI. Es por éso que el planteamiento de la primera es mucho más lineal, más "clásico". No obstante, hay un punto en el que ambas se solapan, y es en lo referente a la gestión aplicada a los interfaces externos de la organización (clientes por un lado y proveedores por otro), mientras que en los apartados más referidos al ámbito "productivo" es donde más difieren. También tienen otros aspectos en común, como la orientación a procesos, pero como vamos a ver en el siguiente párrafo es un apartado en el que la ISO 20000 está mucho más trabajada.

El segundo elemento de la ecuación son los procesos. La ISO 20000 plantea 13 procesos divididos en 5 grupos de procesos, que nosotros podríamos "reagrupar" en 3: procesos de provisión del servicio, procesos de relación y procesos de soporte al servicio (agrupando los de resolución, control y entrega). De este modo es fácil identificar la analogía con ITIL v2, ya que en gran medida la definición de procesos en ambos casos es solapable. No obstante, hay ciertas diferencias: ISO 20000 introduce la gestión de la seguridad dentro de los procesos de provisión (en ITILv2 es independiente), agrupa la gestión de la continuidad y la disponibilidad (en ITILv2 son procesos separados) e introduce como proceso la gestión de informes (en ITIL no existe), dando un mayor peso específico a la monitorización y reporte de información. Con algunos otros matices de menor importancia, podemos decir que en el resto de los aspectos ambas referencias son solapables, si obviamos el hecho de que la ISO 20000 habla de requisitos mínimos e ITIL de "referencias máximas".

Las diferencias más profundas entre ISO 20000 e ITIL vienen provocadas, principalmente, por su fecha de publicación. Mientras que ITIL v2 data de 2001, ISO 20000 fue publicada en 2005, e ITIL v3 lo fue en 2007. Esto hace que dicha evolución se pueda ver como un modelo incremental en el que se van incorporando evoluciones conceptuales, cuyo mayor exponente es el ciclo de vida del servicio. Mientras que ITIL v2 es un modelo "estático" ISO 20000 esboza dicho concepto en su apartado 5, mientras que ITIL v3 lo desarrolla completamente en su nuevo modelo de procesos.

Efectivamente, el tercero de los elementos que incorpora ISO 20000 es el desarrollo de los servicios, o más específicamente la planificación e implementación de los servicios. En realidad no es un concepto nuevo, dado que ya venía recogido en el olvidado libro de ITIL v2 Planing to implement service management. No obstante, ISO 20000 tiene el mérito de recuperar su esencia, muy en línea con conceptos tan de moda actualmente como el de Gobierno TI, e introducirlo como elemento imprescindible de un Sistema de Gestión de Servicios TI. Es en realidad uno de los aspectos más importantes de la ISO 20000, y el elemento diferencial para las organizaciones que, pese a haber adoptado un "modelo ITIL" para sus procesos, sienten que les falta alguna pieza... Y por último, también es un guiño para todos aquellos entusiastas de la ISO 9001 que, pese a todo, se hayan quedado con la sensación de que hay partes de esa norma que no quedan suficientemente cubiertas por la ISO 20000.

21 septiembre 2009

Cuidado con confundir ISO 9001 e ISO 20000

Es cierto que cada vez se oye hablar más de ISO 20000, que poco a poco se está popularizando como un estándar reconocido para la gestión de la calidad de los servicios TI. Pero eso no quiere decir, en ningún caso, que la ISO 20000 sea una ISO 9001 para empresas TIC, como parece que algunos intentan que pensemos. Es como comparar un utilitario con un camión frigorífico: tienen cosas en común, y la filosofía de este último parte del primero, pero si queremos profesionalizar el transporte de alimentos perecederos a grandes distancias no nos sirve con un simple utilitario de propósito general... Así que es muy importante que, a la hora de leer los titulares de algunos reportajes sobre ambas normas, tengamos conocimiento suficiente como para poder ponerlos en perspectiva y no llevarnos impresiones equivocadas.

Simplificando mucho y sin entrar en (importantes) matizaciones, podríamos llegar a decir lo siguiente:
  • ISO 20000 = ISO 9001 + ITIL (v2) + Desarrollo de los servicios
Por tanto, es fácil ver cómo, con sólo una ISO 9001, no es suficiente, por mucho que la empresa sea del sector TIC... Nos faltan 2 de las 3 partes de la ecuación: los procesos de gestión de servicios TI que define ITILv2 y las actividades de planificación e implementación de los servicios que define de manera autónoma la propia ISO 20000. Obviamente hay elementos comunes entre ambas normas, y si tenemos una ISO 9001 la transición a la ISO 20000 será más sencilla, ya que el núcleo del sistema de gestión será el mismo, pero esto no quiere decir que sean intercambiables... y si no que se lo pregunten al cliente que recibe los alimentos perecederos transportados en automóvil.

Quizás otro día dedique un post a explicar las matizaciones de la fórmula de más arriba, pero creo que, por hoy, con esto es suficiente. El mensaje ha quedado claro, verdad? Así que tened cuidado, y no os dejéis engañar...

17 septiembre 2009

Datos personales al descubierto?

El pasado lunes bajaba del avión leyendo un artículo interesante, en prensa generalista, hablando de que la descoordinación de las empresas al ocultar los números de cuenta bancaria del cliente en sus facturas permite averiguarla fácilmente, con sólo combinar las de varias empresas que oculten números complementarios.

Aunque el trashing no sea una técnica tan habitual por estas latitudes como lo es en las películas (supongo que algo tendrá que ver que tampoco las viviendas unifamiliares con cubo de basura propio lo sean), la verdad es que es muy sencillo recabar información "sensible" en los cubos de reciclaje de papel. Y no pensemos que es algo propio de películas de hollywood, porque hasta tenemos (¿leyendas urbanas?) noticias que hablan del uso oficial de esa técnica en algunos países para multar a quien tira la basura fuera del horario establecido...

De todos modos, y volviendo al artículo en cuestión, el problema de fondo radica en saber si el número de cuenta, más allá de estar parcialmente anonimizado, es pertinente en las facturas. El artículo afirma que parece excesivo, pero esa afirmación desde mi punto de vista no está tan clara. Al fin y al cabo, puede considerarse pertinente que la empresa indique el número de cuenta sobre el que se ha realizado o va a realizar el cargo que está siendo comunicado, o al menos proporcione una cantidad de dígitos suficiente como para que se pueda identificar dicha cuenta. La finalidad asociada al fichero no la podemos obviar...

En el fondo, el problema está en la consideración de dato "sensible" que hace la LOPD y la que hace cualquier persona. Porque claro, el número de cuenta no revela prácticamente nada sobre la intimidad del afectado, pero sin embargo muchas personas pensarán que ese dato debería ser más privado que otros como la filiación sindical, por ejemplo... Y es que, como se suele decir, con el dinero no se juega. Pero sin embargo para la LOPD a este dato sólo es necesario aplicarle las medidas de seguridad de nivel bajo, lo mismo que haríamos con el nombre, los apellidos o la dirección de la persona. Así que me temo que legalmente no hay mucho que decir...

Después de todo lo dicho, y para que los defensores acérrimos de la privacidad no se ofendan, también es necesario recordar que cualquier ley tiene carácter de mínimos exigibles, y que a partir de ella la responsabilidad social de cualquier empresa es la encargada de poner en práctica cualquier tipo de norma o forma de actuar que considere que va a ser beneficiosa para sus clientes. Por tanto, no estaría de más apelar a esa RSC que en algunos sectores está tan de moda para abogar por una mayor cohesión entre las prácticas de ofuscación de datos personales de este tipo de organizaciones, con el objeto de que sea realmente cierto, y no sólo aparente, el beneficio social que este tipo de actuaciones quieren conseguir.

11 septiembre 2009

Avances en el Esquema Nacional de Seguridad

Lento pero seguro. Así suele ser el avance de los temas legislativos, más allá de las peleas políticas que les afectan. Es cierto que hace mucho tiempo que no hablaba del tema, pero en los últimos 2 años el Esquema Nacional de Seguridad ha seguido su avance, poco a poco. Hasta el punto de que, en la página referenciada, ya tenemos una primera propuesta para el Esquema Nacional de Seguridad. ¿Qué os parece? ¿Cuáles son vuestras primeras sensaciones al leerlo? Espero vuestros comentarios.

Amenazas, lo que viene (III): Amenazas del futuro

Esta es la tercera y última parte del artículo de Jose Miguel Sobrón "¿Está el mundo preparado para la nueva clase de amenazas que llegan?". Tras haber analizado los límites de la habitual gestión de riesgos y haberlos contrastado con el amplio universo de las amenazas, en esta tercera parte el autor introduce la variable tiempo para recordarnos que la labor de la gestión de riesgos no sólo debe tener en cuenta el presenta, sino mirar al futuro e intentar anticiparse a lo que, por propia definición, no es previsible.

Nos hace falta un concepto más, que regula imperativamente el desarrollo de cualquier teoría, al menos hoy. Este factor que define la componente tridimensional del estudio de las amenazas, es el tiempo: la escala de tiempo como conocida hasta ahora (no entraré en dimensiones superiores para evitar perdernos sin haber siquiera comenzado, pero hay sin duda otras dimensiones intervinientes). El tiempo hace que valores determinados permuten sus sectores de pertenencia. Es importante recordar que toda amenaza “nueva” acaba integrándose en la colección de amenazas convencionales, es solo una cuestión de tiempo. Y también es importante recordar que no siempre lo desconocido se podía haber previsto solo por conocer su existencia.

El tiempo hace que nuestro universo de amenazas se amplíe como si de un cono se tratara, no solamente lo probable y conocido aumenta, cada vez que lo hace aumenta en la misma proporción el resto de sectores. Efectivamente la dimensión de aumento no es lineal, no se trata de un cono perfecto sino de una aproximación teórica para intentar aproximarnos a la comprensión del fenómeno.



Todo aquello que simplemente todavía no existe o no ha sucedido es futuro tal y como lo conocemos ahora. Eso significa que los cuatro sectores que hemos definido anteriormente adquieren una dimensión mucho mayor con el paso del tiempo. El crecimiento en la línea temporal aumenta exponencialmente ya que hoy somos incapaces de regular o controlar el devenir de los acontecimientos en la línea del tiempo, no se puede parar. Probablemente llegara el día en el que sí que sea más factible andar por esa línea de tiempo, pero no lo hemos podido demostrar aún en el terreno de lo práctico. Por mucho que nos empeñemos la función que define la relación entre el paso del tiempo y el crecimiento de cada sector nos es desconocida, no sabemos de su magnitud. Si algún día llegamos a ser capaces de demostrar que efectivamente hay funciones que definen estas áreas de conocimiento, seguramente no serán funciones simples, pero eso esta todavía por ver.

Es importante no olvidar que lo que presento es un constructo teórico, se trata simplemente de un modelo visual que nos ayuda a comprender el concepto, es decir la realidad no tiene porque ser de esta manera y evidentemente puede ser absolutamente asimétrica (palabra mágica que define áreas de reducido / limitado conocimiento). En este punto defino la asimetría como matemáticamente se hace asimetría: que no es exactamente igual en dos partes presupuestas idénticas. No soy capaz de definir el nivel cuantificado de asimetría, eso está todavía lejos de mi capacidad de análisis y predicción. Lo importante de esta asimetría no es la cantidad sino la capacidad que nos da de dejar el espacio entreabierto a nuevas opciones, ese es el verdadero valor de la asimetría, nos permite asumir otros constructos sin tener que permanentemente asumir errores en la verificación de nuestras hipótesis. Básicamente es una pequeña trampa para ganar tiempo.

Hasta ahora nada nuevo bajo la capa celeste. Bueno lo nuevo es que somos capaces de no aturullarnos entre tanto concepto y que hemos intentado simplificar o limitar la presentación de las amenazas de una forma un poco mas visual. ¿Cual es la motivación para organizar las amenazas de esta manera?, primero comprenderlas mejor aunque las desconozcamos inicialmente y segundo ser capaces de preparar una reacción más normalizada con un plan mucho mas abierto a impensables y que no se deje intimidar por la situación.

Después de haber definido someramente cuales sin las diferencias básicas entre las amenazas actuales- recordar que se trata exclusivamente de un modelo de comprensión- el siguiente par de pasos pueden ser como siguen: Catalogar cada sector (y merece la pena el esfuerzo compilatorio) y desarrollar las técnicas básicas que nos conduzcan a una mejor solución de los problemas que se nos plantean. Verdaderamente necesitaremos un grupo de expertos que sean capaces de destripar en detalle cada sector. Las tareas compilatorias son de por si aburridas y tediosas, salvo que el equipo sea lo suficientemente polifacético como para poder combinar diferentes puntos de vista.

Nueva York, Enero de 2009

08 septiembre 2009

Amenazas, lo que viene (II): El universo de las amenazas

En este post voy a publicar la segunda parte del artículo de Jose Miguel Sobrón titulado "¿Está el mundo preparado para la nueva clase de amenazas que llegan?". Me he permitido la licencia de adaptar los títulos con el fin de que cuadren con las divisiones que he hecho. Espero que sirvan de ayuda...

Vamos a explorar el universo real de una forma sencilla. Definamos solo dos dimensiones básicas: Conocido / Desconocido y Probable / Improbable.


Esto automáticamente define cuatro sectores como refleja la figura. Este es el primer momento de acercamiento al problema ya que de todas las posibles opciones vamos a identificar aquellas que son previsibles. Este será el concepto nexo fundamental que siempre marca nuestra tarea, la capacidad de predecir acontecimientos. A posteriori veremos que lo fundamental no es sólo predecir sino combinar la capacidad de predicción con la capacidad de reacción. Analicemos pues sobre estas dos dimensiones las posibilidades de predecir (con éxito claro está).

  • Sector 1: Probable y conocido. Este es nuestro mayor campo de actuación y el que definimos tradicionalmente como “convencional”. No entrare en este momento en el análisis detallado de este sector sino en una mera explicación de las características del mismo para evitar perdernos en el detalle. Incluso siendo el sector más ampliamente conocido de los que vamos a definir, no es ni mucho menos conocido al 100%. Tenemos una idea bastante detallada de su funcionamiento y la mayor parte de sus amenazas se podrían describir como lineales sin cambios de dirección significativos por lo general, hasta 1991, después todo se ha complicado bastante. A partir definitivamente de la caída del muro de Berlín se inicia una serie de procesos cuya tendencia inmediatamente posterior es simplemente incalculable que no impredecible. Desconocemos su dirección y magnitud porque desconocemos lo que podrá controlarlo, la capacidad de reacción. Lo que más nos sorprende de estos fenómenos es su carácter vectorial, su cambio de dirección una vez iniciados por salirse precisamente del área de expectativas previstas no porque nos sean desconocidos sino por la trayectoria inusual o sorprendente.

  • Sector 2: Improbable y conocido. Este es el área en la que los fenómenos que se suceden, por la falta de costumbre, nos sorprenden. No hay una ausencia de casos reales simplemente no les habíamos prestado atención o era irrelevantes para nuestro análisis Los conocemos pero hemos llevado a cabo lo que podríamos denominar una análisis de economía de medios y hemos decidido aparcarlos en al área de puede que pero no creo o si yo lo creo no tengo la suficiente base para explicar mi intuición. Es aquí donde empieza a tomar forma la teoría del shock. Ya entraremos en detalle mas tarde en que consiste esa teoría o teorías Aquí podemos encapsular todo aquello que los clásicos denominan Ciencia ficción: Todo aquello que es imaginable por nosotros (por ende es posible, conocido e improbable) pero que nuestro sentido común o experiencia (raya que define hasta donde puedo llegar defendiendo una opción sin caer en el descrédito social de la comunidad) nos definen como improbable. No siempre son realmente improbables sino inaceptables dentro de los niveles de aceptación general por lo que es más sencillo definirlos así. Aquí somos nosotros mismos quienes decidimos limitar nuestra capacidad de predicción por razones prácticas o simplemente sociales.

  • Sector 3: Probable y desconocido. Esta opción demuestra claramente que la capacidad de predicción del ser humano es bastante limitada. No tenemos el control sobre la capacidad de imaginar o no, simplemente no lo podemos conocer. Esto no es realmente cierto en realidad. Seria mejor decir que la mayor parte de nosotros es incapaz de verlo o siquiera imaginarlo. Sí que hay individuos que han traspasado ese nivel y que son realmente capaces de tener una idea aproximada del concepto. Aquí entra la osadía del individuo en juego para ser capaz de romper la barrera del conocimiento actual y ponerlo a disposición del resto, es lo que se viene conociendo comunmente como “descubrimientos”. Es en este sector donde encontramos los visionarios o privilegiados que son capaces de ir mas allá del resto de todos nosotros para presentarnos sus teorías. Para evitar malentendidos, sirva este ejemplo para marcar la diferencia entre los visionarios innovadores (presenta un trocito del área desconocida a los demás) y los literatos de lo improbable (los que hablan de áreas ya conocidas pero generalmente descartadas por la experiencia o no probadas como válidas). Ambos tienen un mérito incalculable, pero evidentemente diferente en su concepción. No pretendo en absoluto compararlos simplemente definir su área de actuación.

  • Sector 4: Desconocido e Improbable. Todo aquello que pasa al lado de nuestra existencia sin siquiera percibirlo y que además la probabilidad de que suceda a pesar de nuestro desconocimiento es mínima. Este es nuestro mayor agujero en materia de seguridad porque sin lugar a duda será el que provoque estupefacción en los que tengan que reaccionar a la amenaza y se trata de minimizar el tiempo de shock, no seremos capaces de eliminarlo pero si de reducirlo. A diario millones de pequeñas cosas nos sorprenden, pero dado que tenemos una capacidad limitada de procesamiento, nuestro cerebro, consciente e inconscientemente la mayor parte del tiempo, se encarga de aparcarlos para poder ser capaz de mantenernos concentrados en tareas bastante mas básicas de supervivencia, como por ejemplo ser capaces de llegar a tiempo al trabajo sin detenerme en cada sorpresa que me encuentro, pragmático ¿no?.

Hasta aquí lo que el Secretario de Estado Robert Gates define estupendamente con sencillas palabras. Lo que sé que sé, lo que sé que no sé, lo que no sé que sé y lo que no sé que no sé. Impactante y sencilla visión, e impactante el coraje de decirlo a pesar de que no es tan obvio como parece.

07 septiembre 2009

Amenazas, lo que viene (I): ¿Donde están los limites?

A diferencia de otras ocasiones, hoy no voy a publicar un post de mi autoría, sino un artículo escrito por Jose Miguel Sobrón, un experto en seguridad, gestión de crisis y continuidad de negocio que trabaja en una organización internacional en apoyo a la gestión de crisis. Como es un poco extenso, lo publicaré en varias partes. Espero que os guste.

Hace ya unos cuantos años que muchos especialistas se enfrentan al reto de actualizar el inagotable arsenal de “nuevos” riesgos a los que nos enfrentamos. Tarea harto difícil por no decir imposible en un momento de cambio como este. La realidad mundial dista bastante de parar de crecer cuando ni menos estabilizarse.

La pregunta del analista y a veces del directivo o gestor es: ¿Cómo se puede hacer frente a algo que sencillamente desconocemos? Es difícil Y lo es básicamente porque esta cambiando el set de reglas básicas. Hace ya un tiempo que para marcar esta diferencia se han acuñado términos como convencional y no convencional. Estas definiciones a veces son más confusas que clarificadoras y es porque claro, al cabo de pocos meses lo que llamábamos no convencional se ha transformado en algo convencional debido a que se ha integrado perfectamente en nuestra respuesta cotidiana.

El quid de la teoría es reconocer que la seguridad está evolucionando a una velocidad que es difícil de ser asimilada por el común de los mortales que nos vemos sobrepasados por tanto cambio conceptual y variada denominación. La realidad cambiante (jamás encontré un termino tan exacto para una situación como la seguridad actual) hace tambalear la mayor parte de todas las teorías concebidas en los últimos decenios. En realidad solo unas pocas son capaces de sobrevivir por lo evidentemente adelantadas a la realidad diaria. Sucede, que algunos de los que han conseguido interpretar de alguna manera esas lecturas han descubierto a la vez que es más rentable entrar en la nomina de los aspirantes a Nostradamus que en la de los simples teóricos de la seguridad. En un mundo tan atado a reglas y procedimientos es fácil caer en la tentación de buscar alternativas a una falta de atención escandalosa sobre las nuevas amenazas que nos rodean y que sin duda van a formar parte de las próximas complicaciones. Es, sin lugar a dudas más simple llamar la atención del editor si lo que cuento entra de lado en la conexión con lo paranormal o suena a ciencia ficción imposible, que si se basa exclusivamente en una interpretación concienzuda y a la vez artística del arte de la guerra, eso desgraciadamente no vende. Reconoceré que siempre llamará más la atención del público en general un titular de libro que conecte la sapiencia de Nostradamus con nuestros egos voraces de saber el futuro, que uno que sencillamente mencione el trabajo de un investigador que se ha dedicado a profundizar en el análisis.

Ahí esta el reto de la mayor parte de los nuevos teóricos de la seguridad ser capaces de innovar y convencer a la vez. La seguridad no es una ciencia perfecta sino mas bien un arte y como buen artista, la vida desde el completo anonimato hasta el reconocimiento es dura y plagada de desagravios abonados de incomprensión y mediocridad. Como no soy teórico, quedo libre de la vida del artista y me limitaré simplemente a intentar explicar qué es lo que esta cambiando en materia de seguridad y defensa que deja perplejos a gran número de dirigentes y lideres en su aproximación a la comprensión del fenómeno actual.

Sucede por un lado que debemos de dejar de buscar explicaciones a lo que ya hace bastante tiempo es un hecho constatable: la seguridad de hoy no tiene nada que ver con la de hace quince años. El camino comienza por intentar seriamente ser más abiertos y dar un paso más valiente en la comprensión de esta nueva realidad. Siempre me ha hecho sonreír este concepto tan anglosajón de “thinking out of the box”. El problema es que por definición no hay “box” desde hace bastante tiempo y algunos todavía ni se han enterado, luego es ya hora de articular otro término que sirva de verdad a nuestros propósitos con más eficacia. A mi me gusta el de piensa en 360 porque básicamente no limita o el más sencillo de abre tu mente. Bueno sin más me intentaré adentrar en la definición de nuestro universo de amenazas para poder vagamente mediante una clasificación por eliminación entender donde nos encontramos.

El analista de seguridad, que normalmente es una persona absolutamente práctica, evita a toda costa perderse en el batiburrillo de lo intangible por dos razones: la primera ganará tiempo al evitar conjeturar en exceso y la segunda evitará ser despedido porque su tremendamente experimentado jefe no quiere tener que estar explicando conceptos que sabe de antemano que su Jefe Ejecutivo no va a comprender o no podrá justificar delante del Consejo Directivo. Somos pues los propios expertos los que empequeñecemos sobremanera la visión de lo que nosotros vemos porque reducimos ex profeso el abanico de lo que presentamos, por lo intangible de lo desconocido o difícil de explicar. Eso hace que la mayor parte de los neófitos acaben convenciéndose del limitado universo en el que nos movemos, lo que se conoce hasta ahora me refiero.

03 septiembre 2009

Empresas y gripe A

Lo siento, no me he podido resistir. Hay temas sobre los que, si no escribes, parece que no estás al día... Aunque claro, si lo que escribes va contra corriente, quizás estés cometiendo un suicidio social... Bueno, me voy a arriesgar.

A estas alturas seguro que todos hemos oído hablar de la Gripe A, así que no me voy a entretener mucho con ella. No obstante, sí que me gustaría analizar sus efectos desde el punto de vista de la seguridad (de la información), porque tengo la sensación de que estamos perdiendo un poco el norte con este tema.

Vayamos por partes. En primer lugar, ¿qué efectos puede tener la gripe A sobre las empresas? Sencillamente, que el personal afectado no vaya a trabajar por estar sufriendo la enfermedad. Es decir, que desde el punto de vista de la seguridad la gripe A es una amenaza que puede provocar efectos sobre la disponibilidad y continuidad de las personas, y por tanto sobre los servicios que estas personas desarrollen.

El hecho de que sean los "servicios profesionales" los que se vean directamente afectados es un factor a tener en cuenta. Servicios TI puros o empresas productivas cuya cadena de producción esté completamente automatizada no se van a ver afectados de forma directa, sino sólo indirecta (por los servicios de mantenimiento que presten las personas sobre las máquinas correspondientes).

Ahora pasemos a analizar el factor de riesgo de esta amenaza. Por una parte, tendremos que analizar la probabilidad de ocurrencia de esta amenaza. En este caso estamos frente a una pandemia (sencillamente, una enfermedad infecciosa de alcance mundial, o mejor dicho, extendida por varias regiones geográficas extensas de varios continentes) de nivel 6 (la enfermedad se propaga geográficamente de persona a persona de manera exitosa, ya que aparecen brotes comunitarios en al menos 3 países de 2 regiones distintas). Por tanto, podemos decir que la probabilidad de ocurrencia aparentemente es alta. Pero... cómo de alta? Hay noticias que hablan de una tasa actual de ocurrencia de casi 54 casos por 100000 habitantes, y si vemos los datos de otros países europeos ninguno alcanza los 100. ¿Podemos considerar un 0,054% una tasa alta de ocurrencia? Si lo comparamos con el histórico de incidencia de la gripe estacional en España, vemos que el año pasado tuvimos una incidencia máxima de 200 casos semanales, y el máximo histórico alcanzado en 2005 fue de 542. Si extrapolamos este dato a uno mensual, podemos hablar de un umbral máximo histórico de ocurrencia del 2,17%. Si hacemos unas pequeñas suposiciones, como que la incidencia geográfica y temporal es homogénea, podríamos decir que la probabilidad mensual de contagio que tiene cada persona es, redondeando al alza, de un 2,2%. En realidad deberíamos considerar la probabilidad anual para poder mantener los cálculos que figuran a continuación, y aunque jamás van a llegar ni con creces a una tasa mantenida a lo largo del año, vamos a suponer que es así y que la probabilidad anual, acumulativa, es del 26,4% (como veis, estoy dejando muuuucho margen de error, y siempre estimando el caso peor).

El segundo factor para analizar el impacto de la amenaza es valorar sus efectos. En este caso, por separado para la disponibilidad y para la continuidad. Para el segundo, el fatídico, hay que considerar la tasa de mortalidad de la enfermedad, que sería lo que provocaría efectos sobre la continuidad. Para esta enfermedad a día de hoy tenemos una tasa de mortalidad del 0,018% en España, aunque algunas noticias que podemos encontrar en la red han llegado a dar una tasa mundial de 0,78%. Aparentemente no es una probabilidad alta, y tampoco parece serlo comparada con la de la gripe común, que según algunas fuentes sería hasta del triple que la primera.

Para el caso de la disponibilidad es necesario analizar el tiempo medio que una persona está de baja debido a la infección por gripe A. Según algunas fuentes, el dato de referencia varía entre los 2-4 y los 10 días, así que para nuestro cálculo tomaremos el límite superior, por si acaso. Esto supone una indisponibilidad del personal del 2,8% del tiempo anual, aproximadamente, si no consideramos periodos especiales. En términos coloquiales, una baja de semana y media.

En principio, con estos datos ya podríamos hacer una estimación del factor de riesgo. Para la disponibilidad, tendríamos que estimar que la gripe A va a provocar una baja de semana y media de duración en el 2,2% del personal cada mes. ¿Es correcta esta afirmación? Pues me temo que no. En este caso hay un factor que debemos tener muy en cuenta: la tasa de propagación del virus. La probabilidad de infección de una persona concreta sí que sería del 2,2%, pero la probabilidad de que esta persona infecte a compañeros de trabajo durante la semana y media de duración de la enfermedad depende de este dato. Y la verdad es que no he sido capaz de encontrar un dato específico al respecto, salvo que todas las fuentes hablan de una tasa mayor que la correspondiente a la gripe común y algunas afirman que llega a ser del triple. Como no he podido obtener ningún dato numérico, no me ha quedado más opción que recurrir a noticias menos argumentadas, que hablan de un 50% de afección en las empresas. Personalmente me parece un dato inflado, pero ya que es el único que he podido encontrar es el que voy a utilizar.

En definitiva, la afección por gripe A podría llegar a ocasionar como máximo en una empresa la baja del 50% de las personas durante el 2,8% del año con una probabilidad de ocurrencia del 26,4%, es decir, un impacto del 1,4% sobre la disponibilidad con una probabilidad de ocurrencia del 26,4%, de modo que el lucro cesante que debería asociar una empresa a la gripe A serían del 0,37% del valor que generen los servicios profesionales desarrollados por las personas afectadas, que en una empresa de servicios podríamos asimilar a su facturación. Sin olvidar que este es un valor asintótico con mucho margen...

Para estimar el impacto real de la gripe A en cualquier organización me gustaría comparar este dato con uno de referencia muy habitual: las vacaciones. Desde el punto de vista de la disponibilidad tienen un efecto idéntico al de una baja, salvo que son planificadas. En este caso, las vacaciones habitualmente las coge el 100% del personal (pongamos el 90%, por si acaso) con una probabilidad de al menos el 90% de certeza de que lo hagan y una duración de referencia de 3 semanas, así que en este caso hablaríamos de un impacto del 5,18% con una probabilidad de ocurrencia del 90%, es decir, un lucro cesante del 4,7%. ¿No os parece llamativa la comparación?

En definitiva, mi conclusión es que, aun en el peor de los casos, la gripe A no debe ser especial motivo de preocupación para las empresas. Todas asumen que sus empleados se van de vacaciones, y aunque se planifique para que coincida con periodos de menor actividad, la afección por la gripe A también coincidiría, si atendemos a los factores de propagación del virus, con periodos de menor actividad de los clientes, ya que se verían sujetos a las mismas olas. Y de todos modos hay que considerar el elevado diferencial de impacto entre ambos casos... Vamos, que en la práctica muchas empresas seguro que tienen mejores motivos por los que preocuparse que por los efectos de la gripe A. No vaya a ser que en medidas de prevención acaben gastándose más dinero que el lucro cesante que puede llegar a provocar la enfermedad...

01 septiembre 2009

Modelos para la gestion de incidentes de seguridad

A raíz de unos comentarios en relación al último post sobre incidentes de seguridad se me ha ocurrido extender un poco más mi respuesta en forma de post. La idea es, sencillamente, presentar un par de modelos que pueden ser utilizados para la gestión de incidentes de seguridad.

El primero de ellos, como sugieren en los citados comentarios, es seguir el modelo de gestión de problemas de ITIL para llevar a cabo la gestión de incidentes de seguridad. En dicho modelo se habla de monitorizar y ejecutar revisiones preventivas en busca de problemas, que en el ámbito de los incidentes de seguridad se podrían asimilar a las auditorías (técnicas de seguridad y la monitorización de los sistemas de seguridad, pudiendo llegar a considerar incluso las consolas SIM. Por otra parte, ya dentro de la gestión reactiva, la gestión de problemas en sí misma habla de registrar los problemas, diagnosticarlos, identificar las causas del mismo (convirtiendo el problema en un error conocido), definir la solución más apropiada y generar la RFC (petición de cambio) correspondiente. Si sustituimos el término problema por el de incidente de seguridad, el modelo de gestión es perfectamente válido.

El segundo de los modelos que se suele utilizar para la gestión de incidentes de seguridad es el correspondiente a la gestión de no conformidades y acciones correctivas asociadas. Podemos sustituir el incumplimiento de las normas y/o procedimientos establecidos (la no conformidad) por la ruptura de las condiciones de seguridad establecidas (el incidente de seguridad), y a partir de ahí seguir la sistemática de registro y análisis estándar para las no conformidades aplicada al mismo. A partir de la no conformidad se definirán alas cciones correctivas necesarias para resolver la no conformidad, que en nuestro caso supondría identificar las acciones a acometer para solucionar la causa del incidente de seguridad.

Como se puede ver, ambos modelos son equivalentes, y perfectamente válidos para la gestión de incidentes de seguridad. No obstante, tienen algunos matices que no está de más tener en cuenta, por si las moscas.

En primer lugar, la gestión de problemas según ITIL tiene un carácter técnico. Esto supone que los incidentes de seguridad asociados a las personas (y muchos del ámbito de la confidencialidad lo son) van a tener dificultades para ajustarse al modelo. Por otra parte, también es necesario tener en cuenta que la gestión de problemas requiere de la gestión de incidentes y la gestión de cambios y versiones para completar el ciclo de gestión, ya que los incidentes de seguridad requieren tanto de la corrección instantánea de la situación que provoca el incidente (gestión de incidentes) como de la aplicación efectiva de la corrección (gestión de cambios y versiones) para poder considerar que el incidente de seguridad está cerrado. Y por último es necesario considerar, dentro de la gestión de cambios, que el carácter eminentemente operativo que subyace en este proceso puede ser insuficiente para tratar determinados incidentes de seguridad cuyas causas y/o consecuencias puedan llegar a ser de carácter estratégico.

El segundo modelo es complementario al anterior. Es un modelo de caracter más estratégico, de modo que tienen mayor cabida situaciones de carácter menos técnico u operativo, pero al mismo tiempo es un modelo mucho más vago y menos detallado. Tiene la ventaja de que, al exigir la participación activa de la dirección, las decisiones que se adopten van a contar con su "bendición", lo que desde el punto de vista de recursos y prioridades puede ser importante. No obstante, si restringimos el modelo a la gestión de no conformidades y acciones correctivas también sería un modelo incompleto, y para terminar de completarlo deberíamos considerar también ltanto a gestión de acciones preventivas (en relación a las debilidades de seguridad) como la realización de auditorías y el seguimiento de indicadores y cuadros de mando que exige cualquier sistema de gestión normalizado, de modo que también queden contemplado en el modelo el apartado preventivo de la gestión de incidentes de seguridad.

En definitiva, lo importante es que cada organización desarrolle su propia sistemática de gestión de incidentes de seguridad y que, independientemente del modelo que elija (alguno de estos dos o cualquier otro) sea un modelo completo, que contemple todos los apartados necesarios para una gestión efectiva de los incidentes de seguirdad.

26 agosto 2009

Incidentes y responsabilidades

Habitualmente, los que nos dedicamos a esto de la seguridad solemos hablar de riesgos, de controles, de prevención... Sí, también hablamos de incidentes de seguridad, pero habitualmente desde un punto de vista positivista: procedimientos de gestión, minimización de los efectos de los incidentes, etc. Pero muchas veces se nos olvida hablar de la cruda realidad: los incidentes ocurren. Y cuando ocurren, duelen.

Efectivamente, por mucha seguridad que tenga una organización, por mucho SGSI que tenga implantado y por muy bien que venda su certificado, nadie se libra de sufrir incidentes de seguridad. Tarde o temprano, a todo el mundo le toca. Y qué supone sufrir un incidente de seguridad? Veamos:
  • En principio, el incidente ha podido ser contra la disponibilidad (algo ha dejado de funcionar), la integridad (algo se ha corrompido) o la confidencialidad (se ha filtrado alguna información). La traducción respectiva de estas casuísticas es que algo se ha parado (lucro cesante), algo funciona mal (también lucro cesante) o alguien sabe algo que no debería (y eso nunca es bueno).
  • De los incidentes sólo nos enteramos cuando alguien lo notifica. Esto quiere decir que el hecho es conocido, al menos a nivel interno de la organización.
  • Los incidentes siempre tienen connotaciones negativas (intrínsecas al concepto, por éso hay gente que prefiere hablar de incidencias, más allá de las definiciones exactas que hagamos de ambos términos), y por tanto son intrínsecamente morbosos, lo que va a propiciar la progresiva expansión de su conocimiento, cuya velocidad será proporcional al impacto percibido.
  • Lo negativo y morboso, una vez que se ha difundido suficientemente, siempre ocasiona críticas, que se van realimentando y creciendo con la difusión. En el caso de la pérdida de confidencialidad estas críticas serán más evidentes, pero en cualquier caso el posicionamiento generalizado tenderá a criticar el hecho de que la organización haya "permitido" que ocurra el incidente, y más cuanto mayores sean las medidas dispuestas por la organización para tratar de evitar que ocurran.
  • Como consecuencia de lo anterior, es previsible un posicionamiento del personal "en contra" de la organización, al menos del grupo de personas conocedoras del hecho.
  • Este posicionamiento social contrario probablemente vaya a provocar reducciones en el rendimiento de la organización, derivadas de la desmotivación provocada.
  • Cuanto mayor sea el impacto del incidente, su morbosidad potencial o el posicionamiento negativo del personal más probabilidades habrá de que su existencia pueda ser conocida fuera de la organización. Obviamente, si la parada o el mal funcionamiento propios del incidente estaban asociados a servicios externos, su conocimiento por parte de entidades externas será mucho más probable.
  • A nivel externo las pautas de propagación del incidente son equivalentes, sustituyendo las personas por entidades y los agentes externos por medios de comunicación, aunque la velocidad de propagación a nivel externo habitualmente es mucho menor.
  • En el caso de incidentes a nivel externo tendremos que considerar también los efectos derivados del tipo de información que haya sido revelada o de los servicios que hayan dejado de estar operativos, y que pueden ir desde pérdidas de competitividad hasta incumplimientos contractuales o regulatorios, con los consiguientes efectos económicos asociados.
  • Todo ello podrá terminar provocando, a nivel externo, pérdida de prestigio o de reputación corporativa.

En definitiva, un incidente de seguridad ha podido ocasionar lucro cesante, pérdida de credibilidad a nivel interno, posicionamiento "social" en contra de la organización, reducción del rendimiento de la organización, pérdida de competitividad, penalizaciones económicas y pérdida de imagen pública. Obviamente, no todos los incidentes de seguridad van a tener tan "catastróficos" efectos, pero la clave es que debemos ser conscientes de que la gestión de los incidentes de seguridad no debe cubrir sólo los efectos directos del mismo, sino que todas estas derivadas deberían ser consideradas a la hora de llevar a cabo una gestión integral del mismo. Si no, corremos el riesgo de resolver el incidente y al mismo tiempo no ser capaces de cortar el flujo de acontecimientos que acabo de señalar...

24 agosto 2009

Cuestion de confianza

Con el paso del tiempo, cada vez son más las organizaciones certificadas en ISO 27001. Ahora ya no es extraño encontrar empresas que luzcan un certificado de seguridad, y poco a poco comienza a verse cómo algunas de ellas incluso están comenzando a valorar que sus proveedores también estén certificados.

Ante este panorama, la pregunta clave en torno al mercado de las certificaciones comienza a hacerse cada vez más patente. ¿Hasta qué punto una organización está dispuesta a confiar en el certificado de la otra? ¿Es requisito suficiente el hecho de estar certificado para que todo el mundo pueda confiar en tu gestión de la seguridad?

La pregunta tiene más miga de lo que parece. Por un lado, todo el que conozca cómo funcionan los esquemas de certificación sabe que no es suficiente con tener un certificado, sino que el alcance de dicha certificación debe cubrir el ámbito que nos interesa. Pero una vez verificado este aspecto (algo sencillo, ya que figura en el propio certificado), qué más aspectos hay que tener en cuenta?

Como ya he comentado en alguna ocasión, un SGSI tiene varias dimensiones. La primera viene dada por el alcance, pero no es la única. También deberíamos tener en cuenta la Declaración de Aplicabilidad (es decir, qué controles de seguridad tiene aplicados la organización y cuáles no), y además sería muy útil conocer cuál es el nivel de riesgo asumido por la organización, ya que ese parámetro nos va a dar la clave para conocer el grado de "intensidad" con el que se están aplicando los controles. Por tanto, para poder estimar el "nivel de seguridad" de una organización sin necesidad de conocer el detalle de su SGSI sería necesario conocer estos 3 parámetros.

Teniendo esto en mente, podemos darnos cuenta de que la clave de la confianza en el SGSI de otra organización no radica en el certificado en sí mismo, sino en el "nivel de seguridad" que dicha organización presenta en relación al que nuestra organización exige. De este modo, podría existir una organización para la que la simple posesión del certificado por parte del proveedor fuese suficiente garantía de seguridad, ya que esta organización no tiene requisitos particularmente exigentes en materia de seguridad para el servicio o producto de este proveedor, mientras que otra organización opte por definir exigencias mucho mayores en este ámbito debido a que las necesidades de seguridad que tiene para el mismo servicio o producto son mucho mayores.

El "problema" de los certificados en ISO 27001 es que los criterios de auditoría, las exigencias contra las que se contrastan los SGSIs en las auditorías de certificación, son sencillamente (que no es poco) la propia norma y la normativa interna de la organización, pero nunca se tendrán en cuenta las exigencias de los clientes (a no ser que se establezca expresamente o que la organización asuma explícitamente como propias dichas exigencias). Por lo tanto, si dichas exigencias exceden las de la propia organización, el diferencial existente nunca será auditado en las auditorías de certificación, y por tanto debería ser auditado expresamente en auditorías de segunda parte (realizadas por el cliente al proveedor), en las que se incluyan dichas exigencias como criterios de auditoría.

En definitiva, la cadena de confianza establecida por los certificados (presuponiendo que son certificados acreditados, y por tanto de reconocimiento mutuo independientemente de la entidad de certificación) es suficiente si las exigencias en materia de seguridad son las "normales", si consideramos que el cumplimiento de la ISO 27001 es suficiente garantía, mientras que si las exigencias en esta materia son superiores tendremos que recabar más información acerca del SGSI de nuestro proveedor o recurrir a las auditorías de segunda parte para poder verificar el cumplimiento de nuestras exigencias en seguridad.

03 agosto 2009

La culpa la tiene el gobierno... de TI

Buenos días a todos,

Aunque estoy de vacaciones, hoy quiero saldar una deuda pendiente con un colega. Hace ya algún tiempo (más del que me gustaría) recibí un mail suyo invitándome a publicitar un artículo escrito por él en el que indica una serie de recomendaciones para el correcto establecimiento de un Modelo de Gobierno TI, y la verdad es que, aunque leí el artículo y me pareció completamente recomendable, entre unas cosas y otras olvidé el mail y la recomendación asociada. Así que hoy cumplo con la deuda pendiente, con el consejo a todos los lectores de este blog de que lean el artículo con atención, ya que seguro que en algunos contraejemplos se van a sentir identificados:

La culpa la tiene el gobierno de TI, por Jose Manuel Fernández


Que paséis unas buenas vacaciones.

23 julio 2009

Gestion de Riesgos Vs Baselines

Hola a todos! La verdad es que últimamente tengo el blog bastante desatendido. Lo siento, pero por diversos motivos la verdad es que el tiempo no me da de sí ... Los días deberían tener más de 24 horas. Verdad?

Hoy sencillamente os quiero proponer un pequeño debate. O, al menos, una reflexión en la que os invito a participar. ¿Qué ventajas e inconvenientes veis a las dos estrategias de gestión de la seguridad que figuran en el título? ¿Cuál os gusta más? ¿Creéis que son compatibles?

En una de las esquinas del ring tenemos la gestión de riesgos de seguridad. Consiste en analizar los riesgos a los que estamos expuestos y aplicar medidas de seguridad para reducir aquellos riesgos que "sobresalen" por encima del nivel de riesgo que consideramos asumible. Las ventajas seguramente ya las conozcamos, pero como todo, siempre tiene un lado criticable: nada obliga a establecer un bajo nivel de riesgo aceptable, así que si asumimos riesgos elevados la seguridad que aplicaremos será "débil".

En la otra esquina tenemos la aplicación de baselines de seguridad. Consiste en establecer un cierto nivel de seguridad que conseguiremos mediante la aplicación de un determinado conjunto de medidas de seguridad específicas. Independientemente del riesgo, las medidas a aplicar son unas determinadas, con lo que conseguimos un nivel de seguridad "estandarizado", pero podremos estar haciendo una aplicación de medidas de seguridad ineficiente desde el punto de vista del riesgo.

Son dos alternativas válidas, cada una con sus ventajas y sus inconvenientes, aunque aparentemente poco compatibles. ¿Cuál os gusta? ¿Creéis que pueden ser compatibles? ¿Cómo? Estaré encantado de leer las opiniones de todos los que no estén de vacaciones...

30 junio 2009

ISO 20000 para PYMEs

Uno de los principales culpables de que le dedique menos tiempo a publicar comentarios en el blog es un proyecto de implantación de ISO 20000 en PYMEs en el que estoy participando. El objetivo es muy sencillo: ¿No dice el estándar que el Sistema de Gestión de Servicios TI (SGSTI) que propone la ISO 20000 es válido para organizaciones de cualquier tamaño? Pues vamos a demostrarlo implementándolo en PYMEs, con todas las limitaciones de este tipo de empresas (pocos recursos técnicos, pocos recursos humanos, pocos recursos económicos) y alguna más que nos hemos buscado, ya que para conseguir que el proyecto sea subvencionado por el Plan Avanza los plazos de implantación deben garantizar que dichos SGSTIs estén certificados antes de fin de 2009.

La verdad es que es un proyecto muy complejo, tanto a nivel "técnico" como a nivel de gestión. Pero de momento puedo decir que, con sus puntos fuertes y sus áreas de mejora, el proyecto marcha más o menos según lo previsto. Y aunque todavía no tengamos resultados definitivos, sí que hay algunos aspectos que a día de hoy ya creo que se pueden ir destacando. Entre ellos, tenemos:
  • Para las empresas que venden servicios TIC realmente la ISO 20000 tiene importantes connotaciones de negocio: sólo el hecho de adecuar los servicios prestados a las exigencias de la norma está proporcionando ventajas competitivas a las organizaciones a la hora de posicionar sus servicios respecto de los de la competencia.
  • Un SGSTI no tiene por qué ser un monstruo: Si atendemos exclusivamente a los requisitos mínimos que exige la ISO 20000, es posible desarrollar procesos y servicios con unas dedicaciones totalmente asumibles por pequeñas organizaciones.
  • No es imprescindible una super-herramienta para implementar los procesos definidos por la ISO 20000: Aunque las herramientas ayuden mucho, unas pocas aplicaciones bien seleccionadas, la voluntad del equipo de trabajo y un poco de sentido común nos pueden permitir suplir las funcionalidades de herramientas de elevado coste.

En definitiva, sigo pensando no sólo que es posible implementar un SGSTI certificable bajo ISO 20000 en una PYME, sino que un proyecto bien definido en este ámbito puede permitir a dicha PYME obtener beneficios directos y tangibles a la hora de comercializar sus servicios TI, con una inversión relativamente pequeña y amortizable a corto plazo. Y a día de hoy, eso es todo lo que puedo contar...

24 junio 2009

Tecnología Vs Uso

Hoy me he encontrado con este post, un poco por casualidad, pero la verdad es que me ha resultado muy interesante. En él, un conocido blogger (entre otras cosas) analiza las implicaciones de la tecnología de reconocimiento facial en función de los casos de uso, a través de dos casos concretos con distintas implicaciones y percepciones incluso opuestas de la misma tecnología.

La verdad es que el post me parece un ejemplo muy ilustrativo de la neutralidad tecnológica y de cómo lo importante no es la tecnología en sí misma, sino el uso que se haga de ella. E incluso hay que tener en cuenta que usos similares en entornos distintos pueden tener consecuencias muy diferentes, y apreciaciones subjetivas muy distintas, en función de las características del entorno.

Más allá del propio ejemplo, sería muy interesante analizar la aplicabilidad de la LOPD a los usos comentados en el artículo, y las implicaciones que puede tener eso de poder identificar a las personas que aparecen en las fotografías. ¿Estamos en un ámbito estrictamente personal, o es dicha ley aplicable? ¿Qué entidades desempeñarían cada uno de los roles definidos por dicha reglamentación? Un caso de estudio bastante interesante para cualquiera que esté dispuesto a moverse por terrenos resbaladizos, creo...

En definitiva, creo que el citado artículo supone un estupendo ejemplo para poder analizar cómo lo técnico, lo legal y lo moral se entremezclan hasta mucho más allá de lo que podríamos suponer en un principio. ¿Está nuestra sociedad preparada para dar respuestas a estas situaciones? ¿En los 3 ámbitos? Seguro que todavía hay mucho que decir al respecto.

02 junio 2009

Seguridad en prensa

Estos últimos días me ha llamado la atención ver cómo algunos incidentes de seguridad han trascendido más allá de los medios especializados y han llegado a la prensa generalista. Puede que sean situaciones un poco anecdóticas, pero también es cierto que a veces este tipo de hechos son formas muy efectivas de difundir al público en general ciertos conceptos que sin la anécdota jamás llegarían a calar.

El primero es la difusión pública de un vídeo porno en una torre de préstamo de bicis. Parece ser que algún hábil pirata informático consiguió acceder al terminal de préstamo de bicis y reproducir el citado vídeo porno en lugar de la aplicación que controla el alquiler de las bicis. Y claro, en plena calle no tardó en ser advertido por los viandantes... hasta que finalmente la policía "resolvió" el incidente tapando la pantalla con unos folios.

El segundo, mucho más desapercibido, es la posibilidad que tuvieron los periodistas de escuchar una conversación privada entre los presidentes de Brasil y Venezuela porque los aparatos de traducción automática se conectaron antes de tiempo. En este caso fueron los agentes de seguridad los que resolvieron el incidente, recogiendo los aparatos repartidos.

Dos simples ejemplos de incidentes de seguridad relacionados con la integridad de la información visualizada en el primer caso y la confidencialidad de la información hablada en el segundo. En conjunto, un buen ejemplo para recordar algunos conceptos básicos, como:
  • Los incidentes de seguridad pueden tener efectos directos sobre temas tan estratégicos como el prestigio y la imagen.
  • Los terminales públicos también deben ser apropiadamente securizados, aunque aparentemente su importancia pueda no ser excesivamente grande.
  • No sólo la información en soporte electrónico es susceptible de ser atacada.
  • Cualquier medio es susceptible de ser utilizado para provocar una violación de la seguridad.

En definitiva, dos buenos ejemplos para utilizar en las típicas charlas de seguridad que a todos nos ha tocado dar alguna vez.

28 mayo 2009

Seguridad abierta

Lo sé. Últimamente casi no posteo nada. La verdad es que el trabajo diario me está consumiento todo el tiempo y más... Aunque la verdad es que lo asumo de buen grado, porque los proyectos que estamos desarrollando lo merecen. A ver si un día de estos me salto mi regla no escrita de no hablar de los proyectos que tengo y os presento alguno...

Al grano. Surfeando por la red me he encontrado, sin saber muy bien cómo, con un artículo en el que se habla de innovación abierta. Un artículo que, en su interior, afirma que las empresas "han levantado sistemas de defensa antiaérea para explotar su conocimiento", en los que "los escudos antimisiles tienen forma de patentes y contratos de confidencialidad". Y contrapone este planteamiento al de la innovación abierta, afirmando que la libertad personal es imprescindible para generar nuevo conocimiento, que eso supone descontrol, y que "los sistemas de gestión están diseñados para que eso no ocurra".

Estas frases me han hecho reflexionar. ¿Realmente son tan contrarias la innovación-libertad y el control-gestión? El artículo habla de innovación abierta, de la innovación desarrollada no de forma aislada dentro de las organizaciones sino en cooperación con el exterior. ¿Realmente los escudos de seguridad de las empresas son un freno a la innovación, y por tanto al negocio?

La clave, como parece obvio, debería estar en el "justo medio", en la libertad controlada, en el caos gestionado (y seguro). Aunque claro, es más fácil decirlo que hacerlo. Existe la seguridad abierta? La seguridad siempre ha consistido en poner límites, acotar, controlar. En resumidas cuentas, restringir parcialmente la libertad. Y no obstante, yo creo que libertad y seguridad son compatibles, tal y como podemos interpretar de las posturas de Hobbes. En el fondo, sería algo así como que la libertad de un individuo acaba donde comienza la seguridad del resto...

De todas formas, la seguridad abierta tampoco me parece imposible de conseguir. Al igual que en criptografía ya se produjo el cambio de mentalidad de la "seguridad por oscuridad" a la "seguridad abierta", estoy convencido de que ese mismo cambio es posible que se pueda producir en otros ámbitos relacionados con la seguridad. De todos modos, mi gran duda al respecto es ¿Estamos preparados para asumir el cambio de mentalidad que requiere?

En definitiva, creo que el sector de la seguridad debe ir soltando lastre, olvidando los viejos paradigmas de la seguridad en los que la caja fuerte más segura es aquella que no tiene puerta y tratar de avanzar por el camino de la seguridad abierta. No obstante, también creo necesario recordar a los "ultras" de la "apertura" que, al igual que existe el límite entre libertad y libertinaje, nunca será posible una seguridad 100% abierta. Al fin y al cabo, en los sistemas de criptografía pública también hay una clave secreta, verdad? Aunque claro, encontrar ese límite ya es otro cantar...

14 mayo 2009

No lo hagas sin proteccion

El consejo es de Forrester, y no hablan de sexo. Hablan de externalizar servicios en la nube sin tomar las precauciones previas necesarias, en materia de:
  • Seguridad
  • Privacidad
  • Propiedad intelectual
  • Cumplimiento legal

Este tema no es nuevo para los lectores de este blog, pero ahora que lo dice una consultora con tanto prestigio, seguro que el mensaje cala más...

Y ojo, que si el salto a la nube "en general" tiene sus riesgos, en materia de seguridad puede que incluso sean todavía mayores. Y si tres de cada cuatro empresas lo están haciendo, podemos estar ante un problema de dimensiones mucho mayores de las aparentes...

07 mayo 2009

Videovigilancia y LOPD

Hoy he leído un informe jurídico de la AEPD relativo a las copias de seguridad en los ficheros de videovigilancia que, sinceramente, me ha dejado impactado. No por el contenido, que en realidad tiene bastante lógica desde el punto de vista legal, sino por las implicaciones prácticas que tiene. En resumen, viene a decir que:
  • Todos los ficheros de videovigilancia tienen que tener backup.
  • La cancelación mensual de los datos no supone su borrado definitivo, sino sólo que no puedan ser tratados (accedidos).
  • Tanto los datos originales como el backup sólo podrán ser eliminados cuando estemos seguros de que no incumplimos ninguna responsabilidad legal al hacerlo.

En definitiva, que los sistemas más habituales, de sobreescritura mensual, no cumplen la LOPD. Necesitaríamos sacar esta información a un soporte externo al sistema antes de que fuese sobreescrita, y almacenarla en un medio no directamente accesible por el sistema original durante un tiempo mayor, antes de poder eliminar definitivamente la grabación. ¿Cuánto tiempo? Es mi principal duda. Seguro que los abogados pueden contestar a esto mejor que yo, pero me da la sensación de que, si entendemos de forma amplia eso de no incumplir posibles responsabilidades legales, posiblemente podamos llegar a situaciones en las que el requisito puede ser de varios años... Y eso conlleva unos costes importantes, ya que el backup es continuamente creciente. Espero equivocarme, porque si no puede que los fabricantes de soportes hagan el agosto a costa de este informe jurídico... y de las empresas con ficheros de videovigilancia.

29 abril 2009

Securmatica 09

La semana pasada estuve un par de días por Securmática, uno de los congresos del sector más importantes a nivel nacional y un buen lugar para hacerse una idea de cómo se está moviendo la seguridad.

En el congreso se habló de muchas cosas, pero por tratar de resumir un poco, algunos de los aspectos que me parecieron más destacables son los siguientes:
  • Los servicios de seguridad gestionada (SOC, o como prefiráis) están empezando a pegar fuerte. Todavía no son tantas las organizaciones que externalizan parte de la seguridad (principalmente la operación técnica de bajo nivel), pero la seguridad como servicio externalizado está empezando a coger fuerza. Ojo, porque el modelo que propone puede provocar cambios en ciertas presunciones que hasta el momento no habían sido cuestionadas.
  • La necesidad de un cuadro de mando de seguridad cada día es mayor, sobre todo frente a soluciones de seguridad cada vez más diversificadas y para poder afrontar con garantías la mayor madurez de las organizaciones en esta materia. Hay muchas empresas que ya están empezando a trabajar en serio en estos ámbitos.
  • La seguridad de la información cada vez tiene las fronteras más difuminadas, y frente a tanta alternativa de evolución las vías de avance son múltiples. En unos casos predomina la seguridad lógica TI, en otros la seguridad física clásica, hay otros que tienden hacia la gestión de riesgos corporativos... y todos sabemos que quien mucho abarca poco aprieta.
  • A nivel técnico, parece que tanto la gestión de identidades y el single-sign-on como la gestión de logs siguen pegando fuerte y poco a poco son soluciones que se van extendiendo entre las empresas. Pero atención a las nuevas tecnologías, ya que bajo las siglas DLP se están posicionando diversos productos que prometen dar mucho que hablar en el medio plazo.

En definitiva, parece que el sector se mueve. Quizás los cambios sean lentos, es posible que los riesgos a los que tenemos que hacer frente evolucionen a mayor velocidad que nosotros, pero al menos nos movemos, que no es poco. Sobre todo, como no se cansaron de repetir en el congreso, en los tiempos que corren, cuando puede que la inversión en seguridad esté más cuestionada de lo normal. Y con el paso del tiempo podremos ir viendo si nuestros movimientos están siendo acertados...

07 abril 2009

Alcances certificables para ISO 20000

Como ya he comentado alguna vez, definir qué tipo de alcances son certificables bajo ISO 20000 no es un tema sencillo. Los requisitos para conseguir la certificación son fáciles de resumir: montar el sistema de gestión, desarrollar los 13 procesos que define el estándar y aplicar el SGSTI a los servicios a certificar. No obstante, en muchas ocasiones surgen dudas en este último apartado. ¿Qué tipos de servicios son certificables bajo este estándar?

Desde mi punto de vista, podemos encontrar varios tipos de servicios susceptibles de serlo:
  • Servicios desarrollados por sistemas informáticos: Serían todos aquellos servicios que son prestados por aplicaciones o plataformas tecnológicas concretas, entre los que podemos encontrar no sólo los "típicos" ejemplos (correo electrónico, DNS, etc.) sino también servicios prestados a través de aplicaciones desarrolladas a medida, servicios prestados en modo SaaS, etc.
  • Servicios de CPD: Serían todos aquellos servicios orientados al albergue físico y/o lógico de sistemas, entre los que tenemos tanto los clásicos de un datacenter (hosting, housing) como las modernas versiones virtualizadas que están empezando a aparecer.
  • Servicios de soporte técnico: Aquí podemos englobar todos aquellos servicios profesionales prestados en régimen de outsourcing, orientados a TI y en los que la propia infraestructura TI utilizada tiene un peso específico propio fundamental para la prestación del servicio. En esta categoría podemos encontrar desde servicios de asistencia técnica hasta servicios de mantenimiento o help-desk.

Es posible que esta última tipología pueda haber sorprendido a alguien, ya que anteriormente había mostrado ciertas dudas al respecto. No obstante, aunque creo que es en la que mayores matizaciones habría que hacer caso por caso, ver de primera mano que es posible me ha servido para terminar de convencerme. Por lo tanto, si alguien tiene un servicio que se encuadre en alguna de estas tres categorías... ya sabe que puede intentarlo.

24 marzo 2009

Seguridad y redes sociales: el tema de moda

Pues sí, hay que reconocer que la seguridad en las redes sociales es un tema que está de moda dentro del sector. Y no es para menos.


Hace un par de meses, INTECO publicaba un estudio sobre la privacidad de los datos personales y la seguridad de la información en las redes sociales online, en el que se analiza con rigor y bastante profundidad la problemática asociada a este entorno.


La semana que viene, la cátedra UPM APPLUS+ de seguridad y desarrollo de la sociedad de la información, CAPSDESI, organiza un seminario gratuito sobre el tema, que también podrá ser seguido por Internet tanto en directo como en diferido (módulos I, II, III, IV, V, VI y VII disponibles a partir del día 7).

No hay más que hacer una búsqueda de noticias sobre estos temas para darse cuenta de que no sólo hay cientos de noticias en el último mes al respecto, sino que prácticamente a diario aparecen noticias al respecto en algún medio digital de habla hispana. Y eso por no hablar de los miles de blogs con comentarios al respecto que nos podemos encontrar...

¿Realmente es tan importante el tema? ¿Hasta qué punto estamos ante una "moda" o frente a "algo más"? Y lo que es más importante ¿Sirve de algo esta "explosión" de referencias al respecto?

La verdad es que me resulta difícil realizar una valoración objetiva. Creo que sí es importante abordar el tema, que realmente el debate debería llegar a ser un tema de "actualidad", aunque es obvio que, dada la temática del blog, tengo predisposición a ello. Pero por otra parte también tengo la incómoda sensación de que a veces hay más de oportunismo y de comentario fácil al respecto de lo que me gustaría reconocer. Sobre todo a la hora de escuchar o leer ciertos análisis, en muchas ocasiones clones unos de otros que sólo tratan de "llenar un espacio" sin tratar de profundizar en la compleja casuística que hay por debajo.

Y el problema, en el fondo, creo que radica en que muchos de nosotros no terminamos de entender las redes sociales. Sobre todo si pensamos en jóvenes, adolescentes y niños que hacen un uso despreocupado de ellas. Analizamos el problema de la seguridad y de la privacidad desde fuera, desde nuestro propio punto de vista, y creo que eso es un error. Tengo la sensación de que la clave no está en descubrir la nota exacta que tiene y/o tiene que tener la seguridad en las redes sociales, sino en analizar por qué muchos usuarios están dispuestos a "sacrificar" dicha seguridad a cambio de los beneficios que obtienen de su uso. Porque mientras no hagamos el esfuerzo de tratar de entender a los usuarios de estas redes, a esos que desde nuestro punto de vista tienen un nivel de riesgo que "no deberían estar dispuestos a asumir", nunca conseguiremos el que creo que debe ser el objetivo de todas estas referencias: que los usuarios "normales", los de a pie de calle, sean capaces de valorar esos riesgos y puedan decidir con todas las consecuencias si están dispuestos o no a asumirlos. Y a partir de ahí, a ver cuáles son los resultados...

16 marzo 2009

Outsourcing y riesgos

La semana pasada leía un artículo sobre cómo mitigar los riesgos en la seguridad de los datos al hacer outsourcing global (I y II) del que, más allá del propio contenido del artículo, se puede sacar una interesante lista de elementos de seguridad a contemplar a la hora de externalizar servicios:
  • Cumplimiento legal, en general y específicamente en materia de seguridad
  • "Políticas" implementadas en los dispositivos de seguridad
  • Arquitecturas de red seguras
  • Seguridad en las comunicaciones (cifrado, control de acceso, ...).
  • Seguridad en la gestión interna del proveedor de servicios (ISO 27001 / ISO 20000 / ITIL)
  • Controles de seguridad del personal
  • Controles de seguridad física y ambiental
  • Seguridad en el desarrollo y mantenimiento de sistemas
  • Clasificación de la información en base a su criticidad y tratamiento de acuerdo a dicha clasificación
  • Definición de roles y funciones asociados al acceso a la información
  • Medidas de seguridad técnica mínimas a cumplir por el proveedor de servicios
  • Evaluar específicamente los riesgos de seguridad asociados a cada proveedor
  • Verificar el cumplimiento, por parte del proveedor de servicios, de alguna certificación de seguridad asociada al servicio que nos presta
  • Auditar al proveedor (auditorías de segunda parte)
  • Especificar contractualmente las condiciones de seguridad que debe cumplir el proveedor
  • Existencia de una cultura de seguridad en el proveedor, verificable por la existencia de funciones y roles asociados específicamente con la seguridad

Es evidente que esta lista no es exhaustiva, y que seguro que se os ocurren multitud de detalles a incluir a la hora de verificar que las condiciones de seguridad que ofrece un proveedor son las necesarias. No obstante... ¿cuántos de estos apartados figuran expresamente en vuestros contratos de prestación de servicios? ¿Conocéis proveedores de servicios de outsourcing que ofrezcan este tipo de garantías de seguridad? Echáis en falta alguna en concreto? Espero vuestros comentarios.