magerit v2 metodologia de analisis y gestion de riesgos

MINISTERIO DE

ADMINISTRACIONES PÚBLICAS

MAGERIT – versión 2 Metodología de Análisis y Gestión de Riesgos

de los Sistemas de Información

I - Método

© MINISTERIO DE ADMINISTRACIONES PÚBLICAS Madrid, 20 de junio de 2006 (v 1.1) NIPO 326-05-047-X Catálogo general de publicaciones oficiales http://publicaciones.administracion.es

http://publicaciones.administracion.es

Magerit versión 2

© Ministerio de Administraciones Públicas página 3 (de 154)

Índice

1. Introducción a Magerit ..................................................................................................6 1.1. Objetivos de Magerit ..............................................................................................................6 1.2. Introducción al análisis y gestión de riesgos ..........................................................................7 1.3. El análisis y gestión de riesgos en su contexto......................................................................8

1.3.1. Concienciación y formación............................................................................................9 1.3.2. Incidencias y recuperación .............................................................................................9

1.4. Organización de las guías......................................................................................................9 1.4.1. Modo de empleo ...........................................................................................................10 1.4.2. El catálogo de elementos .............................................................................................11 1.4.3. La guía de técnicas.......................................................................................................11

1.5. Para los que han trabajado con Magerit v1.0.......................................................................12 1.6. Evaluación, certificación, auditoría y acreditación................................................................12 1.7. ¿Cuándo procede analizar y gestionar los riesgos? ............................................................14

2. Realización del análisis y de la gestión .....................................................................16 2.1. Análisis de Riesgos ..............................................................................................................16

2.1.1. Paso 1: Activos .............................................................................................................17 2.1.2. Paso 2: Amenazas........................................................................................................22 2.1.3. Paso 4: Determinación del impacto ..............................................................................23 2.1.4. Paso 5: Determinación del riesgo.................................................................................24 2.1.5. Paso 3: Salvaguardas...................................................................................................24 2.1.6. Revisión del paso 4: impacto residual ..........................................................................26 2.1.7. Revisión del paso 5: riesgo residual .............................................................................26

2.2. Gestión de Riesgos ..............................................................................................................26 2.2.1. La interpretación de los valores de impacto y riesgo residuales ..................................26 2.2.2. Selección de salvaguardas...........................................................................................27 2.2.3. Pérdidas y ganancias ...................................................................................................28 2.2.4. La actitud de la Dirección .............................................................................................30 2.2.5. Revisión del paso 1: activos .........................................................................................31

3. Estructuración del proyecto .......................................................................................32 3.1. Participantes.........................................................................................................................33 3.2. Desarrollo del proyecto ........................................................................................................34

3.2.1. Visión global .................................................................................................................37 3.3. Proceso P1: Planificación.....................................................................................................38

3.3.1. Actividad A1.1: Estudio de oportunidad........................................................................40 3.3.2. Actividad A1.2: Determinación del alcance del proyecto..............................................42 3.3.3. Actividad A1.3: Planificación del proyecto ....................................................................47 3.3.4. Actividad A1.4: Lanzamiento del proyecto....................................................................50 3.3.5. Síntesis del proceso P1 ................................................................................................54 3.3.6. Lista de control del proceso P1 ....................................................................................54

3.4. Proceso P2: Análisis de riesgos...........................................................................................56 3.4.1. Actividad A2.1: Caracterización de los activos .............................................................58 3.4.2. Actividad A2.2: Caracterización de las amenazas........................................................63 3.4.3. Actividad A2.3: Caracterización de las salvaguardas...................................................65 3.4.4. Actividad A2.4: Estimación del estado de riesgo..........................................................67 3.4.5. Síntesis del proceso P2 ................................................................................................70 3.4.6. Lista de control del proceso P2 ....................................................................................71

3.5. Proceso P3: Gestión de riesgos...........................................................................................72 3.5.1. Actividad A3.1: Toma de decisiones.............................................................................73 3.5.2. Actividad A3.2: Elaboración del plan seguridad de la información ...............................75 3.5.3. Actividad A3.3: Ejecución del plan................................................................................78 3.5.4. Síntesis del proceso P3 ................................................................................................79 3.5.5. Lista de control del proceso P3 ....................................................................................79

4. Desarrollo de sistemas de información .....................................................................80 4.1. Inicialización de los procesos...............................................................................................80

Magerit versión 2


4.2. Ciclo de vida de las aplicaciones .........................................................................................81 4.2.1. Plan de sistemas ..........................................................................................................81

4.3. Análisis de riesgos ...............................................................................................................82 4.4. Gestión de riesgos ...............................................................................................................82 4.5. MÉTRICA versión 3..............................................................................................................84

4.5.1. SPD – Seguridad del proceso de desarrollo.................................................................86 4.5.2. SSI – Seguridad del sistema de información................................................................88

4.6. Referencias ..........................................................................................................................92 5. Consejos prácticos......................................................................................................94

5.1. Para identificar activos .........................................................................................................94 5.2. Para descubrir y modelar las dependencias entre activos...................................................95 5.3. Para valorar activos..............................................................................................................97 5.4. Para identificar amenazas....................................................................................................98 5.5. Para valorar amenazas ........................................................................................................98 5.6. Para seleccionar salvaguardas ............................................................................................99 5.7. Aproximaciones sucesivas ...................................................................................................99

5.7.1. Protección básica .......................................................................................................100 5.8. Referencias ........................................................................................................................101

Apéndice 1. Glosario .....................................................................................................102 1.1. Términos en español..........................................................................................................102 1.2. Términos anglosajones ......................................................................................................109 1.3. ISO/IEC Guide 73:2002......................................................................................................110 1.4. Referencias ........................................................................................................................111

Apéndice 2. Referencias ...............................................................................................113 Apéndice 3. Marco legal ................................................................................................114

3.1. Procedimiento administrativo .............................................................................................114 3.2. Protección de datos de carácter personal..........................................................................114 3.3. Firma electrónica................................................................................................................114 3.4. Información clasificada.......................................................................................................115 3.5. Seguridad de las redes y de la información .......................................................................115

Apéndice 4. Marco de evaluación y certificación .......................................................116 4.1. Sistemas de gestión de la seguridad de la información (SGSI) .........................................116

4.1.1. La certificación............................................................................................................117 4.1.2. La acreditación de la entidad certificadora .................................................................119 4.1.3. Terminología...............................................................................................................120 4.1.4. Referencias.................................................................................................................121

4.2. Criterios comunes de evaluación (CC)...............................................................................121 4.2.1. Beneficiarios ...............................................................................................................122 4.2.2. Requisitos de seguridad .............................................................................................123 4.2.3. Creación de perfiles de protección .............................................................................124 4.2.4. Uso de productos certificados ....................................................................................125 4.2.5. Terminología...............................................................................................................125 4.2.6. Referencias.................................................................................................................126

Apéndice 5. Herramientas.............................................................................................128 5.1. PILAR.................................................................................................................................129 5.2. Referencias ........................................................................................................................130

Apéndice 6. Evolución de Magerit versión 1.0 ............................................................131 6.1. Libro I. Guía de aproximación a la seguridad de los sistemas de información ..................131 6.2. Libro II. Guía de procedimientos ........................................................................................131 6.3. Libro III. Guía de técnicas ..................................................................................................132 6.4. Libro IV. Guía para desarrolladores de aplicaciones .........................................................132 6.5. Libro V. Guía para responsables del dominio protegible ...................................................133 6.6. Libro VI. Arquitectura de la información y especificaciones de la interfaz para el intercambio de datos.....................................................................................................................................133 6.7. Libro VII. Referencia de normas legales y técnicas ...........................................................133

Magerit versión 2


Apéndice 7. Caso práctico ............................................................................................134 7.1. La historia...........................................................................................................................134 7.2. Proceso P2: Análisis de riesgos.........................................................................................135

7.2.1. Tarea T2.1.1. Identificación de activos .......................................................................137 7.2.2. Tarea T2.1.2: Dependencias ......................................................................................138 7.2.3. Tarea T2.1.3: Valoración ............................................................................................139 7.2.4. Actividad A2.2: Caracterización de las amenazas......................................................141 7.2.5. Actividad A2.4: Estimación de impacto y riesgo .........................................................142 7.2.6. Actividad A2.3: Caracterización de las salvaguardas.................................................145 7.2.7. Actividad A2.4: Estimación del estado de riesgo........................................................148

7.3. Proceso P3: Gestión de riesgos.........................................................................................150 7.3.1. Actividad A3.1: Toma de decisiones...........................................................................150 7.3.2. Actividad A3.2: Plan de seguridad..............................................................................151 7.3.3. Evolución de los indicadores de impacto y riesgo ......................................................152 7.3.4. Calificación según los Criterios de Seguridad del CSAE............................................154 7.3.5. Calificación según la norma ISO/IEC 17799:2005 .....................................................154

Magerit versión 2 Introducción


1. Introducción a Magerit El CSAE1 ha elaborado y promueve Magerit2 como respuesta a la percepción de que la Adminis-tración (y en general toda la sociedad) depende de forma creciente de las tecnologías de la infor-mación para la consecución de sus objetivos de servicio. La razón de ser de Magerit está directa-mente relacionada con la generalización del uso de los medios electrónicos, informáticos y telemá-ticos, que supone unos beneficios evidentes para los ciudadanos; pero también da lugar a ciertos riesgos que deben minimizarse con medidas de seguridad que generen confianza en el uso de tales medios.

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 Guías de la OCDE3 que, en su principio 6 dicen:

6) Evaluación del riesgo. Los participantes deben llevar a cabo evaluaciones de riesgo.

Esta metodología interesa a todos aquellos que trabajan con información mecanizada y los siste-mas informáticos que la tratan. Si dicha información o los servicios que se prestan gracias a ella son valiosos, esta metodología les permitirá saber cuánto de este valor está en juego y les ayuda-rá a protegerlo.

Conocer el riesgo al que están sometidos los elementos de trabajo es, simplemente, imprescindi-ble para poder gestionarlos y por ello han aparecido multitud de guías informales, aproximaciones metódicas y herramientas de soporte todas las cuales buscan objetivar el análisis para saber cuán seguros (o inseguros) están 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 se persigue una aproximación metódica que no deje lugar a la improvisación, ni dependa de la arbitrariedad del analista.

Pese a que se ha puesto en manos de los sistemas de información graves responsabilidades para cumplir los objetivos de las organizaciones, 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 in-versión en defensa de los medios de trabajo no se traduce 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.1. Objetivos de Magerit Magerit persigue los siguientes objetivos:

Directos:

1. concienciar a los responsables de los sistemas de información de la existencia de riesgos y de la necesidad de atajarlos a tiempo

2. ofrecer un método sistemático para analizar tales riesgos

3. ayudar a descubrir y planificar las medidas oportunas para mantener los riesgos bajo control

1 CSAE: Consejo Superior de Administración Electrónica. 2 MAGERIT: Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información 3 Guías de la OCDE para la seguridad de los sistemas de información y redes. Hacia una cultura de segu-

ridad. 2002.



Indirectos:

4. preparar a la Organización para procesos de evaluación, auditoría, certificación o acredita-ción, según corresponda en cada caso

También se ha buscado la uniformidad de los informes que recogen los hallazgos y las conclusio-nes de un proyecto 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.

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 to-mando 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.

Plan de seguridad Conjunto de programas de seguridad que permiten materializar las decisiones de gestión de riesgos

1.2. 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 de-terminado nivel de confianza, los accidentes o acciones ilícitas o malintencionadas que compro-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.

El objetivo a proteger es la misión de la Organización, teniendo en cuenta las diferentes dimensio-nes de la seguridad:

Disponibilidad: o disposición de los servicios a ser usados cuando sea necesario. La carencia de disponibi-lidad supone una interrupción del servicio. La disponibilidad afecta directamente a la produc-tividad de las organizaciones.

Integridad: o mantenimiento de las características de completitud y corrección de los datos. Contra la in-tegridad, 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 autoriza-dos. La confidencialidad es una propiedad de difícil recuperación, pudiendo minar la con-fianza 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.

Autenticidad (de quién hace uso de los datos o servicios): o que no haya duda de quién se hace responsable de una información o prestación de un servicio, tanto a fin de confiar en él como de poder perseguir posteriormente los incumpli-mientos o errores. Contra la autenticidad se dan suplantaciones y engaños que buscan rea-



lizar un fraude. La autenticidad es la base para poder luchar contra el repudio y, como tal, fundamenta el comercio electrónico o la administración electrónica, permitiendo confiar sin papeles ni presencia física.

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 es-fuerzo 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 ac-tivos 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 im-portante 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 Orga-nización.

Sabiendo lo que podría pasar, hay que tomar decisiones:

Gestión de riesgos: selección e implantación de salvaguardas para conocer, prevenir, impedir, reducir o contro-lar los riesgos identificados.

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.

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.3. El análisis y gestión de riesgos en su contexto Las tareas de análisis y gestión de 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 protegidos se encuen-tran los activos. En coordinación con los objetivos, estrategia y política de la Organización, las ac-tividades de gestión de riesgos permiten elaborar un plan de seguridad que, implantado y opera-do, satisfaga los objetivos propuestos con el nivel de riesgo que se acepta la Dirección.

La implantación de los controles de seguridad requiere una organización gestionada y la participación informa-da de todo el personal que trabaja con el sistema de información. Es este personal el responsable de la opera-ción diaria, de la reacción ante inci-dencias y de la monitorización en ge-neral del sistema para determinar si satisface con eficacia y eficiencia los objetivos propuestos.

Este esquema de trabajo debe ser re-petitivo pues los sistemas de informa-ción rara vez son inmutables; más

análisis y gestiónde riesgos

análisis y gestiónde riesgos objetivos, estrategia

y políticaobjetivos, estrategia

y política

planificaciónplanificaciónorganizaciónorganización

implantación desalvaguardas

implantación desalvaguardas concienciación

y formaciónconcienciación

y formación

gestión de config.y cambios

gestión de config.y cambios incidencias y

recuperaciónincidencias yrecuperación



bien se encuentran sometidos a evolución continua tanto propia (nuevos activos) como del entor-no (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 sal-vaguardas, y es la piedra angular para controlar todas las actividades con fundamento. La gestión de riesgos es la estructuración de las acciones de seguridad para satisfacer las necesidades de-tectadas por el análisis.

1.3.1. Concienciación y formación El mejor plan de seguridad se vería seriamente hipotecado sin una colaboración activa de las per-sonas involucradas en el sistema de información, especialmente si la actitud es negativa, contraria o de “luchar contra las medidas de seguridad”. Es por ello que se requiere la creación de una “cul-tura de seguridad” que, emanando de la alta dirección, conciencie a todos los involucrados de su necesidad y pertinencia.

Son dos 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 formación continua a todos los niveles, recordando las cautelas rutinarias y las activida-des 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, 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.3.2. Incidencias y recuperación Simétricamente, las personas involucradas deben ser conscientes de su papel y relevancia conti-nua 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 salvaguardas responderá a la realidad.

Cuando se produce una incidencia, el tiempo empieza a correr en contra del sistema: su supervi-vencia depende de la presteza 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.

Tanto de los éxitos como de los fracasos conviene aprender continuamente e incorporarlos al pro-ceso de análisis y 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 to-do tipo, desde medidas técnicas hasta una óptima organización.

1.4. Organización de las guías Esta versión 2 de Magerit se ha estructurado en tres libros: éste, que describe “El Método”, un "Catálogo de Elementos" y una "Guía de Técnicas".

Esta guía describe la metodología desde tres ángulos:

• El capítulo 2 describe los pasos para realizar un análisis del estado de riesgo y para gestio-nar su mitigación. Es una presentación netamente conceptual.



• El capítulo 3 describe las tareas básicas para realizar un proyecto de análisis y gestión de riesgos, entendiendo que no basta con tener los conceptos claros, sino que es conveniente pautar roles, actividades, hitos y documentación para que la realización del proyecto de aná-lisis y gestión de riesgos esté bajo control en todo momento.

• El capítulo 4 aplica la metodología al caso del desarrollo de sistemas de información, en el entendimiento que los proyectos de desarrollo de sistemas deben tener en cuenta los ries-gos desde el primer momento, tanto los riesgos a que están expuestos, como los riesgos que las propias aplicaciones introducen en el sistema.

Como complemento, el capítulo 5 desgrana una serie de aspectos prácticos, derivados de la expe-riencia acumulada en el tiempo para la realización de un análisis y una gestión realmente efecti-vos.

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,

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 en esta versión 2.

Por ultimo, se desarrolla un caso práctico como ejemplo.

1.4.1. Modo de empleo Los lectores nuevos en la materia, deben empezar por el capítulo 2.

Si ya hay un conocimiento de los conceptos, el ejemplo ayuda a centrar ideas y terminología.

Si se va a lanzar un proyecto de análisis y gestión de riesgos, el capítulo 3 ayuda a estructurarlo y planificarlo. Si el sistema de información es simple y reducido o bien si sólo se requiere una prime-ra aproximación, puede bastar un planteamiento informal; pero cuando el proyecto toma enverga-dura conviene ser metódico.

Si se está realizando un proyecto de análisis y gestión de riesgos, el capítulo 5 ayuda a centrar la actividad sin distracciones.

Si se va a colaborar en un proyecto de desarrollo de un nuevo sistema de información, o en un ciclo de mantenimiento, conviene recurrir al capítulo 4.

Si se va a trabajar con sistemas homologados, bien porque interesa como mecanismo para espe-cificar lo que se necesita, bien porque interesa como mecanismo para especificar lo que se tiene, conviene recurrir al apéndice 4.

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, todo tipo de situaciones, en definitiva. En la práctica, el usuario puede encontrarse ante situaciones donde el análisis es más restringido. Siguen algu-nos casos prácticos frecuentes:

• sólo se requiere un estudio de los ficheros afectos a la legislación de datos de carácter per-sonal

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

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

• etc.



Estas situaciones, frecuentes, se recogen formalmente en las tareas de la actividad A1.2 e infor-malmente comentando que es constructivo centrarse en un dominio reducido e ir ampliando en la medida de las necesidades, antes que afrontar la totalidad.

1.4.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 diferen-tes equipos.

Cada sección incluye una notación XML que se empleará para publicar regularmente los elemen-tos en un formato estándar capaz de ser procesado automáticamente por herramientas de análisis y gestió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 parti-da para avanzar rápidamente sin distracciones ni olvidos.

1.4.3. La guía de técnicas En libro aparte, aporta luz adicional y guías 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

• análisis coste-beneficio

• diagramas de flujo de datos

• diagramas de procesos

• técnicas gráficas

• planificación de proyectos

• 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 reco-mendará 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.5. Para los que han trabajado con Magerit v1.0 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: acti-vos, 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 “subesta-dos de seguridad” dándole el nuevo nombre de “dimensiones”4 e introduciendo nuevas varas de medir lo que interesa de los activos. El submodelo de procesos aparece bajo el epígrafe de “es-tructuració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, tanto por progreso tecnológico como por progreso de los sujetos, pues tan cierto es que los sistemas cambian como que lo hacen los sujetos a su alrededor, bue-nos y malos. Y, cuanto más éxito tengan los sistemas, más usuarios tendrán y simultáneamente, más sujetos habrá interesados en abusar de ellos o, simplemente, destruirlos. 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.

A efectos prácticos, el párrafo anterior se traduce en que se ha segregado en un libro anejo, “Catálogo de Elementos”, los tipos de activos, las dimensiones y criterios de valoración, el catálogo de amenazas y el catálogo de salvaguardas, de tal forma que puedan evolucionar.

El apéndice 6 es más preciso estableciendo las correspondencias entre la versión 1.0 y esta.

1.6. 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 amol-darse a los componentes que lo constituyen. En análisis de riesgos proporciona una visión singu-lar de cómo es cada sistema, qué valor posee, a qué amenazas está expuesto y de qué salva-guardas 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:

4 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.”



En esta sección se hace una presentación conceptual de las actividades citadas. El lector encon-trará 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 indepen-dientes 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 pro-ductos 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 organiza-ciones buscando el análisis de cómo se explotan los sistemas5.

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?6. Un certificado dice que un sistema es capaz de proteger unos datos de unas amena-zas 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.

Antes de proceder a la certificación, debe haberse realizado un análisis de riesgos a fin de cono-cer 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 acredita-ció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,

• 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 liga-do 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 in-formar a la gerencia de si el sistema está bajo control; es decir, si las medidas de seguridad adop-

5 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 certifi-cados 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.

6 Y así tenemos sistemas aptos para “consumo humano” o “utilización en condiciones térmicas extremas”.



tadas están justificadas, implantadas y monitorizadas, de forma que se puede confiar en el siste-ma 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 incohe-rencias entre las necesidades identificadas en el análisis de riesgos y la realidad detectada duran-te la inspección del sistema en operación.

El informe de auditoría deberá dictaminar sobre la adecuación de las medidas y controles al presente Reglamento, 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 994/1999, artículo 17.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 994/1999, de 11 de junio, por el que se aprueba el Reglamento de medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal.

• “Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para el ejercicio de potestades”, MAP, 2004

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 de-terminado por las actividades de gestión de riesgos.

1.7. ¿Cuándo procede analizar y gestionar los riesgos? 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 ge-rencia 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 im-portante (máximo impacto, máximo riesgo) y obviar lo que es secundario o incluso despreciable. Pero si los datos 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.

Un análisis de riesgos 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úbli-co o privado. El análisis de riesgos permite tomar decisiones de inversión en tecnología, desde la adquisición de equipos de producción hasta el despliegue de un centro alternativo para asegurar la continuidad de la actividad, pasando por las decisiones de adquisición de salvaguardas técnicas y de selección y capacitación del personal.

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 de las aplicaciones 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ér-dida 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.

Por precepto legal El análisis de riesgos puede venir requerido por precepto legal. Tal es el caso del Real Decreto 263/1996, de 16 de Febrero, por el que se regula la utilización de técnicas electrónicas, informáti-cas y telemáticas por la Administración General del Estado. En su artículo 4 (Garantías generales



de la utilización de soportes, medios y aplicaciones electrónicas, informáticas y telemáticas) dice así:

2. Cuando se utilicen los soportes, medios y aplicaciones referidos en el apartado anterior, se adoptarán las medidas técnicas y de organización necesarias que aseguren la autenticidad, confidencialidad, integridad, disponibilidad y conservación de la información. Dichas medi-das de seguridad deberán tener en cuenta el estado de la tecnología y ser proporcionadas a la naturaleza de los datos y de los tratamientos y a los riesgos a los que estén expuestos7.

De forma similar, en la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de ca-rá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 da-tos 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 natu-ral.

Texto que se recoge de nuevo en el preámbulo al REAL DECRETO 994/1999, de 11 de junio, por el que se aprueba el Reglamento de medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal. En este decreto se recoge la obligación de elaborar un do-cumento de seguridad

1. El responsable del fichero elaborará e implantará la normativa de seguridad mediante un do-cumento de obligado cumplimiento para el personal con acceso a los datos automatizados de carácter personal y a los sistemas de información.

Difícilmente se puede desarrollar dicho documento sin un análisis previo de los riesgos sobre los datos, análisis que nos lleve a determinar las medidas de seguridad pertinentes.

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ón8 de siste-mas. 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 realiza-ción del análisis de riesgos que identifique amenazas y salvaguardas y gestione satisfactoriamen-te los riesgos del sistema.

Por último, cabe mencionar el empleo de perfiles de protección como mecanismo de contratación. Los perfiles de protección (ISO/IEC-15408) nacen con la doble misión de poder especificar a priori los requisitos de seguridad de un sistema (para su adquisición o desarrollo) y poder servir de refe-rencia internacional del significado de una certificación. En uno u otro caso, establece la “vara de medir” respecto de la que se calificará la idoneidad de la seguridad del sistema. Véase el apéndice 4.2 sobre criterios comunes de evaluación (CC).

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

7 El análisis de riesgos permite determinar los riesgos a los que están expuestos y la gestión de riesgos

permite adecuar las medidas a dichos riesgos. 8 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.

Magerit versión 2 Realización del análisis y gestión


2. Realización del análisis y de la gestión Este capítulo expone de forma conceptual en qué consiste esto del análisis de riesgos y aquello de su gestión, qué se busca en cada momento y qué conclusiones se derivan.

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.

Elementos:

1. activos, que no son sino los elementos del sistema de información (o estrechamente relacio-nados con este) que aportan valor a la Organización

2. amenazas, que no son sino cosas que les pueden pasar a los activos causando un perjuicio a la Organización

3. salvaguardas (o contra medidas), que no son sino elementos de defensa desplegados 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 conclusio-nes con fundamento.

II. gestión de 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 inci-dentes 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.

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.

2.1. Análisis de Riesgos El análisis de riesgos es una aproximación metódica para determinar el riesgo siguiendo unos pa-sos pautados:

1. determinar los activos relevantes para la Organización, su interrelación y su valor, en el sen-tido 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 expecta-tiva de materialización) de la amenaza

Con el objeto de organizar la presentación, se tratan primero los pasos 1, 2, 4 y 5, obviando el pa-so 3, de forma que las estimaciones de impacto y riesgo sean “potenciales”: 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 seccio-nes9:

activosactivos

amenazasamenazas

frecuenciafrecuencia

impactoimpacto

valorvalor

riesgoriesgo

están expuestos a

Interesan por su

degradacióndegradacióncausan una cierta

con una cierta

2.1.1. Paso 1: Activos Se denominan activos los recursos del sistema de información o relacionados con éste, ne-cesarios para que la Organización funcione correctamente y alcance los objetivos propues-tos por su dirección. El activo esencial es la información que maneja el sistema; o sea los datos. Y alrededor de estos datos se pueden identificar otros activos relevantes:

Los servicios que se pueden prestar gracias a aquellos datos, y los servicios que se necesitan para poder gestionar dichos datos.

Las aplicaciones informáticas (software) que permiten manejar los datos.

Los equipos informáticos (hardware) y que permiten hospedar datos, aplicaciones y servi-cios.

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.

Tipos de activos No todos los activos son de la misma especie. Dependiendo del tipo de activo, las amenazas y las salvaguardas son diferentes10. El capítulo 2 del "Catálogo de Elementos" presenta una relación de tipos de activos.

Si el sistema maneja datos de carácter personal, estos suelen ser importantes por sí mismos y requerir una serie de salvaguardas frecuentemente reguladas por ley. En estos activos interesa

9 Los lectores familiarizados con Magerit v1.0, detectarán la ausencia de la voz “vulnerabilidad”. El concep-

to de vulnerabilidad (potencialidad o posibilidad de ocurrencia de una amenaza sobre un activo) se in-corpora por medio de las métricas de degradación del activo y frecuencia de ocurrencia de la amenaza.

10 No se ataca ni se defiende de la misma manera un servicio telemático que un local de trabajo.



determinar qué tratamiento hay que imponerles11. El hecho de que un dato sea de carácter perso-nal impacta sobre todos los activos involucrados en su tratamiento y custodia.

Algo similar ocurre con los datos sometidos a una clasificación de confidencialidad. Cuando se dice que un cierto informe está clasificado como “reservado”, de forma que las copias están nume-radas, sólo pueden llegar a ciertas personas, no deben salir del recinto y deben ser destruidas concienzudamente, etc. se están imponiendo una serie de salvaguardas porque lo ordena el re-glamento, sectorial o específico de la Organización.

Dependencias Los activos más llamativos suelen ser los datos y los servicios; pero estos activos dependen de otros activos más prosaicos como pueden ser los equipos, las comunicaciones o las frecuente-mente olvidadas personas que trabajan con aquellos. Por ello aparece como importante el con-cepto de “dependencias entre activos” o la medida en que un activo superior se vería afectado por un incidente de seguridad en un activo inferior112.

Se dice que un “activo superior” depende de otro “activo inferior” cuando las necesidades de segu-ridad del superior se reflejan en las necesidades de seguridad del inferior. O, dicho en otras pala-bras, 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:

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

• equipamiento y suministros: energía, climatización, comunicaciones

• personal: de dirección, de operación, de desarrollo, etc.

• otros: edificios, mobiliario, etc.

• capa 2: el sistema de información propiamente dicho

• equipos informáticos (hardware)

• aplicaciones (software)

• comunicaciones

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

• capa 3: la información • datos

• meta-datos: estructuras, índices, claves de cifra, etc.

• capa 4: las funciones de la Organización, que justifican la existencia del sistema de in-formación y le dan finalidad

• objetivos y misión

• bienes y servicios producidos

• capa 5: otros activos 11 Es como si el legislador hubiera realizado el análisis de riesgos por nosotros y hubiera determinado las

salvaguardas pertinentes. En todo caso, leyes y regulaciones existen y ayudan a que estos datos, cier-tamente importantes, estén protegidos.

12 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 ejecu-tivo con información estratégica de la empresa, 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.



• credibilidad o buena imagen

• conocimiento acumulado

• independencia de criterio o actuación

• intimidad de las personas

• integridad física de las personas

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.

El valor puede ser propio, o puede ser acumulado. Se dice que los activos inferiores en un es-quema de dependencias, acumulan el valor de los activos que se apoyan en ellos.

El valor nuclear suele estar en la información (o datos) que el sistema maneja, quedando los de-más activos subordinados a las necesidades de explotación y protección de la información. 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 datos y servicios finales 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 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 (autentici-dad de quien accede a los datos para escribir o, simplemente, consultar)

• 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 parcial-mente 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 servicios13.

En sistemas dedicados a la administración electrónica o al 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. En estos activos, además de la autentici-dad, interesa calibrar la:

• 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?

13 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.



Se reconocen habitualmente las dimensiones básicas: autenticidad, confidencialidad, integridad y disponibilidad. En esta metodología se ha refinado la autenticidad para distinguir entre el uso de un servicio y el acceso a unos datos. Además se ha introducido el concepto de trazabilidad (del inglés, accountability) tomado de las guías ISO/IEC 13335, igualmente segmentada entra la traza-bilidad del servicio y la de los datos. Los aspectos de autenticidad y trazabilidad de los datos son críticos para satisfacer medidas reglamentarias sobre ficheros que contengan datos de carácter personal.

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 impres-cindible 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, adi-cionalmente, 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 salir 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érdi-da 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 di-mensiones 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

Todos estos 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.

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.



El capítulo 8.1 de 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 no adolecen de los proble-mas de las valoraciones cualitativas. Sumar valores numéricos es absolutamente “natural” y la in-terpretació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?

El capítulo 8.2 de 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, cualitati-va 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 deten-ción sea irrelevante, mientras que un día sin servicio causa un daño moderado; pero un mes dete-nido 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:

15m 30m 1h 2h 6h 1d 2d 1s 2s 1m 2m 6m 1a total0

1

2

3

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 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 im-pedir 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.



2.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.

Hay accidentes naturales (terremotos, inundaciones, ...) y 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. Hay amenazas causadas por las personas, bien errores, bien ataques intencionados.

El capítulo 5 del "Catálogo de Elementos" presenta una relación de amenazas típicas.

No todas las amenazas afectan a todos los activos14, 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.

Una vez determinado que una amenaza puede perjudicar a un activo, hay que estimar cuán vulne-rable15 es el activo, en dos sentidos:

degradación: cuán perjudicado resultaría el activo

frecuencia: cada cuánto se materializa 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 expre-siones 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 frecuencia16 pone en perspectiva aquella degradación, pues una amenaza puede ser de terri-bles consecuencias pero de muy improbable materialización; mientras que otra amenaza puede ser de muy bajas consecuencias, pero tan frecuente como para acabar acumulando un daño con-siderable.

La frecuencia se modela como una tasa anual de ocurrencia, siendo valores típicos

100 muy frecuente a diario 10 frecuente mensualmente 1 normal una vez al año

1/10 poco frecuente cada varios años

14 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 aplicacio-nes, no a las personas.

15 Los lectores familiarizados con Magerit v1.0, detectarán la ausencia de la voz “vulnerabilidad”. El concep-to de vulnerabilidad (potencialidad o posibilidad de ocurrencia de una amenaza sobre un activo) se in-corpora por medio de las métricas de degradación del activo y frecuencia de ocurrencia de la amenaza.

16 Se mide como el número medio de ocurrencias de la amenaza en un intervalo determinado de tiempo. Típicamente estima sobre periodos anuales. Por ejemplo, si en un cierto sistema se produce una avería del aire acondicionado un promedio de cinco veces en un año, esa es la frecuencia: 5.



2.1.3. Paso 4: Determinación del impacto 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 conside-ración que queda hacer es relativa a las dependencias entre activos. Es frecuente que el valor del sistema de información se centre en los servicios que presta y los datos que maneja, al tiempo que las amenazas suelen materializarse en los medios.

Impacto acumulado Es el calculado sobre un activo teniendo en cuenta

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

• las amenazas a que está expuesto

El impacto acumulado se calcula para cada activo, por cada amenaza y en cada dimensión de va-loració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 infor-mación, permite determinar las salvaguardas de que hay que dotar a los medios de trabajo: pro-tecció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í, ni dependan de ningún 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 acti-vos superiores,

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



• puede agregarse el impacto de una amenaza en diferentes dimensiones.

2.1.4. Paso 5: Determinación del riesgo 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 fre-cuencia de ocurrencia.

El riesgo crece con el impacto y con la frecuencia.

Riesgo acumulado Es el calculado sobre un activo teniendo en cuenta

• el impacto acumulado sobre un activo debido a una amenaza y

• la frecuencia de la amenaza

El riesgo acumulado se calcula para cada activo, por cada amenaza y en cada dimensión de valo-ración, siendo una función del valor acumulado, la degradación causada y la frecuencia de la amenaza.

El riesgo acumulado, al calcularse sobre los activos que soportan el peso del sistema de informa-ción, permite determinar las salvaguardas de que hay que dotar a los medios de trabajo: protec-ció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 frecuencia de la amenaza

El riesgo repercutido se calcula para cada activo, por cada amenaza y en cada dimensión de valo-ración, siendo una función del valor propio, la degradación causada y la frecuencia de la amena-za.

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 riesgo acumulado sobre activos que no sean dependientes entre sí, ni dependan de ningún activo superior común,

• 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 su-periores,

• 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 concu-rrentes,

• puede agregarse el riesgo de una amenaza en diferentes dimensiones.

2.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 tec-nológicos que reducen el riesgo. Hay amenazas que se conjurar simplemente organizándose ade-cuadamente, 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.

Las salvaguardas entran en el cálculo del riesgo de dos formas:

Reduciendo la frecuencia 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 per-miten detectar inmediatamente el ataque para frenar que la degradación avance. Incluso al-gunas salvaguardas se limitan a permitir la pronta recuperación del sistema cuando la ame-naza lo destruye. En cualquiera de las versiones, la amenaza se materializa; pero las con-secuencias se limitan.

activosactivos

amenazasamenazas

frecuenciaresidual

frecuenciaresidual

impactoresidual

impactoresidual

valorvalor

riesgoresidualriesgo

residual

están expuestos a

Interesan por su

degradaciónresidual

degradaciónresidual

causan una cierta

con una cierta

tipo de activodimensiónamenaza

nivel de riesgosalvaguardassalvaguardas

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, lo que implica que:

• es teóricamente idónea

• está perfectamente desplegada, configurada y mantenida

• se emplea siempre

• 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 están de adorno y el 100% para aquellas que son perfectas, se estimará un grado de eficacia real en cada caso concreto.



2.1.6. Revisión del paso 4: impacto residual Si se han hecho todos los deberes a la perfección, el impacto residual debe ser despreciable.

Si hay deberes a medio hacer (normas imprecisas, procedimientos incompletos, salvaguardas in-adecuadas o insuficientes, o controles que no controlan) entonces se dice que el sistema perma-nece sometido a un impacto residual.

El cálculo del impacto residual es sencillo. Como no han cambiado los activos, ni sus dependen-cias, 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 propor-ció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.

2.1.7. Revisión del paso 5: riesgo residual Si se han hecho todos los deberes a la perfección, el riesgo residual debe ser despreciable.

Si hay deberes a medio hacer (normas imprecisas, procedimientos incompletos, salvaguardas in-adecuadas o insuficientes, o controles que no controlan) entonces se dice que el sistema perma-nece sometido a un riesgo 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 frecuencia de las amenazas, se repiten los cál-culos de riesgo usando el impacto residual y la nueva tasa de ocurrencia.

La magnitud de la degradación se toma en consideración en el cálculo del impacto residual.

La magnitud de la frecuencia 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.

2.2. Gestión de Riesgos El análisis de riesgos determina impactos y riesgos. Los impactos recogen daños absolutos, inde-pendientemente de que sea más o menos probable que se dé la circunstancia. En cambio el ries-go pondera la probabilidad de que ocurra. El impacto refleja el daño posible, mientras que el ries-go refleja el daño probable.

Si el impacto y el riesgo residuales son despreciables, se ha terminado. Si no, hay que hacer algo.

2.2.1. La 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 desprecia-bles. Son pues una métrica de carencias.

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ípi-camente no porque no haya nada hecho, sino porque hay elementos fundamentales sin hacer.

Si el valor residual es despreciable, ya está. Esto no quiere decir descuidar la guardia; pero si afrontar el día con cierta confianza17.

17 Don Quijote (Capítulo X) llamaba la atención sobre el “bálsamo de Fierabrás” que “es un bálsamo ... con

el cual no hay que tener temor a la muerte, ni hay pensar morir de ferida alguna. “ No puede el respon-sable de seguridad caer en la confianza ciega pues los sistemas evolucionan, los atacantes inventan, los



Mientras el valor residual sea más que despreciable, hay una cierta exposición.

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. Los respon-sables de la toma de decisiones deberán prestar cuidadosa atención a esta relación de tareas pendientes, que se denomina Informe de Insuficiencias.

2.2.2. Selección de salvaguardas Las amenazas hay que conjurarlas, por principio y mientras no se justifique lo contrario.

Hay que planificar el conjunto de salvaguardas pertinentes para atajar tanto el impacto como el riesgo, reduciendo bien la degradación del activo (minimizando el daño), bien reduciendo la fre-cuencia de la amenaza (minimizando sus oportunidades).

Toda amenaza debe ser conjurada profesionalmente, lo que quiere decir que hay que:

1. establecer una política de la Organización al respecto; o sea, unas directrices generales de quién es responsable de cada cosa

2. establecer una norma; o sea, unos objetivos a satisfacer para poder decir con propiedad que la amenaza ha sido conjurada

3. establecer unos procedimientos; o sea, instrucciones paso a paso de qué hay que hacer

4. desplegar salvaguardas técnicas que efectivamente se enfrenten a las amenazas con capa-cidad para conjurarlas

5. desplegar controles que permitan saber que todo lo anterior está funcionando según lo pre-visto

A este conjunto de elementos se le encasilla habitualmente bajo el nombre de Sistema de Gestión de la Seguridad de la Información (SGSI), aunque se está gestionando tanto como actuando.

El párrafo anterior puede llamar a engaño si el lector interpreta que hay que llevar a cabo todos y cada uno de los puntos para cada amenaza. No. En la práctica lo dicho se traduce en desarrollar una política, unas normas y unos procedimientos junto con el despliegue de una serie de salva-guardas y controles y, ahora sí, verificar que todas y cada una de las amenazas tienen una res-puesta adecuada.

De los puntos anteriores, el más “abierto” es el de determinación de las salvaguardas apropiadas. Es realmente un arte que requiere personal especializado aunque en la práctica las situaciones más habituales están perfectamente documentadas en la literatura y basta elegir de entre un catá-logo en función de la magnitud del riesgo.

Tipos de salvaguardas Un sistema debe considerar prioritariamente las salvaguardas de tipo preventivo que buscan que la amenaza no ocurra o su daño sea despreciable. Es decir, impedir incidentes o ataques.

En la práctica, no todo es previsible, ni todo lo previsible es económicamente razonable atajarlo en sus orígenes. Tanto para enfrentar lo desconocido como para protegerse de aquello a lo que se permanece expuesto, es necesario disponer de elementos que detecten el inicio de un incidente y permitan reaccionar con presteza impidiendo que se convierta en un desastre.

Tanto las medidas preventivas como las de emergencia admiten una cierta degradación de los activos por lo que habrá que disponer por último de medidas de recuperación que devuelvan el valor perdido por los activos.

usuarios son impredecibles en sus errores y en definitiva siempre hay que estar atento y pronto a reac-cionar ante nuevas realidades.



Es de sentido común intentar actuar de forma preventiva para que las cosas no puedan ocurrir o no puedan causar mucho daño; pero no siempre es posible18 y hay que estar preparados para que ocurran. Lo que no debe ser de ninguna manera es que un ataque pase inadvertido: hay que de-tectarlo, registrarlo y reaccionar primero con un plan de emergencia (que pare y limite el incidente) y después con un plan de continuidad y recuperación para regresar a donde se debe estar.

Por último, sin ánimo de saturar al lector, hay que recordar que conviene llegar a un cierto equili-brio entre

salvaguardas técnicas: en aplicaciones, equipos y comunicaciones

salvaguardas físicas: protegiendo el entorno de trabajo de las personas y los equipos

medidas de organización: de prevención y gestión de las incidencias

política de personal: que, a fin de cuentas, es el eslabón imprescindible y más delicado: polí-tica de contratación, formación permanente, Organización de reporte de incidencias, plan de reacción y medidas disciplinarias.

2.2.3. Pérdidas y ganancias Es de sentido común que no se puede invertir en salvaguardas más allá del valor de los propios activos a proteger.

Aparecen en la práctica gráficos como el siguiente que ponen uno frente al otro el coste de la in-seguridad (lo que costaría no estar protegidos) y el coste de las salvaguardas.

0 10 20 30 40 50 60 70 80 90 100

grado de seguridad

riesgo residual gasto en salvaguardas coste total

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 fuertemen-te con pequeñas inversiones19 y que el coste de las inversiones se dispare para alcanzar niveles de seguridad cercanos al 100%20. La curva central suma el coste para la Organización, bien deri-

18 Hay mil razones que pueden impedir una protección absoluta: coste, dificultad técnica, límites legales,

etc. No obstante, una de las razones más fuertes para no poder prevenir es el mero desconocimiento de lo que puede pasar. Podemos prever que se repita lo que ha ocurrido en el pasado; pero es difícil prever el próximo ataque intencionado pues hay un componente creativo de parte del atacante.

19 Medidas básicas de seguridad suponen un importante descenso del riesgo. Por ello son inexcusables. 20 Reflejando una vez más que la seguridad absoluta (riesgo cero) no existe.



vado 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 inverte 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 con-ceptual 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 (no hacer nada) 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 po-sitivos las entradas de dinero. Considerando los siguientes componentes:

− (recurrente) riesgo residual21

− (una vez) coste de las salvaguardas22

− (recurrente) coste anual de mantenimiento de las salvaguardas

+ (recurrente) mejora en la productividad23

+ (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 or-ganizaciones, 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.

21 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.

22 Si la salvaguarda ya existe, coste de mejora. Si no existiera, coste de adquisición e instalación. En cual-quier caso hay que imputar costes de formación de los operadores, usuarios, etc.

23 Este epígrafe puede ser positivo si la Organización mejora su productividad; o puede ser negativo, si em-peora. 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 salva-guardas que minoran la productividad podemos citar la clasificación de documentación con control de ac-ceso restringido.



En los demás escenarios, hay cosas que suman y cosas que restan, pudiendo darse varias situa-ciones24:

-80

-70

-60

-50

-40

-30

-20

-10

0

101 2 3 4 5

E0E1E2E3

• 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 in-versión.

2.2.4. La actitud de la Dirección La dirección de la Organización sometida al análisis de riesgos debe determinar el nivel de impac-to y riesgo aceptable. Más propiamente dicho, debe aceptar la responsabilidad de las insuficien-cias. Esta decisión no es técnica. Puede ser una decisión política o gerencial o puede venir deter-minada 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 de-partamento, 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 Direc-ción 225.

Si el impacto y/o el riesgo están por encima de lo aceptable, se puede:

1. eliminar el activo; suena muy fuerte, pero a veces hay activos que, simplemente, no vale la pena mantener26

2. introducir nuevas salvaguardas o mejorar la eficacia de las presentes

24 En el eje X se muestran años, en referencia al año 0 en que se realiza el análisis de riesgos. En ordena-

das aparecen costes en unidades arbitrarias. 25 Hablar de Dirección es pecar de simplificar la realidad. En inglés suele emplearse el término “stakehol-

ders” (o tenedores de la estaca) para referirse a los afectados por las decisiones estratégicas de una Or-ganizació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 tec-nología por la imprudente puesta en escena de algunos actores.

26 ¿Necesita realmente mantener este dato de carácter personal y nivel alto? ¿Es realmente necesaria la red inalámbrica en la oficina?



2.2.5. Revisión del paso 1: activos Algunas salvaguardas, notablemente las de tipo técnico, se traducen en el despliegue de más equipamiento27 que se convierte a su vez en un activo del sistema. Estos activos soportan parte del valor del sistema y están a su vez sujetos a amenazas que pueden perjudicar a los activos de valor.

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.

27 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.

Magerit versión 2 Estructuración del proyecto


3. Estructuración del proyecto Si en el capítulo anterior se ha marcado de forma conceptual cómo llevar a cabo un análisis y una gestión de riesgos, en este capitulo se plasman aquellos conceptos en componentes de un pro-yecto de análisis y gestión de riesgos (AGR)28. Los pasos se organizan en tres grandes procesos (preparación, análisis y gestión). Cada proceso se organiza en actividades que, finalmente, se es-tructuran en tareas a realizar. En cada tarea se indica lo que hay que hacer así como las posibles dificultades para conseguirlo y la forma de afrontarla con éxito29. En cada proceso se indican los hitos que van marcando el progreso del proyecto hasta su terminación.

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 aspec-tos de seguridad, todo tipo de situaciones, en definitiva. En la práctica, el usuario puede encon-trarse ante situaciones donde el análisis es más restringido. Siguen algunos casos prácticos fre-cuentes:

• 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 recogen formalmente en las tareas de la actividad A1.2 e infor-malmente comentando que es constructivo centrarse en un dominio reducido e ir ampliando en la medida de las necesidades, antes que afrontar la totalidad.

Además de cubrir un dominio más o menos extenso, pueden darse situaciones en las que se re-quieren 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 (actividad A1.2)

2. verticalmente a la profundidad oportuna

28 Corresponde al “Modelo de procesos” de Magerit versión 1.0. 29 En el capítulo 6 se incluyen consejos prácticos adicionales.



3.1. Participantes Durante el desarrollo del proyecto AGR, desde su inicio a su terminación, se identifican los si-guientes órganos colegiados30:

Comité de Dirección El perfil requerido para este grupo de participantes incluye a personas con un nivel alto en la dirección de la Organización, conocimiento de los objetivos estratégicos y de negocio que se persiguen y autoridad para validar y aprobar cada uno de los procesos realizados durante el desarrollo del proyecto.

Las responsabilidades de este comité consisten en

• asignar los recursos necesarios para la ejecución del proyecto

• aprobar los resultados finales de cada proceso

El comité de dirección formaliza sus funciones en la tarea T1.3.2.

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 par-ticipació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

El comité de seguimiento se crea en la tarea T1.1.1 y sus funciones se formalizan en T1.3.2..

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 es-pecialista 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

El equipo de proyecto se determina en la tarea T1.3.2.

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 estra-tegias a medio y largo plazo

30 Es importante formalizar los roles de los participantes en el proyecto. En esta sección se identifican di-

chos roles y se les da un nombre estándar. Más adelante se detalla en qué momento (tarea) del proyecto se constituyen formalmente.



• 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

Las unidades afectadas se determinan en las tareas T1.2.2 y T1.2.3. Los interlocutores de identifican en la tarea T1.3.1.

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 AGR propiamente dicho.

Debe ser una persona con visión global de los sistemas de información y su papel en las ac-tividades de la Organización, sin necesidad de conocer los detalles; pero si al tanto de las incidencias.

El promotor tiene su papel en la tarea T1.1.1.

Director del Proyecto Debe ser un directivo de alto nivel, con responsabilidades en seguridad dentro de la Organi-zació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.

El director del proyecto se designa en la tarea T1.2.2.

Enlace operacional Será una persona de la Organización con buen conocimiento de las personas y de las uni-dades implicadas en el proyecto AGR, que tenga capacidad para conectar al equipo de pro-yecto con el grupo de usuarios.

Es el interlocutor visible del comité de seguimiento.

El enlace operacional se designa en la tarea T1.3.2.

Conviene recordar que un proyecto AGR siempre es mixto por su propia naturaleza; es decir, re-quiere 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.

3.2. Desarrollo del proyecto En esta sección se ordenan y formalizan las acciones a realizar a lo largo de un proyecto AGR, estableciendo un marco normalizado de desarrollo. Este marco de trabajo define:

1. una estructuración del proyecto que sirve de guía al equipo de trabajo y que permite involu-crar en aquél a los responsables y a los usuarios.

2. un conjunto de productos a obtener

3. un conjunto de técnicas para obtener los productos

4. las funciones y responsabilidades de los distintos participantes

El proyecto se divide en tres grandes procesos, desglosándose cada uno en una serie de activi-dades y estas, a su vez, en tareas con el grado de detalle oportuno.

Cada tarea especifica los siguientes conceptos:

• acciones a realizar

• datos de entrada

• datos de salida: productos y documentos a obtener como producto de las acciones



• técnicas recomendadas para llevar a buen término los objetivos de la tarea

• participantes que intervienen o están afectados por la cumplimentación de las acciones

Un proyecto AGR conlleva tres procesos:

Proceso P1: Planificación • Se establecen las consideraciones necesarias para arrancar el proyecto AGR.

• Se investiga la oportunidad de realizarlo.

• Se definen los objetivos que ha de cumplir y el dominio (ámbito) que abarcará.

• Se planifican los medios materiales y humanos para su realización.

• Se procede al lanzamiento del proyecto.

Proceso P2: Análisis de riesgos • Se identifican los activos a tratar, las relaciones entre ellos y la valoración que merecen.

• Se identifican las amenazas significativas sobre aquellos activos y se valoran en términos de frecuencia de ocurrencia y degradación que causan sobre el valor del activo afectado.

• Se identifican las salvaguardas existentes y se valora la eficacia de su implantación.

• Se estima el impacto y el riesgo al que están expuestos los activos del sistema.

• Se interpreta el significado del impacto y el riesgo.

Proceso P3: Gestión de riesgos • Se elige una estrategia para mitigar impacto y riesgo.

• Se determinan las salvaguardas oportunas para el objetivo anterior.

• Se determina la calidad necesaria para dichas salvaguardas.

• Se diseña un plan de seguridad (plan de acción o plan director) para llevar el impacto y el riesgo a niveles aceptables.

• Se lleva a cabo el plan de seguridad.

Estos tres procesos no son necesariamente secuenciales. El proceso P1 es claramente el inicia-dor del proyecto. El proceso P2 funciona como soporte del proceso P3 en el sentido de que la gestión de riesgos (P3) es una tarea continua soportada por los técnicas de análisis (P2). La ges-tión de riesgos supone siempre la alteración del conjunto de salvaguardas, bien porque aparecen nuevas salvaguardas, bien porque se reemplazan unas por otras, bien porque se mejoran las exis-tentes. La gestión de riesgos puede suponer la alteración del conjunto de activos31, bien porque aparecen nuevos activos (elementos de salvaguarda que pasan a formar parte del sistema) o por-que se eliminan activos del sistema. En definitiva, a lo largo del proceso P3 se recurrirá a tareas del proceso P2.

31 Formalmente se dice que la introducción de salvaguardas para mitigar ciertos riesgos puede introducir

nuevos riesgos en el sistema.



P1: PlanificaciónP1: Planificación P2: Análisis de riesgosP2: Análisis de riesgos

P3: Gestión de riesgosP3: Gestión de riesgos

A lo largo de estos procesos se generan una serie de documentos de interés general32:

P1: Planificación • Tipología de activos

• Dimensiones de seguridad relevantes

• Criterios de evaluación

P2: Análisis de riesgos • Modelo de valor

• Mapa de riesgos

• Evaluación de salvaguardas

• Estado de riesgo

• Informe de insuficiencias

P3: Gestión de riesgos • Plan de seguridad

32 Sin entrar en documentos de trabajo del propio proyecto AGR, que se detallan en las tareas.



3.2.1. Visión global Sin perjuicio de una exposición detallada más adelante, se relaciona a continuación el árbol com-pleto de procesos, actividades y tareas que vertebran un proyecto AGR.

Procesos, actividades y tareas Proceso P1: Planificación

Actividad A1.1: Estudio de oportunidad Tarea T1.1.1: Determinar la oportunidad

Actividad A1.2: Determinación del alcance del proyecto Tarea T1.2.1: Objetivos y restricciones generales Tarea T1.2.2: Determinación del dominio y límites Tarea T1.2.3: Identificación del entorno Tarea T1.2.4: Estimación de dimensiones y coste

Actividad A1.3: Planificación del proyecto Tarea T1.3.1: Evaluar cargas y planificar entrevistas Tarea T1.3.2: Organizar a los participantes Tarea T1.3.3: Planificar el trabajo

Actividad A1.4: Lanzamiento del proyecto Tarea T1.4.1: Adaptar los cuestionarios Tarea T1.4.2: Criterios de evaluación Tarea T1.4.3: Recursos necesarios Tarea T1.4.4: Sensibilización

Proceso P2: Análisis de riesgos Actividad A2.1: Caracterización de los activos

Tarea T2.1.1: Identificación de los activos Tarea T2.1.2: Dependencias entre activos Tarea T2.1.3: Valoración de los activos

Actividad A2.2: Caracterización de las amenazas Tarea T2.2.1: Identificación de las amenazas Tarea T2.2.2: Valoración de las amenazas

Actividad A2.3: Caracterización de las salvaguardas Tarea T2.3.1: Identificación de las salvaguardas existentes Tarea T2.3.2: Valoración de las salvaguardas existentes

Actividad A2.4: Estimación del estado de riesgo Tarea T2.4.1: Estimación del impacto Tarea T2.4.2: Estimación del riesgo Tarea T2.4.3: Interpretación de los resultados

Proceso P3: Gestión de riesgos Actividad A3.1: Toma de decisiones

Tarea T3.1.1: Calificación de los riesgos Actividad A3.2: Plan de seguridad

Tarea T3.2.1: Programas de seguridad Tarea T3.2.2: Plan de ejecución

Actividad A3.3: Ejecución del plan Tarea T3.3.*: Ejecución de cada programa de seguridad



3.3. Proceso P1: Planificación El objetivo principal de este proceso es establecer el marco general de referencia para todo el proyecto.

Como objetivos complementarios se pueden identificar los siguientes:

• Motivar, concienciar e involucrar a la Dirección o Gerencia de la Organización.

• Razonar la oportunidad de realizar un proyecto AGR.

• Afirmar y dar a conocer la voluntad de su realización por parte de la Dirección.

• Crear las condiciones humanas y materiales para el buen desarrollo del proyecto.

Este proceso se desarrolla por medio de las siguientes actividades y tareas:

Actividad A1.1: Estudio de oportunidad Se fundamenta la oportunidad de la realización, ahora, del proyecto AGR, enmarcándolo en el desarrollo de las demás actividades de la Organización.

El resultado de esta actividad es el informe denominado “preliminar”.

Tareas:

Tarea T1.1.1: Determinar la oportunidad

Actividad A1.2: Determinación del alcance del proyecto Se definen los objetivos finales del proyecto, su dominio y sus límites. Se realiza una prime-ra identificación del entorno y de las restricciones generales a considerar. Y por último se es-tima el coste que va a suponer.

El resultado de esta actividad es un perfil de proyecto AGR.

Tareas:

Tarea T1.2.1: Objetivos y restricciones generales

Tarea T1.2.2: Determinación del dominio y límites

Tarea T1.2.3: Identificación del entorno

Tarea T1.2.4: Estimación de dimensiones y coste

Actividad A1.3: Planificación del proyecto Se determinan las cargas de trabajo que supone la realización del proyecto. Se planifican las entrevistas que se van a realizar para la recogida de información: quiénes van a ser en-trevistados. 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 AGR

• procedimientos de gestión de la información generada

Tareas:

Tarea T1.3.1: Evaluar cargas y planificar entrevistas

Tarea T1.3.2: Organizar a los participantes

Tarea T1.3.3: Planificar el trabajo



Actividad A1.4: Lanzamiento del proyecto Se adaptan los cuestionarios para la recogida de información adaptándolos al proyecto pre-sente. Se eligen las técnicas principales de evaluación de riesgo a utilizar y se asignan los recursos necesarios para el comienzo del proyecto. También se realiza una campaña infor-mativa de sensibilización a los afectados sobre las finalidades y requerimientos de su parti-cipación.

El resultado de esta actividad está constituido por:

• los cuestionarios para las entrevistas

• el plan de entrevistas

• el catálogo de tipos de activos

• la relación de dimensiones de seguridad y

• los criterios de valoración

Tareas:

Tarea T1.4.1: Adaptar los cuestionarios

Tarea T1.4.2: Criterios de evaluación

Tarea T1.4.3: Recursos necesarios

Tarea T1.4.4: Sensibilización



3.3.1. Actividad A1.1: Estudio de oportunidad Consta de una única tarea:

T1.1.1: Determinar la oportunidad

P1: Planificación A1.1: Estudio de oportunidad T1.1.1: 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 AGR

Productos de entrada

Productos de salida • Informe preliminar recomendando la elaboración del proyecto AGR

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

• Creación del comité de seguimiento Técnicas, prácticas y pautas

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

• Reuniones (ver "Guía de Técnicas" 3.6.2) Participantes

• El promotor

La Dirección suele ser muy consciente de las ventajas que aportan las técnicas electrónicas, in-formáticas y telemáticas a su funcionamiento; pero no tanto de los nuevos problemas de seguri-dad 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 cre-ciente preocupación por la falta de seguridad de los sistemas de información, por su soporte y en-torno, 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 AGR parte de un promotor interno o externo a la Organización, consciente de los problemas relacionados con la seguridad de los sistemas de in-formació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 sis-temas 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 seguri-dad 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 AGR33. Esta aproximación de alto nivel permite obtener una primera visión de los objetivos concretos y las opciones que ten-drían que subyacer a la elaboración del proyecto.

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 anterio-res.

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 servi-cios y los productos implicados en cuestiones de seguridad de los sistemas de información, la ubi-cació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 AGR 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 AGR.

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.

33 Probablemente no se conozca lo que esto significa y haya que incluir en el cuestionario marco una sucin-

ta explicación de qué es y qué objetivos persigue un proyecto AGR.



3.3.2. Actividad A1.2: Determinación del alcance del proyecto Una vez que se ha constatado la oportunidad de realizar el proyecto AGR y el apoyo por la Direc-ció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 pue-den ser afectadas o en la Organización) y el plazo de tiempo considerado para la puesta en prác-tica del proyecto AGR. En particular, la existencia de un Plan Estratégico de Sistemas de Informa-ció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.

Esta actividad consta de cuatro tareas:

T1.2.1: Objetivos y restricciones generales

T1.2.2: Determinación del dominio y límites

T1.2.3: Identificación del entorno

T1.2.4: Estimación de dimensiones y coste

P1: Planificación A1.2: Determinación del alcance del proyecto T1.2.1: Objetivos y restricciones generales 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 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 Técnicas, prácticas y pautas



• El comité de seguimiento

Un proyecto AGR 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 fue-ra 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 va-le”, sino que el proyecto se encontrará con una serie de restricciones, no necesariamente técni-cas, que establecen un marco al que atenerse. Para incorporar las restricciones al análisis y ges-tió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 interna-cional, cambio de la propiedad, reingeniería de procesos, etc.

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 profesiona-les, 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 ejecu-tar el presupuesto



P1: Planificación A1.2: Determinación del alcance del proyecto T1.2.2: Determinación del dominio y límites Objetivos

• Determinar el dominio, alcance o perímetro del proyecto AGR Productos de entrada

• Resultados de la tarea T1.2.1, Objetivos y restricciones generales

• Perfil general de las unidades incluidas en el dominio del proyecto Productos de salida

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

• Lista de roles relevantes en la unidades incluidas en el dominio

• Designación del director del proyecto Técnicas, prácticas y pautas

• Diagramas de procesos (ver "Guía de Técnicas" 3.3) Participantes

• Responsables de las unidades de la Organización


Esta tarea identifica las unidades objeto del proyecto AGR y especifica las características genera-les 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 do-minio 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.



P1: Planificación A1.2: Determinación del alcance del proyecto T1.2.3: Identificación del entorno Objetivos

• Definir el perímetro del dominio

• Definir las relaciones entre el interior del dominio y el entorno Productos de entrada

• Resultados de la tarea T1.2.1, Objetivos y restricciones generales

• Resultados de la tarea T1.2.2, Determinación del dominio y límites

• Esquema de las relaciones de las unidades del dominio con el entorno

• Diagramas de flujo de datos Productos de salida

• Relación de unidades de la Organización que se verán afectadas como perímetro del domi-nio

• Lista de roles relevantes en otras unidades, a considerar para la caracterización del entor-no

Técnicas, prácticas y pautas • Diagramas de flujo de datos (ver "Guía de Técnicas" 3.2)

• Diagramas de procesos (ver "Guía de Técnicas" 3.3)



• Responsables de las unidades incluidas en el dominio


Esta tarea realiza un estudio global de los sistemas de información de las unidades incluidas en el dominio del proyecto, con objeto de identificar sus funciones y finalidades principales y sus rela-ciones con el entorno, así como sus tendencias de evolución. El perfil general de las unidades, producto obtenido en la tarea anterior, se amplia en ésta con la información proporcionada por los responsables de las diversas áreas de dichas unidades.



P1: Planificación A1.2: Determinación del alcance del proyecto T1.2.4: Estimación de dimensiones y coste Objetivos

• Determinar el volumen de recursos necesarios para la ejecución del proyecto AGR: huma-nos, temporales y financieros

Productos de entrada • Resultados de la tarea T1.2.1, Objetivos y restricciones generales

• Resultados de la tarea T1.2.2, Determinación del dominio y límites

• Resultados de la tarea T1.2.3, Identificación del entorno Productos de salida

• Dimensión del proyecto

• Costes y beneficios del proyecto Técnicas, prácticas y pautas

• Análisis coste-beneficio (ver "Guía de Técnicas" 3.1)

• Planificación de proyectos (ver "Guía de Técnicas" 3.5) Participantes

• El director de proyecto

La tarea posibilita el dimensionamiento (tamaño, complejidad, zonas de incertidumbre) del proyec-to a partir del conocimiento de los objetivos del proyecto, del dominio y del perfil de las unidades incluidas en el estudio. En función de la dimensión estimada y de los objetivos del proyecto se es-cogen algunas de las técnicas a utilizar en el proyecto. Por ejemplo, si el proyecto tiene como ob-jetivo la realización de un análisis inicial genérico, la técnica de cálculo del riesgo se orienta a una discriminación dicotómica (en dos bloques) de los riesgos, según que exijan o no otras aplicacio-nes más detalladas de análisis.

Por otra parte la tarea también dimensiona el proyecto en cuanto a su coste y los retornos o bene-ficios que puede aportar, para que la Dirección pueda tomar con fundamento la decisión de em-prenderlo y asignar los recursos necesarios para su desarrollo.

• El estudio del coste del proyecto se realiza estimando los tiempos y perfiles de personal asignado a las etapas del proyecto dimensionado anteriormente.

• El estudio de los retornos sólo puede ser muy impreciso en este proceso inicial, pues no puede tener en cuenta aún el verdadero retorno de un proyecto de seguridad, que es preci-samente el coste de no tener dicha seguridad en el dominio estudiado o sea el resultado del propio proyecto AGR.



3.3.3. Actividad A1.3: Planificación del proyecto En esta actividad se determinan los participantes en el proyecto, determinando sus cargas de tra-bajo, su estructuración en grupos y su modo de actuación.

Esta actividad consta de tres tareas:

T1.3.1: Evaluar cargas y planificar entrevistas

T1.3.2: Organizar a los participantes

T1.3.3: Planificar el trabajo

P1: Planificación A1.3: Planificación del proyecto T1.3.1: Evaluar cargas y planificar entrevistas Objetivos

• Definir los grupos de interlocutores: usuarios afectados en cada unidad

• Planificar las entrevistas de recogida de información 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 cargas Técnicas, prácticas y pautas


• El director de proyecto


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.



P1: Planificación A1.3: Planificación del proyecto T1.3.2: Organizar a los participantes Objetivos

• Determinar los órganos participantes en la gestión, realización, seguimiento y manteni-miento del proyecto

• Definir las funciones y responsabilidades de los órganos participantes

• Establecer las reglas y los modos operativos

• Establecer la clasificación de la información generada

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

Productos de salida • Formalización del comité de dirección

• Formalización del comité de seguimiento

• Criterios y procedimientos de clasificación y gestión de la información generada

• Designación del enlace operacional

• Creación del equipo de trabajo Técnicas, prácticas y pautas

No aplica Participantes

• Comité de seguimiento

• Director del proyecto

Aunque todos los proyectos AGR involucran básicamente a los mismos comités, en esta tarea se concreta la aproximación genérica al caso particular, pudiendo atenerse al caso general, o particu-larizar.

Es particularmente relevante determinar la clasificación de los documentos que se produzcan a lo largo del proyecto. Si existe una norma de clasificación, conviene atenerse a ella para aprovechar procedimientos ya establecidos de tratamiento de los documentos. Si no existiera, es necesario elaborar tanto los criterios de clasificación como los procedimientos de tratamiento. La calificación por defecto será “confidencial”, siendo particularmente importante preservar la confidencialidad de los documentos de evaluación de salvaguardas y de insuficiencias.



P1: Planificación A1.3: Planificación del proyecto T1.3.3: Planificar el trabajo Objetivos

• 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 modifi-caciones en los objetivos marcados, etc.

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

• Resultados de la tarea T1.3.1, Evaluar cargas y planificar entrevistas

• Resultados de la tarea T1.3.2, Organizar a los participantes Productos de salida

• Cronograma del proyecto

• Dedicaciones de los participantes

• Especificación de los recursos materiales necesarios

• Descripción de hitos Técnicas, prácticas y pautas


• El equipo de proyecto



3.3.4. Actividad A1.4: Lanzamiento del proyecto Esta actividad completa las tareas preparatorias del lanzamiento del proyecto: empezando por se-leccionar y adaptar los cuestionarios que se utilizarán en la recogida de datos, así como especifi-car los criterios y las técnicas concretas a emplear; y terminando por asignar los recursos necesa-rios para la realización del proyecto y por realizar la campaña informativa de sensibilización a los implicados.

Esta actividad consta de cuatro tareas:

T1.4.1: Adaptar los cuestionarios

T1.4.2: Criterios de evaluación

T1.4.3: Recursos necesarios

T1.4.4: Sensibilización

P1: Planificación A1.4: Lanzamiento del proyecto T1.4.1: Adaptar los cuestionarios Objetivos

• Identificar la información relevante a obtener, agrupada de acuerdo a la estructura de uni-dades y roles de los participantes

Productos de entrada • Resultados de la actividad A1.3, Planificación del proyecto

Productos de salida • Cuestionarios adaptados

Técnicas, prácticas y pautas • Cuestionarios (ver "Catálogo de Elementos" en general y el apéndice 2 en particular)

Participantes • El equipo de proyecto

La tarea adapta los cuestionarios a utilizar en la recogida de información en el proceso P1 en fun-ció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 de-pende 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 seguri-dad, que para cuestionarios auto administrados por el responsable del dominio o por los usuarios de sus sistemas de información.



P1: Planificación A1.4: Lanzamiento del proyecto T1.4.2: Criterios de evaluación Objetivos

• 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 Productos de entrada

• Catálogo de elementos

• Resultados de la actividad A1.3, Planificación del proyecto Productos de salida

• Catálogo de tipos de activos

• Relación de dimensiones de seguridad

• Criterios de valoración Técnicas, prácticas y pautas

• Ver "Catálogo de Elementos" capítulos 2, 3 y 4 Participantes


Esta tarea, preparatoria del proceso P2 (análisis de riesgos), establece la selección de los criterios y técnicas que se mantendrán a lo largo de todo el proceso. En efecto, la gestión de los riesgos del proceso P3 estará condicionada por el tipo de análisis realizado en el proceso P2: si se han elegido un tipo de criterios y técnicas para evaluar los riesgos, es recomendable aplicar las mis-mas técnicas para evaluar la reducción de riesgos al implantar las salvaguardas propuestas. La elección de estos criterios y técnicas en función de:

• los objetivos del proyecto (T1.2.1)

• el dominio del proyecto (T1.2.2)

Se recomienda atenerse a lo propuesto en el libro “Catálogo de Elementos” anejo a esta guía.



P1: Planificación A1.4: Lanzamiento del proyecto T1.4.3: Recursos necesarios Objetivos

• Asignar los recursos necesarios (humanos, de organización, técnicos, etc.) para la realiza-ción del proyecto AGR

Productos de entrada • Resultados de la actividad A1.3, Planificación del proyecto

Productos de salida • Comunicaciones al personal participante de su asignación al proyecto

• Disponibilidad de los medios materiales necesarios Técnicas, prácticas y pautas





P1: Planificación A1.4: Lanzamiento del proyecto T1.4.4: Sensibilización Objetivos

• Informar a las unidades afectadas

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

• Resultados de la actividad A1.3, Planificación del proyecto Productos de salida

• Nota informativa de la dirección

• Material e informe de presentación del proyecto Técnicas, prácticas y pautas

• Presentaciones (ver "Guía de Técnicas" 3.6.3) Participantes

• El director del proyecto


• El enlace operacional


Esta tarea informa a las unidades afectadas del lanzamiento del proyecto AGR, por diversos me-dios, y como mínimo:

• Una nota informativa de la Dirección, dirigida a las unidades implicadas y declarando su apoyo a la realización del proyecto.

• La presentación del proyecto, sus objetivos y la metodología a emplear, realizada en las unidades implicadas por parte del equipo de proyecto.



3.3.5. Síntesis del proceso P1

3.3.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 AGR, basándose en el estudio de oportunidad realizado por el promotor.

Hito de control H1.2: El comité director del proyecto validará el informe de "Planificación del Proyecto de Análisis y Gestión de Riesgos" que contendrá una síntesis de los productos obtenidos en las activi-dades realizadas en el proceso P1.

3.3.5.2. Resultados

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 funcio-nales, 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.).

Documentación final • Tipología de activos

• Dimensiones de seguridad relevantes

• Criterios de evaluación

• Informe de "Planificación del Proyecto de Análisis y Gestión de riesgos" que contendrá una síntesis de los productos obtenidos en las actividades realizadas en el proceso P1.

3.3.6. Lista de control34 del proceso P1 Organización del proyecto:

√ Aprobación de la Dirección (P1)

√ Compromiso explícito de la Dirección (P1)

√ Apoyo de la Dirección (P1)

√ Comité de seguimiento (T1.3.2)

√ Equipo de proyecto (T1.3.2)

√ Director de proyecto (T1.2.2)

√ Enlace operacional (T1.3.2)

34 Esta lista permite comprobar que se han alcanzado todos los objetivos, subobjetivos y productos de sali-

da detallados en las diferentes tareas.



√ Grupos de interlocutores (T1.3.1)

√ Funciones y método de trabajo (T1.3.2)

√ Criterios de clasificación de la documentación y procedimientos para tratarla (T1.3.2)

Planificación del proyecto:

√ Informe preliminar recomendando y justificando la oportunidad de lanzar un proyecto AGR (T1.1.1)

√ Objetivos expresos y no ambiguos (T1.2.1)

√ Estimación de dimensiones y coste (T1.2.4)

√ Plan de entrevistas: personas y fechas (T1.4.3)

√ Plan de trabajo: hitos (T1.3.3)

√ Asignación de recursos (T1.4.3)

√ Sensibilización de la Organización (T1.4.4)

√ Plan de Proyecto de Análisis y Gestión de Riesgos (P1)

Aspectos técnicos:

√ Limitaciones generales del proyecto (T1.2.1)

√ Dominio del proyecto: unidades incluidas en el análisis (T1.2.2)

√ Entorno del proyecto: otras unidades relacionadas de alguna forma (T1.2.3)

√ Cuestionarios adaptados (T1.4.1)

√ Catálogo de tipos de activos (T1.4.2)

√ Relación de dimensiones de seguridad relevantes (T1.4.2)

√ Criterios de evaluación (T1.4.2)



3.4. Proceso P2: Análisis de riesgos Este proceso es el núcleo central de Magerit y su correcta aplicación condiciona la validez y utili-dad de todo el proyecto. La identificación y estimación de los activos y de las posibles amenazas que les acechan representa una tarea compleja.

Este proceso 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 salva-guardas), como el impacto residual (incluyendo el efecto de las salvaguardas implementa-das si se trata de un sistema actual, no de un sistema previsto).

• Evaluar el riesgo del sistema en estudio, tanto el riesgo potencial (sin salvaguardas), como el riesgo residual (incluyendo el efecto de las salvaguardas implementadas si se trata de un sistema actual, no de un sistema previsto).

• Mostrar al comité director las áreas del sistema con mayor impacto y/o riesgo.

El punto de partida de este proceso es la documentación del anterior referente a los objetivos del proyecto, los planes de entrevistas, la evaluación de cargas, la composición y reglas de actuación del equipo de participantes, el plan de trabajo y el informe de presentación del proyecto.


Actividad 2.1: Caracterización de los activos Esta actividad busca identificar los activos relevantes dentro del sistema a analizar, caracte-rizándolos por el tipo de activo, identificando las relaciones entre los diferentes activos, de-terminando en qué dimensiones de seguridad son importantes y valorando esta importancia.

El resultado de esta actividad es el informe denominado “modelo de valor”.

Tareas:

Tarea T2.1.1: Identificación de los activos

Tarea T2.2.2: Dependencias entre activos

Tarea T2.3.3: Valoración de los activos

Actividad 2.2: Caracterización de las amenazas Esta actividad busca identificar las amenazas relevantes sobre el sistema a analizar, carac-terizándolas por la frecuencia estimada de ocurrencia y la estimación de daño (degradación) que causarían sobre los activos.

El resultado de esta actividad es el informe denominado “mapa de riesgos”.

Tareas:

Tarea T2.2.1: Identificación de las amenazas

Tarea T2.2.2: Valoración de las amenazas

Actividad 2.3: Caracterización de las salvaguardas Esta actividad busca identificar las salvaguardas desplegadas en el sistema a analizar, cali-ficándolas por su eficacia frente a las amenazas que pretenden mitigar.

El resultado de esta actividad es el informe denominado “evaluación de salvaguardas”.

Tareas:



Tarea T2.3.1: Identificación de las salvaguardas existentes

Tarea T2.3.2: Valoración de las salvaguardas existentes

Actividad 2.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 sal-vaguardas

Tareas:

Tarea T2.4.1: Estimación del impacto

Tarea T2.4.2: Estimación del riesgo

Tarea T2.4.3: Interpretación de los resultados



3.4.1. Actividad A2.1: Caracterización de los activos Esta actividad consta de tres tareas:

T2.1.1: Identificación de los activos

T2.1.2: Dependencias entre activos

T2.1.3: Valoración de los activos

El objetivo de estas tareas es reconocer los activos que componen los procesos, y definir las de-pendencias entre ellos. Así y a partir de la información recopilada en la actividad anterior, esta ac-tividad profundiza el estudio de las activos con vistas a obtener la información necesaria para rea-lizar las estimaciones de riesgo.

Es frecuente que las tareas relacionadas con los activos se realicen concurrentemente con las ta-reas relacionadas con las amenazas sobre dichos activos (A2.2) e identificación de las salvaguar-das actuales (A2.3), simplemente porque suelen coincidir las personas y es difícil que el interlocu-tor no tienda de forma natural a tratar cada activo “verticalmente”, viendo todo lo que le afecta an-tes de pasar al siguiente.



P2: Análisis de riesgos A2.1: Caracterización de los activos T2.1.1: Identificación de los activos Objetivos

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

Productos de entrada • Inventarios de datos manejados por la Organización

• Procesos de negocio

• Diagramas de uso

• Diagramas de flujo de datos

• Inventarios de equipamiento lógico

• Inventarios de equipamiento físico

• Caracterización funcional de los puestos de trabajo

• Locales y sedes de la Organización Productos de salida

• Relación de activos a considerar

• Caracterización de los activos Técnicas, prácticas y pautas

• Diagramas de flujo de datos (ver "Guía de Técnicas" 3.2)



• Reuniones (ver "Guía de Técnicas" 3.6.2)

• Ver también la sección 2.1.1. Participantes


• Los grupos de interlocutores

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

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 aplicacio-nes 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



P2: Análisis de riesgos A2.1: Caracterización de los activos T2.1.2: 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 (ver "Guía de Técnicas" 3.2)




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




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



P2: Análisis de riesgos A2.1: Caracterización de los activos T2.1.3: 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 T1.4.2, Criterios de evaluación

• Resultados de la tarea T2.1.1, Identificación de los activos

• Resultados de la tarea T2.1.2, Dependencias entre activos Productos de salida

• Modelo de valor: informe de valor de los activos Técnicas, prácticas y pautas








• La dirección

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 servicios, que conocen las consecuencias de la no prestación del servi-cio o de su prestación degradada

• responsables de los datos, que conocen las consecuencias de la degradación de los datos

• 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.4.2. Actividad A2.2: Caracterización de las amenazas Esta actividad suele discurrir de forma concurrente con las actividades A2.1 y A.2.3 dado que los responsables a entrevistar son los mismos.

Esta actividad consta de dos tareas:

T2.2.1: Identificación de las amenazas

T2.2.2: Valoración de las amenazas

P2: Análisis de riesgos A2.2: Caracterización de las amenazas T2.2.1: Identificación de las amenazas Objetivos

• Identificar las amenazas relevantes sobre cada activo Productos de entrada

• Resultados de la tarea T1.4.2, Criterios de evaluación

• Resultados de la actividad A2.1, Caracterización de los activos Productos de salida

• Relación de amenazas posibles Técnicas, prácticas y pautas

• Catálogos de amenazas (ver "Catálogo de Elementos", capítulo 5)

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






• los grupos de interlocutores

En esta tarea se identifican las amenazas significativas sobre los activos identificados, tomando en consideración:

• el tipo de activo

• las dimensiones en que el activo es valioso

• la experiencia de la Organización

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

• explicación del efecto de la amenaza


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



P2: Análisis de riesgos A2.2: Caracterización de las amenazas T2.2.2: 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 T1.4.2, Criterios de evaluación

• Resultados de la tarea T2.2.1, Identificación de las amenazas

• Series históricas de incidentes

• Antecedentes: incidentes en la Organización Productos de salida

• Mapa de riesgos: informe de amenazas posibles, caracterizadas por su frecuencia de ocu-rrencia 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" 2.3)







En esta tarea se valoran las amenazas identificadas en la tarea anterior, tomando en considera-ció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

Sabiendo que existen una serie de posibles agravantes, como se describe en la sección X.

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.4.3. Actividad A2.3: Caracterización de las salvaguardas Esta actividad suele discurrir de forma concurrente con las actividades A2.1 y A2.2 dado que los responsables a entrevistar son los mismos.


T2.3.1: Identificación de las salvaguardas existentes

T2.3.2: Valoración de las salvaguardas existentes

P2: Análisis de riesgos A2.3: Caracterización de las salvaguardas T2.3.1: Identificación de las salvaguardas existentes Objetivos

• Identificar las salvaguardas, de cualquier tipo, que se han previsto y desplegado a fecha de realización del estudio

Productos de entrada • Inventario de procedimientos operativos

• Inventario de productos y/o desarrollos hardware o software de soporte a la seguridad de los sistemas

• Plan de formación

• Definición de los puestos laborales

• Contratos

• Acuerdos de externalización de servicios Productos de salida

• Relación de salvaguardas desplegadas Técnicas, prácticas y pautas

• Catálogos de salvaguardas (ver "Catálogo de Elementos" capítulo 6)

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






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



P2: Análisis de riesgos A2.3: Caracterización de las salvaguardas T2.3.2: Valoración de las salvaguardas existentes Objetivos

• Determinar la eficacia de las salvaguardas desplegadas Productos de entrada

• Inventario de salvaguardas (Catálogo de Elementos) Productos de salida

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

Técnicas, prácticas y pautas • Entrevistas (ver "Guía de Técnicas" 3.6.1)






• Especialistas en salvaguardas concretas

En esta tarea se valora la efectividad de las salvaguardas identificadas en la tarea anterior, to-mando 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




3.4.4. Actividad A2.4: Estimación del estado de riesgo En esta actividad se combinan los descubrimientos de las actividades anteriores (A2.1, A2.2 y A2.3) para derivar estimaciones del estado de riesgo de la Organización.

Esta actividad consta de tres tareas:

T2.4.1: Estimación del impacto

T2.4.2: Estimación del riesgo

T2.4.3: Interpretación de los resultados

P2: Análisis de riesgos A2.4: Estimación del estado de riesgo T2.4.1: 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 A2.1, Caracterización de los activos

• Resultados de la actividad A2.2, Caracterización de las amenazas

• Resultados de la actividad A2.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" 2.1)

• Análisis algorítmico (ver "Guía de Técnicas" 2.2)

• Ver también la sección 2.1.3 y 2.1.6. Participantes


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 acti-vos 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 acti-vos y la valoración de las amenazas, así como la eficacia de las salvaguardas actualmente desplegadas



P2: Análisis de riesgos A2.4: Estimación del estado de riesgo T2.4.2: 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 A2.1, Caracterización de los activos


• Resultados de la actividad A2.3, Caracterización de las salvaguardas 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" 2.1)

• Análisis algorítmico (ver "Guía de Técnicas" 2.2)



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 acti-vos 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 des-plegadas



P2: Análisis de riesgos A2.4: Estimación del estado de riesgo T2.4.3: Interpretación de los resultados Objetivos

• Interpretar los resultados anteriores de impacto y riesgo

• Establecer relaciones de prioridad por activos o grupos de activos, bien por orden de im-pacto o por orden de riesgo

Productos de entrada • Resultados de la actividad A2.1, Caracterización de los activos


• Resultados de la actividad A2.3, Caracterización de las salvaguardas

• Resultados de la tarea T2.4.1, Estimación del impacto

• Resultados de la tarea T2.4.2, Estimación del riesgo Productos de salida

• Informe priorizado de activos sometidos a mayor impacto

• Informe priorizado de activos sometidos a mayor riesgo

• Estado de riesgo: informe resumen del impacto y riesgo potencial y residual a que está sometido cada activo del dominio

• Informe de insuficiencias: informe que destaca las incoherencias entre las salvaguardas que se necesitan y las que existen y las divergencias entre la magnitud del riesgo y la efi-cacia actual de las salvaguardas

Técnicas, prácticas y pautas • Técnicas gráficas (ver "Guía de Técnicas" 3.4)


• Presentaciones (ver "Guía de Técnicas" 3.6.3)








Aceptación del informe “Modelo de Valor”.

Hito de control H2.2: Aceptación del informe “Mapa de Riesgos”.

Hito de control H2.3: Aceptación del informe “Evaluación de Salvaguardas”.

Hito de control H2.4: Aceptación del informe “Estado de Riesgo”.

Hito de control H2.5: Aceptación del informe “Informe de Insuficiencias”.

3.4.5.2. Resultados

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 funcio-nales, cuadernos de carga, manuales de usuario, manuales de explotación, diagramas de flujo de información y de procesos, modelos de datos, etc.

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 acti-vo.

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

• Estado de riesgo: Informe que detalla para cada activo el impacto y el riesgo residuales frente a cada amena-za.

• Informe de insuficiencias: Informe que detalla las salvaguardas necesarias pero ausentes o insuficientemente eficaces.

Esta documentación es un fiel reflejo del estado de riesgo y de las razones por la que este riesgo no es despreciable. Es fundamental entender las razones que llevan a una valoración determina-



da de riesgo como paso previo al proceso siguiente, P3, que buscará atajar el riesgo o reducirlo a niveles aceptables.

3.4.6. Lista de control del proceso P2 √ Identificación de activos (T2.1.1)

√ Caracterización de los activos (T2.1.1)

√ Dependencias entre activos (T2.1.2)

√ Dimensiones relevantes de seguridad por activo (T2.1.3)

√ Valoración de los activos (T2.1.3)

√ Modelo de valor (A2.1)

√ Identificación de las amenazas relevantes (T2.2.1)

√ Estimación de la frecuencia de ocurrencia (T2.2.2)

√ Estimación del daño (degradación) derivado de la materialización de una amenaza (T2.2.2)

√ Mapa de riesgos (A2.2)

√ Identificación de las salvaguardas existentes (T2.3.1)

√ Estimación de la eficacia de las salvaguardas existentes (T2.3.2)

√ Evaluación de salvaguardas (A2.3)

√ Estimación del impacto e impacto residual (T2.4.1)

√ Estimación del riesgo y riesgo residual (T2.4.2)

√ Estado de riesgo (P2)

√ Informe de insuficiencias (P2)



3.5. Proceso P3: Gestión de riesgos Se procesan los impactos y riesgos identificados en el proceso anterior, bien asumiéndolos, bien afrontándolos. Para afrontar los riesgos que se consideren inaceptables se llevará a cabo un plan de seguridad que corrija la situación actual. Un plan de seguridad se materializa en una colección de programas de seguridad. Algunos programas serán sencillos, mientras que otros alcanzarán suficiente nivel de complejidad y coste como para que su ejecución se convierta en un proyecto propiamente dicho. La serie de programas (y, en su caso, proyectos) se planifica en el tiempo por medio del denominado Plan de Seguridad que ordena y organiza las actuaciones encaminadas a llevar el estado de riesgo a un punto aceptable y aceptado por la Dirección.


Actividad A3.1: Toma de decisiones En esta actividad se traducen las conclusiones técnicas del proceso P2 en decisiones de ac-tuación.

Tareas:

Tarea T3.1.1: Calificación de los riesgos

Actividad A3.2: Plan de seguridad En esta actividad se traducen las decisiones de actuación en acciones concretas: proyectos de mejora de la seguridad planificados en el tiempo.

Tareas:

Tarea T3.2.1: Programas de seguridad

Tarea T3.2.2: Plan de ejecución

Actividad A3.3: Ejecución del plan Esta actividad recoge la serie de proyectos que materializan el plan de seguridad y que se van realizando según dicho plan.

Tareas:

Tarea T3.3.*: Ejecución de cada programa de seguridad



3.5.1. Actividad A3.1: Toma de decisiones Esta actividad consta de una sola tarea:

T3.1.1: Calificación de los riesgos

P3: Gestión de riesgos A3.1: Toma de decisiones T3.1.1: Calificación de los riesgos Objetivos

• Calificar los riesgos en una escala: crítico, grave, apreciable o asumible Productos de entrada

• Resultados del proceso P2, Análisis de riesgos

• Legislación aplicable, leyes y jurisprudencia

• Reglamentación sectorial

• Acuerdos y contratos

• Informes medio ambientales

• Estudios de mercado Productos de salida

• Informe de calificación de impactos y riesgos, incluyendo directrices acerca del plazo de tiempo en que deben estar resueltos

Técnicas, prácticas y pautas • Reuniones (ver "Guía de Técnicas" 3.6.2)





• El comité de dirección

A la vista de los impactos y riesgos a que está expuesto el sistema, hay que tomar una serie de decisiones de tipo gerencial, no técnico, 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 adi-cionales sobre la capacidad de la Organización para aceptar ciertos impactos de naturaleza intan-gible35 tales como:

• imagen pública de cara a la Sociedad

35 La metodología de análisis y gestión de riesgos, al centrarse en la evaluación de daños, no captura ple-

namente 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.



• 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 in-crementar la oferta, capacidad de diferenciarse frente a la competencia, ...

• relaciones con otras organizaciones, tales como capacidad de alcanzar acuerdos estratégi-cos, 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 justi-ficación. Las razones que pueden llevar a esta aceptación son:

• cuando el impacto residual es despreciable

• cuando el riesgo residual es despreciable

• cuando el coste de las salvaguardas oportunas es desproporcionado en comparación al im-pacto y riesgo residuales

Todas las decisiones son propuestas por el comité de seguimiento, oída la opinión del director del proyecto. Todas las decisiones son adoptadas por el comité de dirección.

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



3.5.2. Actividad A3.2: Elaboración del plan seguridad de la información Se traducen las decisiones de actuación en acciones concretas.


T3.2.1: Programas de seguridad

T3.2.2: Plan de ejecución

P3: Gestión de riesgos A3.2: Elaboración del plan de seguridad de la información T3.2.1: Programas de seguridad Objetivos

• Elaborar un conjunto de programas de seguridad Productos de entrada

• Resultados de la tarea T3.1.1, Calificación de los 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

• Análisis de riesgos (ver proceso P2)

• Análisis coste-beneficio (ver "Guía de Técnicas" 3.1)

• Planificación de proyectos (ver "Guía de Técnicas" 3.5)



• Especialistas en seguridad

• Especialistas en áreas específicas de seguridad

Básicamente, se llevan a cabo dos pasos:

1. Se tomarán en consideración todos los escenarios de impacto y riesgo que se consideren críticos o graves como resultado de la tarea anterior.

2. Se elaborará un conjunto de programas de seguridad que den respuesta a todos y cada uno de los escenarios anteriores, sabiendo que un mismo programa puede afrontar diferentes escenarios y que un escenario puede ser abordado por diferentes programas.

En última instancia se trata de implantar o mejorar la implantación de una serie de salvaguardas que lleven impacto y riesgo a niveles residuales asumidos 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 convenien-cia, 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.

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 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 pro-yecto 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



P3: Gestión de riesgos A3.2: Elaboración del plan de seguridad de la información T3.2.2: Plan de ejecución Objetivos

• Ordenar temporalmente los programas de seguridad Productos de entrada

• Resultados de la tarea T3.1.1, Calificación de los riesgos

• Resultados de la tarea T3.2.1, Programas de seguridad Productos de salida

• Cronograma de ejecución del plan

• Plan de Seguridad Técnicas, prácticas y pautas



• Departamento de desarrollo

• Departamento de compras

Hay que ordenar en el tiempo los programas de seguridad teniendo en cuenta los siguientes facto-res:

• 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 contrac-tual, 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 en-tre 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, de-ntro 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 ma-terializan los programas de seguridad.



3.5.3. Actividad A3.3: Ejecución del plan Esta actividad consta de un número de tareas que depende del plan de seguridad determinado en la actividad A3.2, pues se trata de ir ejecutando los programas allí planificados.

Esta actividad consta de N tareas, tantas como se haya previsto en el plan de seguridad:

T3.3.*: Ejecución de cada programa de seguridad36

P3: Gestión de riesgos A3.3: Ejecución del plan T3.3.*: Ejecución de cada programa de seguridad Objetivos

• Alcanzar los objetivos previstos en el plan de seguridad para cada programa planificado Productos de entrada

• Resultados de la actividad A3.2, Plan de seguridad

• Programa de seguridad que nos ocupa

• Análisis de riesgos antes de la ejecución del plan Productos de salida

• Salvaguarda implantada

• Normas de uso y operación

• Sistema de indicadores de eficacia y eficiencia del desempeño de los objetivos de seguri-dad perseguidos

• Modelo de valor actualizado

• Mapa de riesgos actualizado

• Estado de riesgo actualizado (impacto y riesgo residuales). Técnicas, prácticas y pautas



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

• Personal especializado en la salvaguarda en cuestión

36 Esta actividad consta de un número indeterminado de tareas a determinar en cada proyecto. De ahí el

uno de la notación con *.





La Dirección procederá a la aprobación o no del Plan de Seguridad, incluyendo la relación de programas de seguridad y el cronograma propuesto para su ejecución.

Hito de control H3.*: Compleción de cada programa de seguridad, satisfaciendo los criterios de aceptación im-puestos en el Plan de Seguridad.

3.5.4.2. Resultados

Documentación intermedia • Decisiones de calificación de los escenarios de impacto y riesgo

Documentación final • Plan de Seguridad

3.5.5. Lista de control del proceso P3 √ Calificación de los riesgos (T3.1.1)

√ Identificación de los programas de seguridad necesarios (T3.2.1)

√ Programas de seguridad

√ objetivos

√ estimación de esfuerzo

√ estimación de coste

√ plan de aceptación

√ plan de operación

√ plan de mantenimiento

√ plan de formación

√ sistema de controles de eficacia

√ sistema de controles de eficiencia

√ estimación de impacto y riesgo residuales

√ Calendario de ejecución (T3.2.2)

√ Plan de seguridad estratégico: largo plazo (A3.2)

√ Plan de seguridad táctico: medio plazo (A3.2)

√ Planes operativos: proyectos singulares (A3.2)

Magerit versión 2 Desarrollo de sistemas de información


4. 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 fun-ciones y mecanismos que refuerzan la seguridad del nuevo sistema y del propio proceso de desa-rrollo, 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.

Se pueden identificar dos tipos de actividades diferenciadas:

• SSI: actividades relacionadas con la propia seguridad del sistema de información.

• SPD: actividades que velan por la seguridad del proceso de desarrollo del sistema de infor-mación.

Tras una primera exposición sobre el desarrollo de aplicaciones en general, la sección 4.5 profun-diza en su aplicación a Métrica versión 3. Métrica ha sido desarrollada por el CSAE como la “Me-todología de Planificación, Desarrollo y Mantenimiento de sistemas de información”.

4.1. Inicialización de los procesos Hay varias razones que pueden llevar a plantear el desarrollo de una nueva aplicación o la modifi-cación de una existente:

Nuevos servicios y/o datos. • Requiere el desarrollo de nuevas aplicaciones o la modificación de aplicaciones operati-

vas. Puede implicar la desaparición de aplicaciones 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 plata-formas de desarrollo, en las plataformas de explotación, en los servicios de explotación, en los servicios de comunicaciones, etc.

• Requiere el desarrollo de nuevas aplicaciones o la modificación de aplicaciones operati-vas. Puede implicar la desaparición de aplicaciones 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 aplicaciones operativas. Raramente implica el

desarrollo de nuevas aplicaciones o la desaparición de aplicaciones 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 co-municaciones pueden habilitar nuevas amenazas o convertir amenazas que eran desprecia-bles en el pasado en amenazas relevantes en el futuro.



• Típicamente requiere la modificación de aplicaciones operativas, bien en su codificación o, más frecuentemente, en sus condiciones de explotación. Raramente implica el desarrollo de nuevas aplicaciones o la desaparición de aplicaciones operativas.


Modificación de los criterios de calificación de riesgos. Puede venir inducido por criterios de calidad operativa, por novedades en la legislación aplicable, en la reglamentación secto-rial o por acuerdos o contratos con terceros.

• Típicamente requiere la modificación de aplicaciones operativas. Raramente implica el desarrollo de nuevas aplicaciones o la desaparición de aplicaciones operativas.


4.2. 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)

desarrollosubcontratado

desarrollopropio

aceptación

despliegue

operación mantenimiento

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 ante-rior, 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 fa-llo, 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.

4.2.1. Plan de sistemas Las aplicaciones informáticas son un componente de los sistemas de información. Es en el marco de un sistema de información donde las diferentes aplicaciones se empotran para hacerse cargo



de una fracción de los servicios requeridos. Un plan de sistemas determina el marco de desarrollo y explotación de las aplicaciones informáticas, concretamente:

Los servicios requeridos, tanto para los usuarios internos, como los servicios de soporte a usuarios o aplicaciones internas.

Los datos funcionales que se utilizan.

Las aplicaciones que gestionan dichos datos.

El equipamiento: ordenadores y servicios de comunicaciones.

Desde el punto de vista de seguridad, un plan de sistemas permite

• identificar y valorar los servicios esenciales

• identificar, clasificar y valorar los datos esenciales

• determinar la política de seguridad de la Organización; es decir:

• el contexto legal en el que opera la Organización

• los criterios de excelencia en la prestación de los servicios

• los roles del personal relacionado con los sistemas de información

El plan de sistemas permite establecer el modelo de valor; es decir, los grandes epígrafes (acti-vos) y las primeras valoraciones de lo que acabará siendo un análisis de riesgos detallado.

4.3. Análisis de riesgos Como parte de un sistema de información, los riesgos asociados a una aplicación deben ser co-nocidos y estar gestionados. Tanto si son riesgos soportados por la aplicación, o son riesgos re-percutidos sobre activos superiores, o son riesgos acumulados sobre activos inferiores.

Magerit permite modelar directamente la aplicación como un activo, estableciendo sus dependen-cias, bien de activos superiores que dependen de ella, bien de activos inferiores que la soportan. El método permite identificar y valorar amenazas y salvaguardas, derivando información de impac-to y riesgo sobre la propia aplicación y los activos relacionados con ella.

AGR autocontenido. Si la Organización no ha realizado un proyecto AGR, será preciso llevar-lo a cabo incorporando al menos los activos directa o indirectamente relacionados con la aplicación.

AGR marginal. Si la Organización ya ha realizado un proyecto AGR, basta revisar los resulta-dos de dicho proyecto incorporando los nuevos activos. La aparición de una nueva aplica-ción puede implicar nuevos servicios, nuevos datos, nuevo equipamiento, nuevos locales y nuevo personal. También puede implicar la desaparición de antiguos activos que se ven su-perados por la nueva aplicación y sus posibilidades. En cada caso concreto hay que deter-minar lo que hay que añadir y lo que hay que eliminar, siguiendo las actividades A2.1, A2.2 y A2.3 del proceso P2, Análisis de riesgos.

Tanto si se ha seguido una u otra aproximación, al final se dispone de una relación de impactos y riesgos, tanto sobre la aplicación como sobre su entorno. Para derivar estos datos se siguen los pasos de la actividad A2.4 del proceso P2. Para interpretar los resultados se recurre a la tarea A2.4.3 del proceso P2, interpretación de los resultados.

4.4. Gestión de riesgos El proceso P3 de gestión de riesgos recomienda salvaguardas y evalúa el efecto de las salva-guardas desplegadas sobre el impacto y el 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. No obstante, este capítulo se centra en las me-didas que deben aplicarse a las aplicaciones para que estas no menoscaben la seguridad del sis-tema.

Siempre dirigidos por la iniciativa y la corroboración del proceso de gestión de riesgos, hay que tener en cuenta los siguientes aspectos:

Durante la especificación: • Dimensionado

• Perfiles de usuario

• Requisitos de identificación y autenticación de usuarios

• Requisitos de cifrado

• Requisitos de monitorización (control) y registro (log):

• de datos de entrada

• de datos de salida

• de datos intermedios

• de acceso a la aplicación

• de actividad (uso)

Si se adquiere software estándar ... • Contratos de adquisición y mantenimiento

Si se subcontrata el desarrollo de software ... • Contratos de adquisición y mantenimiento

• Entorno de desarrollo: locales, personas, plataforma y herramientas

• Técnicas de programación segura

• Gestión de código fuente

• control de acceso

• control de versiones

Si se desarrolla software en casa ... • Condiciones de mantenimiento

• Entorno de desarrollo: locales, personas, plataforma y herramientas

• Técnicas de programación segura

• Gestión de código fuente

• control de acceso

• control de versiones

Para realizar la aceptación: • Pruebas de aceptación

• 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



• pruebas en carga

• 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)

• acreditaciones

Para realizar el despliegue: • Inventario de aplicaciones en operación

• Gestión de cambios: normativa y procedimientos

• Establecimiento de claves

Durante la operación: • Normativa y procedimientos de ...

• gestión de usuarios

• gestión de claves

• gestión de registros (log)

• gestión de incidencias: registro de evidencias, escalado, plan de emergencia y de re-cuperación

• Análisis de registros (log): herramientas, criterios, procedimientos, ...

• Manuales de uso: administradores, operadores y usuarios

• Formación: inicial y continua: administradores, operadores y usuarios

En los ciclos de mantenimiento: • Normativa y procedimientos de ...

• solicitud

• aprobación, incluyendo el análisis diferencial de riesgos y, aprobación en su caso de las nuevas medidas

Terminación • Destrucción de datos operacionales

• Copia y custodia de datos, cuando proceda por ley o política interna

• Eliminación del código operativo: ejecutable, datos de configuración y cuentas de usuario

• Revisión de las copias de seguridad

4.5. MÉTRICA versión 3 La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento útil para la siste-matización de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos:

• Proporcionar o definir sistemas de información que ayuden a conseguir los fines de la Orga-nización mediante la definición de un marco estratégico para el desarrollo de los mismos.

• Dotar a la Organización de productos software que satisfagan las necesidades de los usua-rios dando una mayor importancia al análisis de requisitos.



• Mejorar la productividad de los departamentos de sistemas y tecnologías de la información y las comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y te-niendo en cuenta la reutilización en la medida de lo posible.

• Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y respon-sabilidad, así como las necesidades de todos y cada uno de ellos.

• Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

Cuando el desarrollo de la aplicación se atenga a la metodología MÉTRICA versión 3, los aspec-tos anteriormente tratados para asegurar que la nueva aplicación no altere incontroladamente el estado de riesgo de la Organización deberán tenerse en cuenta a lo largo del proceso de desarro-llo.

MÉTRICA versión 3 identifica 3 procesos, 5 subprocesos y 4 interfaces:

gestión deconfiguración

aseguramientode la calidad

gestión deproyectos

seguridad

planificaciónPSI

desarrollo

EVS ASI DSI CSI IAS

mantenimientoMSI

planificaciónPSI

desarrollo

EVS ASI DSI CSI IAS

desarrollo

EVS ASI DSI CSI IASEVS ASI DSI CSI IAS

mantenimientoMSI

PSI – Planificación del sistema de información

EVS – Estudio de viabilidad del sistema

ASI – Análisis del sistema de información

DSI – Diseño del sistema de información.

CSI – Construcción del sistema de información

IAS – Implantación y aceptación del sistema

MSI – Mantenimiento del sistema de información

La interfaz de seguridad permite la comunicación entre las tareas de desarrollo y las tareas de análisis y gestión 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.

Es decir que se manejan simultáneamente diferentes requisitos:

• de servicio, procedentes de la dirección

• técnicos, procedentes del equipo de desarrollo

• de seguridad, procedentes del equipo de análisis de riesgos

Esto da pie a una interrelación continua entre el equipo de desarrollo y el equipo de seguridad que, a través de la interfaz de seguridad, van cerrando cada etapa de Métrica. Es importante des-tacar que el alcance de un nivel de seguridad puede requerir modificaciones en los componentes técnicos del sistema; al tiempo que los detalles técnicos pueden alterar el análisis de seguridad.



En cualquier caso, el punto de acuerdo entre los componentes (activos) y el estado de seguridad (impacto y riesgo) debe ser aprobado por la dirección de la Organización.

Como se indica más arriba, se puede distinguir entre la seguridad del proceso de desarrollo (ta-reas SPD) y la seguridad del sistema de información (SSI). Las tareas de la interfaz se organizan según su pertenencia a uno u otro objetivo de seguridad.

4.5.1. 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:

Tareas afectadas en la Interfaz de Seguridad de Métrica v3 PSI: Planificación del sistema de información

SEG 1: Planificación de la seguridad requerida en el proceso PSI PSI-SEG 1.1: Estudio de la seguridad requerida en el proceso PSI PSI-SEG 1.2: Organización y planificación

SEG 4: Catalogación de los productos generados durante el proceso PSI PSI-SEG 4.1: Clasificación y catalogación de los productos generados durante el proceso

PSI EVS: Estudio de viabilidad del sistema

SEG 1: Estudio de la seguridad requerida en el proceso EVS EVS-SEG 1.1: Estudio de la seguridad requerida en el proceso EVS

SEG 2: Selección del equipo de seguridad EVS-SEG 2.1: Selección del equipo de seguridad

SEG 6: Catalogación de los productos generados durante el proceso EVS EVS-SEG 6.1: Clasificación y catalogación de los productos generados durante el proceso

EVS

ASI: Análisis del sistema de información SEG 1: Estudio de la seguridad requerida en el proceso ASI

ASI-SEG 1.1: Estudio de la seguridad requerida en el proceso ASI SEG 4: Catalogación de los productos generados durante el proceso ASI

ASI-SEG 4.1: Clasificación y catalogación de los productos generados durante el proceso ASI

DSI: Diseño del sistema de información SEG 1: Estudio de la seguridad requerida en el proceso DSI

DSI-SEG 1.1: Estudio de la seguridad requerida en el proceso DSI SEG 5: Catalogación de los productos generados durante el proceso DSI

DSI-SEG 5.1: Clasificación y catalogación de los productos generados durante el proceso DSI

CSI: Construcción del sistema de información SEG 1: Estudio de la seguridad requerida en el proceso CSI

CSI-SEG 1.1: Estudio de la seguridad requerida en el proceso CSI SEG 4: Clasificación de los productos generados durante el proceso CSI

CSI-SEG 4.1: Clasificación y catalogación de los productos generados durante el proceso CSI



Tareas afectadas en la Interfaz de Seguridad de Métrica v3 IAS: Implantación y aceptación del sistema

SEG 1: Estudio de la seguridad requerida en el proceso IAS IAS-SEG 1.1: Estudio de la seguridad requerida en el proceso IAS

SEG 4: Catalogación de los productos generados durante el proceso IAS IAS-SEG 4.1: Clasificación y catalogación de los productos generados durante el proceso

IAS MSI: Mantenimiento del sistema de información

SEG 1: Estudio de la seguridad requerida en el proceso MSI MSI-SEG 1.1: Estudio de la seguridad requerida en el proceso MSI

SEG 3: Catalogación de los productos generados durante esta etapa MSI-SEG 3.1: Clasificación y catalogación de los productos generados durante esta etapa

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 do-cumentació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 archi-vo, 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

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, propo-niendo una serie de medidas a tomar

5. el equipo de desarrollo elabora un informe del coste que supondrían las medidas recomen-dadas, 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 se-lecció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 apli-caciones o partes de una aplicación que soporten un alto riesgo

4.5.2. SSI – Seguridad del sistema de información Todo la existencia de un sistema de información puede verse como etapas de concreción crecien-te, 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 sis-temas, 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 me-todologí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.

La utilización de herramientas de soporte debe permitir

1. capturar un modelo inicial (PSI),

2. estudiar variaciones (EVS y ASI),

3. pasar de lo general a lo concreto, previniendo amenazas potenciales y preparando meca-nismos de detección y reacción (DSI y CSI)

4. dirigir su aceptación y explotación (IAS)

5. revisar periódicamente los cambios que se propongan (MSI)



Uso de las tareas de la metodología Magerit Proceso P1: Planificación

Actividad A1.1: Estudio de oportunidad

Tarea T1.1.1: Determinar la oportunidad

Esta tarea se reduce a la decisión, interna, de desarrollar el sistema de información te-niendo en cuenta la seguridad.

Actividad A1.2: Determinación del alcance del proyecto

Tarea T1.2.1: Objetivos y restricciones generales

Los del sistema de información bajo desarrollo.

Tarea T1.2.2: Determinación de dominio y límites


Tarea T1.2.3: Identificación del entorno


Tarea T1.2.4: Estimación de dimensiones y coste

Parte de proyecto (o proyectos) de desarrollo del sistema de información.

Actividad A1.3: Planificación del proyecto

Tarea T1.3.1: Evaluar cargas y planificar entrevistas

Esta tarea se lleva a cabo como en cualquier proyecto AGR. Esta tarea se debe reali-zar con el primer proceso, PSI, quedando establecida la relación de entrevistas para el resto de los procesos, salvo ajustes puntuales que se detecten necesarios.

Tarea T1.3.2: Organizar a los participantes

Esta tarea se lleva a cabo como en cualquier proyecto AGR. Durante el primer proce-so, PSI, debe establecerse la relación de participantes a entrevistar, sin precisar más allá el papel que desempeñan. Según vaya avanzando el desarrollo del sistema, se irá identificando a las personas que satisfacen los roles previstos.

Tarea T1.3.3: Planificar el trabajo


Actividad A1.4: Lanzamiento del proyecto

Tarea T1.4.1: Adaptar los cuestionarios

Esta tarea se lleva a cabo como en cualquier proyecto AGR. Esta tarea se debe reali-zar con el primer proceso, PSI, quedando establecidos para el resto de los procesos, salvo ajustes puntuales.

Tarea T1.4.2: Criterios de evaluación

Esta tarea se lleva a cabo como en cualquier proyecto AGR. Esta tarea se debe reali-zar con el primer proceso, PSI, quedando establecidos para el resto de los procesos.

Tarea T1.4.3: Recursos necesarios


Tarea T1.4.4: Sensibilización


Proceso P2: Análisis de riesgos Actividad A2.1: Caracterización de los activos

Tarea T2.1.1: Identificación de los activos



En los primeros procesos, PSI, se identifican activos genéricos. Según se avanza en el desarrollo, esta identificación se va precisando de forma que los activos genéricos se traducen en activos concretos. La concreción debe ser máxima al llegar al proceso CSI.

Tarea T2.1.2: Dependencias entre activos

En los primeros procesos, PSI, aparecen relaciones de trazo grueso. Según se avanza en el desarrollo, las dependencias se van precisando según los activos genéricos se traducen en activos concretos. La concreción debe ser máxima al llegar al proceso CSI.

Tarea T2.1.3: Valoración de los activos

La valoración de los servicios últimos y de los datos esenciales se puede realizar prác-ticamente desde el primer proceso PSI, si bien según avance el desarrollo pueden segmentarse los servicios y/o los datos, requiriendo una valoración singular que nunca deberá suponer la superación de la valoración de los servicios o datos agregados. Es decir, pueden desagregarse los servicios y/o los datos en fracciones de menor valor.

Típicamente la valoración del resto de los activos puede analizarse como simple valor acumulado desde los activos superiores, explotando las relaciones de dependencia.

Actividad A2.2: Caracterización de las amenazas

Tarea T2.2.1: Identificación de las amenazas

Las amenazas sobre activos genéricos pueden incorporarse desde el primer proceso PSI; pero según se vaya concretando el conjunto detallado de componentes habrá que incorporar amenazas específicas de la tecnología que se emplea.

Tarea T2.2.2: Valoración de las amenazas

Esta tarea se lleva a cabo como en cualquier proyecto AGR.

Actividad A2.3: Caracterización de las salvaguardas

Tarea T2.3.1: Identificación de las salvaguardas existentes

Buena parte de las salvaguardas pueden incorporarse desde el primer proceso PSI.

No obstante, las salvaguardas de carácter técnico, deberán irse precisando según se vaya concretando el conjunto detallado de componentes y la tecnología que se em-plea.

Tarea T2.3.2: Valoración de las salvaguardas existentes


Actividad A2.4: Estimación del estado de riesgo

Tarea T2.4.1: Estimación del impacto


Tarea T2.4.2: Estimación del riesgo


Tarea T2.4.3: Interpretación de los resultados


Proceso P3: Gestión de riesgos Actividad A3.1: Toma de decisiones

Tarea T3.1.1: Calificación de los riesgos




En la toma de decisiones debe participar tanto el equipo de desarrollo como el equipo de análisis de riesgos.

Actividad A3.2: Elaboración del plan director de seguridad de la información

Tarea T3.2.1: Programas de seguridad

Esta tarea queda subsumida en las tareas de desarrollo.

Tarea T3.2.2: Plan de ejecución

Esta tarea queda subsumida en las tareas de desarrollo.

Actividad A3.3: Ejecución del plan

Tarea T3.3.*: Ejecución de cada programa de seguridad

Estas tareas quedan subsumidas en las tareas de desarrollo.

Otras consideraciones Es importante llevar a cabo los diferentes análisis de riesgos de una forma evolutiva, incorporando mayor detalle según avanza el desarrollo; pero nunca volviendo a comenzar desde cero.

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.

Las normas y procedimientos que se derivan en cada proceso van constituyendo el conjunto de normas y procedimientos que se emplearán durante la explotación del sistema.

• Típicamente la normativa debe cerrarse en los primeros procesos: PSI, EVS y ASI, siendo infrecuente su modificación en los procesos siguientes.

• Por el contrario, los procedimientos no se pueden derivar hasta concretar el detalle en los procesos DSI, CSI e IAS. No deberían modificarse, salvo ajustes y correcciones, en los pro-cesos siguientes.

• El proceso IAS pasa normas y procedimientos a explotación.

• El proceso MSI puede suponer la reparación de normas o procedimientos erróneos, o la ex-tensión de normas o procedimientos incompletos que no hayan contemplado todas las cir-cunstancias prácticas.

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 salva-guardas y a monitorizar su operación.

Tareas afectadas en la Interfaz de Seguridad de Métrica v3 PSI: Planificación del sistema de información

SEG 2: Evaluación del riesgo para la arquitectura tecnológica PSI-SEG 2.1: Estudio y evaluación del riesgo de las alternativas de arquitectura tecnológicaPSI-SEG 2.2: Revisión de la evaluación del riesgo de las alternativas de arquitectura tecno-

lógica SEG 3: Determinación de la seguridad en el plan de acción

PSI-SEG 3.1: Determinación de la seguridad en el plan de acción



Tareas afectadas en la Interfaz de Seguridad de Métrica v3 EVS: Estudio de viabilidad del sistema

SEG 3: Recomendaciones adicionales de seguridad para el SI EVS-SEG 3.1: Elaboración de recomendaciones de seguridad

SEG 4: Evaluación de la seguridad de las alternativas de solución EVS-SEG 4.1: Valoración y evaluación de la seguridad de las alternativas de solución

SEG 5: Evaluación detallada de la seguridad de la solución propuesta EVS-SEG 5.1: Descripción detallada de la seguridad de la solución propuesta

ASI: Análisis del sistema de información SEG 2: Descripción de las funciones y mecanismos de seguridad

ASI-SEG 2.1: Estudio de las funciones y mecanismos de seguridad a implantar SEG 3: Definición de los criterios de aceptación de la seguridad

ASI-SEG 3.1: Actualización del plan de pruebas

DSI: Diseño del sistema de información SEG 2: Especificación de requisitos de seguridad del entorno tecnológico

DSI-SEG 2.1: Análisis de los riesgos del entorno tecnológico SEG 3: Requisitos de seguridad del entorno de construcción

DSI-SEG 3.1: Identificación de los requisitos de seguridad del entorno de construcción SEG 4: Diseño de pruebas de seguridad

DSI-SEG 4.1: Diseño de las pruebas de seguridad

CSI: Construcción del sistema de información SEG 2: Evaluación de los resultados de pruebas de seguridad

CSI-SEG 2.1: Evaluación de los resultados de pruebas de seguridad SEG 3: Elaboración del plan de formación de seguridad

CSI-SEG 3.1: Elaboración del plan de formación de seguridad

IAS: Implantación y aceptación del sistema SEG 2: Revisión de medidas de seguridad en el entorno de operación

IAS-SEG 2.1: Revisión de medidas de seguridad en el entorno de operación SEG 3: Evaluación de resultados de pruebas de seguridad de implantación del sistema

IAS-SEG 3.1: Estudio de los resultados de pruebas de seguridad de implantación del sis-tema

SEG 5: Revisión de medidas de seguridad en el entorno de producción IAS-SEG 5.1: Revisión de medidas de seguridad en el entorno de producción

MSI: Mantenimiento del sistema de información SEG 2: Especificación e identificación de las funciones y mecanismos de seguridad

MSI-SEG 2.1: Estudio de la petición MSI-SEG 2.2: Análisis de las funciones y mecanismos de seguridad afectados o nuevos

4.6. Referencias • NIST Special Publication 800-64, “Security Considerations in the Information System Devel-

opment Life Cycle”, Rev.1. June 2004.

• NIST Special Publication 800-27 Rev. A, “Engineering Principles for Information Technology Security (A Baseline for Achieving Security)”, Rev. A, June 2004.

• “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.

Magerit versión 2 Consejos prácticos


5. 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. Por ello se ha considerado conveniente incluir al-gunos 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, di-mensiones de valoración, guías de valoración, catálogos de amenazas y de salvaguardas.

5.1. Para identificar activos Conviene repetir que sólo interesan los recursos de los sistemas de información que tienen un va-lor 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 presen-tació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 confidenciali-dad 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 activos37 o como elementos de valoración38. 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 Organi-zación y el valor de ésta reside en estos intangibles como ya se reconocía en Magerit versión 1.039.

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

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

37 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ér-minos 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.

38 Ver “Catálogo de Elementos”, capítulo “4. Criterios de valoración”. 39 Ver Magerit versión 1.0, “Guía de Procedimientos” / “3. Submodelo de Elementos” / “3.4. Impactos” /

”3.4.3. Tipos”.



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

• ¿Hay activos relacionados con los anteriores?

No siempre es evidente qué es un activo en singular. Si por ejemplo en su unidad tiene 300 pues-tos de trabajo PC, todos idénticos a efectos de configuración y datos que manejan, no es conve-niente analizar 300 activos idénticos. Baste analizar un PC genérico que cuya problemática repre-senta la de todos. Agrupar simplifica el modelo.

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.

5.2. Para descubrir y modelar las dependencias entre activos 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.

Es necesario transmitir al interlocutor que no se busca qué es necesario para que el sistema fun-ciones, 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.

• 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?

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

Este planteamiento de “póngase en el lugar del atacante” es el que da pie a las técnicas denomi-nadas “árboles de ataque”40 que van parejas a lo que en esta metodología se denominan depen-dencias. 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 de-cir 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 locales41. Es fre-cuente 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 de-pendencias, pues las dependencias de dichos servicios se interpretan sin ambigüedad como de-pendencia de todos los elementos que prestan el servicio.

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

40 Ver “Guía de Técnicas”, sección 2.3. 41 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.



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.

Errores típicos No es correcto decir que una aplicación depende de los datos 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: los datos dependen de la aplicación. En térmi-nos de valor, se puede asegurar que la aplicación no vale nada sin datos. Como el valor es una propiedad de los datos, es ese valor el que hereda la aplicación. Luego los datos dependen de la aplicación. Desde otro punto de vista, a través de la aplicación puede accederse a los datos, con-virtiéndose la aplicación en la vía de ataque a los datos.

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 • servicio → aplicación

• aplicación → datos

• servicio → datos

• datos → aplicación

• servicio → aplicación

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

• aplicación → equipo

• servicio → aplicación

• servicio → equipo

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 ejem-plo, 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

servicio 1servicio 1 servicio 2servicio 2

datos 1datos 1 datos 2datos 2datos 1datos 1 datos 2datos 2

aplicaciónaplicación

equipo 1equipo 1 equipo 2equipo 2equipo 1equipo 1 equipo 2equipo 2

¿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 pue-de 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 acu-mulado es síntoma de que las dependencias están mal modeladas o, simplemente, que el activo es irrelevante.

5.3. Para valorar activos Siempre conviene valorar la información o datos que constituyen la razón de ser del sistema de información.

Si se han modelado servicios finales (prestados a usuarios externos al dominio de análisis), con-viene valorarlos igualmente.

Es fácil identificar activos de tipo datos o información y valorarlos siguiendo clasificaciones pauta-das como su carácter personal o su clasificación de seguridad. Pero pasa a ser mucho más deli-cado valorar datos de tipo comercial u operacional porque hay que ir a las consecuencias del da-ño sufrido.

El resto de los activos puede frecuentemente pasar sin valorar, pues su valor más importante es soportar los datos 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 re-posició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 trabajo-sa, hay que tener en cuenta que la persona que desempeña ese puesto se convierte en muy va-liosa, 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 per-sonas 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 Delphi42: mande cuestionarios a los que opinan e intente que converjan a una opinión co-mú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 Elemen-tos", 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.

42 Ver "Guía de Técnicas", capítulo 3.7.



Datos de carácter personal Los datos de carácter personal están tipificados por leyes y reglamentos, requiriendo de la Orga-nización que adopte una serie de medidas de protección independientes del valor del activo43.

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 reve-lació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.

5.4. 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 ocurri-do 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 ca-pacidad 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 interesan-tes 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.

5.5. Para valorar amenazas La tarea es desmoralizadora: para cada activo en cada dimensión, determinar la degradación que causarían y la frecuencia probable 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 valo-res 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 atacante44

• que no requiera gran inversión en equipo por parte del atacante45

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

43 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.

44 Hay que estar atentos a la “comercialización” de las herramientas de ataque pues un ataque puede re-querir un gran experto para realizarlo manualmente (es decir, es poco frecuente); pero si el experto em-paqueta 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 pasa-do a ser muy frecuente).

45 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 dispon-ga de muchísimos más medios efectivos que el atacado.



• que haya un enorme beneficio en juego (que el atacante pueda salir fuertemente beneficia-do, 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

Partiendo de un valor estándar, hay que ir aumentando o disminuyendo sus calificaciones de fre-cuencia 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 cam-bian 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 ajus-tar 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 fre-cuencia, 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 an-tes o después se pedirán explicaciones, sobre todo si como consecuencia se van a recomendar salvaguardas costosas.

5.6. 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 or-ganizar 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 pe-rió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 ten-ga 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.

5.7. 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 esti-maciones 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-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 razona-blemente protegidos cuando no hay tiempo para un análisis de riesgos en toda su plenitud. Cuan-do, con tiempo, se llegue a la fase de gestión de riesgos tras un análisis exhaustivo, muy proba-blemente ocurra que muchas salvaguardas están ya dispuestas, necesitándose sólo la introduc-ción de algunas nuevas y/o la mejora de la eficacia de las existentes. No es pues trabajo perdido seguir estas aproximaciones informales.

5.7.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 puede 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/IEC 17799:2005

• normas nacionales, por ejemplo los “Criterios de Seguridad”

• normas sectoriales

• normas corporativas, especialmente frecuentes en pequeñas delegaciones de grandes or-ganizaciones

Las ventajas de protegerse por catálogo son:

• es muy rápido

• no cuesta apenas esfuerzo

• 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 in-justificado

• 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 parti-da útil para refinar posteriormente.

La protección por catálogo puede refinarse un poco considerando el valor de los activos o cuantifi-cando 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.

En base al valor de los activos Si usted tiene todos los datos operacionales en soporte informático, tiene que hacer copias de se-guridad.

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 pre-senciales), registre cuidadosamente quién hace qué en cada momento pues se enfrentará a inci-dencias 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 se-guridad es disponer de la información correcta cuando haga falta.

En base a las vulnerabilidades 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 corri-giendo los defectos anunciados por el fabricante.

Cuando se sabe que los sistemas de información son vulnerables, hay que protegerlos.

5.8. Referencias • ISO/IEC 17799:2005, “Information technology – Security techniques – Code of practice for

information security management”, Junio 2005.

• “Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para el ejercicio de potestades”, MAP, 2004

• C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”, Addison Wesley, 2003.

• UNE-ISO/IEC 17799:2002, “Tecnología de la Información. Código de Buenas Prácticas de la Gestión de la Seguridad de la Información”, 2002.

• United States General Accounting Office, Accounting and Information Management Division, “Information Security Risk Assessment -- GAO Practices of Leading Organizations.

• Ministerio de Administraciones Públicas, “Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información”, MAP, versión 1.0, 1997.

Magerit versión 2 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).

1.1. Términos en español Acreditación Acción de facultar a un sistema o red de información para que procese da-

tos sensibles, determinando el grado en el que el diseño y la materializa-ción de dicho sistema cumple los requerimientos de seguridad técnica preestablecidos. [CESID:1997]

Accreditation: Formal declaration by the responsible management approv-ing the operation of an automated system in a particular security mode us-ing 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. [15443-1:2005]

Activo Recursos del sistema de información o relacionados con éste, nece-sarios para que la Organización funcione correctamente y alcance los objetivos propuestos por su dirección. 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: Anything that has value to the organization. [13335-1:2004]

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 pre-serving. [TDIR:2003]

Assets: Information or resources to be protected by the countermeasures of a Target of Evaluation. [CC:1999]

AGR Análisis y Gestión de Riesgos Amenaza Eventos que pueden desencadenar un incidente en la Organización,

produciendo daños materiales o pérdidas inmateriales en sus acti-vos. Eventos que pueden desencadenar un incidente en la Organización, pro-duciendo daños materiales o pérdidas inmateriales en sus activos. [Mage-rit:1997]

Condición del entorno del sistema de información que, dada una oportuni-dad, podría dar lugar a que se produjese una violación de la seguridad.



[CESID:1997]

Threat: A potential cause of an incident which may result in harm to a sys-tem or organization. [17799:2005][13335-1:2004]

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 unauthor-ized access, destruction, disclosure, modification of information, and/or de-nial of service. [800-53:2004]

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. 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 seguri-dad insuficiente puede tener para la organización, obteniendo cierto cono-cimiento del riesgo que se corre. [Magerit:1997]

Risk analysis: Systematic use of information to identify sources and to es-timate the risk. [17799:2005][Guide 73:2002]

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: The systematic process of estimating the magnitude of risks. [13335-1:2004]

Risk Analysis: Examination of information to identify the risk to an informa-tion 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 in-formation 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]

Risk Assessment: A study of vulnerabilities, threats, likelihood, loss or im-pact, 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 opera-



tions. [TDIR:2003] Ataque Cualquier acción deliberada encaminada a violar los mecanismos de segu-

ridad de un sistema de información. [CESID:1997] Auditoría de segu-ridad

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 es-tructuras de seguridad.

Autenticidad Aseguramiento de la identidad u origen. Autenticación: Característica de dar y reconocer la autenticidad de los ac-tivos 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 di-chas 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:2004]

Authenticity: The property that ensures that the identity of a subject or re-source is the one claimed. Authenticity applies to entities such as users, processes, systems, and information. [13335-1:2004]

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

Confidencialidad Aseguramiento de que la información es accesible sólo para aquellos autorizados a tener acceso. Aseguramiento de que la información es accesible sólo para aquellos auto-rizados a tener acceso. [17799:2002]

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 unauthor-ized 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 pro-prietary information. [800-53:2004]

Confidentiality: The requirement of keeping proprietary, sensitive, or per-sonal 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]

Confidentiality: The property that information is not made available or dis-closed to unauthorized individuals, entities, or processes. [7498-2:1989]

Contra medida Véase salvaguarda. Control Véase salvaguarda. 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 cuan-do lo requieran a la información y sus activos asociados. Aseguramiento de que los usuarios autorizados tienen acceso cuando lo requieran a la información y sus activos asociados. [17799:2002]

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 author-ized to use them (JCS 1997) [OPSEC]

Availability: Ensuring timely and reliable access to and use of information. [800-53:2004]

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 au-thorized users. [CNSS:2003] [TDIR:2003] [CIAO:2000]

Availability: The property of being accessible and usable upon demand by an authorized entity. [7498-2:1989]

Documento de selección de controles

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.

Estado de riesgo Informe: Caracterización de los activos por su riesgo residual; es de-cir 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. Gestión de riesgos Selección e implantación de salvaguardas para conocer, prevenir,

impedir, reducir o controlar los riesgos identificados. 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 perjui-cios. La gestión de riesgos se basa en los resultados obtenidos en el aná-lisis de los riesgos. [Magerit:1997]

Risk treatment: process of selection and implementation of measures to modify risk. [17799:2005][13335-1:2004][Guide 73:2002]

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). [OP-SEC]

Risk management: Process of identifying and applying countermeasures commensurate with the value of the assets protected based on a risk as-sessment. [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 que sobre un activo tiene la materialización de una amena-



za. [Magerit:1997]

Impact: The result of an information security incident. [13335-1:2004]

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 salva-guardas determinadas en el plan de seguridad de la información.

Incidente Evento con consecuencias en detrimento de la seguridad del sistema de información. Information security event: An identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be secu-rity relevant. [17799:2005]

Information security incident: Any unexpected or unwanted event that might cause a compromise of business activities or information security. [13335-1:2004]

Incident: A successful or unsuccessful action attempting to circumvent technical controls, organizational policy, or law. This is often called an at-tack. [TDIR:2003]

Informe de insuficiencias

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

Integridad Garantía de la exactitud y completitud de la información y los méto-dos de su procesamiento. Garantía de la exactitud y completitud de la información y los métodos de su procesamiento. [17799:2002]

Característica que previene contra la modificación o destrucción no autori-zadas 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, al-tered, or destroyed (NSC EO 1995; JCS 1997). [OPSEC]

Integrity: Guarding against improper information modification or destruc-tion, and includes ensuring information non-repudiation and authenticity. [800-53:2004]

Integrity: the property of safeguarding the accuracy and completeness of assets. [13335-1:2004]

Integrity: the authenticity, accuracy, and completeness of an asset. [Oc-tave:2003]

Data integrity: A condition existing when data is unchanged from its source and has not been accidentally or maliciously modified, altered, or de-stroyed. [CNSS:2003] [TDIR:2003] [CIAO:2000]

Data integrity: The data quality that exists as long as accidental or mali-cious 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 acti-



vos. Threat Analysis: The examination of all actions and events that might ad-versely affect a system or operation. [TDIR:2003]

Threat Assessment: An evaluation of the nature, likelihood, and conse-quence of acts or events that could place sensitive information and assets as risk. [TDIR:2003]

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

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

Programa de seguridad

Agrupación de tareas orientadas a afrontar el riesgo del sistema. La agrupación se realiza por conveniencia, bien porque se trata de ta-reas 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.

Proyecto de seguridad

Programa de seguridad cuya envergadura es tal que requiere una planificación específica.

Riesgo Estimación del grado de exposición a que una amenaza se materiali-ce sobre uno o más activos causando daños o perjuicios a la Organi-zación. Posibilidad de que se produzca un impacto determinado en un activo, en un dominio o en toda la Organización. [Magerit:1997]

Probabilidad de que una vulnerabilidad propia de un sistema de informa-ción sea explotada por las amenazas a dicho sistema, con el objetivo de penetrarlo. [CESID:1997]

Risk: combination of the probability of an event and its consequence. [17799:2005][Guide 73:2002]

Risk: A measure of the potential degree to which protected information is subject to loss through adversary exploitation. [OPSEC]

Risk: the potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization. [13335-1:2004]

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 miti-gating 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 residual Riesgo remanente en el sistema tras la implantación de las salva-guardas determinadas en el plan de seguridad de la información. Riesgo que se da tras la aplicación de salvaguardas dispuestas en un es-cenario de simulación o en el mundo real. [Magerit:1997]



Residual risk: The risk that remains after risk treatment. [13335-1:2004]

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]

Riesgo acumulado Dícese del calculado tomando en consideración el valor propio de un acti-vo 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 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 ac-tivos de los que depende.

Salvaguarda Procedimiento o mecanismo tecnológico que reduce el riesgo. Control: Means of managing risks, including policies, procedures, guide-lines, practices or organizational structures, which can be of administrative, technical, management or legal nature. [17799:2005]

Countermeasure: Anything which effectively negates or mitigates an ad-versary's ability to exploit vulnerabilities. [OPSEC]

Safeguard: Protective measures prescribed to meet the security require-ments (i.e., confidentiality, integrity, and availability) specified for an infor-mation system. Safeguards may include security features, management constraints, personnel security, and security of physical structures, areas, and devices. [800-53:2004]

Safeguard: a practice, procedure or mechanism that treats risk. [13335-1:2004]

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 secu-rity, 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 im-pact on a system. [TDIR:2003]

Seguridad La capacidad de las redes o de los sistemas de información de resis-tir, con un determinado nivel de confianza, los accidentes o acciones ilícitas o malintencionadas que comprometan la disponibilidad, au-tenticidad, integridad y confidencialidad de los datos almacenados o transmitidos y de los servicios que dichas redes y sistemas ofrecen o hacen accesibles. 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]

Sistema de infor-mació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 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 collec-tion, storage, processing, maintenance, use, sharing, dissemination, dispo-sition, 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 in-formation. Information systems include applications and their supporting infrastructure. [CRAMM:2003]

Trazabilidad Aseguramiento de que en todo momento se podrá determinar quién hizo qué y en qué momento. 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: The property that ensures that the actions of an entity may be traced uniquely to the entity. [13335-1:2004]

Accountability: Process of tracing information system activities to a respon-sible source. [CNSS:2003]

Valor De un activo. Es una estimación del coste inducido por la materiali-zació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 ac-tivos que dependen de él. Bienes de abolengo: Los heredados de los abuelos. [DRAE]

Vulnerabilidad 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. 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: A weakness of an asset or group of assets that can be ex-ploited by one or more threats. [17799:2005][13335-1:2004]

Vulnerability: The susceptibility of information to exploitation by an adver-sary. [OPSEC]

Vulnerability: Weakness in an information system, system security proce-dures, 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]

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



Accountability Trazabilidad ALE Annual Loss Expectancy ARO Annual Rate of Occurrence

Authenticity Autenticidad Availability Disponibilidad

Asset Activo BIA Business Impact Analysis

Business Impact Analysis Análisis de impacto Confidentiality Confidencialidad

Countermeasure Contra medida Frequency Frecuencia

Impact Impacto Integrity Integridad

Residual risk Riesgo residual Risk Riesgo

Risk analysis Análisis de riesgos Risk assessment Análisis de riesgos

Risk management Gestión de riesgos Risk map Mapa de riesgo

Risk treatment Tratamiento del riesgo Safeguard Salvaguarda

Security Seguridad Statement of applicability Documento de selección de controles

Traceability Trazabilidad Threat Amenaza Value Valor

Vulnerability Vulnerabilidad

1.3. ISO/IEC Guide 73:2002 La Guía 73 de ISO [2002] estructura los conceptos de gestión de riesgos de la siguiente forma:

Risk management: coordinated activities to direct and control an organization with regard to risk.

Risk assessment: overall process of risk analysis and risk evaluation.

Risk analysis: systematic use of information to identify sources and to estimate risk.

Source identification: process to find, list and characterize sources46.

Risk estimation: process used to assign values to the probability47 and consequences of a risk.

46 Source: item or activity having a potential for a consequence.

Consequence: outcome of an event. Event: occurrence of a particular set of circumstances.

47 Probability: extend to which an event is likely to occur.



Risk evaluation: process of comparing the estimated risk against given risk criteria to determine the signifi-cance of the risk.

Risk treatment: process of selection and implementation of measures to modify risk.

La siguiente tabla resume la relación entre la terminología identificada en la Guide 73 y Magerit:

Guide 73:2002 Magerit v2

Risk management Análisis y gestión de riesgos P1 + P2 + P3

Risk assessment

Risk analysis Análisis de riesgos P2

Source identification

Risk estimation

Risk evaluation A3.1

Risk treatment Gestión de riesgos A3.2 + A3.3

1.4. Referencias [DRAE]

Real Academia Española. Diccionario de la Lengua Española. 22.ª edición, 2001. http://buscon.rae.es/diccionario/drae.htm

[OPSEC] OPSEC Glossary of Terms, http://www.ioss.gov/docs/definitions.html

[17799:2005] ISO/IEC 17799:2005, “Information technology -- Code of practice for information security man-agement”, 2005.

[15443-1:2005] ISO/IEC TR 15443:2005, “Information technology -- Security techniques -- A framework for IT security assurance -- Part 1: Overview and framework”, 2005.

[800-53:2004] NIST, “Recommended Security Controls for Federal Information Systems”, National Institute of Standards and Technology, special publication 800-53, 2004.

[13335-1:2004] ISO/IEC 13335-1:2004, “Information technology -- Security techniques -- Management of infor-mation and communications technology security -- Part 1: Concepts and models for information and communications technology security management”, 2004.

[CRAMM:2003] “CCTA Risk Analysis and Management Method (CRAMM)”, Version 5.0, 2003.

[Octave:2003] C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”, Addison Wesley, 2003.



[TDIR:2003] Texas Department of Information Resources, “Practices for Protecting Information Resources Assets“, Revised September 2003.

[CNSS:2003] Committee on National Security Systems, Instruction No. 4009, “National Information Assuran-ce (IA) Glossary“, May 2003.

[Guide 73:2002] ISO/IEC Guide 73:2002, “Risk management – Vocabulary – Guidelines for use in Standards”, 2002.

[17799:2002] UNE ISO/IEC:2002, “Tecnología de la Información – Código de Buenas Prácticas para la Ges-tión de la Seguridad de la Información”, 2002.

[CIAO:2000] Critical Infrastructure Assurance Office, “Practices for Securing Critical Information Assets”, January 2000.

[CC:1999] ISO/IEC 15408:1999, “Information technology — Security techniques — Evaluation criteria for IT security”, 1999.

[NSTISS:1998] National Security Telecommunications and Information Systems Security Committee, “Index of National Security Telecommunications Information Systems Security Issuances”, NSTISSI no. 4014, NSTISSC Secretariat, 1998.

[CESID:1997] Centro Superior de Información de la Defensa, “Glosario de Términos de Criptología”, Ministe-rio de Defensa, 3ª edición, 1997.

[Magerit:1997] Ministerio de Administraciones Públicas, “Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información”, MAP, versión 1.0, 1997.

[Ribagorda:1997] A. Ribagorda, “Glosario de Términos de Seguridad de las T.I.”, Ediciones CODA, 1997.

[7498-2:1989] ISO 7498-2:1989, “Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 2: Security Architecture”, 1989.

Magerit versión 2 Referencias


Apéndice 2. Referencias Aunque los capítulos y apéndices incluyen referencias bibliográficas específicas al tema que enfo-can, en este apéndice se recopilan las referencias a métodos y metodologías que afrontan el aná-lisis y gestión de riesgos como actividad integral. Las referencias se ordenan temporalmente: de más recientes a más antiguas.

• Federal Office for Information Security (BSI). “IT Baseline Protection Manual”, October 2003. Germany. http://www.bsi.de/gshb/english/etc/index.htm

• “The Vulnerability Assessment and Mitigation Methodology”, P.S. Antón et al., RAND Na-tional Defense Research Institute, MR-1601-DARPA, 2003.

• “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/

• “Information Security Risk Analysis”, T.R. Peltier, Auerbach Pub; 1st edition (January 23, 2001)

• “Risk Management: Multiservice Tactics, Techniques, and Procedures for Risk Manage-ment”, Air Land Sea Application Center, FM 3-100.12, MCRP 5-12.1C, NTTP 5-03.5, AFTTP(I) 3-2.30. February 2001.

• Air Force Pamphlet 90-902, “Operational Risk Management (ORM) Guidelines and Tools”, December 2000.

• KPMG Peat Marwick LLP, “Vulnerability Assessment Framework 1.1“, October 1998.

• 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

• GMITS, ISO/IEC TR 13335-2:1997, “Information technology - Security techniques - Guide-lines for the management of IT security - Part 2: Managing and planning IT security”.

Por último se debe citar una herramienta que lleva implícitamente una metodología. Al ser un pro-ducto, le fecha se limita a indicar la de la ultima versión en el mercado.

• CRAMM, “CCTA Risk Analysis and Management Method (CRAMM)”, Version 5.0, 2003.

Magerit versión 2 Marco legal


Apéndice 3. Marco legal En este apéndice se recopila la 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 un proyecto AGR. La relación no pretende ser exhaustiva, amén de estar sujeta a un proceso legisla-tivo activo, por lo que es obligación del responsable prestar atención a las novedades que vayan apareciendo..

La documentación actualizada puede encontrarse en las páginas web del SSISTAD48 del CSAE49:

http://www.csi.map.es/

Por último, se han incluido algunas referencias a acuerdos de carácter político o de otra naturale-za a los cuales conviene también prestar atención. Por ejemplo, las Guías de la OCDE.

3.1. Procedimiento administrativo • 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.

• Real Decreto 263/1996, de 16 de febrero, por el que se regula la utilización de técnicas elec-trónicas, informáticas y telemáticas por la Administración General del Estado.

• Real Decreto 209/2003, de 21 de febrero, por el que se regulan los registros y las notifica-ciones telemáticas, así como la utilización de medios telemáticos para la sustitución de la aportación de certificados por los ciudadanos.

• Resolución de 26 de mayo de 2003 de la Secretaría de Estado para la Administración Públi-ca por la que se dispone la publicación del Acuerdo del Pleno de la Comisión Interministerial de Adquisición de Bienes y Servicios Informáticos (CIABSI) de 18 de diciembre de 2002 por el que se aprueban los Criterios de seguridad, normalización y conservación de las aplica-ciones utilizadas por la Administración General del Estado en el ejercicio de sus potestades.

• Orden PRE/1551/2003, de 10 de junio, por la que se desarrolla la Disposición final primera del Real Decreto 209/2003, de 21 de febrero, por el que se regulan los registros y las notifi-caciones telemáticas, así como la utilización de medios telemáticos para la sustitución de la aportación de certificados por los ciudadanos.

3.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 Per-

sonal.


3.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 elec-trónicos, informáticos y telemáticos, con las Administraciones Públicas.

48 SSITAD: Seguridad de los Sistemas de Información y Protección de Datos Personalizados Automatiza-

dos, comité técnico del CSAE. 49 CSAE: Consejo Superior de Administración Electrónica.

Magerit versión 2 Marco legal


3.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 ofi-ciales.

• Orden Ministerial número 76/2002, de 18 de abril, por la que se establece la política de se-guridad para la protección de la información del Ministerio de Defensa almacenada, proce-sada 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 Nacio-nal.

• Decisión del Consejo de 19 de marzo de 2001, por la que se adoptan las normas de seguri-dad 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)

3.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 enfo-

que político europeo

• Guías de la OCDE para la seguridad de los sistemas de información y redes. Hacia una cul-tura de seguridad

Magerit versión 2 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 cali-dad 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.

4.1. Sistemas de gestión de la seguridad de la información (SGSI) Los problemas de seguridad de los sistemas de información tienen un origen técnico pero son tan complejos que la solución no puede ser solamente técnica. La tecnología es demasiado rica en oportunidades y por tanto hay que mantenerla bajo control asegurando que trabaje para los objeti-vos de la Organización.

Seguridad es estar prevenido (antes); es estar preparado para reaccionar a las emergencias, pre-vistas o imprevistas; y es saber rehacerse tras el desastre. Todo esto no es gratis: cuesta dinero, tiempo y esfuerzo. Por ello es necesario racionalizar, con criterio económico, una solución equili-brada entre lo que se evita que ocurra, lo que se monta para detectar fallos, y lo que se tiene pre-parado para cuando ocurra lo que, teóricamente, nunca debiera haber ocurrido. Y, todo eso, sin olvidar la dimensión tiempo, porque hay que racionalizar gastos e inversiones tanto para lo que sabemos hoy como para lo que descubriremos mañana.

Aparece pues un componente de gestión, tan necesario como los componentes técnicos.

Sistema de gestión de la seguridad de la información Es un sistema de gestión que comprende la política, la estructura organizativa, los procedi-mientos, los procesos y los recursos necesarios para implantar la gestión de la seguridad de la información. El sistema es la herramienta de que dispone la Dirección de las organizacio-nes para llevar a cabo las políticas y los objetivos de seguridad (integridad, confidencialidad y disponibilidad, asignación de responsabilidad, autenticación, etc.). Proporciona mecanis-mos para la salvaguarda de los activos de información y de los sistemas que los procesan, en concordancia con las políticas de seguridad y planes estratégicos de la organización. [UNE 71502:2004]

Esta es la esencia del modelo PDCA (de inglés Plan, Do, Check, Act) que se usa en los modelos de gestión de la calidad.

planificaciónplanificaciónPlan

monitorizacióny evaluación

monitorizacióny evaluación

Check

implementacióny operación

implementacióny operación

Do

mantenimientoy mejora

mantenimientoy mejora

Act

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, involu-crando a las personas que se hacen cargo del sistema o están relacionadas con éste. Un plan tie-ne éxito cuando lleva a una operación diaria sin sorpresas.

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 res-ponden 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 nove-dades que se produzcan, tanto en cuanto a modificaciones del propio sistema de información, co-mo a nuevas amenazas.

La reacción (A de Act) es saber derivar consecuencias de la experiencia, propia y de sistemas si-milares, 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 los objetivos propuestos.

4.1.1. La certificación Certificar un sistema de gestión de la seguridad consiste en que alguien, competente, afirma que un sistema está sano y 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 deta-lle 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íme-tro es difuso no quedará claro qué hay que hacer en los pasos siguientes; en particular, no se sa-brá muy bien a qué personas y departamentos hay que dirigirse para reclamar la información per-tinente. 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 or-ganigrama 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 Orga-nizació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é salva-guardas 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 caso es tener una estrategia, marcada por la política y el detalle del mapa de riesgos.

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á.



Los resultados del análisis de riesgos permiten elaborar un documento de selección de controles, así como una justificación de la calidad que deben tener. 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 uti-liza un “esquema de certificación” (por ejemplo, en España, disponemos de la norma UNE 71502).

La norma UNE 71502:2004 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 de acuerdo con la norma UNE ISO/IEC 17799:2002 dentro del contexto de los riesgos identificados por las organizaciones. Especifica los requisitos de los controles de seguridad de acuerdo con las necesidades de las organizaciones con independencia de su tipo, tamaño o área de actividad.”

La norma UNE 71502:2004 parte de una relación de controles basada en la norma UNE-ISO/IEC 17799:2002, relación que hay que ajustar a la organización sujeta a evaluación, obviando los ele-mentos que no son pertinentes. De considerarse necesario se seleccionarán controles específicos adicionales, fuera de la UNE-ISO/IEC 17799, para cada organización, adecuados a su modelo particular de negocio, así como los objetivos que se pretenden obtener con los mismos, justifican-do la selección.

La relación básica es la siguiente:

Política de seguridad Revisión y evaluación periódica de la política de seguridad

Control y gestión de la documentación

Aspectos organizativos para la seguridad Asignación de responsabilidades sobre Seguridad de la Información

Identificación de riesgo por el acceso de terceros Contratación de servicios Contratación de outsourcing Contratación de empresas colaboradoras

Clasificación y control de activos Inventario de activos

Clasificación de activos Clasificación de la información Revisión y clasificación periódica de activos Revisión periódica del análisis de riesgos Marcado y tratamiento de la información

Seguridad ligada al personal Contratación del personal

Formación Comunicación de incidencias

Seguridad física y del entorno Instalación y protección de los equipos

Mantenimiento de los equipos

Gestión de comunicaciones y operaciones Procesos operativos

Control de cambios Gestión de incidencias



Medidas y controles contra software dañino Recuperación de información Gestión de soportes removibles Eliminación de soportes Seguridad del correo electrónico Disponibilidad de sistemas públicos Control de entrada, almacenamiento y salida de información Análisis y gestión de registros Planificación de la capacidad del sistema Intercambio físico de información Intercambio lógico de información Autorización de salida de material y/o información Copias de respaldo y restauración

Control de accesos Identificación y autenticación de usuarios Restricción de acceso a la información Control de acceso a la red Control de acceso al sistema operativo Control de acceso lógico a la información Gestión de contraseñas Gestión remota de equipos

Desarrollo y mantenimiento de sistemas Control del paso de desarrollo a pruebas

Control de paso de pruebas a producción Control de cambios de sistema operativo Control de cambios en el software Selección, control y aprobación de software externo Control del diseño de aplicaciones Especificación de los requerimientos de seguridad Control de software en operación

Gestión de continuidad del negocio Gestión de la continuidad de negocio

Mantenimiento y evaluación de los planes de continuidad

Conformidad Identificación de la legislación aplicable

Revisión de cumplimiento de legislación Auditorías internas

4.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 certifi-car 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 reco-nocimiento mutuo de certificados emitidos por diferentes certificadores en diferentes países.

4.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 de-termine 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 SP 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.

Esquema de certificación Marco técnico y administrativo que establece la referencia de trabajo frente a la que se con-trasta el cumplimiento de la organización sometida a evaluación, se emite el certificado o re-gistro 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 documenta-ció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 vo-luntario.

Política de seguridad Conjunto de normas reguladoras, reglas y prácticas que determinan el modo en que los acti-vos, incluyendo la información considerada como sensible, son gestionados, protegidos y distribuidos dentro de una organización.



4.1.4. Referencias • ISO/IEC 17799:2005, “Information technology -- Code of practice for information security

management”, 2005.

• UNE 71502:2004, “Especificaciones para los Sistemas de Gestión de la Seguridad de la In-formación (SGSI)”, 2004.

• UNE-ISO/IEC 17799:2002, “Tecnología de la Información. Código de Buenas Prácticas de la Gestión de la Seguridad de la Información”, 2002.

• ISO Guide 72:2001, “Guidelines for the justification and development of management system standards”, 2001.

• European Co-Operation for Accreditation, “Guidelines for the Accreditation of Bodies Operat-ing Certification / Registration of Information Security Management Systems”, EA-7/03, Feb-ruary 2000.

4.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 Crite-ria). 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 transparen-te de evaluación, garantizando la objetividad de las adquisiciones.

La misma necesidad lleva a la aparición de iniciativas europeas como ITSEC (Information Techno-logy 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 centra-das en los equipos de computación, a englobar sistemas de información mucho más complejos.

Los CC permiten

1. definir las funciones de seguridad50 de los productos y sistemas (en tecnologías de la infor-mació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 salva-guardas adecuadas se vea notablemente simplificada para las organizaciones que necesitan miti-gar 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 Co-munes en el Campo de la Tecnología de la Información”51.

La evaluación de un sistema es la base para su certificación. Para certificar es necesario disponer de

50 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. 51 El día 23 de mayo de 2000 tuvo lugar en Baltimore (Maryland, Estados Unidos) la ratificación de la ad-

hesión de Alemania, Australia, Canadá, España, Estados Unidos, Finlandia, Francia, Grecia, Italia, No-ruega, Nueva Zelanda, Países Bajos y Reino Unido, al Arreglo sobre el Reconocimiento de los Certifica-dos de Criterios Comunes en el campo de la Seguridad de la Tecnología de la Información (en lo sucesi-vo 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.



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ón52 que fije el marco administrativo y regulatorio bajo el que se realiza la 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 aseguramiento53:

EAL0: sin garantías

EAL1: probado funcionalmente

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+54.

4.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:

52 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 evalua-ción y certificación de la seguridad de las tecnologías de información, de aplicación a productos y siste-mas en su ámbito.” El esquema nacional puede encontrarse en http://www.oc.ccn.cni.es/ .

53 EAL: Evaluation Assurance Level 54 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.



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 merca-do

• 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 realiza-

das en cualquier parte

Todos estos participantes convergen sobre un objeto a evaluar denominado TOE (Target Of Eva-luation), que no es sino 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.

4.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 de-nomina perfil de protección (PP – Protection Profile). Si no se está hablando de un sistema ge-né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 mercado55.

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 oferta56.

CC determina los apartados en que debe estructurarse un PP o un ST. El índice de estos docu-mentos es un buen indicador de su alcance:

55 Un ejemplo típico de PP podría ser aquel que fija las características de seguridad que se deben exigir a

un cortafuegos. 56 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.



PP- perfil de protección 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 Application notes Rationale

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

Los PP y los ST pueden ser a su vez sometidos a una evaluación formal que verifique su completi-tud 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.

4.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 ana-lista, 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 de seguridad y se subdividen en dos grandes grupos

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 Parte 3: Requisitos de garantía 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

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

4.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 cercio-rarse de que el PP o ST respecto del que se han certificado satisface los requisitos de nuestro sis-tema. 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 ries-go residuales bajo control.

En la medida en que un producto certificado se ajusta a un PP o ST que satisface nuestras nece-sidades, la gestión de riesgos se reduce a adquirir el producto, instalarlo y operarlo en las condi-ciones adecuadas.

Es importante destacar que tanto los PP como los ST incluyen una sección denominada “hipóte-sis” (assumptions) en la que se establecen una serie de prerrequisitos que debe satisfacer el en-torno operacional en el que se instala TOE. No se hace sino reconocer que el mejor producto, in-adecuadamente instalado u operado, es incapaz de garantizar la satisfacción de los objetivos glo-bales. Por ello, los productos certificados son componentes muy sólidos de un sistema; pero ade-más hay que garantizar su entorno para asegurar el sistema completo.

4.2.5. Terminología Debido a que su objetivo es servir de referencia internacional y sustentar evaluaciones y certifica-ciones, 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 evalua-ciones 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 catego-rí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 evalua-ció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.

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.

4.2.6. Referencias • “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.

• CC, “Common Criteria for Information Technology Security Evaluation”, Version 2.3, 2005.

• Part 1: Introduction and general model



• Part 2: Security functional requirements

• Part 3: Security assurance requirements

También publicados como norma ISO/IEC 15408:2005, partes -1, -2 y -3.

• ITSEC, European Commission, “Information Technology Security Evaluation Criteria”, ver-sion 1.2, 1991.

• TCSEC, Department of Defence, “Trusted Computer System Evaluation Criteria”, DOD 5200.28-STD, Dec. 1985.

Magerit versión 2 Herramientas


Apéndice 5. Herramientas La realización de un proyecto AGR 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 a los proyectos AGR 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 op-ción entre uno y otro planteamiento ha sido motivo de largo debate. Los modelos cualitativos ofre-cen resultados útiles antes que los modelos cuantitativos, simplemente porque la captura de datos cualitativa es más ágil que la cuantitativa57. 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 nece-sitan números.

Una opción mixta es útil: un modelo cualitativo para el sistema de información completo, con ca-pacidad de entrar en un modelo cuantitativo para aquellos componentes cuya protección va a re-querir 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 eje-cución de los programas. 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 progresi-va 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".

57 Hay que valorar activos y esta es una tarea de consenso. Tanto la valoración como la búsqueda del con-

senso son notablemente más rápidas si hay que determinar un orden de magnitud que si hay que deter-minar un número absoluto.



• 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 forma-tos 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

5.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 homogenei-dad 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, pre-sentá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 dife-rentes situaciones temporales. Típicamente se puede incorporar el resultado de los diferentes programas 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:

• Criterios de Seguridad, normalización y conservación

• UNE-ISO/IEC 17799:2002: sistemas de gestión de la seguridad

• RD 994/1999: datos de carácter personal

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.



5.2. Referencias CARVER

“Criticality, Accessibility, Recuperability, Vulnerability, Effect, and Recognizability”, National In-frastructure Institute’s Center for Infrastructure Expertise, USA.

COBRA “Security Risk Analysis & Assessment, and ISO 17799 / BS7799 Compliance”, C&A Systems Security Ltd, UK.

CRAMM “CCTA Risk Analysis and Management Method”. Insight Consulting. UK.

The CRAMM Risk Analysis and Management Method is owned, administered and main-tained by the Security Service on behalf of the UK Government.

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.

RIS2K Soporte de Magerit v1.0. Ministerio de Administraciones Públicas. España.

PILAR “Procedimiento Informático-Lógico para el Análisis de Riesgos”. Centro Nacional de Inteligen-cia. Ministerio de Defensa. España.

Magerit versión 2 Evolución de Magerit


Apéndice 6. Evolución de Magerit versión 1.0 La versión 1.0 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. Esta segunda versión no parte con ánimo de ruptura, sino que se plantea con ánimo de mejora, adaptándola al tiempo presente e incorporando la experiencia de estos años.

Las siguientes secciones servirán de guía dentro de la versión 2 a los profesionales familiarizados con la versión 1.

6.1. Libro I. Guía de aproximación a la seguridad de los sistemas de in-formación En estos años la consciencia de la necesidad de la seguridad ha avanzado enormemente y ya no se ha considerado necesario una aproximación tan general. La introducción es más sucinta y toda la guía se centra en el análisis y gestión de riesgos.

La Guía de Aproximación señalaba una serie de salvaguardas, denominadas mínimas, que siguen vigentes:

1. Documentación de la política de seguridad

2. Asignación de funciones y responsabilidades

3. Responsabilidades del usuario en el acceso

4. Proceso de selección

5. Comportamiento ante incidentes

6. Controles físicos de seguridad

7. Seguridad del equipamiento

8. Cumplimiento de obligaciones jurídicas

9. Protección, transporte y destrucción

10. Gestión externa de servicios

Todos ellos recogidos en el catálogo de salvaguardas que se incluye en el "Catálogo de Elemen-tos". Esta guía no pretende en cambio extenderse en estas salvaguardas, sino que prefiere referir al lector a la abundante bibliografía disponible, tanto técnica como de organismos internacionales de normalización.

6.2. Libro II. Guía de procedimientos El submodelo de elementos se respeta en su mayor parte, aunque se evita la voz submodelo en beneficio de una terminología más directa.

El término “vulnerabilidad” (de los activos frente a las amenazas), origen de algunas confusiones, se ha sustituido por una denominación genérica de “valoración de las amenazas” que, como an-tes, se traduce en dos medidas: frecuencia de ocurrencia y degradación del activo.

El concepto de impacto recibe un trato de primer rango, paralelo al de riesgo.

Los tipos de activos han merecido capítulo íntegro en el “Catálogo de Elementos”. En particular se recomienda no introducir como activos los valores intangibles de la Organización que se incorpo-rarán al modelo como criterios de valoración (también en capítulo íntegro en el “Catálogo de Ele-mentos”)



valorvalor

activosactivos amenazasamenazas

impactoimpacto

riesgoriesgo

degradacióndegradación

frecuenciafrecuencia

salvaguardassalvaguardas

riesgo residualriesgo residual

se materializan sobre losmide el interés de los

sufren una

causan una cierta

ocurren conuna cierta

permiten estimar el

permiten estimar el

mitigan el

limitanel perjuicio

reducenla ocurrencia(preventivas)

limitan el riesgo a un valor

El submodelo de procesos se ha redenominado “aproximación formal”. Las etapas de la versión 1.0 han evolucionado a procesos en esta versión 2.

La Etapa 1, “Planificación del análisis y gestión de riesgos”, se reproduce en el proceso P1, man-teniendo la estructura de actividades y tareas.

La Etapa 2, “Análisis de riesgos”, se ha reordenado en el proceso P2, con una estructuración más sistemática. Es explícito el análisis de las salvaguardas existentes. Se eleva la medida de impacto de mero paso intermedio a resultado final. Se formalizan los informes emitidos.

De la Etapa 3, “Gestión del riesgo”, la primera tarea, “Interpretación del riesgo”, pasa a ser el colo-fón del proceso P2, diferenciándola de la tarea de “Calificación de los riesgos” que si es parte del proceso P3.

Las etapas E3, “Gestión del riesgo”, y E4, “Selección de salvaguardas” se han condensado en el proceso P3 que se vertebra alrededor de la generación de un “Plan de Seguridad”, reconociendo que la selección e implantación de mecanismos de seguridad es frecuentemente objeto de proyec-tos de envergadura que conviene singularizar dentro de un marco estratégico que garantice la unidad de objetivo.

Globalmente, el proceso P2 se convierte en subsidiario del proceso P3, que recurrirá a aquel para todos los replanteamiento evolutivos; o sea, recálculo de los valores residuales de impacto y ries-go.

6.3. Libro III. Guía de técnicas Se ha aligerado notablemente, manteniéndose los procesos Delphi de valoración en escenarios de incertidumbre, las técnicas gráficas y los modelos de cálculo mediante tablas y algoritmos, que se exponen con más detalle por ser técnicas específicas de los proyectos de análisis y gestión de riesgos.

Se presentan como libro anejo.

6.4. Libro IV. Guía para desarrolladores de aplicaciones El paso de Métrica v2.1 a Métrica v3.0 ha supuesto una completa revisión de este punto. Aquí aparece en el capítulo de “Desarrollo de Sistemas Informáticos”, enfatizando primero el desarrollo de aplicaciones aisladas y luego el proceso de desarrollo de sistemas de información completos.



6.5. Libro V. Guía para responsables del dominio protegible Toda esta información se ha distribuido en la nueva estructuración. Hay partes en la aproximación informal, en el método formal, en los consejos prácticos y en el "Catálogo de Elementos".

6.6. Libro VI. Arquitectura de la información y especificaciones de la in-terfaz para el intercambio de datos Se presentaba un modelo de datos orientado a una herramienta, lo que se ha considerado excesi-vo detalle para una guía metodológica.

Lo que si se incluye en esta nueva versión es una serie de especificaciones XML para el inter-cambio de información. Esta guía incluye la estructura para compartir modelos de valor (activos) y el "Catálogo de Elementos" incluye estructuras para compartir otros tipos de información.

6.7. Libro VII. Referencia de normas legales y técnicas Actualizada, pasa al apéndice 3 de esta guía.

Magerit versión 2 Caso práctico


Apéndice 7. Caso práctico A título de ejemplo, este apéndice analiza el caso de una unidad administrativa que utiliza siste-mas de información propios y de terceros para sus tareas internas y para prestar servicios de atención a los ciudadanos (administración electrónica).

El ejemplo sólo pretende ser ilustrativo, sin que el lector deba derivar mayores consecuencias o conclusión alguna de obligado cumplimiento. Incluso ante los mismos impactos y riesgos, las so-luciones pueden ser diferentes, sin poder extrapolarse ciegamente de una a otra circunstancia. En particular hay que destacar el papel de la Dirección de la Organización como último punto de deci-sión respecto de qué política adoptar para mantener impactos y riesgos bajo control.

Buena parte del texto que sigue presenta la situación en palabras “normales”, tal y como puede llegarle al equipo de trabajo a lo largo de las entrevistas. Es la misión de este equipo traducir el conocimiento adquirido a los términos formales definidos por esta metodología.

7.1. La historia La unidad objeto de estudio no es de nueva creación, sino que lleva años tramitando expedientes de forma local, antes manualmente, ahora por medio de un sistema informático propio. A este sis-tema informático se le ha añadido recientemente una conexión a un archivo central que funciona como “memoria histórica”: permite recuperar datos y conservar los expedientes cerrados. La últi-ma novedad consiste en ofrecer un servicio propio de la administración electrónica, en el que los usuarios pueden realizar sus tramitaciones vía web, usando su NIF como identificación, mas una contraseña personal. El mismo sistema de tramitación es usado localmente por un funcionario que atiende a los ciudadanos que se personan en las dependencias de la unidad.

El responsable del proyecto de administración electrónica, alarmado por las noticias aparecidas en los medios sobre la inseguridad de Internet, y sabiendo que un fallo en el servicio conllevaría un serio daño a la imagen de su unidad, asume el papel de promotor. En este papel escribe un infor-me interno58, dirigido al director de la unidad, en el que da cuenta de

• los medios informáticos con que se está trabajando y los que se van a instalar

• las incidencias acaecidas desde que la unidad existe

• las incertidumbres que le causa el uso de Internet para la prestación del servicio

En base a dicho informe argumenta la conveniencia de lanzar un proyecto AGR.

La dirección, convencida de la necesidad de tomar medidas antes de que ocurra una desgracia, crea un comité de seguimiento formado por los responsables de los servicios involucrados: aten-ción a usuarios, asesoría jurídica, servicios informáticos y seguridad física.

Se determina que el alcance del proyecto (actividad A1.2) será el servicio de tramitación electróni-ca, presencial y remoto. También se estudiará la seguridad de la información que se maneja: ex-pedientes. Respecto del equipamiento, se analizarán equipos y redes de comunicaciones. Se to-ma la decisión de dejar fuera del estudio elementos que pudieran ser relevantes en un análisis más detallado como pudieran ser los datos de identificación y autenticación de los usuarios de los sistemas, las áreas de trabajo del personal que los maneja, la sala de equipos (centro de proceso de datos) y las personas relacionadas con el proceso. Esta previsto lanzar un futuro proyecto AGR más detallado que profundice en dichos aspectos.

Explícitamente se excluirá la evaluación de la seguridad de los servicios subsidiarios que se em-plean. El análisis es local, circunscrito a la unidad que nos ocupa. Dichos servicios remotos se consideran, a efectos de este análisis, “opacos”; es decir, que no entraremos en analizar cómo se prestan.

58 Como es habitual, en estas fases iniciales el proyecto no esté formalizado; no obstante, se está realizan-

do el “Informe Preliminar” resultado de la actividad “A1.1. Estudio de oportunidad”.



El lanzamiento del proyecto (actividad A1.4) incluye una reunión de la dirección con el comité de seguimiento en la que se exponen los puntos principales del análisis somero realizado por el pro-motor que queda habilitado como director del proyecto AGR en el que participaran dos personas de su equipo junto con un contrato de asesoría establecido con una empresa consultora externa. Uno de los miembros del equipo interno tendrá un perfil técnico: ingeniero de sistemas. A la con-sultora externa se le exige identificar nominalmente a las personas que van a participar y firmar un acuerdo de confidencialidad.

El proyecto se anuncia internamente mediante comunicación general a todo el personal de la uni-dad y notificación personal a aquellas personas que se verán directamente afectadas. En estas comunicaciones se identifican las personas responsables del proyecto.

7.2. Proceso P2: Análisis de riesgos La fase de análisis de riesgos arranca con una serie de entrevistas a los responsables designados por el comité de seguimiento, entrevistas en las que participan

• la persona de enlace, como introductor

• el personal de la consultora externa como director de la entrevista

• el personal propio como secretario: acta de la reunión y recopilación de datos

Servicio de tramitación El servicio de tramitación se presta por medio de una aplicación informática desarrollada en el pa-sado sobre una base de datos. A esta aplicación se accede a través de una identificación local del usuario que controla sus privilegios de acceso. En la faceta de tramitación presencial, es la perso-na que está atendiendo al usuario final la que se identifica frente al sistema. En el caso de la tra-mitación remota, el el propio administrado quien se identifica.

Toda la tramitación incluye una fase de solicitud (y entrada de datos) y una fase de respuesta (y entrega de datos). El usuario realiza su solicitud y espera una notificación para recoger la respues-ta. La notificación es por correo, certificado en el caso de tramitación presencial, y electrónico en el caso de tramitación electrónica.

Iniciar una tramitación supone abrir un expediente que se almacena localmente en la oficina. También supone recabar una serie de datos del archivo central de información, datos que se co-pian localmente. Al cierre del expediente, los datos y un informe de las actuaciones realizadas se remiten al archivo central para su custodia, eliminándose la información de los equipos locales.

El personal de la unidad se identifica por medio de su cuenta de usuario, mientras que los usua-rios remotos se identifican por su NIF. En ambos casos el sistema requiere una contraseña para autenticarlos.

Por último, hay que destacar el papel que presta la mensajería electrónica en todo el proceso de tramitación, usado tanto como medio interno de comunicación entre el personal, y como meca-nismo de notificación a los usuarios externos. Como norma, no se debe emplear el correo como transporte de documentos; estos siempre serán servidos por medio de accesos web.

Servicio de archivo central En forma de intranet, se presta un servicio centralizado de archivo y recuperación de documentos. Los usuarios acceden por medio de una interfaz web local, que se conecta por medio de una red privada virtual con el servidor remoto, identificándose por medio de su NIF. Este servicio sólo está disponible para el personal de la unidad y para el empleado virtual que presta el servicio de trami-tación remota.

Equipamiento informático La unidad dispone de varios equipos personales de tipo PC situados dentro de los locales. Estos equipos disponen de un navegador web, de un cliente de correo electrónico sin almacenamiento local de los mensajes y un paquete ofimático estándar (procesador de textos y hoja de cálculo).



Existe una capacidad de almacenamiento local de información en el disco del PC, del que no se realizan copias de seguridad; es más, existe un procedimiento de instalación / actualización que borra el disco local y reinstala el sistema íntegro.

Los equipos no disponen de unidades de disco removible de ningún tipo: disquetes, CD, DVD, USB, etc.

Se dispone de un servidor de tamaño medio, de propósito general, dedicado a las tareas de:

• servidor de ficheros

• servidor de mensajería electrónica, con almacenamiento local y acceso vía web

• servidor de bases de datos: expedientes en curso e identificación de usuarios

• servidor web para la tramitación remota y para la intranet local

Comunicaciones Se dispone de una red de área local que cubre las dependencias de trabajo y la sala de equipos. Está explícitamente prohibida la instalación de módems de acceso remoto y redes inalámbricas, existiendo un procedimiento rutinario de inspección.

Existe una conexión a Internet, de ADSL, contratada a un operador comercial. Sobre este enlace se prestan múltiples servicios

• servicio (propio) de tramitación remota

• servicio de correo electrónico (como parte del servicio de tramitación remota)

• servicio (propio) de acceso a información

• red privada virtual con el archivo central

La conexión a Internet se realiza única y exclusivamente a través de un cortafuegos que limita las comunicaciones a nivel de red, permitiendo únicamente:

• el intercambio de correo electrónico con el servidor de correo

• el intercambio web con el servidor web

La red privada virtual con el archivo central utiliza una aplicación informática software. La red se establece al inicio de la jornada, cortándose automáticamente a la hora de cierre. En el estableci-miento los equipos terminales se reconocen mutuamente y establecen una clave de sesión para la jornada. No hay intervención de ningún operador local.

Hay una sensación de que muchos servicios dependen de la conexión a Internet. Además, en el pasado ha habido incidencias tales como cortes de servicio debidos a obras municipales y a una deficiente prestación del servicio por parte del proveedor. Por todo ello:

1. se ha establecido un contrato de servicio que establece un cierto nivel de calidad, por enci-ma del cual el operador debe abonar unas indemnizaciones pactadas de antemano en pro-porción al periodo de interrupción o a la lentitud (insuficiente volumen de datos transmitidos en periodos determinados de tiempo) del enlace.

2. se ha contratado con otro proveedor un enlace digital (RDSI) de respaldo, enlace que habi-tualmente no está establecido, pero que se activa automáticamente cuando el enlace ADSL se interrumpe durante más de 10 minutos

Durante la entrevista se descubre que estos enlaces se prestan sobre la misma acometida de red telefónica que presta los servicios de voz de la unidad.

Seguridad física El personal trabaja en los locales de la unidad, principalmente en zonas interiores, salvo una serie de terminales en los puntos de atención al público. El acceso a las zonas interiores está limitado a las horas de oficina, quedando cerrado con llave fuera de dicho horario. En horas de oficina hay un control de entrada que identifica a los empleados y registra su hora de entrada y de salida.



La sala de equipos es simplemente una habitación interior que permanece cerrada con llave, de la que es custodio el administrador de sistemas. La sala dispone de un sistema de detección y extin-ción de incendios que se revisa anualmente. Esta sala dista 50 metros de la canalización de agua más cercana.

Los locales de la unidad ocupan íntegramente la planta 4ª de un edificio de oficinas de 12 plantas. Los controles de acceso son propios de la unidad, no del edificio, que es de uso compartido con otras actividades. No hay ningún control sobre qué hay en el piso de arriba o en el piso de abajo.

7.2.1. Tarea T2.1.1. Identificación de activos Resultado de las anteriores entrevistas se determina trabajar59 con el siguiente conjunto de acti-vos60:

El sistema descrito es, evidentemente, más complejo; pero el número de activos significativos se ha reducido drásticamente para que el ejemplo sea realmente simple, centrado en la casuística típica que se desea ilustrar.

59 En este apéndice se utilizará la herramienta PILAR en su versión de análisis cualitativo. 60 La relación de activos agrupa a estos en tres capas (en negrita). La estructuración en capas es mero arti-

lugio de ordenación de la información. En cada capa se indican qué activos hay de cara tipo. Se ha em-pleado la relación del “Catálogo de Elementos”, capítulo “2. Tipos de activos”.



7.2.2. Tarea T2.1.2: Dependencias Teniendo en cuenta las dependencias para operar (disponibilidad) y de almacenamiento de datos (integridad y confidencialidad), se ha determinado la siguiente matriz de dependencias entre acti-vos:

[S_T

_pre

senc

ial]

[S_T

_rem

ota]

[D_e

xp]

[em

ail]

[arc

hivo

]

[SW

_exp

]

[PC

]

[SR

V]

[fire

wal

l]

[LA

N]

[AD

SL]

[S_T_presencial] √ √ √ √ √ √ √ [S_T_remota] √ √ √ √ √ √ √ √

[D_exp] √ √ √ √ √ [email] √ √ √ √

[archivo] √ √ √ [SW_exp]

[PC] [SRV]

[firewall] [LAN]

[ADSL]

Estas tablas se pueden representar gráficamente, cuidando de que no haya una saturación de dependencias; es decir, rara vez se puede presentar todo el sistema en un sólo gráfico. Para el caso de los datos de expedientes en curso, el gráfico de dependencias queda así:



7.2.3. Tarea T2.1.3: Valoración La dirección está preocupada por el potencial abuso de los procesos de tramitación, algunos de los cuales pueden incluir el abono de cantidades económicas importantes, bien a beneficio de la Organización, bien a beneficio de los usuarios. La existencia de un móvil económico puede incitar al abuso tanto al personal interno como a los usuarios remotos, existiendo una especial incomodi-dad relacionada con la impunidad de atacantes que pudieran perpetrar ataques desde cualquier remoto punto del planeta.

También hay una especial sensibilidad relativa a la disponibilidad de los servicios. En particular hay preocupación porque no se pudiera atender una demanda presencial.

Los servicios web a usuarios externos, se consideran “emblemáticos” y se quieren cuidar con es-mero para dar una imagen de modernidad, eficacia y vocación de servicio. Todo lo que suponga dar una mala imagen, bien porque no está disponible el servicio, bien porque se presta de forma errónea, bien porque las incidencias no son atendidas con presteza, ..., todas estas situaciones se quieren evitar en la medida de lo posible.

Las bases de datos locales hospedan información relativa a personas que quedarán adscritos al nivel medio dentro de la calificación de datos de carácter personal.

En vista de todo ello, se ha consensuado la siguiente valoración61 de los activos del sistema. Sólo se han valorado explícitamente los activos superiores del árbol de dependencias, que quedan de la siguiente manera:

dimensiones de seguridad activo [D] [I] [C] [A_S] [A_D] [T_S] [T_D]

[S_T_presencial] Tramitación presencial [5](1) [7](2) [6](3) [S_T_remota] Tramitación remota [3](4) [7](5) [6](6) [D_exp] Expedientes en curso [5](7) [6](8) [5](9) [5](10)

Concretamente, los niveles se han asignado por las siguientes razones (llamadas en la tabla ante-rior):

(1) [5.da] Probablemente cause la interrupción de actividades propias de la Organización con impacto en otras organizaciones

(2) [7.da] Probablemente cause una interrupción seria de las actividades propias de la Or-ganización con un impacto significativo en otras organizaciones [5.lro] Obligaciones legales: probablemente sea causa de incumplimiento de una ley o regulación

(3) [6.pi2] Información personal: probablemente quebrante seriamente la ley o algún re-glamento de protección de información personal

(4) [3.da] Probablemente cause la interrupción de actividades propias de la Organización (5) [7.da] Probablemente cause una interrupción seria de las actividades propias de la Or-

ganización con un impacto significativo en otras organizaciones [6.pi1] Información personal: probablemente afecte gravemente a un grupo de indivi-duos [5.lro] Obligaciones legales: probablemente sea causa de incumplimiento de una ley o regulación

(6) [6.pi2] Información personal: probablemente quebrante seriamente la ley o algún re-glamento de protección de información personal

(7) [5.da] Probablemente cause la interrupción de actividades propias de la Organización 61 Para cada activo se indica su valoración en cada dimensión de seguridad.

Como criterios de valoración se ha empleado el capítulo “4. Criterios de valoración” del “Catálogo de Ele-mentos”. Como dimensiones de seguridad se ha empleado la relación del capítulo “3. Dimensiones de valoración” del “Catálogo de Elementos”.



con impacto en otras organizaciones (8) [6.pi2] Información personal: probablemente quebrante seriamente la ley o algún re-

glamento de protección de información personal (9) [5.lro] Obligaciones legales: probablemente sea causa de incumplimiento de una ley o

regulación (10) [5.lro] Obligaciones legales: probablemente sea causa de incumplimiento de una ley o

regulación

Cuando esta valoración se propaga a través del árbol de dependencias62, resulta la siguiente tabla de valor acumulado en cada uno de los activos del sistema (se muestra sobre fondo blanco lo que es valor propio, y sobre fondo de color lo que es acumulado):

dimensiones de seguridad activo [D] [I] [C] [A_S] [A_D] [T_S] [T_D]

[S_T_presencial] Tramitación presencial [5] [7] [6] [S_T_remota] Tramitación remota [3] [7] [6] [D_exp] Expedientes en curso [5] [5] [6] [7] [5] [6] [5] [email] Mensajería electrónica [5] [7] [6] [archivo] Archivo histórico central [5] [5] [6] [7] [5] [6] [5] [SW_exp] Tramitación de expedientes [5] [5] [6] [7] [5] [6] [5] [PC] Puestos de trabajo [5] [5] [6] [7] [5] [6] [5] [SRV] Servidor [5] [5] [6] [7] [5] [6] [5] [firewall] Cortafuegos [5] [5] [6] [7] [5] [6] [5] [LAN] Red local [5] [5] [6] [7] [5] [6] [5] [ADSL] Conexión a Internet [5] [5] [6] [7] [5] [6] [5]

En este punto se obtiene el “Modelo de Valor”63 de la organización.

62 Ver “Guía de Técnicas” sección “2.2.1. Modelo cualitativo”. 63 Ver “Apéndice 4.1. Modelo de valor” del “Catálogo de Elementos”.



7.2.4. Actividad A2.2: Caracterización de las amenazas Siendo difícil, por no decir imposible, caracterizar lo que podría ocurrirle a los activos si no hubiera salvaguardas desplegadas, se recurre a una calificación estándar de las amenazas típicas sobre los activos teniendo en cuenta su naturaleza y su valor.

Con todas estas consideraciones, y a título ilustrativo, la siguiente tabla64 muestra las amenazas que se han considerado típicas para el caso de los expedientes administrativos.

dimensiones de seguridad

activo / amenaza frecuencia D I C A_S A_D T_S T_D

[D_exp] Expedientes en curso 50% 50% 100% 100% 100% 100% 100%

[E.1] Errores de los usuarios 10 10% 10%

[E.2] Errores del administrador 1 20% 20% 10% 10% 10% 20% 20%

[E.3] Errores de monitorización (log) 1 50% 50%

[E.4] Errores de configuración 0,5 50% 10% 10% 50% 50% 50% 50%

[E.14] Escapes de información 1 1%

[E.15] Alteración de la información 10 1%

[E.16] Introducción de falsa información 100 1%

[E.17] Degradación de la información 10 1%

[E.18] Destrucción de la información 10 1%

[E.19] Divulgación de información 1 10%

[A.4] Manipulación de la configuración 0,1 50% 10% 50% 100% 100% 100% 100%

[A.11] Acceso no autorizado 100 10% 50% 50%

[A.14] Intercepción de información (escucha) 10 50%

[A.15] Modificación de información 10 50%

[A.16] Introducción de falsa información 20 50%

[A.17] Corrupción de la información 10 50%

[A.18] Destrucción de la información 10 50%

[A.19] Divulgación de información 10 100%

Nótese que hay una diferencia entre la percepción del usuario y las amenazas potenciales en el sistema. Esta diferencia se debe a la existencia de salvaguardas, que se tendrá en cuenta más adelante.

En este punto se obtiene el “Mapa de Riesgos”65 de la organización.

64 La primera columna muestra las amenazas típicas sobre el activo. La segunda columna recoge la fre-

cuencia de ocurrencia expresada como tasa anual (incidencias por año). Las demás columnas recogen la degradación del activo expresada como porcentaje de su valor. Hay una columna por dimensión de seguridad (véase “Catálogo de Elementos”, capítulo “3. Dimensiones de valoración”).

65 Ver “Apéndice 4.2. Mapa de riesgos” del “Catálogo de Elementos”.



7.2.5. Actividad A2.4: Estimación de impacto y riesgo Sin tener todavía en cuenta las salvaguardas, se derivan las siguientes estimaciones de impacto y riesgo acumulado sobre los diferentes activos. Las tablas siguientes recogen para cada activo (fi-las) la estimación de impacto y riesgo en cada dimensión de seguridad (columnas).

Impacto acumulado66

Riesgo acumulado67

66 Para el cálculo del impacto acumulado se sigue lo indicado en la sección “2.1.3. Paso 4: Determinación

del impacto”, donde se tiene en cuenta el valor acumulado sobre el activo (en la citada dimensión) y la degradación causada por la amenaza (en la citada dimensión). Véase también la sección “2.2.1. Modelo cualitativo” de la “Guía de Técnicas”.

67 Para el cálculo del riesgo acumulado se sigue lo indicado en la sección “2.1.4. Determinación del riesgo”, donde se incorpora la frecuencia estimada de ocurrencia de la amenaza. Se utiliza un modelo tabular si-milar al descrito en la sección “2.1. Análisis mediante tablas” de la “Guía de Técnicas”. Se utiliza una es-cala de {0} a {5} para calibrar el riesgo.



Impacto repercutido68 En estas tablas se analiza cada activo (superior) valorado en sí mismo (con valor propio) y se hace un seguimiento de aquellos otros activos (inferiores) de los que depende. Cuando las ame-nazas se materializan sobre los activos inferiores, el perjuicio repercute sobre los superiores.

68 Para el cálculo del impacto repercutido se sigue lo indicado en la sección “2.1.3. Paso 4: Determinación

del impacto”, donde se utiliza el valor propio del activo superior y la degradación causada por la amenaza sobre el activo inferior indicado.



Riesgo repercutido69

69 Para el cálculo del riesgo repercutido se sigue lo indicado en la sección “2.1.4. Determinación del riesgo”,

donde se incorpora la frecuencia estimada de ocurrencia de la amenaza sobre el activo inferior indicado.



7.2.6. Actividad A2.3: Caracterización de las salvaguardas A la hora de evaluar el estado de seguridad de la unidad bajo estudio, hay que indagar una serie de aspectos generales y una serie de aspectos específicos de cada activo. En esta indagación hay que tener en cuenta tanto la naturaleza de los activos como su valor y las amenazas a que está expuesto.

En aspectos generales hay que averiguar

• cómo se organiza la seguridad: responsables, toma de decisiones, contactos externos, etc.

• si hay una identificación de roles del personal, asociados a privilegios de acceso

• sí hay segregación efectiva de tareas

• si existe una política de seguridad documentada y revisada periódicamente

• cómo se gestionan las incidencias

• cómo se gestionan los registros de actividad

• si existe un plan de contingencia: gestión de emergencias, continuidad y recuperación

Respecto de los servicios prestados por la Organización, hay que averiguar

• si existe normativa y procedimientos de uso, conocidos y empleados

• si hay una planificación de capacidades

• si hay mecanismos de prevención del repudio

• si hay mecanismos de prevención de ataques de denegación de servicio

• cómo se gestionan los usuarios

• qué registro queda de lo que se hace

Respecto de los datos manejados por la Organización, hay que averiguar

• si hay un inventario de ficheros, con identificación de responsable


• si se hacen copias de respaldo y con qué calidad

• si se han previsto mecanismos para garantizar el secreto

• si se han previsto mecanismos para garantizar la integridad

• si se han previsto mecanismos de registro de acceso

Respecto de los aplicativos en uso, hay que averiguar

• cómo se gestiona su mantenimiento

• cómo se controla su configuración, en particular de usuarios y derechos de acceso

• si se ha inspeccionado el código, especialmente frente a puertas traseras de acceso

Respecto del servicio de mensajería (email), hay que averiguar


• cómo se gestionan los usuarios

• cómo se controla el contenido de los mensajes y de los ficheros adjuntos

• desde el punto de vista de fugas de información

• desde el punto de vista de inyección de programas dañinos (por ejemplo, virus)

• desde el punto de vista de autenticidad del origen

• cómo se asegura la disponibilidad del servicio



Respecto del servicio de archivo, hay que averiguar


• cómo se controla quién accede a su uso

• cómo se garantiza el secreto de los datos que transportan

• cómo se garantiza su disponibilidad

Respecto del equipamiento informático, hay que averiguar


• cómo se gestiona su mantenimiento

• cómo se controla su configuración, en particular de usuarios y derechos de acceso


Respecto de las comunicaciones, hay que averiguar


• cómo se controla quién accede a su uso

• cómo se garantiza el secreto de los datos que transportan


Tenga en cuenta el lector que esto es sólo un ejemplo que no pretende ser exhaustivo. Se han referenciado los aspectos más relevantes; no todos. Es especialmente de destacar la ausencia de un análisis de las instalaciones físicas y del personal, que han quedado fuera por mantener el ejemplo reducido..

Indagando se averigua que:

• Existe una política de seguridad heredada de la Organización matriz de la unidad que nos ocupa. Al ser una unidad de pequeñas dimensiones, existe un responsable único de seguri-dad que informa directamente a la Dirección y es el contacto frente a otras organizaciones. Además existe un procedimiento local de escalado de incidencias que puede provocar un escalado más allá de la propia unidad.

• El servidor central hospeda una tabla para controlar qué privilegios de acceso tiene cada usuario, en particular diferenciando la capacidad administrativa para dar curso a los expe-dientes a lo largo de su proceso. Toda la actividad se registra en un fichero al que sólo se tiene acceso el operador y que se remite diariamente al archivo central.

• Los procedimientos de trabajo con los sistemas no están escritos. Se confía en que las pro-pias aplicaciones web adapten las actividades que se pueden realizar en cada momento se-gún el estado del expediente en curso y los privilegios del usuario. Sí se realiza un registro de todas y cada una de las actuaciones del personal sobre los servicios web. Para el proce-so manual existen una serie de impresos disponibles con instrucciones incluidas sobre cuándo usarlos, qué datos proporcionar y cómo tramitarlos.

• Una persona de la unidad tiene las funciones de operador, encargándose de todas las ta-reas de instalación, configuración y resolución de incidencias. Esta persona dispone de pro-cedimientos escritos para las actividades rutinarias; pero debe improvisar en situaciones atí-picas, para las que puede recurrir al soporte técnico de la Organización matriz.

• No existe ningún plan de contingencia (más allá del proceso manual de las actividades).

• Existen contratos de mantenimiento con los suministradores de los equipos y de los progra-mas básicos: sistema operativo, ofimática, correo y servidores web.

• Los usuarios internos son administrados por el operador, que requiere solicitud por escrito de altas, bajas y cambios. Dicha solicitud debe venir firmada por el gerente.



• Los usuarios externos se dan de alta personalmente, indicando su NIF. Para recabar su con-traseña deben personarse físicamente la primera vez. Una vez registrados no se hace un seguimiento de las cuentas, que duran indefinidamente.

• Tanto los usuarios internos como externos se identifican por medio de un nombre de usuario y una contraseña. Todos reciben unas someras instrucciones sobre cómo elegir contrase-ñas; pero no se verifica que las cumplan, ni que las contraseñas se cambien regularmente.

• Se ha realizado recientemente una auditoría de los datos de carácter personal, habiendo si-do superada plenamente en todos los aspectos.

• Los datos procedentes del archivo central se consideran correctos. Los datos introducidos por los ciudadanos deben ser validados por el personal de la unidad. Los datos introducidos por los usuarios internos deben ser validados por un segundo usuario; normalmente los in-troduce una persona y los valida quien firma el progreso del expediente.

• El aplicativo de tramitación de expedientes es suministrado por la Organización matriz, con-siderándose “de calidad suficiente”.

• Se ha instalado un sistema anti-virus y se ha contratado un servicio de mantenimiento 24x7 a través de la Organización matriz con un tiempo de respuesta inferior a 1 día.

• El servicio de mensajería se centraliza en el servidor de forma que el acceso de los usuarios internos es a través de una interfaz web. Sistemáticamente se elimina todo tipo de anexo en el correo saliente y se analiza con el anti-virus los anexos del correo entrante.

• El servicio de archivo central es un servicio prestado externamente que se va a considerar “de calidad suficiente”. En un análisis más detallado habrá que entrar en la prestación de es-te servicio.

• Las comunicación a Internet responde a un contrato ADSL estándar, no habiéndose reali-zado un estudio de necesidades, ni estar prevista ninguna cláusula contractual de calidad de servicio o ampliación de capacidad.

• La conexión al archivo central se realiza sobre Internet, usando una red privada virtual que se establece entre los extremos. Esta red está configurada y mantenida desde el archivo central, sin tener capacidad local de configuración alguna. Se considerará “de calidad sufi-ciente”.

En este punto se obtiene la “Evaluación de Salvaguardas”70 de la organización.

Insuficiencias detectadas Cotejados los descubrimientos, se aprecian las siguientes insuficiencias:

• La segregación de tareas es adecuada excepto en el caso del administrador de sistemas que dispone de amplia capacidad de acceso a todos los sistemas, instalaciones y configura-ciones.

• Debería existir un plan de contingencia: gestión de emergencias, plan de continuidad y plan de recuperación.

• Deberían existir procedimientos escritos para todas las tareas ordinarias y para las inciden-cias previsibles, incluyendo todas las que se hayan dado en el pasado.

• Debería realizarse un estudio del uso de la conexión ADSL y su evolución para poder plani-ficar una ampliación de capacidad. También debería establecerse con el proveedor un acuerdo de calidad de servicio.

• Deberían establecerse mecanismos para detectar y reaccionar a un ataque de denegación de servicio.

70 Ver “Apéndice 4.3. Evaluación de salvaguardas” del “Catálogo de Elementos”.



• Debería hacerse un seguimiento de las cuentas de los usuarios externos, al menos detec-tando largos periodos de inactividad, intentos de penetración y comportamientos anómalos en general.

• El uso de contraseñas como mecanismo de autenticación se considera “débil”, recomen-dándose el uso de tarjetas criptográficas de identificación.

En este punto se obtiene el “Informe de Insuficiencias”71 de la organización.

7.2.7. Actividad A2.4: Estimación del estado de riesgo Conocidos el “Modelo de Valor”, el “Mapa de Riesgos” y la “Evaluación de Salvaguardas” se pro-cede a la estimación del los indicadores de impacto y riesgo, tanto acumulados (sobre los activos inferiores) como repercutidos (sobre los activos superiores).

Impacto acumulado residual72

Riesgo acumulado residual73

71 Ver “Apéndice 4.5. Informe de insuficiencias” del “Catálogo de Elementos”. 72 Para el cálculo del impacto residual se sigue lo indicado en la sección “2.1.6. Revisión del paso 4: impac-

to residual. Véase también la sección “2.2.1. Modelo cualitativo” de la “Guía de Técnicas”. 73 Para el cálculo del riesgo residual se sigue lo indicado en la sección “2.1.7. Revisión del paso 5: riesgo

residual. Véase también la sección “2.1. Análisis mediante tablas” de la “Guía de Técnicas”.



Impacto repercutido residual



Riesgo repercutido residual

En este punto se obtiene el “Estado de Riesgo”74 de la organización. Este “Estado de Riesgo” vie-ne documentado por el informe de “Evaluación de Salvaguardas” que recoge de despliegue actual de seguridad, y el “Informe de Insuficiencias”75 que recoge las debilidades descubiertas.

7.3. Proceso P3: Gestión de riesgos

7.3.1. Actividad A3.1: Toma de decisiones Vistos los indicadores de riesgo residual y las insuficiencias de la unidad, la Dirección decide clasi-ficar en los siguientes niveles los programas de seguridad a desarrollar:

De carácter urgente P1: Desarrollar un plan de contingencia

P2: Monitorizar y gestionar las cuentas de usuarios externos Consideraciones importantes P3.1: Documentar todos los procedimientos de trabajo, revisando los actuales y añadiendo los que falten

P3.2: Segregar las funciones del administrador de sistemas

74 Ver “Apéndice 4.4. Estado de riesgo” del “Catálogo de Elementos”. 75 Ver “Apéndice 4.5. Informe de insuficiencias” del “Catálogo de Elementos”.



Temas a considerar en el futuro • Uso de tarjetas de identificación

• Relaciones con el proveedor de comunicaciones para garantizar la calidad del servicio

• Contratación de un servicio alternativo de comunicaciones

• Medidas frente a ataques de denegación de servicio

7.3.2. Actividad A3.2: Plan de seguridad Todas las consideraciones anteriores hay que plasmarlas en un “Plan de Seguridad”76 que organi-za las actividades de forma planificada y gestionada.

El desarrollo del plan de contingencia (programa P1) se traduce en un proyecto específico para el que

1. este año se realizará una estimación de costes del proyecto y una solicitud de propuestas que se completará con la adjudicación a un contratista externo

2. a la vista de la oferta ganadora se destinarán fondos el año que viene para la realización del plan; en esta realización se incluirán todas las tareas administrativas (dimensionado, selec-ción de soluciones, procedimientos, etc.), exceptuándose las posibles ejecuciones de obra civil o contratación de servicios externalizados de continuidad, que serán objeto de futuras licitaciones

Para la monitorización de cuentas (programa P2) se lanza un proyecto para el desarrollo de un sistema de gestión de cuentas que incluya la detección de intrusiones y el lanzamiento de alar-mas. Se estima que este proyecto se puede lanzar inmediatamente y que su duración será de un año.

Para la documentación de todos los procedimientos (programa P3.1) se recurrirá a una ampliación del contrato de consultoría y asesoramiento que la Organización matriz tiene actualmente. En esta ampliación, consultores externos se encargarán de recabar la información pertinente, completando los manuales actuales. Esta tarea no se acometerá hasta el próximo ejercicio. En la elaboración de procedimientos se definirán las tareas específicas de un operador (local) y un administrador (remoto) de forma que se alcance el objetivo del programa P3.2. Se negocia con archivo central la disposición de un servicio centralizado de administración, dejando a nivel local las meras funcio-nes de operación.

Por último se recaba de la Organización matriz información sobre el uso de tarjetas de identifica-ción corporativas e incluso del DNI electrónico, como medios que pudieran utilizarse en el futuro para mejorar la autenticidad de los usuarios. Para el próximo ejercicio se contratará un estudio de las modificaciones requeridas para incorporar dichos mecanismos, tanto para los usuarios internos como para los usuarios externos. Parte de ese estudio será un plan detallado de realización, que en ningún caso se acometerá antes de dos años.

76 Ver “Apéndice 4.6. Plan de seguridad” del “Catálogo de Elementos”.



7.3.3. Evolución de los indicadores de impacto y riesgo Las siguientes figuras muestran la evolución de los indicadores de impacto y riesgo, acumulado y repercutido, en tres instantes de la gestión del sistema de información sometido a estudio:

• sin salvaguardas

• en el momento presente

• tras la ejecución de los programas P1, P2 y P3 del plan de seguridad

Impacto acumulado

Riesgo acumulado



Impacto repercutido

Riesgo repercutido



7.3.4. Calificación según los Criterios de Seguridad del CSAE Los “Criterios de Seguridad, Normalización y Conservación de las Aplicaciones Utilizadas para el Ejercicio de Potestades” proporcionan en su libro de “Criterios de Seguridad” una larga relación de salvaguardas que deben implantarse en los sistemas. La siguiente gráfica muestra el grado de satisfacción de dichos criterios a lo largo del desarrollo del plan de seguridad:

7.3.5. Calificación según la norma ISO/IEC 17799:2005 La norma ISO/IEC 17799:2005, “Code of practice for information security management”77, define una serie de controles recomendables para sistemas de gestión de la seguridad de la información (SGSI). La siguiente gráfica muestra el grado de satisfacción de dichos criterios a lo largo del de-sarrollo del plan de seguridad:

77 Cuando se edita este documento, no existe una traducción oficial de la norma; el texto de los epígrafes

puede ser diferente cuando se publique la traducción oficial.

MINISTERIO DE




II - Catálogo de Elementos



Magerit versión 2


Índice 1. Introducción ...................................................................................................................5 2. Tipos de activos.............................................................................................................6

2.1. Relación de tipos....................................................................................................................6 2.2. Datos de carácter personal ..................................................................................................11 2.3. Datos clasificados ................................................................................................................11

2.3.1. Ley de secretos oficiales ..............................................................................................13 2.4. Sintaxis XML ........................................................................................................................14 2.5. Referencias ..........................................................................................................................14

3. Dimensiones de valoración ........................................................................................16 3.1. Relación de dimensiones .....................................................................................................16 3.2. Sintaxis XML ........................................................................................................................17 3.3. Referencias ..........................................................................................................................18

4. Criterios de valoración................................................................................................19 4.1. Escala estándar....................................................................................................................20 4.2. Sintaxis XML ........................................................................................................................25 4.3. Referencias ..........................................................................................................................26

5. Amenazas .....................................................................................................................27 5.1. [N] Desastres naturales........................................................................................................27 5.2. [I] De origen industrial ..........................................................................................................28 5.3. [E] Errores y fallos no intencionados....................................................................................31 5.4. [A] Ataques intencionados....................................................................................................35 5.5. Correlación de errores y ataques .........................................................................................41 5.6. Amenazas por tipo de activos ..............................................................................................42

5.6.1. [S] Servicios..................................................................................................................42 5.6.2. [D] Datos / Información .................................................................................................43 5.6.3. [SW] Aplicaciones (software)........................................................................................43 5.6.4. [HW] Equipos informáticos (hardware) .........................................................................43 5.6.5. [COM] Redes de comunicaciones ................................................................................44 5.6.6. [SI] Soportes de información ........................................................................................44 5.6.7. [AUX] Equipamiento auxiliar .........................................................................................45 5.6.8. [L] Instalaciones............................................................................................................45 5.6.9. [P] Personal ..................................................................................................................45 5.6.10. Disponibilidad .............................................................................................................46

5.7. Sintaxis XML ........................................................................................................................46 5.8. Referencias ..........................................................................................................................47

6. Salvaguardas ...............................................................................................................48 6.1. Salvaguardas de tipo general...............................................................................................48 6.2. Salvaguardas para la protección de los servicios ................................................................49 6.3. Salvaguardas para la protección de los datos / información................................................49 6.4. Salvaguardas para la protección de las aplicaciones (software) .........................................50 6.5. Salvaguardas para la protección de los equipos (hardware) ...............................................50 6.6. Salvaguardas para la protección de las comunicaciones ....................................................50 6.7. Seguridad física....................................................................................................................51 6.8. Salvaguardas relativas al personal ......................................................................................51 6.9. Externalización .....................................................................................................................51 6.10. Referencias ........................................................................................................................52

Apéndice 1. Notación XML..............................................................................................53 Apéndice 2. Fichas ..........................................................................................................54 Apéndice 3. Modelo de valor ..........................................................................................82

3.1. Formato XML........................................................................................................................82 Apéndice 4. Informes.......................................................................................................84

4.1. Modelo de valor....................................................................................................................84 4.2. Mapa de riesgos...................................................................................................................84 4.3. Evaluación de salvaguardas ................................................................................................85

Magerit versión 2


4.4. Estado de riesgo ..................................................................................................................85 4.5. Informe de insuficiencias......................................................................................................85 4.6. Plan de seguridad ................................................................................................................86



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 espe-cí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 de análisis y gestión.

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.

Magerit versión 2 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. Consulte las refe-rencias.

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. Relación de tipos [S] Servicios

Función que satisface una necesidad de los usuarios (del servicio). Para la prestación de un ser-vicio se requieren una serie de medios.

Los servicios aparecen como activos de un análisis de riesgos bien como servicios finales (pres-tados por la Organización a terceros), bien como servicios instrumentales (donde tanto los usua-rios como los medios son propios), bien como servicios contratados (a otra organización que los proporciona con sus propios medios).

Así se encuentran servicios públicos prestados por la Administración para satisfacer necesidades de la colectividad; servicios empresariales prestados por empresas para satisfacer necesidades de sus clientes; servicios internos prestados por departamentos especializados dentro de la Or-ganización, que son usados por otros departamentos u empleados de la misma; etc.

Al centrarse esta guía en la seguridad de las tecnologías de la información y las comunicaciones, es natural que aparezcan servicios de información, servicios de comunicaciones, servicios de seguridad, etc. sin por ello ser óbice para encontrar otros servicios requeridos para el eficaz des-empeño de la misión de la organización. [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 (usuarios y medios de la propia organización) [cont] contratado a terceros (se presta con medios ajenos) [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); permi-tiendo la identificación y facilitando los atributos que caracterizan al elemento determinado.

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 res-pecto de la organización.

3. Servicios asociados a sistemas de criptografía de clave pública, incluyendo especialmente la gestión de certificados.



[D] Datos / Información Elementos de información que, de forma singular o agrupados de alguna forma, representan el conocimiento que se tiene de algo.

Los datos son el corazón que permite a una organización prestar sus servicios. Son en cierto sentido un activo abstracto que será almacenado en equipos o soportes de información (normal-mente agrupado en forma de bases de datos) o será transferido de un lugar a otro por los medios de transmisión de datos.

Es habitual que en un análisis de riesgos e impactos, el usuario se limite a valorar los datos, siendo los demás activos meros sirvientes que deben cuidar y proteger los datos que se les en-comiendan. [vr] datos vitales (vital records) (1) [com] datos de interés comercial (2) [adm] datos de interés para la administración pública [int] datos de gestión interna [voice] voz [multimedia] multimedia [source] código fuente [exe] código ejecutable [conf] datos de configuración [log] registro de actividad (log) [test] datos de prueba [per] datos de carácter personal (3) [A] de nivel alto [M] de nivel medio [B] de nivel básico [label] datos clasificados (4) [S] secreto [R] reservado [C] confidencial [DL] difusión limitada [SC] sin clasificar

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 pueden iden-tificar aquellos que son imprescindibles para que la Organización supere una situació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 aquellos que tienen valor para la prestación de los servicios propios de la organiza-ción.

3. Dícese de cualquier información concerniente a personas físicas identificadas o identificables. 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.

4. 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 determinadas por regulaciones sectoriales, por acuerdos entre organizaciones o por normativa interna.



[SW] Aplicaciones (software) 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 aplica-ciones 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. [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 [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 [ts] servidor de terminales [backup] sistema de backup



[HW] Equipos informáticos (hardware) Dícese de bienes materiales, físicos, destinados a soportar directa o indirectamente los servicios que presta la organización, siendo pues depositarios temporales o permanentes de los datos, soporte de ejecución de las aplicaciones informáticas o responsables del procesado o la transmi-sión de datos. [host] grandes equipos (1) [mid] equipos medios (2) [pc] informática personal (3) [mobile] informática móvil (4) [pda] agendas electrónicas [easy] fácilmente reemplazable (5) [data] que almacena datos (6) [peripheral] periféricos [print] medios de impresión (7) [scan] escáneres [crypto] dispositivos criptográficos [network] soporte de la red (8) [modem] módems [hub] concentradores [switch] conmutadores [router] encaminadores [bridge] pasarelas [firewall] cortafuegos [wap] punto de acceso wireless [pabx] centralita telefónica

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 como 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 imponer solamente unos requerimientos mínimos como entorno de operación. Son fácilmente reempla-zables 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 que, en caso de avería temporal o definitiva pueden ser reemplazados pronta y económicamente.

6. Son aquellos equipos en los que los datos permanecen largo tiempo. En particular, se clasifi-carán de este tipo aquellos equipos que disponen de los datos localmente, a diferencia de aquellos que sólo manejan datos en tránsito.

7. Dícese de impresoras y servidores de impresión. 8. Dícese de equipamiento necesario para transmitir datos: routers, módems, etc.



[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. [PSTN] red telefónica [ISDN] rdsi (red digital) [X25] X25 (red de datos) [ADSL] ADSL [pp] punto a punto [radio] red inalámbrica [sat] por satélite [LAN] red local [MAN] red metropolitana [Internet] Internet [vpn] red privada virtual

[SI] Soportes de información En este epígrafe se consideran dispositivos físicos que permiten almacenar información de forma permanente o, al menos, durante largos periodos de tiempo. [electronic] electrónicos [disk] discos [san] almacenamiento en red [disquette] disquetes [cd] cederrón (CD-ROM) [usb] dispositivos 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

[AUX] Equipamiento auxiliar En este epígrafe se consideran otros equipos que sirven de soporte a los sistemas de informa-ción, sin estar directamente relacionados con datos. [power] fuentes de alimentación [ups] sistemas de alimentación ininterrumpida [gen] generadores eléctricos [ac] equipos de climatización [cabling] cableado [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



[L] Instalaciones En este epígrafe entran los lugares donde se hospedan los sistemas de información y comunica-ciones. [site] emplazamiento [building] edificio [local] local [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

[P] Personal En este epígrafe aparecen las personas relacionadas con los sistemas de información. [ue] usuarios externos [ui] usuarios internos [op] operadores [adm] administradores de sistemas [com] administradores de comunicaciones [dba] administradores de BBDD [des] desarrolladores [sub] subcontratas [prov] proveedores

2.2. Datos de carácter personal La clasificación de los datos de carácter personal depende de la legislación aplicable en cada lu-gar y circunstancia. 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º 298, de 14 de diciembre de 1999)

• Real Decreto 994/1999, de 11 de junio, por el que se aprueba el Reglamento de medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal (B.O.E. Nº 151, de 25 de junio de 1999)

Esta legislación establece los siguientes criterios:

Nivel básico Datos de carácter personal: cualquier información concerniente a personas físicas identifica-das o identificables. LOPD artículo 3. RD artículo 4.1.

Nivel medio Datos de carácter personal relativos a la comisión de infracciones administrativas o penales, Hacienda Pública o servicios financieros. RD artículos 4.2 y 4.4.

Nivel alto Datos de carácter personal relativos a ideología, religión, creencias, origen racial, salud o vi-da sexual, así como los recabados para fines policiales sin consentimiento de las personas afectadas. RD artículo 4.3.

2.3. Datos clasificados La clasificación de datos es un procedimiento administrativo propio de cada organización o sector de actividad, que determina las condiciones de tratamiento de la información en función de la ne-cesidad de preservar su confidencialidad.

La Comunidad Europea se rige por

• 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)

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

en la que se establecen los siguientes niveles:

Secreto (Très secret UE / EU Top Secret) Esta clasificación se aplicará únicamente a la información y al material cuya divulgación no autorizada pueda causar un perjuicio excepcionalmente grave a los intereses esenciales de la Unión Europea o de uno o más de sus Estados miembros.

Si existe la probabilidad de que la puesta en peligro de materiales marcados TRÈS SECRET UE/EU TOP SECRET:

• amenace directamente la estabilidad interna de la UE o de alguno de sus Estados miem-bros o de países amigos;

• cause un perjuicio excepcionalmente grave a las relaciones con gobiernos amigos;

• ocasione directamente la pérdida generalizada de vidas humanas; • ocasione un daño excepcionalmente grave a la capacidad de funcionar efectivamente o a

la seguridad de las fuerzas de los Estados miembros o a las de otros contribuyentes, o haga que cese la efectividad de operaciones de seguridad o de inteligencia sumamente valiosas;

• ocasione un grave daño a largo plazo a la economía de la UE o de los Estados miem-bros.

Reservado (Secret UE) Esta clasificación se aplicará únicamente a la información y al material cuya divulgación no autorizada pueda suponer un perjuicio grave para los intereses de la Unión Europea o de uno o más de sus Estados miembros.

Si existe la probabilidad de que la puesta en peligro de materiales marcados SECRET UE: • cree tensiones internacionales;

• cause un perjuicio grave a las relaciones con gobiernos amigos;

• ponga vidas en peligro directamente o dañe gravemente el orden público o la seguridad o libertad individuales;

• ocasione un daño grave a la capacidad de funcionar efectivamente o a la seguridad de las fuerzas de los Estados miembros o a las de otros contribuyentes, o haga que cese la efectividad de operaciones de seguridad o de inteligencia sumamente valiosas;

• ocasione un considerable daño material a los intereses financieros, monetarios, económi-cos o comerciales de la UE o de uno de sus Estados miembros.

Confidencial (Confidentiel UE) Esta clasificación se aplicará a la información y al material cuya divulgación no autorizada pueda suponer un perjuicio para los intereses esenciales de la Unión Europea o de uno o más de sus Estados miembros.

Si existe la probabilidad de que la puesta en peligro de materiales marcados CONFIDEN-TIEL UE:

• perjudique las relaciones diplomáticas, es decir, ocasione una protesta formal u otras sanciones;

• perjudique la seguridad o libertad individuales;

• perjudique la capacidad de funcionar efectivamente o a la seguridad de las fuerzas de los Estados miembros o las de otros contribuyentes, o disminuya la efectividad de operacio-nes de seguridad o de inteligencia valiosas;



• menoscabe notablemente la viabilidad financiera de organizaciones importantes;

• impida la investigación de delitos graves o facilite su comisión;

• menoscabe notablemente los intereses financieros, económicos y comerciales de la UE o de sus Estados miembros;

• ponga graves obstáculos al desarrollo o al funcionamiento de políticas prioritarias de la UE;

• interrumpa o perturbe notablemente actividades importantes de la UE.

Difusión limitada (Restreint UE) Esta clasificación se aplicará a la información y al material cuya divulgación no autorizada pueda resultar desventajosa para los intereses de la Unión Europea o de uno o más de sus Estados miembros.

Si existe la probabilidad de que la puesta en peligro de materiales marcados RESTREINT UE:

• afecte desfavorablemente a las relaciones diplomáticas; • causar considerable sufrimiento a individuos;

• dificulte el mantenimiento de la eficacia operativa o la seguridad de las fuerzas de los Es-tados miembros o de otros contribuyentes;

• ocasione pérdidas financieras o facilite ganancias o ventajas indebidas a individuos o empresas;

• quebrante el debido esfuerzo por mantener la reserva de la información facilitada por ter-ceros;

• quebrante restricciones legales a la divulgación de información;

• dificulte la investigación o facilite la comisión de delitos;

• ponga en desventaja a la UE o a sus Estados miembros en negociaciones comerciales o en actuaciones de otra índole con terceros;

• ponga obstáculos al desarrollo o al funcionamiento efectivos de políticas prioritarias de la UE;

• menoscabe la adecuada gestión de la UE y sus operaciones.

2.3.1. Ley de secretos oficiales La normativa europea citada anteriormente recoge la normativa española previa, Ley y Reglamen-to de Secretos Oficiales, que regula los procedimientos y medidas necesarias para la protección de las “materias clasificadas”.

• Ley 48/1978 de 7 de octubre, que modifica la Ley 9/1968, de 5 de abril, sobre secretos ofi-ciales.

• 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 9/1968, de 5 de abril, reguladora de los Secretos Oficiales. La ley 9 determina:

Artículo 2. A los efectos de esta Ley podrán ser declaradas «materias clasificadas» los asuntos, actos, documentos, informaciones, datos y objetos cuyo conocimiento por personas no autorizadas pueda dañar o poner en riesgo la seguridad y defensa del Estado.

Artículo 3. Las «materias clasificadas» serán calificadas en las categorías de secreto y reservado en



atención al grado de protección que requieran.

Precisándose en el reglamento:

Articulo tercero, Materias clasificadas de «secreto» y de «reservado» I. La clasificación de «secreto» se aplicará a todas las materias referidas en el artículo anterior

que precisen del más alto grado de protección por su excepcional importancia y cuya reve-lación no autorizada por autoridad competente para ello, pudiera dar lugar a riesgos o per-juicios de la seguridad del Estado, o pudiera comprometer los Intereses fundamentales de la Nación en materia referente a la defensa nacional, la paz exterior o el orden constitucional.

II. La clasificación de «reservado» se aplicará a los asuntos, actos, documentos, informaciones, datos y objetos no comprendidos en el apartado anterior por su menor importancia, pero cu-yo conocimiento o divulgación pudiera afectar a los referidos intereses fundamentales de la Nación, la seguridad del Estado, la defensa nacional, la paz exterior o el orden constitucio-nal.

2.4. Sintaxis 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.

La notación se describe en el apéndice 1. tipos ::= <tipos> { tipo }* </tipos> tipo ::= <tipo código> #nombre# [ descripción ] { tipo }* </tipo> descripción ::= <descripcion> #texto# </descripcion>

Atributos Atributo Ejemplo Descripción

código C=”X” X es un identificador único que permite determinar unívocamente a qué tipo se refiere.

2.5. Referencias Existen numerosas fuentes que identifican activos dentro del ámbito de las tecnologías de la in-formación y las comunicaciones.

• GMITS, ISO/IEC IS 13335-1:2004, “Information technology - Security techniques - Guide-lines for the management of IT security - Part 1: Concepts and models for information and communications technology security management”.

• 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

• UNE-ISO/IEC 17799:2002, “Tecnología de la Información. Código de Buenas Prácticas de la



Gestión de la Seguridad de la Información”. 2002.


• GMITS, ISO/IEC TR 13335-5: 2001, “Information technology - Security techniques - Guide-lines for the management of IT security - Part 5: Management guidance of network security”

• GMITS, ISO/IEC TR 13335-4: 2000, “Information technology - Security techniques - Guide-lines for the management of IT security - Part 4: Selection of safeguards”

• GMITS, ISO/IEC TR 13335-3:1998, “Information technology - Security techniques - Guide-lines for the management of IT security - Part 3: Techniques for management of IT security” Publicado como UNE 71501-3.

• 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 • GMITS, ISO/IEC TR 13335-2:1997, “Information technology - Security techniques - Guide-

lines for the management of IT security - Part 2: Managing and planning IT security” Publicado como UNE 71501-2.

Magerit versión 2 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. Relación de dimensiones [D] disponibilidad Aseguramiento de que los usuarios autorizados tienen acceso cuando lo requieran a la información y sus activos asociados. ¿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 indisponibi-lidad 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 inte-rrupciones que no admiten recuperación: la organización está acabada.

[I] integridad de los datos Garantía de la exactitud y completitud de la información y los métodos de su procesamien-to. ¿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.

[C] confidencialidad de los datos Aseguramiento de que la información es accesible sólo para aquellos autorizados a tener acceso. ¿Qué importancia tendría que el dato fuera conocido por personas no autorizadas? Los datos reciben una alta valoración desde el punto de vista de confidencialidad cuando su revelació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.

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.



[A_S] autenticidad de los usuarios del servicio Aseguramiento de la identidad u origen. ¿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 autenti-cidad cuando su acceso por cualquiera no supone preocupación alguna.

[A_D] autenticidad del origen de los datos Aseguramiento de la identidad u origen. ¿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 cuando un defecto de imputación causaría graves quebrantos a la organización. Típicamente, se habilita 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.

[T_S] trazabilidad del servicio Aseguramiento de que en todo momento se podrá determinar quién hizo qué y en qué momento. ¿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 su-poner el incumplimiento de obligaciones legales.

[T_D] trazabilidad de los datos Aseguramiento de que en todo momento se podrá determinar quién hizo qué y en qué momento. ¿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 su-poner el incumplimiento de obligaciones legales.

3.2. Sintaxis 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.

La notación se describe en el apéndice 1. dimensiones ::= <dimensiones> { dimensión }* </dimensiones> dimensión ::= <dimension código> #nombre# [ descripción ]



</dimension> descripción ::= <descripcion> #texto# </descripcion>


código C=”X” X es un identificador único que permite determinar unívocamente a qué dimensión se refiere.

3.3. Referencias • ISO/IEC 13335-1:2004, “Information technology -- Security techniques -- Management of in-

formation and communications technology security -- Part 1: Concepts and models for infor-mation and communications technology security management”, 2004.

• C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”, Addison Wesley, 2003.

http://www.cert.org/octave/

• FIPS PUB 199, “Standards for Security Categorization of Federal Information and Informa-tion Systems”, December 2003.

http://csrc.nist.gov/publications/fips/index.html • ISO/IEC 17799:2000, “Information technology -- Code of practice for information security

management”, 2000.

• Ministerio de Administraciones Públicas, “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 7498-2:1989, “Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 2: Security Architecture”, 1989.

Magerit versión 2 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, permitiéndo 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; pero frecuentemente la valoración es cualitativa, quedando a discreción del usuario; es decir, respondiendo a criterios subjetivos.

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 5 niveles. Ambas escalas, detallada y simplifi-cada se correlacionan como se indica a continuación:

99

77

66

44

11

8 alto8 alto

5 medio5 medio

33

2 bajo2 bajo

despreciable0 despreciable0

10 muy alto10 muy alto

valor criterio 10 muy alto daño muy grave a la organización 7-9 alto daño grave a la organización 4-6 medio daño importante a la organización 1-3 bajo daño menor a la organización 0 despreciable irrelevante a efectos prácticos

La tabla siguiente pretende guiar con más detalle a los usuarios valorando de forma homogénea activos cuyo valor es importante por diferentes motivos, habiéndose tomado en consideración los siguientes:

• seguridad de las personas

• información de carácter personal4 • obligaciones derivadas de la ley, del marco regulatorio, de contratos, etc.

• capacidad para la persecución de delitos

• intereses comerciales y económicos

• pérdidas financieras

• interrupción del servicio

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.

4 La información de carácter personal se califica por dos vías: administrativa y valorada. La vía administra-tiva consiste en indicar a qué nivel pertenece el dato en cuestión; siendo esta una decisión cualitativa, las salvaguardas a emplear son independientes del valor que el dato en sí tenga para la organización. La vía valorada asigna un nivel a las consecuencias que para la organización tendría el deterioro del dato. De esta forma se distingue entre las obligaciones legales y los perjuicios para el servicio, sin obviar ninguno de estos aspectos, ambos importantes.



• orden público

• política corporativa

• otros valores intangibles Lo más normal es que un activo reciba una simple valoración en cada dimensión en la que es va-lioso. Este planteamiento puede y debe ser enriquecido en el caso de dimensiones más complejas como es el caso de la disponibilidad, en la que las consecuencias varían dependiendo del tiempo que dure la interrupción. En estos casos, la dimensión no recibe una única calificación, sino tantas como escalones se hayan considerado relevantes. Los criterios que siguen se aplican en cada escalón, pudiendo variar el motivo5.

4.1. Escala estándar va-lor

criterio

10 [olm] Probablemente cause un daño excepcionalmente serio a la eficacia o seguridad de la misión operativa o logística

[iio] Probablemente cause daños excepcionalmente graves a misiones extremadamente importantes de inteligencia o información

[si] Seguridad: probablemente sea causa de un incidente excepcionalmente serior de seguridad o dificulte la investigación de incidentes excepcionalmente serios

[ps] Seguridad de las personas: probablemente suponga gran pérdida de vidas humanas

[po] Orden público: alteración seria del orden constitucional

[ir] Probablemente cause un impacto excepcionalmente grave en llas relaciones interna-cionales

[lbl] Datos clasificados como secretos

5 Por ejemplo, una interrupción breve puede causar la desafección de los usuarios mientras que una inte-

rrupción larga puede llevar a penalizaciones por incumplimiento de obligaciones administrativas.



va-lor

criterio

9 [da] Probablemente cause una interrupción excepcionalmente seria de las actividades propias de la Organización con un serio impacto en otras organizaciones

[adm] Administración y gestión: probablemente impediría seriamente la operación efectiva de la organización, pudiendo llegar a su cierre

[lg] Probablemente causaría causaría una publicidad negativa generalizada por por afec-tar de forma excepcionalmente grave a las relaciones ...

[lg.a] a las relaciones con otras organizaciones

[lg.b] a las relaciones con el público en general [lg.c] a las relaciones con otros paises

[olm] Probablemente cause un daño serio a la eficacia o seguridad de la misión operativa o logística

[iio] Probablemente cause serios daños a misiones muy importantes de inteligencia o in-formación

[cei] Intereses comerciales o económicos: [cei.a] de enorme interés para la competencia

[cei.b] de muy elevado valor comercial

[cei.c] causa de pérdidas económicas excepcionalmente elevadas

[cei.d] causa de muy significativas ganancias o ventajas para individuos u organiza-ciones

[cei.e] constituye un incumplimiento excepcionalmente grave de las obligaciones contractuales relativas a la seguridad de la información proporcionada por ter-ceros

[lro] Obligaciones legales: probablemente cause un incumplimiento excepcionalmente grave de una ley o regulación

[si] Seguridad: probablemente sea causa de un serio incidente de seguridad o dificulte la investigación de incidentes serios

[ps] Seguridad de las personas: probablemente suponga la muerte de uno o más indivi-duos

[po] Orden público: alteración seria del orden público

[ir] Probablemente cause un serio impacto en las relaciones internacionales [lbl] Datos clasificados como reservados

8 [ps] Seguridad de las personas: probablemente cause daño a la seguridad o libertad indi-vidual (por ejemplo, es probable que llegue a amenazar la vida de uno o más indivi-duos)

[crm] Impida la investigación de delitos graves o facilite su comisión

[lbl] Datos clasificados como confidenciales



va-lor

criterio

7 [da] Probablemente cause una interrupción seria de las actividades propias de la Organi-zación con un impacto significativo en otras organizaciones

[adm] Administración y gestión: probablemente impediría la operación efectiva de la organi-zación

[lg] Probablemente causaría una publicidad negativa generalizada

[lg.a] por afectar gravemente a las relaciones con otras organizaciones

[lg.b] por afectar gravemente a las relaciones con el público en general

[lg.c] por afectar gravemente a las relaciones con otros paises [olm] Probablemente cause perjudique la eficacia o seguridad de la misión operativa o lo-

gística

[iio] Probablemente cause serios daños a misiones importantes de inteligencia o informa-ción

[cei] Intereses comerciales o económicos:

[cei.a] de alto interés para la competencia [cei.b] de elevado valor comercial

[cei.c] causa de graves pérdidas económicas

[cei.d] proporciona ganancias o ventajas desmedidas a individuos u organizaciones

[cei.e] constituye un serio incumplimiento de obligaciones contractuales relativas a la seguridad de la información proporcionada por terceros

[lro] Obligaciones legales: probablemente cause un incumplimiento grave de una ley o re-gulación

[si] Seguridad: probablemente sea causa de un grave incidente de seguridad o dificulte la investigación de incidentes graves

[ps] Seguridad de las personas: probablemente cause daños de cierta consideración a varios individuos

[ir] Probablemente cause un impacto significativo en las relaciones internacionales

[lbl] Datos clasificados como confidenciales

6 [pi1] Información personal: probablemente afecte gravemente a un grupo de individuos

[pi2] Información personal: probablemente quebrante seriamente la ley o algún reglamen-to de protección de información personal

[ps] Seguridad de las personas: probablemente cause daños de cierta consideración, res-tringidos a un individuo

[po] Orden público: probablemente cause manifestaciones, o presiones significativas

[lbl] Datos clasificados como de difusión limitada



va-lor

criterio

5 [da] Probablemente cause la interrupción de actividades propias de la Organización con impacto en otras organizaciones

[adm] Administración y gestión: probablemente impediría la operación efectiva de más de una parte de la organización

[lg] Probablemente sea causa una cierta publicidad negativa

[lg.a] por afectar negativamente a las relaciones con otras organizaciones

[lg.b] por afectar negativamente a las relaciones con el público

[olm] Probablemente merme la eficacia o seguridad de la misión operativa o logística más allá del ámbito local

[iio] Probablemente dañe a misiones importantes de inteligencia o información

[pi1] Información personal: probablemente afecte gravemente a un individuo

[pi2] Información personal: probablemente quebrante seriamente leyes o regulaciones

[lro] Obligaciones legales: probablemente sea causa de incumplimiento de una ley o regu-lación

[ir] Probablemente tenga impacto en las relaciones internacionales


4 [pi1] Información personal: probablemente afecte a un grupo de individuos

[pi2] Información personal: probablemente quebrante leyes o regulaciones [ps] Seguridad de las personas: probablemente cause daños menores a varios individuos

[crm] Dificulte la investigación o facilite la comisión de delitos




va-lor

criterio

3 [da] Probablemente cause la interrupción de actividades propias de la Organización

[adm] Administración y gestión: probablemente impediría la operación efectiva de una parte de la organización

[lg] Probablemente afecte negativamente a las relaciones internas de la Organización

[olm] Probablemente merme la eficacia o seguridad de la misión operativa o logística (al-cance local)

[iio] Probablemente cause algún daño menor a misiones importantes de inteligencia o in-formación


[cei.a] de cierto interés para la competencia

[cei.b] de cierto valor comercial

[cei.c] causa de pérdidas financieras o merma de ingresos

[cei.d] facilita ventajas desproporcionadas a individuos u organizaciones

[cei.e] constituye un incumplimiento leve de obligaciones contractuales para mante-ner la seguridad de la información proporcionada por terceros

[pi1] Información personal: probablemente afecte a un individuo

[pi2] Información personal: probablemente suponga el incumplimiento de una ley o regula-ción

[lro] Obligaciones legales: probablemente sea causa de incumplimiento leve o técnico de una ley o regulación

[si] Seguridad: probablemente sea causa de una merma en la seguridad o dificulte la in-vestigación de un incidente

[ps] Seguridad de las personas: probablemente cause daños menores a un individuo

[po] Orden público: causa de protestas puntuales

[ir] Probablemente cause un impacto leve en las relaciones internacionales [lbl] Datos clasificados como de difusión limitada

2 [lg] Probablemente cause una pérdida menor de la confianza dentro de la Organización


[cei.a] de bajo interés para la competencia [cei.b] de bajo valor comercial

[pi1] Información personal: pudiera causar molestias a un individuo

[pi2] Información personal: pudiera quebrantar de forma leve leyes o regulaciones

[ps] Seguridad de las personas: pudiera causar daño menor a varios individuos

[lbl] Datos clasificados como sin clasificar



va-lor

criterio

1 [da] Pudiera causar la interrupción de actividades propias de la Organización

[adm] Administración y gestión: pudiera impedir la operación efectiva de una parte de la or-ganización

[lg] Pudiera causar una pérdida menor de la confianza dentro de la Organización

[olm] Pudiera mermar la eficacia o seguridad de la misión operativa o logística (alcance lo-cal)

[iio] Pudiera causar algún daño menor a misiones importantes de inteligencia o informa-ción


[cei.a] de pequeño interés para la competencia

[cei.b] de pequeño valor comercial

[pi1] Información personal: pudiera causar molestias a un individuo

[lro] Obligaciones legales: pudiera causar el incumplimiento leve o técnico de una ley o regulación

[si] Seguridad: pudiera causar una merma en la seguridad o dificular la investigación de un incidente

[ps] Seguridad de las personas: pudiera causar daños menores a un individuo

[po] Orden público: pudiera causar protestas puntuales

[ir] Pudiera tener un impacto leve en las relaciones internacionales [lbl] Datos clasificados como sin clasificar

0 [1] no afectaría a la seguridad de las personas

[2] sería causa de inconveniencias mínimas a las partes afectadas

[3] supondría pérdidas económicas mínimas [4] no supondría daño a la reputación o buena imagen de las personas u organizaciones

4.2. Sintaxis 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.

La notación se describe en el apéndice 1. valoración ::= <valoracion> { nivel }* </valoracion> nivel ::= <nivel valor código> { ítem }* </nivel> ítem ::= <item> #descripción# </item>




valor V=”X” X es un índice entre 0 y 10 de valoración cualitativa de activos. código C=”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.3. Referencias • 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/

Magerit versión 2 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 tipo 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.

[N.1] Fuego Tipos de activos:

[HW] equipos informáticos (hardware) [COM] redes de comunicaciones [SI] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

Dimensiones: 1. [D] disponibilidad 2. [T_S] trazabilidad de los servicios 3. [T_D] trazabilidad de los datos

Descripción: incendios: posibilidad de que el fuego acabe con recursos del sistema.

[N.2] Daños por agua Tipos de activos:



Descripción: inundaciones: posibilidad de que el agua acabe con recursos del sistema.

[N.*] Desastres naturales Tipos de activos:





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.

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.

[I.1] Fuego Tipos de activos:



Descripción: incendio: posibilidad de que el fuego acabe con los recursos del sistema.

[I.2] Daños por agua Tipos de activos:



Descripción: escapes, fugas, inundaciones: posibilidad de que el agua acabe con los recursos del sistema.

[I.*] Desastres industriales Tipos de activos:



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.



[I.3] Contaminación mecánica Tipos de activos:

[HW] equipos informáticos (hardware) [COM] redes de comunicaciones [SI] soportes de información [AUX] equipamiento auxiliar


Descripción: vibraciones, polvo, suciedad, ...

[I.4] Contaminación electromagnética Tipos de activos:

[HW] equipos informáticos (hardware) [COM] redes de comunicaciones [SI] soportes de información (electróni-

cos) [AUX] equipamiento auxiliar


Descripción: interferencias de radio, campos magnéticos, luz ultravioleta, ...

[I.5] Avería de origen físico o lógico Tipos de activos:

[SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [SI] soportes de información [AUX] equipamiento auxiliar


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.

[I.6] Corte del suministro eléctrico Tipos de activos:

[HW] equipos informáticos (hardware) [COM] redes de comunicaciones [SI] soportes de información (electróni-

cos) [AUX] equipamiento auxiliar


Descripción: cese de la alimentación de potencia



[I.7] Condiciones inadecuadas de temperatura y/o humedad Tipos de activos:



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, ...

[I.8] Fallo de servicios de comunicaciones Tipos de activos:

[COM] redes de comunicaciones Dimensiones:

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.

[I.9] Interrupción de otros servicios y suministros esenciales Tipos de activos:

[AUX] equipamiento auxiliar Dimensiones:


otros servicios o recursos de los que depende la operación de los equipos; por ejemplo, papel para las impresoras, toner, refrigerante, ...

[I.10] Degradación de los soportes de almacenamiento de la información Tipos de activos:

[SI] soportes de información Dimensiones:

1. [D] disponibilidad 2. [T_S] trazabilidad de los servicios 3. [T_D] trazabilidad de los datos

Descripción: como consecuencia del paso del tiempo

[I.11] Emanaciones electromagnéticas Tipos de activos:

[HW] equipos informáticos (hardware) [COM] redes de comunicaciones [L] instalaciones

Dimensiones: 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.

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.

[E.1] Errores de los usuarios Tipos de activos:

[S] servicios [D] datos / información [SW] aplicaciones (software)

Dimensiones: 1. [I] integridad 2. [D] disponibilidad

Descripción: equivocaciones de las personas cuando usan los servicios, datos, etc.

[E.2] Errores del administrador Tipos de activos:

[S] servicios [D] datos / información [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

Dimensiones: 1. [D] disponibilidad 2. [I] integridad 3. [C] confidencialidad 4. [A_S] autenticidad del servicio 5. [A_D] autenticidad de los datos 6. [T_S] trazabilidad del servicio 7. [T_D] trazabilidad de los datos

Descripción: equivocaciones de personas con responsabilidades de instalación y operación

[E.3] Errores de monitorización (log) Tipos de activos:

[S] servicios [D] datos / información [SW] aplicaciones (software)

Dimensiones: 1. [T_S] trazabilidad del servicio 2. [T_D] trazabilidad de los datos

Descripción: inadecuado registro de actividades: falta de registros, registros incompletos, registros incorrec-tamente fechados, registros incorrectamente atribuidos, ...



[E.4] Errores de configuración Tipos de activos:


Dimensiones: 1. [D] disponibilidad 2. [I] integridad 3. [C] confidencialidad 4. [A_S] autenticidad del servicio 5. [A_D] autenticidad de los datos 6. [T_S] trazabilidad del servicio 7. [T_D] trazabilidad de los datos

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, encaminamiento, etc.

[E.7] Deficiencias en la organización Tipos de activos:

[P] personal Dimensiones:


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.

[E.8] Difusión de software dañino Tipos de activos:

[SW] aplicaciones (software) Dimensiones:

1. [D] disponibilidad 2. [I] integridad 3. [C] confidencialidad 4. [A_S] autenticidad del servicio 5. [A_D] autenticidad de los datos 6. [T_S] trazabilidad del servicio 7. [T_D] trazabilidad de los datos

Descripción: propagación inocente de virus, espías (spyware), gusanos, troyanos, bombas lógicas, etc.

[E.9] Errores de [re-]encaminamiento Tipos de activos:

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

Dimensiones: 1. [C] confidencialidad 2. [I] integridad 3. [A_S] autenticidad del servicio 4. [T_S] trazabilidad del servicio

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.



[E.10] Errores de secuencia Tipos de activos:


Dimensiones: 1. [I] integridad

Descripción: alteración accidental del orden de los mensajes transmitidos.

[E.14] Escapes de información Tipos de activos:

[D] datos / información [SW] aplicaciones (software) [COM] redes de comunicaciones


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.

[E.15] Alteración de la información Tipos de activos:

[D] datos / información Dimensiones:

1. [I] integridad 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.

[E.16] Introducción de información incorrecta Tipos de activos:



inserción accidental de información incorrecta.


[E.17] Degradación de la información Tipos de activos:



degradació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.

[E.18] Destrucción de información Tipos de activos:


1. [D] disponibilidad



Descripción: pérdida accidental de información.


[E.19] Divulgación de información Tipos de activos:


1. [C] confidencialidad Descripción:

revelación por indiscreción.

Incontinencia verbal, medios electrónicos, soporte papel, etc.

[E.20] Vulnerabilidades de los programas (software) Tipos de activos:


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.

[E.21] Errores de mantenimiento / actualización de programas (software) Tipos de activos:


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.

[E.23] Errores de mantenimiento / actualización de equipos (hardware) Tipos de activos:

[HW] equipos informáticos (hardware) Dimensiones:


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.

[E.24] Caída del sistema por agotamiento de recursos Tipos de activos:

[S] servicios [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

Dimensiones: 1. [D] disponibilidad

Descripción: la carencia de recursos suficientes provoca la caída del sistema cuando la carga de trabajo es desmesurada.



[E.28] Indisponibilidad del personal Tipos de activos:

[P] personal interno Dimensiones:


ausencia accidental del puesto de trabajo: enfermedad, alteraciones del orden público, guerra bacteriológica, ...

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.

[A.4] Manipulación de la configuración Tipos de activos:


Dimensiones: 1. [I] integridad 2. [C] confidencialidad 3. [A_S] autenticidad del servicio 4. [A_D] autenticidad de los datos 5. [T_S] trazabilidad del servicio 6. [T_D] trazabilidad de los datos 7. [D] 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, encaminamiento, etc.

[A.5] Suplantación de la identidad del usuario Tipos de activos:


Dimensiones: 1. [C] confidencialidad 2. [A_S] autenticidad del servicio 3. [A_D] autenticidad de los datos 4. [I] integridad

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.

[A.6] Abuso de privilegios de acceso Tipos de activos:

[S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

Dimensiones: 1. [C] confidencialidad 2. [I] integridad



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.

[A.7] Uso no previsto Tipos de activos:

[S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [SI] soportes de información [AUX] equipamiento auxiliar [L] instalaciones


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.

[A.8] Difusión de software dañino Tipos de activos:


1. [D] disponibilidad 2. [I] integridad 3. [C] confidencialidad 4. [A_S] autenticidad del servicio 5. [A_D] autenticidad de los datos 6. [T_S] trazabilidad del servicio 7. [T_D] trazabilidad de los datos

Descripción: propagación intencionada de virus, espías (spyware), gusanos, troyanos, bombas lógicas, etc.

[A.9] [Re-]encaminamiento de mensajes Tipos de activos:


Dimensiones: 1. [C] confidencialidad 2. [I] integridad 3. [A_S] autenticidad del servicio 4. [T_S] trazabilidad del servicio

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.



[A.10] Alteración de secuencia Tipos de activos:


Dimensiones: 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.

[A.11] Acceso no autorizado Tipos de activos:

[S] servicios [D] datos / información [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [SI] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

Dim1nsiones: 1. [C] confidencialidad 2. [I] integridad 3. [A_S] autenticidad del servicio

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.

[A.12] Análisis de tráfico Tipos de activos:

[COM] redes de comunicaciones Dimensiones:


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”.

[A.13] Repudio Tipos de activos:

[S] servicios Dimensiones:

1. [T_S] trazabilidad del servicio 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.



[A.14] Interceptación de información (escucha) Tipos de activos:

[D] datos / información [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones


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.

[A.15] Modificación de la información Tipos de activos:



alteración intencional de la información, con ánimo de obtener un beneficio o causar un perjui-cio. 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.

[A.16] Introducción de falsa información Tipos de activos:



inserción interesada de información falsa, con ánimo de obtener un beneficio o causar un per-juicio.


[A.17] Corrupción de la información Tipos de activos:



degradación intencional de la información, con ánimo de obtener un beneficio o causar un per-juicio.


[A.18] Destrucción la información Tipos de activos:



eliminación intencional de información, con ánimo de obtener un beneficio o causar un perjui-cio.




[A.19] Divulgación de información Tipos de activos:



revelación de información.

[A.22] Manipulación de programas Tipos de activos:


1. [C] confidencialidad 2. [I] integridad 3. [A_S] autenticidad del servicio 4. [A_D] autenticidad de los datos 5. [T_S] trazabilidad del servicio 6. [T_D] trazabilidad de los datos

Descripción: alteración intencionada del funcionamiento de los programas, persiguiendo un beneficio indi-recto cuando una persona autorizada lo utiliza.

[A.24] Denegación de servicio Tipos de activos:

[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.

[A.25] Robo Tipos de activos:


Dimensiones: 1. [D] disponibilidad 2. [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.



[A.26] Ataque destructivo Tipos de activos:



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.

[A.27] Ocupación enemiga Tipos de activos:


Dimensiones: 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.

[A.28] Indisponibilidad del personal Tipos de activos:



ausencia deliberada del puesto de trabajo: como huelgas, absentismo laboral, bajas no justifi-cadas, bloqueo de los accesos, ...

[A.29] Extorsión Tipos de activos:



Descripción: presión que, mediante amenazas, se ejerce sobre alguien para obligarle a obrar en determi-nado sentido.



[A.30] Ingeniería social Tipos de activos:



Descripción: abuso de la buena fe de las personas para que realicen actividades que interesan a un terce-ro.

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-rrelacionan6:

número error ataque 1 Errores de los usuarios 2 Errores del administrador 3 Errores de monitorización (log) 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 de la información Modificación de la información 16 Introducción de información incorrecta Introducción de falsa información 17 Degradación de la información Corrupción de la información 18 Destrucción de información Destrucción la información 19 Divulgación de información Divulgación de información

6 Se deja en blanco la columna “ataque” cuando la amenaza es simplemente por error. Se deja en blanco

la columna “error” cuando la amenaza siempre es deliberada.



número error ataque 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

de equipos (hardware)

24 Caída del sistema por agotamiento de recursos

Denegación de servicio

25 Robo 26 Ataque destructivo 27 Ocupación enemiga 28 Indisponibilidad del personal Indisponibilidad del personal 29 Extorsión 30 Ingeniería social

5.6. Amenazas por tipo de activos Para completar la anterior presentación amenaza por amenaza, los siguientes cuadros agrupan las amenazas según el tipo de activo, indicando en qué dimensión puede afectarles significativa-mente. Nótese que debido a las dependencias entre activos, los activos inferiores soportan el va-lor de los activos superiores, siendo aquellos la vía por la que resultan perjudicados estos.

5.6.1. [S] Servicios Las siguientes amenazas pueden materializarse sobre los activos de tipo [S], con consecuencias para la seguridad del sistema de información.

[D] [I] [C] [A_*] [T_*] E.1 E.2 E.4 E.24

E.1 E.2 E.4 E.9 E.10

E.2 E.4 E.9

E.2 E.4 E.9

E.2 E.3 E.4 E.9

A.4 A.7 A.24

A.4 A.5 A.6 A.9 A.10 A.11

A.4 A.5 A.6 A.9 A.11

A.4 A.5 A.9 A.11

A.4 A.9 A.13



5.6.2. [D] Datos / Información Las siguientes amenazas pueden materializarse sobre los activos de tipo [D], con consecuencias para la seguridad del sistema de información.

[D] [I] [C] [A_*] [T_*] E.1 E.2 E.3 E.18

E.1 E.2 E.3 E.15 E.16 E.17

E.2 E.3 E.14 E.19

E.2 E.4

E.2 E.3 E.4

A.4 A.18

A.4 A.11 A.15 A.16 A.17

A.4 A.11 A.14 A.19

A.4 A.11

A.4

5.6.3. [SW] Aplicaciones (software) Las siguientes amenazas pueden materializarse sobre los activos de tipo [SW], con consecuen-cias para la seguridad del sistema de información.

[D] [I] [C] [A_*] [T_*] I.5 I.5 E.1 E.2 E.4 E.8 E.20 E.21

E.1 E.2 E.4 E.8 E.9 E.10 E.20 E.21

E.2 E.4 E.8 E.9 E.14 E.20

E.2 E.4 E.8 E.9

E.2 E.3 E.4 E.8 E.9

A.4 A.7 A.8

A.4 A.5 A.6 A.8 A.9 A.10 A.11 A.22

A.4 A.5 A.6 A.8 A.9 A.11 A.14 A.22

A.4 A.5 A.8 A.9 A.11 A.22

A.4 A.8 A.9 A.22

5.6.4. [HW] Equipos informáticos (hardware) Las siguientes amenazas pueden materializarse sobre los activos de tipo [HW], con consecuen-cias para la seguridad del sistema de información.

[D] [I] [C] [A_*] [T_*] N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.5 I.6 I.7

I.11 N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.5 I.6 I.7



[D] [I] [C] [A_*] [T_*] E.2 E.4 E.23 E.24

E.2 E.4

E.2 E.4

E.2 E.4

E.2 E.4

A.4 A.7 A.24 A.25 A.26 A.27

A.4 A.6 A.11

A.4 A.6 A.11 A.14 A.25 A.27

A.4 A.11

A.4

5.6.5. [COM] Redes de comunicaciones Las siguientes amenazas pueden materializarse sobre los activos de tipo [COM], con consecuen-cias para la seguridad del sistema de información.

[D] [I] [C] [A_*] [T_*] N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.5 I.6 I.7 I.8

I.11 N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.5 I.6 I.7

E.2 E.4 E.24

E.2 E.4 E.9 E.10

E.2 E.4 E.9 E.14

E.2 E.4 E.9

E.2 E.4 E.9

A.4 A.7 A.24 A.25 A.26 A.27

A.4 A.5 A.6 A.9 A.10 A.11

A.4 A.5 A.6 A.9 A.11 A.12 A.14 A.25

A.4 A.5 A.9 A.11

A.4 A.9

5.6.6. [SI] Soportes de información Las siguientes amenazas pueden materializarse sobre los activos de tipo [SI], con consecuencias para la seguridad del sistema de información.


N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.5 I.6 I.7 I.10



[D] [I] [C] [A_*] [T_*] A.7 A.25 A.26 A.27

A.11 A.11 A.25 A.27

A.11

5.6.7. [AUX] Equipamiento auxiliar Las siguientes amenazas pueden materializarse sobre los activos de tipo [AUX], con consecuen-cias para la seguridad del sistema de información.


N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.5 I.6 I.7

A.7 A.25 A.26 A.27

A.11 A.11 A.25 A.27

A.11

5.6.8. [L] Instalaciones Las siguientes amenazas pueden materializarse sobre los activos de tipo [L], con consecuencias para la seguridad del sistema de información.

[D] [I] [C] [A_*] [T_*] N.1 N.2 N.* I.1 I.2 I.*

N.1 N.2 N.* I.1 I.2 I.*

A.7 A.26 A.27

A.11 A.11 A.27

A.11

5.6.9. [P] Personal Las siguientes amenazas pueden materializarse sobre los activos de tipo [P], con consecuencias para la seguridad del sistema de información.

[D] [I] [C] [A_*] [T_*] E.7 E.28

A.28 A.29 A.30

A.29 A.30

A.29 A.30

A.29 A.30



5.6.10. Disponibilidad Las siguientes amenazas pueden materializarse sobre diferentes tipos de activos, con consecuen-cias para la disponibilidad del sistema de información.

avería destrucción

física lógica

saturación carencia

[S] servicios E.1 E.2 E.3 A.4

A.7 E.24 A.24

[D] datos / infor-mación

E.1 E.2 E.18 A.18

E.1 E.2 E.4 A.4

[SW] aplicaciones (software)

I.5 E.1 E.2 E.4 E.20 E.21 A.4 E.8 A.8

A.7

[HW] equipos in-formáticos (hard-ware)

N.1 N.2 N.* I.1 I.2 I.* I.3 I.7 A.26 A.27

N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.5 I.7

I.4 E.2 E.4 A.4 E.23

A.7 E.24 A.24

I.6 A.25

[COM] redes de comunicaciones

N.1 N.2 N.* I.1 I.2 I.* I.3 I.7 A.26 A.27

N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.5 I.7

I.4 E.2 E.4 A.4

A.7 E.24 A.24

I.6 I.8 A.25

[SI] soportes de información

N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 I.7 I.10 A.26 A.27

N.2 I.2 I.3 I.4 I.5

A.7 I.6 A.25

[AUX] equipa-miento auxiliar

N.1 N.2 N.* I.1 I.2 I.* I.3 I.4 A.26 A.27

N.1 N.2 N.* I.1 I.2 I.2* I.3 I.4 I.5 I.7

A.7 I.6 I.9 A.25

[L] instalaciones N.1 N.2 N.* I.1 I.2 I.* A.26 A.27

N.1 N.2 N.* I.1 I.2 I.*

A.7

[P] personas E.7 E.28 A.28

5.7. Sintaxis 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.

La notación se describe en el apéndice 1. amenazas ::= <amenazas> { grupo }* </amenazas> grupo ::= <grupo> { grupo | amenaza }* [ descripción ]



</grupo> amenaza ::= <amenaza código_amenaza> #nombre# { dimensión }+ [ descripción ] </amenaza > dimensión ::= <dimension código_dimensión> descripción ::= <descripcion> #texto# </descripcion>


código_amenaza Z=”X” X es un identificador único que permite determinar unívocamente a qué amenaza se refiere.

código_dimensión D=”X” X es un identificador único que permite determinar unívocamente a qué dimensión se refiere.

5.8. Referencias Existen numerosas fuentes que catalogan amenazas dentro del ámbito de las tecnologías de la información y las comunicaciones.


• 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/




• 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

• GMITS, ISO/IEC TR 13335-2:1997, “Information technology - Security techniques - Guide-lines for the management of IT security - Part 2: Managing and planning IT security” Publicado como UNE 71501-2.

Magerit versión 2 Salvaguardas


6. Salvaguardas Las salvaguardas permiten hacer frente a las amenazas. Hay diferentes aspectos en los cuales puede actuar una salvaguarda para alcanzar sus objetivos de limitación del impacto y/o mitigación del riesgo:

[PR] procedimientos, que siempre son necesarios; a veces bastan procedimientos, pero otras veces los procedimientos son un componente de una salvaguarda más compleja. Se requie-ren procedimientos tanto para la operación de las salvaguardas preventivas como para la gestión de incidencias y la recuperación tras las mismas. Los procedimientos deben cubrir aspectos tan diversos como van del desarrollo de sistemas la configuración del equipamien-to.

[PER] política de personal, que es necesaria cuando se consideran sistemas atendidos por personal. La política de personal debe cubrir desde las fases de especificación del puesto de trabajo y selección, hasta la formación continua.

Soluciones técnicas, frecuentes en el entorno de las tecnologías de la información, que pue-den ser [SW] aplicaciones (software)

[HW] dispositivos físicos

[COM] protección de las comunicaciones

[FIS] seguridad física, de los locales y áreas de trabajo

La protección integral de un sistema de información requerirá una combinación de salvaguardas de los diferentes aspectos comentados, debiendo la solución final

1. estar equilibrada en los diferentes aspectos

2. tener en cuenta las salvaguardas adecuadas a cada tipo de activos

3. tener en cuenta las salvaguardas adecuadas a la dimensión de valor del activo

4. tener en cuenta las salvaguardas adecuadas a la amenaza a conjurar

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 determinar requisitos que deberán ser satisfechos por la solución práctica que se elija.

6.1. Salvaguardas de tipo general Son aquellas que se refieren al buen gobierno de la seguridad con efectos beneficiosos sobre to-do tipo de activos.

• Organización de la seguridad: roles, comités, ...

• Política corporativa de seguridad de la información

• Gestión de privilegios: adjudicación, revisión y terminación

• Procedimientos de escalado y gestión de incidencias

• Procedimientos de continuidad de operaciones: emergencia y recuperación



• Auditoría, registro (certificación) y acreditación del sistema

6.2. Salvaguardas para la protección de los servicios ciclo de vida protección del valor

• Especificación del servicio • Desarrollo del servicio

• Despliegue del servicio

• Operación del servicio

• Terminación del servicio

[A_S] → • Control de acceso

[T_S] →

• Registro de actuaciones

• Registro de incidencias

[D] →

• Plan de continuidad El control de acceso es un servicio de salvaguarda recurrente que se aplica en múltiples tipos de activos: acceso a los servicios, acceso a las aplicaciones, acceso al sistema operativo, acceso a los soportes de información, acceso físico a las instalaciones, etc. En todos ellos se requiere un sistema de identificación y autenticación que determine quién es el aspirante (sea persona u otro programa) y se coordine con el sistema de gestión de privilegios.

Los mecanismos de identificación y autenticación son múltiples y pueden combinarse de diferen-tes formas. Cabe destacar los siguientes:

• contraseñas: útil para sistemas que soportan poco riesgo, o como complemento a otros mecanismos

• certificados digitales: útil en sistemas expuestos a amenazas de repudio

• dispositivos (tokens o tarjetas): útil en sistemas que soportan riesgo elevado o requisi-tos de urgente disponibilidad

• características biométricas: útil para identificar personas, que no roles.

6.3. Salvaguardas para la protección de los datos / información organización protección del valor

• Carácter personal, si procede

• documento de seguridad

• Clasificación, si procede • Gestión de claves, si se emplea cifrado

[A_D] →

• Control de acceso

• Firma electrónica [T_D] →


• Registro de incidencias

[D] →

• Copias de respaldo [I] →

• Detección y recuperación

[C] →

• Cifrado (preventivo)

• Marcado (persecución)



6.4. Salvaguardas para la protección de las aplicaciones (software) ciclo de vida protección del valor

• Especificación funcional y no funcional

• Desarrollo • desarrollo seguro

• protección del código fuente

• Aceptación y puesta en operación

• Explotación

• gestión de cambios y configuración

• gestión de incidencias • Homologación / certificación / acreditación

[I] →

• Protección frente a código dañino: vi-rus, troyanos, puertas traseras, etc.

[A_S, A_D] →


[T_S, T_D] →


6.5. Salvaguardas para la protección de los equipos (hardware) seguridad física seguridad del sistema operativo • Inventario

• Control de entradas y salidas

• Destrucción

• Homologación / certificación / acreditación

• Configuración

• equipos internos

• equipos que salen de los locales

• Mantenimiento [I] →

• Protección frente a código dañino: vi-rus, espías, etc.

• detección de intrusión

• Registro de actuaciones • Gestión de privilegios


6.6. Salvaguardas para la protección de las comunicaciones ciclo de vida protección del valor

• Planificación de capacidad

• Adquisición y mantenimiento

• Configuración

• segregación de redes • configuración de routers

• configuración de cortafuegos

• Gestión de claves, si se emplea cifrado

• Detección de intrusión

• monitorización de uso

• [D] → Plan de continuidad

• [I] → Garantías de integridad

• [C] → Cifrado

• [A_S] → Control de acceso • [T_S] → Registro de actuaciones



6.7. Seguridad física protección de las instalaciones

• Protección frente a accidentes naturales

• terremotos, riadas, incendios, tormentas, etc. • Protección frente a accidentes industriales

• incendio, inundación, etc.

• contaminación mecánica: polvo, vibraciones

• contaminación electromagnética

• Protección frente a emanaciones electromagnéticas

• Protección del recinto: edificios, locales y áreas de trabajo • anuncio mínimo

• barreras físicas

• protección del cableado

• Control de acceso: entrada y salida de personas, equipos, soportes de información, etc.

6.8. Salvaguardas relativas al personal ciclo de vida

• Especificación del puesto de trabajo • Selección de personal

• Condiciones contractuales: responsabilidad en seguridad

• Formación continua

6.9. Externalización Es cada vez más flexible la frontera entre los servicios de seguridad prestados internamente y los servicios contratados a terceras partes:

• Desarrollo de aplicaciones o equipos

• Aplicaciones que ejecutan en otro lugar con acceso remoto (ASP – Application Service Pro-visioning)

• Mantenimiento de programas y equipos

• Seguridad gestionada: monitorización remota y gestión delegada de incidencias • Prestación de servicios de comunicaciones

• Prestación de servicios de custodia de datos / información

• etc.

En todos estos casos es fundamental cerrar los aspectos de relació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

6.10. Referencias • “Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para el

ejercicio de potestades”, MAP, 2004 http://www.csi.map.es/csi/pg5c10.htm

• Centro Criptológico Nacional. Instrucción Técnica de Seguridad de las TIC (CCN-STIC-302). Interconexión de CIS que manejen información clasificada nacional en la Administración”. Versión 1.2. Marzo de 2004.

• ISO/IEC TR 15446:2004, “Information technology -- Security techniques -- Guide for the pro-duction of Protection Profiles and Security Targets”.


• “COBIT Security Baseline”, ISACA, 2004. http://www.isaca.org/

• “IT Baseline Protection Manual”, Federal Office for Information Security (BSI), Germany. Oc-tober 2003. http://www.bsi.de/gshb/english/etc/index.htm

• “The Standard of Good Practice for Information Security”, ISF. 2003 http://www.isfsecuritystandard.com/index_ns.htm

• NIST Special Publication 800-53: “Recommended Security Controls for Federal Information Systems”. 31 October, 2003. http://csrc.nist.gov/publications/index.html

• DoD Instruction 8500-2p, “Information Assurance (IA) Implementation”. Feb. 2003. • UNE-ISO/IEC 17799:2002, “Tecnología de la Información. Código de Buenas Prácticas de la

Gestión de la Seguridad de la Información”. 2002.




• ISO/IEC 15408, “Information technology — Security techniques — Evaluation criteria for IT security”, 1999. http://www.commoncriteriaportal.org/



• 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

• GMITS, ISO/IEC TR 13335-2:1997, “Information technology - Security techniques - Guide-lines for the management of IT security - Part 2: Managing and planning IT security” Publicado como UNE 71501-2.

Magerit versión 2 Notación XML


Apéndice 1. Notación XML Las descripciones de formatos XML se ajustan a la siguiente notación de tipo BNF7:

• 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

7 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.

Magerit versión 2 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.

Para cada tipo de activo: • [D] datos / información

• [S] servicios

• [SW] aplicaciones (software)

• [HW] equipamiento informático (hardware)

• [COM] redes de comunicaciones

• [SI] soportes de información • [AUX] equipamiento auxiliar

• [L] instalaciones

• [P] personal

Reproduzca las fichas siguientes, una por activo, del tipo que corresponda.



[D] Datos / información [D] Datos / Información

código: nombre: descripción: propietario: responsable: tipo (marque todos los adjetivos que procedan):

( ) [vr] datos vitales (vital records)

( ) [com] datos de interés comercial ( ) [adm] datos de interés para la administración pública

( ) [int] datos de gestión interna

( ) [source] código fuente

( ) [exe] código ejecutable

( ) [conf] datos de configuración

( ) [log] registro de actividad (log)

( ) [test] datos de prueba

( ) [per] datos de carácter personal

( ) [A] de nivel alto

( ) [M] de nivel medio ( ) [B] de nivel básico

( ) [label] datos clasificados

( ) [S] secreto

( ) [R] reservado

( ) [C] confidencial ( ) [DL] difusión limitada

( ) [SC] sin clasificar



Valoración de los datos / información, típicamente en las siguientes dimensiones de seguridad:

[I] integridad

[C] confidencialidad [A_D] autenticidad de quién accede a los datos

[T_D] trazabilidad de quién accede a los datos, cuándo y qué hace

Valoración dimensión valor justificación

[I] [C]

[A_D] [T_D]



Dependencias de activos inferiores (hijos) activo: grado: ¿por qué?:

activo: grado: ¿por qué?:




[S] Servicios [S] Servicios

código: nombre: descripción: responsable: tipo (marque todos los adjetivos que procedan):

( ) [anon] anónimos (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 (usuarios y medios de la propia organización)

( ) [cont] contratado a terceros (se presta con medios ajenos)

( ) [www] world wide web

( ) [telnet] acceso remoto a cuenta local

( ) [email] correo electrónico

( ) [ftp] transferencia de ficheros ( ) [edi] intercambio electrónico de datos

( ) [dir] servicio de directorio

( ) [idm] gestión de identidades

( ) [ipm] gestión de privilegios

( ) [pki] PKI – infraestructura de clave pública



Valoración de los servicios que ofrece la Organización a otros, típicamente en las siguientes di-mensiones:

[D] disponibilidad [A_S] autenticidad de quién accede al servicio

[T_S] trazabilidad de quién accede al servicio, cuándo y que hace

Valoración dimensión valor justificación

[D] [A_S] [T_S]



[SW] Aplicaciones (software) [SW] Aplicaciones (software)

código: nombre: descripción: responsable: tipo (marque todos los adjetivos que procedan):

( ) [prp] desarrollo propio (in house)

( ) [sub] desarrollo a medida (subcontratado)

( ) [std] estándar (off the shelf)

( ) [browser] navegador web

( ) [www] servidor de presentación ( ) [email_client] cliente de correo electrónico

( ) [app] servidor de aplicaciones

( ) [file] servidor de ficheros

( ) [dbms] sistema de gestión de bases de datos

( ) [tm] monitor transaccional

( ) [office] ofimática ( ) [av] anti virus

( ) [backup] sistema de backup

( ) [os] sistema operativo



Valoración (si procede) dimensión valor justificación



[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):

( ) [host] grandes equipos

( ) [mid] equipos medios

( ) [pc] informática personal

( ) [mobile] informática móvil

( ) [pda] agendas personales ( ) [easy] fácilmente reemplazable

( ) [data] que almacena datos

( ) [peripheral] periféricos

( ) [print] medios de impresión

( ) [scan] escáneres ( ) [crypto] dispositivos criptográficos

( ) [network] soporte de la red

( ) [modem] módems

( ) [hub] concentradores

( ) [switch] conmutadores

( ) [router] encaminadores ( ) [bridge] pasarelas

( ) [firewall] cortafuegos

( ) [pabx] centralita telefónica



[COM] Redes de comunicaciones [COM] Redes de comunicaciones


( ) [PSTN] red telefónica

( ) [ISDN] rdsi (red digital)

( ) [X25] X25 (red de datos)

( ) [ADSL] ADSL

( ) [pp] punto a punto ( ) [radio] red inalámbrica

( ) [sat] satélite

( ) [LAN] red local

( ) [MAN] red metropolitana

( ) [Internet] Internet ( ) [vpn] red privada virtual



[SI] Soportes de información [SI] Soportes de información


( ) [electronic] electrónicos

( ) [disk] discos

( ) [disquette] disquetes

( ) [cd] cederrón (CD-ROM)

( ) [usb] dispositivos 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



[AUX] Equipamiento auxiliar [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 ( ) [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



[L] Instalaciones [L] Instalaciones


( ) [site] emplazamiento

( ) [building] edificio

( ) [local] local

( ) [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



[P] Personal [P] Personal

código: nombre: descripción: número: tipo (marque todos los adjetivos que procedan):

( ) [ue] usuarios externos

( ) [ui] usuarios internos

( ) [op] operadores

( ) [adm] administradores de sistemas

( ) [com] administradores de comunicaciones ( ) [dba] administradores de BBDD

( ) [des] desarrolladores

( ) [sub] subcontratas

( ) [prov] proveedores

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.

3.1. Formato XML modelo ::= <modelo> { dato }* { activo }* { dependencia }* { valoración }* </modelo> dato ::= <dato clave texto /> activo ::= <activo código> #nombre# { tipo }+ { dato }* </activo> tipo ::= <tipo tipo /> dependencia ::= <dependencia superior inferior grado /> valoración ::= <valoracion activo dimension valor />

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.

Magerit versión 2 Modelo de valor


atributo 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.

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.

4.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

4.2. Mapa de riesgos Relación de las amenazas a que están expuestos los activos.


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



4.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)


2. Salvaguardas (ver capítulo 5) Para cada salvaguarda, al nivel de detalle que se estime oportuno, indicación de su eficaciafrente a los riesgos a los que se enfrenta. Si procede, muéstrese la evolución histórica y la planificación actual.

4.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.


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.

4.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


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.



4.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

• 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




III - Guía de Técnicas





Í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 .................................................................................................13 2.2.3. Un modelo escalonado .................................................................................................17 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.1. Análisis coste-beneficio........................................................................................................26

3.1.1. Conceptos.....................................................................................................................26 3.1.2. Realización de un análisis coste / beneficio .................................................................26 3.1.3. Referencias...................................................................................................................29

3.2. Diagramas de flujo de datos (DFD)......................................................................................30 3.2.1. Descripción ...................................................................................................................30 3.2.2. Descomposición o explosión por niveles......................................................................31 3.2.3. Notación........................................................................................................................33 3.2.4. Consistencia de los diagramas de flujo de datos .........................................................37 3.2.5. Ejemplo de construcción...............................................................................................40 3.2.6. Utilización en el proyecto de análisis y gestión de riesgos...........................................44 3.2.7. Referencias...................................................................................................................44

3.3. Diagramas de procesos .......................................................................................................45 3.3.1. Conceptos.....................................................................................................................45 3.3.2. SADT (Structured Analysis and Design Technique).....................................................46 3.3.3. Utilización en el proyecto de análisis y gestión de riesgos...........................................48 3.3.4. Referencias...................................................................................................................49

3.4. Técnicas gráficas .................................................................................................................50 3.4.1. Diagramas de GANTT ..................................................................................................50 3.4.2. Por puntos y líneas .......................................................................................................52 3.4.3. Por barras .....................................................................................................................53 3.4.4. Gráficos de ‘radar’ ........................................................................................................54 3.4.5. Diagramas de Pareto....................................................................................................55 3.4.6. Diagramas de tarta .......................................................................................................59

3.5. Planificación de proyectos....................................................................................................60 3.5.1. Diagramas PERT..........................................................................................................60 3.5.2. Referencias...................................................................................................................63

3.6. Sesiones de trabajo..............................................................................................................64 3.6.1. Entrevistas ....................................................................................................................64 3.6.2. Reuniones.....................................................................................................................65 3.6.3. Presentaciones.............................................................................................................66 3.6.4. Referencias...................................................................................................................67

3.7. Valoración Delphi .................................................................................................................68 3.7.1. Resumen ejecutivo .......................................................................................................68 3.7.2. Aspectos sociológicos ..................................................................................................69 3.7.3. Análisis de las respuestas ............................................................................................70 3.7.4. Resumen ......................................................................................................................71 3.7.5. Referencias...................................................................................................................72



1. Introducción Este libro de técnicas completa la guía metodológica Magerit. Se presume el conocimiento y com-prensión de los conceptos de análisis y gestión de riesgos, según se exponen en la guía metodo-lógica.

El objetivo es describir las técnicas utilizadas en los proyectos de análisis y gestión de riesgos1. Se considera técnica al conjunto de heurísticas y procedimientos que se apoyan en estándares, es decir, que utilizan una o varias notaciones específicas en términos de sintaxis y semántica y cumplen unos criterios de calidad en cuanto a la forma de obtención del producto asociado. Las prácticas representan un medio para la consecución de unos objetivos específicos de manera rá-pida, segura y precisa, sin necesidad de cumplir unos criterios o reglas preestablecidas.

Para cada una de las técnicas y prácticas 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 pa-ra 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 ca-so 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 es-pecíficas de las distintas técnicas.

1 Varias de las técnicas referenciadas se han incorporado de Métrica versión 3.

Magerit versión 2 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áli-sis 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.

Magerit versión 2 Análisis tabular


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, perjudi-quen la visión de conjunto.

La experiencia ha demostrado la utilidad de métodos simples de análisis llevados a cabo por me-dio 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 mag-nitud 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 1% 10% 100%

MA M A MA

A B M A

M MB B M

B MB MB B

valor

MB MB MB MB

Aquellos activos que reciban una calificación de impacto muy alto (MA) deberían ser objeto de atención inmediata.

Magerit versión 2 Análisis tabular


Estimación del riesgo Por otra parte se modela la frecuencia por medio de alguna escala sencilla:

MF: muy frecuente (a diario) F: frecuente (mensual) FN: frecuencia normal (anual) PF: poco frecuente (cada varios años)

Pudiendo combinarse impacto y frecuencia en una tabla para calcular el riesgo:

frecuencia riesgo PF FN F MF

MA A MA MA MA

A M A MA MA

M B M A MA

B MB B M A

impacto

MB MB MB B M Aquellos activos que reciban una calificación de riesgo muy alto (MA) deberían ser objeto de aten-ción inmediata. Los que reciban una calificación de riesgo alto, deberían ser objeto de planifica-ción inmediata de salvaguardas.

2.1.1. Referencias • ISO/IEC 13335-1:2004 – Information technology – Guidelines for the management of IT se-

curity – Part 1: Concepts and models for Information and communications technology secu-rity management.

Magerit versión 2 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 ele-mentos 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 cualitati-vo 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 preci-sió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 valo-res.

Valores. En un análisis de riesgos es necesario poder valorar, al menos relativamente, los elementos invo-lucrados. 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 = { ..., v0, v1, ..., vi, ... } Esta serie de niveles satisface las siguientes propiedades:

• orden total: ∀ i, vi < vi+1

• existe un elemento singular, “v0”, que se denomina “despreciable”2.

Informalmente, se dice que un activo tiene “i puntos” para indicar que su valoración es “vi“3.

El valor de los activos. Cada activo, en cada dimensión, recibe un valor de la escala V. Las diferentes dimensiones de un análisis son independientes entre sí, mereciendo un activo una calificación de valor en cada una de las dimensiones.

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.

2 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 v0. 3 Si el lector lo desea, en este sistema de valoración, puede interpretar los puntos como órdenes de mag-

nitud; por ejemplo, interpretando vx como 10x.



E incluso puede dibujar figuras de diamante:

(A → B1) ∧ (A → B2) ∧ (B1→ C) ∧ (B2→ C) A depende de B1 y B2; B1 y B2 dependen de C.

A

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) = { Ai , Ai ⇒ 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), maxi {valor(Ai)})

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. Si un activo tiene un valor acumulado “vx“ y se degrada un porcentaje “d”, el valor del impacto será

impacto = vround(x × d)

Ejemplo. Si un activo vale “v8“ y se degrada un 90%, el impacto será “v7“:

round(8×0,9) = round(7,2) = 7

Cuando el impacto queda reducido a “v0”, 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 reper-cuten sobre A. Si B sufre una degradación “d”, eso mismo le ocu-rre a A, siendo el impacto sobre A la pérdida de su valor propio. Si A tiene un valor propio “vx“, el impacto es

impacto = vround(x × d)

Ejemplo. Si A vale “v5“ y depende de B (cuyo valor no interesa aquí) que se degrada un 20%, el impacto repercutido sobre A será “v1“:

round(5×0,2) = round(1,0) = 1

Cuando el impacto queda reducido a “v0”, se dice que el impacto es despreciable.

Frecuencia de una amenaza. Para caracterizar la frecuencia de las amenazas se usará una escala de valores simbólicos:

F = { ..., f0, f1, ..., fi, … } Es decir, una serie de niveles de frecuencia, que son los elementos o átomos de análisis.

Esta serie de niveles satisface las siguientes propiedades:

• orden total: ∀ j, fj < fj+1

• existe un elemento singular, “f0”, que se denomina “frecuencia despreciable”

• existe un elemento singular, “fn”, que se denomina “frecuencia normal”4

Informalmente, se dice que una amenaza tiene “j puntos de frecuencia” para indicar a que su fre-cuencia es “fj”.

Riesgo. El riesgo se mide por medio de la escala de valores, siendo una función del impacto y la frecuen-cia:

riesgo = ℜ(impacto, frecuencia)

función que hay que definir con los siguientes requisitos:

• crece con el valor: ∀ fi, ℜ(vi, fj) < ℜ(vi+1 , fj)

• crece con la frecuencia: ∀ vi, ℜ(vi, fj) < ℜ(vi , fj+1)

• ℜ(v0, fn) = v0

Una función sencilla que satisface estas propiedades es

ℜ(vi, fj) = vi+j-n

El riesgo es un valor, pudiendo tomar el valor “v0”, e incluso valores inferiores, en cuyo caso se entiende que el riesgo es “despreciable”.

4 Si se quiere hacer un estudio anualizado, fn se referirá a “una vez al año”.

activo Aactivo A

activo Bactivo B amenaza Z



Ejemplo. Si un activo vale “v8“ y se degrada un 90%, el impacto será “v7“:

round(8×0,9) = round(7,2) = 7

Si la frecuencia estimada para la amenaza es “f2“, y se considera “f3“ como frecuencia normal, entonces el riesgo será “v6“.

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.

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) y 1,0 (salvaguarda plenamente eficaz), valor que se puede des-componer en una eficacia frente al impacto, “ei”, y una eficacia frente a la frecuencia “ef”.

Degradación residual. Si el activo, sin protección, podía sufrir una degradación “d”, gracias a las salvaguardas la degra-dación se ve reducida a un valor residual “dr”:

dr = d × (1-ei) Donde “ei” es la medida de la eficacia de las salvaguardas disminuyendo la degradación de este activo (o sea, limitando el impacto sobre este activo). Los casos extremos son:

• si las salvaguardas no tienen efecto sobre este activo, ei= 0 y dr= d

• si las salvaguardas son ideales, ei= 1 y dr= 0

Ejemplo. Si un activo se ve degradado en un 66% (o sea, 2/3 de su valor); pero las salvaguardas son efi-caces en un 90%, la degradación residual es del 7%:

dr = 0,66 × (1-0,9) = 0,07

El impacto residual. El impacto residual se calcula como el impacto, pero utilizando la degradación residual:

impacto_residual = v round(x × dr)

Un paquete de salvaguardas perfectamente eficaz reduce el impacto a un valor residual “v0”, 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.

9

7

6

4

1

8

5

3

2

0

10

d= 90%d= 90%f= fn-1f= fn-1

valor

impacto

riesgo



La frecuencia residual. De forma similar al impacto, la frecuencia de la amenaza sobre el activo se ve reducida a un valor residual. Si la frecuencia era “fj”, ahora queda:

frecuencia_residual = fk para k = round(j × (1 − ef))

Siendo “ef” la eficacia de las salvaguardas mitigando la frecuencia 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.

Ejemplo. Sea un activo A de valor “v5“, que depende de otro activo B de valor “v8“. Sea una amenaza sobre el activo B que lo degrada un 90%, con una frecuencia estimada “f2“, siendo “f3“ la frecuencia normal.

Sobre este sistema se despliega un paquete de salvaguardas que reduce el impacto en un 50% y la frecuencia de ocurrencia en otro 50%.

Los cálculos arrojan los siguientes indicadores:

sobre A sobre B valor acumulado: v5

impacto repercutido: v4 riesgo repercutido: v3 degradación residual: 45% impacto residual: v2 frecuencia residual: f1 riesgo residual: v0

valor acumulado: v5 + v8 = v8 impacto acumulado: v7 riesgo acumulado: v6 degradación residual: 45% impacto residual: v3 frecuencia residual: f1 riesgo residual: v1

Resumen En este modelo, denominado cualitativo, se han posicionado los activos en una escala de valor relativo, definiendo arbitrariamente un valor “v0” 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.

Las estimaciones de impacto y riesgo residual incorporan la eficacia de las salvaguardas para en-frentarse a la amenaza, bien limitando el impacto, “ei”, bien reduciendo la frecuencia, “ef”.

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 frecuencia 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 la escala 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, “v0“, representa la frontera entre los valores que son desprecia-bles 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 indepen-dientes) y 1,0 (activos con dependencia absoluta). A este coeficiente se le denomina grado de de-pendencia.

Como la dependencia puede ser directa o indirecta, se calculará del cierre transitivo de las depen-dencias 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 ⇒ Bi) × grado(Bi → C) }

Donde las sumas se realizan de acuerdo con esta fórmula:

a + b = 1 − (1 − a) × (1 − b)5

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 5 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 necesi-dad 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%.

50%

30%

15%

50%

30%

15%

100%

50%

65%

100%

30%

100%

50%

65%

100%

30%

50%

55%

50%

30%

50%

55%

50%

30%



o indirectamente de B:

SUP(B) = { Ai , Ai ⇒ B } Se define el valor acumulado sobre B como la suma (tradicional) de valores de los activos superio-res, ponderados por el grado de dependencia:

valor_acumulado(B) = valor(B) +Σi { valor(Ai) × grado(Ai ⇒ 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 degrada-ció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 acumula-do es de cuantía 900.000.

Cuando el impacto queda reducido a “v0”, 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 de-gradació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)

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 “v0”, o menos, se dice que el impacto es despreciable.

Frecuencia de una amenaza. La frecuencia de una amenaza es un valor real superior a cero.

Se determina un valor “f0“ como frecuencia “despreciable”, por debajo de la cual la amenaza no merece ser tomada en consideración.

Riesgo. El riesgo se calcula como

riesgo = impacto × frecuencia

Es un valor real, mayor que cero.

Se determina un umbral “r0“ por debajo del cual el riesgo es “despreciable”, que es

r0 = v0



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, cu-ya 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 des-componer en una eficacia frente al impacto, “ei”, y una eficacia frente a la frecuencia “ef”, de forma que

(1 − ei) × (1 − ef) = 1 − e6

Degradación residual. Es la parte de la degradación que no consigue contrarrestar la eficacia del paquete de salvaguar-das aplicado.

El impacto residual.

Un sistema de salvaguardas absolutamente ineficaz (ei = 0) deja el impacto donde estaba, mien-tras que un sistema de salvaguardas plenamente eficaz (ei = 1) reduce el impacto a 0. En forma de cálculo:

impacto_residual = impacto x (1 – ei)


1.000.000 x 90% = 900.000

Si las salvaguardas tienen un 90% de eficacia sobre el impacto, el impacto residual es

900.000 x (1 – 0,9) = 90.000 El impacto acumulado se realiza con los datos de impacto acumulado sobre un activo y las salva-

6 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, es-tando al tiempo acotado al rango [0%..100%].



guardas 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. En forma de cálculo:

frecuencia_residual = frecuencia x (1 – ef)

El riesgo residual. Puede derivarse indirectamente como

riesgo_residual = impacto_residual x frecuencia residual


1.000.000 x 90% = 900.000

Si la frecuencia estimada es de 0,1, el riesgo es de cuantía

900.000 x 0,1 = 90.000

Si las salvaguardas tienen un 90% de eficacia sobre el impacto, el impacto residual es 900.000 x (1 – 0,9) = 90.000

Si las salvaguardas tienen un 50% de eficacia sobre la frecuencia, la frecuencia residual queda en

0,1 x (1 – 0,5) = 0,05

El riesgo residual queda en 90.000 x 0,05 = 4.500

La eficacia combinada de las salvaguardas es

1 – (1 – 90%) x (1 – 50%) = 95%

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.

Resumen En este modelo, denominado cuantitativo, se trabaja con valores reales, siempre superiores a ce-ro.

Se modela el grado de dependencia entre activos como un continuo entre 0,0 (activos indepen-dientes) y 1,0 (activos absolutamente dependientes; lo que ocurre sobre el inferior repercute con-tundentemente 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 abso-luta), 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 gas-to en salvaguardas con la disminución de pérdidas.



Las estimaciones de impacto y riesgo residual incorporan la eficacia de las salvaguardas para en-frentarse a la amenaza.

Si la valoración del activo es económica, el modelo cuantitativo permite comparar el gasto en sal-vaguardas 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 escalo-nes de valor. El caso típico es la interrupción del servicio, que responde a esquemas como el si-guiente

15m

30m 1h 2h 6h 1d 2d 1s 2s 1m 2m 6m 1a

tota

l

S1

0

2

4

6

8

10

coste

duración de la parada

coste de [la interrupción de la] disponibilidad

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 = { e1, e2, ..., en } 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[ei]

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[e1] ≤ v[e2] ≤ … ≤ v[en]

Las dependencias entre activos. Se usará el tratamiento cualitativo (sí o no depende) o el cuantitativo (depende en tal grado) se-gú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áxi-mo 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úbli-co). A partir de una hora, la imagen ofrecida a los ciudadanos empieza a resentirse. Si el servi-cio se demora más de un día, se considera inútil, aunque de una gravedad relativa pues siem-pre queda la opción de la reclamación por escrito. Ambos servicios dependen de un equipamiento informático que hereda las valoraciones de am-bos 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 “ei“ 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 co-rrespondiente, 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[ei]”.

El impacto acumulado empleará en valor acumulado sobre el activo que es víctima de la amena-za.

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 es-crito 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”7.

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.

Este escalón de eficacia puede ser e0, si la salvaguarda es tan contundente que no deja lugar ni al primer escalón valorado, e1.

Este escalón de eficacia es el mismo que la degradación cuando la salvaguarda es incapaz de reducir el impacto8.

Este escalón de eficacia nunca puede ser superior al escalón de degradación, pues una salva-guarda 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 constitu-yen 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 salvaguar-das:

escalón(ps)= escalón(s) si s es singular

maxk { escalón(psk) } si ps= todas (psk) mink { escalón(psk) } si ps= algunas (psk) mink { escalón(psk) } si ps= una (psk)

Donde el valor especial “na”9 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 “ed“ de degradación, gracias a las salva-guardas se colocará en el escalón propuesto como escalón de eficacia, “es“; pero modulado por la eficacia “ei” frente al impacto, resultado en un escalón residual “er“:

r = ⎣d − ((d − s) × ei)⎦ 10

Donde el valor especial “na” se valora como 0.

El impacto residual. Es el valor correspondiente al escalón residual:

impacto_residual = valor[er]

7 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.

8 Un centro de respaldo que empieza a funcionar en 48 horas es inútil frente a amenazas que detienen el servicio durante 6 horas.

9 na: no aplica. 10 La notación ⎣v⎦ indica el entero que resulta de un redondeo por defecto.



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.

El riesgo residual. En base al impacto residual y la frecuencia residual, se empleará el modelo cualitativo o cuantitati-vo, 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(ps0, ps1, ...) | algunas (ps0, ps1, ...) | una (ps0, ps1, ...)

La eficacia de una salvaguarda. Cada salvaguarda se valora según su eficacia reduciendo el riesgo del activo que protege. La efi-cacia de un paquete de salvaguardas es un número real entre 0,0 y 1,0:

• si una salvaguarda es idónea (100% eficaz), se dice que e = 1

• si una salvaguarda es insuficiente, se dice que e < 1

• si una salvaguarda no sirve para nada, se dice que e= 0

• si una salvaguarda no tiene sentido en este contexto, se dice que e = na

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) si s es singular mediak { e(psk) } 11 si ps= todas (psk) min { 1,0, Σk e(psk) si ps= algunas (psk)

maxk { e(psk) } si ps= una (psk) 11 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.



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.

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(psk) × pk / Σk pk

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 frecuen-cia, 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: satis-facción de su cometido. Por último se puede calcular la eficacia reduciendo el riesgo, “e”, como

(1 − ei) × (1 − ef) = 1 − e

Magerit versión 2 Á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 tra-bajos 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 obje-tivo, convirtiéndose las ramas en objetivos intermedios que a su vez pueden refinarse. Los posi-bles 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 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 habilida-des 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 enri-quecer con información de detalle, que puede ser de muy diferentes tipos:

• 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 reali-zar 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 es-cenarios simplificados de ataque:

• usuarios inexpertos pero con bastante dinero

• atacantes profesionales pero sin capacidad de inversión (o sin necesidad de realizar una in-



versión adicional para perpetrar este ataque)

• atacantes que quedarían impunes

• etc. Para alcanzar estos escenarios especializados basta eliminar del árbol las ramas que no satisfa-gan una condición cualitativa o cuantitativa12.

Sobre un árbol con atributos es posible determinar el ataque más probable, simplemente extra-yendo 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 be-neficio para el atacante

Un sistema ideal de salvaguardas eliminaría todas las ramas del árbol. Un sistema real suele lle-var 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 sim-plemente 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 exponien-do 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 12 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 requie-ren 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 contra-dictorias.



cómo lo prevenimos. Capturan de alguna forma el razonamiento del atacante y permiten anticipar-se a lo que pudiera ocurrir.

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 media-namente 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 Maga-

zine, August 2002.

• A.P. Moore et al., “Attack Modeling for Information Security and Survivability”, Software En-gineering 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.

Magerit versión 2 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 indi-caciones dadas en este libro complementan a las presentadas a lo largo de la metodología.

Se han considerado de especial interés:

1. análisis coste beneficio

2. diagramas de flujo de datos (DFD)

3. diagramas de procesos (SADT)

4. técnicas gráficas: GANTT, histogramas, diagramas de Pareto y de tarta 5. técnicas de planificación y gestión de proyectos (PERT)

6. sesiones de trabajo: entrevistas, reuniones y presentaciones

7. valoraciones Delphi

que se desarrollan en las siguientes secciones.

Magerit versión 2 Análisis coste-beneficio


3.1. Análisis coste-beneficio La técnica de análisis coste/beneficio tiene como objetivo fundamental proporcionar una medida de los costes en que se incurre en la realización de un proyecto y comparar dichos costes previs-tos con los beneficios esperados de la realización de dicho proyecto. Esta medida o estimación servirá para:

• Valorar la necesidad y oportunidad de acometer la realización del proyecto.

• Seleccionar la alternativa más beneficiosa para la realización del proyecto.

• Estimar adecuadamente los recursos económicos necesarios en el plazo de realización del proyecto.

Es de destacar la necesidad cada vez mayor de guiarse por criterios económicos y no sólo técni-cos para la planificación de trabajos y proyectos. Por ello se hace una primera introducción sobre las técnicas y métodos de evaluación de conceptos económicos, con el fin de proporcionar a los profesionales criterios que les ayuden en la planificación de proyectos y evaluación de alternati-vas.

3.1.1. Conceptos Punto de amortización (Break-Even Point)

Es el momento en el tiempo en que el conjunto de beneficios obtenidos por la explotación del nuevo sistema iguala al conjunto de costes de todo tipo que ha ocasionado. A partir del punto de amortización (Break-Even Point), el sistema entra en fase de aportar beneficios ne-tos a la Organización.

Periodo de amortización (PayBack)

Es el periodo de tiempo que transcurre desde que los costes son máximos hasta que se al-canza el punto de amortización (Break-Even Point), es decir, en cuanto el sistema empieza a aportar beneficios. Cuanto menor sea el periodo de amortización (Payback) de un Siste-ma, más atractivo será para la Organización acometer su implantación.

Retorno de la Inversión - ROI (Return of Investment)

Es el rendimiento de la inversión expresada en términos de porcentaje. Se calcula mediante la fórmula siguiente:

ROI Beneficio Neto Anual Coste Desarrollo AnualizadoInversión Promedio

x100

Siendo:

Beneficio Neto Anual: Ganancia que aporta el sistema como consecuencia de su uso, es decir los beneficios obtenidos más los gastos no incurridos. Deben restársele los gastos operacionales anuales y los de mantenimiento del sistema.

Coste de Desarrollo Anualizado: Total del gasto inicial de desarrollo del sistema, dividido por los años que se supone que va a ser operativo.

Inversión Promedio: Total de la inversión realizada (costes de desarrollo, hardware, softwa-re, etc.) dividido por el total de conceptos en los que se invierte.

3.1.2. Realización de un análisis coste / beneficio Para la realización del análisis coste/beneficio se seguirán los siguientes pasos:

1. Producir estimaciones de costes/beneficios. 2. Determinar la viabilidad del proyecto y su aceptación.

3.1.2.1. Producir estimaciones de costes-beneficios Se realizará una lista de todo lo que es necesario para implementar el sistema y una lista de los



beneficios esperados del nuevo sistema.

En general, los costes suelen ser mensurables y estimables en unidades económicas, no así los beneficios, los cuales pueden ser tangibles o no tangibles. En un análisis de costes y beneficios se deben considerar aquellos aspectos tangibles, es decir, mensurables en valores como dinero, tiempo, etc., y no tangibles, es decir, no ponderables de una forma objetiva.

Entre los beneficios no tangibles pueden estar:

• El aumento de cuentas debido a un mejor servicio a los clientes.

• La mejora en la toma de decisiones debido a una mejora en el soporte informático.

La valoración de los beneficios no tangibles se debe estimar de una forma subjetiva y será reali-zada por las áreas correspondientes.

A menudo es conveniente desglosar los costes estimados a lo largo del proyecto, para ofrecer una información más detallada de la distribución de los recursos de cara a la dirección.

En la estimación de costes se considerarán, entre otros, los siguientes aspectos:

Adquisición de hardware y software: El que sea preciso para el desarrollo, implantación y normal funcionamiento del sistema. Se debe considerar la saturación de máquinas o siste-mas actuales como consecuencia de la entrada en vigor del nuevo sistema.

Gastos de mantenimiento de hardware y software anteriores.

Gastos de comunicaciones: Líneas, teléfono, correo, etc.

Gastos de instalación: Cableado, acondicionamiento de sala, recursos humanos y materiales, gastos de viaje, etc.

Coste de desarrollo del sistema.

Gastos del mantenimiento del sistema: Coste anual.

Gastos de consultoría: En caso de requerirse algún consultor externo en cualquier etapa del proyecto.

Gastos de formación: De todo tipo (Desarrolladores, Operadores, Implantadores, Usuario Fi-nal, etc.).

Gastos de material: Papel, toner, etc.

Costes derivados de la curva de aprendizaje: De todo el personal involucrado: Desarrollado-res, Técnicos de Sistemas, Operadores, y desde luego, Usuarios.

Costes financieros, de publicidad, etc.

En la estimación de beneficios se pueden considerar cuestiones como las siguientes: Incremento de la productividad: Ahorro o mejor utilización de recursos humanos.

Ahorro de gastos de mantenimiento del sistema actual.

Ahorros de adquisición y mantenimiento de hardware y software, o reutilización de plata-formas sustituidas.

Incremento de ventas o resultados, disminución de costes: Producidos por una mejora de la gestión (rotación de stock, "just in time", analítica de clientes, etc.).

Ahorro de material de todo tipo: Sustituido por datos electrónicos que proporciona el sistema, como por ejemplo: papel, correo, etc.

Beneficios financieros.

Otros beneficios tangibles: Ahorro de recursos externos, consultoría, formación, etc.

Beneficios intangibles: Incremento de la calidad del producto o servicio, mejora de la imagen de la compañía, mejora en la atención al cliente, mejora en la explotación, etc.



3.1.2.2. Determinar la viabilidad del proyecto Se basará en uno de los métodos siguientes:

• retorno de la inversión

• valor actual

Retorno de la Inversión Este método consiste en calcular el coste y el beneficio anual, conociendo el coste total al inicio del proyecto "C0”, para determinar en qué año se recupera el coste total inicialmente estimado.

AÑO COSTE BENEFICIO BENEFICIO NETO0 C0 0 1 C1 B1 B1 - C1 2 C2 B2 B2 - C2

n Cn Bn Bn - Cn

El año de recuperación de la inversión se produce cuando

i Bi Ci C0

Valor Actual Este método permite tener en cuenta que un gasto invertido durante un cierto tiempo produce un beneficio. El método consiste en determinar el dinero que es viable invertir inicialmente para que se recupere la inversión en un periodo de tiempo definido previamente.

El resultado depende del tipo de interés (r) utilizado en la evaluación.

Se debe calcular, en primer lugar, el beneficio neto que se obtendrá cada año. Dicho beneficio no es real, ya que se debe estimar el valor real de dicha cantidad en el año n. Para ello se aplica la fórmula:

Valor actual Beneficio neto1 r 100 n

Para n= 1, 2, ... años.

Se debe estudiar en cuántos años se recupera la inversión realizada inicialmente, o bien, si en un periodo de años fijado previamente se retorna la inversión y, por tanto, es viable el proyecto. Si la inversión es el C0, se determinará la viabilidad del proyecto consultando la siguiente tabla:

AÑO COSTE BENEFICIO VALOR ACTUAL 0 C0 0 1 C1 B1 VA1 B1 C1 1 r 100 2 C2 B2 VA2 B2 C2 1 r 100 2

n Cn Bn VAn Bn Cn 1 r 100 n



El proyecto será viable si

i VAi C0

a lo largo del periodo fijado.

3.1.3. Referencias • R.A. Brealey and S.C. Myers, “Principles of Corporate Finance”, Mcgraw-Hill College; 6th

edition, December 2000.

• A.E. Boardman, “Cost-Benefit Analysis: Concepts and Practice”, Prentice Hall, 2nd Edition, October 2000.

• H.M. Levin and P.J. McEwan, “Cost-Effectiveness Analysis Methods and Applications”, Sage Publications, Inc., 2nd edition, September 2000.

• Office of The Deputy Chief Information Officer, “Cost-Benefit Analysis Guide for NIH IT Pro-jects”, Revised May, 1999.

• Office of Management and Budget, Circular No. A-94 Revised, “Guidelines and Discount Rates for Benefit-Cost Analysis of Federal Programs”, October 29, 1992.

Magerit versión 2 Diagramas de flujo de datos


3.2. Diagramas de flujo de datos (DFD) El objetivo de los diagramas de flujo de datos es la obtención de un modelo lógico que presente cómo los datos progresan por el sistema de información. Así se facilita su comprensión por los usuarios y los miembros del equipo de desarrollo, sin entrar en detalles de las manipulaciones que sufren los datos.

El sistema se divide en distintos niveles de detalle, con el objetivo de:

• Simplificar la complejidad del sistema, representando los diferentes procesos de que consta.

• Facilitar el mantenimiento del sistema.

3.2.1. Descripción Un diagrama de flujo de datos es una técnica muy apropiada para reflejar de una forma clara y precisa los procesos que conforman el sistema de información. Permite representar gráficamente los límites del sistema y la lógica de los procesos, estableciendo qué funciones hay que desarro-llar. Además, muestra el flujo o movimiento de los datos a través del sistema y sus transformacio-nes como resultado de la ejecución de los procesos.

Esta técnica consiste en la descomposición sucesiva de los procesos, desde un nivel general, hasta llegar al nivel de detalle necesario para reflejar toda la semántica que debe soportar el sis-tema en estudio.

El diagrama de flujo de datos se compone de los siguientes elementos:

Entidad externa: representa un ente ajeno al sistema que proporciona o recibe información del mismo. Puede hacer referencia a departamentos, personas, máquinas, recursos u otros sis-temas. El estudio de las relaciones entre entidades externas no forma parte del modelo. Puede aparecer varias veces en un mismo diagrama, así como en los distintos niveles del DFD para mejorar la claridad del diagrama.

Proceso: representa una funcionalidad que tiene que llevar a cabo el sistema para transformar o manipular datos. El proceso debe ser capaz de generar los flujos de datos de salida a par-tir de los de entrada, más una información constante o variable al proceso. El proceso nunca es el origen ni el final de los datos, puede transformar un flujo de datos de entrada en varios de salida y siempre es necesario como intermediario entre una entidad externa y un alma-cén de datos.

Almacén de datos: representa la información en reposo utilizada por el sistema independien-temente del sistema de gestión de datos (por ejemplo un. fichero, base de datos, archivador, etc.). Contiene la información necesaria para la ejecución del proceso. El almacén no puede crear, transformar o destruir datos, no puede estar comunicado con otro almacén o entidad externa y aparecerá por primera vez en aquel nivel en que dos o más procesos accedan a él.

Flujo de datos: representa el movimiento de los datos, y establece la comunicación entre los procesos y los almacenes de datos o las entidades externas. Un flujo de datos entre dos procesos sólo es posible cuando la información es síncrona, es decir, el proceso destino comienza cuando el proceso origen finaliza su función.

Los flujos de datos que comunican procesos con almacenes pueden ser de los siguientes tipos:

De consulta: representan la utilización de los valores de uno o más campos de un almacén o la comprobación de que los valores de los campos seleccionados cumplen unos criterios de-terminados.

De actualización: representan la alteración de los datos de un almacén como consecuencia de la creación de un nuevo elemento, por eliminación o modificación de otros ya existentes.

De diálogo: es un flujo entre un proceso y un almacén que representa una consulta y una ac-tualización.

Existen sistemas que precisan de información orientada al control de datos y requieren flujos y



procesos de control, así como los mecanismos que desencadenan su ejecución. Para que resulte adecuado el análisis de estos sistemas, se ha ampliado la notación de los diagramas de flujo de datos incorporando los siguientes elementos:

Proceso de control: representa procesos que coordinan y sincronizan las actividades de otros procesos del diagrama de flujo de datos.

Flujo de control: representa el flujo entre un proceso de control y otro proceso. El flujo de con-trol que sale de un proceso de control activa al proceso que lo recibe y el que entra le infor-ma de la situación de un proceso. A diferencia de los flujos tradicionales, que pueden consi-derarse como procesadores de datos porque reflejan el movimiento y transformación de los mismos, los flujos de control no representan datos con valores, sino que en cierto modo, se trata de eventos que activan los procesos (señales o interrupciones).

3.2.2. Descomposición o explosión por niveles Los diagramas de flujo de datos han de representar el sistema de la forma más clara posible, por ello su construcción se basa en el principio de descomposición o explosión en distintos niveles de detalle.

La descomposición por niveles se realiza de arriba abajo (top-down), es decir, se comienza en el nivel más general y se termina en el más detallado, pasando por los niveles intermedios necesa-rios. De este modo se dispondrá de un conjunto de particiones del sistema que facilitarán su estu-dio y su desarrollo.

La explosión de cada proceso de un DFD origina otro DFD y es necesario comprobar que se man-tiene la consistencia de información entre ellos, es decir, que la información de entrada y de salida de un proceso cualquiera se corresponde con la información de entrada y de salida del diagrama de flujo de datos en el que se descompone.

En cualquiera de las explosiones puede aparecer un proceso que no necesite descomposición. A éste se le denomina Proceso primitivo y sólo se detalla en él su entrada y su salida, además de una descripción de lo que realiza. En la construcción hay que evitar en lo posible la descomposi-ción desigual, es decir, que un nivel contenga un proceso primitivo, y otro que necesite ser frag-mentado en uno o varios niveles más.

El modelo de procesos deberá contener:

• Un diagrama de contexto (Nivel 0).

• Un diagrama 0 (Nivel 1).

• Tantos diagramas 1, 2, 3, ... n como funciones haya en el diagrama 0 (Nivel 2). • Tantos niveles intermedios como sea necesario.

• Varios DFD en el último nivel de detalle.

El diagrama de contexto tiene como objetivo delimitar el ámbito del sistema con el mundo exterior definiendo sus interfaces. En este diagrama se representa un único proceso que corresponde al sistema en estudio, un conjunto de entidades externas que representan la procedencia y destino de la información y un conjunto de flujos de datos que representan los caminos por los que fluye dicha información.

A continuación, este proceso se descompone en otro DFD, en el que se representan los procesos principales o subsistemas. Un subsistema es un conjunto de procesos cuyas funcionalidades tie-nen algo en común. Éstos deberán ser identificados en base a determinados criterios, como por ejemplo: funciones organizativas o administrativas propias del sistema, funciones homogéneas de los procesos, localización geográfica de los mismos, procesos que actualicen los mismos almace-nes de datos, etc.

Cada uno de los procesos principales se descompone a su vez en otros que representan funcio-nes más simples y se sigue descomponiendo hasta que los procesos estén suficientemente deta-llados y tengan una funcionalidad concreta, es decir, sean procesos primitivos. Como resultado se obtiene un modelo de procesos del sistema de información que consta de un conjunto de diagramas de flujo de datos de diferentes niveles de abstracción, de modo que cada



uno proporciona una visión más detallada de una parte definida en el nivel anterior.

Además de los diagramas de flujo de datos, el modelo de procesos incluye la especificación de los flujos de datos, de los almacenes de datos y la especificación detallada de los procesos que no precisan descomposición, es decir los procesos de último nivel o primitivos. En la especificación de un proceso primitivo se debe describir, de una manera más o menos formal, cómo se obtienen los flujos de datos de salida a partir de los flujos de datos de entrada y características propias del proceso.

Dependiendo del tipo de proceso se puede describir el procedimiento asociado utilizando un len-guaje estructurado o un pseudocódigo, apoyándose en tablas de decisión o árboles de decisión.



A continuación se muestra un ejemplo gráfico que representa la de descomposición jerárquica de los diagramas de flujo de datos.

3.2.3. Notación

Entidad externa: Se representa mediante una elipse con un identificador y un nombre significativo en su interior:



Si la entidad externa aparece varias veces en un mismo diagrama, se representa con una línea inclinada en el ángulo superior izquierdo:

Proceso: Se representa por un rectángulo subdividido en tres casillas donde se indica el nombre del proce-so, un número identificativo y la localización.

Si el proceso es de último nivel, se representa con un asterisco en el ángulo inferior derecho sepa-rado con una línea inclinada.

El nombre del proceso debe ser lo más representativo posible. Normalmente estará constituido por un verbo más un sustantivo.

El número identificativo se representa en la parte superior izquierda e indica el nivel del DFD en que se está. Hay que resaltar que el número no indica orden de ejecución alguno entre los proce-sos ya que en un DFD no se representa una secuencia en el tratamiento de los datos. El número que identifica el proceso es único en el sistema y debe seguir el siguiente estándar de notación:

• El proceso del diagrama de contexto se numera como cero.

• Los procesos del siguiente nivel se enumeran desde 1 y de forma creciente hasta completar el número de procesos del diagrama.

• En los niveles inferiores se forma con el número del proceso en el que está incluido seguido de un número que lo identifica en ese contexto.

La localización expresa el nombre del proceso origen de la descomposición que se esté tratando.



Almacén de datos: Se representa por dos líneas paralelas cerradas en un extremo y una línea vertical que las une. En la parte derecha se indica el nombre del almacén de datos y en la parte izquierda el identifica-dor de dicho almacén en el DFD.

Si un almacén aparece repetido dentro un DFD se puede representar de la siguiente forma:

Flujo de datos: Se representa por una flecha que indica la dirección de los datos, y que se etiqueta con un nom-bre representativo.

La representación de los flujos de datos entre procesos y almacenes es la siguiente:



Proceso de control: Se representa por un rectángulo, con trazo discontinuo, subdividido en tres casillas donde se indi-ca el nombre del proceso, un número identificativo y la localización.

Flujo de control: Se representa por una flecha con trazo discontinuo que indica la dirección de flujo y que se etique-ta con un nombre representativo.



Ejemplo La figura es un diagrama de flujos de un Sistema Gestor de Pedidos. En él están representados todos los elementos que pueden intervenir en una Diagrama de Flujo de Datos.

3.2.4. Consistencia de los diagramas de flujo de datos Una vez construidos los diagramas de flujo de datos que componen el modelo de procesos del sistema de información, es necesario comprobar y asegurar su validez. Para ello, se debe estudiar cada diagrama comprobando que es legible, de poca complejidad y si los nombres asignados a sus elementos ayudan a su comprensión sin ambigüedades.

Además, los diagramas deben ser consistentes. En los diagramas hay que comprobar que en un DFD resultado de una explosión:

• No falten flujos de datos de entrada o salida que acompañaban al proceso del nivel superior.

• No aparezca algún flujo que no estuviese ya asociado al proceso de nivel superior.

• Todos los elementos del DFD resultante deben estar conectados directa o indirectamente con los flujos del proceso origen.

A continuación se incluyen ejemplos de la consistencia o inconsistencia de los diagramas de flujo de datos.



Sea el diagrama de contexto de la figura. Los flujos A, C y D, entran al sistema, y el flujo B sale de él.

Ejemplo de consistencia de diagramas de flujo de datos En la explosión del sistema en el diagrama de nivel 1, aparecen todos los flujos, y en su sentido correcto: A y C entran al subsistema o proceso 1, B sale del proceso 2, y D entra en el proceso 3. Se observa que el proceso 3, origina dos flujos de salida: E que va a al proceso 1, y F al proceso 2.



La descomposición del proceso 1, muestra los flujos A, C y E correctamente, como entradas a las funciones del diagrama.

Ejemplo de inconsistencia de diagramas de flujo de datos Partiendo del mismo diagrama de contexto utilizado en el anterior ejemplo, los flujos A, C y D, que entran al sistema, y el flujo B, que sale de él, deben aparecer en la primera descomposición, el diagrama de nivel 1. En la figura se aprecia que falta el flujo D, y hay un flujo G que o bien falta en el nivel anterior, sobra en este.

Por otro lado, en el proceso 3 no entra ningún flujo, no es posible por tanto que transforme datos saliendo los flujos E y F y además está desconectado del nivel anterior.



En el siguiente paso, la inconsistencia más clara es la falta del flujo C, que entra al proceso 1, y sin embargo no aparece en su explosión.

Además, hay otra inconsistencia respecto al almacén A1: en el diagrama del nivel anterior, el pro-ceso 1 se conectaba con un flujo de entrada-salida este almacén, cosa que no se refleja en el dia-grama de este proceso, en el que sólo aparece uno de entrada.

3.2.5. Ejemplo de construcción. El caso en estudio es un modelo de procesos de un sistema de información de Conocimientos de técnicos. Según estos conocimientos, los técnicos podrán ser asignados a determinados proyec-tos de la Organización.

El sistema recogerá la información referente a los técnicos, procedente de la Dirección técnica de la Organización y de los proyectos, procedente de cualquier sección o Unidad de Negocio en las que está dividida dicha Organización.



Las entidades externas son pues Dirección Técnica y Unidad de Negocio, que introducen los da-tos al sistema y hacen peticiones de consultas e informes sobre los técnicos y sus conocimientos. El diagrama de contexto será el siguiente:

Los flujos de entrada son: Datos Técnicos, con datos de los técnicos introducidos por la Dirección Técnica, así como posibles peticiones de información sobre ellos; y Datos Unidad, que proviene de la Unidad de Negocio, conteniendo datos referentes a la unidad, de proyectos y clientes, así como posibles peticiones de consultas sobre los mismos.

Los flujos de salida son: Información Técnicos, que contendrá datos de técnicos, de consulta o informes, para uso de la Dirección Técnica y Consultas Unidad, con datos requeridos por la Uni-dad de Negocio.

El sistema de Conocimientos se descompone en el diagrama de nivel 1, conteniendo dos subsis-temas. El subsistema 1 recogerá las funciones a realizar con los datos de los técnicos de la Orga-nización (actualizaciones, consultas, informes, etc.), por lo que se denomina Tratar Técnicos. El subsistema 2 contendrá las funciones asociadas al procesamiento de datos de proyectos, por lo que se le da el nombre Tratar Proyectos.



En el diagrama se encuentran cuatro almacenes, tres de los cuales son accedidos por funciones de los dos subsistemas: A1 Conocimientos, A2 Proyectos y A3 Técnicos. El cuarto, A4 Clientes, sólo es accedido por el subsistema Tratar Proyectos.

Los flujos sin nombre indican que hay entrada y/o salida de todos los datos del almacén. En este diagrama siguen apareciendo las entidades externas para la mayor comprensión del mismo.

A partir de ahora, se centrará el ejemplo en la descomposición del subsistema 1 Tratar Técnicos, hasta llegar a su nivel más detallado.

En el diagrama resultado de la explosión de Tratar Técnicos, se incluyen cuatro procesos o fun-ciones para el tratamiento completo de éstos. El flujo de entrada Datos Técnicos se compone tanto de los datos profesionales de los técnicos, como de datos de peticiones de información sobre los mismos, por lo cual se ha dividido en dos: Datos Profesionales, que es entrada del proceso 1.1 Validar datos Técnicos y Peticiones Informa-ción Técnicos, que entra en la función 1.4 Informar.



Para la validación, el proceso 1.1 Validar Datos Técnicos obtiene información del almacén A3 Técnicos y genera una salida, el flujo Datos Técnicos Correctos, que lleva los datos válidos a la función 1.2 Actualizar Almacenes Técnicos. Esta función se encarga de actualizar los almacenes A3 Técnicos y A1 Conocimientos, pero también emite un flujo al proceso 1.3 Asignar a Proyectos. Éste se encarga de hacer asignaciones de técnicos en el almacén A2 Proyectos.

La función 1.4 Informar, recibe las peticiones de información sobre técnicos, las procesa utilizando los almacenes necesarios y genera el flujo Información Técnicos que irá a la entidad Dirección Técnica, según muestran los primeros diagramas.

Obsérvese que para mayor claridad no se ha incluido ya ninguna entidad externa, y además, se ha repetido el almacén A3 Técnicos, evitando que el cruce de flujos oscurezca la lectura del dia-grama.

En este momento, todos los procesos se consideran primitivos, excepto el proceso 1.4 Informar, del que se obtiene su descomposición. Sus funciones han de obtener Informes Técnicos y Consul-tas Técnicos, flujos que componen Información Técnicos que aparecía en el nivel anterior.



Por otro lado, también aparece dividido el flujo de entrada Peticiones Información Técnicos, dife-renciando la entrada al proceso de consultas o al de emisión de informes.

Por último, se puede apreciar que los almacenes son los mismos que se conectaban con el proce-so en el nivel anterior y los flujos son de entrada a las funciones.

3.2.6. Utilización en el proyecto de análisis y gestión de riesgos Los diagramas DFD son un producto de entrada en varias tareas del proyecto AGR. Son conve-nientes para

• delimitar el dominio en el que se centra el proyecto (T1.2.2)

• descubrir el entorno del dominio y las relaciones entre el dominio y su entorno (T1.2.3)

• identificar activos (T2.1.1), principalmente de tipo datos y aplicaciones (software) aunque también ayuda a descubrir servicios

• determinar dependencias entre activos (T2.2.2): cuando una información X es procesada por una aplicación A, se dice que X depende de A

• aunque por definición los DFD no entran en detalles de los componentes físicos donde resi-den los datos y las aplicaciones, cuando se averigüe dónde residen las diferentes aplicacio-nes, se puede recurrir de nuevo a los DFD para analizar las dependencias de las comunica-ciones

3.2.7. Referencias • S.W. Ambler, “The Object Primer. Agile Model Driven Development with UML 2”, Cambridge

University Press, 3rd ed. 2004.

• C.P. Gane and T. Sarson, “Structured Systems Analysis: Tools and Techniques”, Prentice Hall, 1st ed. 1979.

Magerit versión 2 Diagramas de procesos


3.3. Diagramas de procesos Existen muchas técnicas para el modelado de procesos de la Organización, aunque la elección de una de ellas se debe llevar a cabo dentro del contexto de cada organización o incluso del de un determinado proyecto, en función de los objetivos que se persigan. Se describe la técnica SADT (Structured Analysis and Design Technique) que es una de las posi-bles elecciones para el modelado de procesos de la Organización.

3.3.1. Conceptos Se incluyen unas definiciones de carácter general, relacionadas con los procesos de la Organiza-ción.

Proceso de la Organización Un proceso de la Organización se descompone en una serie de actividades (qué se hace) y éstas en procedimientos (cómo se hace). Además hay que saber quién lo hace.

Se caracteriza porque:

• Tiene un disparador que es un evento externo.

• Posee unas actividades que proporcionan las salidas adecuadas en respuesta al evento.

• Transforma entradas de todos los tipos en salidas, siguiendo unas reglas.

• Utiliza pasos lógicos que afectan a distintas funciones en distintos departamentos. • Contiene indicadores de rendimiento para los que se pueden establecer objetivos mensura-

bles.

• Proporciona un producto o servicio a una entidad externa o a otro proceso interno.

Modelo de procesos de la Organización Es el mapa o diagrama del proceso que representa las interacciones entre actividades, objetos y recursos de la Organización, con la documentación adicional de sus características y la informa-ción que fluye entre ellos.

Tipos de procesos De acuerdo a sus características se distinguen los procesos:

• Principales: que están en contacto directo con el cliente o que dan respuesta a las deman-das del mercado. A menudo denominados “procesos finales”.

• De soporte: para guiar, controlar, planificar o aportar recursos a los procesos principales o a otros procesos de soporte. A menudo denominados “procesos internos”.

La representación de un proceso se realiza mediante una caja rectangular. Cada caja se etiqueta con un nombre formado por una acción y un objeto (por ejemplo: rellenar formularios, confirmar con cliente, instalar equipos, reservar viaje, etc.) Entre las propiedades que reúne un buen modelo de procesos se encuentran las siguientes:

• Tiene un objetivo claramente definido

• Permite obtener una visión general y de detalle de los procesos

• Identifica eventos que disparan actividades del proceso

• Identifica conexiones lógicas entre actividades

• Establece las relaciones con el cliente final • Actúa como repositorio y organizador del proceso de información

• Establece medidas de tiempo de proceso, esfuerzo y coste



• Ayuda en la identificación de las áreas con problemas que afectan al nivel de satisfacción del cliente

• Contiene gráficos y texto • Crea un vocabulario común

3.3.2. SADT (Structured Analysis and Design Technique) La técnica que se describe a continuación se refiere al diagrama de actividades de SADT, que se puede emplear para el modelado de procesos de la Organización debido a que permite represen-tar un proceso con las actividades que lo componen.

3.3.2.1. Descripción Un modelo realizado con la técnica SADT permite representar las actividades de un proceso, defi-nir las dependencias y relaciones entre dichas actividades, los controles que determinan o limitan su ejecución, los mecanismos que los ponen en marcha, así como los datos que se utilizan, com-parten o transforman en los procesos. Los diagramas SADT incorporan los procesos de la Organización en orden secuencial, de acuerdo a su lógica de ejecución mediante una numeración que se refleja en la esquina inferior derecha de cada actividad. De esta manera se consigue un modelo de actividades que refleja el nivel de in-fluencia de una actividad sobre el resto de las del proceso.

El resultado final es un conjunto de diagramas que contienen las actividades del proceso, cuida-dosamente coordinados y organizados en niveles, que empiezan por el diagrama de nivel más general y terminan por los de detalle. Cualquier actividad compleja puede subdividirse en activida-des más detalladas.

Los flujos que interconectan actividades se clasifican en cuatro tipos de acuerdo a su significado:

Entrada: hace referencia a la información que se utilizará para producir las salidas de la activi-dad. La entrada es transformada por la actividad.

Salida: se trata de información que se produce en la actividad.

Control: se trata de restricciones que afectan a una actividad. Regula la producción de las sa-lidas a partir de las entradas, pudiendo indicar cómo y cuando se producen las salidas.

Mecanismo: normalmente se refiere a máquinas, personas, recursos o sistemas existentes que ejecutan la actividad. Es importante incluir aquellos mecanismos que serán diferentes en el entorno actual y en el entorno futuro.

Al incorporar controles que regulan las actividades, los flujos de salida de una actividad pueden actuar como controles e incluso mecanismos en la actividad precedente o dependiente.

Los diagramas SADT requieren una serie de puntos de partida:

• Concretar el tema a tratar

• Asumir un punto de vista determinado • Fijar un objetivo

El primero permite definir el ámbito dentro y fuera de la Organización y el segundo proporciona una guía al construir el modelo. Por último, el objetivo ayuda a decidir cuándo se finaliza en la construcción del modelo.

3.3.2.2. Notación En la cabecera del diagrama se incluye información relativa al autor, proyecto, fecha de creación o de última revisión y estado.

Los dos elementos principales de los diagramas SADT son las actividades del proceso a modeli-zar y los flujos que establecen la comunicación entre las actividades. Las actividades se representan mediante una caja rectangular cuyo nombre contiene un verbo, que responde a una función o parte activa del proceso, y los flujos mediante flechas. El número de



actividades en un diagrama, para hacerlo comprensible, debe oscilar entre 3 y 6.

Cada lado de la caja tiene un significado específico:

• El lado izquierdo está reservado para las entradas • El superior corresponde a los controles • El lado derecho para las salidas • El inferior se reserva para los mecanismos

Esta notación responde a los siguientes principios: las entradas son transformadas en salidas, los controles son restricciones bajo las que se desarrollan las actividades y los mecanismos son los medios, humanos o materiales, que permiten su ejecución. Cada flujo (flecha) representa planes, datos, máquinas e información, etc., y debe nombrarse con un sustantivo.

Las actividades en los diagramas SADT no se ubican de forma aleatoria, sino por la influencia que una actividad tiene sobre otras. La más dominante, es decir, la que más influye en las restantes, debe ser normalmente la primera en la secuencia de actividades y se sitúa en la esquina superior izquierda del diagrama. Por ejemplo, si se trata de realizar un proceso de selección de personal, la actividad más dominante será la de revisar las referencias de los candidatos. La menos dominan-te, por el contrario, se sitúa en la esquina inferior derecha, por ejemplo, en el caso anterior, sería la de contratar o rechazar a un candidato a empleo. Cada actividad se numera siguiendo una se-cuencia que empieza en la que se corresponde con la actividad más dominante y así sucesiva-mente.

La influencia de una actividad sobre otra se manifiesta en una salida de la primera que o bien es entrada o bien es un control en la segunda. Un diagrama de actividades SADT no es un diagrama de flujo de datos ya que recoge, además de las transformaciones de entrada y salida de información, las reglas que ponen restricciones a di-cha transformación. En este sentido, las flechas documentan las interfaces entre las actividades del proceso y entre éste y su entorno.

Existen cinco tipos de interconexiones entre actividades, que son las siguientes:

• Control • Entrada

• Control – Realimentación

• Entrada – Realimentación

• Salida – Mecanismo

La conexión por control o entrada se da cuando una salida de una actividad se convierte en con-trol o entrada, respectivamente, de una actividad de menor influencia. Cualquiera de las conexio-nes con realimentación tienen lugar cuando una salida de una actividad afecta a otra de mayor influencia como entrada o como control. La conexión de una salida de una actividad que actúa



como un mecanismo de otra, implica que la primera le proporciona medios a la segunda para su ejecución (aunque este tipo de conexión es poco usual).

Ejemplo A continuación se muestra un ejemplo del proceso de selección de personal de una organización mediante la técnica SADT.

3.3.3. Utilización en el proyecto de análisis y gestión de riesgos Los diagramas SADT son un producto de entrada en varias tareas del proyecto AGR. Son conve-nientes para

• delimitar el dominio en el que se centra el proyecto (T1.2.2)

• descubrir el entorno del dominio y las relaciones entre el dominio y su entorno (T1.2.3) • identificar activos (T2.1.1), principalmente de tipo servicios (procesos), datos, aplicaciones

(software) y personal

• determinar dependencias entre activos (T2.2.2):

• cuando un proceso P utiliza una información X, se dice que P depende de X

• cuando un proceso P utiliza una aplicación A, se dice que P depende de A

• cuando una información X es procesada por una aplicación A, se dice que X depende de A

• cuando un proceso P es manipulado por una persona (o role) H, se dice que P depende de H

• aunque por definición los diagramas SADT no entran en detalles de los componentes físicos donde residen los procesos, cuando se averigüe dónde residen estos, se puede recurrir de nuevo a los diagramas para analizar las dependencias de las comunicaciones



3.3.4. Referencias • Clarence G. Feldmann, “The Practical Guide to Business Process Reengineering Using

IDEF0”, Dorset House Publishing Company, 1998.

• Hill, S. and L. Robinson, “A Concise Guide to the IDEF0 Technique”, Enterprise Technology Concepts, 1995.

• FIPS 183: “Integration Definition for Function Modeling (IDEF0)”. Federal Information Proc-essing Standards. December, 1993.

• David A. Marca and Clement L. McGowan, “SADT: Structured Analysis and Design Tech-niques”. McGraw-Hill, New York, NY, 1988.

Magerit versión 2 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 pro-yecto AGR pueden apoyar a dicho proyecto, tanto como soporte a presentaciones, como en la to-ma de decisiones. Se presentan:

• Diagramas de GANTT, para seguimiento de proyectos

• Gráficas para presentar resultados

• puntos

• barras

• radar • Diagramas de Pareto, para priorización de acciones

• Diagramas de tarta

3.4.1. Diagramas de GANTT Henry Laurence Gantt (1861-1919) fue un ingeniero que asesoraba a empresas. Ideó una forma de representar gráficamente la evolución prevista y la evolución real de los proyectos en el tiempo. Esta representación ha sido bautizada con su nombre.

Los diagramas GANTT ayudan a la representación de actividades y recursos en función del tiem-po, es decir, dan una aproximación ordenada de un proceso y modelizan su planificación. El obje-tivo de los Diagramas GANTT consiste en facilitar la comprensión de los detalles de un plan y el progreso en su ejecución. Este método sencillo parte de una matriz organizada en filas y colum-nas:

• Las filas recogen las actividades a realizar y/o los recursos a emplear. • Las columnas recogen la escala de tiempos.

La duración y ubicación en el tiempo de cada actividad o recurso se representa mediante un línea (que puede ser de distintos grosores y colores).



GANTT de actividades

desplie-ga la ocupación temporal de cada actividad y las relaciones “requisito previo para” entre ellas. Frecuentemente se incluyen informaciones adicionales tales como hitos de control, el estado de ejecución de cada tarea (porcentaje de progreso), el responsable de su ejecución, etc.

GANTT de recursos despliega el consumo de recursos, humanos o de otro tipo, a lo largo del tiempo.

El tratamiento informático de los diagramas GANTT facilita la actualización de la planificación, que es dinámica (o sea, que debe controlarse y modificarse permanentemente).



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 usan-do 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

x i x j Por el contrario, una escala logarítmica es adecuada cuando importa transmitir la diferencia relati-va entre valores:

xi x j

xi

En proyectos de análisis y gestión de riesgos se trabaja con múltiples magnitudes que son per-cepciones 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 horizon-tales de nivel para marcan umbrales: valores mínimos o máximos para alguna toma de decisiones.



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 convenciona-les: los elementos a considerar en un eje y los valores en el otro eje. Son muy similares a las pre-sentaciones 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.



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 hori-zontales de nivel para marcan umbrales: valores mínimos o máximos para alguna toma de deci-siones.

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 semi-ejes o radios que parten de un centro. Estos radios, tantos como factores, se gradúan para repre-sentar 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, facili-tando 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 dibu-jan las escalas como radios (dentro de un círculo máximo cuyo radio sea el valor más alto norma-lizado 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).

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 pin-tan 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 geren-cial 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" se-gú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.

La gráfica es muy útil al permitir identificar visualmente en una sola revisión tales minorías de ca-



racterí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 lo-grar 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 me-nor 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.



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 7.300 [D_económicos] datos económicos 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



Pasos 5, 6 y 7: dibujar la gráfica

0

20.000

40.000

60.000

80.000

100.000

120.000

140.000

[S

_T_r

emot

a]tra

mita

ción

vía

ww

w

[D

_eco

nóm

icos

]da

tos

econ

ómic

os

[S_T

_pre

senc

ial]

tram

itaci

ónpr

esen

cial

[S

_not

ifica

ción

]no

tific

ació

nte

lem

átic

a

[D

_nor

mat

iva]

norm

ativ

a le

gal

[D

_exp

edie

ntes

]es

tado

de

latra

mita

ción

[S

_inf

o]in

form

ació

n de

norm

ativ

a

OTR

OS

activos

0%

20%

40%

60%

80%

100%

riesgoagregado



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.

Magerit versión 2 Planificación de proyectos


3.5. Planificación de proyectos Un proyecto complejo consta de una serie de tareas o actividades, algunas de las cuales son in-dependientes entre sí, mientras que otras están relacionadas de tal forma que hay que terminar una para empezar otra. Las técnicas del camino crítico (CP – Critical Path) y PERT (Program Evaluation and Review Technique) fueron desarrolladas hacia 1950 con el objetivo de modelar proyectos complejos, es-timar su tiempo de realización y analizar las consecuencias que sobre el conjunto tendría una desviación en una tarea.

3.5.1. Diagramas PERT Para capturar las dependencias entre tareas de un proyecto se construyen los llamados diagra-mas PERT que son grafos constituidos por:

hitos que marcan el comienzo o terminación de una tarea; se usan como nodos del grafo, asignándoseles un nombre único que suele ser numérico

tareas que recogen las actividades; se usan como arcos del grafo, entre nodos, asignándose-les un nombre único

La siguiente figura muestra un diagrama de un proyecto con 8 hitos y 10 tareas:

1 2

3

6

8

7

5

4

A

B

C

D

E F

G

H

I

J

El diagrama nos dice, entre otras cosas que:

• hito 1: arranque del proyecto

• hito 2: las tareas B y C no pueden empezar hasta que termine la tarea A

• hito 3: las tareas D y E no pueden empezar hasta que termine la tarea B

• hito 5: la tarea I no puede empezar hasta que terminen D, F y G • hito 8: culminación del proyecto

Para construir un diagrama PERT se siguen los siguientes pasos:

1. se identifican hitos y tareas

2. se identifican las dependencias entre tareas

3. se construye el grafo 4. se estima la duración requerida por cada tarea

5. se determina el camino crítico

6. se usa el diagrama PERT a lo largo de la ejecución del proyecto, revisando la duración de las tareas y calculando de nuevo el camino crítico

Los pasos 1-4, sobre el ejemplo anterior, se traducen en la siguiente tabla



hito tiempo estimado tarea inicial final optimista realista pesimista PERT

A 1 2 2 2 3 2,2 B 2 3 3 5 6 4,8 C 2 6 2 3 6 3,3 D 3 5 1 2 3 2,0 E 3 4 4 7 10 7,0 F 4 5 1 1 2 1,2 G 6 5 4 5 10 5,7 H 6 7 4 4 6 4,3 I 5 8 1 2 4 2,2 J 7 8 4 6 8 6,0

En las estimaciones de tiempo se han incluido 3 valores, un valor mínimo de duración (aproxima-ción optimista, si todo fuera perfectamente), un valor máximo (aproximación pesimista, lo peor que puede pasar) y un valor intermedio (aproximación realista, lo que parece razonable que cueste llevar a cabo la tarea). La última columna muestra la estimación realizada por el método PERT, que responde a la siguiente fórmula

optimista 4 realista pesimista6

Con estos datos se puede estimar el tiempo mínimo necesario para alcanzar cada hito. El primer hito se considera en tiempo 0,0. Para los demás hitos se toman en consideración cada una de las tareas Ti que llevan a él (anteriores). Para cada una de dichas tareas Ti, sea H1i el hito de arran-que y H2i el hito de terminación. Para cada Ti se calcula

1. T1i, momento de arranque, que es el tiempo del hito H1i

2. T2i, momento de terminación, que es T1i + duración estimada de la tarea El momento en que se alcanza el hito H2i es el máximo de los T2i de las tareas que convergen en él.

La siguiente tabla resume los cálculos para el ejemplo anterior.

hito ¿cuándo? camino crítico 1 0,0 - 2 2,2 A 3 7,0 A, B 4 14,0 A, B, E 5 15,2 A, B, E, F 6 5,5 A, C 7 9,8 A, C, H 8 17,4 A, B, E, F, I

tarea inicio final A 0,0 2,2 B 2,2 7,0 C 2,2 5,5 D 7,0 9,0 E 7,0 14,0 F 14,0 15,2 G 5,5 11,2 H 5,5 9,8 I 15,2 17,4 J 9,8 15,8

El camino crítico se calcula de atrás hacia adelante (esto es, del hito 8 al hito 1, en el ejemplo pro-puesto) teniendo en cuenta qué tarea de las que convergen en el nodo termina más tarde:

• hito 8: el caso peor es: hito 5 + tarea I

• hito 5: el caso peor es: hito 4 + tarea F



• hito 4: el caso peor es: hito 3 + tarea E

• hito 3: el caso peor es: hito 2 + tarea B

• hito 2: el caso peor es: hito 1 + tarea A • hito 1: tiempo 0,0

1 2

3

6

8

7

5

4

A

B

C

D

E F

G

H

I

J

Dado que el camino crítico impone un tiempo mínimo de realización del proyecto y, por tanto, la fecha más temprana en la que se espera terminarlo, dicho camino crítico se convierte en el objeto a optimizar si la fecha de terminación no fuera aceptable. Identificadas las tareas críticas, se pue-de intentar reducir su tiempo de realización a base de incrementar los recursos dedicadas a la misma, posiblemente derivándolos de otras tareas que no son críticas. Las herramientas de sopor-te de los cálculos PERT permiten realizar simulaciones hasta modelar los objetivos deseados.

Nótese que la optimización del camino crítico supone alterar la asignación de recursos al proyecto. Puede ocurrir que baste una adecuada reubicación de otras tareas que comparten recursos para, sin aumentar el gasto total, se optimice la asignación de recursos al proyecto. Pero en otras oca-siones, reducir el tiempo consumido por una tarea puede implicar el incremento neto de recursos y, por tanto, el incremento de coste del proyecto. En estos casos, hay que llegar a un equilibrio entre gasto y duración. La técnica mostrada permite analizar diferentes posibilidades justificando en cada caso el aumento de gasto. A lo largo de la realización del proyecto, los tiempos estimados pueden irse reemplazando por los tiempo incurridos reales, actualizando el cálculo del camino crítico y permitiendo detectar a tiempo si hay desviaciones que impacten en la terminación del proyecto o no. Los recursos asignados al proyecto en cada momento pueden irse optimizando en función de la evolución de los cálculos PERT.

Es habitual utilizar diagramas de GANTT (presentados anteriormente) para trabajar con los con-ceptos del modelo PERT y estudiar gráficamente el camino crítico del proyecto.

Resumen La técnica PERT permite:

• identificar tareas, hitos y relaciones entre todo ello

• estimar tiempos: • duración de cada tarea,

• momento en el que se alcanza cada hito,

• momento de arranque y culminación de cada tarea y

• tiempo estimado para completar el proyecto

• determinar el camino crítico

• que se debe monitorizar para gestionar desviaciones en la ejecución del proyecto, y



• que es el conjunto de tareas a optimizar para reducir la duración global del proyecto.

La principal limitación del método PERT es su dependencia de las estimaciones de tiempo. La práctica muestra una tendencia invariable al optimismo por parte del planificador, tanto mayor ale-jado de la realidad como menor es su experiencia. Por ello es tan importante usar PERT como herramienta de planificación previa y de seguimiento a lo largo del proyecto, incluyendo los tiem-pos reales en el informe final de forma que sirva de experiencia para futuros proyectos de carácter similar.

3.5.2. Referencias • R. Burke, “Project Management: Planning and Control Techniques”, John Wiley & Sons; 3rd

edition. May 16, 2001. • J.J. Moder, C.R. Phillips, E.W. Davis, “Project Management With Cpm, Pert & Precedence

Diagramming”, Blitz Publishing Company; 3rd edition. February, 1995.

• K. Lockyer, J. Gordon, “Project Management and Project Network Techniques”, Trans-Atlantic Publications; 6th edition. December 1, 1995.

• R.D. Archibald, R.L. Yilloria, “Network-based Management Systems”, (Information Science S.) John Wiley & Sons Inc. March, 1967.

Magerit versión 2 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 desarro-llo, 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 infor-mació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 ex-poner 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 pregun-tas planificadas sin margen para la improvisación. Las entrevistas se dicen libres cuando, exis-tiendo 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 ex-tenderse 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á fuertemen-te 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 participan-tes, 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 informa-ció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 pudie-ra 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.

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 provoca-das).

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 consecuen-cias 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 conse-cuencias 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 determi-nado tema, analizar nuevas necesidades de información, así como comunicar los resultados obte-nidos como consecuencia de un estudio.

Para realizar una reunión es necesario designar a las personas que deben participar en ella y de-terminar 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, 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 en-tre los asistentes. La persona responsable de la reunión ejercita la dinámica de dirección de gru-pos, 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 reunio-nes.

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 va-rios 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 prin-cipal 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 introduc-ción, una visión previa, el cuerpo del tema, una revisión y la conclusión final. Previamente, el po-nente 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 estructura-da el mensaje, sino que además, el contenido se debe exponer de una forma convincente, utili-zando 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 utili-zar como pueden ser datos estadísticos, análisis de resultados, etc.

También tiene especial relevancia escoger los apoyos audiovisuales oportunos que aclaren con-ceptos 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 piza-rras, 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 materia-les necesarios que se hayan considerado oportunos en la preparación de la presentación.

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 cen-trado el tema objeto de la presentación, resaltando los puntos más importantes y utilizando el ma-terial 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 impor-tante, 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, mate-rial 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. Doro-

fee, 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

Magerit versión 2 Valoración Delphi


3.7. Valoración Delphi La técnica o método Delphi13, original de la Rand Corporation (Research ANd Development), co-menzó 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 prospec-tivos 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 au-tor 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 pro-blemas técnicamente complejos.

• Está planteada como una reflexión organizada de expertos sobre un tema concreto, re-flexión que permite recoger las ideas y opiniones más cualificadas en el ámbito de la seguri-dad (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 re-capitulació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 mayori-taria, 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 posi-bles.

• 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 aca-bado: 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 cues-tionario, 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.

13 “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.



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 co-rrecta a las personas correctas, si la pregunta estaba claramente expresada o si, por el con-trario se debe volver a empezar con nuevas preguntas y/o nuevos entrevistados.

Se elabora un cuestionario¿cuánto vale X?

Se determina qué opiniones cuentan

Se tabulan las respuestas

¿consenso?

Se recogen las respuestas

Se distribuye el cuestionario

Se distribuye 1. el cuestionario2. las respuestas

ya está

no

si

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 pun-tuales 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. Suce-sivas 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 disposi-

ción a colaborar

• probablemente lo que está mal es el diseño del cuestionario y más vale revisarlo que in-sistir 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 conjun-to del grupo seleccionado.



• 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 ale-jados.

• 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 elemen-tos 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 loga-rítmicas suelen ser las más adecuadas.

Dados n valores, x1, x 2, ... , x n se definen los siguientes estadísticos:

Media o valor medio

x 1n i 1

n

xi

Mediana Habiendo ordenado los valores xi en orden ascendente (de menor a mayor), se deno-mina mediana al primer valor que deja por debajo al 50% de los datos; es decir al va-lor en la posición n 2

Desviación estándar o típica

1n 1 i 1

n

x i x 2

Desviación media

desviación media 1n i 1

n

x i x

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

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 in-tercuartí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, con-viene 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 adecua-da. 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 quinta14. En el análisis se suman los puntos recibidos por cada respuesta para determinar su posición relativa en la ordena-ció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 ra-zonado 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 co-

14 Obviamente, hay que adecuar estos números a cada caso concreto.



mún o generalizada en la sociedad.

3.7.5. Referencias • J. Fowles, “Handbook of Futures Research. Westport, Greenwood Press, 1978.

• H.A. Linstone and M. Turoff (eds), “The Delphi Method: Techniques and Applications”, Read-ing, 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 Re-port, 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.

magerit v2 metodologia de analisis y gestion de riesgos

Documents