Arquitectura de Software - Profesoresisis3702/dokuwiki/lib/... · Seguridad Habilidad de controlar,...

DEPARTAMENTO DE SISTEMAS

Arquitectura de Software

Atributos de Calidad Seguridad

ISIS-3702


Agenda

•  Introducción •  Touchpoints •  Perspectiva de Seguridad


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]



  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.



  Las mas relevantes:   Seguridad   Desempeño y escalabilidad   Disponibilidad y resilience (recuperabilidad)   Evolución


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




  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



  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



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


Agenda



Touchpoints

Imagen tomada de “Sotware Security:Building Security In” Gary McGraw


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.


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


Touchpoints

•  Puntos de Contacto en Seguridad



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


Touchpoints

•  Manejo de Conocimiento



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


  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


•  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


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


•  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


•  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


•  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


•  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


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



•  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



•  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



•  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



•  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



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


Casos de Abuso



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)


•  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


•  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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


SQUARE

•  Paso 5. Seleccionar técnica de descubrimiento o  Util cuando se tienen diferentes tipos de usuarios

o  Evitan problemas de comunicación


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


SQUARE

•  Paso 6. Descubrimiento de requerimientos de Seguridad o  Se utiliza la o las técnicas seleccionadas para

descubrir los requerimientos de seguridad


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


SQUARE

•  Paso 7. Categorización de Requerimientos o  Se busca diferenciar los requerimientos escenciales

de los deseables


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


SQUARE

•  Paso 8. Requerimientos Priorizados o  Priorización basada en análisis costo/benficio y

viabilidad técnica


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


SQUARE

•  Paso 9. Inspección de Requerimientos o  Se buscan defectos inyectados en esta fase

o  Apoyo de los Usuarios y expertos en seguridad


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



•  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



•  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


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



Tomado de [1] pag 157



•  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



•  La propuesta

o  Análisis de resistencia al ataque

o  Análisis de ambigüedad

o  Análisis de debilidad



•  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



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



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



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



•  Por default JBoss no inicia el Java 2 Security Manager



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



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



•  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



•  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



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


Agenda



•  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


Perspectiva de Seguridad



•  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



•  Ejemplo

89




90


•  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



•  Ejemplo




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



•  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



•  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



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



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



•  Ejemplo




•  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



  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



•  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



•  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



•  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



•  Material preparado por o  Darío Correal o  Nicolás López

104


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

Arquitectura de Software - Profesoresisis3702/dokuwiki/lib/... · Seguridad Habilidad de controlar,...

Documents

Transcript of Arquitectura de Software - Profesoresisis3702/dokuwiki/lib/... · Seguridad Habilidad de controlar,...