Taller de Construcción de Sistemas

Modelos de
Arquitectura de
Software (IIII)
YTALO BORJA MORI
FACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA
UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
Security
Perspective
Security Perspective
La habilidad del sistemas para mantener un control confiable, monitoreo y
auditoría de quiénes ejecutan acciones en los recursos del sistema.
Adicionalmente la habilidad para detectar y recuperarse de security
breaches.

Contexto: Hoy en día necesitamos proteger los sistemas de información,

necesitamos introducir seguridad, especialmente a los sistemas distribuidos,
a los sistemas que son deployados en redes públicas y otras razones más.
Facebook attack!

 https://www.theverge.com/2018/10/12/17968302/facebook-hacker-
personal-details-29-million-accounts
 ¿Qué es Seguridad?

Seguridad es el conjunto de procesos y tecnologías que permite a los
propietarios de recursos en el sistema para controlar con confianza a quiénes
ejecutan actividades en recursos en particular.


Quiénes?

Personas, software, etc.
 Being secure o Estar seguro

El hecho de indicar que el sistema en el que trabajan es seguro es difícil de
determinar.

Se puede decir a ciencia cierta que un Sistema es Seguro?

La seguridad es un proceso de manejo de riesgos que balancea los riesgos de
seguridad en contra de los costos de protegerse de ellos.
Aplicabilidad de seguridad en 6 vistas

Image from Rozanski

Image from Rozanski
 Objetivos de la Seguridad

Objetivos respecto a proteger ASSET en contra de daños (HARM).
 ASSET, cualquier recurso de valor para los stakeholders, puede ser tangible o
no tangible.
 Tipos de daños comunes:

Disclosure relacionado con Confidentiality

Modification relacionado con Integrity

Unavailability relacionado con Availability
 Ejemplos

Prevenir discloure o revelación de los datos de tarjeta de crédito de nuestros
clientes.


Prevenir la modificación ilegal de las notas de los alumnos de la FISI.


La no disponibilidad de la cuentas bancarias de los clientes. Ejemplo: Banco
Interbank
 ¿Qué actividades se realizan en la
ingeniería de seguridad de software?
 Security Policy

Es una descripción de alto nivel de los principals (subjects), assets (objects) y
security properties que deben ser robustos en el sistema.


Para definirlo las políticas de seguridad se requiere los requerimientos y la
arquitectura del sistema en alto nivel.
 Términos importantes

Principals: personas, programas de computadora (entidades con algo de
autoridad, pueden no ser el adversario)


Assets: cualquier cosa o recurso que necesita ser protegido.


Properties: se define en relación entre los Principals y los Assets.
 Ejemplo de Security Properties

La familia CIA, una de las propiedad de seguridad más comunes
 Confidentility: El adversario no debería poder leer mis emails.
 Integrity: El adversario no debería poder cambiar my estado bancario.
 Availability: El adversario no debería prevenirme de acceder a una website.


Otras familias:

Authenticity

Anonymity

Non-repudiation

Forward secrecy.


Algunas propiedades no van a tener una clasificación, por ejemplo si nos hacemos
la siguiente pregunta: ¿El sistema está haciendo lo que debe de hacer?
 Threat Model

¿Cuáles son los recursos disponibles para el adversario?


Recursos y capacidades del adversario, por ejemplo partes del sistema pueden
ser observadas, o ser influenciados o modificadas. También entidades que se
pueden corromper con el fin de extraer secretos o ser usados para actuar como si
fueran el adversario.


Estrategia: El adversio escogerá cualquier recursos que sea conveniente para él
para violar los security properties. SIEMPRE PREGÚNTENSE QUÉ, no cómo ni por
qué.
 Threat vs Threat Model

Threat 
Threat Model

Qué cosa mala puede suceder. 
Las capacidades del adversario.

Qué es los que el adversario quiere 
Pregunta: Qué?
conseguir o cómo. 
Ejemplo: El adversario puede

Objetivo final o medios de ataques. observar el tráfico de datos, el

Pregunta: Cómo? Por qué? adversario puede controlar un

Ejemplos: El adverio roba la clave, el servidor y hacer que este actúe
adversario roba dinero, etc. erróneamente.
¿Cuál es el security policy? Preguntense lo siguiente:
1) Cuál es el Sistema bajo ataque?
2) Quiénes son los principals?
3) Cuáles son los assets?
4) Cuáles son los security properties a mantener?

¿Cuál es el threat model?

 Asimetría entre el atacante y la defensa

El atacante solo necesita un camino para violar un security property. Dado los
recursos en el threat model.


El defensor necesita asegurarse que ninguna estragia adversaria pueda violar los
security properties.


Cuál de los presenta mayor dificultad? El ataque o la defensa?
 ¿Cuándo un sistema es seguro?

Esta pregunta no tiene sentido amenos que se defina de esta forma:


UN SISTEMA ES SEGURO SI UN ADVERSARIO LIMITADO POR UN ESPECÍFICO
THREAT MODEL NO PUEDE VIOLAR EL SECURITY POLICY.


Entonces: ¿Un sistema puede ser más seguro que otro?
Recomendación

 J. Saltzer and M. Schroeder. The Protection of Information in Computer

Systems. Fourth ACM Symposium on Operating Systems Principles
(October 1973)
 Importantes Skills

Inferir las policies y los threat models.


Inferir cómo y por qué un sistema de seguridad falla.
Image from Rozanski
Image from Rozanski
Design the security implementation
using architectural tactics for security
 Mitigation Tactics
 Authentication mechanisms
 Password, smartcard, biometric, single-sign-on

 Access control
 Typically using 3rd party security infrastructure(JavaEE,.Net)

 Limit access using firewall

 Secrecy
 Needed to protect sensitive information that leaves our system
 Use secure network link(SSL/TLS); encrypt data on client machine
 Detection and Recovery Tactics
 Intrusion detection system
 Restrict access when attack
 Use availability tactics (see later) to recover from failures
Common Problems and Pitfalls

 Inadequate Security Requirements

 No clear security requirements
 Complex security policies
 Ignoring the insider threat
 Architecture pitfalls
 Technology-driven approach & piecemeal security
 Using ad hoc or unproven security technology
 Security embedded in the application code
 Lack of administration facilities
 System does not fail securely
 Security as an afterthought
Checklist for Security Requirements

 What are the system’s security goals?

 What are the sensitive resources?
 What are the confidentiality, integrity, availability, and accountability goals?
 What are the system’s security policies?
 Do these policies satisfy the security goals?
 Are these policies as simple as possible?
 What are the system’s security threats?
 Have you considered insider as well as outsider threats?
 Have you consider how the system’s deployment environment will alter the
threats?
Checklist for Architecture Definition

 What security mechanisms does your system include to prevent or reduce each security
threat?
 What security mechanisms does your system include to detect and recover from security
breaches?
 Have you considered end-to-end security?
 Is there a security gap?
 What is the system’s weakestpoint?
 Are you using proven third-party security infrastructure as much as possible?
 e.g.standardsecuritytechnologiesinJEEor.Net
 Are your security mechanisms cost-effective?
 Have you considered impact on other qualities?
 e.g. impact on performance and usability
 Tarea en Grupo

Del libro: 24 Deadly Sins of Software Security. Autor:
Michael Howrad.

Detectar 4 pecados que el aplicativo que están
desarrollando pueda originar security breach. Sustentar
por qué.

Este trabajo será por sus grupos y tendrá deadline.
Martes: 06 de noviembre del 2018 hasta las 11.00 pm.
Muchas Gracias.