Modelos de madurez para SGSI desde un enfoque práctico

Transcripción

1 CAPITULO 9 Modelos de madurez para SGSI desde un enfoque práctico Luís Enrique Sánchez Crespo Daniel Villafranca Alberca Eduardo Fdez-Medina Patón Mario Piattini Velthuis 1. Introducción 2. Modelos de Madurez de la Seguridad en las TIC 3. Métricas y Cuadros de Mando 4. Aplicación de los Modelos de Madurez en la construcción de Cuadros de Mando 5. Conclusiones 6. Bibliografía Agradecimientos

2 1. Introducción El cambio social producido por Internet y la rapidez en el intercambio de información, ha dado lugar a que las empresas empiecen a tomar conciencia del valor que tiene la información para sus organizaciones y se preocupen de proteger sus datos. El nuevo modelo empresarial que comenzó a implantase a principios de siglo, basado en el Gobierno de las Tecnologías y Sistemas de Información (veáse capítulo 1), hace que la información y los procesos que apoyan los sistemas y las redes sean los activos más importantes para cualquier organización. Estos activos están sometidos a riesgos de una gran variedad, que pueden afectar de forma crítica a la empresa. Algunas cifras que nos muestran la magnitud de los problemas ocasionados por falta de unas medidas de seguridad adecuadas aparecen en fuentes tales como el Computer Security Institute (CSI) en colaboración con la Oficina Federal de Investigación (FBI), publican anualmente el informe CCI/FBI Computer crime and security survey status dónde se calculan pérdidas totales en los Estados Unidos que en 2005 como resultado de fallos de seguridad en los ordenadores alcanzaron los $ En el caso de España la situación es mucho más grave, ya que la mayoría de las empresas son incapaces de responder a las preguntas más básicas de seguridad, ya que no existen controles funcionales sobre la información. El único control existente de forma generalizada en las empresas de nuestro entorno son los principios de buena fe y suerte, es decir, ante la incapacidad de controlar la seguridad de la información, prefiero asumir el riesgo. Actualmente, más del 90% de las empresas españolas son incapaces de decir si están sufriendo fugas de información, o cuales son sus principales activos. En este marco, surge el concepto de Seguridad de la Información, que tiene como misión protegerla de las amenazas para asegurar la continuidad del negocio, minimizar los daños y maximizar el retorno de la inversión. Esto se consigue mediante el uso de los Sistemas de Gestión de la Seguridad de la Información (SGSI) que permite la implantación de un conjunto de controles adecuados, como son políticas, prácticas, procedimientos, estructuras organizativas y funciones software. Estos controles necesitan ser verificados para asegurar que los objetivos específicos de la empresa u organización son alcanzados. A pesar de que existen numerosos estándares de seguridad en las TIC (ISO/IEC 17799:2005 (ISO/IEC, 2005), las guías para la gestión de la seguridad (ISO/IEC, 2004b), COBIT 4.0 (COBIT, 2005)), e incluso un modelo de madurez de las capacidades de la ingeniería de seguridad de sistemas (SSE-CMM (SSE-CMM, 2003)), estos textos suelen estar diseñados para grandes corporaciones, son muy rígidos, y su aplicación práctica en pequeñas y medianas empresas requiere mucho tiempo y suele ser muy cara. Estos motivos hacen que muchas empresas ofrezcan resistencia a la incorporación de técnicas de gestión de seguridad adecuadas, asumiendo de este modo unos riesgos de seguridad, y por tanto de pérdida de competitividad que resultan inaceptables en la empresa moderna. Los controles clásicos se muestran por sí solos insuficientes para dar unas mínimas garantías de seguridad; las herramientas de seguridad existentes en el mercado ayudan a solucionar parte de los problemas de seguridad, pero nunca afrontan el problema de una manera global e integrada; por último, la enorme diversidad de estas herramientas y su falta de integración suponen un enorme coste en recursos para poderlas gestionar. 2

3 El mercado demanda actualmente a las empresas que sean capaces de garantizar que las tecnologías para los activos informáticos y de información sean seguras, rápidas y de fácil interacción. Los gerentes de los departamentos de sistemas, se enfrentaron al reto de contestar a las preguntas Son seguros nuestros sistemas, Cuál es nuestro actual nivel de seguridad?, Dónde debemos mejorar nuestra seguridad?. La falta de herramientas que permitan afrontar la gestión de la seguridad de los sistemas de información de una forma centralizada, sencilla y dimensionada al tamaño de las compañías, y la falta de guías de seguridad de la información, que permitan responder a las preguntas de dónde tengo que buscar?, que tengo que controlar? y cómo tengo que controlarlo?. En el caso de las medianas empresas y las pymes, los problemas son aun mayores ya que a todos los problemas anteriores se suma la falta de dimensionamiento del departamento de sistemas de información, cuyos recursos son totalmente insuficientes para abarcar toda la complejidad de los sistemas informáticos. El panorama es complejo y, para una pequeña o mediana empresa, abordar la implantación de un sistema de gestión de seguridad, con la posibilidad de tener varios niveles de exigencia y con unos recursos limitados, se convierte en una tarea muy compleja. Además, el proceso casi siempre termina derivando en que la empresa asuma el riesgo de carecer de un sistema de gestión de la seguridad, ante la incapacidad de implantarlo. En este capítulo trataremos de definir más en detalle los Modelos de Madurez tradicionales basados en los estándares de seguridad anteriormente mencionados. Trataremos la aplicación práctica de estos estándares para dar solución al problema de la evaluación del nivel de seguridad, abordando el uso de métricas para definir indicadores. Estos índicadores son la base en la construcción de cuadros de mando. Finalmente trataremos de dar respuesta al problema que se plantea en las pequeñas y medianas empresas para poder aplicar los estándares de seguridad, mediante el uso de nuestro modelo en espiral y la selección de los indicadores adecuados. 3

