Magerit V3 - Completo

MAGERIT – versión 3.0 Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información Libro I - Método

TÍTULO: MAGERIT – versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro I - Método Elaboración y coordinación de contenidos: Dirección General de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica Equipo responsable del proyecto: Director, Miguel Angel Amutio Gómez, Ministerio de Hacienda y Administraciones Públicas Javier Candau, Centro Criptológico Nacional, Ministerio de la Presidencia Consultor externo: José Antonio Mañas, Catedrático de la Universidad Politécnica de Madrid Características: Adobe Acrobat 5.0 Responsable edición digital: Subdirección General de Información, Documentación y Publicaciones (Jesús González Barroso) Madrid, octubre de 2012 Disponible esta publicación en el Portal de Administración Electrónica (PAe): http://administracionelectronica.gob.es/ Edita: © Ministerio de Hacienda y Administraciones Públicas Secretaría General Técnica Subdirección General de Información, Documentación y Publicaciones Centro de Publicaciones Colección: administración electrónica NIPO: 630-12-171-8

Magerit 3.0

Índice 1. Introducción ...................................................................................................................6  1.1 Buen gobierno .........................................................................................................................6  1.2. Confianza ...............................................................................................................................6  1.3. Gestión ...................................................................................................................................7  1.4. Magerit ...................................................................................................................................7  1.5. Introducción al análisis y gestión de riesgos ..........................................................................8  1.6. El análisis y el tratamiento de los riesgos en su contexto ....................................................10  1.6.1. Concienciación y formación..........................................................................................11  1.6.2. Incidencias y recuperación ...........................................................................................11  1.7. Organización de las guías....................................................................................................12  1.7.1. Modo de empleo ...........................................................................................................12  1.7.2. El catálogo de elementos .............................................................................................13  1.7.3. La guía de técnicas.......................................................................................................14  1.8. Evaluación, certificación, auditoría y acreditación................................................................14  1.9. ¿Cuándo procede analizar y gestionar los riesgos? ............................................................16  2. Visión de conjunto.......................................................................................................19  3. Método de análisis de riesgos....................................................................................22  3.1. Conceptos paso a paso........................................................................................................22  3.1.1. Paso 1: Activos .............................................................................................................22  3.1.2. Paso 2: Amenazas........................................................................................................27  3.1.3. Determinación del impacto potencial............................................................................28  3.1.4. Determinación del riesgo potencial...............................................................................29  3.1.5. Paso 3: Salvaguardas...................................................................................................31  3.1.6. Paso 4: impacto residual ..............................................................................................35  3.1.7. Paso 5: riesgo residual .................................................................................................35  3.2. Formalización de las actividades .........................................................................................35  3.2.1. Tarea MAR.1: Caracterización de los activos...............................................................37  3.2.2. Tarea MAR.2: Caracterización de las amenazas .........................................................40  3.2.3. Tarea MAR.3: Caracterización de las salvaguardas ....................................................42  3.2.4. Tarea MAR.4: Estimación del estado de riesgo ...........................................................44  3.3. Documentación ....................................................................................................................45  3.4. Lista de control .....................................................................................................................46  4. Proceso de gestión de riesgos...................................................................................47  4.1. Conceptos ............................................................................................................................48  4.1.1. Evaluación: interpretación de los valores de impacto y riesgo residuales....................48  4.1.2. Aceptación del riesgo ...................................................................................................49  4.1.3. Tratamiento...................................................................................................................49  4.1.4. Estudio cuantitativo de costes / beneficios ...................................................................50  4.1.5. Estudio cualitativo de costes / beneficios .....................................................................53  4.1.6. Estudio mixto de costes / beneficios.............................................................................53  4.1.7. Opciones de tratamiento del riesgo: eliminación ..........................................................53  4.1.8. Opciones de tratamiento del riesgo: mitigación............................................................53  4.1.9. Opciones de tratamiento del riesgo: compartición........................................................54  4.1.10. Opciones de tratamiento del riesgo: financiación .......................................................54  4.2. Formalización de las actividades .........................................................................................54  4.2.1. Roles y funciones .........................................................................................................55  4.2.2. Contexto .......................................................................................................................57  4.2.3. Criterios ........................................................................................................................57  4.2.4. Evaluación de los riesgos .............................................................................................58  4.2.5. Decisión de tratamiento ................................................................................................58  4.2.6. Comunicación y consulta..............................................................................................59  4.2.7. Seguimiento y revisión..................................................................................................59  4.3. Documentación del proceso.................................................................................................60  4.4. Indicadores de control del proceso de gestión de riesgos ...................................................60  © Ministerio de Hacienda y Administraciones Públicas

página 3 (de 127)

Magerit 3.0

5. Proyectos de análisis de riesgos ...............................................................................62  5.1. Roles y funciones .................................................................................................................62  5.2. PAR.1 – Actividades preliminares ........................................................................................64  5.2.1. Tarea PAR.11: Estudio de oportunidad ........................................................................64  5.2.2. Tarea PAR.12: Determinación del alcance del proyecto ..............................................66  5.2.3. Tarea PAR.13: Planificación del proyecto ....................................................................69  5.2.4. Tarea PAR.14: Lanzamiento del proyecto....................................................................69  5.3. PAR.2 – Elaboración del análisis de riesgos........................................................................70  5.4. PAR.3 – Comunicación de resultados..................................................................................71  5.5. Control del proyecto .............................................................................................................71  5.5.1. Hitos de control.............................................................................................................71  5.5.2. Documentación resultante ............................................................................................71  6. Plan de seguridad ........................................................................................................73  6.1. Tarea PS.1: Identificación de proyectos de seguridad.........................................................73  6.2. Tarea PS.2: Planificación de los proyectos de seguridad ....................................................75  6.3. Tarea PS.3: Ejecución del plan ............................................................................................76  6.4. Lista de control de los planes de seguridad .........................................................................76  7. Desarrollo de sistemas de información .....................................................................77  7.1. Inicialización de los procesos...............................................................................................77  7.2. SSI – Seguridad del sistema de información .......................................................................78  7.2.1. Ciclo de vida de las aplicaciones..................................................................................79  7.2.2. Contexto .......................................................................................................................80  7.2.3. Fase de especificación: adquisición de datos ..............................................................80  7.2.4. Fase de diseño: estudio de opciones ...........................................................................81  7.2.5. Soporte al desarrollo: puntos críticos ...........................................................................81  7.2.6. Aceptación y puesta en marcha: puntos críticos ..........................................................82  7.2.7. Operación: análisis y gestión dinámicos.......................................................................83  7.2.8. Ciclos de mantenimiento: análisis marginal..................................................................83  7.2.9 Terminación ...................................................................................................................83  7.2.10 Documentación de seguridad ......................................................................................84  7.3. SPD – Seguridad del proceso de desarrollo ........................................................................84  7.4. Referencias ..........................................................................................................................85  8. Consejos prácticos......................................................................................................86  8.1. Alcance y profundidad..........................................................................................................86  8.2. Para identificar activos .........................................................................................................87  8.3. Para descubrir y modelar las dependencias entre activos...................................................88  8.4. Para valorar activos..............................................................................................................91  8.5. Para identificar amenazas....................................................................................................93  8.6. Para valorar amenazas ........................................................................................................93  8.7. Para seleccionar salvaguardas ............................................................................................94  8.8. Aproximaciones sucesivas ...................................................................................................94  8.8.1. Protección básica .........................................................................................................95  Apéndice 1. Glosario .......................................................................................................97  A1.1. Términos en español .........................................................................................................97  A1.2. Términos anglosajones....................................................................................................106  A1.3. ISO – Gestión del riesgo..................................................................................................107  Apéndice 2. Referencias ...............................................................................................108  Apéndice 3. Marco legal ................................................................................................112  A3.1. Seguridad en el ámbito de la Administración electrónica ................................................112  A3.2. Protección de datos de carácter personal .......................................................................112  A3.3. Firma electrónica .............................................................................................................112  A3.4. Información clasificada ....................................................................................................112  A3.5. Seguridad de las redes y de la información.....................................................................113  Apéndice 4. Marco de evaluación y certificación .......................................................114  A4.1. Sistemas de gestión de la seguridad de la información (SGSI).......................................114  © Ministerio de Hacienda y Administraciones Públicas

página 4 (de 127)

Magerit 3.0 A4.1.1. La certificación .........................................................................................................115  A4.1.2. La acreditación de la entidad certificadora...............................................................116  A4.1.3. Terminología ............................................................................................................116  A4.2. Criterios comunes de evaluación (CC) ............................................................................117  A4.2.1. Beneficiarios.............................................................................................................119  A4.2.2. Requisitos de seguridad...........................................................................................119  A4.2.3. Creación de perfiles de protección...........................................................................120  A4.2.4. Uso de productos certificados ..................................................................................121  A4.2.5. Terminología ............................................................................................................122 

Apéndice 5. Herramientas.............................................................................................124  A5.1. PILAR...............................................................................................................................125  Apéndice 6. Evolución de Magerit................................................................................126  A6.1. Para los que han trabajado con Magerit v1 .....................................................................126  A6.2. Para los que han trabajado con Magerit v2 .....................................................................127 

© Ministerio de Hacienda y Administraciones Públicas

página 5 (de 127)

Magerit 3.0

Introducción

1. Introducción El CSAE 1 ha elaborado y promueve Magerit 2 como respuesta a la percepción de que la Administración Pública (y en general toda la sociedad) depende de forma creciente de los sistemas de información para alcanzar sus objetivos. El uso de tecnologías de la información y comunicaciones (TIC) supone unos beneficios evidentes para los ciudadanos; pero también da lugar a ciertos riesgos que deben gestionarse prudentemente con medidas de seguridad que sustenten la confianza de los usuarios de los servicios.

1.1 Buen gobierno La gestión de los riesgos es una piedra angular en las guías de buen gobierno [ISO 38500], público o privado, donde se considera un principio fundamental que las decisiones de gobierno se fundamenten en el conocimiento de los riesgos que implican: 1.6.12 Propuesta Recopilación de los beneficios, costos, riesgos, oportunidades, y otros factores que deben tenerse en cuenta en las decisiones que se tomen. 3 cubriendo riesgos en general y riesgos TIC en particular: Esta norma establece los principios para el uso eficaz, eficiente y aceptable de las tecnologías de la información. Garantizando que sus organizaciones siguen estos principios ayudará a los directores a equilibrar riesgos y oportunidades derivados del uso de las TI. 4 Se insiste recurrentemente en el necesario equilibrio entre riesgos y oportunidades para tomar las mejores decisiones. En pocas palabras, la gestión de los riesgos es nuclear al gobierno de las organizaciones. En particular, los riesgos que tienen su origen en el uso de tecnologías de la información deben trasladarse a los órganos de gobierno y contextualizarse en la misión de la organización. El conocimiento de los riesgos permite calibrar la confianza en que los sistemas desempeñarán su función como la Dirección espera, habilitando un marco equilibrado de Gobierno, Gestión de Riesgos y Cumplimiento (GRC), tres áreas que deben estar integradas y alineadas para evitar conflictos, duplicación de actividades y zonas de nadie. Los órganos de gobierno no deben tratar solamente riesgos TIC. Es más, no deben tratar los riesgos TIC por separado de los demás riesgos. Aunque Magerit se especializa en riesgos TIC, debemos ser muy conscientes de que es esencial transmitir a los órganos de gobiernos las oportunidades y los riesgos que conllevan las tecnologías de la información para que se puedan incluir en un marco global y tomar las mejores decisiones para la Organización.

1.2. Confianza La confianza es la esperanza firme que se tiene de que algo responderá a lo previsto. La confianza es un valor crítico en cualquier organización que preste servicios. Las administraciones públicas son especialmente sensibles a esta valoración. Por una parte dependemos fuertemente de los sistemas de información para cumplir nuestros objetivos; pero por otra parte, no deja de ser un tema recurrente la inquietud por su seguridad. Los afectados, que frecuentemente no son técnicos, se preguntan si estos sistemas merecen su confianza, confianza que se ve mermada por cada fallo y, sobre todo, cuando la inversión no se tra1 2 3

4

CSAE: Consejo Superior de Administración Electrónica. MAGERIT: Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información 1.6.12 Proposal. Compilation of benefits, costs, risks, opportunities, and other factors applicable to decisions to be made. Includes business cases This standard establishes principles for the effective, efficient and acceptable use of IT. Ensuring that their organisations follow these principles will assist directors in balancing risks and encouraging opportunities arising from the use of IT.

© Ministerio de Hacienda y Administraciones Públicas

página 6 (de 127)

Magerit 3.0

Introducción

duce en la ausencia de fallos. Lo ideal es que los sistemas no fallen. Pero lo cierto que se acepta convivir con sistemas que fallan. El asunto no es tanto la ausencia de incidentes como la confianza en que están bajo control: se sabe qué puede pasar y se sabe qué hacer cuando pasa. El temor a lo desconocido es el principal origen de la desconfianza y, en consecuencia, aquí se busca conocer para confiar: conocer los riesgos para poder afrontarlos y controlarlos.

1.3. Gestión Conocer el riesgo al que están sometidos los elementos de trabajo es, simplemente, imprescindible para poder gestionarlos. En el periodo transcurrido desde la publicación de la primera versión de Magerit (1997) hasta la fecha, el análisis de riesgos se ha venido consolidando como paso necesario para la gestión de la seguridad. Así se recoge claramente en las Directrices de la OCDE [OCDE] que, en su principio 6 dicen: 6) Evaluación del riesgo. Los participantes deben llevar a cabo evaluaciones de riesgo. En el Esquema Nacional de Seguridad [RD 3/2010], el Capítulo II Principios Básicos, dice Artículo 6. Gestión de la seguridad basada en los riesgos. 1. El análisis y gestión de riesgos será parte esencial del proceso de seguridad y deberá mantenerse permanentemente actualizado. 2. La gestión de riesgos permitirá el mantenimiento de un entorno controlado, minimizando los riesgos hasta niveles aceptables. La reducción de estos niveles se realizará mediante el despliegue de medidas de seguridad, que establecerá un equilibrio entre la naturaleza de los datos y los tratamientos, los riesgos a los que estén expuestos y las medidas de seguridad.

1.4. Magerit Siguiendo la terminología de la normativa ISO 31000, Magerit responde a lo que se denomina “Proceso de Gestión de los Riesgos”, sección 4.4 (“Implementación de la Gestión de los Riesgos”) dentro del “Marco de Gestión de Riesgos”. En otras palabras, MAGERIT implementa el Proceso de Gestión de Riesgos dentro de un marco de trabajo para que los órganos de gobierno tomen decisiones teniendo en cuenta los riesgos derivados del uso de tecnologías de la información.

Ilustración 1. ISO 31000 - Marco de trabajo para la gestión de riesgos

© Ministerio de Hacienda y Administraciones Públicas

página 7 (de 127)

Magerit 3.0

Introducción

Hay varias aproximaciones al problema de analizar los riesgos soportados por los sistemas TIC: guías informales, aproximaciones metódicas y herramientas de soporte. Todas buscan objetivar el análisis de riesgos para saber cuán seguros (o inseguros) son los sistemas y no llamarse a engaño. El gran reto de todas estas aproximaciones es la complejidad del problema al que se enfrentan; complejidad en el sentido de que hay muchos elementos que considerar y que, si no se es riguroso, las conclusiones serán de poco fiar. Es por ello que en Magerit se persigue una aproximación metódica que no deje lugar a la improvisación, ni dependa de la arbitrariedad del analista. Magerit persigue los siguientes objetivos: Directos: 1. concienciar a los responsables de las organizaciones de información de la existencia de riesgos y de la necesidad de gestionarlos 2. ofrecer un método sistemático para analizar los riesgos derivados del uso de tecnologías de la información y comunicaciones (TIC) 3. ayudar a descubrir y planificar el tratamiento oportuno para mantener los riesgos bajo control Indirectos: 4. preparar a la Organización para procesos de evaluación, auditoría, certificación o acreditación, según corresponda en cada caso También se ha buscado la uniformidad de los informes que recogen los hallazgos y las conclusiones de las actividades de análisis y gestión de riesgos: Modelo de valor Caracterización del valor que representan los activos para la Organización así como de las dependencias entre los diferentes activos. Mapa de riesgos Relación de las amenazas a que están expuestos los activos. Declaración de aplicabilidad Para un conjunto de salvaguardas, se indica sin son de aplicación en el sistema de información bajo estudio o si, por el contrario, carecen de sentido. Evaluación de salvaguardas Evaluación de la eficacia de las salvaguardas existentes en relación al riesgo que afrontan. Estado de riesgo Caracterización de los activos por su riesgo residual; es decir, por lo que puede pasar tomando en consideración las salvaguardas desplegadas. Informe de insuficiencias Ausencia o debilidad de las salvaguardas que aparecen como oportunas para reducir los riesgos sobre el sistema. Es decir, recoge las vulnerabilidades del sistema, entendidas como puntos débilmente protegidos por los que las amenazas podrían materializarse. Cumplimiento de normativa Satisfacción de unos requisitos. Declaración de que se ajusta y es conforme a la normativa correspondiente. Plan de seguridad Conjunto de proyectos de seguridad que permiten materializar las decisiones de tratamiento de riesgos

1.5. Introducción al análisis y gestión de riesgos Seguridad es la capacidad de las redes o de los sistemas de información para resistir, con un determinado nivel de confianza, los accidentes o acciones ilícitas o malintencionadas que compro© Ministerio de Hacienda y Administraciones Públicas

página 8 (de 127)

Magerit 3.0

Introducción

metan la disponibilidad, autenticidad, integridad y confidencialidad de los datos almacenados o transmitidos y de los servicios que dichas redes y sistemas ofrecen o hacen accesibles. 5 El objetivo a proteger es la misión de la Organización, teniendo en cuenta las diferentes dimensiones de la seguridad: Disponibilidad: o disposición de los servicios a ser usados cuando sea necesario. La carencia de disponibilidad supone una interrupción del servicio. La disponibilidad afecta directamente a la productividad de las organizaciones. Integridad: o mantenimiento de las características de completitud y corrección de los datos. Contra la integridad, la información puede aparecer manipulada, corrupta o incompleta. La integridad afecta directamente al correcto desempeño de las funciones de una Organización. Confidencialidad: o que la información llegue solamente a las personas autorizadas. Contra la confidencialidad o secreto pueden darse fugas y filtraciones de información, así como accesos no autorizados. La confidencialidad es una propiedad de difícil recuperación, pudiendo minar la confianza de los demás en la organización que no es diligente en el mantenimiento del secreto, y pudiendo suponer el incumplimiento de leyes y compromisos contractuales relativos a la custodia de los datos. A estas dimensiones canónicas de la seguridad se pueden añadir otras derivadas que nos acerquen a la percepción de los usuarios de los sistemas de información: Autenticidad: Propiedad o característica consistente en que una entidad es quien dice ser o bien que garantiza la fuente de la que proceden los datos. Contra la autenticidad de la información podemos tener manipulación del origen o el contenido de los datos. Contra la autenticidad de los usuarios de los servicios de acceso, podemos tener suplantación de identidad. Trazabilidad: Aseguramiento de que en todo momento se podrá determinar quién hizo qué y en qué momento. La trazabilidad es esencial para analizar los incidentes, perseguir a los atacantes y aprender de la experiencia. La trazabilidad se materializa en la integridad de los registros de actividad. Todas estas características pueden ser requeridas o no dependiendo de cada caso. Cuando se requieren, no es evidente que se disfruten sin más. Lo habitual que haya que poner medios y esfuerzo para conseguirlas. A racionalizar este esfuerzo se dedican las metodologías de análisis y gestión de riesgos que comienzan con una definición: Riesgo: estimación del grado de exposición a que una amenaza se materialice sobre uno o más activos causando daños o perjuicios a la Organización. El riesgo indica lo que le podría pasar a los activos si no se protegieran adecuadamente. Es importante saber qué características son de interés en cada activo, así como saber en qué medida estas características están en peligro, es decir, analizar el sistema: Análisis de riesgos: proceso sistemático para estimar la magnitud de los riesgos a que está expuesta una Organización. Sabiendo lo que podría pasar, hay que tomar decisiones:

5

Reglamento (CE) n 460/2004 del Parlamento Europeo y del Consejo, de 10 de marzo de 2004, por el que se crea la Agencia Europea de Seguridad de las Redes y de la Información.

© Ministerio de Hacienda y Administraciones Públicas

página 9 (de 127)

Magerit 3.0

Introducción

Tratamiento de los riesgos proceso destinado a modificar el riesgo. Hay múltiples formas de tratar un riesgo: evitar las circunstancias que lo provocan, reducir las posibilidades de que ocurra, acotar sus consecuencias, compartirlo con otra organización (típicamente contratando un servicio o un seguro de cobertura), o, en última instancia, aceptando que pudiera ocurrir y previendo recursos para actuar cuando sea necesario. Nótese que una opción legítima es aceptar el riesgo. Es frecuente oír que la seguridad absoluta no existe; en efecto, siempre hay que aceptar un riesgo que, eso sí, debe ser conocido y sometido al umbral de calidad que se requiere del servicio. Es más, a veces aceptamos riesgos operacionales para acometer actividades que pueden reportarnos un beneficio que supera al riesgo, o que tenemos la obligación de afrontar. Es por ello que a veces se emplean definiciones más amplias de riesgo: Efecto de la incertidumbre sobre la consecución de los objetivos. [ISO Guía 73] Como todo esto es muy delicado, no es meramente técnico, e incluye la decisión de aceptar un cierto nivel de riesgo, deviene imprescindible saber en qué condiciones se trabaja y así poder ajustar la confianza que merece el sistema. Para ello, qué mejor que una aproximación metódica que permita tomar decisiones con fundamento y explicar racionalmente las decisiones tomadas.

1.6. El análisis y el tratamiento de los riesgos en su contexto Las tareas de análisis y tratamiento de los riesgos no son un fin en sí mismas sino que se encajan en la actividad continua de gestión de la seguridad. El análisis de riesgos permite determinar cómo es, cuánto vale y cómo de protegido se encuentra el sistema. En coordinación con los objetivos, estrategia y política de la Organización, las actividades de tratamiento de los riesgos permiten elaborar un plan de seguridad que, implantado y operado, satisfaga los objetivos propuestos con el nivel de riesgo que acepta la Dirección. Al conjunto de estas actividades se le denomina Proceso de Gestión de Riesgos. La implantación de las medidas de seguridad requiere una organización gestionada y la participación informada de todo el personal que trabaja con el sistema de información. Es este personal el responsable de la operación diaria, de la reacción ante incidencias y de la monitorización en general del sistema para determinar si satisface con eficacia y eficiencia los objetivos propuestos. Este esquema de trabajo debe ser repetitivo pues los sistemas de información rara vez son inmutables; más bien se encuentran sometidos a evolución continua tanto propia (nuevos activos) como del entorno (nuevas amenazas), lo que exige una revisión periódica en la que se aprende de la experiencia y se adapta al nuevo contexto. El análisis de riesgos proporciona un modelo del sistema en términos de activos, amenazas y salvaguardas, y es la piedra angular para controlar todas las actividades con fundamento. La fase de tratamiento estructura las acciones que se acometen en materia de seguridad para satisfacer las necesidades detectadas por el análisis. Los sistemas de gestión de la seguridad de la información (SGSI) [ISO 27001] formalizan cuatro etapas cíclicas:

© Ministerio de Hacienda y Administraciones Públicas

página 10 (de 127)

Magerit 3.0

Introducción

Ilustración 2. Ciclo PDCA

El análisis de riesgos es parte de las actividades de planificación, donde se toman decisiones de tratamiento. Estas decisiones se materializan en la etapa de implantación, donde conviene desplegar elementos que permitan la monitorización de las medidas desplegadas para poder evaluar la efectividad de las mismas y actuar en consecuencia, dentro de un círculo de excelencia o mejora continua.

1.6.1. Concienciación y formación El mejor plan de seguridad se vería seriamente hipotecado sin una colaboración activa de las personas involucradas en el sistema de información, especialmente si la actitud es negativa, contraria a las medidas, o tienen la percepción de pasarse el día “luchando contra las [absurdas] medidas de seguridad”. Es por ello que se requiere la creación de una “cultura de seguridad” que, emanando de la alta dirección, conciencie a todos los involucrados de su necesidad y pertinencia. Son tres los pilares fundamentales para la creación de esta cultura: •

una política de seguridad corporativa que se entienda (escrita para los que no son expertos en la materia), que se difunda y que se mantenga al día

•

una normativa se seguridad que, entrando en áreas específicas de actividad, aclare la postura de la Organización; es decir, defina lo que es uso correcto y lo que es incumplimiento

•

una formación continua a todos los niveles, recordando las cautelas rutinarias y las actividades especializadas, según la responsabilidad adscrita a cada puesto de trabajo

A fin de que estas actividades cuajen en la organización, es imprescindible que la seguridad sea: •

mínimamente intrusiva: que no dificulte innecesariamente la actividad diaria ni hipoteque alcanzar los objetivos de productividad propuestos,

•

sea “natural”: que no de pie a errores gratuitos 6 , que facilite el cumplimiento de las buenas prácticas propuestas y

•

practicada por la Dirección: que dé ejemplo en la actividad diaria y reaccione con presteza a los cambios e incidencias.

1.6.2. Incidencias y recuperación Las personas involucradas en la utilización y operación del sistema deben ser conscientes de su papel y relevancia continua para prevenir problemas y reaccionar cuando se produzcan. Es importante crear una cultura de responsabilidad donde los potenciales problemas, detectados por los que están cercanos a los activos afectados, puedan ser canalizados hacia los puntos de decisión. De esta forma el sistema de seguridad responderá con presteza a las circunstancias de cada momento. 6

A menudo se oye hablar de “seguridad por defecto” o “seguridad sin manual” para recoger esta idea de que los sistemas son más seguros si la forma natural de utilizarlos es la forma segura de utilizarlos.

© Ministerio de Hacienda y Administraciones Públicas

página 11 (de 127)

Magerit 3.0

Introducción

Cuando se produce una incidencia, el tiempo empieza a correr en contra del sistema: su supervivencia depende de la agilidad y corrección de las actividades de reporte y reacción. Cualquier error, imprecisión o ambigüedad en estos momentos críticos, se ve amplificado convirtiendo lo que podía ser un mero incidente en un desastre. Conviene aprender continuamente, tanto de los éxitos como de los fracasos, e incorporar lo que vamos aprendiendo al proceso de gestión de riesgos. La madurez de una organización se refleja en la pulcritud y realismo de su modelo de valor y, consecuentemente, en la idoneidad de las salvaguardas de todo tipo, desde medidas técnicas hasta una óptima organización.

1.7. Organización de las guías Esta versión 3 de Magerit se ha estructurado en dos libros y una guía de técnicas: — Libro I – Método — Libro II – Catálogo de elementos — Guía de Técnicas – Recopilación de técnicas de diferente tipo que pueden ser de utilidad para la aplicación del método. Este libro se estructura de la siguiente forma: •

El capítulo 2 presenta los conceptos informalmente. En particular se enmarcan las actividades de análisis y tratamiento dentro de un proceso integral de gestión de riesgos.

•

El capítulo 3 concreta los pasos y formaliza las actividades de análisis de los riesgos.

•

El capítulo 4 describe opciones y criterios de tratamiento de los riesgos y formaliza las actividades de gestión de riesgos.

•

El capítulo 5 se centra en los proyectos de análisis de riesgos, proyectos en los que nos veremos inmersos para realizar el primer análisis de riesgos de un sistema y eventualmente cuando hay cambios sustanciales y hay que rehacer el modelo ampliamente.

•

El capítulo 6 formaliza las actividades de los planes de seguridad, a veces denominados planes directores o planes estratégicos.

•

El capítulo 7 se centra en el desarrollo de sistemas de información y cómo el análisis de riesgos sirve para gestionar la seguridad del producto final desde su concepción inicial hasta su puesta en producción, así como a la protección del propio proceso de desarrollo.

•

El capítulo 8 se anticipa a algunos problemas que aparecen recurrentemente cuando se realizan análisis de riesgos.

Los apéndices recogen material de consulta: 1. un glosario, 2. referencias bibliográficas consideradas para el desarrollo de esta metodología, 3. referencias al marco legal que encuadra las tareas de análisis y gestión en la Administración Pública Española, 4. el marco normativo de evaluación y certificación 5. las características que se requieren de las herramientas, presentes o futuras, para soportar el proceso de análisis y gestión de riesgos, 6. una guía comparativa de cómo Magerit versión 1 ha evolucionado a la versión 2 y a esta versión 3.

1.7.1. Modo de empleo Siempre se explican informalmente las actividades a realizar, y en ciertos casos se formalizan como tareas que permiten una planificación y seguimiento:

© Ministerio de Hacienda y Administraciones Públicas

página 12 (de 127)

Magerit 3.0

Introducción

Ilustración 3. Actividades formalizadas

En sistemas pequeños, estas actividades pueden llevarse a cabo sin muchos formalismos; pero cuando el sistema adquiere envergadura e involucra a diferentes personas y equipos de trabajo durante varias semanas, meses o años, la planificación formal ayuda a mantener el proceso bajo control. En el planteamiento de estas guías se ha seguido un criterio “de máximos”, reflejando todo tipo de situaciones. En la práctica, el usuario puede encontrarse ante situaciones donde el alcance es más restringido. Ante estas situaciones, conviene ser práctico y no pretender aplicar todas las tareas descritas en Magerit desde el primer momento. Suele ser prudente realizar una aproximación iterativa, aplicando el método primero con trazo grueso y luego ir revisando el modelo para entrar en detalles. El proceso de gestión de riesgos debe identificar y tratar urgentemente los riesgos críticos, pudiendo ir tratando progresivamente riesgos de menor criticidad. Como se dice popularmente “lo perfecto es enemigo de lo bueno”. Lo prudente es armonizar el esfuerzo al valor de la información y los servicios que se sustentan. Entiéndase pues Magerit como una guía que se puede y se debe adaptar al caso y sus circunstancias.

1.7.2. El catálogo de elementos En libro aparte, se propone un catálogo, abierto a ampliaciones, que marca unas pautas en cuanto a: •

tipos de activos

•

dimensiones de valoración de los activos

•

criterios de valoración de los activos

•

amenazas típicas sobre los sistemas de información

•

salvaguardas a considerar para proteger sistemas de información

Se persiguen dos objetivos: 1. Por una parte, facilitar la labor de las personas que acometen el proyecto, en el sentido de ofrecerles elementos estándar a los que puedan adscribirse rápidamente, centrándose en lo específico del sistema objeto del análisis. 2. Por otra, homogeneizar los resultados de los análisis, promoviendo una terminología y unos criterios uniformes que permitan comparar e incluso integrar análisis realizados por diferentes equipos. Cada sección incluye una notación XML que se empleará para publicar regularmente los elementos en un formato estándar capaz de ser procesado automáticamente por herramientas de análisis y gestión.

© Ministerio de Hacienda y Administraciones Públicas

página 13 (de 127)

Magerit 3.0

Introducción

Si el lector usa una herramienta de análisis y gestión de riesgos, este catálogo será parte de la misma; si el análisis se realiza manualmente, este catálogo proporciona una amplia base de partida para avanzar rápidamente sin distracciones ni olvidos.

1.7.3. La guía de técnicas En libro aparte, aporta luz adicional y orientación sobre algunas técnicas que se emplean habitualmente para llevar a cabo proyectos de análisis y gestión de riesgos: •

•

técnicas específicas para el análisis de riesgos •

análisis mediante tablas

•

análisis algorítmico

•

árboles de ataque

técnicas generales •

técnicas gráficas

•

sesiones de trabajo: entrevistas, reuniones y presentaciones

•

valoración Delphi

Se trata de una guía de consulta. Según el lector avance por la tareas del proyecto, se le recomendará el uso de ciertas técnicas específicas, de las que esta guía busca ser una introducción, así como proporcionar referencias para que el lector profundice en las técnicas presentadas.

1.8. Evaluación, certificación, auditoría y acreditación El análisis de riesgos es una piedra angular de los procesos de evaluación, certificación, auditoría y acreditación que formalizan la confianza que merece un sistema de información. Dado que no hay dos sistemas de información iguales, la evaluación de cada sistema concreto requiere amoldarse a los componentes que lo constituyen. El análisis de riesgos proporciona una visión singular de cómo es cada sistema, qué valor posee, a qué amenazas está expuesto y de qué salvaguardas se ha dotado. Es pues el análisis de riesgos paso obligado para poder llevar a cabo todas las tareas mencionadas, que se relacionan según el siguiente esquema:

© Ministerio de Hacienda y Administraciones Públicas

página 14 (de 127)

Magerit 3.0

Introducción

Ilustración 4. Contexto de certificación y acreditación de sistemas de información

En esta sección se hace una presentación conceptual de las actividades citadas. El lector encontrará en el apéndice 4 un tratamiento específico de los marcos normativos relativos a sistemas de gestión y productos de seguridad.

Evaluación Es cada vez más frecuente la evaluación de la seguridad de los sistemas de información, tanto internamente como parte de los procesos de gestión, como por medio de evaluadores independientes externos. Las evaluaciones permiten medir el grado de confianza que merece o inspira un sistema de información.

Certificación La evaluación puede llevar a una certificación o registro de la seguridad del sistema. En la práctica se certifican productos y se certifican sistemas de gestión de la seguridad. La certificación de productos es, de alguna forma, impersonal: “esto tiene estas características técnicas”. Sin embargo, la certificación de sistemas de gestión tiene que ver con el “componente humano” de las organizaciones buscando el análisis de cómo se explotan los sistemas 7 . Certificar es asegurar responsablemente y por escrito un comportamiento. Lo que se certifica, producto o sistema, se somete a una serie de evaluaciones orientadas por un objetivo ¿para qué lo quiere? 8 . Un certificado dice que un sistema es capaz de proteger unos datos de unas amenazas con una cierta calidad (capacidad de protección). Y lo dice en base a que ha observado la existencia y el funcionamiento de una serie de salvaguardas. Es decir que detrás de un certificado no hay sino los conceptos de un análisis de riesgos.

7 Hay vehículos con altas calificaciones técnicas y otros más humildes. Lo mismo que hay conductores que son verdaderos profesionales y otros de los que nunca nos explicaremos cómo es que están certificados como “aptos para el manejo de vehículos”. Lo ideal es poner un gran coche en manos de un gran conductor. De ahí para abajo, tenemos una gran variedad de situaciones de menor confianza: mayor riesgo de que algo vaya mal. 8 Y así tenemos sistemas aptos para “consumo humano” o “utilización en condiciones térmicas extremas”.

© Ministerio de Hacienda y Administraciones Públicas

página 15 (de 127)

Magerit 3.0

Introducción

Antes de proceder a la certificación, debe haberse realizado un análisis de riesgos a fin de conocer los riesgos y de controlarlos mediante la adopción de los controles adecuados, además, será un punto de control de la gestión del producto o sistema.

Acreditación Algunas certificaciones tienen como objetivo la acreditación del producto o sistema. La acreditación es un proceso específico cuyo objetivo es legitimar al sistema para formar parte de sistemas más amplios. Se puede ver como una certificación para un propósito específico.

Auditorías Aunque no sea lo mismo, no están muy lejos de este mundo las auditorías, internas o externas, a las que se someten los sistemas de información •

unas veces requeridas por ley para poder operar en un cierto sector (cumplimiento),

•

otras veces requeridas por la propia Dirección de la Organización,

•

otras veces requeridas por entidades colaboradoras que ven su propio nivel de riesgo ligado al nuestro.

Una auditoría puede servirse de un análisis de riesgos que le permita (1) saber qué hay en juego, (2) saber a qué está expuesto el sistema y (3) valorar la eficacia y eficiencia de las salvaguardas. Frecuentemente, los auditores parten de un análisis de riesgos, implícito o explícito, que, o bien realizan ellos mismos, o bien lo auditan. Siempre en la primera fase de la auditoría, pues es difícil opinar de lo que no se conoce. A partir del análisis de riesgos se puede analizar el sistema e informar a la gerencia de si el sistema está bajo control; es decir, si las medidas de seguridad adoptadas están justificadas, implantadas y monitorizadas, de forma que se puede confiar en el sistema de indicadores de que dispone la gerencia para gestionar la seguridad de los sistemas. La conclusión de la auditoría es un informe de insuficiencias detectadas, que no son sino incoherencias entre las necesidades identificadas en el análisis de riesgos y la realidad detectada durante la inspección del sistema en operación. El informe de auditoría deberá dictaminar sobre la adecuación de las medidas y controles a la Ley y su desarrollo reglamentario, identificar sus deficiencias y proponer las medidas correctoras o complementarias necesarias. Deberá, igualmente, incluir los datos, hechos y observaciones en que se basen los dictámenes alcanzados y recomendaciones propuestas. [RD 1720/2007, artículo 96.2] En el caso de la Administración pública, existen algunos referentes fundamentales respecto de los cuales se puede y se debe realizar auditorías: •

Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.

•

Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. BOE de 29 de enero de 2010.

Las auditorías deben repetirse regularmente tanto para seguir la evolución del análisis de riesgos (que se debe actualizar regularmente) como para seguir el desarrollo del plan de seguridad determinado por las actividades de gestión de riesgos.

1.9. ¿Cuándo procede analizar y gestionar los riesgos? Un análisis de riesgos TIC es recomendable en cualquier Organización que dependa de los sistemas de información y comunicaciones para el cumplimiento de su misión. En particular en cualquier entorno donde se practique la tramitación electrónica de bienes y servicios, sea en contexto público o privado. El análisis de riesgos permite tomar decisiones de gestión y asignar recursos con perspectiva, sean tecnológicos, humanos o financieros. © Ministerio de Hacienda y Administraciones Públicas

página 16 (de 127)

Magerit 3.0

Introducción

El análisis de riesgos es una herramienta de gestión que permite tomar decisiones. Las decisiones pueden tomarse antes de desplegar un servicio o con éste funcionando. Es muy deseable hacerlo antes, de forma que las medidas que haya que tomar se incorporen en el diseño del servicio, en la elección de componentes, en el desarrollo del sistema y en los manuales de usuario. Todo lo que sea corregir riesgos imprevistos es costoso en tiempo propio y ajeno, lo que puede ir en detrimento de la imagen prestada por la Organización y puede suponer, en último extremo, la pérdida de confianza en su capacidad. Siempre se ha dicho que es mejor prevenir que curar y aquí se aplica: no espere a que un servicio haga agua; hay que prever y estar prevenido. Realizar un análisis de riesgos es laborioso y costoso. Levantar un mapa de activos y valorarlos requiere la colaboración de muchos perfiles dentro de la Organización, desde los niveles de gerencia hasta los técnicos. Y no solo es que haya que involucrar a muchas personas, sino que hay que lograr una uniformidad de criterio entre todos pues, si importante es cuantificar los riesgos, más importante aún es relativizarlos. Y esto es así porque típicamente en un análisis de riesgos aparecen multitud de datos. La única forma de afrontar la complejidad es centrarse en lo más importante (máximo impacto, máximo riesgo) y obviar lo que es secundario o incluso despreciable. Pero si los riesgos no están bien ordenados en términos relativos, su interpretación es imposible. En resumen, que un análisis de riesgos no es una tarea menor que realiza cualquiera en sus ratos libres. Es una tarea mayor que requiere esfuerzo y coordinación. Por tanto debe ser planificada y justificada.

Certificación y acreditación Si el sistema aspira a una certificación, el análisis de riesgos es un requisito previo que exigirá el evaluador. Es la fuente de información para determinar la relación de controles pertinentes para el sistema y que por tanto deben ser inspeccionados. Véase el apéndice 4.1 sobre certificación de sistemas de gestión de la seguridad de la información (SGSI). El análisis de riesgos es así mismo un requisito exigido en los procesos de acreditación 9 de sistemas. Estos procesos son necesarios cuando se va a manejar en el sistema información clasificada nacional, UE, OTAN o de otros acuerdos internacionales. El primer paso del proceso es la realización del análisis de riesgos que identifique amenazas y salvaguardas y gestione satisfactoriamente los riesgos del sistema.

Por precepto legal El análisis de riesgos puede venir requerido por precepto legal. Tal es el caso de Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. En el Capítulo II, Principios Básicos, se dice: Artículo 6. Gestión de la seguridad basada en los riesgos. 1. El análisis y gestión de riesgos será parte esencial del proceso de seguridad y deberá mantenerse permanentemente actualizado. 2. La gestión de riesgos permitirá el mantenimiento de un entorno controlado, minimizando los riesgos hasta niveles aceptables. La reducción de estos niveles se realizará mediante el despliegue de medidas de seguridad, que establecerá un equilibrio entre la naturaleza de los datos y los tratamientos, los riesgos a los que estén expuestos y las medidas de seguridad. El mismo Real Decreto 3/2010, en el Capítulo III, Requisitos Mínimos, se dice: Artículo 13. Análisis y gestión de los riesgos. 1. Cada organización que desarrolle e implante sistemas para el tratamiento de la información y las comunicaciones realizará su propia gestión de riesgos. 2. Esta gestión se realizará por medio del análisis y tratamiento de los riesgos a los que está expuesto el sistema. Sin perjuicio de lo dispuesto en el Anexo II, se empleará alguna metodología reconocida internacionalmente. 9 En el sentido formal de autorización para manejar información clasificada. Los procesos de acreditación se ajustan a la normativa aplicable en cada caso.

© Ministerio de Hacienda y Administraciones Públicas

página 17 (de 127)

Magerit 3.0

Introducción

3. Las medidas adoptadas para mitigar o suprimir los riesgos deberán estar justificadas y, en todo caso, existirá una proporcionalidad entre ellas y los riesgos. La Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, que en su Artículo 1, Objeto de la Ley, dice así: 2. Las Administraciones Públicas utilizarán las tecnologías de la información de acuerdo con lo dispuesto en la presente Ley, asegurando la disponibilidad, el acceso, la integridad, la autenticidad, la confidencialidad y la conservación de los datos, informaciones y servicios que gestionen en el ejercicio de sus competencias. La Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal, en su artículo 9 (Seguridad de los datos) dice así: 1. El responsable del fichero, y, en su caso, el encargado del tratamiento, deberán adoptar las medidas de índole técnica y organizativas necesarias que garanticen la seguridad de los datos de carácter personal y eviten su alteración, pérdida, tratamiento o acceso no autorizado, habida cuenta del estado de la tecnología, la naturaleza de los datos almacenados y los riesgos a que están expuestos, ya provengan de la acción humana o del medio físico o natural. Por último, la gestión continua de los riesgos es uno de los principio básicos del Esquema Nacional de Seguridad, ya citado anteriormente.

En conclusión Procede analizar y gestionar los riesgos cuando directa o indirectamente lo establezca un precepto legal y siempre que lo requiera la protección responsable de los activos de una organización.

© Ministerio de Hacienda y Administraciones Públicas

página 18 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

2. Visión de conjunto Hay dos grandes tareas a realizar: I. análisis de riesgos, que permite determinar qué tiene la Organización y estimar lo que podría pasar. II. tratamiento de los riesgos, que permite organizar la defensa concienzuda y prudente, defendiendo para que no pase nada malo y al tiempo estando preparados para atajar las emergencias, sobrevivir a los incidentes y seguir operando en las mejores condiciones; como nada es perfecto, se dice que el riesgo se reduce a un nivel residual que la Dirección asume. Ambas actividades, análisis y tratamiento se combinan en el proceso denominado Gestión de Riesgos.

Ilustración 5. Gestión de riesgos

El análisis de riesgos considera los siguientes elementos: 1. activos, que son los elementos del sistema de información (o estrechamente relacionados con este) que soportan la misión de la Organización 2. amenazas, que son cosas que les pueden pasar a los activos causando un perjuicio a la Organización 3. salvaguardas (o contra medidas), que son medidas de protección desplegadas para que aquellas amenazas no causen [tanto] daño. Con estos elementos se puede estimar: 1. el impacto: lo que podría pasar 2. el riesgo: lo que probablemente pase El análisis de riesgos permite analizar estos elementos de forma metódica para llegar a conclusiones con fundamento y proceder a la fase de tratamiento. Informalmente, se puede decir que la gestión de la seguridad de un sistema de información es la gestión de sus riesgos y que el análisis permite racionalizar dicha gestión.

© Ministerio de Hacienda y Administraciones Públicas

página 19 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Formalmente, la gestión de los riesgos está estructurada de forma metódica en las normas ISO (ver Anexo 1). Se propone el siguiente esquema:

Ilustración 6. Proceso de gestión de riesgos (fuente: ISO 31000)

La determinación del contexto lleva a una determinación de los parámetros y condicionantes externos e internos que permiten encuadrar la política que se seguirá para gestionar los riesgos. Un elemento a destacar es el alcance del análisis, incluyendo obligaciones propias y obligaciones contraídas, así como las relaciones con otras organizaciones, sean para intercambio de información y servicios o proveedoras de servicios subcontratados. Véase la norma [ISO 31000] para un mayor desarrollo de los factores que determinan el contexto. La identificación de los riesgos busca una relación de los posibles puntos de peligro. Lo que se identifique será analizado en la siguiente etapa. Lo que no se identifique quedará como riesgo oculto o ignorado. El análisis de los riesgos busca calificar los riesgos identificados, bien cuantificando sus consecuencias (análisis cuantitativo), bien ordenando su importancia relativa (análisis cualitativo). De una u otra forma, como resultado del análisis tendremos una visión estructurada que nos permita centrarnos en lo más importante. La evaluación de los ri esgos va un paso más allá del análisis técnico y traduce las consecuencias a términos de negocio. Aquí entran factores de percepción, de estrategia y de política permitiendo tomar decisiones respecto de qué riesgos se aceptan y cuales no, así como de en qué circunstancias podemos aceptar un riesgo o trabajar en su tratamiento. El tratamiento de los riesgos recopila las actividades encaminadas a modificar la situación de riesgo. Es una actividad que presenta numerosas opciones como veremos más adelante. Comunicación y consulta. Es importante no olvidar nunca que los sistemas de información deben ser soporte de la productividad de la Organización. Es absurdo un sistema muy seguro pero que impide que la Organización alcance sus objetivos. Siempre hay que buscar un equilibrio entre seguridad y productividad y en ese equilibrio hay que contar con la colaboración de varios interlocutores:

© Ministerio de Hacienda y Administraciones Públicas

página 20 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

•

los usuarios cuyas necesidades deben ser tenidas en cuenta y a los que hay que informar para que colaboren activamente en la operación del sistema dentro de los parámetros de seguridad determinados por la Dirección

•

los proveedores externos, a los que hay proporcionar instrucciones claras para poder exigirles tanto el cumplimiento de los niveles de servicio requeridos, como la gestión de los incidentes de seguridad que pudieran acaecer

•

los órganos de gobierno para establecer canales de comunicación que consoliden la confianza de que el sistema de información responderá sin sorpresas para atender a la misión de la Organización y que los incidentes serán atajados de acuerdo el plan previsto

Seguimiento y revisión. Es importante no olvidar nunca que el análisis de riesgos es una actividad de despacho y que es imprescindible ver qué ocurre en la práctica y actuar en consecuencia, tanto reaccionando diligentemente a los incidentes, como mejorando continuamente nuestro conocimiento del sistema y de su entorno para mejorar el análisis y ajustarlo a la experiencia.

© Ministerio de Hacienda y Administraciones Públicas

página 21 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

3. Método de análisis de riesgos 3.1. Conceptos paso a paso El análisis de riesgos es una aproximación metódica para determinar el riesgo siguiendo unos pasos pautados: 1. determinar los activos relevantes para la Organización, su interrelación y su valor, en el sentido de qué perjuicio (coste) supondría su degradación 2. determinar a qué amenazas están expuestos aquellos activos 3. determinar qué salvaguardas hay dispuestas y cuán eficaces son frente al riesgo 4. estimar el impacto, definido como el daño sobre el activo derivado de la materialización de la amenaza 5. estimar el riesgo, definido como el impacto ponderado con la tasa de ocurrencia (o expectativa de materialización) de la amenaza Con el objeto de organizar la presentación, se introducen los conceptos de “impacto y riesgo potenciales” entre los pasos 2 y 3. Estas valoraciones son “teóricas”: en el caso de que no hubiera salvaguarda alguna desplegada. Una vez obtenido este escenario teórico, se incorporan las salvaguardas del paso 3, derivando estimaciones realistas de impacto y riesgo. La siguiente figura recoge este primer recorrido, cuyos pasos se detallan en las siguientes secciones:

Ilustración 7. Elementos del análisis de riesgos potenciales

3.1.1. Paso 1: Activos Componente o funcionalidad de un sistema de información susceptible de ser atacado deliberada o accidentalmente con consecuencias para la organización. Incluye: información, datos, servicios, aplicaciones (software), equipos (hardware), comunicaciones, recursos administrativos, recursos físicos y recursos humanos. [UNE 71504:2008] En un sistema de información hay 2 cosas esenciales: — la información que maneja — y los servicios que presta. Estos activos esenciales marcan los requisitos de seguridad para todos los demás componentes del sistema. © Ministerio de Hacienda y Administraciones Públicas

página 22 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Subordinados a dicha esencia se pueden identificar otros activos relevantes: — Datos que materializan la información. — Servicios auxiliares que se necesitan para poder organizar el sistema. — Las aplicaciones informáticas (software) que permiten manejar los datos. — Los equipos informáti cos (hardware) y que permiten hospedar datos, aplicaciones y servicios. — Los soportes de información que son dispositivos de almacenamiento de datos. — El equipamiento auxiliar que complementa el material informático. — Las redes de comunicaciones que permiten intercambiar datos. — Las instalaciones que acogen equipos informáticos y de comunicaciones. — Las personas que explotan u operan todos los elementos anteriormente citados. No todos los activos son de la misma especie. Dependiendo del tipo de activo, las amenazas y las salvaguardas son diferentes 10 . El capítulo 2 del "Catálogo de Elementos" presenta una relación de tipos de activos.

Dependencias Los activos esenciales son la información y los servicios prestados; pero estos activos dependen de otros activos más prosaicos como pueden ser los equipos, las comunicaciones, las instalaciones y las frecuentemente olvidadas personas que trabajan con aquellos. De manera que los activos vienen a formar árboles o grafos de dependencias donde la seguridad de los activos que se encuentran más arriba en la estructura o ‘superiores’ depende de los activos que se encuentran más abajo o ‘inferiores’. Estas estructuras reflejan de arriba hacia abajo las dependencias, mientas que de abajo hacia arriba la propagación del daño caso de materializarse las amenazas. Por ello aparece como importante el concepto de “dependencias entre activos” o la medida en que un activo superior se vería afectado por un incidente de seguridad en un activo inferior 11 . Se dice que un “activo superior” depende de otro “activo inferior” cuando las necesidades de seguridad del superior se reflejan en las necesidades de seguridad del inferior. O, dicho en otras palabras, cuando la materialización de una amenaza en el activo inferior tiene como consecuencia un perjuicio sobre el activo superior. Informalmente puede interpretarse que los activos inferiores son los pilares en los que se apoya la seguridad de los activos superiores. Aunque en cada caso hay que adaptarse a la Organización objeto del análisis, con frecuencia se puede estructurar el conjunto de activos en capas, donde las capas superiores dependen de las inferiores: •

•

activos esenciales •

información que se maneja

•

servicios prestados

servicios internos •

•

que estructuran ordenadamente el sistema de información

el equipamiento informático •

aplicaciones (software)

10 No se ataca ni se defiende de la misma manera un servicio telemático que un local de trabajo. 11 Un ejemplo puede ser mejor que mil palabras. Si se quema el local que hospeda los equipos, lo que no funciona es el servicio percibido por el usuario a kilómetros de distancia. Si roban el portátil de un ejecutivo con información estratégica de la Organización, lo que sufre es la confidencialidad de dicha información. Las instalaciones se reconstruyen; pero puede haberse pasado la oportunidad de prestar el servicio. El robo se subsana comprando otro portátil; pero el secreto ya está perdido.

© Ministerio de Hacienda y Administraciones Públicas

página 23 (de 127)

Magerit 3.0

•

Proyectos de análisis de riesgos •

equipos informáticos (hardware)

•

comunicaciones

•

soportes de información: discos, cintas, etc.

el entorno: activos que se precisan para garantizar las siguientes capas •

equipamiento y suministros: energía, climatización, etc.

•

mobiliario

•

los servicios subcontratados a terceros

•

las instalaciones físicas

•

el personal •

usuarios

•

operadores y administradores

•

desarrolladores

Valoración ¿Por qué interesa un activo? Por lo que vale. No se está hablando de lo que cuestan las cosas, sino de lo que valen. Si algo no vale para nada, prescíndase de ello. Si no se puede prescindir impunemente de un activo, es que algo vale; eso es lo que hay que averiguar pues eso es lo que hay que proteger. La valoración se puede ver desde la perspectiva de la ‘necesidad de proteger’ pues cuanto más valioso es un activo, mayor nivel de protección requeriremos en la dimensión (o dimensiones) de seguridad que sean pertinentes. El valor puede ser propio, o puede ser acumulado. Se dice que los activos inferiores en un esquema de dependencias, acumulan el valor de los activos que se apoyan en ellos. El valor nuclear suele estar en la información que el si stema maneja y los servicios que se prestan (activos denominados esenciales), quedando los demás activos subordinados a las necesidades de explotación y protección de lo esencial. Por otra parte, los sistemas de información explotan los datos para proporcionar servicios, internos a la Organización o destinados a terceros, apareciendo una serie de datos necesarios para prestar un servicio. Sin entrar en detalles técnicos de cómo se hacen las cosas, el conjunto de información y servicios esenciales permite caracterizar funcionalmente una organización. Las dependencias entre activos permiten relacionar los demás activos con datos y servicios.

Dimensiones De un activo puede interesar calibrar diferentes dimensiones: •

su confidencialidad: ¿qué daño causaría que lo conociera quien no debe? Esta valoración es típica de datos.

•

su integridad: ¿qué perjuicio causaría que estuviera dañado o corrupto? Esta valoración es típica de los datos, que pueden estar manipulados, ser total o parcialmente falsos o, incluso, faltar datos.

•

su disponibilidad: ¿qué perjuicio causaría no tenerlo o no poder utilizarlo? Esta valoración es típica de los servicios 12 .

12 Hay servicios finales que materializan la misión última de la Organización. Hay servicios internos de los que la Organización se sirve para estructurar su propia distribución de responsabilidades. Por último, hay servicios que se adquieren de otras organizaciones: suministros externos.

© Ministerio de Hacienda y Administraciones Públicas

página 24 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

En sistemas dedicados a servicios de la sociedad de la información como puedan ser los de administración electrónica o comercio electrónico, el conocimiento de los actores es fundamental para poder prestar el servicio correctamente y poder perseguir los fallos (accidentales o deliberados) que pudieran darse. Así pues, en los activos esenciales, frecuentemente es útil valorar: •

la autenticidad: ¿qué perjuicio causaría no saber exactamente quien hace o ha hecho cada cosa? Esta valoración es típica de servicios (autenticidad del usuario) y de los datos (autenticidad de quien accede a los datos para escribir o, simplemente, consultar)

•

la trazabilidad del uso del servicio: ¿qué daño causaría no saber a quién se le presta tal servicio? O sea, ¿quién hace qué y cuándo?

•

la trazabilidad del acceso a los datos: ¿qué daño causaría no saber quién accede a qué datos y qué hace con ellos?

Se reconocen habitualmente como dimensiones básicas la confidencialidad, integridad y disponibilidad. En esta metodología se han añadido la autenticidad y el concepto de trazabilidad (del inglés, accountability), que a efectos técnicos se traducen en mantener la integridad y la confidencialidad de ciertos activos del sistema que pueden ser los servicios de directorio, las claves de firma digital, los registros de actividad, etc. El capítulo 3 del "Catálogo de Elementos" presenta una relación de dimensiones de seguridad. En un árbol de dependencias, donde los activos superiores dependen de los inferiores, es imprescindible valorar los activos superiores, los que son importantes por sí mismos. Automáticamente este valor se acumula en los inferiores, lo que no es óbice para que también puedan merecer, adicionalmente, su valoración propia.

¿Cuánto vale la “salud” de los activos? Una vez determinadas qué dimensiones (de seguridad) interesan de un activo hay que proceder a valorarlo. La valoración es la determinación del coste que supondría recuperarse de una incidencia que destrozara el activo. Hay muchos factores a considerar: •

coste de reposición: adquisición e instalación

•

coste de mano de obra (especializada) invertida en recuperar (el valor) del activo

•

lucro cesante: pérdida de ingresos

•

capacidad de operar: confianza de los usuarios y proveedores que se traduce en una pérdida de actividad o en peores condiciones económicas

•

sanciones por incumplimiento de la ley u obligaciones contractuales

•

daño a otros activos, propios o ajenos

•

daño a personas

•

daños medioambientales

La valoración puede ser cuantitativa (con una cantidad numérica) o cualitativa (en alguna escala de niveles). Los criterios más importantes a respetar son: •

la homogeneidad: es importante poder comparar valores aunque sean de diferentes dimensiones a fin de poder combinar valores propios y valores acumulados, así como poder determinar si es más grave el daño en una dimensión o en otra

•

la relatividad: es importante poder relativizar el valor de un activo en comparación con otros activos

Ambos criterios se satisfacen con valoraciones económicas (coste dinerario requerido para “curar” el activo) y es frecuente la tentación de ponerle precio a todo. Si se consigue, excelente. Incluso es fácil ponerle precio a los aspectos más tangibles (equipamiento, horas de trabajo, etc.); pero al entrar en valoraciones más abstractas (intangibles como la credibilidad de la Organización) la valoración económica exacta puede ser escurridiza y motivo de agrias disputas entre expertos. © Ministerio de Hacienda y Administraciones Públicas página 25 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

El capítulo 4 del "Catálogo de Elementos" presenta unas pautas para la valoración sistemática de activos.

Valoración cualitativa Las escalas cualitativas permiten avanzar con rapidez, posicionando el valor de cada activo en un orden relativo respecto de los demás. Es frecuente plantear estas escalas como “órdenes de magnitud” y, en consecuencia, derivar estimaciones del orden de magnitud del riesgo. La limitación de las valoraciones cualitativas es que no permiten comparar valores más allá de su orden relativo. No se pueden sumar valores. La "Guía de Técnicas" presenta un modelo de análisis basado en valoraciones cualitativas.

Valoración cuantitativa Las valoraciones numéricas absolutas cuestan mucho esfuerzo; pero permiten sumar valores numéricos de forma absolutamente “natural”. La interpretación de las sumas no es nunca motivo de controversia. Si la valoración es dineraria, además se pueden hacer estudios económicos comparando lo que se arriesga con lo que cuesta la solución respondiendo a las preguntas: •

¿Vale la pena invertir tanto dinero en esta salvaguarda?

•

¿Qué conjunto de salvaguardas optimizan la inversión?

•

¿En qué plazo de tiempo se recupera la inversión?

•

¿Cuánto es razonable que cueste la prima de un seguro?

La "Guía de Técnicas" presenta un modelo de análisis basado en valoraciones cuantitativas.

El valor de la interrupción del servicio Casi todas las dimensiones mencionadas anteriormente permiten una valoración simple, cualitativa o cuantitativa. Pero hay una excepción, la disponibilidad. No es lo mismo interrumpir un servicio una hora o un día o un mes. Puede que una hora de detención sea irrelevante, mientras que un día sin servicio causa un daño moderado; pero un mes detenido suponga la terminación de la actividad. Y lo malo es que no existe proporcionalidad entre el tiempo de interrupción y las consecuencias. En consecuencia, para valorar la [interrupción de la] disponibilidad de un activo hay que usar una estructura más compleja que se puede resumir en algún gráfico como el siguiente: 3

2

1

0 15m

30m

1h

2h

6h

1d

2d

1s

2s

1m

2m

6m

1a

total

Ilustración 8. Coste de la [interrupción de la] disponibilidad

donde aparece una serie de escalones de interrupción que terminan con la destrucción total o permanente del activo. En el ejemplo anterior, paradas de hasta 6 horas se pueden asumir sin consecuencias. Pero a las 6 horas se disparan las alarmas que aumentan si la parada supera los 2 días. Y si la parada supera el mes, se puede decir que la Organización ha perdido su capacidad de operar: ha muerto. Desde el punto de vista de los remedios, la gráfica dice directamente que no © Ministerio de Hacienda y Administraciones Públicas

página 26 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

hay que gastarse ni un euro por evitar paradas de menos de 6 horas. Vale la pena un cierto gasto por impedir que una parada supere las 6 horas o los 2 días. Y cuando se valore lo que cuesta impedir que la parada supera el mes, hay que poner en la balanza todo el valor de la Organización frente al coste de las salvaguardas. Pudiera ser que no valiera la pena.

3.1.2. Paso 2: Amenazas El siguiente paso consiste en determinar las amenazas que pueden afectar a cada activo. Las amenazas son “cosas que ocurren”. Y, de todo lo que puede ocurrir, interesa lo que puede pasarle a nuestros activos y causar un daño. Amenaza Causa potencial de un incidente que puede causar daños a un sistema de información o a una organización. [UNE 71504:2008]

Identificación de las amenazas El capítulo 5 del "Catálogo de Elementos" presenta una relación de amenazas típicas. De origen natural Hay accidentes naturales (terremotos, inundaciones, ...). Ante esos avatares el sistema de información es víctima pasiva, pero de todas formas tendremos en cuenta lo que puede suceder. Del entorno (de origen industrial) Hay desastres industriales (contaminación, fallos eléctricos, ...) ante los cuales el sistema de información es víctima pasiva; pero no por ser pasivos hay que permanecer indefensos. Defectos de las aplicaciones Hay problemas que nacen directamente en el equipamiento propio por defectos en su diseño o en su implementación, con consecuencias potencialmente negativas sobre el sistema. Frecuentemente se denominan vulnerabilidades técnicas o, simplemente, ‘vulnerabilidades’ 13 . Causadas por las personas de forma accidental Las personas con acceso al sistema de información pueden ser causa de problemas no intencionados, típicamente por error o por omisión. Causadas por las personas de forma deliberada Las personas con acceso al sistema de información pueden ser causa de problemas intencionados: ataques deliberados; bien con ánimo de beneficiarse indebidamente, bien con ánimo de causar daños y perjuicios a los legítimos propietarios. No todas las amenazas afectan a todos los activos 14 , sino que hay una cierta relación entre el tipo de activo y lo que le podría ocurrir.

Valoración de las amenazas Cuando un activo es víctima de una amenaza, no se ve afectado en todas sus dimensiones, ni en la misma cuantía. 13

14

Estos defectos se clasifican habitualmente bajo la taxonomía conocida como CVE (Common Vulnerability Enumeration), una norma internacional de facto. La mayor parte de estos defectos suelen afectar a aplicaciones software. Las instalaciones pueden incendiarse; pero las aplicaciones, no. Las personas pueden ser objeto de un ataque bacteriológico; pero los servicios, no. Sin embargo, los virus informáticos afectan a las aplicaciones, no a las personas.

© Ministerio de Hacienda y Administraciones Públicas

página 27 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Una vez determinado que una amenaza puede perjudicar a un activo, hay que valorar su influencia en el valor del activo, en dos sentidos: degradación: cuán perjudicado resultaría el [valor del] activo probabilidad: cuán probable o improbable es que se materialice la amenaza La degradación mide el daño causado por un incidente en el supuesto de que ocurriera. La degradación se suele caracterizar como una fracción del valor del activo y así aparecen expresiones como que un activo se ha visto “totalmente degradado”, o “degradado en una pequeña fracción”. Cuando las amenazas no son intencionales, probablemente baste conocer la fracción físicamente perjudicada de un activo para calcular la pérdida proporcional de valor que se pierde. Pero cuando la amenaza es intencional, no se puede pensar en proporcionalidad alguna pues el atacante puede causar muchísimo daño de forma selectiva. La probabilidad de ocurrencia es más compleja de determinar y de expresar. A veces se modela cualitativamente por medio de alguna escala nominal: MA muy alta

casi seguro

fácil

A

alta

muy alto

medio

M

media

posible

difícil

B

baja

poco probable muy difícil

MB muy baja muy raro

extremadamente difícil

Tabla 1. Degradación del valor

A veces se modela numéricamente como una frecuencia de ocurrencia. Es habitual usar 1 año como referencia, de forma que se recurre a la tasa anual de ocurrencia 15 como medida de la probabilidad de que algo ocurra. Son valores típicos: MA 100 muy frecuente

a diario

A

10

frecuente

mensualmente

M

1

normal

una vez al año

B

1/10 poco frecuente

cada varios años

MB 1/100 muy poco frecuente siglos Tabla 2. Probabilidad de ocurrencia

3.1.3. Determinación del impacto potencial Se denomina impacto a la medida del daño sobre el activo derivado de la materialización de una amenaza. Conociendo el valor de los activos (en varias dimensiones) y la degradación que causan las amenazas, es directo derivar el impacto que estas tendrían sobre el sistema. La única consideración que queda hacer es relativa a las dependencias entre activos. Es frecuente que el valor del sistema se centre en la información que maneja y los servicios que presta; pero las amenazas suelen materializarse en los medios. Para enlazar unos con otros recurriremos al grafo de dependencias.

Impacto acumulado Es el calculado sobre un activo teniendo en cuenta

15

•

su valor acumulado (el propio mas el acumulado de los activos que dependen de él)

•

las amenazas a que está expuesto

ARO – Annual Rate of Occurrence.

© Ministerio de Hacienda y Administraciones Públicas

página 28 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

El impacto acumulado se calcula para cada activo, por cada amenaza y en cada dimensión de valoración, siendo una función del valor acumulado y de la degradación causada. El impacto es tanto mayor cuanto mayor es el valor propio o acumulado sobre un activo. El impacto es tanto mayor cuanto mayor sea la degradación del activo atacado. El impacto acumulado, al calcularse sobre los activos que soportan el peso del sistema de información, permite determinar las salvaguardas de que hay que dotar a los medios de trabajo: protección de los equipos, copias de respaldo, etc.

Impacto repercutido Es el calculado sobre un activo teniendo en cuenta •

su valor propio

•

las amenazas a que están expuestos los activos de los que depende

El impacto repercutido se calcula para cada activo, por cada amenaza y en cada dimensión de valoración, siendo una función del valor propio y de la degradación causada. El impacto es tanto mayor cuanto mayor es el valor propio de un activo. El impacto es tanto mayor cuanto mayor sea la degradación del activo atacado. El impacto es tanto mayor cuanto mayor sea la dependencia del activo atacado. El impacto repercutido, al calcularse sobre los activos que tienen valor propio, permite determinar las consecuencias de las incidencias técnicas sobre la misión del sistema de información. Es pues una presentación gerencial que ayuda a tomar una de las decisiones críticas de un análisis de riesgos: aceptar un cierto nivel de riesgo.

Agregación de valores de impacto Los párrafos anteriores determinan el impacto que sobre un activo tendría una amenaza en una cierta dimensión. Estos impactos singulares pueden agregarse bajo ciertas condiciones: •

puede agregarse el impacto repercutido sobre diferentes activos,

•

puede agregarse el impacto acumulado sobre activos que no sean dependientes entre sí, y no hereden valor de un activo superior común,

•

no debe agregarse el impacto acumulado sobre activos que no sean independientes, pues ello supondría sobre ponderar el impacto al incluir varias veces el valor acumulado de activos superiores,

•

puede agregarse el impacto de diferentes amenazas sobre un mismo activo, aunque conviene considerar en qué medida las diferentes amenazas son independientes y pueden ser concurrentes,

•

puede agregarse el impacto de una amenaza en diferentes dimensiones.

3.1.4. Determinación del riesgo potencial Se denomina riesgo a la medida del daño probable sobre un sistema. Conociendo el impacto de las amenazas sobre los activos, es directo derivar el riesgo sin más que tener en cuenta la probabilidad de ocurrencia. El riesgo crece con el impacto y con la probabilidad, pudiendo distinguirse una serie de zonas a tener en cuenta en el tratamiento del riesgo (que veremos más adelante): •

zona 1 – riesgos muy probables y de muy alto impacto

•

zona 2 – franja amarilla: cubre un amplio rango desde situaciones improbables y de impacto medio, hasta situaciones muy probables pero de impacto bajo o muy bajo

© Ministerio de Hacienda y Administraciones Públicas

página 29 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

•

zona 3 – riesgos improbables y de bajo impacto

•

zona 4 – riesgos improbables pero de muy alto impacto

Ilustración 9. El riesgo en función del impacto y la probabilidad

Riesgo acumulado Es el calculado sobre un activo teniendo en cuenta •

el impacto acumulado sobre un activo debido a una amenaza y

•

la probabilidad de la amenaza

El riesgo acumulado se calcula para cada activo, por cada amenaza y en cada dimensión de valoración, siendo una función del valor acumulado, la degradación causada y la probabilidad de la amenaza. El riesgo acumulado, al calcularse sobre los activos que soportan el peso del sistema de información, permite determinar las salvaguardas de que hay que dotar a los medios de trabajo: protección de los equipos, copias de respaldo, etc.

Riesgo repercutido Es el calculado sobre un activo teniendo en cuenta •

el impacto repercutido sobre un activo debido a una amenaza y

•

la probabilidad de la amenaza

El riesgo repercutido se calcula para cada activo, por cada amenaza y en cada dimensión de valoración, siendo una función del valor propio, la degradación causada y la probabilidad de la amenaza. El riesgo repercutido, al calcularse sobre los activos que tienen valor propio, permite determinar las consecuencias de las incidencias técnicas sobre la misión del sistema de información. Es pues una presentación gerencial que ayuda a tomar una de las decisiones críticas de un análisis de riesgos: aceptar un cierto nivel de riesgo.

Agregación de riesgos Los párrafos anteriores determinan el riesgo que sobre un activo tendría una amenaza en una cierta dimensión. Estos riesgos singulares pueden agregarse bajo ciertas condiciones: • •

puede agregarse el riesgo repercutido sobre diferentes activos,

puede agregarse el impacto acumulado sobre activos que no sean dependientes entre sí, y no hereden valor de un activo superior común, © Ministerio de Hacienda y Administraciones Públicas página 30 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

•

no debe agregarse el riesgo acumulado sobre activos que no sean independientes, pues ello supondría sobre ponderar el riesgo al incluir varias veces el valor acumulado de activos superiores,

•

puede agregarse el riesgo de diferentes amenazas sobre un mismo activo, aunque conviene considerar en qué medida las diferentes amenazas son independientes y pueden ser concurrentes,

•

puede agregarse el riesgo de una amenaza en diferentes dimensiones.

3.1.5. Paso 3: Salvaguardas En los pasos anteriores no se han tomado en consideración las salvaguardas desplegadas. Se miden, por tanto, los impactos y riesgos a que estarían expuestos los activos si no se protegieran en absoluto. En la práctica no es frecuente encontrar sistemas desprotegidos: las medidas citadas indican lo que ocurriría si se retiraran las salvaguardas presentes. Se definen las salvaguardas o contra medidas como aquellos procedimientos o mecanismos tecnológicos que reducen el riesgo. Hay amenazas que se conjurar simplemente organizándose adecuadamente, otras requieres elementos técnicos (programas o equipos), otras seguridad física y, por último, está la política de personal. El capítulo 6 del "Catálogo de Elementos" presenta una relación de salvaguardas adecuadas para cada tipo de activos.

Selección de salvaguardas Ante el amplio abanico de posibles salvaguardas a considerar, es necesario hacer una criba inicial para quedarnos con aquellas que son relevantes para lo que hay que proteger. En esta criba se deben tener en cuenta los siguientes aspectos: 1. tipo de activos a proteger, pues cada tipo se protege de una forma específica 2. dimensión o dimensiones de seguridad que requieren protección 3. amenazas de las que necesitamos protegernos 4. si existen salvaguardas alternativas Además, es prudente establecer un principio de proporcionalidad y tener en cuenta: 1. el mayor o menor valor propio o acumulado sobre un activo, centrándonos en lo más valioso y obviando lo irrelevante 2. la mayor o menor probabilidad de que una amenaza ocurra, centrándonos en los riesgos más importantes (ver zonas de riesgo) 3. la cobertura del riesgo que proporcionan salvaguardas alternativas Esto lleva a dos tipos de declaraciones para excluir una cierta salvaguarda del conjunto de las que conviene analizar: •

no aplica – se dice cuando una salvaguarda no es de aplicación porque técnicamente no es adecuada al tipo de activos a proteger, no protege la dimensión necesaria o no protege frente a la amenaza en consideración

•

no se justif ica – se dice cuando la salvaguarda aplica, pero es desproporcionada al riesgo que tenemos que proteger

Como resultado de estas consideraciones dispondremos de una “declaración de aplicabilidad” o relación de salvaguardas que deben ser analizadas como componentes nuestro sistema de protección.

Efecto de las salvaguardas Las salvaguardas entran en el cálculo del riesgo de dos formas: © Ministerio de Hacienda y Administraciones Públicas

página 31 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Reduciendo la probabilidad de las amenazas. Se llaman salvaguardas preventivas. Las ideales llegan a impedir completamente que la amenaza se materialice. Limitando el daño causado. Hay salvaguardas que directamente limitan la posible degradación, mientras que otras permiten detectar inmediatamente el ataque para frenar que la degradación avance. Incluso algunas salvaguardas se limitan a permitir la pronta recuperación del sistema cuando la amenaza lo destruye. En cualquiera de las versiones, la amenaza se materializa; pero las consecuencias se limitan.

Ilustración 10. Elementos de análisis del riesgo residual

Tipo de protección Esta aproximación a veces resulta un poco simplificadora, pues es habitual hablar de diferentes tipos de protección prestados por las salvaguardas: [PR] prevención Diremos que una salvaguarda es preventiva cuando reduce las oportunidades de que un incidente ocurra. Si la salvaguarda falla y el incidente llega a ocurrir, los daños son los mismos. Ejemplos: autorización previa de los usuarios, gestión de privilegios, planificación de capacidades, metodología segura de desarrollo de software, pruebas en pre-producción, segregación de tareas, ... [DR] disuasión Diremos que una salvaguarda es disuasoria cuando tiene un efecto tal sobre los atacantes que estos no se atreven o se lo piensan dos veces antes de atacar. Son salvaguardas que actúan antes del incidente, reduciendo las probabilidades de que ocurra; pero que no tienen influencia sobre los daños causados caso de que el atacante realmente se atreva. Ejemplos: vallas elevadas, guardias de seguridad, avisos sobre la persecución del delito o persecución del delincuente, ...

© Ministerio de Hacienda y Administraciones Públicas

página 32 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

[EL] eliminación Diremos que una salvaguarda elimina un incidente cuando impide que éste tenga lugar. Son salvaguardas que actúan antes de que el incidente se haya producido. No reducen los daños caso de que la salvaguarda no sea perfecta y el incidente llegue a ocurrir. Ejemplos: eliminación de cuentas estándar, de cuentas sin contraseña, de servicios innecesarios, …; en general, todo lo que tenga que ver con la fortificación o bastionado, ..., cifrado de la información, ..., armarios ignífugos, ... [IM] minimización del impacto / limitación del impacto Se dice que una salvaguarda minimiza o limita el impacto cuando acota las consecuencias de un incidente. Ejemplos: desconexión de redes o equipos en caso de ataque, detención de servicios en caso de ataque, seguros de cobertura, cumplimiento de la legislación vigente [CR] corrección Diremos que una salvaguarda es correctiva cuando, habiéndose producido un daño, lo repara. Son salvaguardas que actúan después de que el incidente se haya producido y por tanto reducen los daños. Véase: recuperación más abajo. Ejemplos: gestión de incidentes, líneas de comunicación alternativas, fuentes de alimentación redundantes, ... [RC] recuperación Diremos que una salvaguarda ofrece recuperación cuando permite regresar al estado anterior al incidente. Son salvaguardas que no reducen las probabilidades del incidente, pero acotan los daños a un periodo de tiempo. Ejemplos: copias de seguridad (back-up) [MN] monitorización Son las salvaguardas que trabajan monitorizando lo que está ocurriendo o lo que ha ocurrido. Si se detectan cosas en tiempo real, podemos reaccionar atajando el incidente para limitar el impacto; si se detectan cosas a posteriori, podemos aprender del incidente y mejorar el sistema de salvaguardas de cara al futuro. Ejemplos: registros de actividad, registro de descargas de web, ... [DC] detección Diremos que una salvaguarda funciona detectando un ataque cuando informa de que el ataque está ocurriendo. Aunque no impide el ataque, sí permite que entren en operación otras medidas que atajen la progresión del ataque, minimizando daños. Ejemplos: anti-virus, IDS, detectores de incendio, ... [AW] concienciación Son las actividades de formación de las personas anexas al sistema que pueden tener una influencia sobre él. La formación reduce los errores de los usuarios, lo cual tiene un efecto preventivo. También mejora las salvaguardas de todo tipo pues los que las operan lo hacen con eficacia y rapidez, potenciando su efecto o, al menos, no menoscabándolo por una mala operación. Ejemplos: cursos de concienciación, cursos de formación, ... [AD] administración Se refiere a las salvaguardas relacionadas con los componentes de seguridad del sistema. Una buena administración evita el desconocimiento de lo que hay y por tanto impide que © Ministerio de Hacienda y Administraciones Públicas

página 33 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

hayan puertas desconocidas por las que pudiera tener éxito un ataque. En general pueden considerarse medidas de tipo preventivo. Ejemplos: inventario de activos, análisis de riesgos, plan de continuidad, ... La siguiente tabla relaciona cada uno de estos tipos de protección con el modelo anterior de reducción de la degradación y de la probabilidad: efecto

tipo

preventivas: reducen la probabilidad [PR] preventivas [DR] disuasorias [EL] eliminatorias acotan la degradación

[IM] minimizadoras [CR] correctivas [RC] recuperativas

consolidan el efecto de las demás

[MN] de monitorización [DC] de detección [AW] de concienciación [AD] administrativas

Tabla 3. Tipos de salvaguardas

Eficacia de la protección Las salvaguardas se caracterizan, además de por su existencia, por su eficacia frente al riesgo que pretenden conjurar. La salvaguarda ideal es 100% eficaz, eficacia que combina 2 factores: desde el punto de vista técnico •

es técnicamente idónea para enfrentarse al riesgo que protege

•

se emplea siempre

desde el punto de vista de operación de la salvaguarda •

está perfectamente desplegada, configurada y mantenida

•

existen procedimientos claros de uso normal y en caso de incidencias

•

los usuarios están formados y concienciados

•

existen controles que avisan de posibles fallos

Entre una eficacia del 0% para aquellas que faltan y el 100% para aquellas que son idóneas y que están perfectamente implantadas, se estimará un grado de eficacia real en cada caso concreto. Para medir los aspectos organizativos, se puede emplear una escala de madurez que recoja en forma de factor corrector la confianza que merece el proceso de gestión de la salvaguarda: factor 0%

100%

nivel significado L0

inexistente

L1

inicial / ad hoc

L2

reproducible, pero intuitivo

L3

proceso definido

L4

gestionado y medible

L5

optimizado

Tabla 4. Eficacia y madurez de las salvaguardas

© Ministerio de Hacienda y Administraciones Públicas

página 34 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Vulnerabilidades Se denomina vulnerabilidad a toda debilidad que puede ser aprovechada por una amenaza, o más detalladamente a las debilidades de los activos o de sus medidas de protección que facilitan el éxito de una amenaza potencial. Traducido a los términos empleados en los párrafos anteriores, son vulnerabilidades todas las ausencias o ineficacias de las salvaguardas pertinentes para salvaguardar el valor propio o acumulado sobre un activo. A veces se emplea el término “insuficiencia” para resaltar el hecho de que la eficacia medida de la salvaguarda es insuficiente para preservar el valor del activo expuesto a una amenaza.

3.1.6. Paso 4: impacto residual Dado un cierto conjunto de salvaguardas desplegadas y una medida de la madurez de su proceso de gestión, el sistema queda en una situación de posible impacto que se denomina residual. Se dice que hemos modificado el impacto, desde un valor potencial a un valor residual. El cálculo del impacto residual es sencillo. Como no han cambiado los activos, ni sus dependencias, sino solamente la magnitud de la degradación, se repiten los cálculos de impacto con este nuevo nivel de degradación. La magnitud de la degradación tomando en cuenta la eficacia de las salvaguardas, es la proporción que resta entre la eficacia perfecta y la eficacia real. El impacto residual puede calcularse acumulado sobre los activos inferiores, o repercutido sobre los activos superiores.

3.1.7. Paso 5: riesgo residual Dado un cierto conjunto de salvaguardas desplegadas y una medida de la madurez de su proceso de gestión, el sistema queda en una situación de riesgo que se denomina residual. Se dice que hemos modificado el riesgo, desde un valor potencial a un valor residual. El cálculo del riesgo residual es sencillo. Como no han cambiado los activos, ni sus dependencias, sino solamente la magnitud de la degradación y la probabilidad de las amenazas, se repiten los cálculos de riesgo usando el impacto residual y la probabilidad residual de ocurrencia. La magnitud de la degradación se toma en consideración en el cálculo del impacto residual. La magnitud de la probabilidad residual tomando en cuenta la eficacia de las salvaguardas, es la proporción que resta entre la eficacia perfecta y la eficacia real. El riesgo residual puede calcularse acumulado sobre los activos inferiores, o repercutido sobre los activos superiores.

3.2. Formalización de las actividades Este conjunto de actividades tiene los siguientes objetivos: •

Levantar un modelo del valor del sistema, identificando y valorando los activos relevantes.

•

Levantar un mapa de riesgos del sistema, identificando y valorando las amenazas sobre aquellos activos.

•

Levantar un conocimiento de la situación actual de salvaguardas.

•

Evaluar el impacto posible sobre el sistema en estudio, tanto el impacto potencial (sin salvaguardas), como el impacto residual (incluyendo el efecto de las salvaguardas desplegadas para proteger el sistema).

•

Evaluar el riesgo del sistema en estudio, tanto el riesgo potencial (sin salvaguardas), como el riesgo residual (incluyendo el efecto de las salvaguardas desplegadas para proteger el sistema).

© Ministerio de Hacienda y Administraciones Públicas

página 35 (de 127)

Magerit 3.0 •

Proyectos de análisis de riesgos

Informar de las áreas del sistema con mayor impacto y/o riesgo a fin de que se puedan tomar las decisiones de tratamiento con motivo justificado.

El análisis de los riesgos se lleva a cabo por medio de las siguientes tareas: MAR – Método de Análisis de Riesgos MAR.1 – Caracterización de los activos MAR.11 – Identificación de los activos MAR.12 – Dependencias entre activos MAR.13 – Valoración de los activos MAR.2 – Caracterización de las amenazas MAR.21 – Identificación de las amenazas MAR.22 – Valoración de las amenazas MAR.3 – Caracterización de las salvaguardas MAR.31 – Identificación de las salvaguardas pertinentes MAR.32 – Valoración de las salvaguardas MAR.4 – Estimación del estado de riesgo MAR.41 – Estimación del impacto MAR.42 – Estimación del riesgo

MAR.1: Caracterización de los activos Esta actividad busca identificar los activos relevantes dentro del sistema a analizar, caracterizándolos por el tipo de activo, identificando las relaciones entre los diferentes activos, determinando en qué dimensiones de seguridad son importantes y valorando esta importancia. El resultado de esta actividad es el informe denominado “modelo de valor”. Sub-tareas: Tarea MAR.11: Identificación de los activos Tarea MAR.12: Dependencias entre activos Tarea MAR.13: Valoración de los activos

MAR.2: Caracterización de las amenazas Esta actividad busca identificar las amenazas relevantes sobre el sistema a analizar, caracterizándolas por las estimaciones de ocurrencia (probabilidad) y daño causado (degradación). El resultado de esta actividad es el informe denominado “mapa de riesgos”. Sub-tareas: Tarea MAR.21: Identificación de las amenazas Tarea MAR.22: Valoración de las amenazas

MAR.3: Caracterización de las salvaguardas Esta actividad busca identificar las salvaguardas desplegadas en el sistema a analizar, calificándolas por su eficacia frente a las amenazas que pretenden mitigar. El resultado de esta actividad se concreta en varios informes: — declaración de aplicabilidad — evaluación de salvaguardas — insuficiencias (o vulnerabilidades del sistema de protección) © Ministerio de Hacienda y Administraciones Públicas

página 36 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Sub-tareas: Tarea MAR.31: Identificación de las salvaguardas pertinentes Tarea MAR.32: Valoración de las salvaguardas

MAR.4: Estimación del estado de riesgo Esta actividad procesa todos los datos recopilados en las actividades anteriores para •

realizar un informe del estado de riesgo: estimación de impacto y riesgo

•

realizar un informe de insuficiencias: deficiencias o debilidades en el sistema de salvaguardas

Sub-tareas: Tarea MAR.41: Estimación del impacto Tarea MAR.42: Estimación del riesgo Es frecuente que las tareas relacionadas con los activos (MAR.1) se realicen concurrentemente con las tareas relacionadas con las amenazas sobre dichos activos (MAR.2) e identificación de las salvaguardas actuales (MAR.3), simplemente porque suelen coincidir las personas y es difícil que el interlocutor no tienda de forma natural a tratar cada activo “verticalmente”, viendo todo lo que le afecta antes de pasar al siguiente.

3.2.1. Tarea MAR.1: Caracterización de los activos Esta actividad consta de tres sub-tareas: MAR.11: Identificación de los activos MAR.12: Dependencias entre activos MAR.13: Valoración de los activos El objetivo de estas tareas es reconocer los activos que componen el sistema, definir las dependencias entre ellos, y determinar que parte del valor del sistema se soporta en cada activo. Podemos resumirlo en la expresión “conócete a ti mismo”. MAR: Análisis de riesgos MAR.1: Caracterización de los activos MAR.11: Identificación de los activos Objetivos •

Identificar los activos que componen el sistema, determinando sus características, atributos y clasificación en los tipos determinados

Productos de entrada •

Inventario de datos manejados por el sistema

•

Inventario de servicios prestados por el sistema

•

Procesos de negocio

•

Diagramas de uso

•

Diagramas de flujo de datos

•

Inventarios de equipamiento lógico

•

Inventarios de equipamiento físico

•

Locales y sedes de la Organización

•

Caracterización funcional de los puestos de trabajo

© Ministerio de Hacienda y Administraciones Públicas

página 37 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

MAR: Análisis de riesgos MAR.1: Caracterización de los activos MAR.11: Identificación de los activos Productos de salida •

Relación de activos a considerar

•

Caracterización de los activos: valor propio y acumulado

•

Relaciones entre activos

Técnicas, prácticas y pautas •

Ver “Libro II – Catálogo”.

•

Diagramas de flujo de datos

•

Diagramas de procesos

•

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

Esta tarea es crítica. Una buena identificación es importante desde varios puntos de vista: •

materializa con precisión el alcance del proyecto

•

permite las interlocución con los grupos de usuarios: todos hablan el mismo lenguaje

•

permite determinar las dependencias precisas entre activos

•

permite valorar los activos con precisión

•

permite identificar y valorar las amenazas con precisión

•

permite determinar qué salvaguardas serán necesarias para proteger el sistema

Caracterización de los activos Para cada activo hay que determinar una serie de características que lo definen: •

código, típicamente procedente del inventario

•

nombre (corto)

•

descripción (larga)

•

tipo (o tipos) que caracterizan el activo

•

unidad responsable. A veces hay más de una unidad. Por ejemplo, en el caso de aplicaciones cabe diferenciar entre la unidad que la mantiene y la que la explota.

•

persona responsable. Especialmente relevante en el caso de datos. A veces hay más de un responsable. Por ejemplo en caso de datos de carácter personal cabe diferenciar entre el responsable del dato y el operador u operadores que lo manejan.

•

ubicación, técnica (en activos intangibles) o geográfica (en activos materiales)

•

cantidad, si procede como puede ser en el caso de la informática personal (por ejemplo 350 equipos de sobremesa)

•

otras características específicas del tipo de activo

© Ministerio de Hacienda y Administraciones Públicas

página 38 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

MAR: Análisis de riesgos MAR.1: Caracterización de los activos MAR.12: Dependencias entre activos Objetivos • Identificar y valorar las dependencias entre activos, es decir la medida en que un activo de orden superior se puede ver perjudicado por una amenaza materializada sobre un activo de orden inferior Productos de entrada • Resultados de la tarea T1.2.1, Identificación • Procesos de negocio • Diagramas de flujo de datos • Diagramas de uso Productos de salida • Diagrama de dependencias entre activos Técnicas, prácticas y pautas • Diagramas de flujo de datos • Diagramas de procesos • Entrevistas (ver "Guía de Técnicas") • Reuniones • Valoración Delphi (ver "Guía de Técnicas") Para cada dependencia conviene registrar la siguiente información: •

estimación del grado de dependencia: hasta un 100%

•

explicación de la valoración de la dependencia

•

entrevistas realizadas de las que se ha deducido la anterior estimación

MAR: Análisis de riesgos MAR.1: Caracterización de los activos MAR.13: Valoración de los activos Objetivos •

Identificar en qué dimensión es valioso el activo

•

Valorar el coste que para la Organización supondría la destrucción del activo

Productos de entrada •

Resultados de la tarea MAR.11, Identificación de los activos

•

Resultados de la tarea MAR.12, Dependencias entre activos

Productos de salida •

Modelo de valor: informe de valor de los activos

Técnicas, prácticas y pautas •

Ver “Libro II – Catálogo”.

•

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

Valoración Delphi (ver "Guía de Técnicas")

© Ministerio de Hacienda y Administraciones Públicas

página 39 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Para la adquisición de este conocimiento puede ser necesario entrevistar a diferentes colectivos dentro de la Organización: •

dirección o gerencia, que conocen las consecuencias para la misión de la Organización

•

responsables de los datos, que conocen las consecuencias de sus fallos de seguridad

•

responsables de los servicios, que conocen las consecuencias de la no prestación del servicio o de su prestación degradada

•

responsables de sistemas de información y responsables de operación, que conocen las consecuencias de un incidente

Para cada valoración conviene registrar la siguiente información: •

dimensiones en las que el activo es relevante

•

estimación de la valoración en cada dimensión

•

explicación de la valoración

•

entrevistas realizadas de las que se han deducido las anteriores estimaciones

3.2.2. Tarea MAR.2: Caracterización de las amenazas Esta actividad consta de dos sub-tareas: MAR.21: Identificación de las amenazas MAR.22: Valoración de las amenazas El objetivo de estas tareas es caracterizar el entorno al que se enfrenta el sistema, qué puede pasar, qué consecuencias se derivarían y cómo de probable es que pase. Podemos resumirlo en la expresión “conoce a tu enemigo”. MAR: Análisis de riesgos MAR.2: Caracterización de las amenazas MAR.21: Identificación de las amenazas Objetivos •

Identificar las amenazas relevantes sobre cada activo

Productos de entrada •

Resultados de la actividad MAR.1, Caracterización de los activos

•

Informes relativos a defectos en los productos. Esto es, informes de vulnerabilidades.

Productos de salida •

Relación de amenazas posibles

Técnicas, prácticas y pautas •

Catálogos de amenazas (ver "Catálogo de Elementos")

•

Árboles de ataque (ver "Guía de Técnicas")

•

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

Valoración Delphi (ver "Guía de Técnicas")

En esta tarea se identifican las amenazas significativas sobre los activos identificados, tomando en consideración: © Ministerio de Hacienda y Administraciones Públicas

página 40 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

•

el tipo de activo

•

las dimensiones en que el activo es valioso

•

la experiencia de la Organización

•

los defectos reportados por los fabricantes y organismos de respuesta a incidentes de seguridad (CERTS)

Para cada amenaza sobre cada activo conviene registrar la siguiente información: •

explicación del efecto de la amenaza

•

entrevistas realizadas de las que se ha deducido la anterior estimación

•

antecedentes, si los hubiera, bien en la propia Organización, bien en otras organizaciones que se haya considerado relevantes

MAR: Análisis de riesgos MAR.2: Caracterización de las amenazas MAR.22: Valoración de las amenazas Objetivos •

Estimar la frecuencia de ocurrencia de cada amenaza sobre cada activo

•

Estimar la degradación que causaría la amenaza en cada dimensión del activo si llegara a materializarse

Productos de entrada •

Resultados de la tarea MAR2.1, Identificación de las amenazas

•

Series históricas de incidentes

•

Informes de defectos en los productos

•

Antecedentes: incidentes en la Organización

Productos de salida •

Mapa de riesgos: informe de amenazas posibles, caracterizadas por su frecuencia de ocurrencia y la degradación que causarían en los activos

Técnicas, prácticas y pautas •

Árboles de ataque (ver "Guía de Técnicas")

•

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

Valoración Delphi (ver "Guía de Técnicas")

En esta tarea se valoran las amenazas identificadas en la tarea anterior, tomando en consideración: •

la experiencia (historia) universal

•

la experiencia (historia) del sector de actividad

•

la experiencia (historia) del entorno en que se ubican los sistemas

•

la experiencia (historia) de la propia Organización

•

los informes anexos a los reportes de defectos proporcionados por los fabricantes y organismos de respuesta a incidentes de seguridad (CERTS)

Sabiendo que existen una serie de posibles agravantes, como se describe en la sección X. © Ministerio de Hacienda y Administraciones Públicas

página 41 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Para cada amenaza sobre cada activo conviene registrar la siguiente información: •

estimación de la frecuencia de la amenaza

•

estimación del daño (degradación) que causaría su materialización

•

explicación de las estimaciones de frecuencia y degradación

•

entrevistas realizadas de las que se han deducido las anteriores estimaciones

3.2.3. Tarea MAR.3: Caracterización de las salvaguardas Esta actividad consta de dos sub-tareas: MAR.31: Identificación de las salvaguardas pertinentes MAR.32: Valoración de las salvaguardas El objetivo de estas tareas es doble: saber qué necesitamos para proteger el sistema y saber si tenemos un sistema de protección a la altura de nuestras necesidades. MAR: Análisis de riesgos MAR.3: Caracterización de las salvaguardas MAR.31: Identificación de las salvaguardas pertinentes Objetivos •

Identificar las salvaguardas convenientes para proteger el sistema

Productos de entrada •

modelo de activos del sistema

•

modelo de amenazas del sistema

•

indicadores de impacto y riesgo residual

•

informes de productos y servicios en el mercado

Productos de salida •

Declaración de aplicabilidad: relación justificada de las salvaguardas necesarias

•

Relación de salvaguardas desplegadas

Técnicas, prácticas y pautas •

Catálogos de salvaguardas (ver "Catálogo de Elementos")

•

Árboles de ataque (ver "Guía de Técnicas")

•

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

Para cada salvaguarda conviene registrar la siguiente información: •

descripción de la salvaguarda y su estado de implantación

•

descripción de las amenazas a las que pretende hacer frente

•

entrevistas realizadas de las que se ha deducido la anterior información

Para determinar las salvaguardas pertinentes es frecuente recurrir a catálogos de salvaguardas o al consejo de personas expertas. De una u otra forma dispondremos de una colección de salvaguardas para elegir, de forma que el complejo problema de encontrar lo que necesitamos se reduce al problema más sencillo de descartar lo que no necesitamos. © Ministerio de Hacienda y Administraciones Públicas

página 42 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

En el proceso de descarte hay varias razones para eliminar una salvaguarda propuesta: •

porque no es apropiada para el activo que necesitamos defender

•

porque no es apropiada para la dimensión de seguridad que necesitamos defender

•

porque no es efectiva oponiéndose a la amenaza que necesitamos contrarrestar

•

porque es excesiva para el valor que tenemos que proteger (desproporcionada)

•

porque disponemos de medidas alternativas

MAR: Análisis de riesgos MAR.3: Caracterización de las salvaguardas MAR.32: Valoración de las salvaguardas Objetivos •

Determinar la eficacia de las salvaguardas pertinentes

Productos de entrada •

Inventario de salvaguardas derivado de la tarea MAR.31

Productos de salida •

Evaluación de salvaguardas : informe de salvaguardas desplegadas, caracterizadas por su grado de efectividad

•

Informe de insuficien cias (o vul nerabilidades): relación de salvaguardas que deberían estar pero no están desplegadas o están desplegadas de forma insuficiente

Técnicas, prácticas y pautas •

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

Valoración Delphi (ver "Guía de Técnicas")

En esta tarea se valora la efectividad de las salvaguardas identificadas en la tarea anterior, tomando en consideración: •

la idoneidad de la salvaguarda para el fin perseguido

•

la calidad de la implantación

•

la formación de los responsables de su configuración y operación

•

la formación de los usuarios, si tienen un papel activo

•

la existencia de controles de medida de su efectividad

•

la existencia de procedimientos de revisión regular

Para cada salvaguarda conviene registrar la siguiente información: •

estimación de su eficacia para afrontar aquellas amenazas

•

explicación de la estimación de eficacia

•

entrevistas realizadas de las que se ha deducido la anterior estimación

© Ministerio de Hacienda y Administraciones Públicas

página 43 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

3.2.4. Tarea MAR.4: Estimación del estado de riesgo En esta tarea se combinan los descubrimientos de las tareas anteriores (MAR.1, MAR.2 y MAR.3) para derivar estimaciones del estado de riesgo de la Organización. Esta actividad consta de tres tareas: MAR.41: Estimación del impacto MAR.42: Estimación del riesgo El objetivo de estas tareas es disponer de una estimación fundada de lo que puede ocurrir (impacto) y de lo que probablemente ocurra (riesgo). MAR: Análisis de riesgos MAR.4: Estimación del estado de riesgo MAR.41: Estimación del impacto Objetivos • Determinar el impacto potencial al que está sometido el sistema • Determinar el impacto residual al que está sometido el sistema Productos de entrada • Resultados de la actividad MAR.1, Caracterización de los activos • Resultados de la actividad MAR.2, Caracterización de las amenazas • Resultados de la actividad MAR.3, Caracterización de las salvaguardas Productos de salida • Informe de impacto (potencial) por activo • Informe de impacto residual por activo Técnicas, prácticas y pautas • Análisis mediante tablas (ver "Guía de Técnicas") • Análisis algorítmico (ver "Guía de Técnicas") En esta tarea se estima el impacto al que están expuestos los activos del sistema: •

el impacto potencial, al que está expuesto el sistema teniendo en cuenta el valor de los activos y la valoración de las amenazas; pero no las salvaguardas actualmente desplegadas

•

el impacto residual, al que está expuesto el sistema teniendo en cuenta el valor de los activos y la valoración de las amenazas, así como la eficacia de las salvaguardas actualmente desplegadas

MAR: Análisis de riesgos MAR.4: Estimación del estado de riesgo MAR.42: Estimación del riesgo Objetivos • Determinar el riesgo potencial al que está sometido el sistema • Determinar el riesgo residual al que está sometido el sistema Productos de entrada • Resultados de la actividad MAR.1, Caracterización de los activos • Resultados de la actividad MAR.2, Caracterización de las amenazas • Resultados de la actividad MAR.3, Caracterización de las salvaguardas • Resultados de la actividad MAR.4, Estimaciones de impacto © Ministerio de Hacienda y Administraciones Públicas

página 44 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

MAR: Análisis de riesgos MAR.4: Estimación del estado de riesgo MAR.42: Estimación del riesgo Productos de salida • Informe de riesgo (potencial) por activo • Informe de riesgo residual por activo Técnicas, prácticas y pautas • Análisis mediante tablas (ver "Guía de Técnicas") • Análisis algorítmico (ver "Guía de Técnicas") En esta tarea se estima el riesgo al que están sometidos los activos del sistema: •

el riesgo potencial, al que está sometido el sistema teniendo en cuenta el valor de los activos y la valoración de las amenazas; pero no las salvaguardas actualmente desplegadas

•

el riesgo residual, al que está sometido el sistema teniendo en cuenta el valor de los activos y la valoración de las amenazas, así como la eficacia de las salvaguardas actualmente desplegadas

3.3. Documentación Documentación intermedia •

Resultados de las entrevistas.

•

Documentación de otras fuentes: estadísticas, observaciones de expertos y observaciones de los analistas.

•

Información existente utilizable por el proyecto (por ejemplo inventario de activos)

•

Documentación auxiliar: planos, organigramas, requisitos, especificaciones, análisis funcionales, cuadernos de carga, manuales de usuario, manuales de explotación, diagramas de flujo de información y de procesos, modelos de datos, etc.

•

Informes y evaluaciones de defectos de los productos, procedentes de fabricantes o de centros de respuesta a incidentes de seguridad (CERTs).

Documentación final •

Modelo de valor Informe que detalla los activos, sus dependencias, las dimensiones en las que son valiosos y la estimación de su valor en cada dimensión.

•

Mapa de riesgos: Informe que detalla las amenazas significativas sobre cada activo, caracterizándolas por su frecuencia de ocurrencia y por la degradación que causaría su materialización sobre el activo.

•

Declaración de aplicabilidad: Informe que recoge las contramedidas que se consideran apropiadas para defender el sistema de información bajo estudio.

•

Evaluación de salvaguardas: Informe que detalla las salvaguardas existentes calificándolas en su eficacia para reducir el riesgo que afrontan.

•

Informe de insuficiencias o vulnerabilidades:

Informe que detalla las salvaguardas necesarias pero ausentes o insuficientemente eficaces. © Ministerio de Hacienda y Administraciones Públicas página 45 (de 127)

Magerit 3.0 •

Proyectos de análisis de riesgos

Estado de riesgo: Informe que detalla para cada activo el impacto y el riesgo, potenciales y residuales, frente a cada amenaza.

Esta documentación es un fiel reflejo del estado de riesgo y de las razones por la que este riesgo no es aceptable. Es fundamental entender las razones que llevan a una valoración determinada de riesgo para que el proceso de gestión de riesgos esté bien fundamentado. El proceso de gestión de riesgos partirá de estas valoraciones para atajar el riesgo o reducirlo a niveles aceptables.

3.4. Lista de control √ actividad

tarea

Se han identificado los activos esenciales: información que se trata y servicios que se prestan

MAR.11

Se han valorado las necesidades o niveles de seguridad requeridos por cada activo esencial en cada dimensión de seguridad

MAR.13

Se han identificado los demás activos del sistema

MAR.11

Se han establecido el valor (o nivel requerido de seguridad) de los demás activos en función de su relación con los activos esenciales (por ejemplo, mediante identificación de las dependencias)

MAR.12

Se han identificado las amenazas posibles sobre los activos

MAR.21

Se han estimado las consecuencias que se derivarían de la materialización de dichas amenazas

MAR.22

Se ha estimado la probabilidad de que dichas amenazas se materialicen

MAR.23

Se han estimado los impactos y riesgos potenciales, inherentes al sistema

MAR.4

Se han identificado las salvaguardas apropiadas para atajar los impactos y riesgos potenciales

MAR.31

Se ha valorado el despliegue de las salvaguardas identificadas

MAR.32

Se han estimado los valores de impacto y riesgo residuales, que es el nivel de impacto y riesgo que aún soporta el sistema tras el despliegue de las salvaguardas

MAR.4

© Ministerio de Hacienda y Administraciones Públicas

página 46 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

4. Proceso de gestión de riesgos A la vista de los impactos y riesgos a que está expuesto el sistema, hay que tomar una serie de decisiones condicionadas por diversos factores: •

la gravedad del impacto y/o del riesgo

•

las obligaciones a las que por ley esté sometida la Organización

•

las obligaciones a las que por reglamentos sectoriales esté sometida la Organización

•

las obligaciones a las que por contrato esté sometida la Organización

Dentro del margen de maniobra que permita este marco, pueden aparecer consideraciones adicionales sobre la capacidad de la Organización para aceptar ciertos impactos de naturaleza intangible 16 tales como: •

imagen pública de cara a la Sociedad (aspectos reputacionales)

•

política interna: relaciones con los propios empleados, tales como capacidad de contratar al personal idóneo, capacidad de retener a los mejores, capacidad de soportar rotaciones de personas, capacidad de ofrecer una carrera profesional atractiva, etc.

•

relaciones con los proveedores, tales como capacidad de llegar a acuerdos ventajosos a corto, medio o largo plazo, capacidad de obtener trato prioritario, etc.

•

relaciones con los clientes o usuarios, tales como capacidad de retención, capacidad de incrementar la oferta, capacidad de diferenciarse frente a la competencia, ...

•

relaciones con otras organizaciones, tales como capacidad de alcanzar acuerdos estratégicos, alianzas, etc.

•

nuevas oportunidades de negocio, tales como formas de recuperar la inversión en seguridad

•

acceso a sellos o calificaciones reconocidas de seguridad

Todas las consideraciones anteriores desembocan en una calificación de cada riesgo significativo, determinándose si ... 1. es crítico en el sentido de que requiere atención urgente 2. es grave en el sentido de que requiere atención 3. es apreciable en el sentido de que pueda ser objeto de estudio para su tratamiento 4. es asumible en el sentido de que no se van a tomar acciones para atajarlo La opción 4, aceptación del riesgo, siempre es arriesgada y hay que tomarla con prudencia y justificación. Las razones que pueden llevar a esta aceptación son: •

cuando el impacto residual es asumible

•

cuando el riesgo residual es asumible

•

cuando el coste de las salvaguardas oportunas es desproporcionado en comparación al impacto y riesgo residuales

La calificación de los riesgos tendrá consecuencias en las tareas subsiguientes, siendo un factor básico para establecer la prioridad relativa de las diferentes actuaciones.

16 La metodología de análisis y gestión de riesgos, al centrarse en la evaluación de daños, no captura plenamente los beneficios de la ausencia de daños que, generando un ambiente de confianza, permite un mejor desempeño de las funciones de la Organización en su entorno de operación.

© Ministerio de Hacienda y Administraciones Públicas

página 47 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

4.1. Conceptos El análisis de riesgos determina impactos y riesgos. Los impactos recogen daños absolutos, independientemente de que sea más o menos probable que se dé la circunstancia. En cambio, el riesgo pondera la probabilidad de que ocurra. El impacto refleja el daño posible (lo peor que puede ocurrir), mientras que el riesgo refleja el daño probable (lo que probablemente ocurra). El resultado del análisis es sólo un análisis. A partir de el disponemos de información para tomar decisiones conociendo lo que queremos proteger (activos valorados=, de qué lo queremos proteger (amenazas valoradas) y qué hemos hecho por protegerlo (salvaguardas valoradas). Todo ello sintetizado en los valores de impacto y riesgo. A partir de aquí, las decisiones son de los órganos de gobierno de la Organización que actuarán en 2 pasos: •

paso 1: evaluación

•

paso 2: tratamiento

La siguiente figura resume las posibles decisiones que se pueden tomar tras haber estudiado los riesgos. La caja ‘estudio de los riesgos’ pretende combinar el análisis con la evaluación.

Ilustración 11. Decisiones de tratamiento de los riesgos

Todos estos aspectos se desarrollan en las secciones siguientes.

4.1.1. Evaluación: interpretación de los valores de impacto y riesgo residuales Impacto y riesgo residual son una medida del estado presente, entre la inseguridad potencial (sin salvaguarda alguna) y las medidas adecuadas que reducen impacto y riesgo a valores aceptables. Los párrafos siguientes se refieren conjuntamente a impacto y riesgo. Si el valor residual es igual al valor potencial, las salvaguardas existentes no valen para nada, típicamente no porque no haya nada hecho, sino porque hay elementos fundamentales sin hacer. Es importante entender que un valor residual es sólo un número. Para su correcta interpretación debe venir acompañado de la relación de lo que se debería hacer y no se ha hecho; es decir, de las vulnerabilidades que presenta el sistema. Los responsables de la toma de decisiones deberán prestar cuidadosa atención a esta relación de tareas pendientes, que se denomina Informe de Insuficiencias o de vulnerabilidades. © Ministerio de Hacienda y Administraciones Públicas

página 48 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

4.1.2. Aceptación del riesgo La Dirección de la Organización sometida al análisis de riesgos debe determinar el nivel de impacto y riesgo aceptable. Más propiamente dicho, debe aceptar la responsabilidad de las insuficiencias. Esta decisión no es técnica. Puede ser una decisión política o gerencial o puede venir determinada por ley o por compromisos contractuales con proveedores o usuarios. Estos niveles de aceptación se pueden establecer por activo o por agregación de activos (en un determinado departamento, en un determinado servicio, en una determinada dimensión, ...) Cualquier nivel de impacto y/o riesgo es aceptable si lo conoce y acepta formalmente la Dirección 17 .

4.1.3. Tratamiento La Dirección puede decidir aplicar algún tratamiento al sistema de seguridad desplegado para proteger el sistema de información. Hay dos grandes opciones: •

reducir el riesgo residual (aceptar un menor riesgo)

•

ampliar el riesgo residual (aceptar un mayor riesgo)

Para tomar una u otra decisión hay que enmarcar los riesgos soportados por el sistema de información dentro de un contexto más amplio que cubre un amplio espectro de consideraciones de las que podemos apuntar algunas sin pretender ser exhaustivos: •

cumplimiento de obligaciones; sean legales, regulación pública o sectorial, compromisos internos, misión de la Organización, responsabilidad corporativa, etc. •

posibles beneficios derivados de una actividad que en sí entraña riesgos

•

condicionantes técnicos, económicos, culturales, políticos, etc.

• equilibrio con otros tipos de riesgos: comerciales, financieros, regulatorios, medioambientales, laborales, …

En condiciones de riesgo residual extremo, casi la única opción es reducir el riesgo. En condiciones de riesgo residual aceptable , podemos optar entre aceptar el nivel actual o ampliar el riesgo asumido. En cualquier caso hay que mantener una monitorización continua de las circunstancias para que el riesgo formal cuadre con la experiencia real y reaccionemos ante cualquier desviación significativa.

Ilustración 12. Zonas de riesgo

17

Hablar de Dirección es pecar de simplificar la realidad. En inglés suele emplearse el término “stakeholders” (o tenedores de la estaca) para referirse a los afectados por las decisiones estratégicas de una Organización: dueños, gerentes, usuarios, empleados e incluso la sociedad en general. Porque al final si se aceptan riesgos imprudentemente elevados, el perjudicado puede no ser sólo el que dirige, sino todos los que tienen su confianza puesta en la Organización y cuyo lamentable desempeño oscurecería sus legítimas expectativas. En última instancia puede verse afectada la confianza en un sector o en una tecnología por la imprudente puesta en escena de algunos actores.

© Ministerio de Hacienda y Administraciones Públicas

página 49 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

En condiciones de riesgo residual medio, podemos observar otras características como las pérdidas y ganancias que pueden verse afectadas por el escenario presente, o incluso analizar el estado del sector en el que operamos para compararnos con la “norma”. En términos de las zonas de riesgo que se expusieron anteriormente, •

zona 1 – riesgos muy probables y de muy alto impacto; posiblemente nos planteemos sacarlos de esta zona

•

zona 2 – riesgos de probabilidad relativa e impacto medio; se pueden tomar varias opciones

•

zona 3 – riesgos improbables y de bajo impacto; o los dejamos como están, o permitimos que suban a mayores si ello nos ofreciera alguna ventaja o beneficio en otro terreno

•

zona 4 – riesgos improbables pero de muy alto impacto; suponen un reto de decisión pues su improbabilidad no justifica que se tomen medidas preventivas, pero su elevado impacto exige que tengamos algo previsto para reaccionar; es decir, hay que poner el énfasis en medidas de reacción para limitar el daño y de recuperación del desastre si ocurriera.

También conviene considerar la incertidumbre del análisis. Hay veces que sospechamos las consecuencias, pero hay un amplio rango de opiniones sobre su magnitud (incertidumbre en el impacto). En otras ocasiones la incertidumbre afecta a la probabilidad. Estos escenarios suelen afectar a las zonas 4 y 3, pues cuando la probabilidad es alta, normalmente adquirimos experiencia, propia o ajena, con rapidez y salimos de la incertidumbre. En cualquier caso, toda incertidumbre debe considerarse como mala y debemos hacer algo: •

buscar formas de mejorar la previsión, típicamente indagando en foros, centros de respuesta a incidentes o expertos en la materia;

•

evitar el riesgo cambiando algún aspecto, componente o arquitectura del sistema; o

•

tener preparados sistemas de alerta temprana y procedimientos flexibles de contención, limitación y recuperación del posible incidente.

A veces que estos escenarios de incertidumbre ocurren en un terreno en el que hay obligaciones de cumplimiento y la propia normativa elimina o reduce notablemente las opciones disponibles; es decir, el sistema se protege por obligación más que por certidumbre del riesgo. A la vista de estas consideraciones se tomarán las decisiones de tratamiento.

4.1.4. Estudio cuantitativo de costes / beneficios Es de sentido común que no se puede invertir en salvaguardas más allá del valor que queremos proteger. Aparecen en la práctica gráficos como el siguiente que ponen uno frente al otro el coste de la inseguridad (lo que costaría no estar protegidos) y el coste de las salvaguardas.

© Ministerio de Hacienda y Administraciones Públicas

página 50 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

0

10

20

30

40

50

60

70

80

90

100

grado de seguridad riesgo residual

gasto en salvaguardas

coste total

Ilustración 13. Relación entre el gasto en seguridad y el riesgo residual

Este tipo de gráficas intentan reflejar cómo al avanzar de un grado de seguridad 0 hacia un grado de seguridad del 100%, el coste de la inseguridad (el riesgo) disminuye, mientras que el coste de la inversión en salvaguardas aumenta. Es intencionado el hecho de que el riesgo caiga fuertemente con pequeñas inversiones 18 y que el coste de las inversiones se dispare para alcanzar niveles de seguridad cercanos al 100% 19 . La curva central suma el coste para la Organización, bien derivado del riesgo (baja seguridad), bien derivado de la inversión en protección. De alguna forma existe un punto de equilibrio entre lo que se arriesga y lo que se invierte en defensa, punto al que hay que tender si la única consideración es económica. Pero llevar el sentido común a la práctica no es evidente, ni por la parte del cálculo del riesgo, ni por la parte del cálculo del coste de las salvaguardas. En otras palabras, la curva anterior es conceptual y no se puede dibujar en un caso real. En la práctica, cuando hay que protegerse de un riesgo que se considera significativo, aparecen varios escenarios hipotéticos: E0: si no se hace nada E1: si se aplica un cierto conjunto de salvaguardas E2: si se aplica otro conjunto de salvaguardas Y así N escenarios con diferentes combinaciones de salvaguardas. El análisis económico tendrá como misión decidir entre estas opciones, siendo E0 (seguir como estamos) una opción posible, que pudiera estar justificada económicamente. En cada escenario hay que estimar a lo largo del tiempo el coste que va a suponer. Para poder agregar costes, se contabilizan como valores negativos las pérdidas de dinero y como valores positivos las entradas de dinero. Considerando los siguientes componentes:

18 19 20

−

(recurrente) riesgo residual 20

−

(una vez) coste de las salvaguardas 21

Medidas básicas de seguridad suponen un importante descenso del riesgo. Por ello son inexcusables. Reflejando una vez más que la seguridad absoluta (riesgo cero) no existe. Si la frecuencia de las amenazas se ha estimado como tasa anual, los datos de riesgo residual estarán automáticamente anualizados. Si se hubiera empleado otra escala, habría que convertirla a términos anuales.

© Ministerio de Hacienda y Administraciones Públicas

página 51 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

−

(recurrente) coste anual de mantenimiento de las salvaguardas

+

(recurrente) mejora en la productividad 22

+

(recurrente) mejoras en la capacidad de la Organización para prestar nuevos servicios, conseguir mejores condiciones de los proveedores, entrar en asociación con otras organizaciones, etc.

El escenario E0 es muy simple: todos los años se afronta un gasto marcado por el riesgo, que se acumula año tras año. En los demás escenarios, hay cosas que suman y cosas que restan, pudiendo darse varias situaciones 23 como las recogidas en la gráfica siguiente. Se presentan valores acumulados a lo largo de un periodo de 5 años. La pendiente de la recta responde a los costes recurrentes. El valor el primer año corresponde a los costes de implantación.

Ilustración 14. Ejemplos de decisiones de tratamiento del riesgo •

En E0 se sabe lo que cada año (se estima que) se pierde

•

El escenario E1 aparece como mala idea, pues supone un gasto añadido el primer año; pero este gasto no se recupera en años venideros.

•

No así el escenario E2 que, suponiendo un mayor desembolso inicial, empieza a ser rentable a partir del cuarto año.

•

Más atractivo aún es el escenario E3 en el que a costa de un mayor desembolso inicial, se empieza a ahorrar al tercer año, e incluso se llega a obtener beneficios operativos a partir del quinto año. Se puede decir que en escenario E3 se ha hecho una buena inversión.

21

Si la salvaguarda ya existe, coste de mejora. Si no existiera, coste de adquisición e instalación. En cualquier caso hay que imputar costes de formación de los operadores, usuarios, etc. 22 Este epígrafe puede ser positivo si la Organización mejora su productividad; o puede ser negativo, si empeora. Como ejemplo típico de salvaguardas que mejoran la productividad podemos citar la introducción de dispositivos de autenticación en sustitución de la clásica contraseña. Como ejemplo típico de salvaguardas que minoran la productividad podemos citar la clasificación de documentación con control de acceso restringido. 23 En el eje X se muestran años, en referencia al año 0 en que se realiza el análisis de riesgos. En ordenadas aparecen costes en unidades arbitrarias.

© Ministerio de Hacienda y Administraciones Públicas

página 52 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

4.1.5. Estudio cualitativo de costes / beneficios Cuando el análisis es cualitativo, en la balanza de costes beneficios aparecen aspectos intangibles que impiden el cálculo de un punto numérico de equilibrio. Entre los aspectos intangibles se suelen contemplar: — aspectos reputacionales o de imagen — aspectos de competencia: comparación con otras organizaciones de mismo ámbito de actividad — cumplimiento normativo, que puede ser obligatorio o voluntario — capacidad de operar — productividad Estas consideraciones nos llevan a contemplar diversos escenarios para determinar el balance neto. Por ejemplo, el no adoptar medidas puede exponernos a un cierto riesgo que causaría mala imagen; pero si la solución preventiva causa también mala imagen o supone un merma notable de oportunidades o de productividad, hay que buscar un punto de equilibrio, eligiendo una combinación de medidas que sea asumible.

4.1.6. Estudio mixto de costes / beneficios En análisis de riesgos meramente cualitativos, la decisión la marca el balance de costes y beneficios intangibles, si bien siempre hay que hacer un cálculo de lo que cuesta la solución y cerciorarse de que el gasto es asumible. De o contrario, la supuesta solución no es una opción. Es decir, primero hay que pasar el filtro económico y luego elegir la mejor de las soluciones factibles.

4.1.7. Opciones de tratamiento del riesgo: eliminación La eliminación de la fuente de riesgo es una opción frente a un riesgo que no es aceptable. En un sistema podemos eliminar varias cosas, siempre que no afecten a la esencia de la Organización. Es extremadamente raro que podamos prescindir de la información o los servicios esenciales por cuanto constituyen la misión de la Organización. Cambiar estos activos supone reorientar la misión de la Organización. Más viable es prescindir de otros componentes no esenciales, que están presentes simple y llanamente para implementar la misión, pero no son parte constituyente de la misma. Esta opción puede tomar diferentes formas: •

Eliminar cierto tipo de activos, emplean otros en su lugar. Por ejemplo: cambiar de sistema operativo, de fabricante de equipos, …

•

Reordenar la arquitectura del sistema (el esquema de dependencias en nuestra terminología) de forma que alteremos el valor acumulado en ciertos activos expuestos a grandes amenazas. Por ejemplo: segregar redes, desdoblar equipos para atender a necesidades concretas, alejando lo más valioso de lo más expuesto, …

Las decisiones de eliminación de las fuentes de riesgo suponen realizar un nuevo análisis de riesgos sobre el sistema modificado.

4.1.8. Opciones de tratamiento del riesgo: mitigación La mitigación del riesgo se refiere a una de dos opciones: •

reducir la degradación causada por una amenaza (a veces se usa la expresión ‘acotar el impacto’)

•

reducir la probabilidad de que una amenaza de materializa

En ambos casos lo que hay que hacer es ampliar o mejorar el conjunto de salvaguardas. En términos de madurez de las salvaguardas: subir de nivel. © Ministerio de Hacienda y Administraciones Públicas

página 53 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Algunas salvaguardas, notablemente las de tipo técnico, se traducen en el despliegue de más equipamiento 24 que se convierte a su vez en un activo del sistema. Estos nuevos activos también acumularán valor del sistema y estarán a su vez sujetos a amenazas que pueden perjudicar a los activos esenciales. Hay pues que repetir el análisis de riesgos, ampliándolo con el nuevo despliegue de medios y, por supuesto, cerciorarse de que el riesgo del sistema ampliado es menor que el del sistema original; es decir, que las salvaguardas efectivamente disminuyen el estado de riesgo de la Organización.

4.1.9. Opciones de tratamiento del riesgo: compartición Tradicionalmente se ha hablado de ‘transferir el riesgo’. Como la transferencia puede ser parcial o total, es más general hablar de ‘compartir el riesgo’. Hay dos formas básicas de compartir riesgo: •Riesgo

cualitativo: se comparte por medio de la externalización de componentes del sistema, de forma que se reparten responsabilidades: unas técnicas para el que opera el componente técnico; y otras legales según el acuerdo que se establezca de prestación del servicio.

•

Riesgo cuantitativo: se comparte por medio de la contratación de seguros, de forma que a cambio de una prima, el tomador reduce el impacto de las posibles amenazas y el asegurador corre con las consecuencias. Hay multitud de tipos y cláusulas de seguros para concretar el grado de responsabilidad de cada una de las partes.

Cuando se comparten riesgos cambia, bien el conjunto de componentes del sistema, bien su valoración, requiriéndose un nuevo análisis del sistema resultante.

4.1.10. Opciones de tratamiento del riesgo: financiación Cuando se acepta un riesgo, la Organización hará bien en reservar fondos para el caso de que el riesgo se concrete y haya que responder de sus consecuencias. A veces de habla de ‘fondos de contingencia’ y también puede ser parte de los contratos de aseguramiento. Normalmente esta opción no modifica nada del sistema y nos vale el análisis de riesgos disponible.

4.2. Formalización de las actividades

Ilustración 15. Proceso de gestión de riesgos 24 Ejemplos típicos pueden ser un equipo cortafuegos, un sistema de gestión de redes privadas virtuales, tarjetas inteligentes de identificación de los usuarios, una PKI de clave pública, etc.

© Ministerio de Hacienda y Administraciones Públicas

página 54 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

4.2.1. Roles y funciones En el proceso de gestión de riesgos aparecen varios actores. Los siguientes párrafos intentan identificarlos de forma somera y explicitar cuales son sus funciones y responsabilidades. Órganos de gobierno En este epígrafe se incluyen aquellos que órganos colegiados o unipersonales que deciden la misión y los objetivos de la Organización. Típicamente se incluyen en esta categoría los altos cargos de los organismos. Cuando existe un Comité de Seguridad de la Información, suele aparecer en este nivel. Estos órganos tienen la autoridad última para aceptar los riesgos con que se opera. Se dice que son los “propietarios del riesgo”. Dirección ejecutiva En este epígrafe se incluyen aquellos órganos colegiados o unipersonales que toman decisiones que concretan cómo alcanzar los objetivos de negocio marcados por los órganos de gobierno. Típicamente se incluyen en esta categoría los responsables de unidades de negocio, los responsables de la calidad de los servicios prestados por la organización, etc. Dirección operacional En este epígrafe se incluyen aquellos órganos colegiados o unipersonales que toman decisiones prácticas para materializar las indicaciones dadas por los órganos ejecutivos. Típicamente se incluyen en esta categoría los responsables de operaciones, de producción, de explotación y similares.

Esquema Nacional de Seguridad En el Esquema Nacional de Seguridad de identifican ciertos roles que pueden verse involucrados en el proceso de gestión de riesgos: Responsable de la información Típicamente a nivel de gobierno. Tiene la responsabilidad última sobre qué seguridad requiere una cierta información manejada por la Organización. A este nivel se suele concretar la responsabilidad sobre datos de carácter personal y sobre la clasificación de la información. A veces este role lo ejerce el Comité de Seguridad de la Información. Responsable del servicio Típicamente a nivel de gobierno, aunque a veces baja a nivel ejecutivo. Tiene la responsabilidad última de determinar los niveles de servicio aceptables por la Organización. A veces este role lo asume el Comité de Seguridad de la Información. Responsable de la seguridad Típicamente a nivel ejecutivo, actuando como engranaje entre las directrices emanadas de los responsables de la información y los servicios, y el responsable del sistema. A su vez funciona como supervisor de la operación del sistema y vehículo de reporte al Comité de Seguridad de la Información. A veces se denomina a esta figura CISO (Chief Information Security Officer). En lo que respecta al proceso de gestión de riesgos, es la persona que traslada la valoración de los activos esenciales, que aprueba la declaración de aplicabilidad de salvaguardas, los procedimientos operativos, los riesgos residuales y los planes de seguridad. En esta fun-

© Ministerio de Hacienda y Administraciones Públicas

página 55 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

ción de informante, suele ser la persona encargada de elaborar los indicadores del esto de seguridad del sistema. Responsable del sistema A nivel operacional. Toma decisiones operativas: arquitectura del sistema, adquisiciones, instalaciones y operación del día a día. En lo que respecta al proceso de gestión de riesgos, es la persona que propone la arquitectura de seguridad, la declaración de aplicabilidad de salvaguardas, los procedimientos operativos y los planes de seguridad. También es la persona responsable de la implantación y correcta operación de las salvaguardas. Administradores y operadores Son las personas encargadas de ejecutar las acciones diarias de operación del sistema según las indicaciones recibidas de sus superiores jerárquicos.

Matriz RACI La matriz que se expone a continuación es orientativa y cada organismo deberá adecuarla a su organización particular. La matriz de la asignación de responsabilidades (RACI por las iniciales, en inglés, de los tipos de responsabilidad) se utiliza generalmente en la gestión de proyectos para relacionar actividades con recursos (individuos o equipos de trabajo). De esta manera se logra asegurar que cada una de las tareas esté asignada a un individuo o a un órgano colegiado.

rol

descripción

R Responsible Este rol realiza el trabajo y es responsable por su realización. Lo más habitual es que exista sólo un R, si existe más de uno, entonces el trabajo debería ser subdividido a un nivel más bajo, usando para ello las matrices RASCI. Es quien debe ejecutar las tareas. A Accountable Este rol se encarga de aprobar el trabajo finalizado y a partir de ese momento, se vuelve responsable por él. Sólo puede existir un A por cada tarea. Es quien debe asegurar que se ejecutan las tareas. C Consulted

Este rol posee alguna información o capacidad necesaria para terminar el trabajo. Se le informa y se le consulta información (comunicación bidireccional).

I

Este rol debe ser informado sobre el progreso y los resultados del trabajo. A diferencia del Consultado, la comunicación es unidireccional.

Informed

Tabla 5. Roles en procesos distribuidos

RINF O

RSER V

RSE G

RSI S

niveles de seguridad requeridos por la información

A

I

R

C

niveles de seguridad requeridos por el servicio

I

A

R

C

análisis de riesgos

I

I

A/R

C

declaración de aplicabilidad

I

I

A/R

C

A

A

R

I

I

I

C

A

R

A

C

R

Tarea

Dirección

aceptación del riesgo residual implantación de las medidas de seguridad supervisión de las medidas de seguridad © Ministerio de Hacienda y Administraciones Públicas

I

AS S

página 56 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos Dirección

RINF O

RSER V

RSE G

RSI S

AS S

I

I

I

A

I

R

planes de mejora de la seguridad

A

C

planes de concienciación y formación

A

C

planes de continuidad

C

A

seguridad en el ciclo de vida

C

A

Tarea estado de seguridad del sistema

Tabla 6. Matriz RACI - Tareas relacionadas con la gestión de riesgos

Siendo Dirección – Alta Dirección, Órganos de Gobierno RINFO – Responsable de la Información RSERV – Responsable del Servicio RSEG – Responsable de la Seguridad RSIS – Responsable (operacional) del Sistema ASS – Administrador(es) de la Seguridad del Sistema

4.2.2. Contexto Hay que documentar el entorno externo en el que opera la Organización: cultural, social y político. Esto incluye tanto aspectos nacionales como internacionales, viniendo marcados por el ámbito de actividad de la Organización. Hay que identificar las obligaciones legales, reglamentarias y contractuales. Por ejemplo, suele haber obligaciones asociadas a — tratamiento de datos de carácter personal, — tratamiento de información clasificada, — tratamiento de información y productos sometidos a derechos de propiedad intelectual — prestación de servicios públicos — operación de infraestructuras críticas — etc. Hay que identificar el entorno en cuanto competencia y posicionamiento respecto de la competencia. Hay que identificar el contexto interno en el que se desenvuelve la actividad de la Organización: política interna, compromisos con los accionistas y con los trabajadores o sus representantes. La identificación del contexto en el que se desarrolla el proceso de gestión de riesgos debe ser objeto de una revisión continua para adaptarse a las circunstancias de cada momento.

4.2.3. Criterios Múltiples aspectos relacionados con los riesgos son objeto de estimaciones. Conviene que las estimaciones sean lo más objetivas que sea posible o. al menos, que sean repetibles, explicables y comparables. En particular conviene establecer escalas de valoración para — valorar los requisitos de seguridad de la información — valorar los requisitos de disponibilidad de los servicios © Ministerio de Hacienda y Administraciones Públicas

página 57 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

— estimar la probabilidad de una amenaza — estimar las consecuencias de un incidente de seguridad — estimar el nivel de riesgo a partir de las estimaciones de impacto y probabilidad — … (ver “Libro II – Catálogo de Elementos”) Hay que establecer reglas y/o criterios para tomar decisiones de tratamiento: — umbrales de impacto — umbrales de probabilidad — umbrales combinados de impacto y probabilidad — umbrales de nivel de riesgo — impacto en la reputación de la Organización o de las personas responsables — impacto en la posición de competencia — impacto comparado con otras áreas de riesgo: financiero, regulatorio, medioambiental, seguridad industrial, etc — combinaciones o concurrencia de riesgos que pudieran tener un efecto combinado — amenazas especialmente sensibles (puede ser por motivos técnicos, porque adolecen de una amplia incertidumbre o porque su ocurrencia causaría una notable alarma social con grave daño para la reputación o la continuidad de las operaciones de la Organización, incluso si sus consecuencia técnicas o materiales son modestas) — …

4.2.4. Evaluación de los riesgos Se sigue la metodología descrita en el capítulo anterior. La primera vez que se ejecuta esta actividad puede ser conveniente lanzar un proyecto específico de análisis de riesgos. Ver capítulo siguiente.

4.2.5. Decisión de tratamiento Se pueden tomar las diferentes opciones mencionadas al principio de este capítulo. Hay múltiples formas de reducir el riesgo: — eliminar el riesgo eliminando sus causas: información tratada, servicios prestados, arquitectura del sistema, — reducir o limitar el impacto — reducir la probabilidad de que la amenaza ocurra — en el caso de amenazas derivadas de defectos de los productos (vulnerabilidades técnicas): reparar el producto (por ejemplo, aplicar los parches del fabricante) — implantar nuevas salvaguardas o mejorar la calidad de las presentes — externalizar partes del sistema — contratar seguros de cobertura A veces la decisión consiste en aceptar un incremento del riesgo: — aceptando trabajar con nueva información o prestar nuevos servicios — alterando la arquitectura del sistema — reduciendo las salvaguardas presentes — reduciendo la calidad de las salvaguardas presentes (es decir, dedicando menos recursos) © Ministerio de Hacienda y Administraciones Públicas

página 58 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

En última instancia siempre hay que acabar aceptando un cierto riesgo residual, en cuyo caso es posible que se decide reservar fondos para hacer frente a alguna contingencia.

4.2.6. Comunicación y consulta Antes de tomar ninguna decisión relativa al tratamiento de un riesgo hay que entender para qué se usa el sistema y cómo se usa. Esto quiere decir mantener un contacto fluido con varios actores — los órganos de gobierno y decisión, pues toda decisión debe estar alineada con la misión de la Organización — los usuarios y técnicos de sistemas, pues toda decisión debe tener en cuenta su impacto en la productividad y sobre la usabilidad del sistema — los proveedores, pues toda decisión debe contar con su colaboración Hay que tener en cuenta que cualquier medida de seguridad que merme la productividad, dificulte la operación del sistema, o requiera una elaborada formación de los usuarios, está condenada al fracaso, Toda medida de seguridad debe estar — apoyada por la Dirección — amparada por la Política de Seguridad de la Organización — apoyada por normativa clara y legible, ampliamente divulgada — explicada de forma breve, clara y directa en procedimientos operativos de seguridad Por último es interesante disponer de indicadores que midan el grado de aceptación por parte de los usuarios, identificando tanto el grado de cumplimiento como los problemas que causa su seguimiento.

4.2.7. Seguimiento y revisión El análisis de los riesgos es un ejercicio formal, basado en múltiples estimaciones y valoraciones que pueden no compadecerse con la realidad. Es absolutamente necesario que el sistema esté bajo monitorización permanente. Los indicadores de impacto y riesgo potenciales son útiles para decidir qué puntos deben ser objeto de monitorización. Y debe estar preparado un sistema de detección precoz de posibles incidentes (en base a indicadores predictivos) así como un sistema de reacción a incidentes de seguridad. Se procurará disponer de un conjunto de indicadores clave de riesgo (KRI – Key Risk Indicators). Estos indicadores: o

son propuestos por el Responsable de la Seguridad;

o

su definición es acordada por el Responsable de la Seguridad y el propietario del riesgo; la definición indicará exactamente:

— en qué medidas se basan, — cuál es el algoritmo de cálculo, — la periodicidad de evaluación y — los umbrales de aviso y alarma (atención urgente) o

se le presentan al responsable correspondiente

— rutinariamente, con la periodicidad establecida, — puntualmente, por demanda del propietario del riesgo medido, — y extraordinariamente cuando se supera un umbral de riesgo o

estos indicadores estarán a disposición de los auditores

© Ministerio de Hacienda y Administraciones Públicas

página 59 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

La responsabilidad de monitorizar un riesgo recae en su propietario, sin perjuicio de que la función puede ser delegada en el día a día, retomando el control de la situación cuando hay que tomar medidas para atajar un riesgo que se ha salido de los márgenes tolerables. Cada vez que la realidad difiere de nuestras estimaciones conviene hacer un ciclo de revisión del análisis y las decisiones de tratamiento.

Servicios subcontratados Cuando dependemos de terceros es especialmente importante conocer el desempeño de nuestros proveedores, tanto con un buen sistema de reporte, escalado y resolución de los incidentes de seguridad, como en el establecimiento de indicadores predictivos. Del análisis de dependencias realizado durante el análisis de riesgos, tenemos información de en qué medida y en qué dimensiones de seguridad dependemos de cada proveedor externo. De esta información se sigue qué elementos debemos monitorizar para asegurarnos que satisfacen nuestros requisitos de seguridad.

4.3. Documentación del proceso Documentación interna •

Definición de roles, funciones y esquemas de reporte

•

Criterios de valoración de la información

•

Criterios de valoración de los servicios

•

Criterios de evaluación de los escenarios de impacto y riesgo

Documentación para otros •

Plan de Seguridad

4.4. Indicadores de control del proceso de gestión de riesgos √ actividad

tarea

Se han definido los roles y responsabilidades respecto de la gestión de riesgos

4.2.1

Se ha establecido el contexto de gestión de riesgos

4.2.2

Se han establecido los criterios de valoración de riesgos y toma de decisiones de tratamiento

4.2.3

Se han interpretado los riesgos residuales en términos de impacto en el negocio o misión de la Organización

4.2.4

Se han identificado y valorado opciones de tratamiento de los riesgos residuales (propuesta de programas de seguridad)

4.2.5

Los órganos de gobierno han adoptado una propuesta de tratamiento — evitar el riesgo — prevenir: mitigar la probabilidad de que ocurra — mitigar el impacto si ocurriera — compartir el riesgo con un tercero — asumir el riesgo

4.2.5

Se han previsto recursos para acometer el plan de seguridad

4.2.5

© Ministerio de Hacienda y Administraciones Públicas

página 60 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

√ actividad

tarea

Se han previsto recursos para atender a contingencias

4.2.5

Se han comunicado las decisiones a las partes afectadas

4.2.6

Se ha desplegado un sistema de monitorización constante para detectar modificaciones en los supuestos de análisis de riesgos

4.2.7

Se han establecido las normas y procedimientos de actuación en caso de detectar desviaciones de los supuestos

4.2.7

© Ministerio de Hacienda y Administraciones Públicas

página 61 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

5. Proyectos de análisis de riesgos Las actividades de análisis de riesgo son recurrentes dentro del proceso de gestión, ya que hay que estar continuamente revisando el análisis y manteniéndolo al día. Podemos llamar ‘análisis de riesgos marginales’ a las salidas de estas actividades que, generalmente, requieren poco volumen de trabajo en cada iteración. Pero antes de pasar a las iteraciones marginales, hay que disponer de un análisis de riesgos que sirva de plataforma de trabajo. Esto ocurre la primera vez que se realiza un análisis de riesgos y cuando la política de la organización marque que se prepare una nueva plataforma, sea por razones formales o porque los cambios acumulados justifican una revisión completa. Cuando se realiza un análisis de riesgos partiendo de cero, se consumen una serie de recursos apreciables y conviene planificar estas actividades dentro de un proyecto, sea interno o se subcontrate a una consultora externa. En esta sección se presentan las consideraciones que se deben tener en cuenta para que este proyecto llegue a buen término. PAR.1 – Actividades preliminares PAR.2 – Elaboración del análisis de riesgos PAR.3 – Comunicación de resultados

5.1. Roles y funciones Durante la ejecución del proyecto es frecuente que se creen algunos roles específicos para llevar el proyecto a buen fin. Comité de Seguimiento Está constituido por los responsables de las unidades afectadas por el proyecto; así como por los responsables de la informática y de la gestión dentro de dichas unidades. También será importante la participación de los servicios comunes de la Organización (planificación, presupuesto, recursos humanos, administración, etc.) En cualquier caso la composición del comité depende de las características de las unidades afectadas. Las responsabilidades de este comité consisten en •

resolver las incidencias durante el desarrollo del proyecto

•

asegurar la disponibilidad de recursos humanos con los perfiles adecuados y su participación en las actividades donde es necesaria su colaboración

•

aprobar los informes intermedios y finales de cada proceso

•

elaborar los informes finales para el comité de dirección

Este comité se suele nombrar por el Comité de Seguridad de la Información, y dicho comité reporta el avance del proyecto. A veces el Comité de Seguimiento toma la forma de subcomité del Comité de Seguridad de la Información. Equipo de proyecto Formado por personal experto en tecnologías y sistemas de información y personal técnico cualificado del dominio afectado, con conocimientos de gestión de seguridad en general y de la aplicación de la metodología de análisis y gestión de riesgos en particular. Si el proyecto se hace con asistencia técnica mediante contratación externa, el subsiguiente personal especialista en seguridad de sistemas de información se integrará en este equipo de proyecto. Las responsabilidades de este equipo consisten en •

llevar a cabo las tareas del proyecto

•

recopilar, procesar y consolidar datos

•

elaborar los informes

© Ministerio de Hacienda y Administraciones Públicas

página 62 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

El Equipo de Proyecto reporta al Comité de Seguimiento a través del Director del Proyecto. Grupos de Interlocutores Está formado por usuarios representativos dentro de las unidades afectadas por el proyecto. Lo constituyen varios posibles subgrupos: •

Responsables de servicio, conscientes de la misión de la Organización y sus estrategias a medio y largo plazo

•

Responsables de servicios internos

•

Personal de explotación y operación de los servicios informáticos, conscientes de los medios desplegados (de producción y salvaguardas) y de las incidencias habituales

Además de dichos órganos colegiados, hay que identificar algunos roles singulares: Promotor Es una figura singular que lidera las primeras tareas del proyecto, perfilando su oportunidad y alcance para lanzar el proyecto de análisis de riesgos propiamente dicho. Debe ser una persona con visión global de los sistemas de información y su papel en las actividades de la Organización, sin necesidad de conocer los detalles; pero si al tanto de las incidencias. Director del Proyecto Debe ser un directivo de alto nivel, con responsabilidades en seguridad dentro de la Organización, de sistemas de información o, en su defecto, de planificación, de coordinación o de materias, servicios o áreas semejantes. Es la cabeza visible del equipo de proyecto e interlocutor con el Responsable de la Seguridad de la Organización.. Enlace operacional Será una persona de la Organización con buen conocimiento de las personas y de las unidades implicadas en el proyecto, que tenga capacidad para conectar al equipo de proyecto con el grupo de usuarios. Es el interlocutor visible del comité de seguimiento con los grupos de usuarios. Conviene recordar que un proyecto de análisis de riesgos siempre es mixto por su propia naturaleza; es decir, requiere la colaboración permanente de especialistas y usuarios tanto en las fases preparatorias como en su desarrollo. La figura del enlace operacional adquiere una relevancia permanente que no es habitual en otro tipo de proyectos más técnicos. El proyecto de análisis de los riesgos se lleva a cabo por medio de las siguientes tareas: PAR – Proyecto de Análisis de Riesgos PAR.1 – Actividades preliminares PAR.11 – Estudio de oportunidad PAR.12 – Determinación del alcance del proyecto PAR.13 – Planificación del proyecto PAR.14 – Lanzamiento del proyecto PAR.2 – Elaboración del análisis de riesgos PAR.3 – Comunicación de resultados

© Ministerio de Hacienda y Administraciones Públicas

página 63 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

5.2. PAR.1 – Actividades preliminares Tarea PAR.11: Estudio de oportunidad Se fundamenta la oportunidad de la realización, ahora, del proyecto de análisis de riesgos, enmarcándolo en el desarrollo de las demás actividades de la Organización. El resultado de esta actividad es el informe denominado “preliminar”.

Tarea PAR.12: Determinación del alcance del proyecto Se definen los objetivos finales del proyecto, su dominio y sus límites. El resultado de esta actividad es un perfil de proyecto de análisis de riesgos.

Tarea PAR.13: Planificación del proyecto Se determinan las cargas de trabajo que supone la realización del proyecto. Normalmente la evolución del proyecto viene marcada por una serie de entrevistas con los interlocutores que conocen la información relativa a algún activo o grupo de activos del sistema bajo análisis. Se planifican las entrevistas que se van a realizar para la recogida de información: quiénes van a ser entrevistados. Se elabora el plan de trabajo para la realización del proyecto. En esta actividad se determinan los participantes y se estructuran los diferentes grupos y comités para llevar a cabo el proyecto. El resultado de esta actividad está constituido por: •

un plan de trabajo para el proyecto

•

procedimientos de trabajo

Tarea PAR.14: Lanzamiento del proyecto Se adaptan los cuestionarios para la recogida de información adaptándolos al proyecto presente. Para ello se parte de los criterios establecidos dentro del Proceso de Gestión de Riesgos. También se realiza una campaña informativa de sensibilización a los afectados sobre las finalidades y requerimientos de su participación. El resultado de esta actividad está constituido por: •

los cuestionarios para las entrevistas

•

el catálogo de tipos de activos

•

la relación de dimensiones de seguridad y

•

los criterios de valoración

5.2.1. Tarea PAR.11: Estudio de oportunidad PAR: Proyecto de análisis de riesgos PAR.1: Actividades preliminares PAR.11: Determinar la oportunidad Objetivos • Identificar o suscitar el interés de la Dirección de la Organización en la realización de un proyecto de análisis de riesgos

Productos de entrada

© Ministerio de Hacienda y Administraciones Públicas

página 64 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

PAR: Proyecto de análisis de riesgos PAR.1: Actividades preliminares PAR.11: Determinar la oportunidad Productos de salida •

Informe preliminar recomendando la elaboración del proyecto

•

Sensibilización y apoyo de la Dirección a la realización del proyecto

•

Creación del comité de seguimiento

Técnicas, prácticas y pautas •

Participantes •

El promotor

La Dirección suele ser muy consciente de las ventajas que aportan las técnicas electrónicas, informáticas y telemáticas a su funcionamiento; pero no tanto de los nuevos problemas de seguridad que estas técnicas implican, o de las obligaciones legales o reglamentarias que les afectan En toda Organización pública o privada es importante transformar en medidas concretas la creciente preocupación por la falta de seguridad de los sistemas de información, por su soporte y entorno, puesto que sus efectos no sólo afectan a dichos sistemas, sino al propio funcionamiento de la Organización y, en las situaciones críticas, a su propia misión y capacidad de supervivencia.

Desarrollo La iniciativa para la realización de un proyecto de análisis de riesgos parte de un promotor interno o externo a la Organización, consciente de los problemas relacionados con la seguridad de los sistemas de información, como por ejemplo: •

Incidentes continuados relacionados con la seguridad.

•

Inexistencia de previsiones en cuestiones relacionadas con la evaluación de necesidades y medios para alcanzar un nivel aceptable de seguridad de los sistemas de información que sea compatible con el cumplimiento correcto de la misión y funciones de la Organización.

•

Reestructuraciones en los productos o servicios proporcionados.

•

Cambios en la tecnología utilizada.

•

Desarrollo de nuevos sistemas de información.

El promotor puede elaborar un cuestionario-marco (documento poco sistematizable que deberá crear en cada caso concreto) para provocar la reflexión sobre aspectos de la seguridad de los sistemas de información por parte de : Los responsables de las unidades operativas (responsables de servicios). El cuestionario permite proceder a un examen informal de la situación en cuanto a la seguridad de sus sistemas de información; deben poder expresar su opinión por los proyectos de seguridad ya realizados (con su grado de satisfacción o con las limitaciones de éstos), así como sus expectativas ante la elaboración de un proyecto de análisis de riesgos 25 . Esta aproximación de alto nivel permite obtener una primera visión de los objetivos concretos y las opciones que tendrían que subyacer a la elaboración del proyecto. 25 Probablemente no se conozca lo que esto significa y haya que incluir en el cuestionario marco una sucinta explicación de qué es y qué objetivos persigue el análisis de riesgos en general y el proyecto en particular.

© Ministerio de Hacienda y Administraciones Públicas

página 65 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Los responsables de informática. El cuestionario permite obtener una panorámica técnica para la elaboración del proyecto y posibilita abordar el estudio de oportunidad de realización, tras integrar las opciones anteriores. De las respuestas al cuestionario-marco y de las entrevistas mantenidas con los responsables y colectivos anteriores, el promotor obtiene una primera aproximación sobre las funciones, los servicios y los productos implicados en cuestiones de seguridad de los sistemas de información, la ubicación geográfica de aquéllos, los medios técnicos, los medios humanos, etc. Con estos elementos el promotor realiza el informe preliminar recomendando la elaboración del proyecto de análisis de riesgos e incluyendo estos elementos: •

Exposición de los argumentos básicos.

•

Relación de antecedentes sobre la seguridad de los sistemas de información (Plan Estratégico, Plan de Actuación, etc.).

•

Primera aproximación al dominio a incluir en el proyecto en función de

•

•

las finalidades de las unidades o departamentos

•

las orientaciones gerenciales y técnicas

•

la estructura de la Organización

•

el entorno técnico.

Primera aproximación de los medios, tanto humanos como materiales, para la realización del proyecto.

El promotor presenta este informe preliminar a la Dirección que puede decidir: •

aprobar el proyecto, o bien

•

modificar su dominio y/o sus objetivos, o bien

•

retrasar el proyecto.

5.2.2. Tarea PAR.12: Determinación del alcance del proyecto Una vez que se ha constatado la oportunidad de realizar el proyecto y se cuenta con el apoyo de la Dirección, esta actividad estima los elementos de planificación del proyecto, es decir los participantes y sus cargas de trabajo. En dicha estimación se ha de tener en cuenta la posible existencia de otros planes (por ejemplo un Plan Estratégico de Sistemas de Información o de Seguridad general en las unidades que pueden ser afectadas o en la Organización) y el plazo de tiempo considerado para la puesta en práctica del proyecto. En particular, la existencia de un Plan Estratégico de Sistemas de Información para las unidades que pueden ser afectadas dentro de la Organización puede determinar en gran medida el alcance y la extensión de las actividades que se realicen en esta actividad.

PAR: Proyecto de análisis de riesgos PAR.1: Actividades preliminares PAR.12: Determinación del alcance del proyecto Objetivos •

Determinar los objetivos del proyecto, diferenciados según horizontes temporales a corto y medio plazo

•

Determinar las restricciones generales que se imponen sobre el proyecto

•

Determinar el dominio, alcance o perímetro del proyecto

© Ministerio de Hacienda y Administraciones Públicas

página 66 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

PAR: Proyecto de análisis de riesgos PAR.1: Actividades preliminares PAR.12: Determinación del alcance del proyecto Productos de entrada •

Recopilación de la documentación pertinente de la Organización

Productos de salida •

Especificación detallada de los objetivos del proyecto

•

Relación de restricciones generales

•

Relación de unidades de la Organización que se verán afectadas como parte del proyecto

•

Lista de roles relevantes en la unidades incluidas en el alcance del proyecto

•

los activos esenciales

•

los puntos de interconexión con otros sistemas

•

los proveedores externos

Técnicas, prácticas y pautas •

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

31010:B.1: Brainstorming

•

31010:B.2: Structured or semi-structured interviews

•

31010:B.3: Delphi technique

Participantes •

El comité de seguimiento

Un proyecto de análisis de riesgos puede perseguir objetivos a muy corto plazo tales como el aseguramiento de cierto sistema o un cierto proceso de negocio, o puede pretender objetivos más amplios como fuera el análisis global de la seguridad de la Organización. En todo caso, hay que determinarlo. Especialmente a la hora de tomar acciones correctoras, hay que tener en cuenta que “no todo vale”, sino que el proyecto se encontrará con una serie de restricciones, no necesariamente técnicas, que establecen un marco al que atenerse. Para incorporar las restricciones al análisis y gestión de riesgos, estas se agrupan por distintos conceptos, típicamente: Restricciones políticas o gerenciales Típicas de organizaciones gubernamentales o fuertemente relacionadas con organismos gubernamentales, bien como proveedores o como suministradores de servicios. Restricciones estratégicas Derivadas de la evolución prevista de la estructura u objetivos de la Organización. Restricciones geográficas Derivadas de la ubicación física de la Organización o de su dependencia de medios físicos de comunicaciones. Islas, emplazamientos fuera de las fronteras, etc. Restricciones temporales Que toman en consideración situaciones coyunturales: conflictividad laboral, crisis internacional, cambio de la propiedad, reingeniería de procesos, etc. © Ministerio de Hacienda y Administraciones Públicas

página 67 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Restricciones estructurales Tomando en consideración la organización interna: procedimientos de toma de decisiones, dependencia de casas matrices internacionales, etc. Restricciones funcionales Que tienen en cuenta los objetivos de la Organización. Restricciones legales Leyes, reglamentos, regulaciones sectoriales, contratos externos e internos, etc. Restricciones relacionadas con el personal Perfiles laborales, compromisos contractuales, compromisos sindicales, carreras profesionales, etc. Restricciones metodológicas Derivadas de la naturaleza de la organización y sus hábitos o habilidades de trabajo que pueden imponer una cierta forma de hacer las cosas. Restricciones culturales La “cultura” o forma interna de trabajar puede ser incompatible con ciertas salvaguardas teóricamente ideales. Restricciones presupuestarias La cantidad de dinero es importante; pero también la forma de planificar el gasto y de ejecutar el presupuesto

Alcance Esta tarea identifica las unidades objeto del proyecto y especifica las características generales de dichas unidades en cuanto a responsables, servicios proporcionados y ubicaciones geográficas. También identifica las principales relaciones de las unidades objeto del proyecto con otras entidades, por ejemplo el intercambio de información en diversos soportes, el acceso a medios informáticos comunes, etc. La tarea presume un principio básico: el análisis y la gestión de riesgos debe centrarse en un dominio limitado, que puede incluir varias unidades o mantenerse dentro de una sola unidad (según la complejidad y el tipo de problema a tratar), ya que un proyecto de ámbito demasiado amplio o indeterminado podría ser inabarcable, por excesivamente generalista o por demasiado extendido en el tiempo, con perjuicio en las estimaciones de los elementos del análisis. Para que el alcance quede determinado debemos concretar: — los activos esenciales: información que se maneja y servicios que se prestan — los puntos de intercambio de interconexión con otros sistemas, aclarando qué información se intercambia y qué servicios se prestan mutuamente — los proveedores externos en los que se apoya nuestro sistema de información

© Ministerio de Hacienda y Administraciones Públicas

página 68 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

5.2.3. Tarea PAR.13: Planificación del proyecto Proyecto de análisis de riesgos PAR.1: Actividades preliminares PAR.13: Planificación del proyecto Objetivos •

Definir los grupos de interlocutores: usuarios afectados en cada unidad

•

Planificar las entrevistas de recogida de información

•

Determinar el volumen de recursos necesarios para la ejecución del proyecto: humanos, temporales y financieros

•

Elaborar el calendario concreto de realización de las distintas etapas, actividades y tareas del proyecto

•

Establecer un calendario de seguimiento que defina las fechas tentativas de reuniones del comité de dirección, el plan de entregas de los productos del proyecto, las posibles modificaciones en los objetivos marcados, etc

Productos de entrada •

Resultados de la actividad A1.2, Determinación del alcance del proyecto

Productos de salida •

Relación de participantes en los grupos de interlocutores

•

Plan de entrevistas

•

Informe de recursos necesarios

•

Informe de cargas

Técnicas, prácticas y pautas •

Planificación de proyectos

Participantes •

El director de proyecto

•

El comité de seguimiento

El plan de entrevistas debe detallar a qué persona se va a entrevistar, cuándo y con qué objetivo. Este plan permite determinar la carga que el proyecto va a suponer para las unidades afectadas, bien del dominio, bien del entorno. El plan de entrevistas es especialmente importante cuando los sujetos a entrevistar se hayan en diferentes localizaciones geográficas y la entrevista requiere el desplazamiento de una o ambas partes. También conviene ordenar las entrevistas de forma que primero se recaben las opiniones más técnicas y posteriormente las gerenciales, de forma que el entrevistador pueda evolucionar las preguntas tomando en consideración hechos (experiencia histórica) antes que valoraciones y perspectivas de servicio a terceros.

5.2.4. Tarea PAR.14: Lanzamiento del proyecto Esta actividad completa las tareas preparatorias del lanzamiento del proyecto: empezando por seleccionar y adaptar los cuestionarios que se utilizarán en la recogida de datos y por realizar la campaña informativa de sensibilización a los implicados. © Ministerio de Hacienda y Administraciones Públicas

página 69 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Proyecto de análisis de riesgos PAR.1: Actividades preliminares PAR.14: Lanzamiento del proyecto Objetivos •

Disponer de los elementos de trabajo para acometer el proyecto

Productos de entrada •

Marco de trabajo establecido en el Proceso de Gestión de Riesgos: criterios y relaciones con las partes afectadas

Productos de salida •

Cuestionarios adaptados

•

Determinar el catálogo de tipos de activos

•

Determinar las dimensiones de valoración de activos

•

Determinar los niveles de valoración de activos, incluyendo una guía unificada de criterios para asignar un cierto nivel a un cierto activo

•

Determinar los niveles de valoración de las amenazas: frecuencia y degradación

•

Asignar los recursos necesarios (humanos, de organización, técnicos, etc.) para la realización del proyecto

•

Informar a las unidades afectadas

•

Crear un ambiente de conocimiento general de los objetivos, responsables y plazos

Técnicas, prácticas y pautas •

Cuestionarios (ver "Catálogo de Elementos")

Participantes •

El director del proyecto

•

El equipo de proyecto

La tarea adapta los cuestionarios a utilizar en la recogida de información en el proceso P1 en función de los objetivos del proyecto, del dominio y de los temas a profundizar con los usuarios. Los cuestionarios se adaptan con el objetivo de identificar correctamente los elementos de trabajo: activos, amenazas, vulnerabilidades, impactos, salvaguardas existentes, restricciones generales, etc. en previsión de las necesidades de las actividades A2.1 (caracterización de los activos), A2.2 (caracterización de las amenazas) y A2.3 (caracterización de las salvaguardas). La necesidad de una adaptación siempre existe (debido al amplísimo espectro de los problemas de seguridad que puede y debe tratar Magerit). Pero el grado mayor o menor de adaptación depende además de las condiciones en que se realice la explotación de dichos cuestionarios. No habrá la misma profundidad de adaptación para entrevistas guiadas por el especialista en seguridad, que para cuestionarios auto administrados por el responsable del dominio o por los usuarios de sus sistemas de información.

5.3. PAR.2 – Elaboración del análisis de riesgos Se siguen los pasos del método descrito en el capítulo X anterior. La mayor parte de las tareas requerirán dos o tres entrevistas con los interlocutores apropiados: © Ministerio de Hacienda y Administraciones Públicas página 70 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

— una primera entrevista para exponer las necesidades y recabar los datos — una segunda entrevista para validar que los datos son completos y se han entendido correctamente — según las circunstancias puede ser necesaria alguna entrevista adicional si la validación levanta muchas inexactitudes o dudas El todas estas tareas debe procurarse manejar documentación escrita sometida a un proceso formal de gestión; es decir, aprobada y con unos procedimientos de revisión continua. La información de carácter verbal o informal debe limitarse a facilitar la comprensión, no a transmitir elementos sustanciales que no están documentados en parte alguna.

5.4. PAR.3 – Comunicación de resultados La salida de la fase de análisis es la entrada de la fase de tratamiento. Para la tomar decisiones de tratamiento es necesario conocer tanto los indicadores residuales como los indicadores potenciales de impacto y riesgo. Y para cada escenario de riesgo es necesario disponer de información suficiente para poder entender en qué consiste el riesgo, así como su dinámica y los razonamientos o la base de las estimaciones empleadas para derivar resultados. No basta conocer el valor final del indicador, sino que hay que poder analizar el por qué de ese valor. Por otra parte, las decisiones de tratamiento pueden requerir la realización de modificaciones del análisis de riesgo. Frecuentemente es necesario analizar situaciones hipotéticas (¿qué ocurriría si …?) para poder optar por una decisión u otra. Es por ello que es fundamental el soporte de herramientas que automaticen el cálculo. Para el informe ejecutivo final basta destacar gráficamente los escenarios de mayor impacto, de mayor nivel de riesgo y combinaciones peligrosas de ambos indicadores (ver los cuadrantes o zonas más arriba).

5.5. Control del proyecto 5.5.1. Hitos de control Hito de control H1.1: La Dirección procederá a la aprobación o no de la realización del proyecto de análisis de riesgos, basándose en el estudio de oportunidad realizado por el promotor. Hito de control H1.2: El comité de seguimiento del proyecto validará el informe de "Planificación del Proyecto de Análisis de Riesgos" que contendrá una síntesis de los productos obtenidos en las actividades realizadas en el proceso P1.

5.5.2. Documentación resultante Documentación intermedia •

Resultados de las entrevistas.

•

Documentación de otras fuentes: estadísticas, observaciones de expertos y observaciones de los analistas.

•

Documentación auxiliar: planos, organigramas, requisitos, especificaciones, análisis funcionales, cuadernos de carga, manuales de usuario, manuales de explotación, diagramas de flujo de información y de procesos, modelos de datos, etc.

•

Análisis de los resultados, con la detección de las áreas críticas claves.

•

Información existente utilizable por el proyecto (por ejemplo inventario de activos)

•

Resultados de posibles aplicaciones de métodos de análisis y gestión de riesgos realizadas anteriormente (por ejemplo catalogación, agrupación y valoración de activos, amenazas, vulnerabilidades, impactos, riesgo, mecanismos de salvaguarda, etc.).

© Ministerio de Hacienda y Administraciones Públicas

página 71 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Documentación final •

Modelo de valor: identificación de activos junto con sus dependencias y valoración propia y acumulada

•

Mapa de amenazas junto con sus consecuencias y probabilidad de ocurrencia.

•

Documento de aplicabilidad de las salvaguardas.

•

Informe de valoración de la efectividad de las salvaguardas presentes.

•

Informe de insuficiencias o debilidades del sistema de salvaguardas.

•

Indicadores de impacto y riesgo, potenciales y residuales.

© Ministerio de Hacienda y Administraciones Públicas

página 72 (de 127)

Magerit 3.0

Plan de seguridad

6. Plan de seguridad Esta sección trata de cómo llevar a cabo planes de seguridad, entendiendo por tales proyectos para materializar las decisiones adoptadas para el tratamiento de los riesgos. Estos planes reciben diferentes nombres en diferentes contextos y circunstancias: •

plan de mejora de la seguridad

•

plan director de seguridad

•

plan estratégico de seguridad

•

plan de adecuación (en concreto es el nombre que se usa en el ENS)

Se identifican 3 tareas: PS – Plan de Seguridad PS.1 – Identificación de proyectos de seguridad PS.2 – Plan de ejecución PS.3 – Ejecución

6.1. Tarea PS.1: Identificación de proyectos de seguridad Se traducen las decisiones de tratamiento de los riesgos en acciones concretas. PS: Plan de seguridad PS.1: Identificación de proyectos de seguridad Objetivos •

Elaborar un conjunto armónico de programas de seguridad

Productos de entrada •

Resultados de las actividades de análisis y tratamiento de riesgos

•

Conocimientos de técnicas y productos de seguridad

•

Catálogos de productos y servicios de seguridad

Productos de salida •

Relación de programas de seguridad

Técnicas, prácticas y pautas •

Planificación de proyectos

Participantes •

El equipo de proyecto

•

Especialistas en seguridad

•

Especialistas en áreas específicas de seguridad

En última instancia se trata de implantar o mejorar la implantación de una serie de salvaguardas que lleven impacto y riesgo a los niveles residuales determinados por la Dirección. Este tratamiento de las salvaguardas se materializa en una serie de tareas a llevar a cabo. Un programa de seguridad es una agrupación de tareas. La agrupación se realiza por conveniencia, bien porque se trata de tareas que en singular carecerían de eficacia, bien porque se trata de © Ministerio de Hacienda y Administraciones Públicas

página 73 (de 127)

Magerit 3.0

Plan de seguridad

tareas con un objetivo común, bien porque se trata de tareas que competen a una única unidad de acción. Cada programa de seguridad debe detallar: •

Su objetivo genérico.

•

Las salvaguardas concretas a implantar o mejorar, detallando sus objetivos de calidad, eficacia y eficiencia

•

La relación de escenarios de impacto y/o riesgo que afronta: activos afectados, tipos de activos, amenazas afrontadas, valoración de activos y amenazas y niveles de impacto y riesgo

•

La unidad responsable de su ejecución.

•

Una estimación de costes, tanto económicos como de esfuerzo de realización, teniendo en cuenta:

•

•

costes de adquisición (de productos), o de contratación (de servicios), o de desarrollo (de soluciones llave en mano), pudiendo ser necesario evaluar diferentes alternativas

•

costes de implantación inicial y mantenimiento en el tiempo

•

costes de formación, tanto de los operadores como de los usuarios, según convenga al caso

•

costes de explotación

•

impacto en la productividad de la Organización

Una relación de subtareas a afrontar, teniendo en cuenta •

cambios en la normativa y desarrollo de procedimientos

•

solución técnica: programas, equipos, comunicaciones e instalaciones,

•

plan de despliegue

•

plan de formación

•

Una estimación del tiempo de ejecución desde su arranque hasta su puesta en operación.

•

Una estimación del estado de riesgo (impacto y riesgo residual a su compleción).

•

Un sistema de indicadores de eficacia y eficiencia que permitan conocer en cada momento la calidad del desempeño de la función de seguridad que se desea y su evolución temporal.

Las estimaciones anteriores pueden ser muy precisas en los programas sencillos; pero pueden ser simplemente orientativas en los programas complejos que conlleven la realización de un proyecto específico de seguridad. En este último caso, cada proyecto desarrollará los detalles últimos por medio de una serie de tareas propias de cada proyecto que, en líneas generales responderán a los siguientes puntos: •

Estudio de la oferta del mercado: productos y servicios.

•

Coste de un desarrollo específico, propio o subcontratado.

•

Si se estima adecuado un desarrollo específico hay que determinar: •

la especificación funcional y no-funcional del desarrollo

•

el método de desarrollo que garantice la seguridad del nuevo componente

•

los mecanismos de medida (controles) que debe llevar empotrados

•

los criterios de aceptación

•

el plan de mantenimiento: incidencias y evolución

© Ministerio de Hacienda y Administraciones Públicas

página 74 (de 127)

Magerit 3.0

Plan de seguridad

6.2. Tarea PS.2: Planificación de los proyectos de seguridad PS: Plan de seguridad PS.2: Plan de ejecución Objetivos •

Ordenar temporalmente los programas de seguridad

Productos de entrada •

Resultados de las actividades de análisis y tratamiento de riesgos

•

Resultados de la tarea PS.1 Programas de seguridad

Productos de salida •

Cronograma de ejecución del plan

•

Plan de Seguridad

Técnicas, prácticas y pautas •

Análisis de riesgos (ver “Método de Análisis de Riesgos”)

•

Planificación de proyectos

Participantes •

Departamento de desarrollo

•

Departamento de compras

Hay que ordenar en el tiempo los proyectos de seguridad teniendo en cuenta los siguientes factores: •

la criticidad, gravedad o conveniencia de los impactos y/o riesgos que se afrontan, teniendo máxima prioridad los programas que afronten situaciones críticas

•

el coste del programa

•

la disponibilidad del personal propio para responsabilizarse de la dirección (y, en su caso, ejecución) de las tareas programadas

•

otros factores como puede ser la elaboración del presupuesto anual de la Organización, las relaciones con otras organizaciones, la evolución del marco legal, reglamentario o contractual, etc.

Típicamente un plan de seguridad se planifica en tres niveles de detalle: Plan director (uno). A menudo denominado “plan de actuación”, trabaja sobre un periodo largo (típicamente entre 3 y 5 años), estableciendo las directrices de actuación. Plan anual (una serie de planes anuales). Trabaja sobre un periodo corto (típicamente entre 1 y 2 años), estableciendo la planificación de los programas de seguridad. Plan de proyecto (un conjunto de proyectos con su planificación). Trabaja en el corto plazo (típicamente menos de 1 año), estableciendo el plan detallado de ejecución de cada programa de seguridad. Se debe desarrollar un (1) plan director único, que es el que da perspectiva y unidad de objetivos a las actuaciones puntuales. Este plan director permite ir desarrollando planes anuales que, dentro del marco estratégico, van estructurando la asignación de recursos para la ejecución de las tareas, en particular partidas presupuestarias. Y, por último, habrá una serie de proyectos que materializan los programas de seguridad. © Ministerio de Hacienda y Administraciones Públicas

página 75 (de 127)

Magerit 3.0

Plan de seguridad

6.3. Tarea PS.3: Ejecución del plan PS: Plan de seguridad PS.3: Ejecución Objetivos •

Alcanzar los objetivos previstos en el plan de seguridad para cada proyecto planificado

Productos de entrada •

Resultados de las actividades PS.1 (proyectos de seguridad) y PS.2 (planificación)

•

Proyecto de seguridad que nos ocupa

Productos de salida •

Salvaguardas implantadas

•

Normas de uso y procedimientos de operación

•

Sistema de indicadores de eficacia y eficiencia del desempeño de los objetivos de seguridad perseguidos

•

Modelo de valor actualizado

•

Mapa de riesgos actualizado

•

Estado de riesgo actualizado (impacto y riesgo residuales).

Técnicas, prácticas y pautas •

Análisis de riesgos (ver “Método de Análisis de Riesgos”)

•

Planificación de proyectos

Participantes •

El equipo de proyecto: evolución del análisis de riesgos

•

Personal especializado en la salvaguarda en cuestión

6.4. Lista de control de los planes de seguridad √

actividad

tarea

Se han definido los proyectos constituyentes

PS.1

Se han definido las interdependencias entre proyectos (necesidades de que uno avance para que progrese otro)

PS.1

Se han asignado recursos — disponibles para los proyectos en curso — previstos para los proyectos que seguirán en el futuro

PS.2

Se han definido roles y responsabilidades

PS.1

Se ha establecido un calendario de ejecución

PS.2

Se han definido indicadores de progreso

PS.3

Se han previsto necesidades de concienciación y formación

PS.1

Se han previsto necesidades de documentación: — normativa de seguridad y — procedimientos operativos de seguridad

PS.1

© Ministerio de Hacienda y Administraciones Públicas

página 76 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

7. Desarrollo de sistemas de información Las aplicaciones (software) constituyen un tipo de activos frecuente y nuclear para el tratamiento de la información en general y para la prestación de servicios basados en aquella información. La presencia de aplicaciones en un sistema de información es siempre una fuente de riesgo en el sentido de que constituyen un punto donde se pueden materializar amenazas. A veces, además, las aplicaciones son parte de la solución en el sentido de que constituyen una salvaguarda frente a riesgos potenciales. En cualquier caso es necesario que el riesgo derivado de la presencia de aplicaciones esté bajo control. El análisis de los riesgos constituye una pieza fundamental en el diseño y desarrollo de sistemas de información seguros. Es posible, e imperativo, incorporar durante la fase de desarrollo las funciones y mecanismos que refuerzan la seguridad del nuevo sistema y del propio proceso de desarrollo, asegurando su consistencia y seguridad, completando el plan de seguridad vigente en la Organización. Es un hecho reconocido que tomar en consideración la seguridad del sistema antes y durante su desarrollo es más efectivo y económico que tomarla en consideración a posteriori. La seguridad debe estar embebida en el sistema desde su primera concepción. El Esquema Nacional de Seguridad recoge el riesgo como pieza fundamental de la seguridad de los sistemas en varios de sus principios básicos: Artículo 5. La seguridad como un proceso integral. 1. La seguridad se entenderá como un proceso integral constituido por todos los elementos técnicos, humanos, materiales y organizativos, relacionados con el sistema. La aplicación del Esquema Nacional de Seguridad estará presidida por este principio, que excluye cualquier actuación puntual o tratamiento coyuntural. 2. Se prestará la máxima atención a la concienciación de las personas que intervienen en el proceso y a sus responsables jerárquicos, para que, ni la ignorancia, ni la falta de organización y coordinación, ni instrucciones inadecuadas, sean fuentes de riesgo para la seguridad. Artículo 6. Gestión de la seguridad basada en los riesgos. 1. El análisis y gestión de riesgos será parte esencial del proceso de seguridad y deberá mantenerse permanentemente actualizado. 2. La gestión de riesgos permitirá el mantenimiento de un entorno controlado, minimizando los riesgos hasta niveles aceptables. La reducción de estos niveles se realizará mediante el despliegue de medidas de seguridad, que establecerá un equilibrio entre la naturaleza de los datos y los tratamientos, los riesgos a los que estén expuestos y las medidas de seguridad. Artículo 9. Reevaluación periódica. Las medidas de seguridad se reevaluarán y actualizarán periódicamente, para adecuar su eficacia a la constante evolución de los riesgos y sistemas de protección, llegando incluso a un replanteamiento de la seguridad, si fuese necesario. Durante el desarrollo de un sistema de información, se pueden identificar dos tipos de actividades diferenciadas: •

SSI: actividades relacionadas con la propia seguridad del sistema de información que se está desarrollando.

•

SPD: actividades que velan por la seguridad del proceso de desarrollo del sistema de información.

7.1. Inicialización de los procesos Hay varias razones que pueden llevar a plantear el desarrollo de un nuevo sistema de información o la modificación de uno ya existente: © Ministerio de Hacienda y Administraciones Públicas

página 77 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

Nuevos servicios y/o datos. •

Requiere el desarrollo de un nuevo sistema o la modificación de un sistema ya operativo. Puede implicar la desaparición de partes actualmente operativas.

•

La iniciativa la lleva el responsable de desarrollo, actuando el responsable de seguridad como subsidiario.

Evolución tecnológica. Las tecnologías TIC se encuentran en evolución continua, pudiendo presentarse cambios en las técnicas de desarrollo de sistemas, en los lenguajes o las plataformas de desarrollo, en las plataformas de explotación, en los servicios de explotación, en los servicios de comunicaciones, etc. •

Requiere el desarrollo de un nuevo sistema o la modificación de un sistema ya operativo. Puede implicar la desaparición de partes actualmente operativas.

•

La iniciativa la lleva el responsable de desarrollo, actuando el responsable de seguridad como subsidiario.

Modificación de la calificación de seguridad de servicios o datos. •

Típicamente requiere la modificación de un sistema ya operativo. Raramente implica el desarrollo de un nuevo sistema o la desaparición de partes actualmente operativas.

•

La iniciativa la lleva el responsable de seguridad, actuando el responsable de sistemas como subsidiario.

Consideración de nuevas amenazas. La evolución de las tecnologías y los servicios de comunicaciones pueden habilitar nuevas amenazas o convertir amenazas que eran despreciables en el pasado en amenazas relevantes en el futuro. •

Típicamente requiere la modificación del sistema, bien en sus componentes o, más frecuentemente, en sus condiciones de explotación. Raramente implica el desarrollo de un nuevo sistema o la desaparición de partes actualmente operativas.

•

La iniciativa la lleva el responsable de seguridad, actuando el responsable de sistemas como subsidiario.

Modificación de los cri terios de calificación de riesgos. Puede venir inducido por criterios de calidad operativa, por novedades en la legislación aplicable, en la reglamentación sectorial o por acuerdos o contratos con terceros. •

Típicamente requiere la modificación del sistema. Raramente implica el desarrollo de un nuevo sistema o la desaparición de partes actualmente operativas.

•

La iniciativa la lleva el responsable de seguridad, actuando el responsable de sistemas como subsidiario.

7.2. SSI – Seguridad del sistema de información Toda la existencia de un sistema de información puede verse como etapas de concreción creciente, desde una perspectiva muy global durante los procesos de planificación hasta una visión en detalle durante el desarrollo y explotación. No obstante, este ciclo de vida no es lineal, sino que frecuentemente habrá que tantear opciones alternativas y revisar decisiones tomadas. El análisis de riesgos debe basar sus estimaciones de impacto y riesgo en la realidad de los sistemas, concretada en sus activos. En consecuencia, se puede entender el modelo de valor como evolutivo, recogiendo en cada momento el nivel de detalle de que se dispone. Magerit, como metodología, permite un tratamiento sistemático y homogéneo que es esencial para poder comparar opciones alternativas y para gestionar la evolución de los sistemas. Como principio básico debe considerarse que el análisis de los riesgos debe seguir fielmente la realidad del sistema de información y su contexto, facilitando el mejor análisis de riesgos posible para poder tomar decisiones de tratamiento adecuadas a cada momento.

© Ministerio de Hacienda y Administraciones Públicas

página 78 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

7.2.1. Ciclo de vida de las aplicaciones Típicamente, una aplicación sigue un ciclo de vida a través de varias fases:

especificación

adquisición (estándar)

desarrollo subcontratado

desarrollo propio

aceptación

despliegue

operación

mantenimiento

Ilustración 16. Ciclo de vida de las aplicaciones

Especificación. En esta fase se determinan los requisitos que debe satisfacer la aplicación y se elabora un plan para las siguientes fases. Adquisición o desarrollo. Para traducir una especificación en una realidad, se puede adquirir un producto, o se puede desarrollar, bien en casa, bien por subcontratación externa. Aceptación. Tanto si es una aplicación nueva como si es modificación de una aplicación anterior, nunca una aplicación debe entrar en operación sin haber sido formalmente aceptada. Despliegue. Consistente en instalar el código en el sistema y configurarlo para que entre en operación. Operación. La aplicación se usa por parte de los usuarios, siendo atendidos los incidentes por parte de usuarios y/o los operadores. Mantenimiento. Bien porque aparecen nuevos requisitos, bien porque se ha detectado un fallo, la aplicación puede requerir un mantenimiento que obligue a regresar a cualquiera de las etapas anteriores, en última instancia a la especificación básica.

MÉTRICA versión 3 La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software. MÉTRICA versión 3 identifica los siguientes elementos:

© Ministerio de Hacienda y Administraciones Públicas

página 79 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

EVS

planificación PSI

gestión de configuración

desarrollo

aseguramiento de la calidad

ASI

DSI

CSI

IAS

gestión de proyectos mantenimiento MSI

seguridad

Ilustración 17. Métrica 3 - Actividades

Métrica 3 especificación

PSI – Planificación del sistema de información EVS – Estudio de viabilidad del sistema ASI – Análisis del sistema de información

adquisición o desarrollo DSI – Diseño del sistema de información. CSI – Construcción del sistema de información aceptación

IAS – Implantación y aceptación del sistema

despliegue operación mantenimiento

MSI – Mantenimiento del sistema de información

Tabla 7. Ciclo de vida y actividades en Métrica 3

7.2.2. Contexto Se debe determinar el contexto general: — política de seguridad y normas — requisitos de cumplimiento normativo — obligaciones contractuales — roles y funciones — criterios de valoración de información y servicios — criterios de valoración de riesgos — criterios de aceptación de riesgos En particular, hay que establecer unos procedimientos operativos que instrumenten la comunicación entre las tareas de desarrollo y las tareas de análisis y tratamiento de riesgos. •

La Dirección aporta los servicios necesarios y la calidad de la seguridad deseada.

•

El equipo de desarrollo aporta los elementos técnicos que materializan la aplicación.

•

El equipo de análisis de riesgos aporta un juicio crítico sobre la seguridad del sistema.

•

La misma Dirección aprueba el riesgo residual.

7.2.3. Fase de especificación: adquisición de datos Se debe recopilar información sobre — la información esencial y sus requisitos de seguridad © Ministerio de Hacienda y Administraciones Públicas

página 80 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

— los servicios esenciales y sus requisitos de seguridad — el contexto en el que se va a desarrollar y explotar el sistema En particular se debe establecer un perfil de amenazas, sean naturales, del entorno o de origen humano, sean accidentales o deliberadas. La caracterización del potencial del atacante debe formar parte de las especificaciones del diseño y su modificación más adelante en el ciclo de vida del sistema será objeto de un nuevo análisis y decisión de tratamiento.

7.2.4. Fase de diseño: estudio de opciones La toma de decisiones de tratamiento de los riesgos puede recomendar salvaguardas evaluando su efecto en los indicadores de impacto y riesgo. Las decisiones que se adopten dependerán de los criterios establecidos en la política de seguridad de la Organización y de otras consideraciones específicas de cada caso. Si bien la política de seguridad establece un marco de referencia que no puede violentarse, es habitual que no prevea todos los detalles técnicos y coyunturales del servicio para tomar decisiones precisas. Debido a la interrelación entre los elementos que constituyen un sistema, no es suficiente proteger un cierto tipo de activos para proteger el conjunto. Por ello, la toma de decisiones de tratamiento es local sobre una parte del sistema, pero siempre con un análisis global sobre la seguridad del conjunto.

Análisis y tratamiento de los riesgos La seguridad requerida para la información que se maneja y los servicios que se prestan quedó fijada en la fase de especificación y no se puede modificar ahora. El equipo de desarrollo y el equipo de análisis de riesgos trabajan de forma iterativa hasta encontrar una solución que satisfaga a ambas partes. Normalmente la iniciativa la toma el equipo de desarrollo proponiendo una solución técnica que responda a los requisitos funcionales del sistema. El equipo de seguridad analiza la propuesta informando de los riesgos asociados y, en su caso, proponiendo salvaguardas que pudieran dejar el riesgo en niveles aceptables. En la medida en que las salvaguardas propuestas afecten al diseño, el equipo rehará su propuesta para un nuevo análisis. La especificación de salvaguardas debe incorporar tanto los mecanismos de actuación como los mecanismos de configuración, monitorización y control de su eficacia y eficiencia. Es frecuente que aparezcan algunos desarrollos específicamente destinados a configurar el conjunto de salvaguardas y a monitorizar su operación. Es posible que el equipo de desarrollo pueda presentar dos o más opciones, en cuyo todas ellas serán evaluadas en lo que respecta a riesgo y salvaguardas requeridas. El informe de riesgos será un elemento más de decisión entre las diferentes opciones. Cuando ambos equipos lleguen a una situación estable, con un diseño técnicamente viable, con un riesgo aceptable y unos requisitos aceptables de recursos, la propuesta se eleva para su aprobación. Como resultado de esta fase, dispondremos de especificaciones técnicas de desarrollo acompañadas de un análisis de los riesgos y sus decisiones de tratamiento.

7.2.5. Soporte al desarrollo: puntos críticos Durante el desarrollo hay que incorporar las salvaguardas aprobadas en la fase de diseño, así como controles que permitan monitorizar su eficacia. Estos requisitos de monitorización se suelen concretar en los siguientes aspectos: — registros de actividad — mecanismos para procesar estos registros e informar de la efectividad del sistema de protección — disparo de alarmas cuando los hecho evidencian un problema de seguridad © Ministerio de Hacienda y Administraciones Públicas

página 81 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

El despliegue de estos elementos viene modulado por el nivel de riesgo potencial que se soporta en cada componente del sistema de información. Durante el desarrollo conviene gestionar los riesgos según se indica en la sección relativa a “Seguridad del Proceso de Desarrollo” más adelante.

7.2.6. Aceptación y puesta en marcha: puntos críticos Cuando el sistema se prueba antes de ponerlo en funcionamiento, debe revisarse que todos los registros de actividad funcionan correctamente, así como los sistemas de procesamiento y de alarma incorporados al sistema. También debe comprobarse que el sistema responde al diseño previsto, concretamente que las salvaguardas están desplegadas, que su despliegue es efectivo y que no existen formas de circunvalarlas u obviarlas: es decir que el sistema no permite puertas traseras fuera de control. Sistema(s) de identificación y autenticación: — todo acceso al sistema requiere que el usuario se identifique y se autentique según lo previsto, bloqueando cualquier otra forma de acceso — los mecanismos de identificación y autenticación están protegidos para evitar que un atacante pueda acceder a información o mecanismos que pongan en peligro su efectividad Sistema(s) de control de acceso: — todo acceso a la información y a los servicios verifica previamente que el usuario tiene las autorizaciones pertinentes Servicios externalizados: cuando parte de la operación del sistema está delegada en un tercero: — hay que revisar los contratos de prestación del servicio — hay que revisar la completitud de los procedimientos de reporte y gestión de incidencias Si el sistema no refleja el modelo cuyos riesgos han sido analizados, será rechazado sin pasar a producción. Hay que verificar que la documentación de seguridad es clara y precisa. Esto incluye normativa, procedimientos operacionales, material de concienciación y de formación. Sin poder ser exhaustivos, las siguientes líneas muestran pruebas de aceptación que conviene realizar: — datos de prueba •

si no son reales, deben ser realistas

•

si no se puede evitar que sean reales, hay que controlar copias y acceso

— pruebas funcionales (de los servicios de seguridad) •

simulación de ataques: verificando que se detectan y reportan

•

pruebas en carga: verificando que no se obvian las medidas de protección

•

intrusión controlada (hacking ético)

— inspección de servicios / inspección de código •

fugas de información: canales encubiertos, a través de los registros, etc.

•

puertas traseras de acceso

•

escalado de privilegios

•

problemas de desbordamiento de registros (buffer overflow)

© Ministerio de Hacienda y Administraciones Públicas

página 82 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

7.2.7. Operación: análisis y gestión dinámicos Durante la vida operativa del sistema podemos encontrarnos con cambios en el escenario que invalidan el análisis de riesgos realizado anteriormente. En entornos formales, el sistema requiere una re-acreditación para seguir operando bajo las nuevas condiciones.

Nuevas amenazas Bien porque se descubren nuevas formas de ataque, bien porque la valoración de la capacidad del atacante se modifica. En estos casos hay que rehacer el análisis y decidir cómo tratar los nuevos resultados.

Vulnerabilidades sobrevenidas Por ejemplo, defectos reportados por los fabricantes. En estos casos hay que analizar la nueva situación de riesgo y determinar cual es su tratamiento adecuado para seguir operando. Lo ideal es parchear el sistema; pero bien porque el parche no existe o porque su aplicación requiere unos recursos de los que no disponemos, podemos encontrarnos en una situación nueva ante la cual hay que decidir cómo tratar el riesgo.

Incidentes de seguridad Los incidentes de seguridad pueden indicarnos un fallo en nuestra identificación de amenazas o en su valoración, obligando a revisar el análisis. Un incidente de seguridad también puede suponer un cambio en el sistema. Por ejemplo, una intrusión significa que no podemos contar con la defensa perimetral: tenemos un nuevo sistema, con el atacante en un nuevo lugar y con unas opciones nuevas.

Cambios en la utilización del sistema A veces un sistema ya operacional no se utiliza como estaba previsto: — nueva información con diferentes requisitos de seguridad — nuevos servicios con diferentes requisitos de seguridad — nuevos procedimientos operativos En términos del análisis de riesgos, esto significa una diferente valoración de los activos o de las salvaguardas desplegadas. Es posible que la alteración del sistema en alguna de las facetas contempladas en los puntos anteriores lleve a unos niveles de riesgo que no sean aceptables, obligando a un ciclo de mantenimiento que rediseñe el sistema o parte de él.

7.2.8. Ciclos de mantenimiento: análisis marginal Cuando se propone una modificación del sistema, los nuevos elementos deben llevar a un nuevo análisis de riesgos, regresando a los ciclos iterativos de propuestas y soluciones de la fase de diseño.

7.2.9 Terminación Cuando un sistema de información se retira del servicio, hay que realizar una serie de tareas de seguridad proporcionadas al riesgo al que están sometidos los componentes del sistema a retirar. En concreto: — proteger el valor de la información manejada: retención y control de acceso — proteger las claves criptográficas de cifra y de autenticación: retención y control de acceso Todo lo que no sea necesario retener se destruirá de forma segura: — datos operacionales © Ministerio de Hacienda y Administraciones Públicas

página 83 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

— copias de seguridad — configuración de los sistemas

7.2.10 Documentación de seguridad La documentación de seguridad evoluciona con el ciclo de vida del sistema: fase

documentación de seguridad

contexto

se revisa la política de seguridad se revisa la normativa de seguridad

especificación

se amplia la normativa de seguridad

diseño

se prepara el índice de procedimientos operacionales de seguridad

desarrollo

se elaboran los procedimientos operacionales de seguridad

aceptación y se validan los procedimientos operacionales de seguridad puesta en operación operación

se actualizan los procedimientos operacionales de seguridad

mantenimiento

se actualizan los procedimientos operacionales de seguridad

Tabla 8. Documentación de seguridad a lo largo del ciclo de vida de las aplicaciones

7.3. SPD – Seguridad del proceso de desarrollo Lo que se comenta en esta sección afecta a todas y cada uno de los procesos y subprocesos de Métrica: PSI, EVS, ASI, DSI, CSI, IAS y MSI. La interfaz de seguridad de Métrica identifica hasta 4 tareas que se repiten en cada proceso. Aquí se tratan de forma compacta:

Activos a considerar En cada proceso se requiere un análisis de riesgos específico que contemple: •

•

los datos que se manejan: •

especificaciones y documentación de los sistemas

•

código fuente

•

manuales del operador y del usuario

•

datos de prueba

el entorno software de desarrollo: •

herramientas de tratamiento de la documentación: generación, publicación, control de documentación, etc.

•

herramientas de tratamiento del código: generación, compilación, control de versiones, etc.

•

el entorno hardware de desarrollo: equipos centrales, puestos de trabajo, equipos de archivo, etc.

•

el entorno de comunicaciones de desarrollo

•

las instalaciones

•

el personal involucrado: desarrolladores, personal de mantenimiento y usuarios (de pruebas)

Actividades Se siguen los siguientes pasos © Ministerio de Hacienda y Administraciones Públicas

página 84 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

1. el equipo de desarrollo expone a través del jefe de proyecto los elementos involucrados 2. el equipo de análisis de riesgos recibe a través del director de seguridad la información de los activos involucrados 3. el equipo de análisis de riesgos realiza el análisis 4. el equipo de análisis de riesgos expone a través de su director el estado de riesgo, proponiendo una serie de medidas a tomar 5. el equipo de desarrollo elabora un informe del coste que supondrían las medidas recomendadas, incluyendo costes de desarrollo y desviaciones en los plazos de entrega 6. la dirección califica el riesgo y decide las salvaguardas a implantar oyendo el informe conjunto de análisis de riesgos y coste de las soluciones propuestas 7. el equipo de análisis de riesgos elabora los informes correspondientes a las soluciones adoptadas 8. el equipo de seguridad elabora la normativa de seguridad pertinente 9. la dirección aprueba el plan para ejecutar el proceso con la seguridad requerida

Resultados del análisis y gestión de riesgos En todos los casos •

salvaguardas recomendadas

•

normas y procedimientos de tratamiento de la información

Otras consideraciones Aunque cada proceso requiere su análisis de riesgos específico, es cierto que se trata de modelos tremendamente similares por lo que el mayor esfuerzo lo llevará el primero que se haga, siendo los demás adaptaciones de aquel primero. En los primeros procesos, notablemente en PSI, pueden aparecer contribuciones de alto nivel que afecten a la normativa de seguridad de la Organización e incluso a la propia política de seguridad corporativa. Entre las normas y procedimientos generados es de destacar la necesidad de una normativa de clasificación de la documentación y procedimientos para su tratamiento. En todos los procesos hay que prestar una especial atención al personal involucrado. Como reglas básicas conviene: •

identificar los roles y las personas

•

determinar los requisitos de seguridad de cada puesto e incorporarlos a los criterios de selección y condiciones de contratación

•

limitar el acceso a la información: sólo por necesidad

•

segregar tareas; en particular evitar la concentración en una sola persona de aquellas aplicaciones o partes de una aplicación que soporten un alto riesgo

7.4. Referencias •

“Seguridad de las Tecnologías de la Información. La construcción de la confianza para una sociedad conectada”, E. Fernández-Medina y R. Moya (editores). AENOR, 2003.

•

Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información. Métrica v3. Consejo Superior de Informática y para el Impulso de la Administración Electrónica, 2000.

© Ministerio de Hacienda y Administraciones Públicas

página 85 (de 127)

Magerit 3.0

Consejos prácticos

8. Consejos prácticos Todo el planteamiento anterior puede quedar un poco abstracto y no permitir al analista progresar con solvencia a través de los pasos indicados si confundiera lo importante con lo esencial. Por ello se ha considerado conveniente incluir algunos comentarios que puedan servir de guía para avanzar. Se recomienda también la consulta del "Catálogo de Elementos" que recopila tipos de activos, dimensiones de valoración, guías de valoración, catálogos de amenazas y de salvaguardas.

8.1. Alcance y profundidad Magerit cubre un espectro muy amplio de intereses de sus usuarios. En el planteamiento de estas guías se ha seguido un criterio “de máximos”, reflejando todo tipo de activos, todo tipo de aspectos de seguridad; en definitiva, todo tipo de situaciones. En la práctica, el usuario puede encontrarse ante situaciones donde el análisis es más restringido. Siguen algunos casos prácticos frecuentes: •

sólo se requiere un estudio de los ficheros afectos a la legislación de datos de carácter personal

•

sólo se requiere un estudio de las garantías de confidencialidad de la información

•

sólo se requiere un estudio de la seguridad de las comunicaciones

•

sólo se requiere un estudio de la seguridad perimetral

•

sólo se requiere un estudio de la disponibilidad de los servicios (típicamente porque se busca el desarrollo de un plan de contingencia)

•

se busca una homologación o acreditación del sistema o de un producto

•

se busca lanzar un proyecto de métricas de seguridad, debiendo identificar qué puntos interesa controlar y con qué grado de periodicidad y detalle

•

etc.

Estas situaciones, frecuentes, se traducen en un ajuste del alcance del análisis. Una estrategia frecuente es identificar como servicio a proporcionar el ámbito que deseamos analizar en detalle y usarlo como perímetro exterior de los activos, incorporando directamente valoraciones inferidas de la información que se maneja y la calidad que se espera del servicio. Además de cubrir un dominio más o menos extenso, pueden darse situaciones en las que se requieren análisis de diferente calado: •

un análisis urgente para determinar los activos críticos

•

un análisis global para determinar las medidas generales

•

un análisis de detalle para determinar salvaguardas específicas para ciertos elementos del sistema de información

•

un análisis de detalle cuantitativo para determinar la oportunidad de un gasto elevado

•

...

En resumen, las tareas que a continuación se detallan hay que adaptarlas 1. horizontalmente al alcance que se requiere (tarea MAR.1) 2. verticalmente a la profundidad oportuna

© Ministerio de Hacienda y Administraciones Públicas

página 86 (de 127)

Magerit 3.0

Consejos prácticos

8.2. Para identificar activos Conviene repetir que sólo interesan los recursos de los sistemas de información que tienen un valor para la Organización, bien en sí mismos, bien porque sobre sus hombros descansan activos de valor. A título de ejemplo, un servidor de presentación web es un activo de escaso valor propio. Esto puede asegurarse porque no es normal que una Organización despliegue un servidor de presentación web salvo que lo necesite para prestar un servicio. Todo su valor es imputado: •

la indisponibilidad del servidor supone la interrupción del servicio; el coste que suponga la interrupción del servicio es el valor de disponibilidad que se le imputará al servidor

•

el acceso no controlado al servidor pone en riesgo el secreto de los datos que presenta; el coste que suponga la pérdida de confidencialidad de los datos es el valor de confidencialidad que se le imputará al servidor

•

... y así con las diferentes dimensiones en consideración

Los intangibles Ciertos elementos de valor de las organizaciones son de naturaleza intangible: •

credibilidad o buena imagen

•

conocimiento acumulado

•

independencia de criterio o actuación

•

intimidad de las personas

•

integridad física de las personas

Estos elementos pueden incorporarse al análisis de riesgos como activos 26 o como elementos de valoración 27 . La cuantificación de estos conceptos es a menudo difícil; pero de una u otra forma nunca puede olvidarse que lo que hay que proteger en última instancia es la misión de la Organización y el valor de ésta reside en estos intangibles como ya se reconocía en Magerit versión 1.0 28 .

Identificación de activos Quizás la mejor aproximación para identificar los activos sea preguntar directamente: •

¿Qué activos son esenciales para que usted consiga sus objetivos?

•

¿Hay más activos que tenga que proteger por obligación legal?

•

¿Hay activos relacionados con los anteriores?

Lo esencial es siempre la información que se maneja y los servicios que se prestan. A veces nos interesa singularizar la diferente información y los diferentes servicios, mientras que otras veces podemos agrupar varias informaciones o varios servicios que son equivalentes a efectos de requisitos de seguridad. Incluso es frecuente hacer paquetes de { información + servicios } que la Dirección entiende como un uno. No siempre es evidente qué es un activo en singular.

26 No todos los autores son unánimes en que sea una buena idea identificar activos intangibles. Es cierto que son activos en el sentido financiero; pero es discutible que sean recursos propiamente dichos del sistema de información. Ocurre que si a los interlocutores se les pregunta durante las entrevistas en términos de valores intangibles de la Organización, se pierde la perspectiva del día a día, pues la mayor parte de los miembros de la Organización tienen objetivos más concretos y cercanos sobre los que sí pueden emitir una opinión fundada. 27 Ver “Catálogo de Elementos”, capítulo “4. Criterios de valoración”. 28 Ver Magerit versión 1.0, “Guía de Procedimientos” / “3. Submodelo de Elementos” / “3.4. Impactos” / ”3.4.3. Tipos”.

© Ministerio de Hacienda y Administraciones Públicas

página 87 (de 127)

Magerit 3.0

Consejos prácticos Es habitual y práctico identificar lo que podríamos llamar subsistemas. Un subsistema típico es un equipo informático, que bajo ese nombre contiene el hardware, los soportes de información (discos), periféricos, sistema operativo y aplicaciones (software) de base tales como ofimática, antivirus, etc. Si es posible, trate ese conglomerado como un activo único. Si por ejemplo en su unidad tiene 300 puestos de trabajo PC, todos idénticos a efectos de configuración y datos que manejan, no es conveniente analizar 300 activos idénticos. Baste analizar un PC genérico que cuya problemática representa la de todos. Agrupar simplifica el modelo. Una buena idea es tener tantos activos como perfiles de configuración de equipos personales. Otras veces se presenta el caso contrario, un servidor central que se encarga de mil funciones: servidor de ficheros, de mensajería, de la intranet, del sistema de gestión documental y ... En este caso conviene segregar los servicios prestados como servicios (internos) independientes. Sólo cuando se llegue al nivel de equipamiento físico habrá que hacer confluir en un único equipo todos los servicios. Si en el futuro se consigue segregar servicios entre varios servidores, entonces es fácil revisar el modelo de valor y dependencias.

Durante la fase de identificación de activos es frecuente que haya ciclos de expansión en los que los activos complejos se desagregan en activos más sencillos, y fases de compresión, en las que muchos activos se agrupan bajo un activo único (es frecuente hablar de subsistemas). Estos ciclos se repiten recurrentemente hasta que — el conjunto de activos sea lo bastante detallado como para no olvidarnos de nada — el número de activos no sea tan grande que nos perdamos — la denominación de los activos no sea ambigua y recoja la terminología habitual en la Organización en pocas palabras, el modelo debe ser manejable y fácil de explicar a los que van a tomar decisiones a partir de nuestras conclusiones.

8.3. Para descubrir y modelar las dependencias entre activos Siempre hay que empezar poniendo en lo más alto la información y los servicios. Depende de cada circunstancia el que sea antes la información o los servicios; pero lo más frecuente es que el valor esté en la información y deba ser respetado por los servicios que la manejan.

Ilustración 18. Dependencias al nivel superior

A veces es más difícil de lo esperado porque los responsables de los activos suelen estar más preocupados por el encadenamiento funcional entre activos que por la dependencia en el sentido de propagación de valor (requisitos de seguridad). Es necesario transmitir al interlocutor que no se busca qué es necesario para que el sistema funciones, sino al revés, se busca dónde puede fallar el sistema o, más precisamente, dónde puede verse comprometida la seguridad de los activos.

© Ministerio de Hacienda y Administraciones Públicas

página 88 (de 127)

Magerit 3.0

Consejos prácticos

•

Si unos datos son importantes por su confidencialidad, se necesita saber en qué sitios van a residir dichos datos y por qué lugares van a circular: en esos puntos pueden ser revelados.

•

Si unos datos son importantes por su integridad, se necesita saber en qué sitios van a residir dichos datos y por qué lugares van a circular: en esos puntos pueden ser alterados.

•

Si un servicio es importante por su disponibilidad, se necesita saber qué elementos se usan para prestar dicho servicio: el fallo de esos elementos detendría el servicio.

Estas consideraciones pueden plantearse con argumentos del tipo: •

si usted quisiera acceder a estos datos, ¿dónde atacaría para robarlos?

•

si usted quisiera detener este servicio, ¿dónde atacaría para estropearlo?

Este planteamiento de “póngase en el lugar del atacante” es el que da pie a las técnicas denominadas “árboles de ataque” 29 que van parejas a lo que en esta metodología se denominan dependencias. En efecto, un activo puede ser atacado directamente o indirectamente a través de otro activo del que dependa. Las anteriores consideraciones pueden desembocar en un diagrama “plano” de dependencias que se puede (y conviene a efectos prácticos) convertir en un árbol más compacto. Así, es normal decir que los servicios dependen del equipamiento, que depende a su vez de los locales donde se ubican los equipos, sin necesidad de explicitar que los servicios dependen de los locales 30 . Es frecuente identificar “servicios internos” o “servicios horizontales” que son agrupaciones de activos para una cierta función. Estos servicios intermedios son eficaces para compactar el grafo de dependencias, pues las dependencias de dichos servicios se interpretan sin ambigüedad como dependencia de todos los elementos que prestan el servicio.

Ilustración 19. Servicios internos

Cuando se usen diagramas de flujo de datos o diagramas de procesos, no debe preocupar tanto la ruta que siguen los datos como el conjunto (desordenado) de elementos que intervienen. Un proceso depende de todos los activos que aparecen en su diagrama. Unos datos dependen de todos los sitios por donde pasen. Tanto en unos como en otros diagramas es frecuente encontrar descripciones jerarquizadas donde un proceso se subdivide en niveles de mayor detalle. Estas jerarquías de diagramas pueden ayudar a elaborar el grafo de dependencias. Hay organizaciones donde está muy clara la información que hay que tratar y a partir de ella podemos identificar los servicios que la tratan y el equipamiento desplegado.

29 Ver “Guía de Técnicas”. 30 En la "Guía de Técnicas" encontrará el modelo algorítmico para calcular las dependencias totales entre activos a partir de las dependencias directas.

© Ministerio de Hacienda y Administraciones Públicas

página 89 (de 127)

Magerit 3.0

Consejos prácticos

Hay organizaciones más centradas en los servicios que prestan, pudiendo partir de una enumeración de servicios para asociarles la información que manejan y el equipamiento desplegado. Hay veces que el análisis empieza por el inventariado de equipamiento y luego se va buscando qué servicios se prestan y qué información se trata en el sistema.

Errores típicos No es correcto decir que una aplicación depende de la información que maneja. El razonamiento de quien tal afirma es que “la aplicación no funcionaría sin datos”, lo que es correcto; pero no es lo que interesa reflejar. Más bien es todo lo contrario: la [seguridad de la] información depende de la aplicación que la maneja. En términos de servicio, se puede decir que la aplicación no vale para nada sin datos. Pero como el valor es una propiedad de la información, y la información es alcanzable por medio de la aplicación, son los requisitos de seguridad de la información los que hereda la aplicación. Luego la información depende de la aplicación. En otras palabras: a través de la aplicación puede accederse a la información, convirtiéndose la aplicación en la vía de ataque. Dado que datos y aplicaciones suelen aunar esfuerzos para la prestación de un servicio, el valor del servicio se transmite tanto a los datos como a las aplicaciones intervinientes. mal

bien

aplicación → información información → aplicación Tabla 9. Dependencias de la información y las aplicaciones

En este contexto, a veces conviene distinguir entre los datos y la información. La información es un bien esencial, siendo los datos una concreción TIC de la información. La información es valiosa, lo demás es valioso en la medida en que contiene información. La información que maneja un sistema o bien se pone por encima de los servicios, o bien se agrupa 1. información → servicios → equipamiento (incluyendo datos, aplicaciones, equipos, …) 2. { información + servicios } → equipamiento (incluyendo datos, aplicaciones, equipos, …) No es correcto decir que una aplicación dependa del equipo donde se ejecuta. El razonamiento de quien tal afirma es que “la aplicación no funcionaría sin equipo”, lo que es correcto; pero no es lo que interesa reflejar. Si tanto la aplicación como el equipo son necesarios para prestar un servicio, se debe decir explícitamente, sin buscar caminos retorcidos. mal

bien

•

servicio → aplicación • servicio → aplicación

•

aplicación → equipo • servicio → equipo

Tabla 10. Dependencias de los servicios

© Ministerio de Hacienda y Administraciones Públicas

página 90 (de 127)

Magerit 3.0

Consejos prácticos

Ilustración 20. Jerarquía de dependencias

Los errores comentados a veces pasan desapercibidos mientras el sistema es muy reducido (sólo hay un servicio, una aplicación y un equipo); pero aparecen en cuanto el sistema crece. Por ejemplo, una aplicación X puede ejecutarse en diferentes equipos con diferentes datos para prestar diferentes servicios. Resulta entonces imposible relacionar la aplicación con uno o más equipos, salvo considerando cada caso

Ilustración 21. Dependencias entre activos para la prestación de unos servicios

¿Están bien modeladas las dependencias? Establecer dependencias es una tarea delicada que puede acabar mal. Antes de dar por bueno un modelo de dependencias hay que trazar para cada activo todos los activos de los que depende directa o indirectamente. Y se debe responder positivamente a las preguntas de si •

¿Están todos los que son? Es decir, si se han identificado todos los activos en los que puede ser atacado indirectamente el activo valorado.

•

¿Son todos los que están? Es decir, si realmente el activo valorado puede ser atacado en todos esos activos de los que depende

Como la relación de dependencia propaga el valor acumulado, encontrar un activo sin valor acumulado es síntoma de que las dependencias están mal modeladas o, simplemente, que el activo es irrelevante. En otras palabras: para saber si las dependencias están bien establecidas, estudie el valor acumulado.

8.4. Para valorar activos Siempre conviene valorar la información que constituye la razón de ser del sistema de información. Si se han modelado servicios esenciales (prestados a usuarios externos al dominio de análisis), conviene valorarlos igualmente. © Ministerio de Hacienda y Administraciones Públicas

página 91 (de 127)

Magerit 3.0

Consejos prácticos

Es fácil identificar activos de tipo información y valorarlos siguiendo clasificaciones pautadas como su carácter personal o su clasificación de seguridad. Pero pasa a ser mucho más delicado valorar datos de tipo comercial u operacional porque hay que ir a las consecuencias del daño sufrido. Por ello en las metodologías de gestión de riesgos se requiere que la Organización establezca unos criterios para valorar, criterios que trascienden a los analistas y que deben proceder de los órganos superiores que son los encargados de valorar el sistema y de recibir los resultados del análisis. El resto de los activos puede frecuentemente pasar sin valorar, pues su valor más importante es soportar la información y/o los servicios y de ese cálculo se encargan las relaciones de dependencias. No obstante, si considera oportuno valorar otro tipo de activos ... Los activos más sencillos de valorar son aquellos que se adquieren en un comercio. Si se avería, hay que poner otro. Esto cuesta dinero y tiempo (o sea, más dinero). Se habla de un coste de reposición. Salvo notorias excepciones, frecuentemente ocurre que el coste de los activos físicos es despreciable frente a otros costes, pudiendo obviarse. Es difícil valorar las personas, en general; pero si un puesto supone una formación lenta y trabajosa, hay que tener en cuenta que la persona que desempeña ese puesto se convierte en muy valiosa, pues su “coste de reposición” es notable. En cualquier caso, para valorar un activo se debe identificar al responsable, que será la persona adecuada para valorar el activo. A este responsable hay que ayudarle con tablas de valoración como las del capítulo 4 del "Catálogo de Elementos" que, adaptadas al caso concreto, permitan traducir la percepción de valor en una medida cualitativa o cuantitativa del mismo. A menudo no existe el responsable único y singular de un activo y/o servicio, sino que varias personas dentro de la Organización tienen opinión cualificada al respecto. Hay que oírlas todas. Y llegar a un consenso. Si el consenso no es obvio, puede requerir un careo: junte a los que opinan e intente que lleguen a una opinión común un Delphi 31 : mande cuestionarios a los que opinan e intente que converjan a una opinión común En los procesos de valoración de activos es frecuente recurrir a personas diferentes para valorar activos diferentes. Y es frecuente que cada entrevistado considere sus activos como de la máxima importancia; tanto más frecuente cuanto más especializado esté el entrevistado. Como muchas valoraciones son estimaciones de valor, hay que cuidar que todo el mundo use la misma escala de estimar. Por ello es importante usar una tabla como la del capítulo 4 del "Catálogo de Elementos", directamente o adaptada al caso concreto. Y es importante que tras haber preguntado a los que entienden de cada activo, todos reciban una copia de la valoración global del sistema para que aprecien el valor relativo de “sus activos” y opinen en contexto.

Datos de carácter personal Los datos de carácter personal están tipificados por leyes y reglamentos, requiriendo de la Organización que adopte una serie de medidas de protección independientes del valor del activo 32 . La forma más realista de enfrentarse a los activos de carácter personal es caracterizarlos como tales en el nivel que corresponda y, además, determinar su valor: el daño que supondría su revelación o alteración indebida. Con esta aproximación, el análisis de impactos y riesgos permitirá proteger los datos tanto por obligación legal como por su propio valor.

31 Ver "Guía de Técnicas". 32 Es posible aproximarse a la valoración de los activos que son de carácter personal cuantificando la multa que impondría la Agencia de Protección de Datos. Esta aproximación no vale en un análisis cualitativo. En un análisis cuantitativo, esta aproximación parte de la hipótesis de que lo peor que puede pasar con ese dato es ser motivo de multa.

© Ministerio de Hacienda y Administraciones Públicas

página 92 (de 127)

Magerit 3.0

Consejos prácticos

8.5. Para identificar amenazas La tarea aparece como imposible: para cada activo, en cada dimensión, identificar amenazas. Se puede partir de la experiencia pasada, propia o de organizaciones similares. Lo que ha ocurrido puede repetirse y, en cualquier caso, sería impresentable no tenerlo en cuenta. Complementariamente, un catálogo de amenazas como el incluido en el "Catálogo de Elementos" ayuda a localizar lo que conviene considerar en función del tipo de activo y de las dimensiones en las que tiene un valor propio o acumulado. A menudo se recurre a idear escenarios de ataque que no son sino dramatizaciones de cómo un atacante se enfrentaría a nuestros sistemas. Esta técnica es la que a veces se denomina “árboles de ataque”. Póngase en la piel del atacante e imagine qué haría con sus conocimientos y su capacidad económica. Puede que tenga que plantearse diferentes situaciones dependiendo del perfil técnico del atacante o de sus recursos técnicos y humanos. Estas dramatizaciones son interesantes para poder calcular impactos y riesgos; pero además serán muy útiles a la hora de convencer a la alta dirección y a los usuarios de por qué una amenaza no es teórica sino muy real. Es más, cuando evalúe las salvaguardas puede ser conveniente revisar estos escenarios de ataque. Es habitual que las herramientas de soporte al análisis de riesgos aporten perfiles típicos para apoyar en esta tarea.

8.6. Para valorar amenazas La tarea es desmoralizadora: para cada activo en cada dimensión, determinar la degradación que causarían y la probabilidad de ocurrencia. Siempre que sea posible conviene partir de datos estándar. En el caso de desastres naturales o accidentes industriales, se puede disponer de series históricas, genéricas o del lugar en el que se ubican los equipos de nuestro sistema de información bajo estudio. Probablemente también se disponga de un historial que informe de lo que es frecuente y de lo que “no pasa nunca”. Más complicado es calificar los errores humanos; pero la experiencia permite ir aquilatando valores realistas. Y lo más complejo es calificar los ataques deliberados pues dependen de la suerte, buena o mala. Hay muchos motivos que agudizan el peligro de una amenaza: •

que no requiera grandes conocimientos técnicos por parte del atacante 33

•

que no requiera gran inversión en equipo por parte del atacante 34

•

que haya un enorme beneficio económico en juego (que el atacante puede enriquecerse)

•

que haya un enorme beneficio en juego (que el atacante pueda salir fuertemente beneficiado, en su estima, en su conocimiento por todo el mundo, ...); por lo que más quiera, evite los retos y jamás alardee de que su sistema de información es invulnerable: no lo es y no tiene gracia que se lo demuestren

•

que haya un mal ambiente de trabajo, semilla de empleados descontentos que se vengan a través de los sistemas, simplemente para causar daño

•

que haya una mala relación con los usuarios externos, que se vengan a través de nuestros sistemas

33 Hay que estar atentos a la “comercialización” de las herramientas de ataque pues un ataque puede requerir un gran experto para realizarlo manualmente (es decir, es poco frecuente); pero si el experto empaqueta su ataque en una herramienta con una simple interfaz gráfica, usar la herramienta se convierte en un deporte que no requiere del atacante sino ausencia de escrúpulos (es decir, la amenaza ha pasado a ser muy frecuente). 34 Hay que tener muy en cuenta que Internet es una red inmensa de poder de cómputo. Si alguien sabe cómo organizarse, no es difícil poner a la red a “trabajar para mí” lo que supone que el atacante disponga de muchísimos más medios efectivos que el atacado.

© Ministerio de Hacienda y Administraciones Públicas

página 93 (de 127)

Magerit 3.0

Consejos prácticos

Partiendo de un valor estándar, hay que ir aumentando o disminuyendo sus calificaciones de frecuencia y degradación hasta reflejar lo más posible el caso concreto. A menudo no es evidente determinar el valor correcto y es necesario recurrir a simulaciones que orienten. El uso de algún tipo de herramienta es muy útil para estudiar las consecuencias de un cierto valor, lo que algunos autores denominan la sensibilidad del modelo a cierto dato. Si se aprecia que los resultados cambian radicalmente ante pequeñas alteraciones de una estimación de frecuencia o degradación, hay que (1) ser realistas y (2) prestar extrema atención a por qué el sistema es tan sensible a algo tan concreto y tomar medidas orientadas a independizar el sistema; es decir, a no hacer crítica una cierta amenaza. Recuerde que la frecuencia no afecta al impacto, por lo que estudiando el impacto se puede ajustar la degradación y, posteriormente, estudiando el riesgo se puede ajustar la frecuencia. Nunca se debe aceptar un valor injustificado de degradación en la esperanza de compensarlo con la frecuencia, pues la estimación del impacto es importante en sí misma, además de la de riesgo. Sea cual sea la decisión final que se tome para estimar un valor, hay que documentarla pues antes o después se pedirán explicaciones, sobre todo si como consecuencia se van a recomendar salvaguardas costosas. Es habitual que las herramientas de soporte al análisis de riesgos aporten perfiles típicos para apoyar en esta tarea.

8.7. Para seleccionar salvaguardas Probablemente la única forma es tirar de catálogo. Use un (sistema) experto que le ayude a ver qué solución es adecuada para cada combinación de •

tipo de activo

•

amenaza a la que está expuesto

•

dimensión de valor que es motivo de preocupación

•

nivel de riesgo

A menudo encontrará muchas soluciones para un problema, con diferentes calidades. En estos casos debe elegir una solución proporcionada a los niveles de impacto y riesgo calculados. Muchas salvaguardas son de bajo coste, bastando configurar adecuadamente los sistemas u organizar normativa para que el personal haga las cosas de forma adecuada. Pero algunas contra medidas son realmente costosas (en su adquisición, en su despliegue, en su mantenimiento periódico, en la formación del personal a su cargo, ...). En estos casos conviene ponderar si el coste de la salvaguarda no supera el riesgo potencial; es decir, tomar siempre decisiones de gasto que supongan un ahorro neto. Por último, y no menos importante, a la hora de desplegar salvaguardas hay que considerar su facilidad de uso. Lo ideal es que la salvaguarda sea transparente de forma que el usuario no tenga que hacer nada o, en su defecto, cuanto menos haya que hacer, mejor. Simplemente porque una salvaguarda de complejo manejo requiere personal especializado y añade a las amenazas que ya tenía el sistema la amenaza que supone su defectuosa utilización.

8.8. Aproximaciones sucesivas El lector ya se habrá percibido de que el análisis de riesgos puede ser muy laborioso, requiriendo tiempo y esfuerzo. Además, hay que introducir muchos elementos que no son objetivos, sino estimaciones del analista, lo que implica que haya que explicar y consensuar lo que significa cada cosa para no estar expuestos a impactos o riesgos que se ignoran o se infravaloran, ni convertir la paranoia en un dispendio de recursos injustificados. Si hay que ser prácticos y efectivos, conviene realizar aproximaciones sucesivas. Se empieza por un análisis somero, de alto nivel, identificando rápidamente lo más crítico: activos de gran valor, vulnerabilidades manifiestas o, simplemente, recomendaciones de libro de texto porque no hay nada más prudente que aprender en cabeza ajena, aprovechando la experiencia de los demás. Este análisis de riesgos es imperfecto, evidentemente; pero cabe confiar en que lleve en la direc© Ministerio de Hacienda y Administraciones Públicas

página 94 (de 127)

Magerit 3.0

Consejos prácticos

ción correcta. Los párrafos siguientes dan indicaciones de cómo orientarse rápidamente hacia el objetivo final: tener impactos y riesgos bajo control. Nótese que estas aproximaciones imperfectas permiten desplegar rápidamente sistemas razonablemente protegidos cuando no hay tiempo para un análisis de riesgos en toda su plenitud. Cuando, con tiempo, se llegue a la fase de gestión de riesgos tras un análisis exhaustivo, muy probablemente ocurra que muchas salvaguardas están ya dispuestas, necesitándose sólo la introducción de algunas nuevas y/o la mejora de la eficacia de las existentes. No es pues trabajo perdido seguir estas aproximaciones informales.

8.8.1. Protección básica Es frecuente oír hablar de medidas básicas de protección (baseline) que deberían implantarse en todos los sistemas, salvo que se demuestre que no son pertinentes a algún caso particular. Por favor, no discuta; ni lo dude: a sus sistemas de información no debe poder acceder cualquiera en cualquier momento. Puede protegerlos física o lógicamente, poniéndolos en una sala donde no entra cualquiera, o imponiendo una identificación de acceso lógico. Pero ¡protéjalos! Este tipo de razonamientos se pueden aplicar con frecuencia y llevan a desplegar un mínimo de salvaguardas “de puro sentido común”. Una vez avanzado lo que es obvio y no se debería nunca discutir, se puede avanzar a niveles más elaborados, específicos de cada sistema. Para aplicar un tratamiento básico se requiere un catálogo de salvaguardas. Existen numerosas fuentes, entre las que cabe destacar: •

normas internacionales, por ejemplo [ISO 27002]

•

normas sectoriales

•

normas corporativas, especialmente frecuentes en pequeñas delegaciones de grandes organizaciones

Las ventajas de protegerse por catálogo son: •

es muy rápido

•

cuesta menos esfuerzo que ponerse a analizar y decidir

•

se logra un nivel homogéneo con otras organizaciones parecidas

Los inconvenientes de protegerse por catálogo son: •

el sistema puede protegerse frente a amenazas que no padece, lo que supone un gasto injustificado

•

el sistema puede estar inadecuadamente protegido frente a amenazas reales

En general, con la protección básica no se sabe lo que se hace y, aún estando probablemente en la senda correcta, no hay medida de si falta o si sobra. No obstante, puede ser un punto de partida útil para refinar posteriormente. La protección por catálogo puede refinarse un poco considerando el valor y la naturaleza de los activos o cuantificando las amenazas.

En base a la tipificación de los activos Si usted tiene datos de carácter personal calificados de nivel alto, tiene que cifrarlos. Si usted tiene datos clasificados como confidenciales, tiene que etiquetarlos y cifrarlos. Aparte de cumplir con la legislación y normativa específica, habrá llevado a cabo una especie de “vacunación preventiva” de activos que seguro que son importantes. Si usted tiene una red local conectada al exterior, tiene que poner un cortafuegos en el punto de conexión. etc. © Ministerio de Hacienda y Administraciones Públicas

página 95 (de 127)

Magerit 3.0

Consejos prácticos

En base al valor de los activos Si usted tiene todos los datos operacionales en soporte informático, tiene que hacer copias de seguridad. Si usted tiene equipos informáticos, manténgalos al día con las actualizaciones del fabricante. Lo que vale hay que cuidarlo, por si le pasara algo, sin entrar en muchas precisiones de qué les puede pasar exactamente.

En base a las amenazas Si se trata de un sistema de la llamada administración electrónica (tramitación administrativa no presencial) o si los sistemas se usan para comerciar electrónicamente (compras y ventas no presenciales), registre cuidadosamente quién hace qué en cada momento pues se enfrentará a incidencias con los usuarios, teniendo que determinar quién tiene razón y quien paga los perjuicios. También habrá quien quiera usar sus servicios sin tener derecho a ello (fraude). Lo que se puede necesitar, es necesario, y parte de las responsabilidades del responsable de seguridad es disponer de la información correcta cuando haga falta.

En base a la exposición Si usted tiene una red de equipos antiguos y se conecta a Internet, debe instalar un cortafuegos. Si tiene usted una aplicación en producción, debe mantenerla al día aplicando mejoras y corrigiendo los defectos anunciados por el fabricante. Cuando se sabe que los sistemas de información son vulnerables, hay que protegerlos.

© Ministerio de Hacienda y Administraciones Públicas

página 96 (de 127)

Magerit 3.0

Glosario

Apéndice 1. Glosario Diferentes autores u organizaciones definen los mismos términos de diferentes formas y maneras. Las siguientes tablas recopilan definiciones acordes al sentido en el cual se emplean los términos en esta guía metodológica, tanto en español como en inglés. De las múltiples definiciones se ha seleccionado la preferida en Magerit v2, resaltándola en negrita. Cuando la definición procede de alguna fuente, se cita esta. La ausencia de fuente indica que es definición propia de esta guía. Salvo razones en contra, siempre se ha preferido mantener la definición propuesta en Magerit v1 (1997).

A1.1. Términos en español Aceptación del riesgo

Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010]

Acreditación

Acción de facultar a un sistema o red de información para que procese datos sensibles, determinando el grado en el que el diseño y la materialización de dicho sistema cumple los requerimientos de seguridad técnica preestablecidos. [CESID:1997] Accreditation: Formal declaration by the responsible management approving the operation of an automated system in a particular security mode using a particular set of safeguards. Accreditation is the official authorization by management for the operation of the system, and acceptance by that management of the associated residual risks. Accreditation is based on the certification process as well as other management considerations. [154431:2005]

Activo

Componente o funcionalidad de un sistema de información susceptible de ser atacado deliberada o accidentalmente con consecuencias para la organización. Incluye: información, datos, servicios, aplicaciones (software), equipos (hardware), comunicaciones, recursos administrativos, recursos físicos y recursos humanos. [UNE 71504:2008] Recursos del sistema de información o relacionados con éste, necesarios para que la Organización funcione correctamente y alcance los objetivos propuestos por su dirección. [Magerit: 2006] Recursos del sistema de información o relacionados con éste, necesarios para que la Organización funcione correctamente y alcance los objetivos propuestos por su dirección. [Magerit:1997] Bienes: En la teoría de los valores, la realidad que posee un valor positivo y por ello es estimable. [DRAE] Asset: A component or part of the total system. Assets may be of four types: physical, application software, data, or end user services. [CRAMM:2003] Asset: Something of value to the enterprise. [Octave:2003] Asset: Any information resource with value that is worth protecting or preserving. [TDIR:2003] Assets: Information or resources to be protected by the countermeasures of a Target of Evaluation. [CC:1999]

Amenaza

Causa potencial de un incidente que puede causar daños a un sistema de información o a una organización. [UNE 71504:2008] Potential cause of an unwanted incident, which may result in harm to a system or organization. [ISO/IEC 27000:2009]

© Ministerio de Hacienda y Administraciones Públicas

página 97 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Eventos que pueden desencadenar un incidente en la Organización, produciendo daños materiales o pérdidas inmateriales en sus activos. [Magerit:2006] Eventos que pueden desencadenar un incidente en la Organización, produciendo daños materiales o pérdidas inmateriales en sus activos. [Magerit:1997] Condición del entorno del sistema de información que, dada una oportunidad, podría dar lugar a que se produjese una violación de la seguridad. [CESID:1997] Threat: Any circumstance or event with the potential to adversely impact agency operations (including mission, functions, image, or reputation), agency assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. [800-53:2009] Threat: Any circumstance or event with the potential to adversely impact an information system through unauthorized access, destruction, disclosure, modification of data, and/or denial of service. [CNSS:2003] Threat: An activity, deliberate or unintentional, with the potential for causing harm to an automated information system or activity. [TDIR:2003] Threat: Any circumstance or event that could harm a critical asset through unauthorized access, compromise of data integrity, denial or disruption of service, or physical destruction or impairment. [CIAO:2000] A threat is an indication of a potential undesirable event. [NSTISSI:1998] Threat: A potential violation of security. [7498-2:1989]

Análisis de impacto Estudio de las consecuencias que tendría una parada de X tiempo sobre la Organización. Análisis de riesgos Proceso sistemático para estimar la magnitud de los riesgos a que está expuesta una Organización. Análisis del riesgo – Proceso que permite comprender la naturaleza del riesgo y determinar el nivel de riesgo. [UNE-ISO Guía 73:2010] Identificación de las amenazas que acechan a los distintos componentes pertenecientes o relacionados con el sistema de información (conocidos como ‘activos’); para determinar la vulnerabilidad del sistema ante esas amenazas y para estimar el impacto o grado de perjuicio que una seguridad insuficiente puede tener para la organización, obteniendo cierto conocimiento del riesgo que se corre. [Magerit:1997] Risk assessment: Process of evaluating the risks of information loss based on an analysis of threats to, and vulnerabilities of, a system, operation or activity. [OPSEC] Risk Analysis: Examination of information to identify the risk to an information system. [CNSS:2003] Risk Assessment:: Process of analyzing threats to and vulnerabilities of an information system, and the potential impact resulting from the loss of information or capabilities of a system. This analysis is used as a basis for identifying appropriate and cost-effective security countermeasures. [CNSS:2003] Risk Analysis: An analysis of system assets and vulnerabilities to establish an expected loss from certain events based on estimated probabilities of occurrence. [TDIR:2003] © Ministerio de Hacienda y Administraciones Públicas

página 98 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Risk Assessment: A study of vulnerabilities, threats, likelihood, loss or impact, and theoretical effectiveness of security measures. The process of evaluating threats and vulnerabilities, known and postulated, to determine expected loss and establish the degree of acceptability to system operations. [TDIR:2003]

Ataque

Intento de destruir, exponer, alterar o inhabilitar un sistema de información o la información que el sistema maneja, o violar alguna política de seguridad de alguna otra manera. [ISO/IEC 18043:2006] Cualquier acción deliberada encaminada a violar los mecanismos de seguridad de un sistema de información. [CESID:1997]

Auditoría de seguridad

Estudio y examen independiente del historial y actividades de un sistema de información, con la finalidad de comprobar la idoneidad de los controles del sistema, asegurar su conformidad con la estructura de seguridad y procedimientos operativos establecidos, a fin de detectar brechas en la seguridad y recomendar cambios en los procedimientos, controles y estructuras de seguridad.

Autenticidad

Propiedad o característica consistente en que una entidad es quien dice ser o bien que garantiza la fuente de la que proceden los datos. [UNE 71504:2008] Aseguramiento de la identidad u origen. [Magerit:2006] Autenticación: Característica de dar y reconocer la autenticidad de los activos del dominio (de tipo información) y/o la identidad de los actores y/o la autorización por parte de los autorizadores, así como la verificación de dichas tres cuestiones. [Magerit:1997] Authenticity: Having an undisputed identity or origin. [OPSEC] Authenticity: The property of being genuine and being able to be verified and trusted; confidence in the validity of a transmission, a message, or message originator. [800-53:2009]

Certificación

Confirmación del resultado de una evaluación, y que los criterios de evaluación utilizados fueron correctamente aplicados.

Confidencialidad

Propiedad o característica consistente en que la información ni se pone a disposición ni se revela a individuos, entidades o procesos no autorizados. [UNE 71504:2008] Aseguramiento de que la información es accesible sólo para aquellos autorizados a tener acceso. [Magerit:2006] Característica que previene contra la divulgación no autorizada de activos del dominio. [Magerit:1997] Confidentiality: An assurance that information is not disclosed to unauthorized entities or processes (DOD JP 1994; JCS 1997) [OPSEC] Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. [800-53:2009] Confidentiality: The requirement of keeping proprietary, sensitive, or personal information private and inaccessible to anyone that is not authorized to see it. [Octave:2003] Confidentiality: Assurance that information is not disclosed to unauthorized persons, processes, or devices. [CNSS:2003] [TDIR:2003]

© Ministerio de Hacienda y Administraciones Públicas

página 99 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Confidentiality: The property that information is not made available or disclosed to unauthorized individuals, entities, or processes. [ISO 7498-2:1989]

Contra medida

Véase salvaguarda.

Control

Véase salvaguarda.

Declaración de aplicabilidad

Documento formal en el que, para un conjunto de salvaguardas, se indica sin son de aplicación en el sistema de información bajo estudio o si, por el contrario, carecen de sentido.

Degradación

Pérdida de valor de un activo como consecuencia de la materialización de una amenaza.

Dimensión de seguridad

Un aspecto, diferenciado de otros posibles aspectos, respecto del que se puede medir el valor de un activo en el sentido del perjuicio que causaría su pérdida de valor.

Disponibilidad

Aseguramiento de que los usuarios autorizados tienen acceso cuando lo requieran a la información y sus activos asociados. [UNE 71504:2008] Característica que previene contra la denegación no autorizada de acceso a activos del dominio. [Magerit:1997] Availability: The assurance that data transmissions, computer processing systems, and/or communications are not denied to those who are authorized to use them (JCS 1997) [OPSEC] Availability: Ensuring timely and reliable access to and use of information. [800-53:2009] Availability: The extend to which, or frequency with which, an asset must be present or ready for use. [Octave:2003] Availability: Timely, reliable access to data and information services for authorized users. [CNSS:2003] [TDIR:2003] [CIAO:2000] Availability: The property of being accessible and usable upon demand by an authorized entity. [ISO 7498-2:1989]

Estado de riesgo

Informe: Caracterización de los activos por su riesgo residual; es decir lo que puede pasar tomando en consideración las salvaguardas desplegadas.

Evaluación de salvaguardas

Informe: Evaluación de la eficacia de las salvaguardas existentes en relación al riesgo que afrontan.

Frecuencia

Tasa de ocurrencia de una amenaza. Número de sucesos o de efectos en una unidad de tiempo definida. [UNEISO Guía 73:2010]

Gestión de riesgos Actividades coordinadas para dirigir y controlar una organización el lo relativo al riesgo. [UNE-ISO Guía 73:2010] Selección e implantación de salvaguardas para conocer, prevenir, impedir, reducir o controlar los riesgos identificados. [Magerit:2006] Selección e implantación de las medidas o ‘salvaguardas’ de seguridad adecuadas para conocer, prevenir, impedir, reducir o controlar los riesgos identificados y así reducir al mínimo su potencialidad o sus posibles perjuicios. La gestión de riesgos se basa en los resultados obtenidos en el análisis de los riesgos. [Magerit:1997] © Ministerio de Hacienda y Administraciones Públicas

página 100 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Risk management: A security philosophy which considers actual threats, inherent vulnerabilities, and the availability and costs of countermeasures as the underlying basis for making security decisions (JSCR 1994). [OPSEC] Risk management: Process of identifying and applying countermeasures commensurate with the value of the assets protected based on a risk assessment. [CNSS:2003] The identification, assessment, and mitigation of probabilistic security events (risks) in information systems to a level commensurate with the value of the assets protected. [CIAO:2000]

Impacto

Consecuencia que sobre un activo tiene la materialización de una amenaza. Consecuencia – Resultado de un suceso que afecta a los objetivos. [UNEISO Guía 73:2010] Consecuencia que sobre un activo tiene la materialización de una amenaza. [Magerit:1997] Impact: The effect of a threat on an organization's mission and business objectives. [Octave:2003] Impact: The effect on the organisation of a breach in security. [CRAMM:2003]

Impacto residual

Impacto remanente en el sistema tras la implantación de las salvaguardas determinadas en el plan de seguridad de la información.

Incidente de seguridad

Suceso (inesperado o no deseado) con consecuencias en detrimento de la seguridad del sistema de información. [UNE 71504:2008] Evento con consecuencias en detrimento de la seguridad del sistema de información. [Magerit:2006] Information security event: identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of controls, or a previously unknown situation that may be security relevant. [ISO/IEC 27000:2009] Information security incident: single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security. [ISO/IEC 27000:2009] Incident: A successful or unsuccessful action attempting to circumvent technical controls, organizational policy, or law. This is often called an attack. [TDIR:2003]

Informe de insuficiencias

Informe: Ausencia o debilidad de las salvaguardas que aparecen como oportunas para reducir el riesgo sobre el sistema.

Integridad

Propiedad o característica consistente en que el activo no ha sido alterado de manera no autorizada. [UNE 71504:2008] Característica que previene contra la modificación o destrucción no autorizadas de activos del dominio. [Magerit:1997] Information integrity: The state that exists when information is unchanged from its source and has not been accidentally or intentionally modified, altered, or destroyed (NSC EO 1995; JCS 1997). [OPSEC]

© Ministerio de Hacienda y Administraciones Públicas

página 101 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Integrity: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. [800-53:2009] Integrity: the authenticity, accuracy, and completeness of an asset. [Octave:2003] Data integrity: A condition existing when data is unchanged from its source and has not been accidentally or maliciously modified, altered, or destroyed. [CNSS:2003] [TDIR:2003] [CIAO:2000] Data integrity: The data quality that exists as long as accidental or malicious destruction, alteration, or loss of data does not occur. [CRAMM:2003] Integrity: Condition existing when an information system operates without unauthorized modification, alteration, impairment, or destruction of any of its components. [CIAO:2000]

Mapa de riesgos

Informe: Relación de las amenazas a que están expuestos los activos. Threat Analysis: The examination of all actions and events that might adversely affect a system or operation. [TDIR:2003] Threat Assessment: An evaluation of the nature, likelihood, and consequence of acts or events that could place sensitive information and assets as risk. [TDIR:2003]

Medida de seguridad

Véase salvaguarda.

Modelo de valor

Informe: Caracterización del valor que representan los activos para la Organización así como de las dependencias entre los diferentes activos.

Plan de seguridad

Conjunto de proyectos de seguridad que permiten materializar las decisiones de gestión de riesgos.

Probabilidad

Probabilidad (likelihood) – Posibilidad de que un hecho se produzca. [UNE-ISO Guía 73:2010] NOTA 1 – En la terminología de la gestión del riesgo, la palabra “probabilidad” se utiliza para indicar la posibilidad de que algún hecho se produzca, que esta posibilidad está definida, medida o determinada objetiva o subjetivamente, cualitativa o cuantitativamente, y descrita utilizando términos generales o de forma matemática [tales como una probabilidad o una frecuencia sobre un periodo de tiempo dado].

Proyecto de seguridad

Agrupación de tareas orientadas a tratar el riesgo del sistema. La agrupación se realiza por conveniencia, bien porque se trata de tareas que en singular carecerían de eficacia, bien porque se trata de tareas con un objetivo común, bien porque se trata de tareas que competen a una única unidad de acción.

Riesgo

Estimación del grado de exposición a que una amenaza se materialice sobre uno o más activos causando daños o perjuicios a la Organización. Efecto de la incertidumbre sobre la consecución de los objetivos. [UNEISO Guía 73:2010] Posibilidad de que se produzca un impacto determinado en un activo, en un dominio o en toda la Organización. [Magerit:1997]

© Ministerio de Hacienda y Administraciones Públicas

página 102 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Probabilidad de que una vulnerabilidad propia de un sistema de información sea explotada por las amenazas a dicho sistema, con el objetivo de penetrarlo. [CESID:1997] Risk: A measure of the potential degree to which protected information is subject to loss through adversary exploitation. [OPSEC] Risk: Possibility that a particular threat will adversely impact an information system by exploiting a particular vulnerability. [CNSS:2003] Risk: A combination of the likelihood that a threat will occur, the likelihood that a threat occurrence will result in an adverse impact, and the severity of the resulting adverse impact. Reducing either the threat or the vulnerability reduces the risk. [TDIR:2003] Total risk: The potential for the occurrence of an adverse event if no mitigating action is taken (i.e., the potential for any applicable threat to exploit a system vulnerability). [TDIR:2003] Risk: A measure of the exposure to which a system or potential system may be subjected. [CRAMM:2003]

Riesgo acumulado

Dícese del calculado tomando en consideración el valor propio de un activo y el valor de los activos que depende de él. Este valor se combina con la degradación causada por una amenaza y la frecuencia estimada de la misma.

Riesgo potencial

Riesgos potenciales. Los riesgos del sistema de información en la hipótesis de que no hubieran salvaguardas presentes. [UNE 71504:2008] Inherent risk – The risk level or exposure without taking into account the actions that management has taken or might take (e.g. implementing controls) [RiskIT-PG:2009]

Riesgo repercutido Dícese del calculado tomando en consideración únicamente el valor propio de un activo. Este valor se combina con la degradación causada por una amenaza y la frecuencia estimada de la misma, medidas ambas sobre activos de los que depende. Riesgo residual

Riesgo remanente en el sistema después del tratamiento del riesgo. [UNEISO Guía 73:2010] Riesgo remanente en el sistema tras la implantación de las salvaguardas determinadas en el plan de seguridad de la información. [Magerit:2006] Riesgo que se da tras la aplicación de salvaguardas dispuestas en un escenario de simulación o en el mundo real. [Magerit:1997] Residual risk: Portion of risk remaining after security measures have been applied. [CNSS:2003] [CRAMM:2003] Residual Risk: The potential for the occurrence of an adverse event after adjusting for the impact of all in-place safeguards. [TDIR:2003]

Salvaguarda

Procedimiento o mecanismo tecnológico que reduce el riesgo. Control: Medida que modifica un riesgo. [UNE-ISO Guía 73:2010] Control: Means of managing risks, including policies, procedures, guidelines, practices or organizational structures, which can be of administrative, technical, management or legal nature. [ISO/IEC 27000:2009] Countermeasure: Anything which effectively negates or mitigates an adversary's ability to exploit vulnerabilities. [OPSEC]

© Ministerio de Hacienda y Administraciones Públicas

página 103 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Safeguard: Protective measures prescribed to meet the security requirements (i.e., confidentiality, integrity, and availability) specified for an information system. Safeguards may include security features, management constraints, personnel security, and security of physical structures, areas, and devices. [800-53:2009] Countermeasure: Action, device, procedure, technique, or other measure that reduces the vulnerability of an information system. [CNSS:2003] Security safeguard: Protective measures and controls prescribed to meet the security requirements specified for an information system. Safeguards may include security features, management constraints, personnel security, and security of physical structures, areas, and devices. [CNSS:2003] Countermeasure: Any action, device, procedure, technique, or other measure that mitigates risk by reducing the vulnerability of, threat to, or impact on a system. [TDIR:2003]

Seguridad

La capacidad de las redes o de los sistemas de información de resistir, con un determinado nivel de confianza, los accidentes o acciones ilícitas o malintencionadas que comprometan la disponibilidad, autenticidad, integridad y confidencialidad de los datos almacenados o transmitidos y de los servicios que dichas redes y sistemas ofrecen o hacen accesibles. [Reglamento (CE) n 460/2004 del Parlamento Europeo y del Consejo, de 10 de marzo de 2004, por el que se crea la Agencia Europea de Seguridad de las Redes y de la Información]. Information System Security: Protection of information systems against unauthorized access to or modification of information, whether in storage, processing or transit, and against the denial of service to authorized users, including those measures necessary to detect, document, and counter such threats. [CNSS:2003]

Seguridad de la información

Confianza en que los sistemas de información están libres y exentos de todo peligro o daño inaceptables. [UNE 71504:2008]

Sistema de información

Los ordenadores y redes de comunicaciones electrónicas, así como los datos electrónicos almacenados, procesados, recuperados o transmitidos por los mismos para su operación, uso, protección y mantenimiento. Conjunto organizado de recursos para que la información se pueda recoger, almacenar, procesar (tratar), mantener, usar, compartir, distribuir, poner a disposición, presentar o transmitir. [UNE 71504:2008] Conjunto de elementos físicos, lógicos, elementos de comunicación, datos y personal que permiten el almacenamiento, transmisión y proceso de la información. [Magerit:1997] Cualquier sistema o producto destinado a almacenar, procesar o transmitir información. [CESID:1997] Information System: Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information. [CNSS:2003] Information System: Any procedure or process, with or without IT support, that provides a way of acquiring, storing, processing or disseminating information. Information systems include applications and their supporting infrastructure. [CRAMM:2003]

Tratamiento de riesgos

Proceso destinado a modificar el riesgo. [UNE-ISO Guía 73:2010] El proceso de selección e implantación de las medidas o salvaguardas pa-

© Ministerio de Hacienda y Administraciones Públicas

página 104 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] ra prevenir, impedir, reducir o controlar los riesgos identificados. [UNE 71504:2008]

Trazabilidad

Aseguramiento de que en todo momento se podrá determinar quién hizo qué y en qué momento. [UNE 71504:2008] Propiedad o característica consistente en que las actuaciones de una entidad pueden ser imputadas exclusivamente a dicha entidad. [ISO/IEC 7498-2:1989] Responsabilidad: Cualidad que permite que todas las acciones realizadas sobre un sistema de tecnología de la información sean asociadas de modo inequívoco a un individuo o entidad. [CESID:1997] Accountability: Process of tracing information system activities to a responsible source. [CNSS:2003]

Valor

De un activo. Es una estimación del coste inducido por la materialización de una amenaza. Cualidad que poseen algunas realidades, consideradas bienes, por lo cual son estimables. [DRAE]

Valor acumulado

Considera tanto el valor propio de un activo como el valor de los activos que dependen de él. Bienes de abolengo: Los heredados de los abuelos. [DRAE]

Vulnerabilidad

Defecto o debilidad en el diseño, implementación u operación de un sistema que habilita o facilita la materialización de una amenaza. Propiedades intrínsecas de que algo se produzca como resultado de una sensibilidad a una fuente de riesgo que puede conducir a un suceso con una consecuencia. [UNE-ISO Guía 73:2010] A weakness in design, implementation, operation or internal control. [RiskIT-PG:2009] A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. [RFC4949:2007] Estimación de la exposición efectiva de un activo a una amenaza. Se determina por dos medidas: frecuencia de ocurrencia y degradación causada. [Magerit:2006] Vulnerabilidad de un activo es la potencialidad o posibilidad de ocurrencia de la materialización de una amenaza sobre dicho activo. [Magerit:1997] Debilidad en la seguridad de un sistema de información. [CESID:1997] Vulnerability: The susceptibility of information to exploitation by an adversary. [OPSEC] Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited. [CNSS:2003] Vulnerability: A weakness or lack of controls that would allow or facilitate a threat actuation against a specific asset or target. [CRAMM:2003]

© Ministerio de Hacienda y Administraciones Públicas

página 105 (de 127)

Magerit 3.0

Glosario

A1.2. Términos anglosajones Breve diccionario inglés-español de términos habituales en análisis y gestión de riesgos: Acrónimos ALE

Annual Loss Expectancy

ARO Annual Rate of Occurrence BIA

Business Impact Analysis

GRC Governance, Risk Management, and Compliance Accountability Authenticity Availability Asset Business Impact Analysis Compliance Confidentiality Countermeasure Frequency Impact Information security Information security incident Information system Integrity Residual risk Risk Risk acceptance Risk analysis Risk assessment Risk management Risk map Risk treatment Safeguard Security Statement of applicability Traceability Threat Value Vulnerability

Trazabilidad Autenticidad Disponibilidad Activo Análisis de impacto Cumplimiento Confidencialidad Contra medida Frecuencia Impacto Seguridad de la información Incidente de seguridad Sistema de información Integridad Riesgo residual Riesgo Aceptación de riesgos Análisis de riesgos Análisis de riesgos Gestión de riesgos Mapa de riesgo Tratamiento del riesgo Salvaguarda Seguridad Documento de selección de controles Trazabilidad Amenaza Valor Vulnerabilidad

© Ministerio de Hacienda y Administraciones Públicas

página 106 (de 127)

Magerit 3.0

Glosario

A1.3. ISO – Gestión del riesgo La definiciones de ISO en lo que respecta a riesgos se recogen en la guía [ISO 73]

Definiciones Riesgo Efecto de la incertidumbre sobre la consecución de los objetivos. NOTA 1 – Un efecto es una desviación, positiva y/o negativa, respecto a lo previsto. NOTA 2 – Los objetivos pueden tener diferentes aspectos (tales como financieros, de salud y seguridad, o ambientales) y se pueden aplicar a diferentes niveles (tales como nivel estratégico, nivel de un proyecto, de un producto, de un proceso o de una organización completa). NOTA 3 – Con frecuencia, el riesgo se caracteriza por referencia a sucesos potenciales y a sus consecuencias, o a una combinación de ambos. NOTA 4 – Con frecuencia, el riesgo se expresa en términos de combinación de las consecuencias de un suceso (incluyendo los cambios en las circunstancias) y de su probabilidad. NOTA 5 – La incertidumbre es el estado, incluso parcial, de deficiencia en la información relativa a la comprensión o al conocimiento de un suceso, de sus consecuencias o de su probabilidad. Proceso de gestión del riesgo Aplicación sistemática de políticas, procedimientos y prácticas de gestión a las actividades de comunicación, consulta, establecimiento del contexto, e identificación, análisis, evaluación, tratamiento, seguimiento y revisión del riesgo. Dueño del riesgo Persona o entidad que tiene la responsabilidad y autoridad para gestionar un riesgo. Tratamiento del riesgo Proceso destinado a modificar el riesgo. NOTA 1 – El tratamiento del riesgo puede implicar: — evitar el riesgo, decidiendo no iniciar o continuar con la actividad que motiva el riesgo; — aceptar o aumentar el riesgo con objeto de buscar una oportunidad; — eliminar la fuente de riesgo; — cambiar la probabilidad; — cambiar las consecuencias; — compartir el riesgo con otra u otras partes [incluyendo los contratos y la financiación del riesgo]; y — mantener el riesgo en base a una decisión informada. NOTA 2 – Los tratamientos del riesgo que conducen a consecuencias negativas, en ocasiones se citan como “mitigación del riesgo”, “eliminación del riesgo”, “prevención del riesgo” y “reducción del riesgo”. NOTA 3 – El tratamiento del riesgo puede originar nuevos riesgos o modificar los riesgos existentes.

© Ministerio de Hacienda y Administraciones Públicas

página 107 (de 127)

Magerit 3.0

Glosario

Apéndice 2. Referencias Arreglo 2000 “Arreglo sobre el Reconocimiento de los Certificados de Criterios Comunes en el campo de la Seguridad de las Tecnologías de la Información”, Mayo, 2000. BSI Federal Office for Information Security (BSI). “IT Baseline Protection Manual”, October 2003. Germany. http://www.bsi.de/gshb/english/etc/index.htm CC Comon Criteria. Ver [ISO 15408]. CEM Common Evaluation Methodology. Ver [ISO 18045]. CESID Centro Superior de Información de la Defensa, “Glosario de Términos de Criptología”, Ministerio de Defensa, 3ª edición, 1997. CIAO Critical Infrastructure Assurance Office, “Practices for Securing Critical Information Assets”, January 2000. CNSS Committee on National Security Systems, Instruction No. 4009, “National Information Assurance (IA) Glossary“, May 2003. CRAMM “CCTA Risk Analysis and Management Method (CRAMM)”, Version 5.0, 2003. DARPA 1601 “The Vulnerability Assessment and Mitigation Methodology”, P.S. Antón et al., RAND National Defense Research Institute, MR-1601-DARPA, 2003. DRAE Real Academia Española. Diccionario de la Lengua Española. 22.ª edición, 2001. http://buscon.rae.es/diccionario/drae.htm EA-7 European Co-Operation for Accreditation, “Guidelines for the Accreditation of Bodies Operating Certification / Registration of Information Security Management Systems”, EA-7/03, February 2000. EBIOS “Méthode pour l’Expression des Besoins et l’Identification des Objectifs de Sécurité”. Service Central de la Sécurité des Systèmes d'Information. France. GAO United States General Accounting Office, Accounting and Information Management Division, “Information Security Risk Assessment — GAO Practices of Leading Organizations. ISO 73 ISO Guide 73:2009, “Risk management — Vocabulary”. UNE-ISO Guía 73:2010, “Gestión del riesgo. Vocabulario”. ISO 7498-2 ISO 7498-2:1989, “Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture”.

© Ministerio de Hacienda y Administraciones Públicas

página 108 (de 127)

Magerit 3.0

Glosario

ISO 15408 ISO/IEC 15408:2009, “Information technology — Security techniques — Evaluation criteria for IT security”. ISO 15443-1 ISO/IEC TR 15443-1:2005, “Information technology — Security techniques — A framework for IT security assurance -- Part 1: Overview and framework”. ISO 18043 ISO/IEC 18043:2006, “Information technology — Security techniques — Selection, deployment and operations of intrusion detection systems”. ISO 18045 ISO/IEC 18045:2008, “Information technology — Security techniques — Methodology for IT security evaluation”. ISO 27000 ISO/IEC 27000:2009, “Information technology — Security techniques — Information security management systems — Overview and vocabulary”. ISO 27001 ISO/IEC 27001:2005, “Information technology — Security techniques — Information security management systems — Requirements” UNE-ISO/IEC 27001:2007, “Tecnología de la información. Técnicas de seguridad. Sistemas de Gestión de la Seguridad de la Información (SGSI). Requisitos” ISO 27002 ISO/IEC 27002:2005, “Information technology — Security techniques — Code of practice for information security management”. UNE-ISO/IEC 27002:2009, “Tecnología de la Información. Código de Buenas Prácticas de la Gestión de la Seguridad de la Información”. ISO 27005 ISO/IEC 27005:2011, “Information technology — Security techniques — Information security risk management”. ISO 31000 ISO 31000:2009, “Risk management — Principles and guidelines”. UNE-ISO 31000:2010, “Gestión del riesgo. Principios y directrices”. ISO 31010 ISO/IEC 31010:2009, “Risk management — Risk assessment techniques”. UNE-ISO/IEC 31010:2010, “Gestión del riesgo. Técnicas de apreciación del riesgo”. ISO 38500 ISO/IEC 38500:2008. “Corporate governance of information technology”. ITSEC European Commission, “Information Technology Security Evaluation Criteria”, version 1.2, 1991. Magerit:1997 Ministerio de Hacienda y Administraciones Públicas, “Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información - Versión 1”, 1997. Magerit:2006 Ministerio de Hacienda y Administraciones Públicas, “Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información – Versión 2”, 2006. NIST 800-27 NIST, “Engineering Principles for Information Technology Security (A Baseline for Achieving Security)”, SP 800-27 Rev. A, June 2004.

© Ministerio de Hacienda y Administraciones Públicas

página 109 (de 127)

Magerit 3.0

Glosario

NIST 800-30 NIST, “Risk Management Guide for Information Technology Systems”, SP 800-30, 2Jul. 002. NISR, “DRAFT Guide for Conducting Risk Assessments”, SP 800-30 Rev.1, Sept. 2011. NIST 800-37 NIST, “Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach”, SP 800-37 Rev.1, Feb. 2010 NIST 800-39 NIST, “Managing Information Security Risk: Organization, Mission, and Information System View”, SP 800-39, Mar. 2011 NIST 800-53 NIST, “Recommended Security Controls for Federal Information Systems”, National Institute of Standards and Technology, special publication SP 800-53 Rev.3, Aug. 2009. NIST 800-64 NIST, “Security Considerations in the Information System Development Life Cycle”, SP 800-64 Rev.2, Oct. 2008. NSTISS National Security Telecommunications and Information Systems Security Committee, “Index of National Security Telecommunications Information Systems Security Issuances”, NSTISSI no. 4014, NSTISSC Secretariat, 1998. OCDE Directrices de la ocde para la seguridad de sistemas y redes de información : hacia una cultura de seguridad. 2004 Octave C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”, Addison Wesley, 2003. OPSEC OPSEC Glossary of Terms, http://www.ioss.gov/docs/definitions.html Peltier 2001 T.R. Peltier, “Information Security Risk Analysis”, Auerbach Pub; 1st edition (January 23, 2001) PILAR “Procedimiento Informático-Lógico para el Análisis de Riesgos”. Centro Criptológico Nacional. Centro Nacional de Inteligencia. Ministerio de Presidencia. España. RD 3/2010 Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. RD 1720/2007 Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal. Ribagorda A. Ribagorda, “Glosario de Términos de Seguridad de las T.I.”, Ediciones CODA, 1997. RIS2K Soporte de Magerit v1.0. Ministerio de Hacienda y Administraciones Públicas. España. RiskIt-F ISACA, “The Risk IT Framework”, 2009. RiskIt-PG ISACA, “The Risk IT Practitioner Guide”. 2009.

© Ministerio de Hacienda y Administraciones Públicas

página 110 (de 127)

Magerit 3.0

Glosario

TCSEC Department of Defense, “Trusted Computer System Evaluation Criteria”, DOD 5200.28-STD, Dec. 1985. TDIR:2003 Texas Department of Information Resources, “Practices for Protecting Information Resources Assets“, Revised September 2003. UNE 71504 UNE 71504:2008, “Metodología de análisis y gestión de riesgos para los sistemas de información”.

© Ministerio de Hacienda y Administraciones Públicas

página 111 (de 127)

Magerit 3.0

Marco legal

Apéndice 3. Marco legal En este apéndice se apunta cierta normativa legal, nacional e internacional, relevante al caso del análisis y gestión de riesgos, bien por exigirlo, bien por sustentarlo, bien por ser de utilidad en el Proceso de Gestión de Riesgos. La relación no pretende ser exhaustiva, amén de estar sujeta a un proceso legislativo activo, por lo que es obligación del responsable prestar atención a las novedades que vayan apareciendo.. Se han incluido algunas referencias a acuerdos de carácter político o de otra naturaleza a los cuales conviene también prestar atención. Por ejemplo, las Guías de la OCDE.

A3.1. Seguridad en el ámbito de la Administración electrónica •

Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común, LRJ-PAC.

•

Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.

•

Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. BOE de 29 de enero de 2010.

•

Corrección de errores del Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. BOE de 11 de marzo de 2010.

•

Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica. BOE de 29 de enero 2010.

A3.2. Protección de datos de carácter personal •

LOPD, Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

•

Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.

A3.3. Firma electrónica •

Ley 59/2003, de 19 de diciembre, de firma electrónica.

•

Ley 66/1997, de 30 de diciembre, de Medidas Fiscales, Administrativas y del Orden Social; art. 81.

•

Real Decreto 1317/2001, de 30 de noviembre, por el que se desarrolla el artículo 81 de la Ley 66/1997, de 30 de diciembre, de Medidas Fiscales, Administrativas y del Orden Social, en materia de prestación de servicios de seguridad por la Fábrica Nacional de Moneda y Timbre-Real Casa de la Moneda, en las comunicaciones a través de técnicas y medios electrónicos, informáticos y telemáticos, con las Administraciones Públicas.

A3.4. Información clasificada •

Ley 9/1968, de 5 de abril, sobre Secretos Oficiales.

•

Decreto 242/1969, de 20 de Febrero. por el que se desarrollan las disposiciones de la Ley 9/1968. de 5 de abril sobre Secretos Oficiales.

•

Ley 48/1978, de 7 de octubre, que modifica la Ley 9/1968, de 5 de abril, sobre secretos oficiales.

© Ministerio de Hacienda y Administraciones Públicas

página 112 (de 127)

Magerit 3.0

Marco legal

•

Orden Ministerial número 76/2002, de 18 de abril, por la que se establece la política de seguridad para la protección de la información del Ministerio de Defensa almacenada, procesada o transmitida por sistemas de información y telecomunicaciones.

•

LEY 11/2002, de 6 de mayo, reguladora del Centro Nacional de Inteligencia.

•

Real Decreto 421/2004, de 12 de marzo, por el que se regula el Centro Criptológico Nacional.

•

Decisión del Consejo de 19 de marzo de 2001, por la que se adoptan las normas de seguridad del Consejo (2001/264/EC)

•

Decisión de la Comisión de 29 de noviembre de 2001, por la que se modifica su Reglamento interno (2001/844/CE, CECA, Euratom)

A3.5. Seguridad de las redes y de la información •

COM(2001)298 final -- Seguridad de las redes y de la información: Propuesta para un enfoque político europeo

•

OCDE: Directrices para la seguridad de los sistemas y redes de información - Hacia una cultura de seguridad

© Ministerio de Hacienda y Administraciones Públicas

página 113 (de 127)

Magerit 3.0

Evaluación y certificación

Apéndice 4. Marco de evaluación y certificación La complejidad de los sistemas de información conlleva un gran esfuerzo para determinar la calidad de las medidas de seguridad de que se ha dotado y la confianza que merecen. Es frecuente la aparición de terceras partes que de forma independiente emiten juicios sobre dichos aspectos, juicios que se emiten tras una evaluación rigurosa y que se plasman en un documento reconocido. En este capítulo se repasan someramente dos marcos en los que se ha formalizado el proceso de evaluación y certificación (o registro): •

en los sistemas de gestión de la seguridad de la información

•

en los productos de seguridad

Para cada uno de estos marcos se indica su oportunidad, la forma de organizarse para alcanzar la certificación y el marco administrativo y normativo en el que se desarrolla la actividad.

A4.1. Sistemas de gestión de la seguridad de la información (SGSI) Se define “sistema de gestión” como lo que la Organización hace para gestionar sus procesos o actividades, de forma que los productos que fabrica o los servicios que presta satisfagan los objetivos que la propia organización de ha marcado, típicamente •

satisfacer la calidad demandada por los clientes

•

cumplir con las obligaciones legales, regulatorias y contractuales

Dentro del sistema de gestión de una Organización, se entiende por “sistema de gestión de la seguridad de la información” (SGSI) la parte relacionada con la seguridad de la información. Es habitual entender que los sistemas de gestión deben ajustarse al llamado ciclo de Denning (PDCA), habitual en sistemas de gestión de la calidad: P – Plan – Se establecen objetivos y se preparan planes para alcanzarlos. Esto incluye analizar la situación de la Organización: dónde estamos y dónde queremos estar. D – Do – Se ejecutan los planes. C – Check – Se evalúan los resultados obtenidos para determinar en qué medida se han alcanzado los objetivos propuestos. A – Act – A fin de estar cada día mejor (mejora continua), se actualizan los planes y su implantación. Plan planificación planificación Act

Do

mantenimiento mantenimiento yymejora mejora

implementación implementación yyoperación operación Check monitorización monitorización yyevaluación evaluación

Ilustración 22. Ciclo PDCA

La planificación (P de Plan) debe incluir una política de seguridad que marque objetivos y un análisis de riesgos que modele el valor del sistema, su exposición a amenazas, y lo que se tiene (o se necesita) para mantener el riesgo bajo control. Es natural que con estas bases se genere un plan de seguridad razonado para la gestión de riesgos. La acción (D de Do) es la ejecución del plan, en sus aspectos técnicos y de organización, involucrando a las personas que se hacen cargo del sistema o están relacionadas con éste. Un plan tiene éxito cuando lleva a una operación diaria sin sorpresas. © Ministerio de Hacienda y Administraciones Públicas

página 114 (de 127)

Magerit 3.0

Evaluación y certificación

La monitorización (C de Check) de la operación del sistema parte del hecho de que no se puede confiar ciegamente en la eficacia de las medidas, sino que continuamente hay que evaluar si responden a lo esperado con la eficacia deseada. Hay que medir tanto lo que ocurre como lo que ocurriría si no se hubieran tomado medidas. A veces se habla del “coste de la inseguridad” como justificación de que el gasto de dinero y esfuerzo tiene fundamento. Y hay que atender a las novedades que se produzcan, tanto en cuanto a modificaciones del propio sistema de información, como a nuevas amenazas. La reacción (A de Act) es saber derivar consecuencias de la experiencia, propia y de sistemas similares, repitiendo el ciclo PDCA. La evaluación de un sistema de gestión de la seguridad parte del supuesto de que el esquema anterior vertebra las actuaciones de la Organización en materia de seguridad, y juzga la eficacia de los controles implantados para alcanzar asegurarnos de que se alcanzan los objetivos propuestos. Nótese que un sistema de gestión maduro debe estar documentado en todos sus aspectos. Es típico de organizaciones inmaduras que las actividades se realizan siguiendo normas y procedimientos que se sobreentienden o están en la cabeza de las personas. Sólo cuando todo figura por escrito podemos hablar de un sistema de gestión que puede ser objeto de una certificación.

A4.1.1. La certificación Certificar un sistema de gestión de la seguridad consiste en que alguien, externo a la Organización y acreditado para la tarea, afirma que ha auditado el sistema y lo considera ajustado a la norma correspondiente. En el caso que nos ocupa, la norma es la UNE-ISO/IEC 27001:2007. El que certifica compromete en ello su palabra (por escrito). Con todas las cautelas de alcance y tiempo que se consideren oportunas (y se recojan explícitamente). Y sabiendo que lo que se asegura hoy, hay que revisarlo a medio plazo pues todo evoluciona. Para obtener un certificado hay que seguir una serie de formalismos. Sin entrar en excesivo detalle nos centraremos en qué evalúa el equipo que envía el organismo de certificación a juzgar a la Organización. Lo primero que hay que hacer es delimitar el alcance de lo que se va a evaluar como “Sistema de Gestión de la Seguridad de la Información”. Esta es una delimitación propia de cada Organización, que refleja su misión y su organización interna. Es importante delimitar con claridad. Si el perímetro es difuso no quedará claro qué hay que hacer en los pasos siguientes; en particular, no se sabrá muy bien a qué personas y departamentos hay que dirigirse para reclamar la información pertinente. Nótese que esto puede no ser evidente. Actualmente es raro encontrar una organización cerrada desde el punto de vista de sus sistemas de información: la externalización de servicios, la administración electrónica y el comercio electrónico han diluido las fronteras. Por otra parte, el organigrama interno rara vez responde a las responsabilidades en seguridad. Lo siguiente que hay que tener claro, escrito y mantenido es la política de seguridad corporativa. A menudo la política de seguridad incluye la relación de la legislación que afecta. Es absolutamente necesario delimitar el marco legislativo y regulatorio al que hay que atenerse. Todo debe estar escrito. Y bien escrito: se entiende, es coherente, se divulga, es conocido por los involucrados y se mantiene al día. Un proceso de certificación siempre tiene un fuerte componente de revisión de documentación. Antes de que venga el equipo evaluador, hay que tener una foto del estado de riesgo de la Organización. Es decir, que hay que hacer un análisis de riesgos identificando activos, valorándolos, identificando y valorando las amenazas significativas. En este proceso se determina qué salvaguardas requiere el sistema y con qué calidad. Cada caso es un mundo aparte: ni todo el mundo tiene los mismos activos, ni valen lo mismo, ni están igualmente interconectados, ni todo el mundo está sujeto a las mismas amenazas, ni todo el mundo adopta la misma estrategia para protegerse. El análisis de riesgos es una herramienta (imprescindible) de gestión. Por hacer o dejar de hacer un análisis de riesgos no se está ni más ni menos seguro: simplemente, se sabe dónde se está. A partir de este conocimiento podemos tomar decisiones de tratamiento y ejecutarlas. © Ministerio de Hacienda y Administraciones Públicas

página 115 (de 127)

Magerit 3.0

Evaluación y certificación

Los resultados del análisis de riesgos permiten justificar las decisiones de tratamiento del riesgo. Todo esto deberá ser verificado por el equipo evaluador que, de quedar satisfecho, avalará la concesión del certificado. El equipo evaluador inspecciona el sistema de información que se desea certificar contrastándolo con una referencia reconocida que permita objetivar la evaluación a fin de evitar cualquier tipo de arbitrariedad o subjetividad y permitir la utilización universal de las certificaciones emitidas. Se utiliza un “esquema de certificación” (en el caso que nos ocupa, la norma UNE-ISO/IEC 27001:2007). La norma 27001 tiene por objeto la especificación de “los requisitos para establecer, implantar, documentar y evaluar un Sistema de Gestión de la Seguridad de la Información con independencia de su tipo, tamaño o área de actividad.”

A4.1.2. La acreditación de la entidad certificadora La credibilidad del certificado es la confianza que merezca el certificador. ¿Cómo se construye esta confianza? Un componente esencial es la credibilidad del esquema de certificación. Un segundo componente es la credibilidad de la organización que emite los certificados. Esta organización es responsable de la competencia del equipo evaluador y de la ejecución del proceso de evaluación. Para certificar que estas responsabilidades se cumplen se procede al llamado “proceso de acreditación” donde una nueva organización evalúa al evaluador. En España, la organización encargada de acreditar organismos certificadores es ENAC, que se acoge a la normativa internacional de reconocimiento mutuo de certificados emitidos por diferentes certificadores en diferentes países.

A4.1.3. Terminología Se recogen a continuación los términos usados en las actividades de certificación de sistemas de información, tal y como se entienden en este contexto. Acreditación Procedimiento mediante el cual un Organismo autorizado reconoce formalmente que una organización es competente para la realización de una determinada actividad de evaluación de la conformidad. Auditoría Ver “evaluación”. Certificación El objetivo de la certificación es “declarar públicamente que un producto, proceso o servicio es conforme con requisitos establecidos” . Certification: A comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. [NIST 800-37] Documento de certificación (o registro) Documento que afirma que el sistema de gestión de la seguridad de la información (SGSI) de una organización es conforme a la normativa de referencia adaptada a la singularidad de la organización certificada. Documento de selección de controles Documento que describe los objetivos de control y los controles relevantes y aplicables al Sistema de Gestión de la Seguridad de la Información de la organización. Éste documento debe estar basado en los resultados y conclusiones del proceso de análisis y gestión de riesgos.

© Ministerio de Hacienda y Administraciones Públicas

página 116 (de 127)

Magerit 3.0

Evaluación y certificación

Esquema de certificación Marco técnico y administrativo que establece la referencia de trabajo frente a la que se contrasta el cumplimiento de la organización sometida a evaluación, se emite el certificado o registro y se mantiene actualizado y válido. Evaluación Conjunto de actividades que permiten determinar si la organización satisface los criterios aplicables dentro del esquema de certificación. Incluye actividades preparatorias, revisión de la documentación, inspección del sistema de información y la preparación de la documentación pertinente para la emisión del certificado de conformidad, si procede. Organismo de certificación (o registro) Entidad que, a la vista del informe de evaluación, certifica (o registra) la satisfacción por la organización de los requisitos establecidos en el esquema de certificación. Organismos de evaluación de la conformidad Son los encargados de evaluar y realizar una declaración objetiva de que los servicios y productos cumplen unos requisitos específicos, ya sean del sector reglamentario o del voluntario. Sistema de gestión Conjunto de recursos que utiliza una organización para alcanzar sus. El sistema de gestión incluye aspectos tan diversos como

— la estructura organizativa, — la definición y asignación de responsabilidades, — la documentación: política(s), normativa, procedimientos, guías, instrucciones, etc. — la planificación de actividades. Sistema de gestión de la seguridad de la información Parte del sistema de gestión que, basado en los riesgos para el negocio, establece, implementa, opera, monitoriza, revisa, mantiene y mejora la seguridad de la información. Política de seguridad Conjunto de normas reguladoras, reglas y prácticas que determinan el modo en que los activos, incluyendo la información considerada como sensible, son gestionados, protegidos y distribuidos dentro de una organización.

A4.2. Criterios comunes de evaluación (CC) La necesidad de evaluar la seguridad de un sistema de información aparece muy temprano de la mano de los procesos de adquisición de equipos del Departamento de Defensa de los EEUU que, en 1983, publica el llamado “Libro Naranja” (TCSEC – Trusted Computer System Evaluation Criteria). El objetivo es especificar sin ambigüedad qué se necesita por parte del comprador y qué se ofrece por parte del vendedor, de forma que no haya malentendidos sino un esquema transparente de evaluación, garantizando la objetividad de las adquisiciones. La misma necesidad lleva a la aparición de iniciativas europeas como ITSEC (Information Technology Security Evaluation Criteria). A mediados de los años 90, existe en el mundo una proliferación de criterios de evaluación que dificulta enormemente el comercio internacional, llegándose a un acuerdo de convergencia que recibe el nombre de “Common Criteria for Information Technology Security Evaluation”, normalmente conocidos como “Criterios Comunes” o por sus siglas, CC. Los CC, además de la necesidad de un entendimiento universal, capturan la naturaleza cambiante de las tecnologías de la información que, en el periodo desde 1980, han pasado de estar centradas en los equipos de computación, a englobar sistemas de información mucho más complejos. Los CC permiten

© Ministerio de Hacienda y Administraciones Públicas

página 117 (de 127)

Magerit 3.0

Evaluación y certificación

1. definir las funciones de seguridad 35 de los productos y sistemas (en tecnologías de la información) y 2. determinar los criterios para evaluar [la calidad] de dichas funciones. Es esencial la posibilidad que los CC abren para que la evaluación sea objetiva y pueda realizarse por una tercera parte (ni por el proveedor, ni por el usuario) de forma que la elección de salvaguardas adecuadas se vea notablemente simplificada para las organizaciones que necesitan mitigar sus riesgos. La administración española, y otras muchas, reconocen las certificaciones de seguridad emitidas en otros países en base al “Arreglo sobre el Reconocimiento de los Certificados de Criterios Comunes en el Campo de la Tecnología de la Información” 36 . La evaluación de un sistema es la base para su certificación. Para certificar es necesario disponer de 1. unos criterios, que definen el significado de los elementos que se van a evaluar 2. una metodología, que marque cómo se lleva a cabo la evaluación 3. un esquema de certificación 37 que fije el marco administrativo y regulatorio bajo el que se realiza la certificación

Ilustración 23. Proceso de certificación

De esta forma se puede garantizar la objetividad del proceso; es decir, construir la confianza en que los resultados de un proceso de certificación son válidos universalmente, independientemente de dónde se realice la certificación. Dado que [la calidad de] la seguridad requerida de un sistema no es siempre la misma, sino que depende de para qué se quiera emplear, CC establece una escala de niveles de aseguramiento 38 : EAL0: sin garantías EAL1: probado funcionalmente 35 En CC se emplea una terminología propia, rigurosa pero no siempre intuitiva. Más adelante se recoge la definición precisa de cada término en el contexto de los CC. 36 El día 23 de mayo de 2000 tuvo lugar en Baltimore (Maryland, Estados Unidos) la ratificación de la adhesión de Alemania, Australia, Canadá, España, Estados Unidos, Finlandia, Francia, Grecia, Italia, Noruega, Nueva Zelanda, Países Bajos y Reino Unido, al Arreglo sobre el Reconocimiento de los Certificados de Criterios Comunes en el campo de la Seguridad de la Tecnología de la Información (en lo sucesivo Arreglo). Posteriormente, se han incorporado Israel, Suecia, Austria, Turquía, Hungría, Japón, República Checa, Corea, Singapur e India. Véase http://www.csi.map.es/csi/pg3433.htm. 37 El Real Decreto 421/2004 de 12 de marzo, regula las funciones del Centro Criptológico Nacional, entre cuyas funciones aparece la de “constituir el organismo de certificación del esquema nacional de evaluación y certificación de la seguridad de las tecnologías de información, de aplicación a productos y sistemas en su ámbito.” El esquema nacional puede encontrarse en http://www.oc.ccn.cni.es/ . 38 EAL: Evaluation Assurance Level

© Ministerio de Hacienda y Administraciones Públicas

página 118 (de 127)

Magerit 3.0

Evaluación y certificación

EAL2: probado estructuralmente EAL3: probado y chequeado metódicamente EAL4: diseñado, probado y revisado metódicamente EAL5: diseñado y probado semi-formalmente EAL6: diseñado, probado y verificado semi-formalmente EAL7: diseñado, probado y verificado formalmente Los niveles superiores requieren un mayor esfuerzo de desarrollo y de evaluación, ofreciendo a cambio unas grandes garantías a los usuarios. Por ejemplo, en el ámbito de la firma electrónica, los dispositivos seguros de firma suelen certificarse contra un perfil de nivel EAL4+ 39 .

A4.2.1. Beneficiarios Los CC se dirigen a una amplia audiencia de potenciales beneficiarios de la formalización de los conceptos y elementos de evaluación: los consumidores (usuarios de productos de seguridad), los desarrolladores y los evaluadores. Un lenguaje común entre todos ellos se traduce en ventajas apreciables: Para los consumidores • que pueden expresar sus necesidades, antes de adquirir los servicios o productos que las satisfagan; esta caracterización puede resultar útil tanto en adquisiciones individuales, como en la identificación de necesidades de grupos de usuarios •

que pueden analizar las características de los servicios o productos que ofrece el mercado

•

que pueden comparar diferentes ofertas

Para los desarrolladores • que saben qué se les va a exigir y cómo se van a evaluar sus desarrollos •

que saben, objetivamente, qué requieren los usuarios

•

que pueden expresar sin ambigüedad lo que hacen sus desarrollos

Para los evaluadores • que disponen de un marco formalizado para saber qué tienen que evaluar y cómo tienen que calificarlo Para todo el mundo • que dispone de unos criterios objetivos que permiten aceptar las certificaciones realizadas en cualquier parte Todos estos participantes convergen sobre un objeto a evaluar denominado TOE (Target Of Evaluation), que es el servicio o producto (de seguridad) cuyas características (de seguridad) se quieren evaluar. Cuando un análisis de riesgos expone la relación de salvaguardas adecuadas, estas pueden venir expresadas en terminología CC, lo que permite engarzar con las ventajas citadas, convirtiéndose en una especificación normalizada.

A4.2.2. Requisitos de seguridad Dado un sistema se pueden determinar, a través de un análisis de riesgos, qué salvaguardas se requieren y con qué calidad. Este análisis puede hacerse sobre un sistema genérico o sobre un sistema concreto. En CC, el conjunto de requisitos que se le exigen a un sistema genérico se de39 Cuando un producto está entre dos niveles, se indica su nivel inferior seguido de un signo “+” que se lee como “aumentado”. Así, un producto evaluado EAL4+ significa que cumple todos los niveles de calidad del nivel 4 y algunos de niveles superiores.

© Ministerio de Hacienda y Administraciones Públicas

página 119 (de 127)

Magerit 3.0

Evaluación y certificación

nomina perfil de protec ción (PP – Protection Profile). Si no se está hablando de un sistema genérico, sino de un sistema concreto, el conjunto de requisitos se conoce como declaración de seguridad (ST – Security Target). Los PP, dado su carácter genérico, cubren diferentes productos concretos. Suelen ser preparados por grupos de usuarios u organismos internacionales que quieren modelar el mercado 40 . Los ST, dado su carácter específico, cubren un producto concreto. Suelen ser preparados por los propios fabricantes que de esta manera formalizan su oferta 41 . CC determina los apartados en que debe estructurarse un PP o un ST. El índice de estos documentos es un buen indicador de su alcance: PP- perfil de protección Introduction — TOE description — Security environment • assumptions • threats • organizational security policies — Security objectives • for the TOE • for the environment — Security requirements • for the environment • TOE functional requirements • TOE assurance requirements — Application notes — Rationale —

ST – declaración de seguridad Introduction — TOE description — Security environment • assumptions • threats • organizational security policies — Security objectives • for the TOE • for the environment — Security requirements • for the environment • TOE functional requirements • TOE assurance requirements — TOE summary specification — PP claims • PP reference • PP tailoring • PP additions — Rationale —

Tabla 11. Perfiles de protección y Declaraciones de seguridad

Los PP y los ST pueden ser a su vez sometidos a una evaluación formal que verifique su completitud e integridad. Los PP así evaluados pueden pasar a registros públicos para ser compartidos por diferentes usuarios. En la elaboración de un ST se hace referencia a los PP a los que se acoge.

A4.2.3. Creación de perfiles de protección La generación de un PP o un ST es básicamente un proceso de análisis de riesgos donde el analista, habiendo determinado el dominio del análisis (el TOE en terminología de CC), identifica amenazas y determina, a través de los indicadores de impacto y riesgo, las salvaguardas que se requieren. En la terminología de CC, las salvaguardas requeridas se denominan requisitos d e seguridad y se subdividen en dos grandes grupos 40 Un ejemplo típico de PP podría ser aquel que fija las características de seguridad que se deben exigir a un cortafuegos. 41 Un ejemplo típico de ST podría ser aquel que fija las características de seguridad del modelo 3000 del fabricante XXL S.A., un modelo que permite cifrar las comunicaciones telefónicas.

© Ministerio de Hacienda y Administraciones Públicas

página 120 (de 127)

Magerit 3.0

Evaluación y certificación

requisitos funcionales de seguridad (functional requirements) •

¿qué hay que hacer?

•

definen el comportamiento funcional del TOE

requisitos de garantía de la funcionalidad de la seguridad (assurance requirements) •

¿está el TOE bien construido?

•

¿es eficaz? ¿satisface el objetivo para el que se requiere?

•

¿es eficiente? ¿alcanza sus objetivos con un consumo razonable de recursos?

Es importante destacar que CC establece un lenguaje común para expresar los objetivos funcionales y de aseguramiento. Es necesario pues que el análisis de riesgos utilice esta terminología en la selección de salvaguardas. La norma CC nos proporciona en su parte 2 el catálogo estandarizado de objetivos funcionales, mientras que en su parte 3 nos proporciona el catálogo estandarizado de objetivos de aseguramiento. Parte 2: Requisitos funcionales FAU: Security audit FCO: Communication FCS: Cryptographic support FDP: User data protection FIA: Identification and authentication FMT: Security management FPR: Privacy FPT: Protection of the TOE security functions FRU: Resource utilisation FTA: TOE access FTP: Trusted path / channels

Parte 3: Requisitos de garantía ACM: Configuration management ADO: Delivery and operation ADV: Development AGD: Guidance documents ALC: Life cycle support ATE: Tests AVA: Vulnerability assessment APE: PP evaluation ASE: ST evaluation

Tabla 12. Requisitos funcionales y de aseguramiento de la función

A4.2.4. Uso de productos certificados Cuando un TOE ha sido certificado de acuerdo a un PP o un ST, según convenga en cada caso, se puede tener la certeza de que dicho TOE satisface las necesidades y además las satisface con la calidad requerida (por ejemplo, EAL4). La certificación de un sistema o producto no es garantía ciega de idoneidad: es necesario cerciorarse de que el PP o ST respecto del que se han certificado satisface los requisitos de nuestro sistema. El análisis de riesgos nos ha permitido elaborar el PP o el ST o, en ocasiones, seleccionar un conjunto apropiado a nuestro mapa de riesgos. Pero lo esencial es que de análisis de riesgos se han obtenido unos requisitos de seguridad cuya satisfacción permitirá mantener impacto y riesgo residuales bajo control. En la medida en que un producto certificado se ajusta a un PP o ST que satisface nuestras necesidades, la gestión de riesgos se reduce a adquirir el producto, instalarlo y operarlo en las condiciones adecuadas. Es importante destacar que tanto los PP como los ST incluyen una sección denominada “hipótesis” (assumptions) en la que se establecen una serie de prerrequisitos que debe satisfacer el entorno operacional en el que se instala TOE. No se hace sino reconocer que el mejor producto, inadecuadamente instalado u operado, es incapaz de garantizar la satisfacción de los objetivos globales. Por ello, los productos certificados son componentes muy sólidos de un sistema; pero además hay que garantizar su entorno para asegurar el sistema completo. © Ministerio de Hacienda y Administraciones Públicas

página 121 (de 127)

Magerit 3.0

Evaluación y certificación

A4.2.5. Terminología Debido a que su objetivo es servir de referencia internacional y sustentar evaluaciones y certificaciones, los criterios comunes deben ser muy precisos en su terminología. En el texto previo se han venido introduciendo los términos según se necesitaban; estos términos se recogen formalmente a continuación: Assurance (garantía) Base de la confianza en que una entidad cumple sus objetivos de seguridad. Evaluation (evaluación) Valoración de un PP, ST o TOE frente a criterios definidos. Evaluation Assurance Level (EAL) (nivel de garantía de evaluación) Paquete que consiste en componentes de garantía de la Parte 3 y que representa un nivel en la escala de garantía predefinida de CC. Evaluation authority (autoridad de evaluación) Organismo que implementa los CC para una comunidad específica mediante un esquema de evaluación por el que se establecen las normas y se supervisa la calidad de las evaluaciones realizadas por organismos de dicha comunidad. Evaluation scheme (esquema de evaluación) Marco administrativo y regulador bajo el que una autoridad de evaluación aplica los CC en una comunidad específica. Formal Expresado en un lenguaje de sintaxis restringida con una semántica definida basada en conceptos matemáticos bien establecidos. Informal Expresado en lenguaje natural. Organisational security policies (Políticas de seguridad organizativas ) Una o más reglas de seguridad, procedimientos, prácticas o directrices impuestas por una organización sobre sus operaciones. Product (producto) Paquete de software, firmware y/o hardware de TI que proporciona una funcionalidad diseñado para su uso o su incorporación en una gran variedad de sistemas. Protection Profile (PP) (perfil de protección) Conjunto de requisitos de seguridad, independiente de la implementación, para una categoría de TOEs que satisfacen unas necesidades específicas del consumidor. Security objective (objetivo de seguridad) Declaración de la intención de contrarrestar las amenazas identificadas y/o de cumplir las políticas e hipótesis de seguridad identificadas de la organización. Security Target (ST) (declaración de seguridad) Conjunto de requisitos de seguridad y especificaciones utilizados como base de la evaluación de un TOE identificado. Semiformal Expresado en un lenguaje de sintaxis restringida con semántica definida. System (sistema) Instalación específica de TI, con un propósito y en un entorno particulares. Target of Evaluation (TOE) (objeto a evaluar) Producto o sistema de TI y sus manuales de administrador y de usuario asociados que se somete a evaluación. © Ministerio de Hacienda y Administraciones Públicas

página 122 (de 127)

Magerit 3.0

Evaluación y certificación

TOE Security Functions (TSF) (funciones de seguridad del TOE) Conjunto compuesto de todo el hardware, firmware y software del TOE con el que hay que contar para la correcta aplicación de la TSP. TOE Security Policy (TSP) (política de seguridad del TOE) Conjunto de reglas que regulan cómo se gestionan, protegen y distribuyen los activos en el TOE.

© Ministerio de Hacienda y Administraciones Públicas

página 123 (de 127)

Magerit versión 2

Herramientas

Apéndice 5. Herramientas La realización de un proyecto de análisis de riesgos supone trabajar con una cierta cantidad de activos que rara vez baja de las decenas y que habitualmente son algunos centenares. El número de amenazas típicamente está del orden de las decenas, mientras que el número de salvaguardas está en los millares. Todo ello nos indica que hay que manejar multitud de datos y combinaciones entre ellos, lo que lleva lógicamente a buscar apoyo de herramientas automáticas. Como requisitos generales, una herramienta de apoyo al análisis de riesgos debe: •

permitir trabajar con un conjunto amplio de activos, amenazas y salvaguardas;

•

permitir un tratamiento flexible del conjunto de activos para acomodar un modelo cercano a la realidad de la Organización;

•

ser utilizada a lo largo de los tres procesos que constituyen el proyecto, especialmente como soporte al proceso P2, Análisis de Riesgos y

•

no ocultar al analista el razonamiento que lleva a las conclusiones.

Las herramientas pueden hacer un tratamiento cualitativo o cuantitativo de la información. La opción entre uno y otro planteamiento ha sido motivo de largo debate. Los modelos cualitativos ofrecen resultados útiles antes que los modelos cuantitativos, simplemente porque la captura de datos cualitativa es más ágil que la cuantitativa 42 . Los modelos cualitativos son eficaces relativizando lo más importante de lo que no es tan importante; pero agrupan las conclusiones en grandes grupos. Los modelos cuantitativos, por el contrario, consiguen una ubicación precisa de cada aspecto. Impacto y riesgo residual pueden ser cualitativos hasta que aparecen grandes inversiones y hay que determinar su racionalidad económica: ¿qué es lo que interesa más? En este punto se necesitan números. Una opción mixta es útil: un modelo cualitativo para el sistema de información completo, con capacidad de entrar en un modelo cuantitativo para aquellos componentes cuya protección va a requerir fuertes desembolsos. También es cierto que el modelo de valor de una Organización debe emplearse durante largo tiempo, al menos durante los años que dure el plan de seguridad para analizar el efecto de la ejecución del plan de seguridad. Es notablemente más dificultoso generar un modelo de valor desde cero que ir adaptando un modelo existente a la evolución de los activos del sistema y a la evolución de los servicios que presta la Organización. En esta evolución continua puede afrontarse la progresiva migración de un modelo cualitativo inicial hacia un modelo cada vez más cuantitativo. Es de destacar que los datos de caracterización de las posibles amenazas son datos tentativos en los primeros modelos; pero la experiencia permite ir ajustando las valoraciones a la realidad. Sean herramientas cualitativas o cuantitativas, estas deben: •

Manejar un catálogo razonablemente completo de tipos de activos. En esta línea se orienta el capítulo 2 del "Catálogo de Elementos".

•

Manejar un catálogo razonablemente completo de dimensiones de valoración. En esta línea se orienta el capítulo 3 del "Catálogo de Elementos".

•

Ayudar a valorar los activos ofreciendo criterios de valoración. En esta línea se orienta el capítulo 4 del "Catálogo de Elementos".

•

Manejar un catálogo razonablemente completo de amenazas. En esta línea se encamina el capítulo 5 del "Catálogo de Elementos".

42 Hay que valorar activos y esta es una tarea de consenso. Tanto la valoración como la búsqueda del consenso son notablemente más rápidas si hay que determinar un orden de magnitud que si hay que determinar un número absoluto.

© Ministerio de Hacienda y Administraciones Públicas

página 124 (de 127)

Magerit versión 2

Herramientas

•

Manejar un catálogo razonablemente completo de salvaguardas. En esta línea se orienta el capítulo 6 del "Catálogo de Elementos".

•

Evaluar el impacto y el riesgo residuales.

Es interesante que las herramientas puedan importar y exportar los datos que manejan en formatos fácilmente procesables por otras herramientas, cabiendo citar •

XML – Extended Markup Language que es la opción tomada en esta guía, que establece formatos XML de intercambio

•

CSV – Comma Separated Values

A5.1. PILAR PILAR, acrónimo de “Procedimiento Informático-Lógico para el Análisis de Riesgos” es una herramienta desarrollada bajo especificación del Centro Nacional de Inteligencia para soportar el análisis de riesgos de sistemas de información siguiendo la metodología Magerit. La herramienta soporta todas las fases del método Magerit: •

Caracterización de los activos: identificación, clasificación, dependencias y valoración

•

Caracterización de las amenazas

•

Evaluación de las salvaguardas

La herramienta incorpora los catálogos del "Catálogo de Elementos" permitiendo una homogeneidad en los resultados del análisis: •

tipos de activos

•

dimensiones de valoración

•

criterios de valoración

•

catálogo de amenazas

Para incorporar este catálogo, PILAR diferencia entre el motor de cálculo de riesgos y la biblioteca de elementos, que puede ser reemplazada para seguir el paso de la evolución en el tiempo de los catálogos de elementos. La herramienta evalúa el impacto y el riesgo, acumulado y repercutido, potencial y residual, presentándolo de forma que permita el análisis de por qué se da cierto impacto o cierto riesgo. Las salvaguardas se califican por fases, permitiendo la incorporación a un mismo modelo de diferentes situaciones temporales. Típicamente se puede incorporar el resultado de los diferentes proyectos de seguridad a lo largo de la ejecución del plan de seguridad, monitorizando la mejora del sistema. Los resultados se presentan en varios formatos: informes RTF, gráficas y tablas para incorporar a hojas de cálculo. De esta forma es posible elaborar diferentes tipos de informes y presentaciones de los resultados. Por último, la herramienta calcula calificaciones de seguridad siguiendo los epígrafes de normas de iure o de facto de uso habitual. Caben citarse: •

UNE-ISO/IEC 27002:2009: sistemas de gestión de la seguridad

•

RD 1720/2007: datos de carácter personal

•

RD 3/2010: Esquema Nacional de Seguridad

Por último hay que destacar que PILAR incorpora tanto los modelos cualitativo como cuantitativo, pudiendo alternarse entre uno y otro para extraer el máximo beneficio de las posibilidades teóricas de cada uno de ellos.

© Ministerio de Hacienda y Administraciones Públicas

página 125 (de 127)

Magerit versión 2

Evolución de Magerit

Apéndice 6. Evolución de Magerit La primera de Magerit, publicada en 1997 ha resistido en su mayor parte el paso del tiempo, ratificándose en lo fundamental. No obstante, el tiempo pasado permite mejorar notablemente aquella primera versión. La segunda versión, publicada en 2005, se planteó como revisión constructiva, adaptándola al tiempo presente e incorporando la experiencia de estos años. Esta tercera versión busca una nueva adaptación, teniendo en cuenta no solo la experiencia práctica sino también la evolución de las normas internacionales de ISO que constituyen un referente obligado.

A6.1. Para los que han trabajado con Magerit v1 Si usted ha trabajado con Magerit v1.0, todos los conceptos le resultarán familiares, aunque hay cierta evolución. En particular reconocerá lo que se denominaba submodelo de elementos: activos, amenazas, vulnerabilidades, impactos, riesgos y salvaguardas. Esta parte conceptual ha sido refrendada por el paso del tiempo y sigue siendo el eje alrededor del cual se vertebran las fases fundamentales de análisis y gestión. Se ha corregido y ampliado lo que se denominaba “subestados de seguridad” dándole el nuevo nombre de “dimensiones” 43 e introduciendo nuevas varas de medir lo que interesa de los activos. El submodelo de procesos aparece bajo el epígrafe de “estructuración del proyecto de análisis y gestión de riesgos”. Si bien Magerit v1.0 ha resistido bien el paso del tiempo en lo conceptual, no se puede decir lo mismo de los detalles técnicos de los sistemas de información con los que se trabaja. Se intenta una puesta al día; pero ante todo se intenta diferenciar lo que es esencial (y permanente) de lo que es coyuntural y cambiará con el tiempo. Esto se traduce en parametrizar el método de trabajo, referenciándolo a catálogos externos de amenazas y salvaguardas que se podrán actualizar, adaptándose al paso del tiempo. Así pues, quede el método, abierto de forma que estando claro qué se hace y cómo, se puedan adaptar los detalles a cada momento. Los 7 libros segregados en Magerit versión 1, han evolucionado:

Magerit versión 1

Magerit versión 3

Libro I. Guía de aproximación a la seguridad de Libro I – Método los sistemas de información Libro II. Guía de procedimientos

Libro I – Método

Libro III. Guía de técnicas

Guía de Técnicas

Libro IV. Guía para desarrolladores de aplica- Libro I – Método / Capítulo 7 Desarrollo de sisciones temas de información Libro V. Guía para responsables del dominio Libro I – Método protegible Libro II – Catálogo de Elementos Libro VI. Arquitectura de la información y espe- Libro II – Catálogo de Elementos / formatos cificaciones de la interfaz para el intercambio de XML datos Libro VII. Referencia de normas legales y técni- Libro I – Método / Apéndice 3. Marco legal cas

43 Dimensión, en una de las acepciones del Diccionario de la Lengua Española, dícese que es “Cada una de las magnitudes de un conjunto que sirven para definir un fenómeno. Por ejemplo, el espacio de cuatro dimensiones de la teoría de la relatividad.”

© Ministerio de Hacienda y Administraciones Públicas

página 126 (de 127)

Magerit versión 2

Evolución de Magerit

A6.2. Para los que han trabajado con Magerit v2 Esta versión 3 mantiene en gran medida la estructura de la versión 2: — Libro I – Método — Libro II – Catálogo de Elementos — Técnicas Cambios en la versión 3: — mejor alineamiento con la normativa ISO, buscando una integración de las tareas de análisis de riesgos dentro de un marco organizacional de gestión de riesgos dirigido desde los órganos de gobierno — se aligera el texto — se eliminan partes poco importantes o poco usadas — se normalizan las diferentes actividades o

MAR – Método de Análisis de Riesgos

o

PAR – Proyecto de Análisis de Riesgos

o

PS – Plan de Seguridad

© Ministerio de Hacienda y Administraciones Públicas

página 127 (de 127)

MAGERIT – versión 3.0 Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información Libro II - Catálogo de Elementos

TÍTULO: MAGERIT – versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro II - Catálogo de Elementos Elaboración y coordinación de contenidos: Dirección General de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica Equipo responsable del proyecto: Director, Miguel Angel Amutio Gómez, Ministerio de Hacienda y Administraciones Públicas Javier Candau, Centro Criptológico Nacional, Ministerio de la Presidencia Consultor externo: José Antonio Mañas, Catedrático de la Universidad Politécnica de Madrid Características: Adobe Acrobat 5.0 Responsable edición digital: Subdirección General de Información, Documentación y Publicaciones (Jesús González Barroso) Madrid, octubre de 2012 Disponible esta publicación en el Portal de Administración Electrónica (PAe): http://administracionelectronica.gob.es/ Edita: © Ministerio de Hacienda y Administraciones Públicas Secretaría General Técnica Subdirección General de Información, Documentación y Publicaciones Centro de Publicaciones Colección: administración electrónica NIPO: 630-12-171-8

Magerit 3.0

Índice 1. Introducción.................................................................................................................... 6

2. Tipos de activos ............................................................................................................. 7

2.1. Activos esenciales..................................................................................................................7

2.1.1. Datos de carácter personal ............................................................................................8

2.2. Arquitectura del sistema.........................................................................................................8

2.3. [D] Datos / Información...........................................................................................................8

2.4. [K] Claves criptográficas.........................................................................................................9

2.5. [S] Servicios ...........................................................................................................................9

2.6. [SW] Software - Aplicaciones informáticas...........................................................................10

2.7. [HW] Equipamiento informático (hardware) .........................................................................10

2.8 [COM] Redes de comunicaciones.........................................................................................11

2.9. [Media] Soportes de información..........................................................................................12

2.10. [AUX] Equipamiento auxiliar...............................................................................................12

2.11. [L] Instalaciones .................................................................................................................13

2.12. [P] Personal........................................................................................................................13

2.13. XML ....................................................................................................................................13

2.13.1. Sintaxis BNF ...............................................................................................................13

2.13.2. Esquema XSD ............................................................................................................14

3. Dimensiones de valoración ......................................................................................... 15

3.1. [D] Disponibilidad .................................................................................................................15

3.2. [I] Integridad de los datos .....................................................................................................15

3.3. [C] Confidencialidad de la información.................................................................................15

3.4. [A] Autenticidad ....................................................................................................................16

3.5. [T] Trazabilidad.....................................................................................................................16

3.6. XML ......................................................................................................................................16

3.6.1. Sintaxis BNF .................................................................................................................16

3.6.2. Esquema XSD ..............................................................................................................17

3.7. Referencias ..........................................................................................................................17

4. Criterios de valoración................................................................................................. 19

4.1. Escalas estándar..................................................................................................................19

4.2. XML ......................................................................................................................................23

4.2.1. Sintaxis BNF .................................................................................................................23

4.2.2. Esquema XSD ..............................................................................................................24

4.3. Referencias ..........................................................................................................................24

5. Amenazas...................................................................................................................... 25

5.1. [N] Desastres naturales........................................................................................................25

5.1.1. [N.1] Fuego ...................................................................................................................25

5.1.2. [N.2] Daños por agua ...................................................................................................25

5.1.3. [N.*] Desastres naturales..............................................................................................26

5.2. [I] De origen industrial ..........................................................................................................27

5.2.1. [I.1] Fuego ....................................................................................................................27

5.2.2. [I.2] Daños por agua .....................................................................................................27

5.2.3. [I.*] Desastres industriales ............................................................................................28

5.2.4. [I.3] Contaminación mecánica ......................................................................................28

5.2.5. [I.4] Contaminación electromagnética ..........................................................................29

5.2.6. [I.5] Avería de origen físico o lógico .............................................................................29

5.2.7. [I.6] Corte del suministro eléctrico ................................................................................30

5.2.8. [I.7] Condiciones inadecuadas de temperatura o humedad .........................................30

5.2.9. [I.8] Fallo de servicios de comunicaciones ...................................................................30

5.2.10. [I.9] Interrupción de otros servicios y suministros esenciales.....................................31

5.2.11. [I.10] Degradación de los soportes de almacenamiento de la información ................31

5.2.12. [I.11] Emanaciones electromagnéticas.......................................................................32

5.3. [E] Errores y fallos no intencionados....................................................................................33

5.3.1. [E.1] Errores de los usuarios ........................................................................................33

5.3.2. [E.2] Errores del administrador .....................................................................................33

5.3.3. [E.3] Errores de monitorización (log) ............................................................................34

© Ministerio de Hacienda y Administraciones Públicas

página 3 (de 75)

Magerit 3.0 5.3.4. [E.4] Errores de configuración ......................................................................................34

5.3.5. [E.7] Deficiencias en la organización............................................................................34

5.3.6. [E.8] Difusión de software dañino .................................................................................35

5.3.7. [E.9] Errores de [re-]encaminamiento...........................................................................35

5.3.8. [E.10] Errores de secuencia .........................................................................................35

5.3.9. [E.14] Escapes de información .....................................................................................35

5.3.10. [E.15] Alteración accidental de la información............................................................36

5.3.11. [E.18] Destrucción de información..............................................................................36

5.3.12. [E.19] Fugas de información.......................................................................................37

5.3.13. [E.20] Vulnerabilidades de los programas (software) .................................................37

5.3.14. [E.21] Errores de mantenimiento / actualización de programas (software) ................37

5.3.15. [E.23] Errores de mantenimiento / actualización de equipos (hardware) ...................38

5.3.16. [E.24] Caída del sistema por agotamiento de recursos..............................................38

5.3.17. [E.25] Pérdida de equipos ..........................................................................................38

5.3.18. [E.28] Indisponibilidad del personal ............................................................................39

5.4. [A] Ataques intencionados....................................................................................................40

5.4.1. [A.3] Manipulación de los registros de actividad (log) ..................................................40

5.4.2. [A.4] Manipulación de la configuración .........................................................................40

5.4.3. [A.5] Suplantación de la identidad del usuario .............................................................41

5.4.4. [A.6] Abuso de privilegios de acceso............................................................................41

5.4.5. [A.7] Uso no previsto ....................................................................................................41

5.4.6. [A.8] Difusión de software dañino .................................................................................42

5.4.7. [A.9] [Re-]encaminamiento de mensajes......................................................................42

5.4.8. [A.10] Alteración de secuencia .....................................................................................42

5.4.9. [A.11] Acceso no autorizado.........................................................................................43

5.4.10. [A.12] Análisis de tráfico .............................................................................................43

5.4.11. [A.13] Repudio ............................................................................................................43

5.4.12. [A.14] Interceptación de información (escucha) .........................................................44

5.4.13. [A.15] Modificación deliberada de la información .......................................................44

5.4.14. [A.18] Destrucción de información..............................................................................44

5.4.15. [A.19] Divulgación de información ..............................................................................45

5.4.16. [A.22] Manipulación de programas .............................................................................45

5.4.17. [A.23] Manipulación de los equipos ............................................................................45

5.4.18. [A.24] Denegación de servicio ....................................................................................46

5.4.19. [A.25] Robo.................................................................................................................46

5.4.20. [A.26] Ataque destructivo ...........................................................................................46

5.4.21. [A.27] Ocupación enemiga .........................................................................................47

5.4.22. [A.28] Indisponibilidad del personal ............................................................................47

5.4.23. [A.29] Extorsión ..........................................................................................................47

5.4.24. [A.30] Ingeniería social (picaresca) ............................................................................47

5.5. Correlación de errores y ataques .........................................................................................48

5.6. Nuevas amenazas: XML ......................................................................................................49

5.6.1. Sintaxis BNF .................................................................................................................49

5.6.2. Esquema XSD ..............................................................................................................49

5.7. Nivel de la amenaza: XML ...................................................................................................50

5.7.1. Sintaxis BNF .................................................................................................................50

5.7.2. Esquema XSD ..............................................................................................................51

5.8. Referencias ..........................................................................................................................51

6. Salvaguardas ................................................................................................................ 53

6.1. Protecciones generales u horizontales ................................................................................53

6.2. Protección de los datos / información ..................................................................................54

6.3. Protección de las claves criptográficas ................................................................................54

6.4. Protección de los servicios...................................................................................................54

6.5. Protección de las aplicaciones (software) ............................................................................54

6.6. Protección de los equipos (hardware)..................................................................................55

6.7. Protección de las comunicaciones .......................................................................................55

6.8. Protección en los puntos de interconexión con otros sistemas ...........................................55

6.9. Protección de los soportes de información ..........................................................................55

© Ministerio de Hacienda y Administraciones Públicas

página 4 (de 75)

Magerit 3.0 6.10. Protección de los elementos auxiliares ..............................................................................56

6.11. Seguridad física – Protección de las instalaciones ............................................................56

6.12. Salvaguardas relativas al personal ....................................................................................56

6.13. Salvaguardas de tipo organizativo .....................................................................................56

6.14. Continuidad de operaciones...............................................................................................56

6.15. Externalización ...................................................................................................................57

6.16. Adquisición y desarrollo .....................................................................................................57

6.17. Referencias ........................................................................................................................57

Apéndice 1. Notación XML .............................................................................................. 59

Apéndice 2. Fichas ........................................................................................................... 60

A2.1. [info] Activos esenciales: información ................................................................................60

A2.2. [service] Activos esenciales: Servicio ................................................................................61

A2.3. [D] Datos / Información ......................................................................................................62

A2.4. [K] Claves criptográficas ....................................................................................................63

A2.5. [S] Servicios .......................................................................................................................63

A2.6. [SW] Aplicaciones (software) .............................................................................................64

A2.7. [HW] Equipamiento informático (hardware) .......................................................................65

A2.8. [COM] Redes de comunicaciones .....................................................................................65

A2.9. [Media] Soportes de información .......................................................................................66

A2.10. [AUX] Equipamiento auxiliar ............................................................................................67

A2.11. [L] Instalaciones ...............................................................................................................68

A2.12. [P] Personal .....................................................................................................................68

Apéndice 3. Modelo de valor ........................................................................................... 70

A3.1. Formato XML .....................................................................................................................70

Apéndice 4. Informes ....................................................................................................... 72

A4.1. Modelo de valor .................................................................................................................72

A4.2. Mapa de riesgos ................................................................................................................72

A4.3. Evaluación de salvaguardas ..............................................................................................73

A4.4. Estado de riesgo ................................................................................................................73

A4.5. Informe de insuficiencias ...................................................................................................73

A4.6. Plan de seguridad ..............................................................................................................74

© Ministerio de Hacienda y Administraciones Públicas

página 5 (de 75)

Magerit 3.0

Introducción

1. Introducción El objetivo de este catálogo de elementos que aparecen en un proyecto de análisis y gestión de riesgos es doble: 1. Por una parte, facilitar la labor de las personas que acometen el proyecto, en el sentido de ofrecerles ítem estándar a los que puedan adscribirse rápidamente, centrándose en lo es­ pecífico del sistema objeto del análisis. 2. Por otra, homogeneizar los resultados de los análisis, promoviendo una terminología y unos criterios que permitan comparar e incluso integrar análisis realizados por diferentes equipos. Persiguiendo estos objetivos, y sabiendo que la tecnología cambia rápidamente, las secciones que siguen describen un catálogo1 que marca unas pautas en cuanto a Tipos de activos, sabiendo que aparecerán nuevos tipos de activos continuamente. Dimensiones de valoración, sabiendo que en casos específicos pueden aparecer dimensio­ nes específicas; pero en la certidumbre de estar recogido lo esencial. Criterios de valoración, sabiendo que hay un fuerte componente de estimación por los exper­ tos; pero marcando una primera pauta de homogeneidad. El ánimo es relativizar el valor de los diferentes activos en sus diferentes dimensiones de valoración, de forma que no sólo se propone una escala dentro de una dimensión, sino que también se propone cómo se rela­ cionan las diferentes dimensiones entre sí. Amenazas, sabiendo que no todas las amenazas son significativas sobre todos los sistemas; pero con una razonable esperanza de que este catálogo crezca lentamente. Salvaguardas, sabiendo que es un terreno extremadamente complejo por su riqueza de tecno­ logías, productos y combinaciones ingeniosas de elementos básicos. Las salvaguardas se tratan con un enfoque de “identificación de necesidades” por parte de los responsables de los sistemas de información, mientras que se tratan con un enfoque de “controles de eficacia y eficiencia” por los auditores de sistemas. Se ha intentado un lenguaje intermedio que satis­ faga a ambos colectivos. Cada sección incluye una notación XML que se empleará para publicar los elementos en un for­ mato estándar capaz de ser procesado automáticamente por herramientas informáticas.

1 Este catálogo deberá adaptarse a la evolución de los sistemas de información. Es por ello que para cada categoría de elementos se define una notación XML que permitirá publicar ágilmente actualizaciones de este catálogo.

© Ministerio de Hacienda y Administraciones Públicas

página 6 (de 75)

Magerit 3.0

Tipos de activos

2. Tipos de activos

La tipificación de los activos es tanto un información documental de interés como un criterio de identificación de amenazas potenciales y salvaguardas apropiadas a la naturaleza del activo. La siguiente tabla no puede ser exhaustiva, ni tan siquiera válida para siempre. La relación que sigue clasifica los activos dentro de una jerarquía, determinando para cada uno un código que refleja su posición jerárquica, un nombre y una breve descripción de las características que recoge el epígrafe. Nótese que las pertenencia de un activo a un tipo no es excluyente de su pertenencia a otro tipo; es decir, un activo puede ser simultáneamente de varios tipos.

2.1. Activos esenciales En un sistema de información hay 2 cosas esenciales: — la información que se maneja y — los servicios que prestan. Estos activos esenciales marcan los requisitos de seguridad para todos los demás componentes del sistema. Dentro de la información que se maneja, puede ser interesante considerar algunas características formales tales como si son de carácter personal, con requisitos legales, o si están sometidos a alguna clasificación de seguridad, con requisitos normativos: [essential] Activos esenciales [info] información [adm] datos de interés para la administración pública [vr] datos vitales (registros de la organización) (1) [per] datos de carácter personal (2) [A] nivel alto [M] nivel medio [B] nivel bajo [classified] datos clasificados (3) [C] nivel confidencial [R] difusión limitada [UC] sin clasificar [pub] de carácter público [service] servicio

(1)

Dícese de aquellos que son esenciales para la supervivencia de la Organización; es decir que su carencia o daño afectaría directamente a la existencia de la Organización. Se pue­ den identificar aquellos que son imprescindibles para que la Organización supere una situa­ ción de emergencia, aquellos que permiten desempeñar o reconstruir las misiones críticas, aquellos sustancian la naturaleza legal o los derechos financieros de la Organización o sus usuarios.

(2)

Dícese de cualquier información concerniente a personas físicas identificadas o identifica­ bles. Los datos de carácter personal están regulados por leyes y reglamentos en cuanto afectan a las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente su honor e intimidad personal y familiar.

(3)

Dícese de aquellos sometidos a normativa específica de control de acceso y distribución; es decir aquellos cuya confidencialidad es especialmente relevante. La tipificación de qué datos deben ser clasificados y cuales son las normas para su tratamiento, vienen deter­ minadas por regulaciones sectoriales, por acuerdos entre organizaciones o por normativa interna.

© Ministerio de Hacienda y Administraciones Públicas

página 7 (de 75)

Magerit 3.0

Tipos de activos

2.1.1. Datos de carácter personal Existen leyes relativas a los datos de carácter personal que, en función de su naturaleza y las cir­ cunstancias, establecen una serie de obligaciones a los sistemas de información que los tratan. En el caso de la legislación española, se ajusta a los dispuesto en •

Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (B.O.E. número 298, de 14/12/1999)

•

Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desa­ rrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal. (BOE número 17 de 19/1/2008)

El reglamento establece medidas específicas de nivel básico, medio y alto.

2.2. Arquitectura del sistema Se trata de elementos que permiten estructurar el sistema, definiendo su arquitectura interna y sus relaciones con el exterior.

[arch] Arquitectura del sistema [sap] punto de [acceso al] servicio (1) [ip] punto de interconexión (2) [ext] proporcionado por terceros (3)

(1)

Establece una frontera entre la prestación de un servicio (proveedor) y el usuario (consumi­ dor). Los requisitos de seguridad del usuario se convierten en obligaciones del prestatario, mientras que los incidentes de seguridad en el proveedor repercuten en el usuario.

(2)

Establece una frontera inter-pares: cuando dos sistemas se interconectan para intercambiar información.

(3)

Establece una frontera inferior, cuando para la prestación de nuestros servicios recurrimos a un tercero.

2.3. [D] Datos / Información Los datos son el corazón que permite a una organización prestar sus servicios. La información es un activo abstracto que será almacenado en equipos o soportes de información (normalmente agrupado como ficheros o bases de datos) o será transferido de un lugar a otro por los medios de transmisión de datos.

[D] Datos / Información [files] ficheros [backup] copias de respaldo [conf] datos de configuración (1) [int] datos de gestión interna [password] credenciales (ej. contraseñas) [auth] datos de validación de credenciales [acl] datos de control de acceso [log] registro de actividad (2)

© Ministerio de Hacienda y Administraciones Públicas

página 8 (de 75)

Magerit 3.0

Tipos de activos [D] Datos / Información

[source] código fuente [exe] código ejecutable [test] datos de prueba

(1)

Los datos de configuración son críticos para mantener la funcionalidad de las partes y del conjunto del sistema de información.

(2)

Los registros de actividad sustancian los requisitos de trazabilidad.

2.4. [K] Claves criptográficas Las criptografía se emplea para proteger el secreto o autenticar a las partes. Las claves criptográ­ ficas, combinando secretos e información pública, son esenciales para garantizar el funcionamien­ to de los mecanismos criptográficos.

[keys] Claves criptográficas [info] protección de la información [encrypt] claves de cifra [shared_secret] secreto compartido (clave simétrica) (1) [public_encryption] clave pública de cifra (2) [public_decryption] clave privada de descifrado (2) [sign] claves de firma [shared_secret] secreto compartido (clave simétrica) [public_signature] clave privada de firma (2) [public_verification] clave pública de verificación de firma (2) [com] protección de las comunicaciones [channel] claves de cifrado del canal [authentication] claves de autenticación [verification] claves de verificación de autenticación [disk] cifrado de soportes de información [encrypt] claves de cifra [x509] certificados de clave pública

(1)

Por ejemplo, DES, 3-DES, AES, etc.

(2)

Por ejemplo, RSA, Diffie-Hellman, curvas elípticas, etc.

2.5. [S] Servicios Función que satisface una necesidad de los usuarios (del servicio). Esta sección contempla servi­ cios prestados por el sistema.

[S] Servicios [anon] anónimo (sin requerir identificación del usuario) [pub] al público en general (sin relación contractual) [ext] a usuarios externos (bajo una relación contractual) [int] interno (a usuarios de la propia organización)

© Ministerio de Hacienda y Administraciones Públicas

página 9 (de 75)

Magerit 3.0

Tipos de activos [S] Servicios

[www] world wide web [telnet] acceso remoto a cuenta local [email] correo electrónico [file] almacenamiento de ficheros [ftp] transferencia de ficheros [edi] intercambio electrónico de datos [dir] servicio de directorio (1) [idm] gestión de identidades (2) [ipm] gestión de privilegios [pki] PKI - infraestructura de clave pública (3)

(1)

Localización de personas (páginas blancas), empresas o servicios (páginas amarillas); per­ mitiendo la identificación y facilitando los atributos que caracterizan al elemento determina­ do.

(2)

Servicios que permiten altas y bajas de usuarios de los sistemas, incluyendo su caracteriza­ ción y activando los servicios de aprovisionamiento asociados a sus cambios de estado respecto de la organización.

(3)

Servicios asociados a sistemas de criptografía de clave pública, incluyendo especialmente la gestión de certificados.

2.6. [SW] Software - Aplicaciones informáticas Con múltiples denominaciones (programas, aplicativos, desarrollos, etc.) este epígrafe se refiere a tareas que han sido automatizadas para su desempeño por un equipo informático. Las aplicacio­ nes gestionan, analizan y transforman los datos permitiendo la explotación de la información para la prestación de los servicios. No preocupa en este apartado el denominado “código fuente” o programas que serán datos de interés comercial, a valorar y proteger como tales. Dicho código aparecería como datos.

[SW] Aplicaciones (software) [prp] desarrollo propio (in house) [sub] desarrollo a medida (subcontratado) [std] estándar (off the shelf) [browser] navegador web [www] servidor de presentación [app] servidor de aplicaciones [email_client] cliente de correo electrónico [email_server] servidor de correo electrónico [file] servidor de ficheros [dbms] sistema de gestión de bases de datos [tm] monitor transaccional [office] ofimática [av] anti virus [os] sistema operativo [hypervisor] gestor de máquinas virtuales [ts] servidor de terminales [backup] sistema de backup

2.7. [HW] Equipamiento informático (hardware) Dícese de los medios materiales, físicos, destinados a soportar directa o indirectamente los servi­ cios que presta la organización, siendo pues depositarios temporales o permanentes de los datos, © Ministerio de Hacienda y Administraciones Públicas

página 10 (de 75)

Magerit 3.0

Tipos de activos

soporte de ejecución de las aplicaciones informáticas o responsables del procesado o la transmi­ sión de datos.

[HW] Equipos informáticos (hardware) [host] grandes equipos (1) [mid] equipos medios (2) [pc] informática personal (3) [mobile] informática móvil (4) [pda] agendas electrónicas [vhost] equipo virtual [backup] equipamiento de respaldo (5) [peripheral] periféricos [print] medios de impresión (6) [scan] escáneres [crypto] dispositivos criptográficos [bp] dispositivo de frontera (7) [network] soporte de la red (8) [modem] módems [hub] concentradores [switch] conmutadores [router] encaminadores [bridge] pasarelas [firewall] cortafuegos [wap] punto de acceso inalámbrico [pabx] centralita telefónica [ipphone] teléfono IP

(1)

Se caracterizan por haber pocos, frecuentemente uno sólo, ser económicamente gravosos y requerir un entorno específico para su operación. Son difícilmente reemplazables en caso de destrucción.

(2)

Se caracterizan por haber varios, tener un coste económico medio tanto de adquisición co­ mo de mantenimiento e imponer requerimientos estándar como entorno de operación. No es difícil reemplazarlos en caso de destrucción.

(3)

Se caracterizan por ser multitud, tener un coste económico relativamente pequeño e impo­ ner solamente unos requerimientos mínimos como entorno de operación. Son fácilmente reemplazables en caso de destrucción.

(4)

Se caracterizan por ser equipos afectos a la clasificación como informática personal que, además, son fácilmente transportables de un sitio a otro, pudiendo estar tanto dentro del re­ cinto propio de la organización como en cualquier otro lugar.

(5)

Son aquellos equipos preparados para hacerse cargo inmediato de los equipos en produc­ ción.

(6)

Dícese de impresoras y servidores de impresión.

(7)

Son los equipos que se instalan entre dos zonas de confianza.

(8)

Dícese de equipamiento necesario para transmitir datos: routers, módems, etc.

2.8 [COM] Redes de comunicaciones Incluyendo tanto instalaciones dedicadas como servicios de comunicaciones contratados a terce­ ros; pero siempre centrándose en que son medios de transporte que llevan datos de un sitio a otro.

© Ministerio de Hacienda y Administraciones Públicas

página 11 (de 75)

Magerit 3.0

Tipos de activos [COM] Redes de comunicaciones

[PSTN] red telefónica [ISDN] rdsi (red digital) [X25] X25 (red de datos) [ADSL] ADSL [pp] punto a punto [radio] comunicaciones radio [wifi] red inalámbrica [mobile] telefonía móvil [sat] por satélite [LAN] red local [MAN] red metropolitana [Internet] Internet

2.9. [Media] Soportes de información En este epígrafe se consideran dispositivos físicos que permiten almacenar in­ formación de forma permanente o, al menos, durante largos periodos de tiempo.

[Media] Soportes de información [electronic] electrónicos [disk] discos [vdisk] discos virtuales [san] almacenamiento en red [disquette] disquetes [cd] cederrón (CD-ROM) [usb] memorias USB [dvd] DVD [tape] cinta magnética [mc] tarjetas de memoria [ic] tarjetas inteligentes [non_electronic] no electrónicos [printed] material impreso [tape] cinta de papel [film] microfilm [cards] tarjetas perforadas

2.10. [AUX] Equipamiento auxiliar En este epígrafe se consideran otros equipos que sirven de soporte a los siste­ mas de información, sin estar directamente relacionados con datos.

[AUX] Equipamiento auxiliar [power] fuentes de alimentación [ups] sistemas de alimentación ininterrumpida [gen] generadores eléctricos [ac] equipos de climatización [cabling] cableado [wire] cable eléctrico [fiber] fibra óptica [robot] robots [tape] ... de cintas [disk] ... de discos [supply] suministros esenciales [destroy] equipos de destrucción de soportes de información [furniture] mobiliario: armarios, etc [safe] cajas fuertes

© Ministerio de Hacienda y Administraciones Públicas

página 12 (de 75)

Magerit 3.0

Tipos de activos

2.11. [L] Instalaciones En este epígrafe entran los lugares donde se hospedan los sistemas de información y comunica­ ciones. [L] Instalaciones [site] recinto [building] edificio [local] cuarto [mobile] plataformas móviles [car] vehículo terrestre: coche, camión, etc. [plane] vehículo aéreo: avión, etc. [ship] vehículo marítimo: buque, lancha, etc. [shelter] contenedores [channel] canalización [backup] instalaciones de respaldo

2.12. [P] Personal En este epígrafe aparecen las personas relacionadas con los sistemas de información.

[P] Personal [ue] usuarios externos [ui] usuarios internos [op] operadores [adm] administradores de sistemas [com] administradores de comunicaciones [dba] administradores de BBDD [sec] administradores de seguridad [des] desarrolladores / programadores [sub] subcontratas [prov] proveedores

2.13. XML Los tipos de activos cabe esperar que evolucionen en el tiempo para adaptarse a la evolución tec­ nológica. Por ello se incluye a continuación una gramática de tipo XML que permita publicar perió­ dicamente actualizaciones de los tipos antes descritos.

2.13.1. Sintaxis BNF La notación se describe en el apéndice 1. { tipos }* tipos ::= { tipo }* tipo ::=

#name#

[ descripción ]

{ tipo }*



© Ministerio de Hacienda y Administraciones Públicas

página 13 (de 75)

Magerit 3.0

Tipos de activos

descripción ::= #texto#

Atributo

Ejemplo

Descripción

under

under=”X”

X identifica a un tipo de activos ya definido, indicando que los nuevos tipos de activos son refinamientos de X.

code

code=”X”

X es un identificador único que permite determinar unívocamente a qué tipo se refiere.

2.13.2. Esquema XSD version: magerit 3.0 (2011) date: 19.11.2011





























© Ministerio de Hacienda y Administraciones Públicas

página 14 (de 75)

Magerit 3.0

Dimensiones de valoración

3. Dimensiones de valoración Son las características o atributos que hacen valioso un activo. Una dimensión es una faceta o aspecto de un activo, independiente de otras facetas. Pueden hacerse análisis de riesgos centra­ dos en una única faceta, independientemente de lo que ocurra con otros aspectos2. Las dimensiones se utilizan para valorar las consecuencias de la materialización de una amenaza. La valoración que recibe un activo en una cierta dimensión es la medida del perjuicio para la or­ ganización si el activo se ve dañado en dicha dimensión.

3.1. [D] Disponibilidad [D] disponibilidad Propiedad o característica de los activos consistente en que las entidades o procesos au­ torizados tienen acceso a los mismos cuando lo requieren. [UNE 71504:2008] ¿Qué importancia tendría que el activo no estuviera disponible? Un activo tiene un gran valor desde el punto de vista de disponibilidad cuando si una amenaza afectara a su disponibilidad, las consecuencias serían graves. Y recíprocamente, un activo carece de un valor apreciable desde el punto de vista de disponibili­ dad cuando puede no estar disponible frecuentemente y durante largos periodos de tiempo sin por ello causar mayor daño. La disponibilidad es una característica que afecta a todo tipo de activos. A menudo la disponibilidad requiere un tratamiento por escalones pues el coste de la indisponibili­ dad aumenta de forma no lineal con la duración de la interrupción, desde breves interrupciones sin importancia, pasando por interrupciones que causan daños considerables y llegando a interrup­ ciones que no admiten recuperación: la organización está acabada.

3.2. [I] Integridad de los datos [I] integridad Propiedad o característica consistente en que el activo de información no ha sido alterado de manera no autorizada. [ISO/IEC 13335-1:2004] ¿Qué importancia tendría que los datos fueran modificados fuera de control? Los datos reciben una alta valoración desde el punto de vista de integridad cuando su alteración, voluntaria o intencionada, causaría graves daños a la organización. Y, recíprocamente, los datos carecen de un valor apreciable desde el punto de vista de integridad cuando su alteración no supone preocupación alguna.

3.3. [C] Confidencialidad de la información [C] confidencialidad Propiedad o característica consistente en que la información ni se pone a disposición, ni se revela a individuos, entidades o procesos no autorizados. [UNE-ISO/IEC 27001:2007] ¿Qué importancia tendría que el dato fuera conocido por personas no autorizadas?

2 Como es el caso típico conocido como análisis de impacto (BIA) que busca determinar el coste de las paradas de los sistemas y desarrollar planes de contingencia para poner coto al tiempo de parada de la organización. En este caso se hace un análisis sectario de la disponibilidad.

© Ministerio de Hacienda y Administraciones Públicas

página 15 (de 75)

Magerit 3.0

Dimensiones de valoración

Los datos reciben una alta valoración desde el punto de vista de confidencialidad cuando su reve­ lación causaría graves daños a la organización. Y, recíprocamente, los datos carecen de un valor apreciable desde el punto de vista de confiden­ cialidad cuando su conocimiento por cualquiera no supone preocupación alguna.

3.4. [A] Autenticidad [A] autenticidad Propiedad o característica consistente en que una entidad es quien dice ser o bien que garantiza la fuente de la que proceden los datos. [UNE 71504:2008] ¿Qué importancia tendría que quien accede al servicio no sea realmente quien se cree? La autenticidad de los usuarios de un servicio es lo contrario de la oportunidad de fraude o uso no autorizado de un servicio. Así, un servicio recibe una elevada valoración desde el punto de vista de autenticidad cuando su prestación a falsos usuarios supondría un grave perjuicio para la organización. Y, recíprocamente, un servicio carece de un valor apreciable desde el punto de vista de autentici­ dad cuando su acceso por cualquiera no supone preocupación alguna. ¿Qué importancia tendría que los datos no fueran realmente imputables a quien se cree? Los datos reciben una elevada valoración desde el punto de vista de autenticidad del origen cuan­ do un defecto de imputación causaría graves quebrantos a la organización. Típicamente, se habili­ ta la oportunidad de repudio. Y, recíprocamente, los datos carecen de un valor apreciable desde el punto de vista de autentici­ dad del origen cuando ignorar la fuente es irrelevante.

3.5. [T] Trazabilidad [T] trazabilidad Propiedad o característica consistente en que las actuaciones de una entidad pueden ser imputadas exclusivamente a dicha entidad. [UNE 71504:2008]

¿Qué importancia tendría que no quedara constancia fehaciente del uso del servicio? Abriría las puertas al fraude, incapacitaría a la Organización para perseguir delitos y podría supo­ ner el incumplimiento de obligaciones legales. ¿Qué importancia tendría que no quedara constancia del acceso a los datos? Abriría las puertas al fraude, incapacitaría a la Organización para perseguir delitos y podría supo­ ner el incumplimiento de obligaciones legales.

3.6. XML Las dimensiones de valoración cabe esperar que evolucionen en el tiempo para adaptarse a la evolución tecnológica. Por ello se incluye a continuación una gramática de tipo XML que permita publicar periódicamente actualizaciones de las dimensiones antes descritas.

3.6.1. Sintaxis BNF La notación se describe en el apéndice 1. { dimensiones }*

© Ministerio de Hacienda y Administraciones Públicas

página 16 (de 75)

Magerit 3.0

Dimensiones de valoración

dimensiones ::= { dimensión }* dimensión ::= #nombre# [ descripción ] descripción ::= #texto#

Atributo code

Ejemplo code=”X”

Descripción X es un identificador único que permite determinar unívocamente a qué dimensión se refiere.

3.6.2. Esquema XSD

version: magerit 3.0 (2011)

date: 19.11.2011





































3.7. Referencias •

ISO 7498-2:1989, “Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 2: Security Architecture”, 1989.

© Ministerio de Hacienda y Administraciones Públicas

página 17 (de 75)

Magerit 3.0

Dimensiones de valoración

•

ISO/IEC 27000

•

FIPS PUB 199, “Standards for Security Categorization of Federal Information and Informa­ tion Systems”, December 2003. http://csrc.nist.gov/publications/fips/index.html

•

C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”, Addison Wesley, 2003. http://www.cert.org/octave/

© Ministerio de Hacienda y Administraciones Públicas

página 18 (de 75)

Magerit 3.0

Criterios de valoración

4. Criterios de valoración Para valorar los activos vale, teóricamente, cualquier escala de valores. A efectos prácticos es sin embargo muy importante que •

se use una escala común para todas las dimensiones, permitiendo comparar riesgos,

•

se use una escala logarítmica, centrada en diferencias relativas de valor, que no en diferen­ cias absolutas3 y

•

se use un criterio homogéneo que permita comparar análisis realizados por separado

Si la valoración es económica, hay poco más que hablar: dinero. Pero frecuentemente la valora­ ción es cualitativa, quedando a discreción del usuario; es decir, respondiendo a criterios subjeti­ vos. Se ha elegido una escala detallada de diez valores, dejando en valor 0 como determinante de lo que sería un valor despreciable (a efectos de riesgo). Si se realiza un análisis de riesgos de poco detalle, se puede optar por la tabla simplificada de menos niveles. Ambas escalas, detallada y simplificada se correlacionan como se indica a continuación:

valor

criterio

10

extremo

daño extremadamente grave

9

muy alto

daño muy grave

6-8

alto

daño grave

3-5

medio

daño importante

1-2

bajo

daño menor

0

despreciable

irrelevante a efectos prácticos

Las tablas siguientes pretenden guiar con más detalle a los usuarios valorando de forma homogé­ nea activos cuyo valor es importante por diferentes motivos.

4.1. Escalas estándar [pi] Información de carácter personal 6

6.pi1

probablemente afecte gravemente a un grupo de individuos

6.pi2

probablemente quebrante seriamente la ley o algún reglamento de protección de información personal

3 Así siempre es igual de relevante que un activo sea el doble de valioso que otro, independientemente de su valor absoluto. Por el contrario, sería extraño opinar que un activo vale dos más que otro sin explicitar su valor absoluto pues no es igual de relevante pasar de 0,1 a 2,1, que pasar de 1.000.000 a 1.000.002.

© Ministerio de Hacienda y Administraciones Públicas

página 19 (de 75)

Magerit 3.0 5

4

3

2

1

Criterios de valoración

5.pi1

probablemente afecte gravemente a un individuo

5.pi2

probablemente quebrante seriamente leyes o regulaciones

4.pi1

probablemente afecte a un grupo de individuos

4.pi2

probablemente quebrante leyes o regulaciones

3.pi1

probablemente afecte a un individuo

3.pi2

probablemente suponga el incumplimiento de una ley o regulación

2.pi1

pudiera causar molestias a un individuo

2.pi2

pudiera quebrantar de forma leve leyes o regulaciones

1.pi1

pudiera causar molestias a un individuo

[lpo] Obligaciones legales 9

9.lro

probablemente cause un incumplimiento excepcionalmente grave de una ley o re­ gulación

7

7.lro

probablemente cause un incumplimiento grave de una ley o regulación

5

5.lro

probablemente sea causa de incumplimiento de una ley o regulación

3

3.lro

probablemente sea causa de incumplimiento leve o técnico de una ley o regulación

1

1.lro

pudiera causar el incumplimiento leve o técnico de una ley o regulación

[si] Seguridad 10

10.si

probablemente sea causa de un incidente excepcionalmente serio de seguridad o dificulte la investigación de incidentes excepcionalmente serios

9

9.si

probablemente sea causa de un serio incidente de seguridad o dificulte la investi­ gación de incidentes serios

7

7.si

probablemente sea causa de un grave incidente de seguridad o dificulte la investi­ gación de incidentes graves

3

3.si

probablemente sea causa de una merma en la seguridad o dificulte la investiga­ ción de un incidente

1

1.si

pudiera causar una merma en la seguridad o dificultar la investigación de un inci­ dente

[cei] Intereses comerciales o económicos 9

7

9.cei.a

de enorme interés para la competencia

9.cei.b

de muy elevado valor comercial

9.cei.c

causa de pérdidas económicas excepcionalmente elevadas

9.cei.d

causa de muy significativas ganancias o ventajas para individuos u organizaciones

9.cei.e

constituye un incumplimiento excepcionalmente grave de las obligaciones contrac­ tuales relativas a la seguridad de la información proporcionada por terceros

7.cei.a

de alto interés para la competencia

7.cei.b

de elevado valor comercial

7.cei.c

causa de graves pérdidas económicas

7.cei.d

proporciona ganancias o ventajas desmedidas a individuos u organizaciones

© Ministerio de Hacienda y Administraciones Públicas

página 20 (de 75)

Magerit 3.0

3

2

1

0

Criterios de valoración

7.cei.e

constituye un serio incumplimiento de obligaciones contractuales relativas a la se­ guridad de la información proporcionada por terceros

3.cei.a

de cierto interés para la competencia

3.cei.b

de cierto valor comercial

3.cei.c

causa de pérdidas financieras o merma de ingresos

3.cei.d

facilita ventajas desproporcionadas a individuos u organizaciones

3.cei.e

constituye un incumplimiento leve de obligaciones contractuales para mantener la seguridad de la información proporcionada por terceros

2.cei.a

de bajo interés para la competencia

2.cei.b

de bajo valor comercial

1.cei.a

de pequeño interés para la competencia

1.cei.b

de pequeño valor comercial

0.3

supondría pérdidas económicas mínimas

[da] Interrupción del servicio 9

9.da

Probablemente cause una interrupción excepcionalmente seria de las actividades propias de la Organización con un serio impacto en otras organizaciones

9.da2

Probablemente tenga un serio impacto en otras organizaciones

7.da

Probablemente cause una interrupción seria de las actividades propias de la Or­ ganización con un impacto significativo en otras organizaciones

7.da2

Probablemente tenga un gran impacto en otras organizaciones

5.da

Probablemente cause la interrupción de actividades propias de la Organización con impacto en otras organizaciones

5.da2

Probablemente cause un cierto impacto en otras organizaciones

3

3.da

Probablemente cause la interrupción de actividades propias de la Organización

1

1.da

Pudiera causar la interrupción de actividades propias de la Organización

7

5

[po] Orden público 9

9.po

alteración seria del orden público

6

6.po

probablemente cause manifestaciones, o presiones significativas

3

3.po

causa de protestas puntuales

1

1.po

pudiera causar protestas puntuales

[olm] Operaciones 10

10.olm

Probablemente cause un daño excepcionalmente serio a la eficacia o seguridad de la misión operativa o logística

9

9.olm

Probablemente cause un daño serio a la eficacia o seguridad de la misión operati­ va o logística

7

7.olm

Probablemente perjudique la eficacia o seguridad de la misión operativa o logística

5

5.olm

Probablemente merme la eficacia o seguridad de la misión operativa o logística más allá del ámbito local

© Ministerio de Hacienda y Administraciones Públicas

página 21 (de 75)

Magerit 3.0

Criterios de valoración

3

3.olm

Probablemente merme la eficacia o seguridad de la misión operativa o logística (alcance local)

1

1.olm

Pudiera mermar la eficacia o seguridad de la misión operativa o logística (alcance local)

[adm] Administración y gestión 9

9.adm

probablemente impediría seriamente la operación efectiva de la Organización, pu­ diendo llegar a su cierre

7

7.adm

probablemente impediría la operación efectiva de la Organización

5

5.adm

probablemente impediría la operación efectiva de más de una parte de la Organi­ zación

3

3.adm

probablemente impediría la operación efectiva de una parte de la Organización

1

1.adm

pudiera impedir la operación efectiva de una parte de la Organización

[lg] Pérdida de confianza (reputación) 9

9.lg.a

Probablemente causaría una publicidad negativa generalizada por afectar de for­ ma excepcionalmente grave a las relaciones a las relaciones con otras organiza­ ciones

9.lg.b

Probablemente causaría una publicidad negativa generalizada por afectar de for­ ma excepcionalmente grave a las relaciones a las relaciones con el público en ge­ neral

7.lg.a

Probablemente causaría una publicidad negativa generalizada por afectar grave­ mente a las relaciones con otras organizaciones

7.lg.b

Probablemente causaría una publicidad negativa generalizada por afectar grave­ mente a las relaciones con el público en general

5.lg.a

Probablemente sea causa una cierta publicidad negativa por afectar negativamen­ te a las relaciones con otras organizaciones

5.lg.b

Probablemente sea causa una cierta publicidad negativa por afectar negativamen­ te a las relaciones con el público

3

3.lg

Probablemente afecte negativamente a las relaciones internas de la Organización

2

2.lg

Probablemente cause una pérdida menor de la confianza dentro de la Organización

1

1.lg

Pudiera causar una pérdida menor de la confianza dentro de la Organización

0

0.4

no supondría daño a la reputación o buena imagen de las personas u organizacio­ nes

7

5

[crm] Persecución de delitos 8

8.crm

Impida la investigación de delitos graves o facilite su comisión

4

4.crm

Dificulte la investigación o facilite la comisión de delitos

[rto] Tiempo de recuperación del servicio 7

7.rto

RTO < 4 horas

© Ministerio de Hacienda y Administraciones Públicas

página 22 (de 75)

Magerit 3.0

Criterios de valoración

4

4.rto

4 horas < RTO < 1 día

1

1.rto

1 día < RTO < 5 días

0

0.rto

5 días < RTO

[lbl.nat] Información clasificada (nacional) 10

10.lbl

Secreto

9

9.lbl

Reservado

8

8.lbl

Confidencial

7

7.lbl

Confidencial

6

6.lbl

Difusión limitada

5

5.lbl

Difusión limitada

4

4.lbl

Difusión limitada

3

3.lbl

Difusión limitada

2

2.lbl

Sin clasificar

1

1.lbl

Sin clasificar

[lbl.ue] Información clasificada (Unión Europea) 10

10.ue

TRES SECRET UE

9

9.ue

SECRET UE

8

8.ue

CONFIDENTIEL UE

7

7.ue

CONFIDENTIEL UE

6

6.ue

RESTREINT UE

5

5.ue

RESTREINT UE

4

4.ue

RESTREINT UE

3

3.ue

RESTREINT UE

4.2. XML Los tipos de activos cabe esperar que evolucionen en el tiempo para adaptarse a la evolución tec­ nológica. Por ello se incluye a continuación una gramática de tipo XML que permita publicar perió­ dicamente actualizaciones de los tipos antes descritos.

4.2.1. Sintaxis BNF La notación se describe en el apéndice 1. criterios ::= { criterio }* criterio ::=

#texto#

{ criterio }*



© Ministerio de Hacienda y Administraciones Públicas

página 23 (de 75)

Magerit 3.0 Atributo

Criterios de valoración Descripción

Ejemplo

value

value=”X” X es un índice entre 0 y 10 de valoración cualitativa de activos.

code

code=”X”

X es un código único para identificar el criterio; en relación a la tabla previa, se identificará el epígrafe; por ejemplo, “7.4.c”

4.2.2. Esquema XSD

version: magerit 3.0 (2011)

date: 19.11.2011































4.3. Referencias •

CCN-STIC-803 – Esquema Nacional de Seguridad – Criterios de Valoración.

•

SP 800-60, “Guide for Mapping Types of Information and Information Systems to Security Categories”, NIST, June 2004. http://csrc.nist.gov/publications/nistpubs/index.html

•

HMG, “Residual Risk Assessment Method”, INFOSEC Standard No. 1. 2003.

•

C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”, Addison Wesley, 2003. http://www.cert.org/octave/

© Ministerio de Hacienda y Administraciones Públicas

página 24 (de 75)

Magerit 3.0

Amenazas

5. Amenazas Se presenta a continuación un catálogo de amenazas posibles sobre los activos de un sistema de información. Para cada amenaza se presenta un cuadro como el siguiente: [código] descripción sucinta de lo que puede pasar Tipos de activos: •

que se pueden ver afectados por este ti­ po de amenazas

Dimensiones: 1. de seguridad que se pueden ver afecta­ das por este tipo de amenaza, ordenadas de más a menos relevante

Descripción: complementaria o más detallada de la amenaza: lo que le puede ocurrir a activos del tipo indi­ cado con las consecuencias indicadas

5.1. [N] Desastres naturales Sucesos que pueden ocurrir sin intervención de los seres humanos como causa directa o indire­ cta. Origen: Natural (accidental)

5.1.1. [N.1] Fuego [N.1] Fuego Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

Descripción: incendios: posibilidad de que el fuego acabe con recursos del sistema. Ver: EBIOS: 01- INCENDIO

5.1.2. [N.2] Daños por agua [N.2] Daños por agua Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

Descripción: inundaciones: posibilidad de que el agua acabe con recursos del sistema. Ver: EBIOS: 02 - PERJUICIOS OCASIONADOS POR EL AGUA

© Ministerio de Hacienda y Administraciones Públicas

página 25 (de 75)

Magerit 3.0

Amenazas

5.1.3. [N.*] Desastres naturales [N.*] Desastres naturales Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

Descripción: otros incidentes que se producen sin intervención humana: rayo, tormenta eléctrica, terremoto, ciclones, avalancha, corrimiento de tierras, ... Se excluyen desastres específicos tales como incendios (ver [N.1]) e inundaciones (ver [N.2]). Se excluye al personal por cuanto se ha previsto una amenaza específica [E.31] para cubrir la indisponibilidad involuntaria del personal sin entrar en sus causas. Ver: EBIOS: 03 – CONTAMINACIÓN 04 - SINIESTRO MAYOR 06 - FENÓMENO CLIMÁTICO 07 - FENÓMENO SÍSMICO 08 - FENÓMENO DE ORIGEN VOLCÁNICO 09 - FENÓMENO METEOROLÓGICO 10 - INUNDACIÓN

© Ministerio de Hacienda y Administraciones Públicas

página 26 (de 75)

Magerit 3.0

Amenazas

5.2. [I] De origen industrial Sucesos que pueden ocurrir de forma accidental, derivados de la actividad humana de tipo indus­ trial. Estas amenazas puede darse de forma accidental o deliberada.

5.2.1. [I.1] Fuego [I.1] Fuego Tipos de activos: • • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

Descripción: incendio: posibilidad de que el fuego acabe con los recursos del sistema. Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 01- INCENDIO

5.2.2. [I.2] Daños por agua [I.2] Daños por agua Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

Descripción: escapes, fugas, inundaciones: posibilidad de que el agua acabe con los recursos del sistema. Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 02 - PERJUICIOS OCASIONADOS POR EL AGUA

© Ministerio de Hacienda y Administraciones Públicas

página 27 (de 75)

Magerit 3.0

Amenazas

5.2.3. [I.*] Desastres industriales [I.*] Desastres industriales Tipos de activos: • • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

Descripción: otros desastres debidos a la actividad humana: explosiones, derrumbes, ... contaminación química, ... sobrecarga eléctrica, fluctuaciones eléctricas, ... accidentes de tráfico, ... Se excluyen amenazas específicas como incendio (ver [I.1]) e inundación (ver [I.2]). Se excluye al personal por cuanto se ha previsto una amenaza específica, [E.31], para cubrir la indisponibilidad involuntaria del personal sin entrar en sus causas. Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 04 - SINIESTRO MAYOR

5.2.4. [I.3] Contaminación mecánica [I.3] Contaminación mecánica Tipos de activos: • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

1. [D] disponibilidad

Descripción: vibraciones, polvo, suciedad, ... Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 03 – CONTAMINACIÓN

© Ministerio de Hacienda y Administraciones Públicas

página 28 (de 75)

Magerit 3.0

Amenazas

5.2.5. [I.4] Contaminación electromagnética [I.4] Contaminación electromagnética Tipos de activos: • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes de información (electrónicos) [AUX] equipamiento auxiliar

Descripción: interferencias de radio, campos magnéticos, luz ultravioleta, ... Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 14 - EMISIONES ELECTROMAGNÉTICAS 15- RADIACIONES TÉRMICAS 16 - IMPULSOS ELECTROMAGNÉTICOS

5.2.6. [I.5] Avería de origen físico o lógico [I.5] Avería de origen físico o lógico Tipos de activos: • • • •

Dimensiones:

[SW] aplicaciones (software) [HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

1. [D] disponibilidad

Descripción: fallos en los equipos y/o fallos en los programas. Puede ser debida a un defecto de origen o sobrevenida durante el funcionamiento del sistema. En sistemas de propósito específico, a veces es difícil saber si el origen del fallo es físico o lógico; pero para las consecuencias que se derivan, esta distinción no suele ser relevante. Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 28 - AVERÍA DEL HARDWARE 29 - FALLA DE FUNCIONAMIENTO DEL HARDWARE

© Ministerio de Hacienda y Administraciones Públicas

página 29 (de 75)

Magerit 3.0

Amenazas

5.2.7. [I.6] Corte del suministro eléctrico [I.6] Corte del suministro eléctrico Tipos de activos: • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes de información (electrónicos) [AUX] equipamiento auxiliar

Descripción: cese de la alimentación de potencia Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 12 - PÉRDIDA DE SUMINISTRO DE ENERGÍA

5.2.8. [I.7] Condiciones inadecuadas de temperatura o humedad [I.7] Condiciones inadecuadas de temperatura y/o humedad Tipos de activos: • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

1. [D] disponibilidad

Descripción: deficiencias en la aclimatación de los locales, excediendo los márgenes de trabajo de los equipos: excesivo calor, excesivo frío, exceso de humedad, ... Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 11- FALLAS EN LA CLIMATIZACIÓN

5.2.9. [I.8] Fallo de servicios de comunicaciones [I.8] Fallo de servicios de comunicaciones Tipos de activos: •

Dimensiones:

[COM] redes de comunicaciones

1. [D] disponibilidad

Descripción: cese de la capacidad de transmitir datos de un sitio a otro. Típicamente se debe a la destruc­ ción física de los medios físicos de transporte o a la detención de los centros de conmutación, sea por destrucción, detención o simple incapacidad para atender al tráfico presente. Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 13 - PÉRDIDA DE LOS MEDIOS DE TELECOMUNICACIÓN

© Ministerio de Hacienda y Administraciones Públicas

página 30 (de 75)

Magerit 3.0

Amenazas

5.2.10. [I.9] Interrupción de otros servicios y suministros esenciales [I.9] Interrupción de otros servicios y suministros esenciales Tipos de activos: •

Dimensiones:

[AUX] equipamiento auxiliar

1. [D] disponibilidad

Descripción: otros servicios o recursos de los que depende la operación de los equipos; por ejemplo, papel para las impresoras, toner, refrigerante, ... Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: no disponible

5.2.11. [I.10] Degradación de los soportes de almacenamiento de la informa­ ción [I.10] Degradación de los soportes de almacenamiento de la información Tipos de activos: •

Dimensiones:

[Media] soportes de información

1. [D] disponibilidad

Descripción: como consecuencia del paso del tiempo Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 28 - AVERÍA DEL HARDWARE 29 - FALLA DE FUNCIONAMIENTO DEL HARDWARE

© Ministerio de Hacienda y Administraciones Públicas

página 31 (de 75)

Magerit 3.0

Amenazas

5.2.12. [I.11] Emanaciones electromagnéticas [I.11] Emanaciones electromagnéticas Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] media [AUX] equipamiento auxiliar [L] instalaciones

1. [C] confidencialidad

Descripción: hecho de poner vía radio datos internos a disposición de terceros. Es una amenaza donde el emisor es víctima pasiva del ataque. Prácticamente todos los dispositivos electrónicos emiten radiaciones al exterior que pudieran ser interceptadas por otros equipos (receptores de radio) derivándose una fuga de informa­ ción. Esta amenaza se denomina, incorrecta pero frecuentemente, ataque TEMPEST (del inglés “Transient Electromagnetic Pulse Standard”). Abusando del significado primigenio, es frecuen­ te oír hablar de que un equipo disfruta de "TEMPEST protection", queriendo decir que se ha diseñado para que no emita, electromagnéticamente, nada de interés por si alguien lo captara. No se contempla en esta amenaza la emisión por necesidades del medio de comunicación: redes inalámbricas, enlaces de microondas, etc. que estarán amenazadas de interceptación. Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 17 - INTERCEPTACIÓN DE SEÑALES PARÁSITAS COMPROMETEDORAS

© Ministerio de Hacienda y Administraciones Públicas

página 32 (de 75)

Magerit 3.0

Amenazas

5.3. [E] Errores y fallos no intencionados Fallos no intencionales causados por las personas. La numeración no es consecutiva, sino que está alineada con los ataques deliberados, muchas veces de naturaleza similar a los errores no intencionados, difiriendo únicamente en el propósito del sujeto. Origen: Humano (accidental) Ver correlación de errores y amenazas.

5.3.1. [E.1] Errores de los usuarios [E.1] Errores de los usuarios Tipos de activos: • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [Media] soportes de información

1. [I] integridad 2. [C] confidencialidad 3. [D] disponibilidad

Descripción: equivocaciones de las personas cuando usan los servicios, datos, etc. Ver: EBIOS: 38 - ERROR DE USO

5.3.2. [E.2] Errores del administrador [E.2] Errores del administrador Tipos de activos: • • • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [Media] soportes de información

1. [D] disponibilidad 2. [I] integridad 3. [C] confidencialidad

Descripción: equivocaciones de personas con responsabilidades de instalación y operación Ver: EBIOS: 38 - ERROR DE USO

© Ministerio de Hacienda y Administraciones Públicas

página 33 (de 75)

Magerit 3.0

Amenazas

5.3.3. [E.3] Errores de monitorización (log) [E.3] Errores de monitorización (log) Tipos de activos: •

Dimensiones:

[D.log] registros de actividad

1. [I] integridad (trazabilidad)

Descripción: inadecuado registro de actividades: falta de registros, registros incompletos, registros incorrec­ tamente fechados, registros incorrectamente atribuidos, ... Ver: EBIOS: no disponible

5.3.4. [E.4] Errores de configuración [E.4] Errores de configuración Tipos de activos: •

Dimensiones:

[D.conf] datos de configuración

1. [I] integridad

Descripción: introducción de datos de configuración erróneos. Prácticamente todos los activos dependen de su configuración y ésta de la diligencia del ad­ ministrador: privilegios de acceso, flujos de actividades, registro de actividad, encaminamien­ to, etc. Ver: EBIOS: no disponible

5.3.5. [E.7] Deficiencias en la organización Obsoleta. [E.7] Deficiencias en la organización Tipos de activos: •

Dimensiones:

[P] personal

1. [D] disponibilidad

Descripción: cuando no está claro quién tiene que hacer exactamente qué y cuándo, incluyendo tomar me­ didas sobre los activos o informar a la jerarquía de gestión. Acciones descoordinadas, errores por omisión, etc. Ver: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 34 (de 75)

Magerit 3.0

Amenazas

5.3.6. [E.8] Difusión de software dañino [E.8] Difusión de software dañino Tipos de activos: •

Dimensiones:

[SW] aplicaciones (software)

1. [D] disponibilidad 2. [I] integridad 3. [C] confidencialidad

Descripción: propagación inocente de virus, espías (spyware), gusanos, troyanos, bombas lógicas, etc. Ver: EBIOS: no disponible

5.3.7. [E.9] Errores de [re-]encaminamiento [E.9] Errores de [re-]encaminamiento Tipos de activos: • • •

Dimensiones: 1. [C] confidencialidad

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

Descripción: envío de información a través de un sistema o una red usando, accidentalmente, una ruta in­ correcta que lleve la información a donde o por donde no es debido; puede tratarse de mensa­ jes entre personas, entre procesos o entre unos y otros. Es particularmente destacable el caso de que el error de encaminamiento suponga un error de entrega, acabando la información en manos de quien no se espera. Ver: EBIOS: no disponible

5.3.8. [E.10] Errores de secuencia [E.10] Errores de secuencia Tipos de activos: • • •

Dimensiones: 1. [I] integridad

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

Descripción: alteración accidental del orden de los mensajes transmitidos. Ver: EBIOS: no disponible

5.3.9. [E.14] Escapes de información Obsoleta: use E.19. [E.14] Escapes de información Tipos de activos:

Dimensiones:

•

1. [C] confidencialidad

Descripción: la información llega accidentalmente al conocimiento de personas que no deberían tener co­ nocimiento de ella, sin que la información en sí misma se vea alterada. © Ministerio de Hacienda y Administraciones Públicas

página 35 (de 75)

Magerit 3.0

Amenazas

5.3.10. [E.15] Alteración accidental de la información [E.15] Alteración accidental de la información Tipos de activos: • • • • • • •

Dimensiones: 1. [I] integridad

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones

Descripción: alteración accidental de la información. Esta amenaza sólo se identifica sobre datos en general, pues cuando la información está en algún soporte informático, hay amenazas específicas. Ver: EBIOS: no disponible

5.3.11. [E.18] Destrucción de información [E.18] Destrucción de información Tipos de activos: • • • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones

1. [D] disponibilidad

Descripción: pérdida accidental de información. Esta amenaza sólo se identifica sobre datos en general, pues cuando la información está en algún soporte informático, hay amenazas específicas. Ver: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 36 (de 75)

Magerit 3.0

Amenazas

5.3.12. [E.19] Fugas de información [E.19] Fugas de información Tipos de activos: • • • • • • • •

Dimensiones: 1. [C] confidencialidad

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones [P] personal (revelación)

Descripción: revelación por indiscreción. Incontinencia verbal, medios electrónicos, soporte papel, etc. Ver: EBIOS: no disponible

5.3.13. [E.20] Vulnerabilidades de los programas (software) [E.20] Vulnerabilidades de los programas (software) Tipos de activos: •

Dimensiones:

[SW] aplicaciones (software)

1. [I] integridad 2. [D] disponibilidad 3. [C] confidencialidad

Descripción: defectos en el código que dan pie a una operación defectuosa sin intención por parte del usuario pero con consecuencias sobre la integridad de los datos o la capacidad misma de operar. Ver: EBIOS: no disponible

5.3.14. [E.21] Errores de mantenimiento / actualización de programas (softwa­ re) [E.21] Errores de mantenimiento / actualización de programas (software) Tipos de activos: •

Dimensiones:

[SW] aplicaciones (software)

1. [I] integridad 2. [D] disponibilidad

Descripción: defectos en los procedimientos o controles de actualización del código que permiten que sigan utilizándose programas con defectos conocidos y reparados por el fabricante. Ver: EBIOS: 31 - FALLA DE FUNCIONAMIENTO DEL SOFTWARE 32 - PERJUICIO A LA MANTENIBILIDAD DEL SISTEMA DE INFORMACIÓN

© Ministerio de Hacienda y Administraciones Públicas

página 37 (de 75)

Magerit 3.0

Amenazas

5.3.15. [E.23] Errores de mantenimiento / actualización de equipos (hardware) [E.23] Errores de mantenimiento / actualización de equipos (hardware) Tipos de activos: • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes electrónicos [AUX] equipamiento auxiliar

Descripción: defectos en los procedimientos o controles de actualización de los equipos que permiten que sigan utilizándose más allá del tiempo nominal de uso. Ver: EBIOS: 32 - PERJUICIO A LA MANTENIBILIDAD DEL SISTEMA DE INFORMACIÓN

5.3.16. [E.24] Caída del sistema por agotamiento de recursos [E.24] Caída del sistema por agotamiento de recursos Tipos de activos: • • •

Dimensiones:

[S] servicios [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

1. [D] disponibilidad

Descripción: la carencia de recursos suficientes provoca la caída del sistema cuando la carga de trabajo es desmesurada. Ver: EBIOS: 30 - SATURACIÓN DEL SISTEMA INFORMÁTICO

5.3.17. [E.25] Pérdida de equipos [E.25] Robo Tipos de activos: • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

1. [D] disponibilidad 2. [C] confidencialidad

Descripción: la pérdida de equipos provoca directamente la carencia de un medio para prestar los servi­ cios, es decir una indisponibilidad. Se puede perder todo tipo de equipamiento, siendo la pérdida de equipos y soportes de infor­ mación los más habituales. En el caso de equipos que hospedan datos, además se puede sufrir una fuga de información. Ver: EBIOS: 22 - RECUPERACIÓN DE SOPORTES RECICLADOS O DESECHADOS

© Ministerio de Hacienda y Administraciones Públicas

página 38 (de 75)

Magerit 3.0

Amenazas

5.3.18. [E.28] Indisponibilidad del personal [E.28] Indisponibilidad del personal Tipos de activos: •

Dimensiones:

[P] personal interno

1. [D] disponibilidad

Descripción: ausencia accidental del puesto de trabajo: enfermedad, alteraciones del orden público, guerra bacteriológica, ... Ver: EBIOS: 42 - DAÑO A LA DISPONIBILIDAD DEL PERSONAL

© Ministerio de Hacienda y Administraciones Públicas

página 39 (de 75)

Magerit 3.0

Amenazas

5.4. [A] Ataques intencionados Fallos deliberados causados por las personas. La numeración no es consecutiva para coordinarla con los errores no intencionados, muchas ve­ ces de naturaleza similar a los ataques deliberados, difiriendo únicamente en el propósito del suje­ to. Origen: Humano (deliberado) Ver correlación de errores y amenazas.

5.4.1. [A.3] Manipulación de los registros de actividad (log) [A.4] Manipulación de los registros de actividad (log) Tipos de activos: •

Dimensiones:

[D.log] registros de actividad

1. [I] integridad (trazabilidad)

Descripción: Ver: EBIOS: no disponible

5.4.2. [A.4] Manipulación de la configuración [A.4] Manipulación de la configuración Tipos de activos: •

[D.log] registros de actividad

Dimensiones: 1. [I] integridad 2. [C] confidencialidad 3. [A] disponibilidad

Descripción: prácticamente todos los activos dependen de su configuración y ésta de la diligencia del ad­ ministrador: privilegios de acceso, flujos de actividades, registro de actividad, encaminamien­ to, etc. Ver: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 40 (de 75)

Magerit 3.0

Amenazas

5.4.3. [A.5] Suplantación de la identidad del usuario [A.5] Suplantación de la identidad del usuario Tipos de activos: • • • • •

Dimensiones: 1. [C] confidencialidad 2. [A] autenticidad 3. [I] integridad

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

Descripción: cuando un atacante consigue hacerse pasar por un usuario autorizado, disfruta de los privile­ gios de este para sus fines propios. Esta amenaza puede ser perpetrada por personal interno, por personas ajenas a la Organiza­ ción o por personal contratado temporalmente. Ver: EBIOS: 40 - USURPACIÓN DE DERECHO

5.4.4. [A.6] Abuso de privilegios de acceso [A.6] Abuso de privilegios de acceso Tipos de activos: • • • • • •

Dimensiones: 1. [C] confidencialidad 2. [I] integridad 3. [D] disponibilidad

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

Descripción: cada usuario disfruta de un nivel de privilegios para un determinado propósito; cuando un usuario abusa de su nivel de privilegios para realizar tareas que no son de su competencia, hay problemas. Ver: EBIOS: 39 - ABUSO DE DERECHO

5.4.5. [A.7] Uso no previsto [A.7] Uso no previsto Tipos de activos: • • • • • • •

[S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

Dimensiones: 1. 2. 3.

[D] disponibilidad [C] confidencialidad [I] integridad

Descripción: utilización de los recursos del sistema para fines no previstos, típicamente de interés personal: juegos, consultas personales en Internet, bases de datos personales, programas personales, almacenamiento de datos personales, etc. Ver: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 41 (de 75)

Magerit 3.0

Amenazas

5.4.6. [A.8] Difusión de software dañino [A.8] Difusión de software dañino Tipos de activos: •

[SW] aplicaciones (software)

Dimensiones: 1. 2. 3.

[D] disponibilidad [I] integridad [C] confidencialidad

Descripción: propagación intencionada de virus, espías (spyware), gusanos, troyanos, bombas lógicas, etc. Ver: EBIOS: no disponible

5.4.7. [A.9] [Re-]encaminamiento de mensajes [A.9] [Re-]encaminamiento de mensajes Tipos de activos: • • •

Dimensiones: 1. [C] confidencialidad

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

Descripción: envío de información a un destino incorrecto a través de un sistema o una red, que llevan la información a donde o por donde no es debido; puede tratarse de mensajes entre personas, entre procesos o entre unos y otros. Un atacante puede forzar un mensaje para circular a través de un nodo determinado de la red donde puede ser interceptado. Es particularmente destacable el caso de que el ataque de encaminamiento lleve a una entre­ ga fraudulenta, acabando la información en manos de quien no debe. Ver: EBIOS: no disponible

5.4.8. [A.10] Alteración de secuencia [A.10] Alteración de secuencia Tipos de activos: • • •

Dimensiones:

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

1. [I] integridad

Descripción: alteración del orden de los mensajes transmitidos. Con ánimo de que el nuevo orden altere el significado del conjunto de mensajes, perjudicando a la integridad de los datos afectados. Ver: EBIOS: 36 - ALTERACIÓN DE DATOS

© Ministerio de Hacienda y Administraciones Públicas

página 42 (de 75)

Magerit 3.0

Amenazas

5.4.9. [A.11] Acceso no autorizado [A.11] Acceso no autorizado Tipos de activos: • • • • • • • • •

Dim1nsiones:

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [C] confidencialidad 2. [I] integridad

Descripción: el atacante consigue acceder a los recursos del sistema sin tener autorización para ello, típi­ camente aprovechando un fallo del sistema de identificación y autorización. Ver: EBIOS: 33 - USO ILÍCITO DEL HARDWARE

5.4.10. [A.12] Análisis de tráfico [A.12] Análisis de tráfico Tipos de activos: •

Dimensiones:

[COM] redes de comunicaciones

1. [C] confidencialidad

Descripción: el atacante, sin necesidad de entrar a analizar el contenido de las comunicaciones, es capaz de extraer conclusiones a partir del análisis del origen, destino, volumen y frecuencia de los in­ tercambios. A veces se denomina “monitorización de tráfico”. Ver: EBIOS: no disponible

5.4.11. [A.13] Repudio [A.13] Repudio Tipos de activos: • •

Dimensiones:

[S] servicios [D.log] registros de actividad

1. [I] integridad (trazabilidad)

Descripción: negación a posteriori de actuaciones o compromisos adquiridos en el pasado. Repudio de origen: negación de ser el remitente u origen de un mensaje o comunicación. Repudio de recepción: negación de haber recibido un mensaje o comunicación. Repudio de entrega: negación de haber recibido un mensaje para su entrega a otro. Ver: EBIOS: 41 - NEGACIÓN DE ACCIONES

© Ministerio de Hacienda y Administraciones Públicas

página 43 (de 75)

Magerit 3.0

Amenazas

5.4.12. [A.14] Interceptación de información (escucha) [A.14] Interceptación de información (escucha) Tipos de activos: •

Dimensiones:

[COM] redes de comunicaciones

1. [C] confidencialidad

Descripción: el atacante llega a tener acceso a información que no le corresponde, sin que la información en sí misma se vea alterada. Ver: EBIOS: 19 - ESCUCHA PASIVA

5.4.13. [A.15] Modificación deliberada de la información [A.15] Modificación deliberada de la información Tipos de activos: • • • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios (acceso) [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones

1. [I] integridad

Descripción: alteración intencional de la información, con ánimo de obtener un beneficio o causar un perjui­ cio. Ver: EBIOS: no disponible

5.4.14. [A.18] Destrucción de información [A.18] Destrucción de información Tipos de activos: • • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios (acceso) [SW] aplicaciones (SW) [Media] soportes de información [L] instalaciones

1. [D] disponibilidad

Descripción: eliminación intencional de información, con ánimo de obtener un beneficio o causar un perjui­ cio. Ver: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 44 (de 75)

Magerit 3.0

Amenazas

5.4.15. [A.19] Divulgación de información [A.19] Revelación de información Tipos de activos: • • • • • • •

Dimensiones: 1. [C] confidencialidad

[D] datos / información [keys] claves criptográficas [S] servicios (acceso) [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones

Descripción: revelación de información. Ver: EBIOS: 23 – DIVULGACIÓN 27 – GEOLOCALIZACIÓN 34 - COPIA ILEGAL DE SOFTWARE

5.4.16. [A.22] Manipulación de programas [A.22] Manipulación de programas Tipos de activos: •

Dimensiones:

[SW] aplicaciones (software)

1. [C] confidencialidad 2. [I] integridad 3. [D] disponibilidad

Descripción: alteración intencionada del funcionamiento de los programas, persiguiendo un beneficio indi­ recto cuando una persona autorizada lo utiliza. Ver: EBIOS: 26 - ALTERACIÓN DE PROGRAMAS

5.4.17. [A.23] Manipulación de los equipos [A.22] Manipulación de los equipos Tipos de activos: • • •

Dimensiones:

[HW] equipos [Media] soportes de información [AUX] equipamiento auxiliar

1. [C] confidencialidad 2. [D] disponibilidad

Descripción: alteración intencionada del funcionamiento de los programas, persiguiendo un beneficio indi­ recto cuando una persona autorizada lo utiliza. Ver: EBIOS: 25 - SABOTAJE DEL HARDWARE

© Ministerio de Hacienda y Administraciones Públicas

página 45 (de 75)

Magerit 3.0

Amenazas

5.4.18. [A.24] Denegación de servicio [A.24] Denegación de servicio Tipos de activos: • • •

Dimensiones: 1. [D] disponibilidad

[S] servicios [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

Descripción: la carencia de recursos suficientes provoca la caída del sistema cuando la carga de trabajo es desmesurada. Ver: EBIOS: 30 - SATURACIÓN DEL SISTEMA INFORMÁTICO

5.4.19. [A.25] Robo [A.25] Robo Tipos de activos: • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

3. [D] disponibilidad 4. [C] confidencialidad

Descripción: la sustracción de equipamiento provoca directamente la carencia de un medio para prestar los servicios, es decir una indisponibilidad. El robo puede afectar a todo tipo de equipamiento, siendo el robo de equipos y el robo de so­ portes de información los más habituales. El robo puede realizarlo personal interno, personas ajenas a la Organización o personas con­ tratadas de forma temporal, lo que establece diferentes grados de facilidad para acceder al objeto sustraído y diferentes consecuencias. En el caso de equipos que hospedan datos, además se puede sufrir una fuga de información. Ver: EBIOS: 20 - ROBO DE SOPORTES O DOCUMENTOS 21 - ROBO DE HARDWARE

5.4.20. [A.26] Ataque destructivo [A.26] Ataque destructivo Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

Descripción: vandalismo, terrorismo, acción militar, ... Esta amenaza puede ser perpetrada por personal interno, por personas ajenas a la Organiza­ ción o por personas contratadas de forma temporal. Ver: EBIOS: 05 - DESTRUCCIÓN DE HARDWARE O DE SOPORTES

© Ministerio de Hacienda y Administraciones Públicas

página 46 (de 75)

Magerit 3.0

Amenazas

5.4.21. [A.27] Ocupación enemiga [A.27] Ocupación enemiga Tipos de activos: •

Dimensiones:

[L] instalaciones

1. [D] disponibilidad 2. [C] confidencialidad

Descripción: cuando los locales han sido invadidos y se carece de control sobre los propios medios de tra­ bajo. Ver: EBIOS: no disponible

5.4.22. [A.28] Indisponibilidad del personal [A.28] Indisponibilidad del personal Tipos de activos: •

Dimensiones:

[P] personal interno

1. [D] disponibilidad

Descripción: ausencia deliberada del puesto de trabajo: como huelgas, absentismo laboral, bajas no justifi­ cadas, bloqueo de los accesos, ... Ver: EBIOS: 42 - DAÑO A LA DISPONIBILIDAD DEL PERSONAL

5.4.23. [A.29] Extorsión [A.29] Extorsión Tipos de activos: •

Dimensiones:

[P] personal interno

1. [C] confidencialidad 2. [I] integridad 3. [D] disponibilidad

Descripción: presión que, mediante amenazas, se ejerce sobre alguien para obligarle a obrar en determi­ nado sentido. Ver: EBIOS: no disponible

5.4.24. [A.30] Ingeniería social (picaresca) [A.30] Ingeniería social (picaresca) Tipos de activos: •

Dimensiones:

[P] personal interno

1. [C] confidencialidad 2. [I] integridad 3. [D] disponibilidad

Descripción: abuso de la buena fe de las personas para que realicen actividades que interesan a un terce­ ro. Ver: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 47 (de 75)

Magerit 3.0

Amenazas

5.5. Correlación de errores y ataques Errores y amenazas constituyen frecuentemente las dos caras de la misma moneda: algo que le puede pasar a los activos sin animosidad o deliberadamente. Se pueden dar hasta tres combina­ ciones: •

amenazas que sólo pueden ser errores, nunca ataques deliberados

•

amenazas que nunca son errores: siempre son ataques deliberados

•

amenazas que pueden producirse tanto por error como deliberadamente

Para afrontar esta casuística, errores y amenazas se han numerado de tal manera que pueda es­ tablecerse este paralelismo. La siguiente tabla alinea errores con ataques mostrando cómo se co­ rrelacionan: número

error

ataque

1

Errores de los usuarios

2

Errores del administrador

3

Errores de monitorización (log)

Manipulación de los registros de actividad

4

Errores de configuración

Manipulación de la configuración

5

Suplantación de la identidad del usuario

6

Abuso de privilegios de acceso

7

Deficiencias en la organización

Uso no previsto

8

Difusión de software dañino

Difusión de software dañino

9

Errores de [re-]encaminamiento

[Re-]encaminamiento de mensajes

10

Errores de secuencia

Alteración de secuencia

11

Acceso no autorizado

12

Análisis de tráfico

13

Repudio

14

Escapes de información

Interceptación de información (escucha)

15

Alteración accidental de la información

Modificación deliberada de la información

18

Destrucción de información

Destrucción de información

19

Fugas de información

Revelación de información

20

Vulnerabilidades de los programas (soft­ ware)

21

Errores de mantenimiento / actualización de programas (software)

22

Manipulación de programas

23

Errores de mantenimiento / actualización Manipulación de los equipos de equipos (hardware)

24

Caída del sistema por agotamiento de Denegación de servicio recursos

25

Pérdida de equipos

Robo

26

Ataque destructivo

27

Ocupación enemiga

28

Indisponibilidad del personal

Indisponibilidad del personal

29

Extorsión

30

Ingeniería social (picaresca)

© Ministerio de Hacienda y Administraciones Públicas

página 48 (de 75)

Magerit 3.0

Amenazas

5.6. Nuevas amenazas: XML Los amenazas cabe esperar que evolucionen en el tiempo para adaptarse a la evolución tecnoló­ gica. Por ello se incluye a continuación una gramática de tipo XML que permita publicar periódi­ camente actualizaciones de las amenazas antes descritas.

5.6.1. Sintaxis BNF La notación se describe en el apéndice 1. { amenazas }* amenazas ::= { amenaza }* amenaza ::=

#name#

[ descripción ]

{ amenaza }*

descripción ::= #texto#

Atributo

Ejemplo

Descripción

under

under=”X”

X identifica una amenaza ya definida, indicando que las nuevas ame­ nazas son refinamientos de X.

code

code=”X”

X es un identificador único que permite determinar unívocamente a qué amenaza se refiere.

tho

tho=”H”

Origen (agente causante) de la amenaza. Puede ser N – Natural E – Entorno industrial H - Humano

thc

thc=”D”

Causa. Puede ser A – Accidental D - Deliberada

5.6.2. Esquema XSD version: magerit 3.0 (2011) date: 19.11.2011

© Ministerio de Hacienda y Administraciones Públicas

página 49 (de 75)

Magerit 3.0

Amenazas

































































5.7. Nivel de la amenaza: XML Para que una fuente de información pueda proporcionar datos de inteligencia sobre la probabi­ lidad de que una amenaza se materialice sobre un cierto tipo de activos.

5.7.1. Sintaxis BNF La notación se describe en el apéndice 1. { nivel_de_amenaza }* nivel_de_amenaza ::= [ descripción ] descripción ::= #texto#

© Ministerio de Hacienda y Administraciones Públicas

página 50 (de 75)

Magerit 3.0 Atributo

Amenazas Ejemplo

Descripción

class

class=”C”

C identifica por su código a un tipo ya conocido de activos.

threat

threat=”T”

T identifica por su código a una amenaza ya conocida.

level

level=”A”

Nivel de la amenaza. Puede ser VR – muy raro (very rare) U – improbable (unlikely) P – posible (possible) VH – probable (very high) AC – prácticamente segura (almost certain)

5.7.2. Esquema XSD version: magerit 3.0 (2011) date: 19.11.2011





































5.8. Referencias Existen numerosas fuentes que catalogan amenazas dentro del ámbito de las tecnologías de la información y las comunicaciones. •

ISO/IEC 27005 • EBIOS © Ministerio de Hacienda y Administraciones Públicas

página 51 (de 75)

Magerit 3.0

Amenazas

•

IT Baseline Protection Manual, Federal Office for Information Security (BSI), Germany. Oc­ tober 2003.

http://www.bsi.de/gshb/english/etc/index.htm

•

Managing Information Security Risks: The OCTAVE Approach, C.J. Alberts and A.J. Doro­ fee, Addison-Wesley Pub Co; 1st edition (July 9, 2002)

http://www.cert.org/octave/

© Ministerio de Hacienda y Administraciones Públicas

página 52 (de 75)

Magerit 3.0

Salvaguardas

6. Salvaguardas Las salvaguardas permiten hacer frente a las amenazas.

Las salvaguardas, especialmente las técnicas, varían con el avance tecnológico

•

porque aparecen tecnologías nuevas,

•

porque van desapareciendo tecnologías antiguas,

•

porque cambian los [tipos de] activos a considerar,

•

porque evolucionan las posibilidades de los atacantes o

•

porque evoluciona el catálogo de salvaguardas disponibles.

En consecuencia, este catálogo de salvaguardas no entra en la selección de paquetes o produc­ tos a instalar, limitándose a establecer un paraguas taxonómico para ordenar y clasificar las dife­ rentes concreciones materiales, tecnológicas, organizativas y procedimentales que sean de apli­ cación en cada momento..

6.1. Protecciones generales u horizontales H

Protecciones Generales

H.IA

Identificación y autenticación

H.AC

Control de acceso lógico

H.ST

Segregación de tareas

H.IR

Gestión de incidencias

H.tools

Herramientas de seguridad

H.tools.AV

Herramienta contra código dañino

H.tools.IDS

IDS/IPS: Herramienta de detección / prevención de intrusión

H.tools.CC

Herramienta de chequeo de configuración

H.tools.VA

Herramienta de análisis de vulnerabilidades

H.tools.TM

Herramienta de monitorización de tráfico

H.tools.DLP

DLP: Herramienta de monitorización de contenidos

H.tools.LA

Herramienta para análisis de logs

H.tools.HP

Honey net / honey pot

H.tools.SFV

Verificación de las funciones de seguridad

H.VM

Gestión de vulnerabilidades

H.AU

Registro y auditoría

© Ministerio de Hacienda y Administraciones Públicas

página 53 (de 75)

Magerit 3.0

Salvaguardas

6.2. Protección de los datos / información D

Protección de la Información

D.A

Copias de seguridad de los datos (backup)

D.I

Aseguramiento de la integridad

D.C

Cifrado de la información

D.DS

Uso de firmas electrónicas

D.TS

Uso de servicios de fechado electrónico (time stamping)

6.3. Protección de las claves criptográficas K

Gestión de claves criptográficas

K.IC

Gestión de claves de cifra de información

K.DS

Gestión de claves de firma de información

K.disk

Gestión de claves para contenedores criptográficos

K.comms

Gestión de claves de comunicaciones

K.509

Gestión de certificados

6.4. Protección de los servicios S

Protección de los Servicios

S.A

Aseguramiento de la disponibilidad

S.start

Aceptación y puesta en operación

S.SC

Se aplican perfiles de seguridad

S.op

Explotación

S.CM

Gestión de cambios (mejoras y sustituciones)

S.end

Terminación

S.www

Protección de servicios y aplicaciones web

S.email

Protección del correo electrónico

S.dir

Protección del directorio

S.dns

Protección del servidor de nombres de dominio (DNS)

S.TW

Teletrabajo

S.voip

Voz sobre IP

6.5. Protección de las aplicaciones (software) SW

Protección de las Aplicaciones Informáticas

SW.A

Copias de seguridad (backup)

SW.start

Puesta en producción

SW.SC

Se aplican perfiles de seguridad

SW.op

Explotación / Producción

SW.CM

Cambios (actualizaciones y mantenimiento)

SW.end

Terminación

© Ministerio de Hacienda y Administraciones Públicas

página 54 (de 75)

Magerit 3.0

Salvaguardas

6.6. Protección de los equipos (hardware) HW

Protección de los Equipos Informáticos

HW.start

Puesta en producción

HW.SC

Se aplican perfiles de seguridad

HW.A

Aseguramiento de la disponibilidad

HW.op

Operación

HW.CM

Cambios (actualizaciones y mantenimiento)

HW.end

Terminación

HW.PCD

Informática móvil

HW.print

Reproducción de documentos

HW.pabx

Protección de la centralita telefónica (PABX)

6.7. Protección de las comunicaciones COM

Protección de las Comunicaciones

COM.start

Entrada en servicio

COM.SC

Se aplican perfiles de seguridad

COM.A

Aseguramiento de la disponibilidad

COM.aut

Autenticación del canal

COM.I

Protección de la integridad de los datos intercambiados

COM.C

Protección criptográfica de la confidencialidad de los datos intercambiados

COM.op

Operación

COM.CM

Cambios (actualizaciones y mantenimiento)

COM.end

Terminación

COM.internet

Internet: uso de ? acceso a

COM.wifi

Seguridad Wireless (WiFi)

COM.mobile

Telefonía móvil

COM.DS

Segregación de las redes en dominios

6.8. Protección en los puntos de interconexión con otros sistemas IP

Puntos de interconexión: conexiones entre zonas de confianza

IP.SPP

Sistema de protección perimetral

IP.BS

Protección de los equipos de frontera

6.9. Protección de los soportes de información MP

Protección de los Soportes de Información

MP.A

Aseguramiento de la disponibilidad

MP.IC

Protección criptográfica del contenido

© Ministerio de Hacienda y Administraciones Públicas

página 55 (de 75)

Magerit 3.0

Salvaguardas

MP.clean

Limpieza de contenidos

MP.end

Destrucción de soportes

6.10. Protección de los elementos auxiliares AUX

Elementos Auxiliares

AUX.A

Aseguramiento de la disponibilidad

AUX.start

Instalación

AUX.power

Suministro eléctrico

AUX.AC

Climatización

AUX.wires

Protección del cableado

6.11. Seguridad física – Protección de las instalaciones L

Protección de las Instalaciones

L.design

Diseño

L.depth

Defensa en profundidad

L.AC

Control de los accesos físicos

L.A

Aseguramiento de la disponibilidad

L.end

Terminación

6.12. Salvaguardas relativas al personal Son aquellas que se refieren a las personas que tienen relación con el sistema de información. PS

Gestión del Personal

PS.AT

Formación y concienciación

PS.A

Aseguramiento de la disponibilidad

6.13. Salvaguardas de tipo organizativo Son aquellas que se refieren al buen gobierno de la seguridad. G

Organización

G.RM

Gestión de riesgos

G.plan

Planificación de la seguridad

G.exam

Inspecciones de seguridad

6.14. Continuidad de operaciones Prevención y reacción frente a desastres.

BC

Continuidad del negocio

BC.BIA

Análisis de impacto (BIA)

BC.DRP

Plan de Recuperación de Desastres (DRP)

© Ministerio de Hacienda y Administraciones Públicas

página 56 (de 75)

Magerit 3.0

Salvaguardas

6.15. Externalización Es cada vez más flexible la frontera entre los servicios de seguridad prestados internamente y los servicios contratados a terceras partes. En estos casos es fundamental cerrar los aspectos de re­ lación contractual: •

SLA: nivel de servicio, si la disponibilidad es un valor

•

NDA: compromiso de secreto, si la confidencialidad es un valor

•

Identificación y calificación del personal encargado

•

Procedimientos de escalado y resolución de incidencias

•

Procedimiento de terminación (duración en el tiempo de las responsabilidades asumidas)

•

Asunción de responsabilidades y penalizaciones por incumplimiento

E

Relaciones Externas

E.1

Acuerdos para intercambio de información y software

E.2

Acceso externo

E.3

Servicios proporcionados por otras organizaciones

E.4

Personal subcontratado

6.16. Adquisición y desarrollo NEW

Adquisición / desarrollo

NEW.S

Servicios: Adquisición o desarrollo

NEW.SW

Aplicaciones: Adquisición o desarrollo

NEW.HW

Equipos: Adquisición o desarrollo

NEW.COM

Comunicaciones: Adquisición o contratación

NEW.MP

Soportes de Información: Adquisición

NEW.C

Productos certificados o acreditados

6.17. Referencias BSI Federal Office for Information Security (BSI). “IT Baseline Protection Manual”, October 2003. Germany. http://www.bsi.de/gshb/english/etc/index.htm CC Comon Criteria. Ver [ISO 15408]. Guías CCN-STIC https://www.ccn-cert.cni.es/ ISO JTC 71/SC 27 Numerosas guías producidas por ISO concretan medidas de seguridad. Consulte el catálogo del comité 71 "TECNOLOGÍA DE LA INFORMACIÓN", subcomité SC 27 "TÉCNICAS DE SE­ GURIDAD".

© Ministerio de Hacienda y Administraciones Públicas

página 57 (de 75)

Magerit 3.0

Salvaguardas

ISO 15408 ISO/IEC 15408:2009, “Information technology — Security techniques — Evaluation criteria for IT security”. ISO 27002 ISO/IEC 27002:2005, “Information technology — Security techniques — Code of practice for in­ formation security management”. UNE-ISO/IEC 27002:2009, “Tecnología de la Información. Código de Buenas Prácticas de la Gestión de la Seguridad de la Información”. NIST 800-53 NIST, “Recommended Security Controls for Federal Information Systems”, National Institute of Standards and Technology, special publication SP 800-53 Rev.3, Aug. 2009. RD 3/2010 Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. RD 1720/2007 Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarro­ llo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter perso­ nal.

© Ministerio de Hacienda y Administraciones Públicas

página 58 (de 75)

Magerit 3.0

Notación XML

Apéndice 1. Notación XML Las descripciones de formatos XML se ajustan a la siguiente notación de tipo BNF 4: •

las etiquetas XML se muestran como tales

•

los atributos XML se explican en la sección “atributos”

•

{ ... }* denota que hay 0 o más

•

{ ... }+ denota que hay 1 o más

•

| denota que son alternativas

•

[...] denota que es opcional (0 o 1)

•

#texto# es contenido literal: un nombre o una descripción

•

lo demás es obligatorio

4 BNF: Backus-Naur Form. Es una forma de representar la gramática de un lenguaje. Una gramática BNF consiste en una serie de reglas de producción, donde el lado izquierdo se materializa en lo que se indica en el lado derecho. El lado derecho puede explicitar términos finales, o bien ser a su vez desarrollado mediante nuevas reglas de producción.

© Ministerio de Hacienda y Administraciones Públicas

página 59 (de 75)

Magerit 3.0

Fichas

Apéndice 2. Fichas Las siguientes secciones proporciona fichas para la captura de datos en un proyecto de análisis y gestión de riesgos. Reproduzca las fichas siguientes, una por activo, del tipo que corresponda.

A2.1. [info] Activos esenciales: información [info] Información código:

nombre:

descripción:

propietario: responsable:

tipo (marque todos los adjetivos que procedan) Ver Sección 2.1.

Valoración de la información, típicamente en las siguientes dimensiones de seguridad: [I] integridad [C] confidencialidad [A] autenticidad de los datos [T] trazabilidad de los datos, quién ha modificado qué

Valoración dimensión

valor

justificación

[I] [C] [A] [T] Las dependencias normalmente identifican servicios y personas que manejan esta información:

Dependencias de activos inferiores (hijos) activo:

grado:

© Ministerio de Hacienda y Administraciones Públicas

página 60 (de 75)

Magerit 3.0

Fichas

Dependencias de activos inferiores (hijos) ¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.2. [service] Activos esenciales: Servicio [service] Servicio código:

nombre:

descripción:

responsable:

tipo (marque todos los adjetivos que procedan) Ver Sección 2.1.

Valoración de los servicios que ofrece la Organización a otros, típicamente en las siguientes di­ mensiones: [D] disponibilidad [A] autenticidad de quién accede al servicio [T] trazabilidad de quién accede al servicio, cuándo y que hace

Valoración dimensión

valor

justificación

[D] [A] [T] Las dependencias normalmente identifican equipamiento desplegado para prestar este servicio:


aplicaciones (sw),




equipos (hw),




equipos de comunicaciones,




soportes de información (media), etc.




personas a cargo del servicio.

© Ministerio de Hacienda y Administraciones Públicas

página 61 (de 75)

Magerit 3.0

Fichas

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.3. [D] Datos / Información [D] Datos / Información código:

nombre:

descripción:

responsable: tipo (marque todos los adjetivos que procedan) Ver Sección 2.3.

Las dependencias normalmente identifican


equipos que los hospedan




líneas de comunicación por las que se transfieren




soportes de información




personas relacionadas: usuarios.

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

© Ministerio de Hacienda y Administraciones Públicas

página 62 (de 75)

Magerit 3.0

Fichas

A2.4. [K] Claves criptográficas [K] Claves criptográficas código:

nombre:

descripción:

responsable: tipo (marque todos los adjetivos que procedan) Ver Sección 2.4.

Las dependencias normalmente identifican


equipos que las hospedan




soportes de información




personas relacionadas: operadores, administradores y criptocustodios.

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.5. [S] Servicios [S] Servicios código:

nombre:

descripción:

© Ministerio de Hacienda y Administraciones Públicas

página 63 (de 75)

Magerit 3.0

Fichas [S] Servicios

responsable: tipo (marque todos los adjetivos que procedan) Ver Sección 2.5.

Las dependencias normalmente identifican


personas relacionadas: usuarios, operadores y administradores.

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.6. [SW] Aplicaciones (software) [SW] Aplicaciones (software) código:

nombre:

descripción:

responsable: tipo (marque todos los adjetivos que procedan) Ver Sección 2.6.

Las dependencias normalmente identifican


personas relacionadas con esta aplicación: operadores, administradores y desarrolladores.

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?:

© Ministerio de Hacienda y Administraciones Públicas

página 64 (de 75)

Magerit 3.0

Fichas

activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.7. [HW] Equipamiento informático (hardware) [HW] Equipamiento informático (hardware) código:

nombre:

descripción:

responsable: ubicación: número: tipo (marque todos los adjetivos que procedan) Ver Sección 2.7.

Las dependencias normalmente identifican


personas relacionadas con este equipo: operadores, administradores




instalaciones que lo acogen

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.8. [COM] Redes de comunicaciones [COM] Redes de comunicaciones código:

nombre:

© Ministerio de Hacienda y Administraciones Públicas

página 65 (de 75)

Magerit 3.0

Fichas [COM] Redes de comunicaciones

descripción:

responsable: ubicación: número: tipo (marque todos los adjetivos que procedan) Ver Sección 2.8.

Las dependencias normalmente identifican


personas relacionadas: operadores, administradores




instalaciones que lo acogen

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.9. [Media] Soportes de información [SI] Soportes de información código:

nombre:

descripción:

responsable: ubicación: número: tipo (marque todos los adjetivos que procedan)

© Ministerio de Hacienda y Administraciones Públicas

página 66 (de 75)

Magerit 3.0

Fichas [SI] Soportes de información

Ver Sección 2.9.

Las dependencias normalmente identifican


personas relacionadas: operadores, administradores




instalaciones que lo acogen

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.10. [AUX] Equipamiento auxiliar [AUX] Equipamiento auxiliar código:

nombre:

descripción:

responsable: ubicación: número: tipo (marque todos los adjetivos que procedan) Ver Sección 2.10.

Las dependencias normalmente identifican


personas relacionadas con este equipo: operadores, administradores

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: © Ministerio de Hacienda y Administraciones Públicas

página 67 (de 75)

Magerit 3.0

Fichas

activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.11. [L] Instalaciones [L] Instalaciones código:

nombre:

descripción:

responsable: ubicación: número: tipo (marque todos los adjetivos que procedan) Ver Sección 2.11.

Las dependencias normalmente identifican


personas relacionadas con esta instalación: guardias, encargados de mantenimiento

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.12. [P] Personal [P] Personal código:

nombre:

descripción:

© Ministerio de Hacienda y Administraciones Públicas

página 68 (de 75)

Magerit 3.0

Fichas [P] Personal

número: tipo (marque todos los adjetivos que procedan) Ver Sección 2.12.

No suelen identificarse dependencias.

© Ministerio de Hacienda y Administraciones Públicas

página 69 (de 75)

Magerit versión 2

Modelo de valor

Apéndice 3. Modelo de valor En este apéndice se describe un formato XML para el intercambio de modelos de activos entre herramientas. Este formato debe entenderse como de mínimos, en el sentido de que las herra­ mientas pueden incorporar información adicional a la prescrita. La información que se intercambia incluye •

identificación de los activos, con un código y un nombre descriptivo

•

identificación de bajo qué tipo(s) cabe clasificar el activo

•

identificación de las dependencias entre activos

•

valoración de los activos en diferentes dimensiones

La notación se describe en el apéndice 1.

A3.1. Formato XML modelo ::=



{ dato }*

{ activo }*

{ dependencia }*

{ valoración }*



dato ::=



activo ::=



#nombre#

{ tipo }+

{ dato }*



tipo ::=



dependencia ::=



valoración ::=



atributo

ejemplo

descripción

código

codigo=”X”

Acrónimo que identifica unívocamente un activo en un modelo; es decir, que no pueden haber códigos repeti­ dos.

clave

clave=”responsable”

Aparece como características adicionales que informan sobre el modelo o activo. Típicamente aparecen claves como autor, organización, documentación relevante, cla­ sificación, ubicación, fecha, versión, etc.

texto

texto=”JRP”

Texto asociado a la clave en una característica.

tipo

tipo=”T”

T es el código de alguno de los tipos definidos. Ver capítulo 2.

superior

superior=”X”

X es el código de algún activo del modelo.

© Ministerio de Hacienda y Administraciones Públicas

página 70 (de 75)

Magerit versión 2 atributo

Modelo de valor ejemplo

descripción

inferior

inferior=”X”

X es el código de algún activo del modelo.

grado

grado=”valor”

Un número real entre 0.0 y 1.0.

activo

activo=”X”

X es el código de algún activo del modelo.

dimension

dimension=”D”

D es el código de alguna de las dimensiones definidas. Ver capítulo 3.

valor

valor=”[clave]” valor=”valor”

Puede ser una clave simbólica o una cantidad real, posi­ tiva. Ver capítulo 4.

© Ministerio de Hacienda y Administraciones Públicas

página 71 (de 75)

Magerit versión 2

Informes

Apéndice 4. Informes A lo largo del proyecto de análisis y gestión de riesgos se han identificado una serie de informes para los cuales se propone un índice a continuación. Frecuentemente, se puede extraer de estos informes un informe ejecutivo que excluye los detalles.

A4.1. Modelo de valor Caracterización del valor que representan los activos para la Organización así como de las dependencias entre los diferentes activos. 1. Identificación del proyecto Código, descripción, propietario, organización. Versión, fecha. Biblioteca de referencia. 2. Activos 2.1. Árbol de activos (relaciones de dependencia) 2.2. Valoración de los activos (valor propio) Indicando la razón de la valoración atribuida a cada activo en cada dimensión. 3. Descripción detallada Para cada activo: • clasificación (ver capítulo 2) • activos superiores e inferiores • valoración: valor propio y acumulado en cada dimensión

A4.2. Mapa de riesgos Relación de las amenazas a que están expuestos los activos. 1. Identificación del proyecto Código, descripción, propietario, organización. Versión, fecha. Biblioteca de referencia. 2. Activos 2.1. Árbol de activos (relaciones de dependencia) 2.2. Valoración de los activos (valor propio) Indicando la razón de la valoración atribuida a cada activo en cada dimensión. 3. Amenazas por activo Para cada activo: • amenazas relevantes (ver capítulo 5) • degradación estimada en cada dimensión • frecuencia anual estimada 4. Activos por amenaza Para cada amenaza: • activos afectados • degradación estimada en cada dimensión • frecuencia anual estimada

© Ministerio de Hacienda y Administraciones Públicas

página 72 (de 75)

Magerit versión 2

Informes

A4.3. Evaluación de salvaguardas Evaluación de la eficacia de las salvaguardas existentes en relación al riesgo que afrontan. Se trabaja respecto de •

un catálogo de salvaguardas (ver capítulo 5)

1. Identificación del proyecto Código, descripción, propietario, organización. Versión, fecha. Biblioteca de referencia. 2. Salvaguardas (ver capítulo 5) Para cada salvaguarda, al nivel de detalle que se estime oportuno, indicación de su eficacia

frente a los riesgos a los que se enfrenta.

Si procede, muéstrese la evolución histórica y la planificación actual.

A4.4. Estado de riesgo Caracterización de los activos por su riesgo residual; es decir lo que puede pasar tomando en consideración las salvaguardas desplegadas. 1. Identificación del proyecto Código, descripción, propietario, organización. Versión, fecha. Biblioteca de referencia. 2. Activos Para cada activo: 1. Impacto acumulado 2. Riesgo acumulado

3. Impacto repercutido

4. Riesgo repercutido

Si procede, muéstrese la evolución histórica y el efecto de la planificación actual.

A4.5. Informe de insuficiencias Ausencia o debilidad de las salvaguardas que aparecen como oportunas para reducir el riesgo sobre el sistema. Se trabaja respecto de •

un catálogo de salvaguardas (ver capítulo 5)

•

un umbral de eficacia

1. Identificación del proyecto Código, descripción, propietario, organización. Versión, fecha. Biblioteca de referencia. 2. Salvaguardas Para cada salvaguarda, al nivel de detalle que se estime oportuno, cuya eficacia sea infe­ rior a un umbral determinado, indicación de su eficacia frente a los riesgos a los que se en­ frenta.

Si procede, muéstrese la evolución histórica y la planificación actual.

© Ministerio de Hacienda y Administraciones Públicas

página 73 (de 75)

Magerit versión 2

Informes

A4.6. Plan de seguridad Conjunto de programas de seguridad que permiten materializar las decisiones de gestión de riesgos. 1. Marco de referencia •

Política de seguridad de la organización

•

Relación de normas y procedimientos

2. Responsables y responsabilidades (a nivel de organización) 3. Programas de seguridad Por cada programa identificado:

•

objetivo genérico

•

prioridad o urgencia

•

ubicación temporal: ¿cuándo se llevará a cabo?

•

salvaguardas involucradas

•

unidad responsable de su ejecución

•

estimación de costes financieros

•

estimación de recursos

•

estimación de impacto para la organización

Cuando llega el momento para ser acometido, cada programa de seguridad debe detallar: •

Su objetivo genérico.

•

Las salvaguardas concretas a implantar o mejorar, detallando sus objetivos de calidad, efi­ cacia y eficiencia

•

La relación de escenarios de impacto y/o riesgo que afronta: activos afectados, tipos de acti­ vos, amenazas afrontadas, valoración de activos y amenazas y niveles de impacto y riesgo

•

La unidad responsable de su ejecución.

•

Una estimación de costes, tanto económicos como de esfuerzo de realización, teniendo en cuenta:

•

•

costes de adquisición (de productos), o de contratación (de servicios), o de desarrollo (de soluciones llave en mano), pudiendo ser necesario evaluar diferentes alternativas

•

costes de implantación inicial y mantenimiento en el tiempo

•

costes de formación, tanto de los operadores como de los usuarios, según convenga al caso

•

costes de explotación

•

impacto en la productividad de la Organización

Una relación de subtareas a afrontar, teniendo en cuenta •

cambios en la normativa y desarrollo de procedimientos

•

solución técnica: programas, equipos, comunicaciones y locales,

•

plan de despliegue

•

plan de formación

© Ministerio de Hacienda y Administraciones Públicas

página 74 (de 75)

Magerit versión 2

Informes

•

Una estimación del tiempo de ejecución desde su arranque hasta su puesta en operación.

•

Una estimación del estado de riesgo (impacto y riesgo residual a su compleción).

•

Un sistema de indicadores de eficacia y eficiencia que permitan conocer en cada momento la calidad del desempeño de la función de seguridad que se desea y su evolución temporal.

© Ministerio de Hacienda y Administraciones Públicas

página 75 (de 75)

MAGERIT – versión 3.0 Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información Libro III - Guía de Técnicas

TÍTULO: MAGERIT – versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro III - Guía de Técnicas Elaboración y coordinación de contenidos: Dirección General de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica Equipo responsable del proyecto: Director, Miguel Angel Amutio Gómez, Ministerio de Hacienda y Administraciones Públicas Javier Candau, Centro Criptológico Nacional, Ministerio de la Presidencia Consultor externo: José Antonio Mañas, Catedrático de la Universidad Politécnica de Madrid Características: Adobe Acrobat 5.0 Responsable edición digital: Subdirección General de Información, Documentación y Publicaciones (Jesús González Barroso) Madrid, octubre de 2012 Disponible esta publicación en el Portal de Administración Electrónica (PAe): http://administracionelectronica.gob.es/ Edita: © Ministerio de Hacienda y Administraciones Públicas Secretaría General Técnica Subdirección General de Información, Documentación y Publicaciones Centro de Publicaciones Colección: administración electrónica NIPO: 630-12-171-8

Índice

1. Introducción ...................................................................................................................4 2. Técnicas específicas .....................................................................................................5 2.1. Análisis mediante tablas.........................................................................................................6 2.1.1. Referencias.....................................................................................................................7 2.2. Análisis algorítmico. ...............................................................................................................8 2.2.1. Un modelo cualitativo .....................................................................................................8 2.2.2. Un modelo cuantitativo .................................................................................................12 2.2.3. Un modelo escalonado .................................................................................................16 2.2.4. Sobre la eficacia de las salvaguardas ..........................................................................20 2.3. Árboles de ataque ................................................................................................................22 2.3.1. Nodos con atributos......................................................................................................22 2.3.2. Riesgo residual .............................................................................................................23 2.3.3. Construcción del árbol ..................................................................................................23 2.3.4. Referencias...................................................................................................................24

3. Técnicas generales......................................................................................................25 3.4. Técnicas gráficas .................................................................................................................26 3.4.2. Por puntos y líneas .......................................................................................................26 3.4.3. Por barras .....................................................................................................................27 3.4.4. Gráficos de ‘radar’ ........................................................................................................28 3.4.5. Diagramas de Pareto....................................................................................................29 3.4.6. Diagramas de tarta .......................................................................................................33 3.6. Sesiones de trabajo..............................................................................................................34 3.6.1. Entrevistas ....................................................................................................................34 3.6.2. Reuniones.....................................................................................................................35 3.6.3. Presentaciones .............................................................................................................36 3.6.4. Referencias...................................................................................................................37 3.7. Valoración Delphi .................................................................................................................38 3.7.1. Resumen ejecutivo .......................................................................................................38 3.7.2. Aspectos sociológicos ..................................................................................................39 3.7.3. Análisis de las respuestas ............................................................................................40 3.7.4. Resumen ......................................................................................................................41 3.7.5. Referencias...................................................................................................................42

© Ministerio de Hacienda y Administraciones Públicas

página 3 (de 42)

Magerit 3.0

Introducción

1. Introducción Este documento la guía metodológica Magerit. Se presume el conocimiento y comprensión de los conceptos de análisis y gestión de riesgos, según se exponen en la guía metodológica. El objetivo de este documento es describir algunas técnicas utilizadas en análisis y gestión de riesgos. Se considera técnica a un conjunto de heurísticos y procedimientos que ayudan a alcanzar los objetivos propuestos. Para cada una de las técnicas referenciadas: •

se explica brevemente el objetivo que se persigue al utilizarlas,

•

se describen los elementos básicos asociados,

•

se exponen los principios fundamentales de elaboración,

•

se presenta una notación textual y/o gráfica y

•

y se citan las fuentes bibliográficas que, sin ser exhaustivas, se han estimado de interés para que el lector profundice en cada materia.

Todas las técnicas de este libro pueden utilizarse sin ayudas automatizadas; pero su aplicación repetitiva o compleja recomienda el empleo de herramientas tan amplia y frecuentemente como sea posible. Es importante resaltar que la notación que se propone en la aplicación de la técnica en ningún caso se considerará obligatoria. Cada organización podrá utilizar la notación que desee, la que suele utilizar o la que ofrecen sus herramientas de desarrollo, respetando las reglas y restricciones específicas de las distintas técnicas.

© Ministerio de Hacienda y Administraciones Públicas

página 4 (de 42)

Magerit 3.0

Técnicas específicas

2. Técnicas específicas En este capítulo nos centraremos en algunas técnicas muy específicas de los proyectos de análisis y gestión de riesgos, técnicas que no se utilizan en otros contextos de trabajo. Se han considerado de especial interés: 1. uso de tablas para la obtención sencilla de resultados 2. técnicas algorítmicas para la obtención de resultados elaborados 3. árboles de ataque para complementar los razonamientos de qué amenazas se ciernen sobre un sistema de información que se desarrollan en las siguientes secciones.

© Ministerio de Hacienda y Administraciones Públicas

página 5 (de 42)

Magerit 3.0

Análisis algorítmico

2.1. Análisis mediante tablas Dícese análisis de la distinción y separación de las partes de un todo hasta llegar a conocer sus principios o elementos. En el análisis de riesgos hay que trabajar con múltiples elementos que hay que combinar en un sistema para ordenarlo por importancia sin que los detalles, muchos, perjudiquen la visión de conjunto. La experiencia ha demostrado la utilidad de métodos simples de análisis llevados a cabo por medio de tablas que, sin ser muy precisas, sí aciertan en la identificación de la importancia relativa de los diferentes activos sometidos a amenazas. Sea la escala siguiente útil para calificar el valor de los activos, la magnitud del impacto y la magnitud del riesgo: • • • • •

MB: muy bajo B: bajo M: medio A: alto MA: muy alto

Estimación del impacto Se puede calcular el impacto en base a tablas sencillas de doble entrada:

degradación

impacto

valor

1%

10%

100%

MA

M

A

MA

A

B

M

A

M

MB

B

M

B

MB

MB

B

MB

MB

MB

MB

Aquellos activos que reciban una calificación de impacto muy alto (MA) deberían ser objeto de atención inmediata.

© Ministerio de Hacienda y Administraciones Públicas

página 6 (de 42)

Magerit 3.0

Análisis algorítmico

Estimación del riesgo Por otra parte se modelan impacto, probabilidad y riesgo por medio de escalas cualitativas: escalas impacto

probabilidad

riesgo

MA: muy alto

MA: prácticamente seguro MA: crítico

A: alto

A: probable

A: importante

M: medio

M: posible

M: apreciable

B: bajo

B: poco probable

B: bajo

MB: muy bajo MB: muy raro

MB: despreciable

Pudiendo combinarse impacto y frecuencia en una tabla para calcular el riesgo:

probabilidad

riesgo

impacto

MB

B

M

A

MA

MA

A

MA

MA

MA

MA

A

M

A

A

MA

MA

M

B

M

M

A

A

B

MB

B

B

M

M

MB

MB

MB

MB

B

B

2.1.1. Referencias •

ISO/IEC 27005:2011, Information technology — Security techniques — Information security risk management.

•

ISO 31010 ISO/IEC 31010:2009, Risk management — Risk assessment techniques. UNE-ISO/IEC 31010:2010, Gestión del riesgo. Técnicas de apreciación del riesgo. B.29 Matriz de consecuencia / probabilidad

© Ministerio de Hacienda y Administraciones Públicas

página 7 (de 42)

Magerit 3.0

Análisis algorítmico

2.2. Análisis algorítmico. Dícese análisis de la distinción y separación de las partes de un todo hasta llegar a conocer sus principios o elementos. En ciencias químicas, dícese análisis cualitativo del que tiene por objeto descubrir y aislar los elementos o ingredientes de un cuerpo compuesto. A diferencia del análisis cuantitativo que es el que se emplea para determinar la cantidad de cada elemento o ingrediente. En las siguientes secciones se presentan dos enfoques algorítmicos. Primero, un modelo cualitativo que busca una valoración relativa del riesgo que corren los activos (¿qué es lo más frente a qué es lo menos?). Segundo, un modelo cuantitativo que ambiciona responder a la pregunta de cuánto más y cuánto menos. A continuación se presenta un modelo escalonado, típico del análisis de impacto sobre la disponibilidad de los sistemas de información. Por último se incluye un modelo para estimar la eficacia de un paquete de salvaguardas.

2.2.1. Un modelo cualitativo En un análisis de riesgos cualitativo se busca saber qué es lo que hay, sin cuantificarlo con precisión más allá de relativizar los elementos del modelo. En esta sección se presenta un modelo de cálculo que trabaja sobre una escala discreta de valores. Valores. En un análisis de riesgos es necesario poder valorar, al menos relativamente, los elementos involucrados. En particular, los activos, el impacto de las amenazas y el riesgo que se corre. Para todo ello se usará una escala de niveles simbólicos: V = { 0, ..., v 0 , v 1 , ..., v i , ... } El valor 0 representa que no vale absolutamente nada. Esta serie de niveles satisface las siguientes propiedades: •

elemento mínimo: ∀ i, 0 < v i

•

orden total: ∀ i, v i < v i+1

•

existe un elemento singular, “v 0 ”, que se denomina “despreciable” 1 .

Informalmente, se dice que un activo tiene “i puntos” para indicar que su valoración es “v i “ 2 . El valor de los activos. Cada activo, en cada dimensión, recibe un valor de la escala V. Los activos reciben una valoración en cada una de las dimensiones de seguridad. Las dependencias entre activos. Sólo hay que preocuparse de si un activo A depende, significativamente, o no de otro activo B. Es decir, la dependencia entre activos es un valor booleano: sí o no. A→B La dependencia puede ser transitiva: (A → B) ∧ (B → C) A depende de B; B depende de C.

1 Este nivel despreciable establece una frontera, subjetiva, entre lo que es apreciable y debe preocupar, y lo que es despreciable y se puede obviar. Se despreciarán los valores por debajo de v 0 . 2 Si el lector lo desea, en este sistema de valoración, puede interpretar los puntos como órdenes de magnitud; por ejemplo, interpretando v x como 10x.

© Ministerio de Hacienda y Administraciones Públicas

página 8 (de 42)

Magerit 3.0

Análisis algorítmico

E incluso puede dibujar figuras de diamante:

A

(A → B 1 ) ∧ (A → B 2 ) ∧ (B 1 → C) ∧ (B 2 → C) A depende de B1 y B2; B1 y B2 dependen de C.

B1

B2

C

Interesa pues del cierre transitivo de las dependencias directas entre activos. A ⇒ C ⇔ ∃ B, ( A ⇒ B ) ∧ ( B → C ) A depende (indirectamente) de C sí y sólo si existe algún activo B tal que A depende directa o indirectamente de B y B depende directamente de C. En lo que sigue no se distingue entre dependencias directas o indirectas. El valor acumulado. Sea SUP(B) el conjunto superiores de B, es decir el conjunto de activos que dependen directa o indirectamente de B: SUP(B) = { A i , A i ⇒ B } Se define el valor acumulado sobre B como el mayor valor entre el propio y el de cualquiera de sus superiores: valor_acumulado(B) = max (valor(B), max i {valor(A i )}) La fórmula anterior dice que el valor acumulado sobre un activo es el mayor de los valores que soporta, bien propio, bien de alguno de sus superiores. La degradación [del valor] de un activo. Cuando un activo es víctima de una amenaza, una parte de su valor se pierde. Intuitivamente, se habla de un “porcentaje de degradación del activo”, de forma que se puede perder entre un 0% y un 100%. Se recoge “d” como un valor real entre 0,0 (degradación del 0%) y 1,0 (degradación del 100%). Impacto acumulado de una amenaza sobre un activo. Es la medida de lo que implica una amenaza; es decir, la pérdida de valor acumulado. El impacto se mide en las mismas unidades que el valor. Si un activo tiene un valor acumulado “v“ y se degrada un porcentaje “d”, el valor del impacto se calcula con alguna función que cumpla las siguientes condiciones de contorno impacto(0, 0%) = 0 impacto(v, 0%) = 0 impacto(v, 100%) = v ∀ d, v i < v j ⇒ impacto(v i , d) < impacto(v j , d) ∀ v, d i < d j ⇒ impacto(v, d i ) < impacto(v, d j ) Cuando el impacto queda a “v 0 ”, o menos, se dice que el impacto es despreciable.

© Ministerio de Hacienda y Administraciones Públicas

página 9 (de 42)

Magerit 3.0

Análisis algorítmico

Impacto repercutido de una amenaza sobre un activo. Si el activo A depende del activo B, las amenazas sobre B repercuten sobre A. Si B sufre una degradación “d”, eso mismo le ocurre a A, siendo el impacto sobre A la pérdida de su valor propio. Si A tiene un valor propio “v A “, y B tiene un valor propio v B , los impactos sobre A y B serán:

activo activoAA

activo activoBB

amenaza Z

impacto sobre A = impacto(v A , d) impacto sobre B = impacto(v B , d) Cuando el impacto queda reducido a “v 0 ”, se dice que el impacto es despreciable. Probabilidad de una amenaza. Para caracterizar la probabilidad de las amenazas se usará una escala de valores simbólicos: P = { 0, ..., p 0 , p 1 , ..., p i , … } El valor 0 refleja el suceso imposible. El valor p 0 refleja una probabilidad despreciable. Es decir, una serie de niveles de probabilidad, que son los elementos o átomos de análisis. Esta serie de niveles satisface las siguientes propiedades: •

orden total: ∀ j, p j < p j+1

•

existe un elemento singular, “f 0 ”, que se denomina “probabilidad despreciable”

Riesgo. El riesgo se mide por medio de la escala de valores, que es distinta de la escala de valores. R = { 0, ..., r 0 , r 1 , ..., r i , … } El valor 0 refleja el riesgo inexistente. El riesgo es una función del impacto y la probabilidad: riesgo = ℜ(impacto, probabilidad) función que hay que definir con los siguientes requisitos: •

ℜ(0, p) = 0

•

ℜ(v, 0) = 0

•

crece con el valor: ∀ f, v i < v j ⇒ ℜ(v i , p) < ℜ(v j , p)

•

crece con la probabilidad: ∀ v, p i < p j ⇒ ℜ(v, p i ) < ℜ(v , p j )

El riesgo puede tomar el valor “r 0 ”, e incluso valores inferiores, en cuyo caso se entiende que el riesgo es “despreciable”. Habitualmente se emplea alguna función que de más peso al impacto que a la probabilidad. Ver “análisis tabular”. Riesgo acumulado. En el cálculo del riesgo acumulado, se usará el impacto acumulado sobre el activo. Riesgo repercutido. En el cálculo del riesgo repercutido, se usará el impacto repercutido sobre el activo.

© Ministerio de Hacienda y Administraciones Públicas

página 10 (de 42)

Magerit 3.0

Análisis algorítmico

Paquete de salvaguardas. Frente a una amenaza se desplegará una serie de salvaguardas, un paquete de salvaguardas, cuya eficacia, “e”, se calcula según se indica más adelante. Baste adelantar que la eficacia es un valor real entre 0,0 (no protege nada) y 1,0 (salvaguarda plenamente eficaz), valor que se puede descomponer en una eficacia frente al impacto, “ei”, y una eficacia frente a la probabilidad “ep”. Degradación residual. Si el activo, sin protección, podía sufrir una degradación “d”, gracias a las salvaguardas la degradación se ve reducida a un valor residual “dr”: dr(0, ei) = 0 dr(d, 0) = d dr(d, 1) = 0 El impacto residual. El impacto residual se calcula como el impacto, pero utilizando la degradación residual: impacto_residual = impacto(v, dr) Un paquete de salvaguardas perfectamente eficaz reduce el impacto a un valor residual “v 0 ”, es decir, al nivel de despreciable. Si las salvaguardas son insuficientes, el impacto seguirá siendo apreciable. El impacto acumulado residual se calcula sobre el valor acumulado. El impacto residual repercutido se calcula sobre el valor propio. La probabilidad residual. De forma similar al impacto, la probabilidad de la amenaza sobre el activo se ve reducida a un valor residual. Si la probabilidad era “p”, ahora queda: pr(0, ep) = 0 pr(p, 0) = p pr(p, 1) = 0 p

Siendo “e ” la eficacia de las salvaguardas mitigando la probabilidad de ocurrencia de la amenaza. “ef” es un valor entre 0,0 (0% de eficacia; o sea, inútil) y 1,0 (100% de eficacia; o sea, perfecta). Riesgo residual. Es el riesgo calculado a partir del impacto y frecuencia residuales: riesgo_residual = ℜ(impacto_residual, frecuencia_residual) El riesgo residual acumulado se calcula sobre el impacto residual acumulado. El riesgo residual repercutido se calcula sobre el impacto residual repercutido. Resumen En este modelo, denominado cualitativo, se han posicionado los activos en una escala de valor relativo, definiendo arbitrariamente un valor “v 0 ” como frontera entre los valores que preocupan y los que son despreciables. Sobre esta escala de valor se ha medido tanto el valor del activo, propio o acumulado, como el impacto de una amenaza cuando ocurra y el riesgo al que está expuesto. Mientras el impacto mide el valor de la desgracia potencial, el riesgo pondera ese impacto con la frecuencia estimada de ocurrencia de la amenaza. El impacto es la medida del coste si ocurriera mientras que el riesgo mide la exposición en un determinado periodo de tiempo. © Ministerio de Hacienda y Administraciones Públicas

página 11 (de 42)

Magerit 3.0

Análisis algorítmico

Las estimaciones de impacto y riesgo residual incorporan la eficacia de las salvaguardas para enfrentarse a la amenaza, bien limitando el impacto, “ei”, bien reduciendo la probabilidad, “ep”. El modelo pues combina los siguientes parámetros de análisis: •

calibración del valor del activo por medio de una escala discreta

•

calibración de la degradación que supone una amenaza como un porcentaje

•

calibración de la probabilidad de ocurrencia de la amenaza por medio de una escala discreta

•

vertebración de un paquete de salvaguardas

•

calibración de la eficacia de las salvaguardas por medio de un porcentaje

Parámetros todos ellos que permiten moverse arriba y abajo por las escalas de valores.

2.2.2. Un modelo cuantitativo En un análisis de riesgos cuantitativo se busca saber qué y cuánto hay, cuantificando todos los aspectos posibles. El modelo que sigue no trabaja sobre una escala discreta de valores, sino con números reales (en el sentido matemático) positivos. El valor de los activos. El valor de un activo en una cierta dimensión es un valor real superior a cero. Se determina que un cierto valor, “v 0 “, representa la frontera entre los valores que son despreciables y los que son relevantes. Las dependencias entre activos. Interesa tanto de saber si un activo A depende o no de otro activo B, como de saber en qué grado. Se aplican los conceptos de dependencia directa o indirecta expuestos en el modelo cualitativo; pero ahora se calificará la dependencia por medio de un coeficiente entre 0,0 (activos independientes) y 1,0 (activos con dependencia absoluta). A este coeficiente se le denomina grado de dependencia. Como la dependencia puede ser directa o indirecta, se calculará del cierre transitivo de las dependencias directas entre activos. A ⇒ C ⇔ ∃ B, ( A ⇒ B ) ∧ ( B → C ) A depende (indirectamente) de C sí y sólo si existe algún activo B tal que A depende directa o indirectamente de B y B depende directamente de C. Calculando el grado de dependencia como: grado(A ⇒ C) = Σ i { grado(A ⇒ B i ) × grado(B i → C) } Donde las sumas se realizan de acuerdo con esta fórmula: a + b = 1 − (1 − a) × (1 − b) 3

3 Esta manera de sumar satisface las propiedades conmutativa, asociativa y existencia de un elemento neutro, amén de acotar el resultado al rango [0..1] si los sumandos están dentro de dicho rango. La elección de esta curiosa fórmula, tomada del cálculo de probabilidades de Bayes, deriva de la necesidad de reflejar el hecho de que si un activo depende de otro por varias vías (estructuras de diamante), la dependencia total no puede superar el 100%.

© Ministerio de Hacienda y Administraciones Públicas

página 12 (de 42)

Magerit 3.0

Análisis algorítmico

Ejemplos.

En lo que sigue no se distingue entre dependencias directas o indirectas. El valor acumulado. Sea SUP(B) el conjunto de superiores de B, es decir el conjunto de activos que dependen directa o indirectamente de B: SUP(B) = { A i , A i ⇒ B } Se define el valor acumulado sobre B como la suma (tradicional) de valores de los activos superiores, ponderados por el grado de dependencia: valor_acumulado(B) = valor(B) +Σ i { valor(A i ) × grado(A i ⇒ B) } La degradación [del valor] de un activo. Cuando un activo es víctima de una amenaza, una parte de su valor se pierde. Intuitivamente, se habla de un “porcentaje de degradación del activo”, de forma que se puede perder entre un 0% y un 100%. Se recogerá “d” como un valor real entre 0,0 (degradación del 0%) y 1,0 (degradación del 100%). Impacto acumulado de una amenaza sobre un activo. Es la pérdida de valor acumulado. Si un activo tiene un valor acumulado ”v” y sufre una degradación ”d”, el impacto es impacto = i = v × d Ejemplo. Si un activo está valorado en 1.000.000 y sufre una degradación del 90%, el impacto acumulado es de cuantía 900.000. Cuando el impacto queda reducido a “v 0 ”, o menos, se dice que el impacto es despreciable. Impacto repercutido de una amenaza sobre un activo. Si el activo A depende del activo B, las amenazas sobre B repercuten sobre A. Si B sufre una degradación ”d”, A pierde en la proporción en que dependa de B. Si el activo A tiene un valor propio “v”, el impacto es impacto = v × d × grado(A ⇒ B)

© Ministerio de Hacienda y Administraciones Públicas

página 13 (de 42)

Magerit 3.0

Análisis algorítmico

Ejemplo. Sea un activo A valorado en 1.000.000, que depende de otro activo B (cuyo valor no interesa aquí) en un 30%. Si B es víctima de una amenaza que lo degrada un 90%, A sufre un impacto repercutido de cuantía 1.000.000 x 90% x 30% = 270.000 Cuando el impacto queda reducido a “v 0 ”, o menos, se dice que el impacto es despreciable. Probabilidad de una amenaza. Para medir la probabilidad utilizaremos la frecuencia esperada de ocurrencia (ARO – Annual Rate of Occurrence) .La frecuencia de una amenaza es un valor real superior a cero. Se determina un valor “f 0 “ como frecuencia “despreciable”, por debajo de la cual la amenaza no merece ser tomada en consideración. Riesgo. El riesgo se mide en las misma unidades que el valor. El riesgo se calcula como riesgo = impacto × frecuencia Es un valor real, mayor que cero. Ejemplo. Sea un activo valorado en 1.000.000, que es víctima de una amenaza que lo degrada un 90%. El impacto es de cuantía 1.000.000 x 90% = 900.000 Si el activo está expuesto a la amenaza con una frecuencia estimada de 0,1, el riesgo estimado es de cuantía 900.000 x 0,1 = 90.000 Si los valores son euros y la frecuencia mide tasa anual (o sea, si 0,1 significa una vez cada 10 años), entonces la pérdida posible de valor es de 900.000 euros, mientras que la pérdida anual prevista es de 90.000 euros. Riesgo acumulado. En el cálculo del riesgo acumulado, se usará el impacto acumulado sobre el activo; es decir, la pérdida de valor acumulado por amenazas sobre el mismo. Riesgo repercutido. En el cálculo del riesgo repercutido, se usará el impacto repercutido sobre el activo; es decir, la pérdida de valor propio por amenazas en activos inferiores. Paquete de salvaguardas. Frente a una amenaza se despliega una serie de salvaguardas, un paquete de salvaguardas, cuya eficacia, “e”, se calcula según se indica más adelante. Baste adelantar que la eficacia es un valor real entre 0,0 (no protege) y 1,0 (salvaguarda plenamente eficaz), valor que se puede descomponer en una eficacia frente al impacto, “ei”, y una eficacia frente a la frecuencia “ef”, de forma que (1 − ei) × (1 − ef) = 1 − e 4 4 La fórmula elegida disfruta de las siguientes propiedades. Si ei= 0% y ef= 0%, e= 0%. Si ei= 0%, e= ef. Si ef= 0%, e= ei. Si ei o ef= 100%, e= 100%. El resultado es pues creciente con los componentes ei y ef, estando al tiempo acotado al rango [0%..100%].

© Ministerio de Hacienda y Administraciones Públicas

página 14 (de 42)

Magerit 3.0

Análisis algorítmico

Degradación residual. Es la parte de la degradación que no consigue contrarrestar la eficacia del paquete de salvaguardas aplicado. El impacto residual. Un sistema de salvaguardas absolutamente ineficaz (ei = 0 ) deja el impacto donde estaba, mientras que un sistema de salvaguardas plenamente eficaz (ei = 1) reduce el impacto a 0. Ejemplo Sea un activo valorado en 1.000.000, que es víctima de una amenaza que lo degrada un 90%. El impacto es de cuantía 1.000.000 x 90% = 900.000 Si las salvaguardas tienen un 90% de eficacia sobre el impacto, el impacto residual es impacto residual = 900.000 * (1 – 0.9) = 90.000 El impacto acumulado se realiza con los datos de impacto acumulado sobre un activo y las salvaguardas adecuadas para las amenazas sobre dicho activo. El impacto repercutido se realiza con los datos de impacto repercutido sobre el activo superior y las salvaguardas adecuadas para las amenazas del activo inferior. La frecuencia residual. Un sistema de salvaguardas absolutamente ineficaz (ef = 0 ) deja la frecuencia donde estaba, mientras que un sistema de salvaguardas plenamente eficaz (ef = 1) reduce la frecuencia a 0. Al igual que para calcular el impacto residual, se suele emplear alguna función de tipo Pareto. El riesgo residual. Puede derivarse indirectamente como riesgo_residual = impacto_residual x frecuencia residual

Ejemplo Sea un activo valorado en 1.000.000, que es víctima de una amenaza que lo degrada un 90%. El impacto es de cuantía impacto = 1.000.000 x 90% = 900.000 Si la frecuencia anual estimada es de 0,1, el riesgo es de cuantía riesgo = 900.000 x 0,1 = 90.000 = pérdida anual estimada Si las salvaguardas tienen un 90% de eficacia sobre el impacto, el impacto residual es impacto residual = 900.000 x (1 – 90%) = 90.000 Si las salvaguardas tienen un 50% de eficacia sobre la frecuencia, la eficacia combinada de las salvaguardas es frecuencia residual = 0,1 x (1 – 50%) = 0,05 y el riesgo residual es riesgo residual = 90.000 * 0,05 = 4.500 (pérdida anual estimada) Si las cantidades son euros y las frecuencias anuales, la pérdida posible es de 90.000 euros y la pérdida anual se estima en 4.500 euros. © Ministerio de Hacienda y Administraciones Públicas

página 15 (de 42)

Magerit 3.0

Análisis algorítmico

Resumen En este modelo, denominado cuantitativo, se trabaja con valores que son números reales, siempre superiores a cero. Se modela el grado de dependencia entre activos como un continuo entre 0,0 (activos independientes) y 1,0 (activos absolutamente dependientes; lo que ocurre sobre el inferior repercute contundentemente sobre el superior). Se mide tanto el valor del activo, propio o acumulado, como el impacto de una amenaza cuando ocurra y el riesgo que supone. Mientras el impacto mide el valor de la desgracia potencial, el riesgo pondera ese impacto con la frecuencia estimada de ocurrencia de la amenaza. El impacto mide el coste si ocurriera mientras que el riesgo es la medida de la exposición en un periodo de tiempo. Si la valoración del activo es económica (coste monetario que significaría su pérdida total y absoluta), el impacto calculado es el coste inducido por la amenaza y el riesgo calculado es la cantidad que hay que prever como pérdidas anuales. El modelo cuantitativo permite pues comparar el gasto en salvaguardas con la disminución de pérdidas. Las estimaciones de impacto y riesgo residual incorporan la eficacia de las salvaguardas para enfrentarse a la amenaza. Si la valoración del activo es económica, el modelo cuantitativo permite comparar el gasto en salvaguardas con la disminución de pérdidas. El modelo pues combina los siguientes parámetros de análisis: •

calibración del valor del activo por medio de una cantidad numérica

•

calibración de la dependencia entre activos por medio de un porcentaje

•

calibración de la degradación que supone una amenaza por medio de un porcentaje

•

calibración de la frecuencia de ocurrencia de la amenaza por medio de una frecuencia

•

vertebración de un paquete de salvaguardas

•

calibración de la eficacia de las salvaguardas por medio de un porcentaje

Parámetros todos ellos que permiten moverse arriba y abajo por la escala de valores.

2.2.3. Un modelo escalonado Ciertas dimensiones de degradación de un activo se modelan más adecuadamente como escalones de valor. El caso típico es la interrupción del servicio, que responde a esquemas como el siguiente

© Ministerio de Hacienda y Administraciones Públicas

página 16 (de 42)

Magerit 3.0

Análisis algorítmico

coste de [la interrupción de la] disponibilidad 10 8 coste

6 4 2

S1 total

duración de la parada

1a

6m

2m

1m

2s

1s

2d

1d

6h

2h

1h

30m

15m

0

donde se observa una serie de escalones de interrupción que terminan con la destrucción total o permanente del activo. En los párrafos siguientes se indica como analizar este tipo de dimensiones, bien sea de forma cualitativa (escala discreta de niveles de valor) o cuantitativa (valor continuo). Los escalones. Se determina una serie, ordenada, de escalones de valoración: E = { e 1 , e 2 , ..., e n }, donde e 1 < e 2 < ... < e n Cada escalón refleja un tiempo de parada (ver gráfica ilustrativa anterior). El valor de los activos. El activo recibe un valor para cada uno de los escalones v[e i ] valor que puede ser cualitativo o cuantitativo, según el tipo de análisis de interés; pero siempre con la condición de que la serie sea monótona creciente: v[e 1 ] ≤ v[e 2 ] ≤ … ≤ v[e n ] Las dependencias entre activos. Se usará el tratamiento cualitativo (binario: sí o no) o el cuantitativo (grado) según corresponda. El valor acumulado. Se calculará independientemente (en paralelo) para cada escalón. Es decir, para cada activo se estima un valor propio y un valor acumulado en cada escalón. Ejemplo. Una unidad administrativa proporciona un servicio de reclamaciones que, tradicionalmente, se ha prestado de forma escrita: el afectado reclama por carta y se le responde en el plazo máximo de 1 semana. Actualmente ha introducido una ventanilla electrónica alternativa en la que se ha considerado excelente una respuesta en menos de 1 hora (en horario de atención al público). A partir de una hora, la imagen ofrecida a los ciudadanos empieza a resentirse. Si el servicio se demora más de un día, se considera inútil, aunque de una gravedad relativa pues siempre queda la opción de la reclamación por escrito. © Ministerio de Hacienda y Administraciones Públicas

página 17 (de 42)

Magerit 3.0

Análisis algorítmico

Ambos servicios dependen de un equipamiento informático que hereda las valoraciones de ambos servicios:

activo

1h

1d

1s

escrito

[0]

[0]

[8]

web

[3]

[5]

[5]

servidor

[3]

[5]

[8]

acumulado

Degradación [del valor] de un activo. Se indicará como el escalón “e i “ al que conduce la materialización de la amenaza. Así, si la consecuencia de una amenaza Z es una parada de 2 horas, se tomará el escalón correspondiente, cuyo valor económico se valoró anteriormente. El impacto de una amenaza sobre un activo. Es el valor correspondiente al escalón de degradación, “v[e i ]”. El impacto acumulado empleará en valor acumulado sobre el activo que es víctima de la amenaza. El impacto repercutido empleará el valor propio del activo superior en el escalón de degradación del impacto inferior que es víctima de la amenaza. Si el análisis es cuantitativo, se multiplica el valor propio por el grado de dependencia.

Ejemplo. En el ejemplo anterior, un virus informático provoca una detención de unas 48 horas. El impacto en el servidor es [5], lo mismo que en el servicio web. El impacto repercutido en el servicio escrito es [0]. La frecuencia de una amenaza. Se empleará el modelo cualitativo o cuantitativo, según corresponda. El riesgo que supone una amenaza para un activo. Se empleará el modelo cualitativo o cuantitativo, según corresponda. La eficacia de una salvaguarda frente al impacto. Una salvaguarda frente a la interrupción del servicio se caracteriza por un tiempo de reacción: lo que tarde en reponer el servicio. A fin de calificar la eficacia de la salvaguarda, se toma el escalón correspondiente a dicho tiempo de “respuesta garantizada” 5 . Ejemplo. En el caso anterior, se puede desplegar un sistema antivirus que permite reactivar el servicio en 6 horas. Se dice que su eficacia está en el escalón de las 6 horas.

5 El razonamiento es como sigue. Si una parada superior a x1 horas supone un perjuicio v1, y una parada superior a x2 horas, un perjuicio v2; entonces, una parada de x horas, siendo x1 …≤ x < x2, supone un perjuicio v1, dado que no ha llegado al nivel x2.

© Ministerio de Hacienda y Administraciones Públicas

página 18 (de 42)

Magerit 3.0

Análisis algorítmico

Este escalón de eficacia puede ser e 0 , si la salvaguarda es tan contundente que no deja lugar ni al primer escalón valorado, e 1 . Este escalón de eficacia es el mismo que la degradación cuando la salvaguarda es incapaz de reducir el impacto 6 . Este escalón de eficacia nunca puede ser superior al escalón de degradación, pues una salvaguarda no puede empeorar la situación de un activo frente a una amenaza. Además del escalón de eficacia, las salvaguardas que se consideran aplicables al caso constituyen un paquete que se puede caracterizar por su eficacia reduciendo el impacto, ei, y su eficacia reduciendo la frecuencia, ef. El cálculo de estos coeficientes se describe más adelante. Lo que sí hay que indicar es cómo calcular el escalón de efectividad de un paquete de salvaguardas: escalón(ps)=

escalón(s)

si s es singular

max k { escalón(ps k ) }

si ps= todas (ps k )

min k { escalón(ps k ) }

si ps= algunas (ps k )

min k { escalón(ps k ) }

si ps= una (ps k )

Donde el valor especial “na” 7 se comporta como elemento neutro en las operaciones. De forma que, de un conjunto de salvaguardas alternativas se requiere al menos una que sea efectiva. Y que, de un conjunto de salvaguardas concurrentes, la eficacia la marca la peor de ellas. La degradación residual. Si el activo, sin protección, se posicionada en el escalón “e d “ de degradación, gracias a las salvaguardas se colocará en el escalón propuesto como escalón de eficacia, “e s “; pero modulado por la eficacia “ei” frente al impacto, resultado en un escalón residual “e r “: r = ⎣d − ((d − s) × ei)⎦

8

Donde el valor especial “na” se valora como 0. El impacto residual. Es el valor correspondiente al escalón residual: impacto_residual = valor[e r ]

Ejemplo. En el caso anterior, si se despliega un sistema antivirus que permite reactivar el servicio en 6 horas, el impacto residual en servidor y servicio web quedan en [3]. Si se desplegara un sistema antivirus que garantizase la reposición del servicio en 30 minutos, el impacto residual sería [0]. La frecuencia residual. Se empleará el modelo cualitativo o cuantitativo, según corresponda.

6 Un centro de respaldo que empieza a funcionar en 48 horas es inútil frente a amenazas que detienen el servicio durante 6 horas. 7 na: no aplica. 8 La notación ⎣v⎦ indica el entero que resulta de un redondeo por defecto.

© Ministerio de Hacienda y Administraciones Públicas

página 19 (de 42)

Magerit 3.0

Análisis algorítmico

El riesgo residual. En base al impacto residual y la frecuencia residual, se empleará el modelo cualitativo o cuantitativo, según corresponda.

2.2.4. Sobre la eficacia de las salvaguardas Todos los modelos requieren una evaluación de la eficacia de las salvaguardas que se despliegan para proteger a un activo de una amenaza. Se describe a continuación un modelo común para evaluar la eficacia de un conjunto de salvaguardas aplicadas sobre un activo. Paquete de salvaguardas. Frente a una amenaza se despliega un paquete de salvaguardas que no es sino un conjunto de salvaguardas singulares acumuladas sobre un activo. Las diferentes salvaguardas se pueden acumular de forma concurrente (todas son necesarias para surtir efecto), de forma excluyente (sólo tiene efecto una de un conjunto) o de forma aditiva (cuantas más, mejor). ps::= | | |

salvaguarda todas(ps 0 , ps 1 , ...) algunas (ps 0 , ps 1 , ...) una (ps 0 , ps 1 , ...)

La eficacia de una salvaguarda. Cada salvaguarda se valora según su eficacia reduciendo el riesgo del activo que protege. La eficacia de un paquete de salvaguardas es un número real entre 0,0 y 1,0: e

razonamiento

e=1

si una salvaguarda es idónea (100% eficaz)

0 < e < 1 si una salvaguarda es insuficiente e=0

si una salvaguarda no sirve para nada

e = na

i una salvaguarda no tiene sentido en este contexto

La eficacia de la salvaguarda depende tanto de su capacidad natural para proteger el activo como de la calidad de su despliegue. El valor de la eficacia recoge ambos aspectos en un único parámetro. La eficacia de un paquete de salvaguardas. e(ps)= e(s) media k { e(ps k ) }

si s es singular 9

si ps= todas (ps k )

min { 1,0, Σ k e(ps k )

si ps= algunas (ps k )

max k { e(ps k ) }

si ps= una (ps k )

Donde el valor especial “na” se comporta como elemento neutro en las operaciones de cálculo del máximo, producto o suma. De forma que, de un conjunto de salvaguardas concurrentes, la eficacia es la media de ellas; de un conjunto de salvaguardas aditivas, la eficacia de las salvaguardas se acumula, con un límite del 100%; y de un conjunto de salvaguardas alternativas, la eficacia la marca la mejor.

9 El valor medio se calcula de la forma habitual: se suman las eficacias diferentes de NA y se divide por el número de sumandos.

© Ministerio de Hacienda y Administraciones Públicas

página 20 (de 42)

Magerit 3.0

Análisis algorítmico

Eficacia ponderada de un paquete de salvaguardas Como eficacia de un paquete de salvaguardas se ha tomado el valor medio de las eficacias de los componentes. Este cálculo puede modularse si se tiene en cuenta que no todas las salvaguardas son de la misma naturaleza, introduciendo una ponderación “p”: e(ps) = Σ k e(ps k ) × p k

/ Σk p

k

El caso particular de que todas las salvaguardas sean igual de importantes, se consigue tomando “p = 1”. La eficacia frente al impacto y la frecuencia de una amenaza. El riesgo combina impacto y frecuencia. Una salvaguarda puede reducir el impacto, o la frecuencia, o ambas facetas. Depende de la naturaleza de la salvaguarda el que actúe sobre el impacto o sobre la frecuencia. Así, en los párrafos anteriores, se puede diferenciar entre la eficacia reduciendo el impacto, “ei”, y la eficacia reduciendo la frecuencia “ef”, Ambas eficacias se estiman con el mismo criterio: satisfacción de su cometido. Por último se puede calcular la eficacia reduciendo el riesgo, “e”, como (1 − ei) × (1 − ef) = 1 − e

© Ministerio de Hacienda y Administraciones Públicas

página 21 (de 42)

Magerit 3.0

Árboles de ataque

2.3. Árboles de ataque Los árboles de ataque son una técnica para modelar las diferentes formas de alcanzar un objetivo. Aunque han existido durante años con diferentes nombres, se hicieron famosos a partir de los trabajos de B. Schneier que propuso sus sistematización en el área de los sistemas de información. El objetivo del atacante se usa como raíz del árbol. A partir de este objetivo, de forma iterativa e incremental se van detallando como ramas del árbol las diferentes formas de alcanzar aquel objetivo, convirtiéndose las ramas en objetivos intermedios que a su vez pueden refinarse. Los posibles ataques a un sistema se acaban modelando como un bosque de árboles de ataque. Un árbol de ataque pasa revista a cómo se puede atacar un sistema y por tanto permite identificar qué salvaguardas se necesita desplegar para impedirlo. También permiten estudiar la actividad del atacante y por tanto lo que necesita saber y lo que necesita tener para realizar el ataque; de esta forma es posible refinar las posibilidades de que el ataque se produzca si se sabe a quién pudiera interesar el sistema y/o la información y se cruza esta información con la habilidades que se requieren. Veamos un ejemplo ilustrativo sobre como usar fraudulentamente (sin pagar) un servicio de pago: 1. Objetivo: usar sin pagar (OR) 1. suplantar la identidad de un usuario legítimo 2. soslayar la identificación de acceso al servicio 3. abusar del contrato (AND) 1. ser un usuario legítimo 2. conseguir que no se facture el servicio (OR) 1. que no queden trazas de uso 2. que se destruyan las trazas antes de facturación (OR) 1. las destruyo yo 2. engaño al operador para que las borre 3. manipulo del sw para que no las sume 3. repudiar las trazas 4. dar datos de cargo falsos Lo más habitual para alcanzar un objetivo o subobjetivo es que se disponga de varias maneras alternativas (nodos OR); aunque en ocasiones se requiere la concurrencia de varias actividades (nodos AND). En conjunto, se consigue un esquema de las diferentes maneras en las que un usuario podría usarlo sin pagar por ello.

2.3.1. Nodos con atributos Identificadas las diferentes maneras de alcanzar un objetivo, los nodos del árbol se pueden enriquecer con información de detalle, que puede ser de muy diferentes tipos; por ejemplo: •

conocimientos que se requieren del atacante: cualquiera, alguna experiencia, un ingeniero, un hacker profesional, etc.

•

inversión del atacante: cantidad de dinero y tiempo que tendría que desembolsar para realizar la acción

•

riesgo para el atacante: si es capturado, ¿qué consecuencias afrontaría?

Si la información del árbol con estos atributos se procesa automáticamente, podemos obtener escenarios simplificados de ataque: •

usuarios inexpertos pero con bastante dinero

•

atacantes profesionales pero sin capacidad de inversión (o sin necesidad de realizar una inversión adicional para perpetrar este ataque)

© Ministerio de Hacienda y Administraciones Públicas

página 22 (de 42)

Magerit 3.0 •

atacantes que quedarían impunes

•

etc.

Árboles de ataque

Para alcanzar estos escenarios especializados basta eliminar del árbol las ramas que no satisfagan una condición cualitativa o cuantitativa 10 . Sobre un árbol con atributos es posible determinar el ataque más probable, simplemente extrayendo aquel ataque que requiere menos medios y menos conocimiento por parte del atacante. También es posible determinar cuál será la línea de acción de un posible perfil de atacante (que se determina en base al tipo de servicio o información que estamos protegiendo): aquel que con menos coste satisfaga los conocimientos mínimos para realizar el ataque.

2.3.2. Riesgo residual Cuando se han desplegado salvaguardas, su efecto puede reflejarse sobre el árbol de ataque: •

incrementando el conocimiento que el atacante necesitaría para alcanzar su objetivo pese a las salvaguardas desplegadas: idealmente debería ser imposible por mucho que supiera

•

incrementando el desembolso que el atacante tendría que realizar para alcanzar su objetivo a la vista de las salvaguardas desplegadas: idealmente el coste debería ser superior al beneficio para el atacante

Un sistema ideal de salvaguardas eliminaría todas las ramas del árbol. Un sistema real suele llevar los atributos a niveles elevados de conocimiento e inversión que reducen la posibilidad de que el ataque se materialice a un nivel residual aceptado por la Dirección.

2.3.3. Construcción del árbol La construcción del árbol es laboriosa. Marcar el objetivo final requiere un conocimiento de dónde está el valor en la Organización y cual puede ser el objetivo del atacante respecto del mismo. El enriquecimiento en forma de ramas debería ser exhaustivo; pero está limitado por la imaginación del analista; si el atacante es “más listo” tiene una oportunidad para utilizar una vía imprevista. La experiencia permite ir enriqueciendo el árbol con nuevos ataques realmente perpetrados o simplemente detectados en el perímetro con un buen sistema de monitorización. Puede encontrarse ayuda a la construcción del árbol en •

la experiencia propia o ajena en sistemas similares

•

grupos de reflexión (brain storming meetings) en los que de forma informal se van exponiendo cosas que posiblemente pensarían los atacantes; estas sesiones suelen generar mucho material en bruto que hay que organizar y estructurar para ser utilizado como herramienta de análisis

•

herramientas que sugieran ataques en base a la naturaleza de los activos presentes en el sistema

Si se dispone de un modelo de valor como el desarrollado en las actividades de la metodología Magerit, es posible utilizar éste para determinar la naturaleza de los activos y las dependencias entre ellos, de forma que podemos elaborar el árbol de ataques en base al conocimiento de los activos inferiores que constituyen la vía de ataque para alcanzar los activos superiores en los que suele residir el valor para la Organización. Resumen Los árboles de ataque son una herramienta gráfica para analizar y presentar qué puede pasar y cómo lo prevenimos. Capturan de alguna forma el razonamiento del atacante y permiten anticiparse a lo que pudiera ocurrir. 10 Los cálculos suelen ser sencillos y permiten trabajar con diferentes niveles de refinamiento. Los nodos OR cuestan lo que el más barato de sus hijos. Los nodos AND suman los costes. En el caso de analizar conocimientos, los nodos OR requieren en conocimiento más bajo, mientras que los nodos AND requieren el conocimiento del hijo más sofisticado. Nótese que para tomar decisiones combinadas hay que ir al último nodo de detalle, pues frecuentemente lo más barato y lo más sofisticado son condiciones contradictorias.

© Ministerio de Hacienda y Administraciones Públicas

página 23 (de 42)

Magerit 3.0

Árboles de ataque

Aunque es difícil construir árboles exhaustivos en el primer intento, sí son un buen soporte para ir incorporando la experiencia acumulada y recopilar en cada momento el mejor conocimiento de que se dispone. De esta forma es posible realizar simulaciones: •

¿qué pasaría si introducimos nuevos activos?

•

¿qué pasaría si cambiamos las salvaguardas?

•

¿cómo lo enfocaría un atacante de perfil X?

Nótese que los árboles de ataque constituyen una documentación extremadamente valiosa para un atacante, especialmente cuando incorporan el estado actual de salvaguardas, pues facilitan en extremo su trabajo. Por ello deberán extremarse las medidas de protección de su confidencialidad. Su principal inconveniente se encuentra en que es explosivo por la cantidad de árboles y detalle que pueden ser necesarios para recopilar todas las amenazas posibles sobre un sistema medianamente complejo. Por ello cabe esperar su uso como complemento a un análisis de riesgos, permitiendo profundizar en algunas líneas de ataque y dramatizar sus consecuencias.

2.3.4. Referencias •

J. Viega et al., “Risk Analysis: Attack Trees and Other Tricks”, Software Development Magazine, August 2002.

•

A.P. Moore et al., “Attack Modeling for Information Security and Survivability”, Software Engineering Institute, Carnegie Mellon University, Technical Note CMU/SEI-2001-TN-001, 2001.

•

B. Schneier, “Secrets and Lies: Digital Security in a Networked World”, John Wiley & Sons, 2000.

•

B. Schneier, “Attack Trees: Modeling Security Threats”, Dr. Dobb's Journal, December 1999.

ISO 31010 ISO/IEC 31010:2009, Risk management — Risk assessment techniques. UNE-ISO/IEC 31010:2010, Gestión del riesgo. Técnicas de apreciación del riesgo. Esta norma introduce, a título informativo, multitud de técnicas para valorar diferentes magnitudes para analizar riesgos. Aunque los árboles de ataque no aparecen como tales, hay varias técnicas cercanas que analizan secuencias de ataque: B.5 Análisis preliminar de peligros (PHA) B.7 Análisis de riesgos y puntos de control críticos (HACCP) B.14 Análisis de árbol de fallos (FTA) B.15 Análisis del árbol de sucesos (ETA) B.16 Análisis de causa-consecuencia B.17 Análisis de causa-y-efecto B.18 Análisis de capas de protección (LOPA) B.19 Análisis de árbol de decisiones B.21 Análisis de pajarita B.26 Estadísticas y redes Bayesianas

© Ministerio de Hacienda y Administraciones Públicas

página 24 (de 42)

Magerit 3.0

Técnicas generales

3. Técnicas generales En este capítulo nos referiremos a técnicas generales que, entre otros casos, son de utilizad en el desarrollo de un proyecto de análisis y gestión de riesgos. No obstante su generalidad, cuando procede se ha indicado cómo se aplican en el contexto del análisis y gestión de riesgos. Las indicaciones dadas en este libro complementan a las presentadas a lo largo de la metodología. Se han considerado de especial interés: 1. técnicas gráficas: histogramas, diagramas de Pareto y de tarta 2. sesiones de trabajo: entrevistas, reuniones y presentaciones 3. valoraciones Delphi que se desarrollan en las siguientes secciones.

© Ministerio de Hacienda y Administraciones Públicas

página 25 (de 42)

Magerit 3.0

Técnicas gráficas

3.4. Técnicas gráficas Esta sección se centra en cómo algunas representaciones gráficas de los elementos de un proyecto AGR pueden apoyar a dicho proyecto, tanto como soporte a presentaciones, como en la toma de decisiones. Se presentan: •

Gráficas para presentar resultados •

puntos

•

barras

•

radar

•

Diagramas de Pareto, para priorización de acciones

•

Diagramas de tarta

3.4.2. Por puntos y líneas Es la forma más clásica de presentación de resultados. Se limita a usar los ejes cartesianos usando las abscisas para recoger los datos y las ordenadas para mostrar su valor. Los datos en ordenadas se pueden representar en escala lineal o en escala logarítmica. La escala lineal es razonable cuando el rango de valores es reducido, imponiéndose la escala logarítmica cuando el rango es grande (órdenes de magnitud). No obstante, el principal criterio para elegir el tipo de escala debería ser la naturaleza del valor que se quiere representar. Una escala lineal es adecuada cuando importa transmitir la diferencia absoluta entre valores

xi x j Por el contrario, una escala logarítmica es adecuada cuando importa transmitir la diferencia relativa entre valores:

xi x j xi En proyectos de análisis y gestión de riesgos se trabaja con múltiples magnitudes que son percepciones de valor que se ajustan naturalmente a escalas logarítmicas. A veces se pintan las líneas que unen los puntos correspondientes a cada valor en el eje Y para cada dato en el eje X. Otras veces sólo se pintan los puntos. A veces se introducen líneas horizontales de nivel para marcan umbrales: valores mínimos o máximos para alguna toma de decisiones.

© Ministerio de Hacienda y Administraciones Públicas

página 26 (de 42)

Magerit 3.0

Técnicas gráficas

Como ejemplo, se presenta el resultado de cálculo de riesgo en un sistema de información, a lo largo de varias fases del proyecto:

Estas gráficas permiten acumular gran cantidad de información. Informalmente, se puede decir que son más apreciadas por personas con perfil técnico.

3.4.3. Por barras Los diagramas de barras disponen los elementos en unas coordenadas cartesianas convencionales: los elementos a considerar en un eje y los valores en el otro eje. Son muy similares a las presentaciones por puntos y líneas, aunque permiten menos resultados (dado que las barras ocupan más espacio que los puntos). El eje Y puede disfrutar de una escala lineal o logarítmica. Ver consideraciones expuestas en la sección anterior.

© Ministerio de Hacienda y Administraciones Públicas

página 27 (de 42)

Magerit 3.0

Técnicas gráficas

Como ejemplo, se presenta el resultado de cálculo de riesgo en un sistema de información, a lo largo de varias fases del proyecto:

En este tipo de diagramas es fácil recopilar todos los valores. A veces se introducen líneas horizontales de nivel para marcan umbrales: valores mínimos o máximos para alguna toma de decisiones. Informalmente, se puede decir que son presentaciones apreciadas por personas con perfil técnico.

3.4.4. Gráficos de ‘radar’ Estos gráficos representan las distintas variables o factores del fenómeno en estudio sobre semiejes o radios que parten de un centro. Estos radios, tantos como factores, se gradúan para representar sus niveles y posibles umbrales en escala normal o logarítmica, según convenga. El valor alcanzado por cada factor o variable se marca en su radio respectivo (el centro representa el valor cero). Se unen por segmentos los puntos consecutivos así marcados, correspondientes a los valores de las variables definidas en los semiejes, obteniendo un polígono irregular ‘estrellado’ denominado gráfico de ‘radar’ o ‘rosa de los vientos’. Todos ellos ofrecen una visión sintética del fenómeno que permite estudiarlo globalmente, facilitando la observación de sus características y tendencias así como el balance entre sus distintos factores o elementos. Esta visión sintética es especialmente importante en el análisis y gestión de riesgos, donde se busca cierto equilibrio entre factores complementarios. La seguridad procede más de una cobertura homogénea sin fisuras que de una cobertura muy alta en ciertos aspectos frente a claras deficiencias en otros buscando una cierta compensación. El gráfico de ‘radar’ básico exige empezar por decidir qué factores o variables se van a incluir. Así, si se busca representar el estado global de seguridad de una Organización, los factores serán los diferentes servicios. Tras obtener, calcular, clasificar y tabular los valores de cada factor, se dibujan las escalas como radios (dentro de un círculo máximo cuyo radio sea el valor más alto normalizado en cada semieje). Hay que cuidar siempre que exista la misma distancia angular entre los semiejes (es decir que éstos dividan el círculo máximo en arcos iguales).

© Ministerio de Hacienda y Administraciones Públicas

página 28 (de 42)

Magerit 3.0

Técnicas gráficas

El siguiente ejemplo muestra la evolución del riesgo sobre los activos de tipo servicio y datos:

A veces se marcan algunos niveles (circunferencias) con valores especiales tales como umbrales mínimos o cotas máximas. A veces se rellena la superficie abarcada, aunque otras veces se pintan sólo las líneas del perímetro. Las superficies son útiles cuando no se da el caso de que un área “tape” a otra. Las líneas siempre son utilizables. Este tipo de diagramas permiten: •

sintetizar gráficamente el equilibrio o desequilibrio en varios ejes

•

acumular perfiles de máximos o de mínimos

•

mostrar la evolución temporal

Informalmente, se puede decir que son presentaciones apreciadas por personas con perfil gerencial o de dirección.

3.4.5. Diagramas de Pareto Vilfredo Pareto (1848-1923) fue economista italiano estudioso de la distribución de la riqueza. Descubrió que la minoría de la población poseía la mayor parte de la riqueza y la mayoría de la población poseía la menor parte de la riqueza. Con esto estableció la llamada "Ley de Pareto" según la cual la desigualdad económica es inevitable en cualquier sociedad. Posteriormente, se aplicó este concepto a la calidad, obteniéndose lo que hoy se conoce como la regla 80/20. Según este concepto, si se tiene un problema con muchas causas, se puede decir que el 20% de las causas resuelven el 80% del problema y el 80% de las causas solo resuelven el 20% del problema. El análisis de Pareto es una técnica que separa los “pocos vitales” de los “muchos normales”. Una gráfica de Pareto es utilizada para separar gráficamente los aspectos más significativos de un problema que el equipo sepa dónde dirigir sus esfuerzos para mejorar. Reducir los problemas más significativos (las barras más largas en una gráfica Pareto) servirá más para una mejora general que reducir los más pequeños. Con frecuencia, un aspecto tendrá el 80% de los problemas. En el resto de los casos, entre 2 y 3 aspectos serán responsables por el 80% de los problemas. La minoría vital aparece a la izquierda de la gráfica y la mayoría normal a la derecha. Hay veces que es necesario combinar elementos de la mayoría normal en una sola clasificación denominada otros, la cual siempre deberá ser colocada en el extremo derecho. La escala vertical es para el costo en unidades monetarias, frecuencia o porcentaje. © Ministerio de Hacienda y Administraciones Públicas

página 29 (de 42)

Magerit 3.0

Técnicas gráficas

La gráfica es muy útil al permitir identificar visualmente en una sola revisión tales minorías de características vitales a las que es importante prestar atención y de esta manera utilizar todos los recursos necesarios para llevar acabo una acción correctiva sin malgastar esfuerzos. Algunos ejemplos de tales minorías vitales podrían ser: •

La minoría de clientes que representen la mayoría de las ventas.

•

La minoría de productos, procesos, o características de la calidad causantes del grueso de desperdicio o de los costos de reelaboración.

•

La minoría de rechazos que representa la mayoría de quejas de la clientela.

•

La minoría de vendedores que esta vinculada a la mayoría de partes rechazadas.

•

La minoría de problemas causantes del grueso del retraso de un proceso.

•

La minoría de productos que representan la mayoría de las ganancias obtenidas.

•

La minoría de elementos que representan al grueso del costo de un inventarios.

Un equipo puede utilizar la Gráfica de Pareto para varios propósitos durante un proyecto para lograr mejoras: •

Para analizar las causas

•

Para estudiar los resultados

•

Para planear una mejora continua

•

Para comparar fotos de “antes y después” y estudiar qué progreso se ha logrado.

Aplicado a proyectos análisis y gestión de riesgos, cabe citar los siguientes usos •

riesgo del sistema en función de los activos, quizás para cierta dimensión de seguridad, permitiendo detectar qué activos contribuyen fundamentalmente al riesgo del sistema

•

riesgo del sistema en función de las amenazas, quizás para cierta dimensión de seguridad, permitiendo detectar qué amenazas contribuyen fundamentalmente al riesgo del sistema

3.4.5.1. Construcción 1. Seleccionar las categorías lógicas 2. Reunir datos: valor para cada categoría 3. Ordenar los datos de mayor a menor a menor valor •

a menudo conviene introducir una nueva categoría “otros” para agrupar los datos de menor valor para los que no se requiere detalle; esta categoría siempre es la última

4. Calcular el valor agregado para cada categoría •

y calcular el porcentaje del total que cada categoría representa

5. Trazar los ejes: •

eje horizontal (x) para las categorías

•

eje vertical (Y) primario, para la magnitud propia del valor a representar; puede ser lineal o logarítmica, según convenga

•

eje vertical (Y) secundario, para el porcentaje del total: lineal

6. De izquierda a derecha trazar las barras para cada categoría. Si existe una categoría “otros”, debe ser colocada al final, sin importar su valor. Es decir, que no debe tenerse en cuenta al momento de ordenar de mayor a menor la frecuencia de las categorías. 7. Trazar el gráfico para el porcentaje agregado 8. Analizar la gráfica para determinar los “pocos vitales”

3.4.5.2. Ejemplo práctico Se aplican los pasos anteriores a un caso práctico, a título de ilustración. © Ministerio de Hacienda y Administraciones Públicas

página 30 (de 42)

Magerit 3.0

Técnicas gráficas

Pasos 1 y 2: seleccionar categorías y recopilar valores Como resultado del análisis de riesgos, se dispone de la siguiente tabla que resume el riesgo en los diferentes servicios y datos del sistema de información activos

riesgo

[S] Servicios [S_T_remota] tramitación vía www

132.400

[S_T_presencial] tramitación presencial

99.300

[S_notificación] notificación telemática

83.400

[S_info] información de normativa

40.400

[S_news] noticias y modificaciones

5.300

[D] Datos / información [D_ciudadanos] identificación de usuarios [D_económicos] datos económicos

7.300 120.600

[D_expedientes] estado de la tramitación

45.000

[D_normativa] normativa legal

55.100

[D_histórico] de cambios

12.200

Paso 3: ordenar los datos e introducir “otros” activos

riesgo

[S_T_remota] tramitación vía www

132.400

[D_económicos] datos económicos

120.600

[S_T_presencial] tramitación presencial

99.300

[S_notificación] notificación telemática

83.400

[D_normativa] normativa legal

55.100

[D_expedientes] estado de la tramitación

45.000

[S_info] información de normativa

40.400

OTROS

24.800

Paso 4: agregar datos y calcular porcentajes activos

riesgo

agregado

[S_T_remota] tramitación vía www

132.400 132.400

22%

[D_económicos] datos económicos

120.600 253.000

42%

[S_T_presencial] tramitación presencial

99.300 352.300

59%

[S_notificación] notificación telemática

83.400 435.700

72%

[D_normativa] normativa legal

55.100 490.800

82%

[D_expedientes] estado de la tramitación

45.000 535.800

89%

[S_info] información de normativa

40.400 576.200

96%

OTROS

24.800 601.000 100% 601.000

© Ministerio de Hacienda y Administraciones Públicas

página 31 (de 42)

© Ministerio de Hacienda y Administraciones Públicas OTROS

[S_info] información de normativa

[D_expedientes] estado de la tramitación

[D_normativa] normativa legal

[S_notificación] notificación telemática

[S_T_presencial] tramitación presencial

[D_económicos] datos económicos

[S_T_remota] tramitación vía www

Magerit 3.0 Técnicas gráficas

Pasos 5, 6 y 7: dibujar la gráfica 140.000 100%

120.000 80%

100.000

80.000 60% riesgo

60.000 40% agregado

40.000

20.000 20%

0 0%

activos

página 32 (de 42)

Magerit 3.0

Técnicas gráficas

3.4.6. Diagramas de tarta Estos diagramas presentan los datos como fracciones de un círculo, distribuidos los 360º de éste en proporción al valor que es representado en cada sección. La proporción suele ser lineal; rara vez logarítmica.

Aunque los datos pueden ordenarse de la forma que más interese en cada momento, es frecuente usar una ordenación de valor decreciente (siguiendo el procedimiento indicado para los diagramas de Pareto). Los diagramas de tarta no permiten presentar muchos datos simultáneamente; pero si son una indicación muy gráfica de cómo las diferentes partes contribuyen al total.

© Ministerio de Hacienda y Administraciones Públicas

página 33 (de 42)

Magerit 3.0

Sesiones de trabajo

3.6. Sesiones de trabajo Las sesiones de trabajo tienen diversos objetivos. Dependiendo del tipo de sesión que se realice, los objetivos pueden ser: obtener información, comunicar resultados, reducir el tiempo de desarrollo, activar la participación de usuarios y directivos o aumentar la calidad de los resultados. Las sesiones de trabajo pueden ser de varios tipos en función de las personas que participen en ellas, el objetivo que se persiga y el modo de llevarlas a cabo. Las entrevistas son un tipo de sesiones de trabajo dirigidas a obtener la información de una forma individual dónde aparecen los perfiles de entrevistado y entrevistador. Las reuniones pueden tener el mismo objetivo, pero la información está dispersa entre varias personas y únicamente trabajando en grupo, se conseguirá extraer y depurar toda la información de forma global. El objetivo de las presentaciones es la comunicación de avances, conclusiones y resultados por parte del equipo de trabajo al auditorio que corresponda. Se llevan a cabo con el fin de informar sobre el estado de un proyecto en su totalidad o de alguno de los procesos, o exponer uno o varios productos finales de un proceso para su aprobación.

3.6.1. Entrevistas Las entrevistas son reuniones con una persona o un grupo de personas con el objetivo de recabar cierta información. Las entrevistas se dicen estructuradas cuando se atiene a una serie de preguntas planificadas sin margen para la improvisación. Las entrevistas se dicen libres cuando, existiendo un objetivo claro, no existe un formulario rígido. En proyectos de análisis y gestión de riesgos suelen practicarse entrevistas semi-estructuradas en las que, existiendo un guión preestablecido de preguntas, el entrevistado tiene margen para extenderse en puntos no previstos o, más frecuentemente, responderlas en un orden diferente al previsto. En cualquier caso el guión se emplea para no olvidar nada. Por ser más precisos, en las primeras tareas (T1.1.1, Determinar la oportunidad) es casi imposible disponer de un cuestionario rígido, y el entrevistado debe disfrutar de una elevada flexibilidad. En las tareas de descubrimiento (como, por ejemplo, T2.1.1, Identificación de activos) las entrevistas son semi-estructuradas, usando el cuestionario como guía que hay que adaptar. En las tareas de detalle (como, por ejemplo, T2.1.3, Valoración de activos), el margen de maniobra está fuertemente pautado, usándose entrevistas estructuradas. El mayor volumen de entrevistas en un proyecto AGR se encuentra en las tareas del proceso P2, Análisis de riesgos, en el que hay que centrarse especialmente. Las actividades A2.1 (caracterización de los activos), A2.2 (caracterización de las amenazas) y A2.3 (caracterización de las salvaguardas) del proceso P2 (análisis de riesgos), permiten conocer los elementos objeto del análisis de riesgos, identificándolos, valorándolos y relacionándolos. Para capturar este conocimiento se procede por medio de una serie de entrevistas con los participantes, según se determinó en la tarea T1.3.2 (organizar a los participantes) y de acuerdo al plan del proyecto (T1.3.3). Estas entrevistas tienen una importancia crucial porque la información a recoger condiciona el conocimiento del equipo del proyecto (ajeno en parte al funcionamiento del dominio o sea dependiente de los conocedores de su comportamiento cotidiano). La recogida de información es una operación delicada que exige una buena sintonía entre los participantes para no que no quede oculta (ni voluntaria ni involuntariamente) alguna información que posteriormente pudiera revelarse importante y, al tiempo, no caer en un excesivo nivel de detalle que impida separar lo esencial de lo accesorio. Por todo ello es necesario: Durante la preparación de la entrevista: 1. Recopilar los cuestionarios personalizados distribuidos en la tarea T1.4.1. 2. Disponer del documento acreditativo de la Dirección. 3. Ubicar y localizar a los entrevistados, para optimizar la realización de las entrevistas, tanto espacial como temporalmente. © Ministerio de Hacienda y Administraciones Públicas

página 34 (de 42)

Magerit 3.0

Sesiones de trabajo

4. Confirmar cada entrevista, informando de los documentos que se van a requerir durante la entrevista, para facilitar su disponibilidad. Durante la entrevista 5. Informar al entrevistado de los principales conceptos relacionados con la seguridad y la de los sistemas de información, en un grado que depende de su información y experiencia en la materia. 6. Recordar los objetivos de cada entrevista al entrevistado. 7. Perfilar el entorno de trabajo del entrevistado. 8. Recabar las funciones y objetivos del entrevistado. 9. Recabar el modo de actuación del entrevistado. 10. Identificar los medios de que dispone para realizar las funciones y del personal a su cargo. 11. Identificar los procesos realizados y de la información manejada. 12. Identificar posibles situaciones conflictivas (internas o externas, accidentales o provocadas). Para la adquisición de este conocimiento puede ser necesario entrevistar a diferentes colectivos dentro de la Organización: •

dirección o gerencia, que conocen las consecuencias que para la misión de la Organización tendrían los incidentes

•

responsables de los servicios, que conocen los servicios que se manejan y las consecuencias de la no prestación del servicio o de su prestación degradada

•

responsables de los datos, que conocen los datos que se manejan, su valor y las consecuencias de los incidentes que pudieran afectarles

•

responsables de sistemas de información y responsables de operación, que: •

conocen qué sistemas hay en operación

•

tienen el conocimiento histórico de lo que ha pasado anteriormente

•

conocen las consecuencias de un incidente

•

conocen las salvaguardas técnicas implantadas

•

conocen las actividades en curso relacionadas con la seguridad de los sistemas

3.6.2. Reuniones Las reuniones tienen como objetivo obtener información que se encuentra repartida entre varias personas, tomar decisiones estratégicas, tácticas u operativas, transmitir ideas sobre un determinado tema, analizar nuevas necesidades de información, así como comunicar los resultados obtenidos como consecuencia de un estudio. Para realizar una reunión es necesario designar a las personas que deben participar en ella y determinar el lugar en el que poder llevarla a cabo. Las directrices básicas de una reunión son: •

Preparar y convocar la reunión (orden del día)

•

Realizar la reunión

•

Consolidar el resultado de la reunión

•

Elaborar el acta de reunión

Previamente a la convocatoria de la reunión, se definen los objetivos, se planifica el método de trabajo que se va a seguir y el tiempo del que se dispone, se eligen los participantes y se prepara el material necesario. Después de la preparación, es imprescindible enviar al usuario la convocatoria con el orden del día de la reunión. Este orden incluye la fecha, hora de inicio, hora de finalización prevista, lugar, © Ministerio de Hacienda y Administraciones Públicas

página 35 (de 42)

Magerit 3.0

Sesiones de trabajo

asistentes y los puntos a tratar, detallando, entre otros, el tiempo que se dedicará a cada tema y la persona responsable de exponerlo. Dicha convocatoria se envía con antelación suficiente para que los asistentes puedan organizar su agenda y prepararse para la reunión con tiempo. Al inicio de la reunión, es importante hacer un resumen general de los temas a tratar, los objetivos que se persiguen, el método de trabajo y la agenda de la reunión. Si se considera oportuno se puede utilizar la técnica de presentación. Desde su inicio se debe crear un clima de confianza entre los asistentes. La persona responsable de la reunión ejercita la dinámica de dirección de grupos, estimulando la participación, controlando el ritmo de la sesión y centrando o clarificando el tema cuando sea necesario. Al finalizar, se sintetizan las conclusiones, se comprueba si hay acuerdo o si quedan puntos pendientes de reflexión y se propone fechas para próximas reuniones. El responsable de tomar las notas en la reunión, levanta el acta y la remite a los asistentes que deben confirmar su recepción.

3.6.3. Presentaciones El objetivo de las presentaciones es la comunicación de avances, conclusiones y resultados por parte del equipo de trabajo al auditorio que corresponda. Se llevan a cabo con el fin de informar sobre el estado de un proyecto en su totalidad o de alguno de los procesos, o exponer uno o varios productos finales de un proceso para su aprobación. En primer lugar se establece el alcance de la presentación, determinando cuál es el objetivo principal y qué contenido general se quiere comunicar. Una vez que están claros estos puntos, se inicia la preparación de la presentación considerando quién es el ponente, qué tema se va a exponer, cuál va ser la duración estimada y a qué tipo de audiencia o auditorio va dirigida la presentación considerando, a su vez, el nivel de decisión que tengan sus componentes. Todos estos factores van a influir en el tono más o menos formal de la presentación, en el nivel de detalle que requiere la presentación y en los medios a utilizar. La eficacia de una presentación está directamente relacionada con el conocimiento que posea el ponente sobre el tema a exponer, así como de la audiencia a quién va dirigido. Las cuestiones que guían esta preparación responden a las preguntas, a quién se dirige, qué se espera conseguir, de cuánto tiempo se dispone, dónde se va exponer y con qué medios. Una vez analizados todos estos aspectos, se estructura el mensaje que se quiere transmitir a la audiencia de forma que sea significativo y esté bien organizado. Su estructura se apoya en los objetivos y en el concepto esencial que se está tratando y se divide en una apertura o introducción, una visión previa, el cuerpo del tema, una revisión y la conclusión final. Previamente, el ponente debe decidir cuál es el enfoque más eficaz que le quiere dar al tema que va a exponer en función de la audiencia a quien va dirigido. Para conseguir el objetivo de una presentación no es suficiente preparar de una forma estructurada el mensaje, sino que además, el contenido se debe exponer de una forma convincente, utilizando pruebas o materiales de apoyo que refuercen la credibilidad a la audiencia. Por este motivo es importante seleccionar cuidadosamente el material de apoyo que se va a utilizar como pueden ser datos estadísticos, análisis de resultados, etc. También tiene especial relevancia escoger los apoyos audiovisuales oportunos que aclaren conceptos o datos difíciles de captar, resaltar puntos significativos, reforzar la comunicación verbal, despertar interés, cambiar el ritmo de la presentación, etc. Habrá que seleccionar los temas que requieren mayor soporte audiovisual. Conviene señalar que no se debe utilizar un número excesivo de medios ya que no son un fin en sí mismos y podrían dispersar la atención de la audiencia convirtiéndose en fuente de posibles imprevistos por fallos técnicos y repercutiendo negativamente en el ritmo de la presentación. Por este motivo, es importante conocer las ventajas e inconvenientes de cada medio como son pizarras, transparencias, diapositivas, vídeos, ayudas informatizadas, etc., para seleccionar el más apropiado y garantizar el éxito de la presentación. Antes de iniciar la exposición, habrá que asegurar la disponibilidad de todos los recursos materiales necesarios que se hayan considerado oportunos en la preparación de la presentación. © Ministerio de Hacienda y Administraciones Públicas

página 36 (de 42)

Magerit 3.0

Sesiones de trabajo

Durante el desarrollo, es fundamental que el ponente hable con el ritmo adecuado y con un estilo verbal claro, correcto y conciso, y que cuide los aspectos formales. También debe mantener centrado el tema objeto de la presentación, resaltando los puntos más importantes y utilizando el material de soporte de forma adecuada y en el momento preciso, con el fin de captar la atención del auditorio. Conviene prestar atención a la corrección con que el ponente se relaciona con la audiencia. Debe intentar mantener una actitud positiva y abierta ante las posibles preguntas o comentarios. El estilo no verbal es la suma de todas las claves vocales (tono, voz, etc.) y visuales (expresión facial, gestos, movimiento, etc.) que el ponente transmite a la audiencia y es especialmente importante, ya que con él se puede ejercer un impacto significativo sobre la percepción y respuesta de la audiencia. Al finalizar la presentación, puede ser conveniente realizar una evaluación en la que se recojan las capacidades del ponente, el modo en que se llevó a cabo, las características del contenido, material utilizado, etc. y con esta información valorar el grado de satisfacción de la audiencia y tomar las medidas que se consideren oportunas.

3.6.4. Referencias •

“Managing Information Security Risks: The OCTAVE Approach”, C.J. Alberts and A.J. Dorofee, Addison-Wesley Pub Co; 1st edition (July 9, 2002) http://www.cert.org/octave/

•

Magerit, “Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información”, MAP, versión 1.0, 1997 http://www.csi.map.es/csi/pg5m20.htm

•

ISO 31010 ISO/IEC 31010:2009, Risk management — Risk assessment techniques. UNE-ISO/IEC 31010:2010, Gestión del riesgo. Técnicas de apreciación del riesgo. B.2 Entrevistas estructuradas y semiestructuradas

© Ministerio de Hacienda y Administraciones Públicas

página 37 (de 42)

Magerit 3.0

Delphi

3.7. Valoración Delphi La técnica o método Delphi 11 , original de la Rand Corporation (Research ANd Development), comenzó a aplicarse desde 1948 en un proyecto avanzado de las Fuerzas Aéreas de los Estados Unidos y la Compañía Douglas de Aviación, orientándose desde entonces a los estudios prospectivos de investigación espacial. De forma paulatina la técnica diseñada por la Rand Corporation ha ido ampliando sus campos de aplicación: así esta "reflexión intuitiva de expertos" (como algún autor denomina al método Delphi), puede ser utilizada con éxito en multitud de campos y sectores. Delphi es especialmente adecuada para Magerit por las razones siguientes: •

Es una técnica netamente cualitativa que relativamente permite tratar con alta precisión problemas técnicamente complejos.

•

Está planteada como una reflexión organizada de expertos sobre un tema concreto, reflexión que permite recoger las ideas y opiniones más cualificadas en el ámbito de la seguridad (valoración de activos e identificación de amenazas e impactos).

•

Se desarrolla a partir de un cierto ‘escenario inicial’ de modo que permita una adecuada recapitulación e identificación de los problemas que ya existen actualmente.

•

Desarrolla una prospectiva mucho más rica que la mera identificación de la opinión mayoritaria, por medio de un proceso de convergencia de opiniones que se consigue mediante rondas sucesivas de entrevistas.

•

Garantiza satisfactoriamente la ‘limpieza’ de la investigación, impidiendo el predominio de unos expertos sobre otros por razones ajenas a la calidad de sus opiniones.

La técnica Delphi es un instrumento de uso múltiple que se utiliza con muy variados objetivos: •

Identificar problemas.

•

Desarrollar estrategias para la solución de problemas, fijando un rango de alternativas posibles.

•

Identificar factores de resistencia en el proceso de cambio.

•

Establecer previsiones de futuro sobre la evolución de las tendencias que se observan en un determinado campo o sector.

•

Contrastar opiniones en un tema abarcando un amplio campo de disciplinas o sectores.

3.7.1. Resumen ejecutivo 1. Se prepara un cuestionario con los temas cuya valoración se desea conocer. Este punto es crítico para el éxito de los siguientes pasos. Para la elaboración de un buen cuestionario se requiere experiencia y conocimiento del tema que se desea investigar. 2. Se distribuye entre los sujetos que tienen una opinión relevante en el tema a investigar: los expertos. 3. Con las respuestas recibidas, se prepara un histograma indicando cuántos entrevistados se decantan por cada nivel de valoración. 4. Si hay una clara concentración de respuestas en torno a un único valor, el proceso ha acabado: hay un claro consenso en el valor buscado. 5. Si hay diferencias importantes de opinión, se remite de nuevo el mismo cuestionario; pero esta vez acompañado del histograma. Si se han apreciado ambigüedades en el primer cuestionario, deben aclararse en esta segunda ronda. A los entrevistados se les inquiere sobre si consideran que deben mantener su primera opinión o prefieren modificarla.

11 “Delphi” es la forma inglesa de pronunciar Delfos, población griega famosa por su oráculo. Pese al origen fonético, el método usado por el Oráculo de Delphos (adivinación) no tenía nada que ver con el usado con el método Delphi (consenso de opinión entre expertos). Delphi basa la calidad de sus resultados en la hipótesis de que cuando no existe un conocimiento preciso de la realidad, lo mejor que se puede hacer es recoger la opinión, consensuada, de un grupo lo más amplio posible de expertos en la materia.

© Ministerio de Hacienda y Administraciones Públicas

página 38 (de 42)

Magerit 3.0

Delphi

6. Si el histograma de esta segunda ronda sigue sin mostrar una respuesta clara, se pueden realizar nuevas rondas o convocar a los entrevistados en una reunión conjunta para llegar a un consenso. 7. Ante un histograma disperso, siempre hay que preguntarse si se ha hecho la pregunta correcta a las personas correctas, si la pregunta estaba claramente expresada o si, por el contrario se debe volver a empezar con nuevas preguntas y/o nuevos entrevistados.

Se determina qué opiniones cuentan Se elabora un cuestionario ¿cuánto vale X? Se distribuye el cuestionario Se recogen las respuestas Se tabulan las respuestas Se distribuye 1. el cuestionario 2. las respuestas

no

¿consenso? si

ya está

En sentido estricto, Delphi no es tanto un método como un conjunto de técnicas que se aplican según las circunstancias. Algunos aspectos hay que determinarlos en cada caso: Número de participantes. Se estima que el número ideal se encuentra entre 15 y 35 expertos. Aplicado al análisis de riesgos, se pueden establecer grupos amplios en temas generales (por ejemplo, frecuencia típica de una amenaza o idoneidad de una salvaguarda para un riesgo); pero en temas puntuales es difícil pasar de unos pocos participantes (por ejemplo, para valorar un activo). Número de rondas. La segunda ronda es necesaria salvo que haya un consenso suficiente en la primera. Sucesivas rondas pueden dar una opinión más refinada; pero no esto no siempre se consigue por diferentes motivos: •

los expertos muestran rápidamente síntomas de agotamiento, disminuyendo su disposición a colaborar

•

probablemente lo que está mal es el diseño del cuestionario y más vale revisarlo que insistir en el error

Como recomendación general para proyectos de análisis y gestión de riesgos, se puede centrar en número estándar en dos rondas.

3.7.2. Aspectos sociológicos Delphi permite que un grupo trabaje aisladamente y de forma anónima. Es un instrumento que agrupa sistemáticamente las opiniones de un grupo y evita el excesivo protagonismo que pueden ejercer algunas personas, además de cualidades como éstas: •

La generación de ideas de forma aislada produce una mayor cantidad de éstas en el conjunto del grupo seleccionado.

© Ministerio de Hacienda y Administraciones Públicas

página 39 (de 42)

Magerit 3.0

Delphi

•

El proceso de respuestas escritas a las preguntas formuladas obliga a los que responden a pensar en toda la complejidad del problema y a proponer, por tanto, ideas de gran calidad.

•

La conducta del grupo es proactiva, puesto que los que responden no pueden reaccionar ante las ideas expresadas por los otros, eliminando posibles excesos de protagonismo que se manifiestan cuando se expresan opiniones de forma directa y simultánea.

•

El anonimato y el aislamiento entre los que responden proporciona una gran libertad frente a la presión hacia el conformismo en las opiniones.

•

La técnica es válida para obtener opiniones de expertos que se encuentren físicamente alejados.

•

Se puede comprobar que el error de predicción de un conjunto de expertos en un tema es siempre menor que la media de los errores de las opiniones individuales de las personas que lo integran.

3.7.3. Análisis de las respuestas Delphi implica un análisis estadístico del producto de cada una de las rondas de cuestionarios. El análisis debe garantizar que la opinión de cada uno de los expertos se encuentre representada en la respuesta final. Para determinar si hay consenso se necesita una medida de la dispersión de las respuestas. Para determinar cual es el consenso se necesita un punto de convergencia. El análisis es diferente si se busca un valor en una escala continua de valoración (por ejemplo, intentando determinar el valor de un activo para la Organización) o si se intenta identificar elementos a considerar (por ejemplo, activos que deben incluirse en el análisis). En el caso de opiniones de valor, se recurre a estimaciones estadísticas. En el caso de opiniones, se recurre a esquemas de votación.

3.7.3.1. Análisis estadístico Las respuestas se ubican sobre una escala de valores, lineal o logarítmica según la naturaleza del problema que se esté analizando. En aspectos de percepción subjetiva de valor, las escalas logarítmicas suelen ser las más adecuadas. Dados n valores, x 1, x 2, ... , x n se definen los siguientes estadísticos: Media o valor medio

x

1 n

n

xi i 1

Mediana Habiendo ordenado los valores x i en orden ascendente (de menor a mayor), se denomina mediana al primer valor que deja por debajo al 50% de los datos; es decir al valor en la posición n 2 Desviación estándar o típica

1 n 1

n

xi x

2

i 1

Desviación media

desviación media

1 ni

n

xi x 1

Cuartiles. Habiendo ordenado los valores en orden ascendente, se definen 3 puntos de interés Q1: primer valor que deja por debajo al 25% de los datos Q2: primer valor que deja por debajo al 50% de los datos (la mediana) Q3: primer valor que deja por debajo al 75% de los datos © Ministerio de Hacienda y Administraciones Públicas

página 40 (de 42)

Magerit 3.0

Delphi

Recorrido intercuartílico Se define como la distancia Q3 – Q1. Es el rango que recoge las opiniones del 50% de los expertos más “centrados”. Para determinar el valor de consenso se pueden utilizar la media o la mediana, si bien esta última es habitualmente más adecuada por ser inmune a las opiniones más extremas. Para determinar la dispersión se puede utilizar la desviación estándar, la media o el recorrido intercuartílico. La desviación estándar da una importancia mayor a la existencia de respuestas muy alejadas de la media, lo que suele considerarse mala idea. El recorrido intercuartílico es el más adecuado para desechar opiniones extremas. En cualquier caso, cuando se remiten los resultados de una ronda para la siguiente ronda, conviene acompañar los estadísticos de un histograma o diagrama de frecuencia de las respuestas agrupadas en intervalos. Sobre este histograma conviene indicar algunos los valores importantes: •

la mediana o cuartil Q3

•

la media

•

el cuartil Q1

•

el cuartil Q3

•

los valores extremos: los más alejados por arriba y por abajo

3.7.3.2. Votaciones Cuando las respuestas no se pueden asociar a un valor numérico sobre una escala continua de valores, hay que recurrir a técnicas de votación. Sea una pregunta con N posibles respuestas, de las que hay que determinar cual es más adecuada. Una opción es pedirle al experto que valore de 0 a 10 la conveniencia de cada una de las posibles respuestas. En el análisis se puede determinar la valoración media recibida por cada respuesta. En la siguiente ronda, el experto puede estar de acuerdo con la puntuación de consenso, o seguir insistiendo en su opinión divergente. La valoración de consenso y la medida de dispersión se pueden estimar estadísticamente (ver sección anterior). Otra opción es pedirle al experto que seleccione las 5 mejores respuestas y les asigne 5 puntos a la mejor, 4 a la segunda mejor, 3 a la tercera, 2 a la cuarta y uno a la quinta 12 . En el análisis se suman los puntos recibidos por cada respuesta para determinar su posición relativa en la ordenación de consenso. En la siguiente ronda, el experto puede estar de acuerdo en la ordenación de consenso, o seguir insistiendo en su opinión divergente.

3.7.4. Resumen Se pueden resumir los rasgos esenciales de un proceso Delphi en los siguientes puntos: •

Anonimato de respuestas, que reduce las distorsiones de personalidades dominantes que pudieran producirse en reuniones o comités de expertos.

•

‘Feedback’ o realimentación controlada por medio de interacciones sucesivas de modo que en cada una el experto posee la información que se refiere a la interacción previa.

•

Análisis estadístico de las respuestas del grupo, que permite ir consiguiendo el acuerdo razonado de los expertos evitando cualquier modo de presión para obtener modificaciones en sus puntos de vista.

•

Énfasis puesto en la opinión informada, que en ocasiones puede ser contraria a la más común o generalizada en la sociedad.

12 Obviamente, hay que adecuar estos números a cada caso concreto.

© Ministerio de Hacienda y Administraciones Públicas

página 41 (de 42)

Magerit 3.0

Delphi

3.7.5. Referencias •

ISO 31010 ISO/IEC 31010:2009, Risk management — Risk assessment techniques. UNE-ISO/IEC 31010:2010, Gestión del riesgo. Técnicas de apreciación del riesgo. B.3 Técnica Delphi

•

J. Fowles, “Handbook of Futures Research. Westport, Greenwood Press, 1978.

•

H.A. Linstone and M. Turoff (eds), “The Delphi Method: Techniques and Applications”, Reading, MA: Addison-Wesley Publishing Company, 1975.

•

N.C. Dalkey, “The Delphi Method: An Experimental Study of Group Opinion”, RAND Corporation, RM-5888-PR, 1969.

•

O. Helmer, “Analysis of the Future: The Delphi Method”. RAND Corporation Technical Report, P-3558, March 1967.

•

N. Dalkey and O. Helmer, “An Experimental Application of the Delphi Method to the Use of Experts”. Management Science, vol. 9, no. 3, April 1963.

•

M. Girshick, A. Kaplan and A. Skogstad, “The Prediction of Social and Technological Events”. Public Opinion Quarterly, Spring 1950.

© Ministerio de Hacienda y Administraciones Públicas

página 42 (de 42)