Sistemas De Evaluacion De Seguridad

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

 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

 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

 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

• 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

• 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

• 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

 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

 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

 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

• 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

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

 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

 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

 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

 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

 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

 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

 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

 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

 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

 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

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

 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

 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

http://www.elladodelmal.com	238
http://elladodelmal.blogspot.com	182
http://www.slideshare.net	19
file://	1

Sistemas De Evaluacion De Seguridad

by Chema Alonso on Jul 12, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 440

Statistics

Sistemas De Evaluacion De Seguridad — Presentation Transcript