4 2. Modelos de Madurez de Seguridad en las TIC Los Modelos de Madurez de Seguridad de las TIC buscan establecer una valoración estandarizada, con la que se pueda determinar el estado de la seguridad de la información en una organización, y que nos permita poder planificar el camino que se tiene que recorrer para alcanzar las metas de seguridad deseadas. Estos niveles de madurez serán progresivos, de tal forma que la seguridad de la información implementada aumente conforme se incrementan los niveles de madurez. Estos niveles son el mecanismo ideal para conocer la seguridad de las compañías que se quieren analizar, y de terceras compañías con las que éstas tengan que interactuar. La visión de cómo afrontar estos niveles de madurez, difiere según los autores que se tomen como referencia. De esta forma algunos autores, insisten en utilizar la en modelos de gestión de seguridad, pero siempre haciéndolo de manera incremental, considerando las necesidades particulares de seguridad, usando para ello los modelos de madurez. Otros modelos como el Information Security Institute of South Africa (ISIZA) plantean también un incremento progresivo de la seguridad. El Nivel 1 de ISIZA consiste en la selección de un nivel básico de un pequeño subconjunto de controles de la ISO7799 relacionados con la política de seguridad, control de virus y seguridad del personal. Siguiendo el modelo propuesto por ISIZA se han conseguido reducciones de tiempo a la hora de certificar a las compañías con la norma BS7799. Otro de los aspectos que se están estudiando para su aplicación a los modelos de madurez es la gestión de los costes asociados a la gestión de la seguridad, ya que estos pueden influir en el dimensionamiento del modelo. De esta forma Rebecca Mercuri propone asociar como parte fundamental del desarrollo de los SGSI los análisis de coste-beneficio (CBA) en la fase del análisis de riesgos; Kim&Choi analiza una metodología orientada a modelos de procesos y criterios de análisis de factores de coste y beneficio que soporten la justificación económica de la inversión en seguridad y que puede ser aplicada a estimar el nivel máximo de madurez que debe afrontar la empresa; y Peltier plantea que los controles deben ser seleccionados en base al coste-efectividad en relación con el riesgo que reducen y las perdidas potenciales que las brechas de seguridad pueden ocasionar. En la Sección 2.1 del capitulo, analizaremos los modelos de madurez de la seguridad de las TIC que mayores perspectivas de futuro tienen. En la Sección 2.2 nos centraremos en el modelo de madurez que se esta desarrollando en SICAMAN Nuevas Tecnologias orientado a la implantación de los SGSI en las PYMES, basado en la :2000, adaptándola para ajustarla al tamaño de la empresa en que se desee implantar y a su nivel de madurez. Este modelo esta siendo desarrollado tomando como base los modelos de madurez existentes en la actualidad, analizando sus principales desventajas y probándolos en nuestros clientes para determinar los factores de éxito y fracaso del modelo Modelos Básicos de Madurez de Seguridad en las TIC Entre los modelos de madurez para seguridad de la información que más se están aplicando en las empresas actualmente, destacan el SSE-CMM, COBIT y el ISM3, aunque actualmente se están desarrollando nuevos modelos de madurez que intentan solucionar los problemas detectados en estos modelos. A continuación se muestra una descripción breve de los principales modelos de madurez existentes en la actualidad y algunas de las propuestas más prometedoras: 4

5 - ISO 21827/SSE-CMM: El Modelo de Capacidad y Madurez en la Ingeniería de Seguridad de Sistemas es un modelo derivado del modelo de madurez del software CMM y orientado hacia la seguridad, que describe las características esenciales de los procesos que deben existir en una organización para asegurar una buena seguridad en los sistemas. En Lobree 2002 se comparan las guías de buenas prácticas más importantes con el modelo de madurez SSE- CMM, llegando a la conclusión de que todas consideran básicamente los mismos aspectos de seguridad, pero con diferente nivel de profundidad. Este es un modelo que pretende servir como: o Herramienta para que las organizaciones evalúen las prácticas de ingeniería de seguridad y definan mejoras a las mismas. o Mecanismo estándar para que los clientes puedan evaluar la capacidad de los proveedores de ingeniería de seguridad. o Base para la organización de un mecanismo de evaluación y certificación. En la siguiente figura se muestran las diferentes areas de proceso de SSE-CMM: Categorias SSE-CCM: Áreas de procesos de la Ingeniería de Seguridad. Procesos de Ingenieria. SSE-PA01 Administrar los controles de seguridad. 4 SSE-PA07 Coordinar la seguridad. 4 SSE-PA08 Supervisar la postura sobre la seguridad del sistema. 7 SSE-PA09 Proporcionar Imput de Seguridad. 6 SSE-PA10 Determinar las necesidades de Seguridad. 8 Procesos de riesgo. SSE-PA02 Determinar el impacto 6 SSE-PA03 Identificar los riesgos de seguridad. 6 SSE-PA04 Identificar las amenazas. 6 SSE-PA05 Identificar las vulnerabilidades. 5 Procesos de aseguramiento. SSE-PA06 Construir la estructura de seguridad. 5 SSE-PA11 Verificar y validar la seguridad. 5 Procesos y proyectos de la Organización. SSE-P&O-PA01 Control de Calidad. 7 SSE-P&O-PA02 Gestionar las configuraciones. 5 SSE-P&O-PA03 Gestionar el riesgo del programa. 6 SSE-P&O-PA04 Esfuerzo técnico de monitorización y control 6 SSE-P&O-PA05 Esfuerzo del plan técnico 10 SSE-P&O-PA06 Definir la seguridad de la organización para la Ingenieria de Procesos. 4 SSE-P&O-PA07 Gestionar el proceso de Ingenieria de la Seguridad en la organización. 4 SSE-P&O-PA08 Gestionar la evolución de la linea de productos de seguridad. 5 SSE-P&O-PA09 Gestionar el entorno de soporte de la Ingenieria de la Seguridad. 7 SSE-P&O-PA10 Proporcionar las habilidades y el conocimiento en curso. 8 Prácticas Genericas N1 N2 N3 N4 N

