de Arquitectura de Software

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
Perspectiva Atributo Deseado
Accesibilidad Uso por parte de personas con discapacidades
Disponibilidad Habilida del sistema de estar operacional y recuperarse
y Recuperación 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 Habilidad del sistema de funcionar dentro de sus
Escalabilidad 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
6
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 aproximaciones comunes para lograr cumplir con el atributo

Arquitecturales 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
Aplicabilidad de perspectivas a vistas
Vista Seguridad Desempeño y Disponibilidad y Evolución

Escalabilidad Resilience
/Perspectiva
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
Agenda
•  Touchpoints
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
Touchpoints
  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
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
Touchpoints
•  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 - Casos de Abuso
•  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
•  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   HTTP Query Strings

  Target Programs That Write to Privileged OS Resources   User-Controlled Filename
  Use a User-Supplied Configuration File to Run   Passing Local Filenames to Functions That Expect a URL
Commands   Meta-characters in E-mail Header
  That Elevate Privilege   File System Function Injection, Content Based
Make Use of Configuration File Search Paths   Client-side Injection, Buffer Overflow
  Direct Access to Executable Files   Cause Web Server Misclassification
  Embedding Scripts within Scripts   Alternate Encoding the Leading Ghost Characters
  Leverage Executable Code in Nonexecutable Files   Using Slashes in Alternate Encoding
  Argument Injection   Using Escaped Slashes in Alternate Encoding
  Command Delimiters   Unicode Encoding
  Multiple Parsers and Double Escapes   UTF-8 Encoding
  User-Supplied Variable Passed to File System Calls   URL Encoding
  Postfix NULL Terminator   Alternative IP Addresses
  Postfix, Null Terminate, and Backslash   Slashes and URL Encoding Combined
  Relative Path Traversal   Web Logs
  Client-Controlled Environment Variables   Overflow Binary Resource File
  User-Supplied Global Variables (DEBUG=1, PHP   Overflow Variables and Tags
Globals,
  Overflow Symbolic Links
  and So Forth)
  MIME Conversion
  Session ID, Resource ID, and Blind Trust   HTTP Cookies
  Analog In-Band Switching Signals (aka “Blue Boxing”)
  Filter Failure through Buffer Overflow
  Attack Pattern Fragment: Manipulating Terminal Devices   Buffer Overflow with Environment Variables
  Simple Script Injection
  Buffer Overflow in an API Call
  Embedding Script in Nonscript Elements   Buffer Overflow in Local Command-Line Utilities
  XSS in HTTP Headers
  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)
ISO/IEC 15408-2:2005
•  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
“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]
ISO/IEC 15408-2:2005
•  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
“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]
ISO/IEC 15408-2:2005
•  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
“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]
ISO/IEC 15408-2:2005
•  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
“The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.” [5]
ISO/IEC 15408-2:2005
•  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
“The TSF shall ensure that the protocol used provides for the
unambiguous association between the security attributes and the user
data received.” [5]
ISO/IEC 15408-2:2005
•  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
“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]
ISO/IEC 15408-2:2005
•  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
“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]
ISO/IEC 15408-2:2005
•  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
“The TSF shall ensure the operation of [assignment: list of TOE capabilities]
when the following failures occur: [assignment: list of type of failures].” [5]
ISO/IEC 15408-2:2005
•  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
“The TSF shall require the following events to occur prior to unlocking the
session: [assignment: events to occur].” [5]
ISO/IEC 15408-2:2005
•  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
“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

<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">
•  Qué pasaría si:

o  Salvo la página html en mi computador
o  Cambio el “hidden”
o  Hago submit de la forma
•  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
•  Touchpoints
Atributos de calidad - Seguridad
•  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
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
•  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
90
•  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
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
105

de Arquitectura de Software

Cargado por

Copyright:

Formatos disponibles

de Arquitectura de Software

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

de Arquitectura de Software

Cargado por

Copyright:

Formatos disponibles

DEPARTAMENTO DE SISTEMAS

“ An Architectural Perspective is a collection of

 La metodología propuesta guía el proceso de

 Las mas relevantes:

 Estructura de las perspectivas (en [2]):

Concerns atributos o propiedades de calidad que cubre la perspectiva

Actividades pasos para aplicar la perspectiva a la vista

Tácticas aproximaciones comunes para lograr cumplir con el atributo

Otras fuentes Referencias a otras fuentes sobre el atributo de calidad

 El objetivo de aplicar una perspectiva a

Aplicabilidad de perspectivas a vistas

Vista Seguridad Desempeño y Disponibilidad y Evolución

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

• Manejo del Riesgo

• Puntos de Contacto en Seguridad

• La seguridad es fundamental durante el

• Puntos de Contacto en Seguridad

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

• Los puntos de contacto

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

• 1. Entender el contexto de negocio

 Identificar los riesgos de negocio ayuda a definir los artefactos

• 4. Definir la estrategía de mitigación del riesgo

• 2. Análisis de riesgos arquitecturales

• La seguridad es una propiedad del software no

