IMPLANTACIÓN DE UN SGSI ADOPTANDO LA ISO 27001

Resumen: Se presentan todos los pasos seguidos por un CSP (Cloud Services Provider) para implantar un SGSI (Sistema de Gestión de la Seguridad de la Información) basado en la Norma ISO 27001, coexistiendo con los demás procesos ITIL de Gestión de TI.

 

Autor del artículo		Colaboración
OLOF SANDSTROM
Actualizado	28 de mayo de 2013

ÍNDICE

1. INTRODUCCIÓN
2. DE SISTEMAS A INFORMACIÓN
3. LA SEGURIDAD, REQUERIMIENTO DEL ISP
4. CUADRO DE MANDOS
5. IMPLANTAR UN SGSI
6. EL HORIZONTE TEMPORAL
7. PRIMEROS PASOS
7.1. Creación de la Dirección de Seguridad
7.2. Dotación de recursos
7.3. Comité de Seguridad
8. ESTRUCTURA DEL SGSI
8.1. Alcance, de menos a más
8.2. Política de Seguridad
8.3. Integración con otros Sistemas de Gestión
9. ANÁLISIS DE RIESGOS
9.1. Análisis de herramientas existentes
9.2. BIA (Business Impact Analysis)
9.3. Inventario de activos
9.4. Herramienta a medida
10. CUADRO DE MANDOS
10.1. Primer paso, indicadores ideales
10.2. Segundo paso, indicadores existentes
11. CONSECUENCIAS DEL ANÁLISIS DE RIESGOS
11.1. Auditorías externas
11.2. Plan de gestión de riesgos
12. CICLO DE VIDA DEL DESARROLLO DE CONTROLES
12.1. Elaborar
12.2. Poner en producción
12.3. Monitorizar
12.4. Corregir
13. PROCESO DE CERTIFICACIÓN
13.1. Selección de la entidad certificadora
13.2. Decisión sobre el alcance
13.3. La auditoría de certificación
14. FACTORES DE ÉXITO
14.1. Apoyo de la dirección
14.2. Empatía
15. DERECHOS DE AUTOR
 

 

1. INTRODUCCIÓN

El motivo por el cual decidir desarrollar un sistema de gestión de la seguridad de la información (SGSI), depende en gran parte del objetivo que se haya marcado la empresa. En el caso de Arsys Internet, el principal reto era integrar todos los procesos de las áreas técnicas bajo un marco único que englobara también la seguridad.

Para los procesos puramente técnicos teníamos bastante claro el modelo que íbamos a seguir. En este caso habíamos escogido el modelo ITIL. Sin embargo, no teníamos del todo claro el modelo a seguir a la hora de integrar los procesos de seguridad, ya que los aspectos relacionados con seguridad que se desarrollan en el marco de ITIL eran insuficientes para nosotros.

La Dirección decidió apostar por integrar la seguridad de la información dentro de un sistema de gestión independiente, pero que estuviera integrado con el resto de procesos de la compañía, adoptando así la ISO 27001.

2. DE SISTEMAS A INFORMACIÓN

Aunque inicialmente la apuesta se centraba en garantizar la seguridad de los sistemas informáticos en general, al adoptar la ISO 27001 como un modelo de desarrollo de la seguridad, tuvimos que cambiar el foco. Pasamos así de un modelo basado en la seguridad de los sistemas informáticos a otro basado en la información.

Para aquellos que no estén familiarizados con el modelo ISO 27001, esta diferencia puede parecer trivial. Nada más lejos de la realidad. Al cambiar el foco hacia la información en sentido amplio, nos vimos obligados a contemplar muchísimos más aspectos relacionados con la seguridad que cuando únicamente nos encargábamos de los sistemas informáticos.

Seguíamos teniendo que controlar las vulnerabilidades, la seguridad perimetral, los intentos de intrusión, etc., pero ahora, además, teníamos que garantizar que el personal iba a ser capaz de manejar la información de la compañía de una forma segura, independientemente del formato o soporte en el que se encontrara. Configurar equipos o instalar productos tiene una dimensión controlable desde un departamento técnico, lograr que todo el personal de la empresa sea consciente de la importancia de la seguridad de la información, y siga unos procedimientos y unas normas para garantizar esta seguridad, es bastante más complejo.

 