6 SSE-P&O-PA11 Guias de coordinación. 5 Fig.2.1. Areas de Procesos de SSE-CMM. A diferencia del CMM original, las áreas de proceso no están agrupadas en función de los niveles de madurez, sino que define 22 áreas para cada una de las cuales se puede alcanzar un nivel en función del cumplimiento de unas "características comunes". Existen 11 áreas de procesos de ingeniería y otras 11 dedicadas a la gestión de proyectos y organización. Cada área tiene asociadas un conjunto de prácticas que deben cumplirse según el nivel de madurez. El número de prácticas es común para todas las áreas de un nivel, excepto en el nivel base (ver Figura 2.1). - ISM3: Está orientado a definir diferentes niveles de seguridad, donde cada uno de ellos puede ser el objetivo final de una organización. En otras palabras, no es un modelo que se pueda utilizar para mejorar, sino que sirve para clasificar el nivel de seguridad que requiere una empresa. ISM3 define cinco niveles de madurez de la seguridad de una empresa [0 a 4]: o Nivel ISM3 0: Si bien este nivel puede producir ganancias a corto plazo, es improbable que resulte en una reducción significativa del riesgo de amenazas técnicas e internas de medio a largo plazo sin inversiones impredecibles. o Nivel ISM3 1: Este nivel debería resultar en una reducción significativa del riesgo de amenazas técnicas, con una inversión mínima en procesos ISM esenciales. Se recomienda este nivel para organizaciones con Metas de Seguridad bajas en ambientes de riesgo bajo. o Nivel ISM3 2: Este nivel debería resultar en una mayor reducción del riesgo por amenazas técnicas, con una inversión moderada en procesos ISM. Se recomienda este nivel para organizaciones con Metas de Seguridad normales en ambientes de riesgo normal. o Nivel ISM3 3: Este nivel debería resultar en una reducción del riesgo alta por amenazas técnicas, con una inversión seria en procesos ISM. Se recomienda este nivel para organizaciones con Metas de Seguridad altas en ambientes de riesgo normal o alto. o Nivel ISM3 4: Este nivel debería resultar en la mayor reducción de amenazas, tanto técnicas como internas, por una inversión seria en procesos ISM. Se recomienda este nivel para organizaciones afectadas por requerimientos específicos (como suministradoras de energía y agua, instituciones financieras y organizaciones que comparten o almacenan información sensible) con Metas de Seguridad muy altas en ambientes de riesgo normal o alto. Proceso ISM3 0 ISM3 1 ISM3 2 ISM3 3 ISM3 4 GP-1 X X X X SSP-1,2,3,6 X X X X SSP-4,5 TSP-1,2,3,12 X X X X TSP-5,6,10,11 X X X TSP-4,9 X X TSP-7,8 OSP-1,5,10,16,17 X X X X OSP-2,4,6,7,9,11,12,14,19,22 X X X X X 6

7 OSP-3,8,13,15,20,24 X X OSP-18,21,23,25 X Tabla 2.1. Aplicación de los procesos de ISM3 a sus niveles de madurez. Estos niveles irán asociados a procesos de tal forma que, dependiendo del nivel de madurez, la empresa estará obligada a cumplir con una serie de procesos. De esta forma un nivel 0 implicará no cumplir con ningún proceso. En la Tabla 2.1 podemos ver los procesos de aplicación de los niveles ISM3 sobre procesos. - COBIT: El modelo de madurez de COBIT ofrece las bases para el entendimiento y la evaluación de las condiciones actuales de seguridad y control de los procesos del ambiente de TI de una organización. Este modelo provee las bases para la evaluación de las principales funciones del área de TI, a través de la consideración de cada uno de sus procesos clave, a los cuales se les asignará un valor entre [0-5], indicando así el nivel de esfuerzo ( madurez ) que se sugiere invertir en la actividad de control de dicho proceso, de forma que garantiza una buena relación coste beneficio al asegurar el nivel de seguridad estrictamente requerido. El modelo de madurez de COBIT está basado en el modelo de madurez de desarrollo de software CMM, lo que hace que éste no sea un modelo actualizado, ya que hoy en día lo que se está manejando es el modelo CMMI. Von Solms ha investigado la coexistencia y uso complementario de COBIT y la ISO desarrollando un mapa para la sincronización de ambos marcos de referencia y analizando las razones por las que ambos son complementarios. Algunos de los detractores de la presentan como desventaja que es una guía de soporte, pero que no alcanza todo el marco necesario para el gobierno de las tecnologías de la información. Su principal ventaja frente a COBIT es que es más detallada y tiene más guías orientadas a como deben hacerse las cosas. Un reciente informe del IT Governance Institute soluciona el problema de sincronización desarrollando el mapa entre COBIT s DCO s e ISO/IEC17799:2000. Existen multitud de escenarios en que se pueden ver como se complementan y COBIT. - CC_SSE-CCM: El Common Criteria (CC) provee sólo de estándares para evaluar la información de productos o sistemas de seguridad. Por otra parte SSE-CMM provee de estándares de seguridad para la evaluación de la ingeniería de procesos. Jongsook Lee propone integrar CC y SSE-CMM para crear CC-SSE-CMM, que es un modelo de madurez con las ventajas de ambos modelos. Este nuevo modelo se divide en procesos, productos y ambiente, y cuenta con 2 ventajas principales: o Primero, cuando una organización que fue desarrollada con el CC desea ser evaluada con SSE-CMM para mejorar su nivel con respecto al proceso de seguridad, este modelo puede ser utilizado con eficacia. o En segundo lugar, cuando una organización basada en SSE-CMM desea ser evaluada con el CC, este modelo puede también ser aplicado con eficacia. ISO/IEC clasifica los métodos existentes dependiendo del acercamiento del aseguramiento y de la fase del aseguramiento. La evaluación del aseguramiento se divide en proceso, producto, y ambiente, mientras que las fases del análisis del riesgo son diseño/implementación, integración/verificación, réplica, transición, y operación. Las fases del análisis del riesgo para CC son diseño/implementación, integración/verificación, transición, y operación. Para que exista un método de securación en común, se deben adaptar las fases del ISO/IEC con las del CC. 7

