7/3/09

SGSI virtuales

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

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

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

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


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


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


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


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


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

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

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

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

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



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

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

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

7 comentarios:

Anónimo dijo...

Yo nunca olvidaría la formación en seguridad de la información. Desde la cúspide a la base de la pirámide.

Salu2

Javier Cao Avellaneda dijo...

Pues tienes toda la razón. Es además un pre-requisito a la implantación de un SGSI porque no hay nada peor para un gestor que no saber sobre lo que gestiona.

Anónimo dijo...

Javier, felicitaciones por el post, es totalmente cierto lo que indicas, lamentablemente es una situación mucho más cotidiana de lo que debería ser.

Creo que también habría que mejorar la calidad de la revisión para que quiénes deben dar la certificación puedan identificar estos SGSI virtuales.

Saludos

Anónimo dijo...

Buenas Javier,

Todo ésto que comentas me suena mucho, ésto también lo he visto yo también en muchas empresas que se quieren adecuar a la LOPD y al RDLOP "por cumplir el expediente"; pero que realmente no se preocupan en aprovechar las ventajas que les puede aportar el cumplimiento de la LOPD (en cuanto a la seguridad de la información se refiere).

También creo yo que es labor nuestra de los consultores, de dotarles de procedimientos que sean sencillos de manejar y que sean fácilmente entendibles por los clientes.

Unknown dijo...

En la vida y obra del buscon Don Pablos describia al caballero para el que servia, viejo hidalgo, de mucha nobleza, pero mucha mas pobreza. Tras haber encontrado un trozo de pan, no lo usó en comerlo, pese al hambre que pasaba, sino en desmigarlo y hecharselo sobre el pecho para parecer que había comido.

Los siglos pasan, pero estas practicas perviven, convenientemente modificadas.

Existe una triste practica es España, que es la certificación como objetivo, no ya en seguridad, sino en cualquier otra area, como la calidad. Y es que se le da mas importancia a lo que se parece que a lo que se es.

Consultor dijo...

Hola Javier
Soy consultor en Seguridad de la Información y tengo una duda (Tal vez no sea el comentario apropiado para esta etiqueta ... pero necesitaba saberlo) He leido algunos comentarios tuyos en los grupos de google que refieren a los procesos del alcance del SGSI. Mi duda va por lo siguiente: Por ejemplo las áreas y procesos relacinados a RRHH y Seguridad física no estan contemplados dentro de los procesos que delimitan el alcance del SGSI de un cliente. Esto significa que en el SOA no voy a considerar los controles referentes a estas areas y procesos?. Y en el caso de que sea así .. sería una justificación de exclusión el que no estén dentro del alcance del SGSI?.

Te pregunto esto porque en todos los clientes que he estado involucraban estas áreas y/o procesos pero ahora en el cliente que estoy es distinto.

Por otro lado, en Perú existe una entidad reguladora para las empresas financieras que es la SBS (Superintendencia de Banca y Seguros) y ha sacado ahora ultimo una circular (que es una especie de norma) y en uno de sus articulos indica asi: "Artículo 5°.- Como parte de su sistema de gestión de la seguridad de información, las empresas deberán considerar, como mínimo, la implementación de los controles generales que se indican en el presente artículo.
5.1 Seguridad lógica (...)
5.2 Seguridad de personal (...)" y ahi incluyen la mayoria de los controles de la ISO 27002. Mi pregunta es: Si es que estos articulos son requisitos mínimos para obtener la aprobación de funcionamiento de la SBS, entonces digamos en el el marco peruano las empresas están obligadas a incluir las áreas y procesos mencionadoas con anterioridad (RRHH, Seguridad, etc.)?

Gracias

Javier Cao Avellaneda dijo...

Que no tengan posibilidad de decidir medidas respecto a un área no significa que ese área tenga que excluirse. En organizaciones muy grandes, los alcances pueden limitarse a uno o dos departamentos pero hay áreas que no perteneciendo al alcance, si que pueden alterar la seguridad. En el caso que planteas, estos servicios "fuera del alcance" habría que gestionarlos como "terceros" sobre los que hay que hacer un seguimiento. La idea es que aquello donde delegues seguridad debes tenerlo controlado vía los controles de los objetivos 6.2. y 10.2.

Si no puedes decidir qué hacer en un área porque depende de terceros, siempre puedes regular vía contractual qué requisitos mínimos necesitas para considerar que el servicio cubre tus necesidades de seguridad. En tu caso, le trasladas al tercero el cumplimiento de esas medidas y puedes reservarte el derecho de auditar.

Si son departamentos de una misma organización y no es viable la regulación contractual, entonces habrá que considerar que dichas áreas puede que sea necesario que se incluyan dentro del alcance, dado que existen requisitos legales o regulatorios que obligan a la selección de controles que no pueden ser delegados.

En cualquier caso, en el SOA siempre que aparecen medidas que no son gestionadas directamente por tí, puedes indicar que son proporcionadas por un tercero y que son vigiladas por los controles de los objetivos 6.2. y 10.2.