3. LA SEGURIDAD, REQUERIMIENTO DEL ISP

Como proveedor de servicios de Internet, necesitábamos disponer de unos niveles de seguridad bastante elevados. No sólo para generar confianza a nuestros clientes, sino para nuestra propia tranquilidad y la de nuestro personal.

 

Cuando analizamos los problemas de seguridad que estábamos teniendo, llegamos a la conclusión de que la mayoría de ellos o, al menos, los más relevantes tenían poco que ver con intrusiones, piratas, virus, etc. Eran mucho más frecuentes los problemas que se derivaban de incidentes relacionados con suministro eléctrico, climatización, averías de hardware, etc.

 

Por tanto, tomaba cada vez más fuerza la idea de que el modelo basado en la ISO 27001 era el más adecuado para reducir nuestros niveles de riesgo y aumentar los niveles de seguridad.

 

4. CUADRO DE MANDOS

El siguiente objetivo era disponer de un cuadro de mandos que permitiera conocer cuál era la situación de la compañía con respecto a la seguridad. Este cuadro de mandos tenía que ser comprensible para la Dirección General, al mismo tiempo que no podía suponer una dedicación de recursos excesiva por parte de las áreas técnicas.

 

La experiencia que se había tenido hasta el momento al desarrollar cuadros de mandos que incluyeran aspectos de seguridad no había sido demasiado positiva. Se había requerido un esfuerzo considerable para actualizar el cuadro de mandos y sus valores, por lo que, al final, sólo se actualizaba dos o tres veces al año.

 

Dentro del modelo de la ISO 27001, se decidió desarrollar un cuadro de mandos que, por una parte, cumpliera con los requerimientos establecidos por la norma de referencia y, por el otro, cumpliera con las necesidades de la compañía. Es decir, mantuviera informada a la dirección sin sobrecargar de trabajo al personal de las direcciones técnicas.

 

5. IMPLANTAR UN SGSI

La Dirección General se planteó en un momento inicial el objetivo de desarrollar un SGSI como una vía de mejorar los niveles de seguridad de la compañía. Se trataba de una necesidad interna que, por sí misma, justificaba el esfuerzo que suponía desarrollar un sistema de estas características.

La decisión de certificar el sistema o no hacerlo no resultaba relevante en el momento inicial, aunque, posteriormente, las áreas de desarrollo del negocio encontraron que podía suponer una ventaja competitiva para la empresa. Ese fue el principal motivo para la certificación.

 

6. EL HORIZONTE TEMPORAL

En mis etapas profesionales anteriores, siempre que una empresa se planteaba desarrollar un SGSI el primer escollo que se planteaba era cuánto tiempo iba a costar desarrollar el sistema. En general se pretendía disponer del mismo en un breve periodo de tiempo, el horizonte de entre nueve meses y un año parecía lo más razonable.

 

Sin embargo, en Arsys Internet decidimos que lo importante era disponer de un buen sistema de seguridad, independientemente del tiempo que eso nos llevara. Así, se estudió un plan para el desarrollo del sistema de gestión en, aproximadamente, un año y medio.

Este horizonte nos permitió desarrollar nuestro sistema de una forma natural, adoptando un modelo de desarrollo evolutivo similar al que se suele adoptar modelos de ciclo de vida de desarrollo. A medida que íbamos desarrollando el sistema, lo íbamos poniendo en producción y verificamos si era viable desarrollar los controles de seguridad tal como estaban planteados, si era razonable el esfuerzo para generar los registros e indicadores, si éstos eran suficientemente claros, y con las conclusiones volvíamos a corregir el sistema mejorándolo.

7. PRIMEROS PASOS

7.1. Creación de la Dirección de Seguridad

El primer paso para el desarrollo del sistema de gestión de seguridad fue constituir una Dirección de Seguridad independiente de otras direcciones técnicas, y que dependiera directamente de la Dirección General.

 

Esta nueva Dirección de Seguridad contaba con el apoyo claro y decidido de la Dirección General, de forma que la decisión de adoptar el SGSI partía directamente de la Dirección General, y la Dirección de Seguridad era simplemente el instrumento a través del cual se formalizaba esta decisión de alto nivel. Y así se transmitió a todo el personal de la compañía.

 

