Guzm

án, 2

00

9

Antonio Guzmánantonio.guzman@urjc.es

Guzm

án, 2

00

9

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

13/04/23 07:04 a. m. 2

Guzm

án, 2

00

9

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

13/04/23 07:04 a. m. 3

ISO – International Standardization OrganizationIEC – International Electrotechnical Commision

Guzm

án, 2

00

9

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 17799:2005 y renombrada en el 2007 como ISO 27002:2005). Publicada en 2005 y renombrada en 2007.

* En desarrollo13/04/23 07:04 a. m. 4

Guzm

án, 2

00

9

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

13/04/23 07:04 a. m. 5/50

Guzm

án, 2

00

9

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

• ISO/IEC 27031*: estará centrada en la continuidad de negocio.

13/04/23 07:04 a. m. 6/50

Guzm

án, 2

00

9

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

13/04/23 07:04 a. m. 7/50

Guzm

án, 2

00

9

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.

13/04/23 07:04 a. m. 8/50

Partes Interesad

as

(Seguridadde la

InformaciónGestionada)

Partes Interesad

as

(Requisitos y

Expectativaspara la

Seguridadde la

Información)

Guzm

án, 2

00

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

13/04/23 07:04 a. m. 9/38

Guzm

án, 2

00

9

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 la organización y como parte de continuas mejoras.

13/04/23 07:04 a. m. 10

Guzm

án, 2

00

9

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

13/04/23 07:04 a. m. 11

Guzm

án, 2

00

9

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

Para cada uno de estos aspectos, se proponen diversas métricas de seguridad.

http://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdf13/04/23 07:04 a. m.

12/38

Guzm

án, 2

00

9

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 necesidades de información específica.

13/04/23 07:04 a. m. 13

Guzm

án, 2

00

9

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• PTA• ACE Team

13/04/23 07:04 a. m. 14

Guzm

án, 2

00

9

Este modelo tiene cinco pasos:1. Identificar los objetivos de

seguridad2. Evaluar el sistema3. Realizar la

descomposición del sistema

4. Identificar las amenazas5. Identificar las

vulnerabilidades

13/04/23 07:04 a. m. 15

Guzm

án, 2

00

9

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

13/04/23 07:04 a. m. 16

Guzm

án, 2

00

9

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.

13/04/23 07:05 a. m. 17

Guzm

án, 2

00

9

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.

13/04/23 07:05 a. m. 18

Guzm

án, 2

00

9

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• Atacante Motivado• Crimen organizado

13/04/23 07:05 a. m. 19

Guzm

án, 2

00

9

STRIDE es una metodología para identificar amenazas conocidas. Establece seis categorías:• Spoofing Identity• Tampering with Data• Repudiation• Information Disclosure• Denial of service• Elevation of privilege

13/04/23 07:05 a. m. 20

Guzm

án, 2

00

9

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:

13/04/23 07:05 a. m. 21

5

)

(

_ILITYDISCOVERABUSERAFFECTED

ITYEXPLOTABILBILITYREPRODUCTIDAMAGE

DreadRisk

Guzm

án, 2

00

9

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

13/04/23 07:05 a. m. 22

Guzm

án, 2

00

9

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

13/04/23 07:05 a. m. 23

Guzm

án, 2

00

9

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• Habilitar contramedidas.

13/04/23 07:05 a. m. 24

Guzm

án, 2

00

9

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 CVSS – Common Vulnerability Scoring System

13/04/23 07:05 a. m. 25

Guzm

án, 2

00

9

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 factorialmente con cada amenaza que se estima.

13/04/23 07:05 a. m. 26

Guzm

án, 2

00

9

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.

13/04/23 07:05 a. m. 27

Guzm

án, 2

00

9

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

13/04/23 07:05 a. m.28/38

Guzm

án, 2

00

9

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 bien un decálogo de buenas costumbres.

13/04/23 07:05 a. m. 29

Guzm

án, 2

00

9

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.

13/04/23 07:05 a. m. 30

Guzm

án, 2

00

9

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• Plan de seguridad

13/04/23 07:05 a. m. 31

Guzm

án, 2

00

9

13/04/23 07:05 a. m. 32

http://www.ar-tools.com/index.html?tools/pilar/index.html

Guzm

án, 2

00

9

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 última etapa propone contramedidas para los riesgos.

13/04/23 07:05 a. m.33/38

Guzm

án, 2

00

9

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.

• Identificar y valorar los activos software del sistema.

13/04/23 07:05 a. m.34/38

Guzm

án, 2

00

9

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.

13/04/23 07:05 a. m.35/38

Guzm

án, 2

00

9

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%20Countermeasure%20Determination%20and%20Calculation.pdf

13/04/23 07:05 a. m.36/38

Guzm

án, 2

00

9

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.

13/04/23 07:05 a. m. 37

Guzm

án, 2

00

9

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 • Estudiar los resultados.

13/04/23 07:05 a. m. 38

Guzm

án, 2

00

9

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/

13/04/23 07:05 a. m. 39

Guzm

án, 2

00

9

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)• Identificar la relevancia de cada componente• Remarcar las contramedidas.

13/04/23 07:05 a. m. 40

Guzm

án, 2

00

9

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• Entender cómo implementar contramedidas http://channel9.msdn.com/wiki/securitywiki/

inputvalidationtrainingmodules/13/04/23 07:05 a. m. 41

Guzm

án, 2

00

9

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 bank personnel

13/04/23 07:05 a. m. 42

Guzm

án, 2

00

9

DEMO–TAM (Threat Analysis & Modeling Tool)

http://msdn.microsoft.com/en-us/security/aa570413.aspx

13/04/23 07:05 a. m. 43

Guzm

án, 2

00

9

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 cualitativa (menos precisa y objetiva).

13/04/23 07:05 a. m. 44

Guzm

án, 2

00

9

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=41933

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.doc http://www.cramm.com/ http://www.csi.map.es/csi/pg5m20.htm http://blogs.msdn.com/threatmodeling/

13/04/23 07:05 a. m. 45