8 CC_SSE-CMM consiste en 23 áreas de procesos con 5 niveles de madurez. Cada área de proceso (PA) tiene BP (prácticas base) y los niveles de capacidad tienen GP (prácticas genéricas). En la Tabla 2.2 se puede ver como se asocian los dos modelos de seguridad. CC Clase Familia SSE-CMM Área de proceso Practica genérica Practica base Tabla 2.2. Relación entre el CC y SSE-CMM En la Tabla 2.3, podemos ver como los proceso del CC coinciden casí al 100% con el modelo SSE-CMM pero difieren en el resto de modelos comparados, lo que hace mucho más difícil su adaptación. Leyenda: 0 Coinciden 100% 1 Coinciden algo. 2 No coinciden. CMMI SSE- CMM SPIC E ISO/IEC ISO/IEC Gestión de la configuración Distribución y operación Desarrollo Guías de documentación Ayuda para determinar el alcance Test Riesgo, vulnerabilidad Tabla 2.3: Compatibilidad entre CC y otros métodos de seguridad. - Eloff y Eloff: Se decanta por definir cuatro clases distintas de protección, que permiten ir incrementando de forma progresiva los niveles de seguridad, basándose para ello en las secciones de la norma. o Clase 1: Protección inadecuada. No cubre ninguna sección de la. o Clase 2: Protección mínima. Cubre aspectos legales y de continuidad del negocio. o Clase 3: Protección razonable. A los anteriores se le suman aspectos organizativos, control de activos y gestión de accesos. o Clase 4: Protección adecuada: Cubre todas las secciones de la. Una representación del modelo que propone lo podemos ver en la Fig.2.2. En gris, vemos las secciones de la norma que no se cumplen para ese nivel de protección. Nombre de sección Política de Seguridad Organización de la Seguridad Clasificación y Control de activos Política de personal Seguridad física Clase 1: Protección inadecuada Clases de protección Clase 2: Protección mínima Clase 3: Protección razonable Clase 4: Protección adecuada 8

9 Comunicaciones y operaciones Control de acceso Desarrollo y mantenimiento de sistemas de información Continuidad del negocio Satisfacción del marco legal y contractual Fig Ejemplo de asociación entre las secciones de la y las clases de protección. - Karen & Barrientes: Esta propuesta de Modelo de Madurez consiste en llevar a cabo un análisis relativo a la seguridad informática para identificar el grado de vulnerabilidad y determinar los aspectos de mejora a ser llevados a cabo en la organización con el objeto de reducir el riesgo. Este modelo apoya la evaluación de la seguridad de la información de una organización, y permite determinar en qué nivel se encuentra la misma con respecto a la seguridad, y así poder establecer cuáles son sus fortalezas y debilidades a la hora de proteger su información. El modelo propuesto cuenta con los 5 niveles planteados por el CMMI, con su debida adaptación para que esté acorde con la seguridad de la información. Cada nivel cuenta con una definición y con una descripción general en la cual se indica el comportamiento que tiene una organización con respecto a la seguridad de la información. Dicho comportamiento determina el nivel de madurez en el que se encuentra la seguridad de la información. Las prácticas de cada nivel corresponden a los controles que están definidos en el estándar internacional ISO/IEC Este modelo tiene en cuenta que las organizaciones tienen estructuras internas diferentes, por lo cual se considera que los controles definidos en cada nivel son los mínimos o más generales que deberían establecer las organizaciones, cualquiera que fuera su estructura interna. El problema principal de todos los modelos de madurez presentados es que no están teniendo éxito a la hora de implantarse en PYMES, debido principalmente a que fueron desarrollados pensando en organizaciones grandes y en las estructuras organizativas asociadas a éstas SSE-PYME: Modelo de Madurez de la Seguridad Orientado a PYMES El Modelo de Madurez para la Seguridad de la Información que hemos propuesto en los congresos de CIBSI 05, ARES 06 y RECSI 06 entre otros y que está en constante evolución, permite a cualquier organización evaluar el estado de su seguridad, pero está orientado principalmente a las PYMES, ya que son las que mayor tasa de fracaso en la implantación de los SGSI están teniendo y con las que menos éxito están teniendo los modelos de madurez existentes. Además, las PYMES representan más del 95% de las empresas españolas, lo que supone que hasta que no se consiga un adecuado nivel de seguridad en ese tipo de empresas, el tejido empresarial español no podrá considerarse maduro desde el punto de vista tecnológico. Para nuestro modelo de madurez se ha utilizado el estándar como punto de partida, coincidiendo con las investigaciones que la universidad de Pittsburgh está emprendiendo para el desarrollo y la puesta en práctica de un estándar comprensivo de la seguridad basado en las guías proporcionadas por la ISO/IEC Otros estudios consideran importante la norma, pero la complementan de alguna forma con otros aspectos, como es el caso de Endorf, que incorpora los requisitos de la HIPAA norteamericana a un programa de seguridad complementando la ISO/IEC 17799; 9

10 Von Solms, que considera una aplicación conjunta y complementaria de los COBIT y la norma; o incluso Masacci, que además de la norma considera controles relativos al cumplimiento de la legislación italiana en materia de protección de datos y privacidad. Las características más destacadas de nuestro modelo son que tiene tres niveles de seguridad [1 a 3] en lugar de los 5-6 niveles que proponen los modelos clásicos; y que se propone que cada nivel sea certificable, en lugar de la certificación total existente hasta el momento. Esta certificación será revisada periódicamente y la compañía podrá subir o bajar su nivel de madurez. Nuestro modelo coincide con las apreciaciones de Eloff y Eloff, el cual sugiere ir realizando una implantación progresiva de controles que permita que la empresa pueda irse adaptando a la evolución de la seguridad de una forma no traumática. Por último, se asocia el nivel de madurez a las características de la empresa, no siendo obligatorio (ni aconsejable en algunos casos), que todas las compañías lleguen al nivel 3. De esta forma y a partir de la información obtenida mediante la implantación en clientes de nuesta empresa SICAMAN Nuevas Tecnologias, se ha desarrollado un modelo de madurez siguiendo la estructura en espiral que podemos ver en la Fig.2.3. Este modelo persigue facilitar la realización de ciclos rápidos y económicos que permitan crear una cultura de seguridad en la organización, de forma constante y progresiva. Nuestro modelo propone realizar inicialmente una estimación del nivel de madurez de la empresa, de tal forma que con un bajo coste, y en poco tiempo, se pueda determina un plan de proyecto que presentar a la dirección de la empresa. Otra de las características del modelo que proponemos es que busca que los planes propuestos sean a corto plazo, en lugar de los planes derivados de los modelos actuales que tienen una duración elevada, lo cual hace que sean totalmente inadecuados para la estructura cambiante presente en las PYMES. Mediante este modelo, podemos estimar en un plazo mínimo de tiempo el nivel de madurez del SGSI de la empresa e identificar el conjunto de normas que más se adapta a ella, trazando hitos realistas a corto plazo de la evolución esperada en la empresa para cada ciclo de la espiral. Una vez que hayamos identificado el nivel de madurez actual de la empresa, se elaborará un plan de mejora que será presentado a la dirección, y cuyo principal objetivo será complementar el nivel de madurez actual para llegar al siguiente nivel de madurez. 10