7.2. Dotación de recursos

Una vez constituida la Dirección de Seguridad, la primera necesidad fue obtener recursos humanos necesarios para poder desarrollar las tareas encomendadas. Ahora mismo, encontrar personal con experiencia en el campo de la seguridad de la información resulta una tarea complicada. Sin embargo, el departamento de Recursos Humanos de Arsys Internet localizó un cualificado equipo de profesionales con una amplia experiencia en este terreno.

 

7.3. Comité de Seguridad

Una vez que Arsys Internet contó con la Dirección de Seguridad, la primera decisión que se tomó fue constituir un Comité de Seguridad que representara a todas las áreas de la organización que tuvieran implicación en materia de seguridad de la información.

Necesitábamos transmitir a toda la compañía la importancia que iban a tener los procesos relacionados con la seguridad de la información, dentro de la propia evolución de la empresa. Por otra parte, también teníamos muy claro que no iba a servir de nada desarrollar un modelo de seguridad que no fuera coherente con la cultura de la compañía, con la forma de trabajar de los distintos departamentos y con los objetivos marcados desde las distintas áreas.

Por eso, desarrollamos una estructura para el Comité de Seguridad donde están representadas trece direcciones de la empresa que recogen la mayor parte de las necesidades y los problemas de seguridad. Así, están presentes en el Comité de Seguridad representantes de las direcciones de recursos humanos, jurídico, atención al cliente, marketing, comercial, infraestructuras, comunicación, etc. Esta colaboración nos permite adoptar decisiones y directrices relacionadas con la seguridad de la información que sean realistas.

8. ESTRUCTURA DEL SGSI

8.1. Alcance, de menos a más

En lo que se refiere al alcance, lo que uno considera en primera instancia como más adecuado es que éste cubra todos y cada uno de los procesos de la compañía. Sin embargo, el esfuerzo que requiere desarrollar un SGSI con un alcance tan amplio probablemente no esté justificado.

 

Así, la Dirección General decidió que el alcance del sistema debería englobar todos los procesos de la compañía, aunque inicialmente se aplicara sólo a las áreas técnicas y a las áreas que están involucradas en la gestión del centro de proceso de datos.

Tenemos, por lo tanto, un sistema de gestión que se aplica a todas las áreas y a todos los procesos de la compañía. De forma que, cuando desarrollamos un procedimiento, una política, una instrucción técnica, etc. lo hacemos pensando en que todos nuestros compañeros deben poder aplicarla. Igualmente, planificamos las acciones de formación que llevamos a cabo para transmitir las iniciativas y las medidas que se desarrollan en materia de seguridad teniendo en cuenta que las tienen que aplicar todo el personal.

 

Sin embargo, a la hora de abordar la certificación, podíamos garantizar que el sistema de gestión iba a estar plenamente operativo y en perfecto funcionamiento para los procesos relacionados con la operación del centro de procesos de datos.

 

Aunque la normativa de seguridad aplica a la totalidad del personal y de los procesos de la compañía, entendíamos que este alcance estaba lo suficientemente robusto y maduro como para poder pasar una auditoría de una entidad de certificación acreditada con garantías de éxito.

 

8.2. Política de Seguridad

Todo este modelo cultural quedó plasmado en la política de seguridad. No queríamos una política de seguridad perfecta que todo el mundo se saltara media docena de veces al día. Queríamos la política de seguridad robusta, pero que todos pudiéramos aplicar en el día a día, y que pudiera ser aprobada por todos los miembros del Comité de Seguridad, de manera que fueran ellos mismos los que instaran a los miembros de sus respectivos equipos a cumplirla.

 

Creo que la palabra consenso es más importante a la hora de definir la política de seguridad que cualquier otra. Si los propios directores de la compañía no tienen claro que la política de seguridad es razonable, viable o, en una palabra, útil, no podemos pretender que el personal vaya a aplicarla.

 

