En estos últimos tiempos estamos presenciando cada vez más iniciativas legislativas en torno al sector de la seguridad. Por un lado, a principios del año pasado presenciábamos el nacimiento del ENS. Por otro lado, estas navidades veíamos cómo el nuevo Código Penal introducía el concepto de la culpa in vigilando en torno a la responsabilidad penal de las personas jurídicas, obligando a las organizaciones a garantizar el debido control corporativo. Este año hemos visto cómo, en un tiempo récord, surgía la Ley 8/2011 para la Protección de las Infraestructuras Críticas y el Real Decreto 704/2011 por el que se aprueba el Reglamento que desarrolla la LPIC. En todas ellas, la correcta aplicación y gestión de la seguridad de la información y los entornos TIC es el núcleo de su aplicación.
Después de ver este panorama, me asalta una duda existencial. Serán estas leyes las alas de la mariposa, y dentro de algún tiempo acabaremos viendo el tsunami provocado? O quizás debamos echar la vista atrás y buscar el aleteo que ha provocado este despliegue legislativo? Está sufriendo el sector su propio efecto mariposa?
06 junio 2011
26 mayo 2011
ENS practico
Hoy sólo quiero poner en común con todos vosotros un par de documentos que seguro que os sirven de ayuda si queréis acercaros a la parte práctica de una implantación de las medidas de seguridad que indica el Esquema Nacional de Seguridad:
- La Guia de Implantacion del Esquema Nacional de Seguridad de AMETIC, un documento que, además de explicar el ENS, incluye un apartado con un caso práctico que seguro que resultará de mucha utilidad para cualquiera que se enfrente por primera vez a una implantación de un ENS.
- El libro Esquema Nacional de Seguridad con Microsoft, un documento que recoge la propuesta de Microsoft para implementar, utilizando sus tecnologías y productos, las medidas de seguridad exigidas por el ENS.
18 mayo 2011
El resumen de tu seguridad
Hace más de un mes que no publico nada. Sigo aquí, aunque por diversos motivos me he tenido que mantener off-line más tiempo del que me hubiera gustado. No obstante, espero que este alejamiento temporal pueda concluir dentro de no demasiado tiempo, y sobre todo que merezca la pena. Ya os contaré...
Hoy quiero referenciar un artículo que he leído en estos últimos tiempos, y que me ha parecido un estupendo alegato acerca de la utilidad de la declaración de aplicabilidad. No es muy extenso, y en cambio es tremendamente acertado, así que animo a todos a leerlo.
En resumidas cuentas, la declaración de aplicabilidad es el resumen de tu seguridad. Es un documento mediante el cual se puede realizar una aproximación sencilla, apta "para todos los públicos", del "tamaño" de tu seguridad. Hace ya mucho tiempo que hablé en el blog de las dimensiones de un SGSI, y sin embargo creo que a día de hoy su vigencia sigue intacta.
La ventaja que tiene este documento es que puede servir, sin comprometer demasiado la confidencialidad de la información asociada, para orientar a los clientes u otras partes interesadas sobre la "fortaleza" de tu seguridad, algo que puede ser muy útil a la hora de firmar acuerdos en los que la seguridad sea un factor importante a considerar. ¿Pediríais vosotros la declaración de aplicabilidad a un proveedor, por poner un ejemplo concreto, de servicios en la nube? ¿Qué otra documentación os parece importante solicitar (y pensáis que puede ser "conseguible"?
Hoy quiero referenciar un artículo que he leído en estos últimos tiempos, y que me ha parecido un estupendo alegato acerca de la utilidad de la declaración de aplicabilidad. No es muy extenso, y en cambio es tremendamente acertado, así que animo a todos a leerlo.
En resumidas cuentas, la declaración de aplicabilidad es el resumen de tu seguridad. Es un documento mediante el cual se puede realizar una aproximación sencilla, apta "para todos los públicos", del "tamaño" de tu seguridad. Hace ya mucho tiempo que hablé en el blog de las dimensiones de un SGSI, y sin embargo creo que a día de hoy su vigencia sigue intacta.
La ventaja que tiene este documento es que puede servir, sin comprometer demasiado la confidencialidad de la información asociada, para orientar a los clientes u otras partes interesadas sobre la "fortaleza" de tu seguridad, algo que puede ser muy útil a la hora de firmar acuerdos en los que la seguridad sea un factor importante a considerar. ¿Pediríais vosotros la declaración de aplicabilidad a un proveedor, por poner un ejemplo concreto, de servicios en la nube? ¿Qué otra documentación os parece importante solicitar (y pensáis que puede ser "conseguible"?
15 abril 2011
El futuro de los estandares de continuidad de negocio
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?
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?
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)