11 Fig.2.3. Modelo en espiral para madurez de los SGSI. Aunque en la Fig.2.3 el modelo de madurez presenta solo ocho secciones de la norma, el modelo de madurez final se está desarrollando sobre las diez secciones presentes en esta norma. Actualmente se están analizando las posibilidades de migrar los resultados obtenidos mediante el método investigación-en-acción a la nueva versión de la norma :2005. Además, aun cuando el núcleo principal del modelo que hemos desarrollado está basado en la ISO/IEC 17799, no hemos renunciado a complementarlo con otro tipo de estándares y recomendaciones en materia de seguridad y de gestión de seguridad, que puedan solucionar carencias detectadas en la. Nuestro modelo define tres niveles de madurez para valorar el estado de la seguridad del sistema de información de la empresa. De esta forma, una empresa que según los parámetros de empleados y facturación se considere pequeña sólo debería aplicar el nivel de madurez -1, que es un subconjunto de los controles recomendados por la (Tabla 2.4). Cualquiera de las otras dos versiones de la norma supondría sobredimensionar la seguridad de la empresa. Esto conllevaría un aumento del nivel de riesgo de que los controles implantados no sean sostenibles y produciría una degradación continua de los controles y del nivel de madurez. Otro factor a tener en cuenta, es que aún cuando las diferentes secciones podrían avanzar de forma independiente, lo lógico es que planifiquemos mejorar aquellos aspectos que necesitan una menor seguridad. Como primer paso para poner en marcha nuestro modelo en una compañía, determinaremos qué nivel de normas deberemos aplicar en base a las características de la empresa. Una vez identificado el nivel apropiado realizaremos un análisis de controles para determinar el plan que nos permita complementar ese nivel de madurez. En nuestro modelo, el nivel de seguridad de la compañía evolucionará en un rango del 0-100% para cada uno de los tres niveles de madurez propuestos. A su vez cada nivel de madurez ha sido dividido en seis subniveles para ayudar a la dirección en el seguimiento del proyecto. Nivel de madurez (Según pre-auditoria realizada sobre la norma ) Valoración Nivel de madurez Tipo de Empresa (según nº de empleados y facturación) Pequeña Mediana Grande 0 25 Empleados Empleados >250 Empleados 0 1 Millones Millones >100 Millones 0 100% Bajo -1 (100) -1 (100) -1 (100) 100% - 200% Medio -1 (100) -2 (300) -2 (300) % Alto -1 (100) -2 (300) -3 (500) Tabla 2.4. Modelos propuestos según el tipo de empresa y su nivel de madurez Caracteristicas de SSE-PYME Una de las principales caracteristicas de nuestro Modelo de Madurez es la versatilidad del mismo, ya que se define como un sistema dinamico y adaptable a las caracteristicas especificas de las empresas, de tal forma que podamos crear un conjunto de normativas que cumplen un conjunto de aspectos básicos y comunes a todos los tipos de compañias, así como un conjunto de aspectos específicos definidos por el tipo de compañía (sector, facturación, nº de personas, etc). 11

12 Otra de las caracteristicas que define nuestro modelo (ver Figura 2.5), es que tiene una estructura interna formada por procesos o dominios con una parte específica que puede variar según el sector o el perfil de la compañía y una parte general que es común para todas las compañias. Modelo de Madurez Nivel de Madurez Nivel1 Nivel de Madurez Nivel2 Nivel de Madurez Nivel3 Proceso1 ProcesoN Metas Especificas Metas Generales Prácticas Especificas Prácticas Generales Fig.2.5. Estructura Interna de los Niveles de Madurez del Modelo SSE-PYME A su vez, cada nivel de madurez de los definidos en nuestros modelos tendrás asociada la siguiente estructura física de documentos que deberá seguir. Nivel de Madurez Dominio1 DominioN Normativas Procesos Controles Metricas Plantillas Registros Instrucciones Técnicas Fig.2.6. Documentos que componen un nivel del modelo de madurez. 12

13 En la Figura 2.6 podemos ver las diferentes partes de que se compone cada Dominio de nuestra propuesta: - Normativas: es el conjunto de reglas que todo empleado de la compañía deberá cumplir dentro del marco legal en el que se encuentre su actividad. - Procesos: ciclo que la compañía debe cumplir para salvaguardar el sistema y obtener el nivel adecuado y deseado de seguridad para los diferentes controles. Los procesos tendrán un ciclo formado por plantillas y registros, que estarán asociados a controles y normativas. Las instrucciones técnicas serán documentos técnicos de apoyo para poder realizar el proceso de forma adecuada. Y mediante las metricas podremos medir el cumplimiento y calidad del proceso. - Controles: se establecerán para salvaguardar los activos y garantizar el cumplimiento de las normativas. - Metricas: nos permitirán medir la evolución del sistema, alimentando el cuadro de mandos de seguridad de la compañía y permitiendo tomar decisiones para mejorar los esquemas del SGSI. - Plantillas: nos indican documentos o formularios que tenemos que rellenar para cumplir con los estandares de calidad. - Registros: representan registros de datos necesarios para el sistema de seguridad. - Instrucciones técnicas: son documentos técnicos de apoyo para el cumplimiento de sistemas de seguridad especificos. Todos los objetos (normativas, procesos, controles, metricas, plantillas, registros e instrucciones técnicas), de cada nivel del modelo de madurez estan interrelacionados entre ellos (Ver Figura 2.7), existiendo matrices que asocian unos con otros y que permiten determinar las dependencias de los mismos de cara a la valoración de las metricas. Controles Metricas Instrucciones Técnicas Procesos Normativas Plantillas Registros Fig.2.7. Relación entre las diferentes partes que forma un nivel. De esta forma las metricas se verán afectadas por el cumplimiento de los procesos, plantillas y registros, y el cumplimiento de éstos determinará el nivel de los controles y procesos. 13