La política de seguridad fue desarrollada y aprobada por el Comité de Seguridad y, posteriormente, fue ratificada por el Comité Ejecutivo. De esta forma, incluso los directores generales, cuando se quejan, por ejemplo, de que la política de cambio de contraseñas está provocando muchos dolores de cabeza, siempre podemos decirles que ellos mismos la aprobaron y que se revisará cuando toque la próxima revisión del documento. Llegado el momento, lo más probable que no se plantee modificar esta directriz, tras analizar sus pros y contras cuidadosamente.

 

8.3. Integración con otros Sistemas de Gestión

Otro reto que se planteaba con el desarrollo del sistema de gestión de la seguridad era la integración con el resto de sistemas de gestión existentes en la compañía. Arsys Internet dispone de certificaciones de calidad y de comercio electrónico, aparte de sus certificaciones como registrador de dominios.

 

La Dirección de Seguridad trabajó estrechamente, y con mucho respeto, con las otras direcciones que habían desarrollado los otros sistemas de gestión. Aprovechamos el esfuerzo que ya se había realizado para desarrollar un marco general de sistemas de gestión, y aportamos nuestra experiencia y las ventajas que se incluyen dentro del modelo ISO 27001 para reforzar los sistemas de gestión existentes.

 

De esta forma, tenemos ahora sistemas más maduros y mejor integrados lo que simplifica tremendamente el trabajo de todos, además de relajar muchas tensiones internas.

 

9. ANÁLISIS DE RIESGOS

9.1. Análisis de herramientas existentes

Para realizar nuestro análisis de riesgos estuvimos valorando las herramientas existentes en el mercado. Queríamos que el análisis de riesgos pudiera ser llevado internamente, sin necesidad de dedicar un número de recursos demasiado elevado, al tiempo que pudiéramos mantenerlo actualizado, al menos mes a mes.

En un entorno con más de 180.000 clientes, entendimos que debíamos analizar con mucho cuidado la metodología que íbamos a utilizar para desarrollar nuestro análisis de riesgos.

 

Al final, llegamos a la conclusión de que el esfuerzo que dedicaríamos a desarrollar una metodología que se adaptara a la realidad de nuestra empresa iba a ser mucho menor al que tendríamos que dedicar los siguientes tres o cuatro años a mantener un análisis de riesgos actualizado, siguiendo algunas de las metodologías que ya existían en el mercado. Por lo tanto, acabamos por desarrollar una metodología propia.

 

9.2. BIA (Business Impact Analysis)

El punto de partida de todo el proceso de análisis de riesgos, como no puede ser de otra forma, iba a ser el negocio. De esta forma, íbamos a valorar los distintos sistemas, entornos, aplicaciones, etc. en función de su aportación al negocio de la empresa.

Decidimos analizar primero los procesos de negocio, haciendo un análisis de su repercusión en el negocio de los mismos, para posteriormente determinar cuáles eran los activos que intervenían en cada uno de los procesos. En cierto sentido, hicimos el camino al revés de cómo se suele hacer. En lugar de buscar primero activos para luego ver a quién afecta, buscamos primero qué era importante para la empresa para analizar posteriormente cuáles eran los activos que permitían que los procesos se llevaran a cabo.

9.3. Inventario de activos

Nuestra empresa tiene un crecimiento en los sistemas informáticos muy importante. Si, por ejemplo, decidiéramos hacer un análisis de riesgo cada seis meses, en cada revisión nos encontraríamos con centenares de nuevos servidores que no han estado contemplados dentro de los análisis de riesgos previos.

Por lo tanto, nuestro primer reto, desde la perspectiva del análisis de riesgos, era mantener actualizado el inventario de activos de sistemas informáticos, incorporando la información necesaria para hacer una valoración de los niveles de riesgo de cada uno de ellos.

 

Para esto, adquirimos una herramienta automatizada de análisis y gestión de inventario de equipos y vulnerabilidades que alimentara a nuestra herramienta de análisis de riesgos.

 

9.4. Herramienta a medida

En un principio, comenzamos a trabajar con bases de datos hechas a medida, hojas de cálculo, modelos de informes, scripts de integración, etc. al final, una vez que pudimos verificar que el modelo funcionaba y que era razonable, acabamos desarrollando internamente una herramienta que recogiera todas estas características.

Actualmente, disponemos de un sistema de análisis y gestión de riesgos que se va actualizando de forma semiautomática, proporcionando información sobre el nivel de riesgo de los distintos entornos de la empresa, de forma más o menos continua.

 

