El mundo de los estándares de continuidad de negocio está sufriendo un lento pero progresivo cambio. Por un lado, hace mes y medio que se publicó la ISO 27031, que sustituye e internacionaliza la antigua BS 25777 sobre continuidad TIC. Este hecho, además, supone reconocer la continuidad TIC como uno de los aspectos propios de la seguridad de la información, puesto que pasa a formar parte de la serie ISO 27000, pero por otro lado lo "aleja" de la continuidad de negocio, ya que el estándar que define los requisitos para el establecimiento de un sistema de gestión dentro de esta serie es la ISO 27001.
Por otro lado se va avanzando en la redacción del futuro estándar de continuidad ISO 22301, que establece los requisitos para un sistema de gestión de la continuidad. Curiosamente, el borrador actual parece que no utiliza el término "negocio", y en su lugar aparece el concepto "preparedness" (algo así como "estar listo para entrar en acción") para el que no se me ocurre un buen término en español. Esta norma sustituirá a la actual ISO 22399, y según parece también lo hará con las vigentes BS 25999 y UNE 71599. No obstante, en este caso el estándar no pertenece a la serie de seguridad de la información, sino que está desarrollado por el comité técnico ISO/TC 223 sobre "societal security" (término para el que tampoco se me ocurre una traducción apropiada, aunque el término seguridad corporativa quizás pueda valer). Por tanto, parece que la separación entre "negocio" y "tecnología" se acentúa en la evolución de estos estándares de continuidad a normas ISO, lo cual me agrada especialmente, como podréis suponer.
De todos modos, sigo viendo una importante carencia en este tipo de estándares de continuidad (al menos, a falta de una definición más exacta de su alcance). Carencia que, además, me da la sensación de que puede ser una de las causas de que su adopción no se esté extendiendo tan rápidamente como se preveía inicialmente. Y es carencia es que, en general, los riesgos que gestionan este tipo de estándares suelen ser riesgos operativos (u operacionales), mientras que cuando se habla de negocio en cualquier organización, todo el mundo suele pensar inicialmente en riesgos económico-financieros y/o como mucho en riesgos de mercado. Quizás el problema sea tan sólo el nombre (y ese pueda ser uno de los motivos por los que se ha eliminado el término "negocio" en la versión ISO), pero por otro lado estoy seguro de que si este tipo de estándares de gestión cubriesen de algún modo este tipo de riesgos más propios del "negocio" su adopción por parte de todo tipo de organizaciones sería mucho más amplia. ¿Estáis de acuerdo?
15 abril 2011
14 abril 2011
Publicada la nueva ISO/IEC 20000-1:2011
El pasado martes se publicó la nueva versión de la ISO 20000. Esta versión sustituye oficialmente a la ISO/IEC 20000-1:2005, y despeja todas las dudas acerca de su contenido. Ya está disponible! Ahora podremos verificar cuántas de las suposiciones previas y de los cambios previamente anunciados eran ciertas.... Al menos, lo que sí se puede comprobar es que efectivamente la nueva versión aumenta su tamaño en un 60%. ¿Serán también correctas el resto de las suposiciones? Seguro que tras una lectura detallada descubriremos la respuesta.
05 abril 2011
Seguridad y meta-gestión
La consultoría es un timo. Esa fue la frase que escuché hace unos días, al tiempo que la mitad de los presentes ponía (poníamos) una cara horrorizada -los "consultores"- y la otra mitad sonreía con gesto de aprobación -los "clientes". Y hablaba de consultoría de seguridad...
En el fondo, el que dijo aquella frase tenía algo de razón. Un consultor debería ser un consejero, alguien a quien le cuentas tus problemas (de seguridad, o de lo que sea) y te propone soluciones (buneas, bonitas, y baratas). Ni más, ni menos. Pero claro, piensas en la consultoría que hacen muchas organizaciones a día de hoy, y le entiendes. Documentación vendida "al peso", mínima personalización -cuando no copy-paste de algún otro cliente-, poca utilidad práctica... Es muy difícil entender que esos "entregables" son las soluciones prometidas.
Y en el mundo de la seguridad la situación todavía puede empeorar más. Normalmente los clientes tienen problemas de seguridad reales, han sufrido incidentes, sus máquinas son vulnerables, su personal "pasa" de la seguridad... y los consultores ni siquiera le ofrecen seguridad, sino gestión. Algunos, incluso meta-gestión: un consultor es la única persona capaz de darle a un cliente un procedimiento sobre cómo escribir procedimientos de seguridad sin necesidad de ayudarle a resolver los problemas (de seguridad) que deben arreglar esos procedimientos. ¿O no?
En el fondo, la situación no es tan absurda. Usando terminología "consultora", la clave es la forma de encarar el problema: top-down o botton-up. Podemos empezar por enseñar a gestionar y conseguir que esa gestión vaya consiguiendo una mejora de la seguridad aplicada, o empezar aplicando medidas de seguridad y luego enseñar cómo se deben gestionar. La aproximación "consultora", clásicamente "top-down", puede argumentar que estamos enseñando a pescar (o incluso a construir cañas, si pensamos en meta-gestión), pero se nos olvida un "detalle" fundamental: el cliente muchas veces tiene hambre. Y en función del tiempo que necesite para aprender a pescar, puede morir de hambre antes de haber aprendido...
En definitiva, creo que para perder el halo de "timo" que algunas personas asocian a la consultoría tenemos que empezar a ser más prácticos, entender más los problemas de nuestros clientes y poner los pies en la tierra a la hora de definir los "entregables". Resumiendo, enseñar a pescar está bien, pero os puedo asegurar -y más ahora que acabo de terminar de comer- que siempre se aprende más con el estómago lleno (los que no quieran perder la terminología "consultora" le pueden llamar quick-wins).
En el fondo, el que dijo aquella frase tenía algo de razón. Un consultor debería ser un consejero, alguien a quien le cuentas tus problemas (de seguridad, o de lo que sea) y te propone soluciones (buneas, bonitas, y baratas). Ni más, ni menos. Pero claro, piensas en la consultoría que hacen muchas organizaciones a día de hoy, y le entiendes. Documentación vendida "al peso", mínima personalización -cuando no copy-paste de algún otro cliente-, poca utilidad práctica... Es muy difícil entender que esos "entregables" son las soluciones prometidas.
Y en el mundo de la seguridad la situación todavía puede empeorar más. Normalmente los clientes tienen problemas de seguridad reales, han sufrido incidentes, sus máquinas son vulnerables, su personal "pasa" de la seguridad... y los consultores ni siquiera le ofrecen seguridad, sino gestión. Algunos, incluso meta-gestión: un consultor es la única persona capaz de darle a un cliente un procedimiento sobre cómo escribir procedimientos de seguridad sin necesidad de ayudarle a resolver los problemas (de seguridad) que deben arreglar esos procedimientos. ¿O no?
En el fondo, la situación no es tan absurda. Usando terminología "consultora", la clave es la forma de encarar el problema: top-down o botton-up. Podemos empezar por enseñar a gestionar y conseguir que esa gestión vaya consiguiendo una mejora de la seguridad aplicada, o empezar aplicando medidas de seguridad y luego enseñar cómo se deben gestionar. La aproximación "consultora", clásicamente "top-down", puede argumentar que estamos enseñando a pescar (o incluso a construir cañas, si pensamos en meta-gestión), pero se nos olvida un "detalle" fundamental: el cliente muchas veces tiene hambre. Y en función del tiempo que necesite para aprender a pescar, puede morir de hambre antes de haber aprendido...
En definitiva, creo que para perder el halo de "timo" que algunas personas asocian a la consultoría tenemos que empezar a ser más prácticos, entender más los problemas de nuestros clientes y poner los pies en la tierra a la hora de definir los "entregables". Resumiendo, enseñar a pescar está bien, pero os puedo asegurar -y más ahora que acabo de terminar de comer- que siempre se aprende más con el estómago lleno (los que no quieran perder la terminología "consultora" le pueden llamar quick-wins).
Suscribirse a:
Entradas (Atom)