14 Así mismo, muchas normativas están asociadas al cumplimiento de las plantillas y registros. El no cumplir con una de ella implicaría la violación de una normativa por parte de un usuario. Las normativas están directamente asociadas al proceso de sanción de la compañía. Uno de los principales objetivos perseguidos con este esquema es realizar un SGSI automatizable que permita a las compañías mantener su sistema de seguridad con el minimo esfuerzo. Por último, otra de las principales característica de nuestro modelo es la definición de sus niveles de madurez. Dentro de los diferentes ciclos definidos para el modelo, existen dominios que tienen más peso que otros en ese nivel. Estos niveles han sido elaborados en base a la experiencia práctica y basandonos en los modelos de SSE-CMM y las investigaciones de los modelos Eloff&Eloff. De esta forma, nuestro modelo propone la siguiente división: - Nivel1 o de Protección mínima: Centraría el peso de la evolución de la empresa en: o Politica de Seguridad. o Continuidad del negocio. o Satisfacción del marco legal y contractual. - Nivel2 o de Protección razonable: Centraría el peso de la evolución de la empresa en: o Organización de la seguridad. o Clasificación y control de activos. o Control de acceso. - Nivel3 o de Protección adecuada: Centraría el peso de la evolución de la empresa en: o Politica del personal. o Seguridad fisica. o Comunicaciones y operaciones. o Desarrollo y mantenimiento de sistemas de información. El resto de dominios evolucionarán támbien en todos los niveles, pero esos serán los más importantes para cada nivel. De esta forma, centramos los pilares de seguridad de la compañía en crear un gobierno de la seguridad y una conciencia en el Nivel1, avanzando en el resto de niveles en aspectos básicos; en el Nivel2 nos centramos en la evolución de la organización de la seguridad y el asentamiento de las politicas; y por último, en el Nivel3 nos centramos en aspectos físicos. Hasta el momento actual, las empresas han centrado su evolución en un modelo inverso al que nosotros proponemos, centrando sus esfuerzos en el Nivel3 antes de evolucionar en el Nivel1 y Nivel2. Nuestra experiencia nos ha demostrado que esta ha sido una de las principales causas del fracaso de las implantaciones de sistemas de seguridad: la falta de unos pilares sobre los que sustentarlos. En la Tabla 2.5 podemos ver un cuadro resumen de cómo se podría repartir el esfuerzo necesario de implantación de los diferentes dominios por niveles: - Nombre de sección Clases de protección Nivel1 Nivel2 Nivel3 Protección Protección Protección mínima razonable adecuada Política de Seguridad Organización de la Seguridad

15 Clasificación y Control de activos Política de personal Seguridad física Comunicaciones y operaciones Control de acceso Desarrollo y mantenimiento de sistemas de información Continuidad del negocio Satisfacción del marco legal y contractual Tabla 2.5. Ejemplo de asociación entre las secciones de la y las clases de protección. De esta forma, en el Nivel1 dedicaríamos un 20% del esfuerzo total a crear una politica de seguridad solida, aunque avanzaríamos en crear unas bases minimas en política de personal. Se puede ver claramente cómo el mayor esfuerzo inicial se dedica a crear y mantener los controles asociados a los aspectos lógicos de la normativa de seguridad, de forma que sirvan de base a los aspectos físicos en posteriores niveles. Por otra parte, en nuestro modelo consideramos que los aspectos relativos a los dominios de Seguridad Fisica y Desarrollo y mantenimiento de sistemas de información deberían basarse en un outsourcing puro mientras no se llegue al Nivel3, ya que los costes necesarios para la infraestructura de mantenimiento y su securización no son soportables por empresas que esten en el Nivel1 o el Nivel2. Uno de los aspectos que se pretende abordar con la aplicación que se esta desarrollando es eliminar la necesidad de utilizar documentos, permitiendo la automatización de todos los procesos necesarios en cada nivel. Otros modelos en los que actualmente estamos trabajando incluyen nuevos factores que pueden afectar a la hora de decidir sobre el nivel de cumplimiento que se debe aplicar: el tipo de actividad de la empresa, la dependencia de departamentos (como el de I+D), etc. En resumen, las principales caracteristicas de nuestro modelo frente a otros modelos se pueden resumir como: - Nuestro modelo de madurez propone 3 Niveles de madurez frente a los 5 Niveles de los modelos clasicos. - Outsourcing como mecanismo de ejecución rápida y ahorro de costes en el Nivel 1 y 2. - Orientación coste-beneficio. - Se centra más en un ánalisis de la madurez de la empresa que en el análisis de riesgos. - Software parametrizable de nivel de madurez basado en la evolución progresiva del nivel en la empresa. Y los principales objetivos perseguidos son: - Reducción de los costes (economicos y temporales) de implantación y mantenimiento. - Mejora del porcentaje de éxito de las implantaciones Lecciones aprendidas Algunas de las principales y más valiosas conclusiones obtenidas de la realimentación de los clientes de SICAMAN Nuevas Tecnologias en los que se han analizado varios modelos son las siguientes: 15

16 - Si sobredimensionamos el nivel de seguridad de una empresa con respecto a su tamaño, se produce una degradación de los controles que hemos sobredimensionado, hasta que éstos alcanzan su punto de equilibrio natural. La consecuencia directa es que la empresa no alcanza los objetivos deseados, y ademas incurre en un gasto del que no obtendra un retorno de la inversión. En la Figura 2.8 podemos ver una simulación de cómo existe una tendencia natural de los sistemas de seguridad a encontrar su equilibrio, y esa tendencia está directamente ligada a varios factores (tamaño, sector, etc). Es decir, el sobre-dimensionamiento de las medidas de seguridad aplicadas se convierte en una pérdida econémica para la empresa, ya que su propia estructura empresarial termina rechazando ese sobre-esfuerzo en seguridad. En la Figura 2.8, el porcentaje de 0-100% (también se puede denominar 0-100% Nivel1) representa el nivel de madurez 1; el porcentaje % representa el nivel de madurez 2 (también se puede denominar 0-100% Nivel2); y el porcentaje de % (también se puede denominar 0-100% Nivel3) representa el nivel de madurez 3. Existen excepciones en algunos sectores y tipos de empresas en las que no se cumple esta tendencia, por lo que se están realizando mejoras en el modelo añadiendo variables al mismo. Simulación de tendencias de niveles de madurez sobredimensionados en las empresas 300 Nivel de madurez Años Pequeña Mediana Grande Fig.2.8. Simulación de tendencia de niveles de madurez sobredimensionados. - Las empresas se muestran más receptivas ante planes de implantación de corto plazo (1 a 2 años) que ante planes a largo plazo (4 a 6 años). La certificación por niveles ofrece una garantía para la valoración de la evolución del proyecto a corto plazo. Por estas razones, ya que la mayoría de nuestros clientes son PYMES, nuestra propuesta ha sido muy bien recibida y su aplicación está resultando muy positiva ya que permite acceder a este tipo de empresas al uso de modelos de madurez de la seguridad, algo que hasta ahora había estado reservado a grandes compañias. Además, con este modelo se permite obtener resultados a corto plazo y reducir los costes que supone el uso de otros modelos, consiguiendo un mayor grado de satisfacción en el cliente. 16