10. CUADRO DE MANDOS

10.1. Primer paso, indicadores ideales

A la hora de desarrollar el cuadro de mandos, empezamos por identificar aquellos indicadores que entendíamos que necesitaríamos para conocer cuál era el nivel de seguridad. Nos salió una relación de más de mil indicadores.

 

Era fantástico, porque podríamos saber al detalle cuál era el estado de la seguridad de la información en cada uno de los procesos de la empresa. Sin embargo, se nos había olvidado un pequeño detalle: para mantener el cuadro de mandos actualizado, prácticamente necesitábamos a tres personas con dedicación exclusiva.

Llegamos a la conclusión de que por muy ideales que fueran los más de mil indicadores, no era viable desde un punto de vista operativo.

 

10.2. Segundo paso, indicadores existentes

Una vez vimos que no era viable esta forma de establecer un cuadro de mandos, volvimos a nuestra idea general. Analizamos los indicadores de los que podíamos disponer con un nivel de esfuerzo razonable. Nos alegró mucho ver que con los indicadores que estábamos manejando, podíamos medir el nivel de eficacia de cerca del 60 por ciento de los objetivos de la norma ISO 27000, por lo que únicamente nos quedó completar el 40 por ciento restante.

Desarrollamos así un cuadro de mandos que, partiendo de unos algo más de un centenar de indicadores, nos aporta información sobre la eficacia de todo el sistema de gestión, y que se va agregando por una parte en objetivos y secciones de la norma ISO 27002, y por otra parte en las cuatro listas clásicas de un ‘balanced score card’.

 

11. CONSECUENCIAS DEL ANÁLISIS DE RIESGOS

11.1. Auditorías externas

Del primer análisis de riesgos se derivaron una serie de actuaciones, de las cuales la primera fue realizar un análisis detallado de cuál era la situación de seguridad a nivel de red, sistemas, código fuente e infraestructuras.

 

La información de la que se disponía como punto de partida para realizar el análisis de riesgos no era suficiente. Nos pareció que lo más recomendable era contratar para cada cosa a empresas externas que estuvieran especializadas en ese campo.

Los resultados de estas auditorías externas nos permitieron, por una parte, asignar las valoraciones relacionadas con probabilidad e impacto dentro del análisis de riesgo y, por otra, plantear medidas dentro del marco del plan de gestión de riesgos.

 

11.2. Plan de gestión de riesgos

Se generaron una serie de líneas de actuación orientada a reducir el nivel de riesgo por debajo del umbral que la Dirección General consideró como razonable para las distintas áreas de actividad.

 

Las acciones que se desarrollaron se podrían resumir en las siguientes:

• Mejora de las infraestructuras de suministro eléctrico y climatización.
• Depuración del código fuente.
• Gestión de contraseñas.
• Herramienta automatizada de análisis de inventario y gestión de vulnerabilidades.
• Herramienta de gestión de información de seguridad (SIM/SEM).
• Herramienta de cifrado.
• Planes de continuidad.
• Formación a todo el personal.

 

12. CICLO DE VIDA DEL DESARROLLO DE CONTROLES

12.1. Elaborar

Para el desarrollo de los controles que contempla la norma ISO 27002, decidimos adoptar el propio modelo del ciclo de vida PDCA de la norma ISO 27001.

 

Así, para cada uno de los controles comenzábamos por:

 


 

• Desarrollar una planificación para el mismo.
• Analizar cuáles eran los requerimientos que exigían la norma de referencia.
• Analizar los requerimientos de nuestro propio negocio
• Estudiar cuál había sido hasta ese momento la cultura dentro de la compañía al respecto.
• Las expectativas de nuestros clientes, de nosotros, etc.

 

Con todo esto, desarrollábamos una primera normativa para el control. Esta normativa consistía típicamente en:

 

• Una política.
• Un procedimiento.
• Una o varias instrucciones técnicas.
• Registros e indicadores.

 

12.2. Poner en producción

También desarrollamos una normativa para la puesta en producción de los controles, que se da a conocer previamente a todos los miembros del Comité de Seguridad, para que lo validen y hagan sus aportaciones.

 

 

