Charla impartida por el Doctor Antonio Guzmán,miembro del Grupo de Arquitecturas de Altas Prestaciones de la Universidad Rey Juan Carlos de Madrid, en el Curso de Verano 2009 de Seguridad Informática en la Universidad de Salamanca.

1. Antonio Guzmán
antonio.guzman@urjc.es
Guzmán, 2009

2.  Estándares ISO/EIC 27000
 Modelos de Gestión de Riesgos
• Microsoft Threat Modeling
• STRIDE/DREAD
• TRIKE
• AS/NZS 4360
• CVSS
• OCTAVE
• MAGERIT
• CRAMM
• PTA
• ACE Team
 Conclusiones
Guzmán, 2009
12/07/09 06:23 AM 2

3.  Con toda probabilidad la certificación ISO/IEC-
27001 será casi una obligación para cualquier
empresa que desee competir en el mercado en
un corto plazo de tiempo.
 Esta certificación está encaminada al
establecimiento de niveles concretos y
adecuados de seguridad que serán compartidos
por los distintos sistemas que deseen
Guzmán, 2009
interrelacionarse. ISO – International Standardization Organization
IEC – International Electrotechnical Commision
12/07/09 06:23 AM 3

4.  El conjunto de estándares que aportan información de la familia ISO-2700x que se pueden
tener en cuenta son:
(http://www.iso27001security.com/html/27004.html)
• BS 7799-2:2005 (ISO/IEC 27001:2005)
• ISO/IEC 27000 – proporcionará una visión general del
marco normativo y un vocabulario común utilizado por
todas las normas de la serie
• ISO/IEC 27001 ISMS - Especificaciones para la creación de
un sistema de gestión de la seguridad de la información
(SGSI). Publicada en 2005.
• ISO/IEC 27002 – Código de buenas prácticas para la
gestión de la seguridad de la información describe el
conjunto de objetivos de control y controles a utilizar en la
construcción de un SGSI (actualizada desde la ISO/IEC
Guzmán, 2009
17799:2005 y renombrada en el 2007 como ISO
27002:2005). Publicada en 2005 y renombrada en 2007.
* En desarrollo
12/07/09 06:23 AM 4

5. • ISO/IEC 27003 ISMS* – proporcionará una guía de
implantación de la norma ISO/IEC 27001.
• ISO/IEC 27004*: describirá los criterios de medición y
gestión para lograr la mejora continua y la eficacia de
los SGSI.
• ISO/IEC 27005 – proporcionará criterios generales
para la realización de análisis y gestión de riesgos en
materia de seguridad.
• ISO/IEC 27006:2007 es una guía para el proceso de
acreditación de las entidades de certificación de los
SGSI. Publicada en 2007.
• ISO/IEC 27007*: será una guía para auditar SGSI.
Guzmán, 2009
12/07/09 06:23 AM 5/50

6. • ISO/IEC TR 27008*: proporcionará una guía para auditar los
controles de seguridad de la norma ISO 27002:2005.
• ISO/IEC 27010*: proporcionará una guía específica para el
sector de las comunicaciones y sistemas de interconexión de
redes de industrias y Administraciones, a través de un
conjunto de normas más detalladas que comenzarán a partir
de la ISO/IEC 27011.
• ISO/IEC 27011*: será una guía para la gestión de la seguridad
en telecomunicaciones (conocida también como X.1051).
Guzmán, 2009
• ISO/IEC 27031*: estará centrada en la continuidad de
negocio.
12/07/09 06:23 AM 6/50

7. • ISO/IEC 27032 *: será una guía para la ciberseguridad.
• ISO/IEC 27033*: sustituirá a la ISO/IEC 18028, norma
sobre la seguridad en redes de comunicaciones.
• ISO/IEC 27034*: proporcionará guías para la seguridad
en el desarrollo de aplicaciones.
• ISO/IEC 27799: no es estrictamente una parte de la serie
ISO 27000 aunque proporciona una guía para el
desarrollo de SGSI para el sector específico de la salud.
Guzmán, 2009
12/07/09 06:23 AM 7/50

8.  El diseño e implantación de un SGSI se encuentra
influenciado por las necesidades, objetivos,
requisitos de seguridad, los procesos, los
empleados , el tamaño, los sistemas de soporte y
la estructura de la organización.
Partes
Interesadas Partes
Interesadas
(Requisitos y
Expectativas (Seguridad
Guzmán, 2009
para la de la
Seguridad Información
de la Gestionada)
Información)
12/07/09 06:23 AM 8/50

9.  La Seguridad de la Información es un proceso.
 La Seguridad de la Información se basa en personas.
 La Seguridad de la Información debe orientarse al
riesgo.
 Un buen SGSI es un sistema rentable para la
organización.
 Aunque no existe la seguridad absoluta. El SGSI
ayuda a la gestión.
 Un proyecto SGSI requiere un equipo de trabajo
Guzmán, 2009
multidisciplinar.
12/07/09 06:23 AM 9/38

10.  El empleo de este estándar permitirá a las
organizaciones dar respuesta a los interrogantes de
cuán efectivo y eficiente es el Sistema de Gestión de
la Seguridad de la Información (SGSI) y qué niveles
de implementación y madurez han sido alcanzados.
 Estas mediciones permitirán comparar los logros
obtenidos en seguridad de la información sobre
periodos de tiempo en áreas de negocio similares de
Guzmán, 2009
la organización y como parte de continuas mejoras.
12/07/09 06:23 AM 10

11. • En una organización se debe describir cómo se
interrelacionan e interactúan el SGSI con las mediciones,
desarrollando guías que aseguren, aclaren y documenten
esta relación.
• Los objetivos son:
• Evaluar la efectividad de la implementación de los controles
de seguridad.
• Evaluar la eficiencia de SGSI.
• Proveer estados de seguridad que guíen las revisiones del
SGSI.
• Comunicar valores de seguridad a la organización.
• Servir como entradas al plan de análisis y tratamiento de
Guzmán, 2009
riesgos.
12/07/09 06:23 AM 11

12.  Los aspectos que se tienen en cuenta a la hora de establecer
estas mediciones son los siguientes:
• Evaluación y tratamiento de riesgos
• Políticas de seguridad
• Organización de la seguridad de la Información
• Gestión de activos
• Seguridad de recursos humanos
• Seguridad física y de entorno
• Gestión de las comunicaciones y operaciones
• Control de Accesos
• Sistemas de adquisición, desarrollo y mantenimiento de la Información
• Gestión de Incidentes de seguridad de la información
• Gestión de la continuidad de negocio
Guzmán, 2009
 Para cada uno de estos aspectos, se proponen diversas
métricas de seguridad.
http://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdf
12/07/09 06:24 AM 12/38

13.  Modelo de seguridad.
• Se debe desarrollar un programa de cómo ejecutar la
medición de la seguridad de la información.
• Para ello hay que definir un modelo que estructure los
atributos medibles con una entidad relevante.
• Debe definir cómo los atributos de una entidad son
cuantificados y convertidos a indicadores que provean
bases para la toma de decisiones, sustentados en
Guzmán, 2009
necesidades de información específica.
12/07/09 06:24 AM 13

14.  Al final lo importante no es tanto cuáles son los pasos a seguir
para la formulación del modelo como la estimación de qué
aspectos son los que se pueden definir. En función de qué se
haya estimado existen muchas posibilidades:
• Microsoft Threat Modelling
• STRIDE/DREAD
• TRIKE
• AS/NZS 4360
• CVSS
• OCTAVE
• Magerit
• CRAMM
Guzmán, 2009
• PTA
• ACE Team
12/07/09 06:24 AM 14

15.  Este modelo tiene cinco
pasos:
1. Identificar los objetivos de
seguridad
2. Evaluar el sistema
3. Realizar la descomposición del
sistema
4. Identificar las amenazas
5. Identificar las vulnerabilidades
Guzmán, 2009
12/07/09 06:24 AM 15

16.  Identificar los Objetivos
• Los objetivos se pueden clasificar en :
• Objetivos de Identidad
• Objetivos Financieros
• Objetivos de reputación
• Objetivos de integridad y confidencialidad
• Objetivos de disponibilidad
Guzmán, 2009
12/07/09 06:24 AM 16

17.  Evaluación del sistema
• Una vez que se han declarado los objetivos se debe
analizar el diseño del sistema para identificar los
componentes, los flujos de información y los límites de
confianza.
 Descomponer el sistema
• Implica identificar las características y los módulos con
impacto en la seguridad que deben ser evaluados.
Guzmán, 2009
12/07/09 06:24 AM 17

18.  Identificar las amenazas
• Se parte del hecho de que es imposible identificar
amenazas que no son conocidas. Por lo tanto,
concentrándose en los riesgos conocidos, se realiza
una identificación basada en el empleo de
herramientas de BugTraq.
Guzmán, 2009
12/07/09 06:24 AM 18

19.  Identificar las amenazas
• Además de saber qué tipo de amenaza es el que se
puede identificar, es preciso clasificar quién es el
posible atacante. Se propone la siguiente clasificación:
• Descubrimiento accidental
• Malware automático
• Atacante curioso
• Script Kiddies
Guzmán, 2009
• Atacante Motivado
• Crimen organizado
12/07/09 06:24 AM 19

20.  STRIDE es una metodología para identificar
amenazas conocidas. Establece seis categorías:
• Spoofing Identity
• Tampering with Data
• Repudiation
• Information Disclosure
• Denial of service
Guzmán, 2009
• Elevation of privilege
12/07/09 06:24 AM 20

21.  DREAD es un modelo que permite establecer un
grado de riesgo que permite ordenar los riesgos
mediante la evaluación de cinco categorías.
 Propone una expresión que se traduce en un
índice:
( DAMAGE + REPRODUCTIBILITY + EXPLOTABILITY +
AFFECTED USER + DISCOVERABILITY )
Risk _ Dread =
Guzmán, 2009
5
12/07/09 06:24 AM 21

22.  Damage Potential Si la amenaza se materializa, ¿cuánto daño puede causar?
• 0 = Nothing
• 5 = Individual user data is compromised or affected.
• 10 = Complete system or data destruction
 Reproducibility ¿Cómo de facil es reproducir el exploit?
• 0 = Very hard or impossible, even for administrators of the application.
• 5 = One or two steps required, may need to be an authorized user.
• 10 = Just a web browser and the address bar is sufficient, without authentication.
 Exploitability ¿Qué se necesita para materializar la amenaza?
• 0 = Advanced programming and networking knowledge, with custom or advanced attack tools.
• 5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools.
• 10 = Just a web browser
 Affected Users ¿Cuántos usuarios se ven afectados?
• 0 = None
• 5 = Some users, but not all
• 10 = All users
 Discoverability ¿Cómo de facil es descubrir esta amenaza?
Guzmán, 2009
• 0 = Very hard to impossible; requires source code or administrative access.
• 5 = Can figure it out by guessing or by monitoring network traces.
• 9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.
• 10 = The information is visible in the web browser address bar or in a form.
12/07/09 06:24 AM 22

23.  Es un modelo similar al propuesto desde
Microsoft.
 Existen sin embargo diferencias. TRIKE propone
una aproximación a la descripción del riesgo que
no aúna los ataques, las amenazas y las
vulnerabilidades.
 Al contrario, permite distinguir unos de otros
construyendo un sistema experto para toma de
Guzmán, 2009
decisiones.
12/07/09 06:24 AM 23

24.  El Australian/New Zealand Standard es simple, muy
flexible e iterativo .
 Proporciona una serie de conjuntos de tablas de riesgos
como ejemplos, pero permite desarrollar y adaptar su
propio modelo a las organizaciones.
 El modelo se resume en cinco puntos.
• Establecer el contexto
• Identificar los riesgos
• Analizar los riesgos
• Evaluar los riesgos
Guzmán, 2009
• Habilitar contramedidas.
12/07/09 06:24 AM 24

25.  El departamento de Homeland Security (DHS)
del gobierno de EEUU estableció que el
denominado grupo “NIAC Vulnerability
Disclosure Working Group”, que incorporaba a
Cisco Systems, Symantec, ISS, Qualys,
Microsoft, CERT/CC y eBay.
 Uno de los resultados de este grupo ha sido el
Guzmán, 2009
CVSS – Common Vulnerability Scoring System
12/07/09 06:24 AM 25

26.  CVSS no es un modelo en sí, sino que permite normalizar
las notificaciones de seguridad asignándole una métrica
única a las amenazas descubiertas.
 La definición de la métrica es muy compleja y su cálculo
implica tener en cuenta factores software y de entorno.
 La evaluación de estos factores obliga a utilizar una tabla
para determinar el grado de criticidad de las amenazas
conocidas.
 De hecho la sobrecarga que supone calcular el índice
CVSS sobre una aplicación determinada aumenta
Guzmán, 2009
factorialmente con cada amenaza que se estima.
12/07/09 06:24 AM 26

27.  CVSS no encuentra ni reduce la superficie de
ataque.
 Tampoco enumera los riesgos para una
programa determinado.
 Lo que proporciona es una aproximación técnica,
estandarizada, abierta y ordenada de una
vulnerabilidad específica.
Guzmán, 2009
12/07/09 06:24 AM 27

28.  http://nvd.nist.gov/cvss.cfm?calculator&adv
 http://jvnrss.ise.chuo-u.ac.jp/jtg/cvss/es/CVSSv2.html
 http://www.security-database.com/cvss.php#AV
 Ejemplo de vulnerabilidades:
• CVE-2009-1301
• CVE-2009-1279
Guzmán, 2009
12/07/09 06:24 AM 28/38

29.  Se trata de un modelo muy complejo originario de la
Carnagie Mellon University en colaboración con el
CERT.
 Se centra en la evaluación del riesgo organizativo y
no técnico.
 Aunque útil en la gestión de grandes organizaciones
es demasiado costoso y no proporciona medidas
para mitigar los efectos de las amenazas. Es más
Guzmán, 2009
bien un decálogo de buenas costumbres.
12/07/09 06:24 AM 29

30.  Se trata de una metodología promovida por el
CSAE (Consejo Superior de administración
electrónica) que persigue una aproximación
metódica al análisis de riesgos.
 Se trata por tanto de una metodología para
auxiliar en tarea de toma de decisiones en
entornos críticos.
Guzmán, 2009
12/07/09 06:24 AM 30

31.  Los objetivos de la aplicación de este modelo son:
• Concienciar a los responsables de los sistemas de información de la existencia
de riesgos y de la necesidad de atajarlos a tiempo
• Ofrecer un método sistemático para analizar tales riesgos
• Ayudar a descubrir y planificar las medidas oportunas para mantener los
riesgos bajo control
• Apoyar la preparación a la Organización para procesos de evaluación,
auditoría, certificación o acreditación, según corresponda en cada caso
 Su aplicación se estructura en cinco niveles:
• Modelo de valor
• Modelo de riesgos
• Estado de los riesgos
• Informe de insuficiencias
Guzmán, 2009
• Plan de seguridad
12/07/09 06:24 AM 31

32. http://www.ar-tools.com/index.html?tools/pilar/index.html
Guzmán, 2009
12/07/09 06:24 AM 32

33.  CRAMM - (CCTA (Central Computer and
Telecommunications Agency) Risk Analysis and
Management Method)
• Propuesta creada por la CCTA de Reino Unido.
• Actualmente está en su quinta versión
• Está estructurada en tres etapas
• Cada etapa está estructurada por unos cuestionarios que
permiten identificar y analizar los riesgos del sistema. La
Guzmán, 2009
última etapa propone contramedidas para los riesgos.
12/07/09 06:24 AM 33/38

34.  Etapa 1: Establecimiento de objetivos
• Definir los límites del estudio.
• Identificar y valorar los activos del sistema.
• Determinar el valor de los datos del sistema a través
de entrevistas con el personal acerca del potencial
daño empresarial que tendría la falta de
disponibilidad, su destrucción, falta de
confidencialidad o su modificación.
Guzmán, 2009
• Identificar y valorar los activos software del sistema.
12/07/09 06:24 AM 34/38

35.  Etapa 2: Evaluación de riesgos
• Identificar y valorar el tipo y nivel de amenazas que
podrían afectar al sistema.
• Evaluar la exposición del sistema frente a estas
amenazas.
• Combinar ambos aspectos con la valoración de los
activos para determinar una medida del riesgo.
Guzmán, 2009
12/07/09 06:24 AM 35/38

36.  Etapa 3: Identificación y Selección de
contramedidas
• Se propone una librería de contramedidas agrupadas
en 70 grupos lógicos para facilitar su aplicación.
http://www.cramm.com/files/techpapers/CRAMM%20Counte
Guzmán, 2009
12/07/09 06:24 AM 36/38

37.  El Practical Threat Analysis propone una suite
para la elaboración de modelos de gestión de
riesgos y permite estimar un nivel de seguridad a
partir de la información incluida en cada
proyecto.
Guzmán, 2009
12/07/09 06:24 AM 37

38.  La realización del modelo conlleva, como en casos
anteriores una serie de fases:
• Establecer los prerrequisitos del modelo
• Establecer lista de etiquetas
• Identificar los recursos del sistema
• Identificar las vulnerabilidades del sistema
• Identificar las contramedidas
• Identificar a los atacantes potenciales
• Identificar los potenciales puntos de entrada del sistema.
• Construir los escenarios de amenazas y los planes de mitigación
Guzmán, 2009
• Estudiar los resultados.
12/07/09 06:24 AM 38

39.  El ACE Team (Application Consulting &
Engineering Team) es parte de InfoSec en
Microsoft y los encargados de desarrollar un
modelo de gestión de riesgos.
http://blogs.msdn.com/threatmodeling/
Guzmán, 2009
12/07/09 06:24 AM 39

40.  Se propone una metodología para la extracción de un
modelo de gestión de riesgos:
• Identificar los objetivos de negocio
• Definir perfiles de usuario
• Definir datos
• Definir los controles de acceso a datos
• Generar los cases para cada usuario
• Definir componentes, servicios e identidades
• Detallar las llamadas de y desde el sistema.
• Generar y evaluar las amenazas (Attack Library)
Guzmán, 2009
• Identificar la relevancia de cada componente
• Remarcar las contramedidas.
12/07/09 06:24 AM 40

41.  Attack Library
• Esta diseñada para:
• Disponer del mínimo de información.
• Transmitir la relación del exploit, la causa y la
contramedida.
• Ser accesible para que la especificación de ataques no
suponga la presencia de un técnico avanzado en seguridad.
• Entender cómo probar el exploit
• Entender cómo reconocer una vulnerabilidad
Guzmán, 2009
• Entender cómo implementar contramedidas
http://channel9.msdn.com/wiki/securitywiki/inputvalidationtrainingm
12/07/09 06:24 AM 41

42.  Ejemplos de Attack Library
 Vandalism
• Threat – Denial of Service due to damage of the machine
Attack – Damage through blunt weapon attacks
Vulnerability - Machines made of mostly plastic parts
Mitigation - Use Cast Iron parts
Vulnerability - Exposed telephone style button
Mitigation – Use recessed buttons
Attack - Damage through vehicle intrusions
Vulnerability - ATM exposed in outdoor settings
Mitigation – Recess ATM behind wall with only interop panel exposed Install
Secura-Posts in front of ATMs
 Skimming
• Threat – exposure of ATM card/account data due to the presence of skimming devices on machines
Attack-Skimming device placed over card reader slot
Vulnerability – User cannot tell when a skimming device is present
Mitigation – place an LCD screen along edge of card slot. When user inserts card, ask
user to enter code displayed on LCD. If the user cannot see the LCD, skimming device present, notify
Guzmán, 2009
bank personnel
12/07/09 06:24 AM 42

43. DEMO–TAM (Threat Analysis & Modeling Tool)
http://msdn.microsoft.com/en-us/security/aa570413.aspx
Guzmán, 2009
12/07/09 06:24 AM 43

44.  Es necesario definir un modelo de evaluación de riesgos
 Los modelos existentes sólo permiten evaluar amenazas
conocidas. Esta evaluación se puede hacer de forma
cualitativa o cuantitativa.
 Una parte clave de estos modelos es la definición de una
métrica que permita evaluar el nivel de seguridad de un
sistema.
 En la definición de esta métrica es preciso evaluar las
vulnerabilidades y, en eso de nuevo, hay dos
posibilidades: una cuantitativa (más costosa) y otra
Guzmán, 2009
cualitativa (menos precisa y objetiva).
12/07/09 06:24 AM 44

45.  http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail
 http://alerta-antivirus.red.es/docs/analisis_ISO-27001.pdf
 http://www.owasp.org/index.php/Threat_Risk_Modeling
 http://www.first.org/cvss/cvss-guide.pdf
 www.cert.org/archive/pdf/01tr016.pdf
 http://www.ptatechnologies.com/Documents/PTA_for_Software.do
 http://www.cramm.com/
 http://www.csi.map.es/csi/pg5m20.htm
 http://blogs.msdn.com/threatmodeling/
Guzmán, 2009
12/07/09 06:24 AM 45