17 3. Métricas y Cuadros de Mando Parte de los problemas de las empresas se han empezado a solucionar gracias a la entrada de métricas y normas de seguridad que han aportado parte de las piezas necesarias para que los departamentos de sistemas puedan retomar el control de la seguridad de sus sistemas. La necesidad de gestionar la seguridad de los sistemas de información obliga a la utilización de métricas e indicadores que permitan evaluar la situación real. Las métricas de seguridad son necesarias para saber el estado de un sistema de información. Las métricas son la clave para interpretar los problemas que pueden ocurrir y actuar en consecuencia. Si una organización no usa métricas de seguridad para la toma de decisiones, las elecciones serán motivadas por aspectos púramente subjetivos, presiones externas o por motivaciones puramente comerciales. 3.1 Las Métricas de Seguridad de la Información en un SGSI La primera pregunta que nos surge al implementar un Sistema de Gestión de la Seguridad de la Información (SGSI) en una organización, es cómo podemos determinar que es seguro. La medida de la calidad de un programa de seguridad puede realmente ser testeado solo cuando la organización es sometida a un estado crítico. Las métricas referidas a la seguridad es la medida de la efectividad del esfuerzo en la seguridad que una organización realiza sobre el factor temporal. Los procesos de métrica deben tener en cuenta la naturaleza del negocio y organización, lo cual genera un problema específico para cada tipo de negocio y los niveles de seguridad que se desean alcanzar. Estos problemas están relacionados con la validación teórica y empírica de las métricas, siendo los más relevantes: Las métricas no están siempre definidas en un contexto en el que el objetivo de interés industrial que se pretende alcanzar mediante su utilización es explícito y quede bien definido. En ocasiones, aunque el objetivo sea explícito, las hipótesis experimentales a menudo no están hechas de forma explícita. Las definiciones de métricas no siempre tienen en cuenta el entorno o el contexto en el cual serán aplicadas, por ejemplo. A menudo, no es posible realizar una adecuada validación teórica de las métricas porque el atributo que una métrica pretende cuantificar no está bien definido. Un gran número de métricas no han sido nunca objeto de validación empírica. Esta situación ha conducido frecuentemente a cierto grado de ambigüedad e imprecisión en las definición, propiedades y suposiciones de las métricas, haciendo que su uso sea difícil, la interpretación peligrosa y la obtención resultados contradictorios en varios estudios de validación. En cuanto las organizaciones empiezan a tomar conciencia de la necesidad de la seguridad en la información, nacen los primeros estándares. A nivel internacional tenemos la norma ISO/IEC 15408, en EEUU surge el libro naranja de TCSEC y en Europa los criterios ITSEC y metodología ITSEM. Las principales críticas que podemos hacer de ellos son la falta de flexibilidad y costes altos en su implantación. Dentro de las metas de estas guías, el COBIT provee unos objetivos de Control para el uso diario en la gestión propia de usuarios y auditores. Por su parte el estándar ISO/IEC 17799:2000 tiene un enfoque más orientado a la implantación de la seguridad de la información y que tiene a los responsables de seguridad de la información como objetivo del mismo. El resto de las guías que se pueden 17

18 comparar a estas dos (ITIL, ISO/IEC 15408, COSO,..) o bien tienen unas metas o bien un enfoque hacia audiencias que se salen de la aplicación práctica del enfoque inicial del presente documento. En la Fig. 3.1 observamos el nivel de detalle de cada uno de los estándares en términos técnicos y complejidad de su operativa (eje vertical) en contraste con la completitud de las guías (eje horizontal). Fig Comparación del Nivel de detalle de los estándares (Fuente: Information Systems Control Journal) En el año 2005 se produjeron varios hechos claves en lo que respecta a los principales estándares: Por un lado se ha realizado la revisión de COBIT en la nueva versión 4.0. La nueva guía ha sido revisada y actualizada incrementando los objetivos de control. Los dominios han sido modificados y adaptados a la nueva problemática surgida desde la v.3.0. Por otra parte, la revisión de la metodología española MAGERIT también la aproxima a los estándares internacionales. Finalmente, en la nueva versión de la ISO 17799:2005, además del cambio sufrido en lo que respecta al nivel de Objetivos de Control, se destata la inclusión de dos conceptos puntuales que han sido elementos claves: - Que la política de seguridad de la información tiene que estar alineada con los requerimientos del negocio (IT Governance) y con las leyes y regulaciones relevantes. - Que a los usuarios hay que darles formación, y concienciarles continuamente en esta materia, lo que les permitirá realizar las acciones necesarias para conseguir una óptima protección En el nuevo panorama que se avecina en relación a los sistemas de información, que las tradicionales tres patas de la seguridad (confidencialidad, integridad y disponibilidad) ahora se ven ampliadas a siete: Disponibilidad. Integridad de los datos. Confidencialidad de los datos. Autenticidad de los usuarios del servicio. 18