A continuación, se imparte la formación necesaria para poner en práctica el control al personal que lo requiera, según la naturaleza del control.

 

12.3. Monitorizar

En la siguiente fase, verificamos con revisiones mensuales si el control se está aplicando o no, el esfuerzo y la dedicación que está consumiendo, si disponemos de los registros, indicadores, el impacto que está teniendo sobre los procesos de negocio y el impacto que está teniendo sobre clientes.

 

Con toda esta información ajustamos tanto la política, como procedimiento, instrucciones técnicas, registros e indicadores.

 

12.4. Corregir

Con estos ajustes, corregimos toda la documentación y volvemos otra vez a la fase inicial. Repetimos este ciclo tantas veces como sea necesario, hasta que finalmente contamos con un proceso con el que tanto empresa como clientes se sienten cómodos. O, al menos, son capaces de sobrevivir a ellos.

 

13. PROCESO DE CERTIFICACIÓN

13.1. Selección de la entidad certificadora

Cuando decidimos obtener una certificación para nuestro sistema de gestión de seguridad de la información como es lógico, la primera cuestión era con quien nos certificábamos.

Arsys Internet dispone actualmente de unidades de negocio en Francia y Portugal y prevemos una mayor expansión internacional en los próximos años. En este sentido, optamos por seleccionar una entidad de certificación que estuviera acreditada oficialmente para emitir este tipo de certificados, de manera que pudiéramos alegar en todos los países en los que operamos que disponemos de un SGSI certificado.

 

13.2. Decisión sobre el alcance

Tal y como comentamos anteriormente, aunque el sistema de gestión de seguridad de la información se ha desarrollado para cubrir todos los procesos y todas las áreas de la compañía, entendimos que en el estadio en el que se encuentra actualmente es lo suficientemente robusto y maduro para todos los procesos relacionados con la gestión de nuestro centro de proceso de datos.

Teniendo en cuenta que la mayor parte de los procesos críticos de negocio dependen de este centro de proceso de datos, entendimos que se trataba de un alcance que aporta valor tanto a la empresa como a nuestros clientes en general.

13.3. La auditoría de certificación

La auditoría fue llevada a cabo por Applus+, entidad de certificación acreditada por ENAC, finalizando con la recomendación por parte del equipo auditor de emitir el certificado.  Tras ello, la Comisión de certificación de la entidad decidió otorgar este prestigioso certificado.

 

14. FACTORES DE ÉXITO

14.1. Apoyo de la dirección

Sin ningún género de dudas, el principal factor de éxito para el desarrollo del SGSI de Arsys Internet ha sido el apoyo de la Dirección General.

 

Se trata de un proyecto que ha sido gestado y desarrollado desde esta Dirección General, y la Dirección de Seguridad siempre ha contado con el apoyo y la confianza necesaria para desarrollar sus trabajos.

Tanto la dedicación en recursos humanos como financieros que fueron necesarios para desarrollar la totalidad del sistema de gestión no han sido cuestionados en ningún momento, más allá de una justificación razonable basada en los resultados del análisis de riesgos.

 

14.2. Empatía

La Dirección de Seguridad ha tenido claro, desde el primer momento, que el camino para lograr un SGSI que realmente se utilice por todo el personal de la empresa pasaba por lograr la complicidad y el apoyo de todos los departamentos implicados en la ejecución de los procesos de negocio.

Se ha hecho un esfuerzo muy importante de integración, consiguiendo así que los procesos relacionados con la seguridad estén presentes en el día a día de cada uno de los departamentos.

 

 

15. DERECHOS DE AUTOR

 

Imágenes bajo licencia 123RF internacional.

 

La presente obra y su título están protegidos por el derecho de autor. Las denominadas obras derivadas, es decir, aquellas que son el resultado de la transformación de ésta para generar otras basadas en ella, también se ven afectadas por dicho derecho.

 

Sobre el autor:

 

 

Olof Sandstrom. Actualmente es Director de Seguridad de Arsys Internet y ha sido Information Security Certification Manager en Applus.

 

Es Ingeniero Técnico de Telecomunicación por la Universidad de Las Palmas de Gran Canaria.

 

 

Twittear