DEPARTAMENTO DE SISTEMAS
Arquitectura de Software
Atributos de Calidad Seguridad
ISIS-3702
DEPARTAMENTO DE SISTEMAS
Agenda
• Introducción • Touchpoints • Perspectiva de Seguridad
DEPARTAMENTO DE SISTEMAS
Atributos de calidad
“ An Architectural Perspective is a collection of activities, tactics and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’s architectural views” [2]
DEPARTAMENTO DE SISTEMAS
Atributos de calidad
La metodología propuesta guía el proceso de diseño de la arquitectura para garantizar que un sistema exhiba una o más atributos de calidad relevantes para los stakeholders.
DEPARTAMENTO DE SISTEMAS
Atributos de calidad
Las mas relevantes: Seguridad Desempeño y escalabilidad Disponibilidad y resilience (recuperabilidad) Evolución
DEPARTAMENTO DE SISTEMAS
6
Perspectiva Atributo Deseado Accesibilidad Uso por parte de personas con discapacidades Disponibilidad y Recuperación
Habilida del sistema de estar operacional y recuperarse ante fallas
Desarrollo Habilidad del sistema de ser diseñado, implementado, etc.
Evolucíon Flexibilidad de ser modificado Internacional. Independencia de un lenguaje particular Localización No dependencia de la ubicación física de sus
componentes Desempeño y Escalabilidad
Habilidad del sistema de funcionar dentro de sus parámetros aceptables de desempeño y manejar incrementos en el volumen de procesamiento
Regulación Conformidad con leyes nacionales e internacionales Seguridad Habilidad de controlar, monitorear y auditar quién puede
ejecutar acciones y sobre cuáles recursos Usabilidad Facilidad de los usuarios para interactuar con el sistema
Atributos de calidad
DEPARTAMENTO DE SISTEMAS
Atributos de calidad
Estructura de las perspectivas (en [2]):
Elemento Descripción Aplicabilidad Cuáles de las vistas se ven impactadas por la perspectiva?
Concerns atributos o propiedades de calidad que cubre la perspectiva
Actividades pasos para aplicar la perspectiva a la vista
Tácticas Arquitecturales
aproximaciones comunes para lograr cumplir con el atributo de calidad
Problemas Aspectos en los que comúnmente se pueden tener problemas para lograr el atributo
Lista de chequeo listas para revisar que se han abordado todos los aspectos relevantes de la perspectiva
Otras fuentes Referencias a otras fuentes sobre el atributo de calidad
DEPARTAMENTO DE SISTEMAS
Atributos de calidad
El objetivo de aplicar una perspectiva a una vista es encontrar y/o definir:
Cómo la arquitectura va a cumplir un atributo de calidad?
Posibles mejoras al diseño para cumplir con el atributo
Otros artefactos que podrán ayudar a validar que el sistema si cumple con un atributo
DEPARTAMENTO DE SISTEMAS
Atributos de calidad
Vista/Perspectiva
Seguridad Desempeño y Escalabilidad
Disponibilidad y Resilience
Evolución
Funcional Medio Medio Bajo Alto
Información Medio Medio Bajo Alto
Concurrencia bajo Alto Medio Medio
Desarrollo Medio Bajo Bajo Alto
Despliegue Alto Alto Alto Bajo
Operacional Medio Bajo Medio Bajo
Aplicabilidad de perspectivas a vistas
DEPARTAMENTO DE SISTEMAS
Agenda
• Introducción • Touchpoints • Perspectiva de Seguridad
DEPARTAMENTO DE SISTEMAS
Touchpoints
Imagen tomada de “Sotware Security:Building Security In” Gary McGraw
DEPARTAMENTO DE SISTEMAS
Touchpoints
• Manejo del Riesgo o Análisis de riesgo a nivel arquitectural
Threat modeling
o Análisis de riesgos a lo largo del ciclo de desarrollo
• Puntos de Contacto en Seguridad o Seguridad en el Software no es Software para
Seguridad o Seguridad es un atributo de calidad en el software
tanto como desempeño, escalabilidad, etc.
DEPARTAMENTO DE SISTEMAS
Touchpoints
• La seguridad es fundamental durante el desarrollo de software o Ejemplo: Microsoft’s Trustworthy Computing
Initiative
• Los desarrolladores, arquitectos y analistas no toman en cuenta la seguridad
• La seguridad no es solamente un password o usar SSL
DEPARTAMENTO DE SISTEMAS
Touchpoints
• Puntos de Contacto en Seguridad
Imagen tomada de “Sotware Security:Building Security In” Gary McGraw
DEPARTAMENTO DE SISTEMAS
Touchpoints
• Los puntos de contacto o No están diseñados para un ciclo de desarrollo
particular
o Cascada
o RUP
o XP / Metodologías Agiles
o FDD
DEPARTAMENTO DE SISTEMAS
Touchpoints
• Manejo de Conocimiento
Imagen tomada de “Sotware Security:Building Security In” Gary McGraw
DEPARTAMENTO DE SISTEMAS
Touchpoints
• 1. Entender el contexto de negocio o Hacer explícito los motivadores de negocio
o Niveles de servicio establecidos
o Retorno de la inversión
• 2. Identificar los riesgos técnicos y de negocio o Los riesgos de negocio van encontra de los
objetivos de negocio
DEPARTAMENTO DE SISTEMAS
Identificar los riesgos de negocio ayuda a definir los artefactos de software claves para mitigar los riesgos de seguridad
Un riesgo técnico es una situación que va encontra del diseño y/o la implementación de un sistema en consideración
o 3. Priorizar los Riesgos Esta labor toma en cuenta los objetivos de negocio de la
empresa
Se tiene en cuenta el impacto que generaría el riesgo
Touchpoints
DEPARTAMENTO DE SISTEMAS
• 4. Definir la estrategía de mitigación del riesgo o Tan importante como descubrir los riesgos técnicos
es saber como mitigarlos
o Se debe generar una estrategia de mitigación de riesgos
• 5. Ejecutar la estrategia de mitigación o Los artefactos donde se hayan identificado fallas
deben ser corregidos
Touchpoints
DEPARTAMENTO DE SISTEMAS
Touchpoints
• Touchpoints o Buenas prácticas en desarrollo de software
seguro o Relativamente fáciles de integrar en el proceso
de desarrollo de software Conocer y entender riesgos de seguridad Diseñar pensando en seguridad Análisis y pruebas de los artefactos principales desde
el punto de vista de seguridad
DEPARTAMENTO DE SISTEMAS
• 2. Análisis de riesgos arquitecturales o Se enfoca en los artefactos de especificación y
diseño
o Se buscan Defectos en Autenticación
Seguridad de los Componentes
Seguridad de los nodos de ejecución
Problemas de protección de los datos
Touchpoints
DEPARTAMENTO DE SISTEMAS
• 5. Casos de Abuso o Se enfocan en los artefactos de requerimientos y
casos de uso
o Es una forma de entrar en la mente de los atacantes
o Similares a los casos de uso
o Describen el comportamiento del sistema bajo ataque
o Se debe conocer lo que se quiere proteger, de quién y por cuanto tiempo
Touchpoints
DEPARTAMENTO DE SISTEMAS
• 6. Requerimientos de Seguridad o Se detallan requerimientos de seguridad o Se especifican claramente
Entradas Salidas
Cursos básicos de acción Caminos de extensión y excepción
o Es importante identificar y mantener los requerimientos de seguridad
Touchpoints
DEPARTAMENTO DE SISTEMAS
• La seguridad es una propiedad del software no una característica
• Cuando actuamos como diseñadores de un sistema tenemos una ventaja sobre los atacantes … conocemos mejor el software
• Este conocimiento es utilizado para mejorar la seguridad
Touchpoints - Casos de Abuso
DEPARTAMENTO DE SISTEMAS
• Cómo diseñadores de nuestro sistema debemos preguntarnos o Cuáles suposiciones están implícitas en nuestro
sistema ?
o Qué cosas harían estas suposiciones falsas?
o Qué clases de patrones de ataque usaría un atacante?
Touchpoints - Casos de Abuso
DEPARTAMENTO DE SISTEMAS
• Casos de Abuso o Propuestos inicialmente en 1999 (McDermont)
o Extensión de los casos de uso con casos de mal uso (Opdahl 2000)
o Uno de los objetivos de los casos de abuso es decidir y documentar cómo debe reaccionar el software ante su uso ilegítimo
Touchpoints - Casos de Abuso
DEPARTAMENTO DE SISTEMAS
• Cómo crear los casos de abuso? o Inicialmente responsabilidad de los diseñadores y
los analistas de seguridad
o Toman como entrada Conjunto de Casos de Uso
Lista de patrones de ataque
o El primer paso es identificar y documentar actores o agentes que podrían ejecutar un ataque
o El segundo paso es crear anti-requerimientos
o El tercer paso es crear un modelo de ataque
Touchpoints - Casos de Abuso
DEPARTAMENTO DE SISTEMAS
• Anti-requerimientos o Creados por los analistas de seguridad
o Se analizan los casos de uso contra la lista de potenciales atacantes
o Se documentan los ataques que causarian que el requerimiento fallara
o Anti-requerimientos ayudan a entender como una amaneza puede abusar del sistema
o Usualmente ligados a la ausencia o falla de una función de seguridad
Touchpoints - Casos de Abuso
DEPARTAMENTO DE SISTEMAS
• Crear un modelo de ataque o Dada una lista de casos de uso y una lista de
amenazas se hace una comparación contra una lista de ataques
o Se pueden utilizar patrones de ataque / STRIDE
o Seleccione patrones de ataque relevantes para el sistema
o Construya casos de abuso que describan como su sistema reacciona a un ataque
Touchpoints - Casos de Abuso
DEPARTAMENTO DE SISTEMAS
• STRIDE o Spoofing
Pretender ser otra persona
o Tampering Modificar datos o código
o Repudiation Negar una acción
o Information Disclosure Exponer información a alguien no autorizado
o Denial of Service Denegar o degradar el servicio a los usuarios
o Elevation of Privilege Ganar privilegios sin autorización
Touchpoints - Casos de Abuso
DEPARTAMENTO DE SISTEMAS
Touchpoints - Patrones de Ataque
Make the Client Invisible Target Programs That Write to Privileged OS Resources Use a User-Supplied Configuration File to Run
Commands That Elevate Privilege Make Use of Configuration File Search Paths Direct Access to Executable Files Embedding Scripts within Scripts Leverage Executable Code in Nonexecutable Files Argument Injection Command Delimiters Multiple Parsers and Double Escapes User-Supplied Variable Passed to File System Calls Postfix NULL Terminator Postfix, Null Terminate, and Backslash Relative Path Traversal Client-Controlled Environment Variables User-Supplied Global Variables (DEBUG=1, PHP
Globals, and So Forth) Session ID, Resource ID, and Blind Trust Analog In-Band Switching Signals (aka “Blue Boxing”) Attack Pattern Fragment: Manipulating Terminal Devices Simple Script Injection Embedding Script in Nonscript Elements XSS in HTTP Headers
HTTP Query Strings User-Controlled Filename Passing Local Filenames to Functions That Expect a URL Meta-characters in E-mail Header File System Function Injection, Content Based Client-side Injection, Buffer Overflow Cause Web Server Misclassification Alternate Encoding the Leading Ghost Characters Using Slashes in Alternate Encoding Using Escaped Slashes in Alternate Encoding Unicode Encoding UTF-8 Encoding URL Encoding Alternative IP Addresses Slashes and URL Encoding Combined Web Logs Overflow Binary Resource File Overflow Variables and Tags Overflow Symbolic Links MIME Conversion HTTP Cookies Filter Failure through Buffer Overflow Buffer Overflow with Environment Variables Buffer Overflow in an API Call Buffer Overflow in Local Command-Line Utilities Parameter Expansion String Format Overflow in syslog()
DEPARTAMENTO DE SISTEMAS
Casos de Abuso
Imagen tomada de “Sotware Security:Building Security In” Gary McGraw
DEPARTAMENTO DE SISTEMAS
ISO/IEC 15408-2:2005
• Provee un conjunto común de requerimientos de seguridad de IT
• Procedimiento de evaluación para establecer un nivel de confianza
• Sirve como guía para el desarrollo de sistemas de software
• El sistema bajo evaluación se denomina Target of Evaluation (TOE)
DEPARTAMENTO DE SISTEMAS
• Direccionado a la definir requerimientos para la protección de información en sistemas de software
o Confidencialidad
o Integridad
o Disponibilidad
ISO/IEC 15408-2:2005
DEPARTAMENTO DE SISTEMAS
• Parte 2 - Requerimientos Funcionales de Seguridad o Establece un conjunto de componentes funcionales
para expresar requerimientos de seguridad en un TOE Componentes
Familias
Clases
o Se utiliza como guía y referencia para la formulación de requerimientos de seguridad
ISO/IEC 15408-2:2005
DEPARTAMENTO DE SISTEMAS
• Clase FAU : Auditoria de Seguridad o Esta familia define requerimientos para analizar de
forma automática actividades del sistema y auditar datos para encontrar posibles o reales violaciones de seguridad
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall be able to maintain profiles of system usage, where an individual profile represents the historical patterns of usage performed by the member(s) of [assignment: the profile target group].” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FCO : Comunicación o Provee dos familias para asegurar la identidad de un
participante en un intercambio de datos Non-repudiation of Origin Non-repudiation of receipt
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall be able to generate evidence of receipt for received [assignment: list of information types] at the request of the [selection: originator, recipient, [assignment: list of third parties]].” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FCS : Soporte Criptográfico o Soporte del ciclo de vida de las llaves criptográficas
Generación Distribución Acceso Destrucción
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: cryptographic key generation algorithm] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FDP : Protección de los Datos de Usuario o Esta familia especifica requerimientos para
protección de datos Control de Acceso Autenticación de los Datos Exportar fuera del control del TSF Importar al TSF Flujo de Información Integridad de los datos almacenados Transferencia segura de datos
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received.” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FIA :Identificación y Autenticación o Esta familia de requerimientos busca establecer y
verificar la supuesta identidad de un usuario Fallas de autenticación Definición de atributos de usuario Especificación de secretos Autenticación de usuarios Identificación de usuarios
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received.” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FMT : Manejo de la Seguridad o Esta clase especifica el manejo de atributos de
seguridad, datos y funciones Manejo de atributos de seguridad
Revocación
Expiración
Roles
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to restrict the ability to [selection: change_default, query, modify, delete,[assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FPR: Privacidad o Esta clase contiene requerimientos de privacidad
para proveer protección al usuario contra descubrimiento y mal uso de su identidad por parte de otros usuarios Anonimato
Pseudonimos
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user name bound to [assignment: list of subjects and/or operations and/or objects].” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FRU: Utilización de Recursos o Esta clase provee soporte a la disponibilidad de
recursos requeridos (procesamiento/almacenamiento) Tolerancia a Fallas Prioridad del Servicio Adjudicación de Recursos
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall ensure the operation of [assignment: list of TOE capabilities] when the following failures occur: [assignment: list of type of failures].” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FTA: Acceso al TOE o Esta familia especifica los requerimientos para
controlar una sesión establecida con un usuario Limitación de sesiones concurrentes
Sesiones con bloqueo
Historia de acceso
Establecimiento de una sesión
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall require the following events to occur prior to unlocking the session: [assignment: events to occur].” [5]
DEPARTAMENTO DE SISTEMAS
• Clase FTP: Canales/Caminos Confiables o Esta clase provee requerimientos de canales de
comunicaciones seguros entre el usuario y el TSF o entre el TSF y otros sistemas Canales Seguros Caminos Seguros
o Ejemplo
ISO/IEC 15408-2:2005
“The TSF shall provide a communication channel between itself and a remote trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure.” [5]
DEPARTAMENTO DE SISTEMAS
SQUARE
• Security Quality Requirements Engineering (SQUARE)
o Desarrollado en Carnegie-Mellon University
o Su objetivo es descubrir, categorizar y priorizar requerimientos de seguridad
o Compuesto por 9 pasos
o Se utilizan diferentes técnicas para descubrir y clasificar los requerimientos
DEPARTAMENTO DE SISTEMAS
SQUARE
• SQUARE o Paso 1. Unificar conceptos o Paso 2. Identificar objetivos de seguridad o Paso 3. Desarrollar artefactos para soportar las
técnicas de descubrimiento o Paso 4. Realizar evaluación de riesgos o Paso 5. Seleccionar técnicas de descubrimiento o Paso 6. Descubrir requerimientos de seguridad o Paso 7. Categorizar requerimientos o Paso 8. Priorizar requerimientos o Paso 9. Inspeccionar Requerimientos
DEPARTAMENTO DE SISTEMAS
SQUARE
o Paso 1. Unificar Conceptos o Entradas
Definiciones tomadas de IEEE, Ontologías de Dominio, SWEBOK, ISO 15408, etc.
o Técnicas Entrevistas, Grupos Objetivos
o Participantes Analistas de Requerimientos, Usuarios
o Salidas Documento de Definiciones
DEPARTAMENTO DE SISTEMAS
SQUARE
o Paso 1. Unificar Conceptos El objetivo es tener una definición común de los términos
involucrados en la aplicación a desarrollar
Alinear términos del Dominio
Lenguajes de Dominio Específico
Modelos de Dominio Específico
MIT Process Handbook
APQC Process Classification Framework
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 2. Identificar Objetivos de Seguridad o Entradas
Definiciones, Motivadores de Negocio, Políticas y procedimientos
o Técnicas Entrevistas, Encuestas
o Participantes Analistas de requerimientos, Usuarios
o Salidas Objetivos
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 2. Identificar Objetivos de Seguridad o Es posible que diferentes usuarios de la
organización (stakeholders) tengan diferentes objetivos de seguridad en mente
Director de recursos humanos
Director de tecnología
Director Financiero
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 3. Desarrollar artefactos para soportar la definición de requerimientos de seguridad o Entradas
Casos de Abuso
o Técnicas
Sesiones de Trabajo
o Participantes
Ingenieros de Requerimientos
o Salidas
Artefactos requeridos, casos de abuso
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 3. Desarrollar artefactos para soportar la definición de requerimientos de seguridad
o Se elaboran los formatos necesarios para guardar y evaluar toda la información requerida
Casos de abuso
Requerimientos
Tablas de evaluación
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 4. Realizar Evaluación de Riesgos o Entradas
Casos de Abuso, Escenarios, Objetivos de Seguridad
o Técnicas Modelaje de Riesgos
o Participantes Ingenieros de Requerimientos, Expertos en Seguridad,
Usuarios
o Salidas Resultados de la evaluación de riesgos
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 4. Realizar Evaluación de Riesgos o Participan expertos en riesgos con amplio
conocimiento en la organización o Se utilizan mecanismos de evaluación
Matrices de Riesgos Escenarios de Calidad
Fuente Estimulo Artefactos Ambiente Respuesta Punto de Sensibilidad Riesgo / no-riesgo
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 5. Seleccionar técnica de descubrimiento o Entradas
Técnicas candidatas, objetivos de negocio, conocimiento de la organización, ISO 15408 (Componentes, Familias, Clases)
o Técnicas Sesiones de Trabajo
o Participantes Ingenieros de requerimientos
o Salidas Técnicas seleccionadas
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 5. Seleccionar técnica de descubrimiento o Util cuando se tienen diferentes tipos de usuarios
o Evitan problemas de comunicación
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 6. Descubrimiento de requerimientos de Seguridad o Entradas
Artefactos, Resultados de análisis de riesgos, técnicas selecionadas, casos de abuso
o Técnicas Entrevistas, Encuestas, Listas de chequeo
(ISO-15408-2:2005)
o Participantes Usuarios
o Salidas Requerimientos de seguridad iniciales
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 6. Descubrimiento de requerimientos de Seguridad o Se utiliza la o las técnicas seleccionadas para
descubrir los requerimientos de seguridad
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 7. Categorización de Requerimientos o Entradas
Requerimientos Iniciales, Arquitectura, ISO15408
o Técnicas Sesiones de trabajo
o Participantes Ingenieros de Requerimientos
o Salidas Requerimientos Categorizados
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 7. Categorización de Requerimientos o Se busca diferenciar los requerimientos escenciales
de los deseables
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 8. Requerimientos Priorizados o Entradas
Requerimientos Categorizados, Resultados de la evaluación de riesgos
o Técnicas Métodos de priorización: Triage
o Participantes Usuarios
o Salidas Requerimientos priorizados
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 8. Requerimientos Priorizados o Priorización basada en análisis costo/benficio y
viabilidad técnica
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 9. Inspección de Requerimientos o Entradas
Requerimientos Priorizados
o Técnicas
Inspección de métodos: Revisión de Pares
o Participantes
Equipo de Inspección
o Salidas
Requerimientos Inspeccionados
DEPARTAMENTO DE SISTEMAS
SQUARE
• Paso 9. Inspección de Requerimientos o Se buscan defectos inyectados en esta fase
o Apoyo de los Usuarios y expertos en seguridad
DEPARTAMENTO DE SISTEMAS
Touchpoints – Análisis de Riesgos
• Análisis de Riesgos
o Identificar y Priorizar riesgos en un punto particular del proceso de desarrollo de software
o Para hacer este análisis se requiere
Conocer bien el negocio
Conocer la legislación respectiva
Contar con el equipo humano requerido
DEPARTAMENTO DE SISTEMAS
Touchpoints – Análisis de Riesgos
• Actividades requeridas en el análisis de Riesgos
o Aprender todo lo posible del sistema a analizar
o Discutir los aspectos de seguridad relevantes para el producto
o Realizar un análisis de impacto
o Priorizar los riesgos
o Desarrollar una estrategia de mitigación
DEPARTAMENTO DE SISTEMAS
Touchpoints – Análisis de Riesgos
• Algunos conceptos utilizados en análisis de riesgos o Bien : El objeto que se desea proteger o Riesgo: Probabilidad de que el bien sufra un evento
con impacto negativo Riesgo = probabilidad X impacto
o Amenaza: Actor o agente fuente del peligro o Vulnerabilidad: Defecto o debilidad en los
procedimientos de seguridad, diseño, implementación, o controles internos que pueden resultar en una violación a las políticas de seguridad Para que una amenaza tenga éxito, debe actuar contra
una vulnerabilidad en le sistema
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• Para poder llevar a cabo el análisis es necesario tener una visión general del sistema objetivo
o Vistas Arquitecturales
o Modelos
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
Tomado de [1] pag 157
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• El análisis debe comenzar por las vistas de alto nivel o Componentes o Procesos o Datos
• Consideraciones durante el análisis o Las amenazas posibles al sistema o Los riesgos presentes en cada nivel o Los tipos de vulnerabilidades en cada nivel o Impacto en el negocio de cada riesgo o La probabilidad de que se materialice el riesgo
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• La propuesta
o Análisis de resistencia al ataque
o Análisis de ambigüedad
o Análisis de debilidad
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
Tomado de [3] pag 162
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• 1. Análisis de Resistencia al Ataque
o Se busca descubrir riesgos conocidos
o 1.1 Identificar Defectos Generales
o 1.2 Buscar correspondencia con los patrones de ataque
o 1.3 Identificar riesgos en la arquitectura
o 1.4 Entender y demostrar la viabilidad de los ataques conocidos
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
o 1.1 Identificar Defectos Generales No cumplimiento de normas, guías y políticas Generación y Manejo de tokens de autenticación Mal uso de primitivas criptográficas Rompimiento del encapsulamiento
o 1.2 Buscar correspondencia con los patrones de ataque Utilizar los resultados de los casos de abuso y la lista de
patrones de ataque
o 1.3 Identificar riesgos en la arquitectura Checklists Patrones de Diseño
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
o 1.4 Entender y demostrar la viabilidad de los ataques conocidos
o Grafos de Explotación Ayudan a entender el tipo de acceso o patrón es
requerido para llevar a cabo un ataque dado un riesgo de software
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
Tomado de [3] pag 164
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• Qué pasaría si: o Salvo la página html en mi computador o Cambio el “hidden” o Hago submit de la forma
<input type="hidden" name="userid" value="ktrout"> <input type="hidden" name="credit_ok" value="1"> <input type="hidden" name="form_expires" value="20001001:12:45:20">
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• Por default JBoss no inicia el Java 2 Security Manager
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• 2. Análisis de Ambiguedad o Se busca descubrir nuevos riesgos
o Descubrir ambiguedades e inconsistencias
o 2.1 Cada participante hace un análisis por separado
o 2.2 Se hace una puesta en común de los resultados individuales
o Todos estamos de acuerdo en como funciona el sistema??
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• 3. Análisis de Debilidades o Se busca entender las dependencia externas de
software
o 3.1 Debilidades o fallas en los frameworks de desarrollo / Contenedores de aplicaciones empresariales
.NET
JEE
o 3.2 Encontrar y analizar fallas en
COTS (Commercial off-the-shelf)
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• 3.3 Identificar Servicios usados por la aplicación
o SOA / ESBs
• 3.4 Cuáles suposiciones se hacen sobre el software externo
o Browser
o RMI
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
• Ejemplo – Jboss
o Las versiones 3.2.2 a 3.2.7 y 4.0.2 le permiten a un atacante obtener información via GET (utilizando “%.”)
Path de instalación
(%) antes del nombre de un archivo revela el contenido del archivo
DEPARTAMENTO DE SISTEMAS
Análisis de Riesgos
Example 1 (Installation path disclosure): [3.2.x and 4.0.2] Request: >>telnet [jbosshost] 8083 >>GET %. HTTP/1.0
Reply: HTTP/1.0 400 C:\Programme\jboss-4.0.2\server\default\conf (Zugriff verweigert) Content-Type: text/html
Example 2 (Config file download): [4.0.2] Request: >>telnet [jbosshost] 8083 >>GET %server.policy HTTP/1.0
Reply:
HTTP/1.0 200 OK Content-Length: 550 Content-Type: text/html
Tomado de: http://marc.info/?l=bugtraq&m=111911095424496&w=2
DEPARTAMENTO DE SISTEMAS
Agenda
• Introducción • Touchpoints • Perspectiva de Seguridad
DEPARTAMENTO DE SISTEMAS
• Aplicación de la Perspectiva de Seguridad 1. Identificar los recursos sensitivos
2. Definir las políticas de seguridad
3. Identificar amenazas
4. Diseñar la implementación de seguridad
5. Evaluar riesgos de seguridad
86
Atributos de calidad - Seguridad
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
Tomado de [1] pag 370
DEPARTAMENTO DE SISTEMAS
• 1. Identificar los recursos sensitivos o Antes de considerar cómo asegurar el sistema, se
debe conocer lo que se quiere asegurar
o Actividades Clasificar los recursos sensitivos
Se utilizan los puntos de vista funcional y de información como entradas
Por cada tipo de recurso sensitivo defina las razones por la que debe ser considerado, quién es su propietario y los controles de acceso requeridos
88
Perspectiva de Seguridad
DEPARTAMENTO DE SISTEMAS
• Ejemplo
89
Perspectiva de Seguridad
Tomado de [1] pag 371
DEPARTAMENTO DE SISTEMAS
90
Perspectiva de Seguridad
• 2. Definir la política de seguridad
o Este modelo identifica a quién se le asigna un nivel de confianza en cúales recursos del sistema
o Actividades
Identificar clases de recursos
Identificar conjuntos de control de acceso
Identificar operaciones sensitivas
Identificar la integridad de los requerimientos
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• Ejemplo
Tomado de [1] pag 374
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• 3. Identificar las amenazas del sistema
o Las siguientes preguntas son un buen inicio
Quién podría tratar de infringir las políticas de seguridad?
Cómo tratarían de hacerlo?
Cúales son las principales características de los atacantes?
Cúales las consecuencias si logran su cometido?
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• Se puede utilizar un árbol de ataques para modelar este paso
• Se debe crear un árbol de ataque para cada uno de los posibles objetivos de un atacante
• Una vez se tiene el árbol se analiza si el sistema neutraliza al atacante o no
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
Tomado de [1] pag 376
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• 4. Diseñar la Implementación de Seguridad
o El objetivo de este paso es diseñar la infraestructura de seguridad de todo el sistema
o Se seleccionan tecnologías de seguridad
Single-sign-on
Firewalls
SSL
Tecnologías criptográficas
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
o El resultado de este paso es un conjunto de decisiones que se reflejarán en los puntos de vista
• Actividades a desarrollar
o Diseñar un mecanismo de mitigación de amenazas
Modificar decisiones arquitecturales !!!
o Diseñar un mecanismo de detección y recuperación
Detectar violaciones al sistema de seguridad y cómo recuperarse en tal caso
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
o Evaluar la tecnología
Usar tecnologías de seguridad especializadas
o Integrar la tecnología
Decidir cómo debe ser integrada la tecnología de seguridad seleccionada en el paso anterior
• 5. Evaluar los riesgos de Seguridad
o El propósito es evaluar si la propuesta de seguridad tiene una relación costo/riesgo aceptable
o ATAM
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• Ejemplo
Tomado de [1] pag 379
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• Tácticas Arquitecturales
o 1. Aplicar principios reconocidos de seguridad
Otorgar la menor cantidad de privilegios posibles
Asegurar el enlace más débil
La seguridad de un sistema es tan fuerte como su elemento más débil
Tecnológico, procedimental, humano
Defender en profundidad
Anillos de seguridad
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
Separar y compartimentalizar
Separar responsabilidades
Un ataque en una parte del sistema no afecta todo el sistema
Mantener el diseño de seguridad simple
Usar los valores por omisión
Dejar los valores por omisión (de fábrica) en algunas aplicaciones
Fallar de forma segura
Suspender la auditoría por que el log de auditoría esta lleno
Asumir que las entidases externas no son seguras
Auditar eventos sensibles
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• 2. Autenticar los usuarios del sistema o Personas, computadores, software, etc.
o Username/password
o Llaves pública/privada (X.509)
o Tokens / Hardware
o Sistemas Single-sign-on
• 3. Autorizar el Acceso o Restringir lo que los usuarios pueden hacer
o Listas de control de acceso
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• 4. Asegurar la privacidad de la información
o Sólo los dueños de la información pueden tener acceso a la información
o Uso de criptografía
• 5. Asegurar la integridad de la información
o Asegurar que la información esta protegida de cambios no autorizados
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• 6. Proteger la disponibilidad
o Proteger el sistema de ataques para reducir la disponibilidad (DoS)
• 7. Integrar tecnologías de seguridad
• 8. Proveer administración de seguridad
DEPARTAMENTO DE SISTEMAS
Perspectiva de Seguridad
• Material preparado por o Darío Correal o Nicolás López
104
DEPARTAMENTO DE SISTEMAS
105
Referencias
[1] Rozanski N, Woods E. “Software Systems Architecture” Addison-Wesley. 2005
[2] Documenting Component and Connector Views with UML 2.0, Technical Report, ESC-TR-2004-08
[3] Gary McGraw. “Software Security – Building Security In” Addison-Wesley. 2005
[4] Greg Hoglund, Gary McGraw, “Exploiting Software – How to Break Code” Addison-Wesley, 2004
[5] ISO/IEC 15408-2:2005
Top Related