19 Autenticidad del origen de los datos. Trazabilidad del servicio. Trazabilidad de los datos. 3.2 Clasificación de las Métricas de seguridad de la información Con un enfoque más práctico en la evaluación y selección de estos indicadores encontramos en NIST una serie de parámetros que van a definir la métrica, tales como el tipo de control, propósito de medida, valores, etc., que nos han servido de referencia en la construcción de nuestro modelo. Según Mañas se propone que para la gestión segura de los sistemas de información se requiere de cuatro métricas clasificadas en: Metricas de gestión Métricas técnicas Métricas del entorno físico Métricas del personal Por otro lado, Villarrubia propone una aproximación para clasificar las métricas en base a las diferentes necesidades que puede tener una organización 1. Objetivos de Seguridad (SO) de la información que son los que se persiguen. 2. Áreas de Control (CA) de cara a cumplir los objetivos de seguridad. 3. Dimensión Temporal (TD), las métricas pueden ser aplicadas en diferentes instantes. 4. Audiencia Prevista (IA), según la cual la métrica informará de los diferentes aspectos de la seguridad. Otros autores como Vaughn clasifican las métricas para el aseguramiento de la información en cuatro categorías, en base a lo que se quiere medir: Metricas de Desarrollo, Metricas de soporte, Metricas de operaciones y Métricas de efectividad, incluyendo subcategorías dentro de cada una de ellas. De cara a unificar esta situación, encontramos que la norma ISO/IEC 17799:2005 nos relaciona los controles a aplicar según las áreas y políticas de seguridad que se establecen en la organización. De esta forma podemos adaptar los niveles de madurez y nuestras métricas en función de parámetros particulares de la empresa u organismo en cuestión. 3.3 Aplicación de las Métricas de seguridad para el desarrollo de Cuadro de Mandos La gestión del riesgo y aseguramiento de la información son dependientes de prácticas específicas de gestión, en la búsqueda continua de información para la toma de decisiones. En este contexto se han desarrollado herramientas de gestión para responder a estas preguntas: Cómo los gerentes manejan el negocio? Cómo conseguir resultados que sean lo más satisfactorios? Cómo se adapta la organización a las tendencias del entorno? Las respuestas a estas preguntas se resuelven en un Cuadro de Mando, un Cuadro de Mando Integral y el Benchmarking. Para resolver estos probemas, Opacki propone dos metodologías para la construcción de una herramienta de monitorización de Cuadro de Mando (scorecard), que son top-down y bottom-up. La metodología top-down, es más formal y permite a los stakeholders definir las necesidades y objetivos 19

20 de la organización. Por el contrario, se recomienda la metodología bottom-up en organizaciones que debido a la falta de madurez del programa de seguridad, necesiten el desarrollo rápido de una herramienta de monitorización (scorecard). Mientras tanto, otros autores definen cuatro niveles de seguridad para una compañía: organización, flujo de procesos, información e infraestructura, diseñando un esquema de seguridad desde la capa superior hacia abajo en la que se implementan los aspectos prácticos. Por otro lado COBIT enlaza los requisitos del negocio de información de la dirección a los objetivos de las TI. Se propone una estructura y una serie de indicadores para medir la tecnología de la información, basados en Indicadores Clave del Rendimiento (KPI), Indicadores clave de logros (KGI) y los Factores críticos del éxito (FCE). Ante la cuestión sobre lo que se debe medir, hay que establecer marcadores e indicadores clave de rendimiento (KPI) para las diferentes áreas funcionales de la seguridad. Para cada una de estas áreas, tendrá que crear los KPI y obviamente las correspondientes mediciones clave de rendimiento (KPM). Esto permite que los recursos y las actividades relacionadas con los servicios de las TI se manejarán y controlarán mediante los objetivos del control, alineado y supervisado usando la métrica de KGI y de KPI de COBIT, según lo ilustrado en la fig.3.2 Fig Gerencia, control, alineación y supervisión en COBIT (Fuente: IT Governance Institute) Estos indicadores son utilizados para medir la tecnología de la información de la empresa y se definen de la siguiente forma: Indicadores clave del rendimiento (KPI): Definen las medidas del rendimiento de los procesos de TI en función de su funcionamiento y operación, con criterios tales como: capacidades, prácticas, habilidades, etc. 20

21 Indicadores clave de logros (KGI): Definen las medidas que determinan si un proceso de TI satisface los requerimientos de negocio, utilizando criterios como: disponibilidad, eficiencia, ausencia de riesgos, etc. La aplicación de esta estructura según se analiza en, permite a los usuarios definir una cascada de métricas con relaciones causales entre los indicadores KPIs, KGIs, desde el nivel de proceso, al nivel de las tecnologías de la información y finalizando en el nivel del negocio. El panorama es complejo y, para una pequeña o mediana empresa, abordar la implantación de un sistema de gestión de seguridad, con la posibilidad de tener varios niveles de exigencia y con unos recursos limitados, se convierte en una tarea muy compleja. Es por ello la importancia que para el desarrollo de un buen SGSI el establecer un Programa de Métricas acorde. Las principales etapas en el Desarrollo de métricas serían: Identificar el estado o madurez de la seguridad Seleccionar las métricas adecuadas para medir: o implantación o eficacia o eficiencia o impacto Roles y responsabilidades de la organización Definición de objetivos de seguridad Revisión de políticas y procedimientos Revisión de planes de seguridad Selección de métricas En la definición de un Cuadro de Mando para la seguridad de la información, en congruencia con la guía de COBIT se nos define cuatro perspectivas tal y como se muestra en la tabla 3.1: Contribución corporativa Cómo ve la organización el valor creado por la seguridad en TI Excelencia Operacional Cuán eficientes y efectivos son los procesos de administración de la seguridad en TI Orientación al usuario Cómo ven los usuarios en TI a la seguridad en la tecnología de la información Orientación Futura Cómo ven los usuarios en TI a la seguridad en la tecnología de la información Tabla 3.1. Cuadro de mando para la Seguridad en IT El desarrollo de un cuadro de mandos de indicadores de seguridad necesita del conocimiento previo de lo que funciona en una compañía. Se debe empezar por determinar los componentes funcionales que quiere medir. En nuestro caso hemos utilizado la norma ISO como guía base para desarrollar las áreas de control que hemos tratado de medir. Estos dominios funcionales son el entrenamiento en la concienciación de los usuarios, las políticas, el control de auditoría, la respuesta a incidentes, el acceso remoto, la continuidad de la empresa y recuperación de los siniestros, la administración de la infraestructura PKI, la evaluación de riesgos, etc. Este cuadro, tiene diferentes niveles y esta orientado a gerentes, permitiéndoles analizar su nivel de seguridad en base a los distintos controles. El cuadro de mandos que se esta desarrollando tiene indicadores estáticos que deben ser actualizados a mano, según las revisiones realizadas por externos 21