• Cómo diseñadores de nuestro sistema

• Cómo crear los casos de abuso?

• Crear un modelo de ataque

 Make the Client Invisible  HTTP Query Strings

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

• Provee un conjunto común de requerimientos

• Direccionado a la definir requerimientos para la

• Parte 2 - Requerimientos Funcionales de

• Clase FAU : Auditoria de Seguridad

“The TSF shall be able to maintain profiles of system usage, where an

• Clase FCO : Comunicación

“The TSF shall be able to generate evidence of receipt for received

• Clase FCS : Soporte Criptográfico

• Clase FDP : Protección de los Datos de

• Clase FIA :Identificación y Autenticación

• Clase FMT : Manejo de la Seguridad

• Clase FPR: Privacidad

• Clase FRU: Utilización de Recursos

• Clase FTA: Acceso al TOE

• Clase FTP: Canales/Caminos Confiables

• Security Quality Requirements Engineering

o Su objetivo es descubrir, categorizar y priorizar

o Compuesto por 9 pasos

o Se utilizan diferentes técnicas para descubrir y

o Paso 1. Unificar Conceptos

o Paso 1. Unificar Conceptos

 Alinear términos del Dominio

 Lenguajes de Dominio Específico

 Modelos de Dominio Específico

 MIT Process Handbook

 APQC Process Classification Framework

• Paso 2. Identificar Objetivos de Seguridad

• Paso 2. Identificar Objetivos de Seguridad

  La metodología propuesta guía el proceso de

  Las mas relevantes:

  Estructura de las perspectivas (en [2]):

  El objetivo de aplicar una perspectiva a

•  Manejo del Riesgo

•  Puntos de Contacto en Seguridad

•  La seguridad es fundamental durante el

•  Puntos de Contacto en Seguridad

•  Los puntos de contacto

•  1. Entender el contexto de negocio

  Identificar los riesgos de negocio ayuda a definir los artefactos

•  4. Definir la estrategía de mitigación del riesgo

•  2. Análisis de riesgos arquitecturales

•  La seguridad es una propiedad del software no

•  Cómo diseñadores de nuestro sistema

•  Cómo crear los casos de abuso?

•  Crear un modelo de ataque

  Make the Client Invisible   HTTP Query Strings

•  Provee un conjunto común de requerimientos

•  Direccionado a la definir requerimientos para la

•  Parte 2 - Requerimientos Funcionales de

•  Clase FAU : Auditoria de Seguridad

•  Clase FCO : Comunicación

•  Clase FCS : Soporte Criptográfico

•  Clase FDP : Protección de los Datos de

•  Clase FIA :Identificación y Autenticación

•  Clase FMT : Manejo de la Seguridad

•  Clase FPR: Privacidad

•  Clase FRU: Utilización de Recursos

•  Clase FTA: Acceso al TOE

•  Clase FTP: Canales/Caminos Confiables

•  Security Quality Requirements Engineering

o  Su objetivo es descubrir, categorizar y priorizar

o  Compuesto por 9 pasos

o  Se utilizan diferentes técnicas para descubrir y

o  Paso 1. Unificar Conceptos

o  Paso 1. Unificar Conceptos

  Alinear términos del Dominio

  Lenguajes de Dominio Específico

  Modelos de Dominio Específico

  MIT Process Handbook

  APQC Process Classification Framework

•  Paso 2. Identificar Objetivos de Seguridad

•  Paso 2. Identificar Objetivos de Seguridad

o  Se elaboran los formatos necesarios para guardar y

•  Paso 4. Realizar Evaluación de Riesgos

•  Paso 4. Realizar Evaluación de Riesgos

•  Paso 5. Seleccionar técnica de

•  Paso 5. Seleccionar técnica de

•  Paso 6. Descubrimiento de requerimientos de

•  Paso 6. Descubrimiento de requerimientos de

•  Paso 7. Categorización de Requerimientos

•  Paso 7. Categorización de Requerimientos

•  Paso 8. Requerimientos Priorizados

•  Paso 8. Requerimientos Priorizados

•  Paso 9. Inspección de Requerimientos

•  Paso 9. Inspección de Requerimientos

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

•  Algunos conceptos utilizados en análisis de

•  Para poder llevar a cabo el análisis es

•  El análisis debe comenzar por las vistas de alto

•  1. Análisis de Resistencia al Ataque

o  1.1 Identificar Defectos Generales

o  1.2 Buscar correspondencia con los patrones de

o  1.3 Identificar riesgos en la arquitectura

o  1.4 Entender y demostrar la viabilidad de los ataques

o  1.1 Identificar Defectos Generales

o  1.4 Entender y demostrar la viabilidad de los ataques

•  Qué pasaría si:

•  Por default JBoss no inicia el Java 2 Security

o  3.2 Encontrar y analizar fallas en

•  3.3 Identificar Servicios usados por la

•  3.4 Cuáles suposiciones se hacen sobre

  (%) antes del nombre de un archivo revela el

•  Aplicación de la Perspectiva de Seguridad

2.  Definir las políticas de seguridad