Presentación realizada durante el Workshop AEI Seguridad 2012 en León, España.

1. Primer Workshop de Investigación en
Tecnologías de Seguridad TIC
Propuesta para la generación y selección
adaptable de configuraciones de seguridad
para sistemas de gestión de procesos de
negocio
Ángel Jesús Varela Vaca y Rafael Martínez Gasca
Universidad de Sevilla
30 de noviembre de 2012

2. Situación actual
Índice
 Nuevos retos de la Seguridad IT - BPM
 OPBUS: Automatización Seguridad - BPM
 Análisis automático de riesgos en BPs
 Tratamiento automático de riesgos para BPs
 Patrones-Modelos de características
 Caso de estudio
 Modelos de control de acceso para BPMS
 Conclusiones

3. Situación actual
Nuevos retos de Seguridad IT - BPMS
Gestión del riesgo del
flujo de control y datos
Dependencia de riesgos
Dependencia de
Procesos de Contramedidas
Negocio
Nuevos Modelos de
BPM Systems control de acceso
Flexibilidad y agilidad
ante los cambios
Integración de servicios.
Tolerancia a fallos

4. Situación actual
Nuevos retos de Seguridad IT
Contramedidas de seguridad
Business/Logical
Confidentiality Integrity Availability
Security Goals
Domain
Regulations/
Standards
Secure Protocol
+ Especialización
Technnical /
Standards + Experiencia
Network Layer Application Layer Transport Layer
Application/ Infrastructure
+ Heterogéneo
Domain
IPSec
S-HTTP HTTPS (SSL/TLS)
Configuration/
Code
require
OpenSSL Apache (mod_ssl) JSSE GnuTLS

5. Situación actual
OPBUS: Optimization Business Process Security
Especificación de los objetivos
del negocio relacionados con la
Seguridad IT de los BPs

6. Situación actual
OPBUS: Gestión Automática de Seguridad & BPM
Id. Activos
Monitorizar
riesgos
Ciclo
Id. Amenazas
Gestión Riesgos
Seleccionar
contramedidas
Evluar
riesgos
Modelos
Modelo
Proceso
Analista
Negocios Evaluación Tratamiento Monitorización
Negocio
riesgos riesgos riesgos
Modelo
Transformación
Riesgos automática
Analista Extensión de modelos
Seguridad deprocesos de negocios
Diseño de Procesos Configuración del sistema

7. Situación actual
OPBUS: Análisis automático de riesgos en BPs
Análisis de riesgos Constraint
Satisfaction
Programme (CSP)
TRANSFORMACIÓN
AUTOMÁTICA
F1: {LOGIN USER,
REQUEST DATA,
Objectives:
POST ENTRY} Data Integrity and Data CSP (Cliente)
Confidentiality
Cliente
Loggin RequestD Post
CSP (F1)
User ata Entry
Start End Vulnerabilities:
Risk: Cross-site scripting Risks: Cross-site scripting V1:Cross-site scripting;
(XSS) and Improper (XSS) and Improper Input V2: Improper Input
Input Validation Validation
Validation
Resolutor
CSP
NO CONFORMIDADES

8. Situación actual
OPBUS: Diagnosis de No Conformidad (NC)
Estrategia
Resolutor CSP
búsqueda
COMET
Resolutor
Modelo COMET
Choco
Modelo
Resolutor
Proceso de Diagnosis
Negocio Modelo Choco actividades No
CPLEX Coformes
Resolutor
Modelo de
riesgos Modelo CPLEX
... ...
Método Riesgos
Resolutor
Generico
CSP
CSP Genérico

9. Situación actual
OPBUS: Herramienta diagnosis automático de NC
Diagnosis
Validación de
modelos
SETUP
Transformación
Transformación Modelos de
directa
Constraints

10. Situación actual
OPBUS: Tratamiento automático de riesgos
Configuraciones
Tratamiento de riesgos SELECCIÓN
seguridad
ÓPTIMA
Catálogo de Contramedida de Seguridad (SC1)
contramedidas
Contramedida de Seguridad (SC2)
Analizador
características
Patrón
Contramedida de Seguridad (SC3)
Patrón Seguridad 3
Seguridad 1 Patrón Contramedida de Seguridad (SC4)
Problem
Seguridad 5
Patrón Context
Problem
Seguridad 2 Force Patrón
Context
Force
Seguridad 4 Problem
Context
Problem Force
Solution Problem
Force Context
Force
Cliente
Modelo
características Loggin Post
Modelo RequestData
Modelo User Entry
características Modelo Start End
características características

11. Situación actual
OPBUS: Patrones de seguridad
Christopher Alexander in 1977: “A
pattern describes a problem which
occurs over and over again our
environment, and then describes the
core of the solution to that pattern“
+ Extensible
+ Adaptable
- Formalización

12. Situación actual
OPBUS: Modelos de características
X=Y+Z
C1
Y = value3
C2 C3 Y = value2 Y = [r21,r22]
Z = value1 Z = [r11,r21]
require
C4 C5 C6 C7 C8
Modelos formales
CP
Lógica descriptiva (LD)
Lógica proposicional (LP)
+ Lógica entera
Programación con restricciones (CP) + Optimización
+ Algoritmos de
búsqueda
Operación sobre el FM

13. Situación actual
OPBUS: Patrones vs Modelos de características
Security Pattern Model Feature models Constraint Models
CSP1
Name
Context COP1
...
Problem
COP2
Forces
operation
Solution MCOP2
described_by
Nombre
Modelo de características para
configuración de SSL/TLS en Apache
Problema
Apache (SSL/TLS)
Contexto
Soluciones Algorithm CipherSuite ClientAuth Port KeyStore Trust Protocol
SecurityLevel = {High}
SecurityLevel = {High}
Obligaciones true want false Type Pass File File Pass Type SSLv2.0 TLSv1.X SSLv3
SecurityLevel = {Medium}
JKS PKCS12 PKCS11 JKS PKCS12 PKCS11
exclude
require
 CSP  Todas las configuraciones posibles [OP: solveAll]
 CSP  Comprobación de configuración válida [OP: sat]
 COP  Configuración específica un objetivo [OP: max/min]
 MCOP  Configuración específica multiples objetivos [OP: max/min]
….

14. Situación actual
Caso de estudio
Modelos de control de
acceso para BPMS

15. Situación actual
Modelos de control de acceso para BPMS
RBAC **
Core
Hirerchy SoD Privacy Temporal
Subject User Rol Permission
General Limited Advanced
Object Operation Object- History-
SSD Operational DSD
based based
Modelo clásico Role-Based Access Control (RBAC)
Ventajas con respecto a BPM:
+ Permisos asignados a roles/grupo (usuario adquiere rol)
+ Sistema pasivo de control de acceso (los permisos a los recursos y estos son accedidos desde el rol)
+ Permite diferentes jerarquías de roles (rol hereda permisos)
+ Separación de deberes de diferentes tipos (dinámico/estático, temporal, …)
Limitaciones con respecto a BPM:
─ BPMN define “roles” y “subroles” en los modelos  Ejecución de tareas individuales  PROBLEMA:
¿A quién se asignará mi tarea?  Necesidad de gestión sesiones-rol-tarea-permisos  TRBAC
─ Sistema activo de control de acceso  Activación de tareas activa permisos dinámicamente hacia
los roles  PROBLEMA: ¿Cómo controlo quién va a ejecutar la tarea?  TRBAC
─ SoD  PROBLEMA: No implementada por defecto en BPMS  TRBAC
** “A Verifiable Modeling Approach to Configurable Role-Based Access Control”, Dae-Kyoo Kim, Lunjin Lu, and Sangsig Kim
“Role-Based Access Control”, David F. Ferraiolo, D. Richard Kuhn, Ramaswamy Chandramouli

16. Situación actual
Modelos de control de acceso para BPMS
SessionID: Integer
Active: Boolean
ActiveUser: User
NumberUserAuthorized: Integer
NumberOfActivations: Integer
Modelo avanzado
Session SessionID: Integer
UserId: Integer
Task Role-Based Access Control (TRBAC)
ActiveRol: Rol
require
Card_U: Integer
User
require
Card_A: Integer
Card_U < NumberUserAuthorized
Ventajas con respecto a BPM:
Card_A < NumberOfActivations
[1..n]
URA Organization
+ Permisos = TAREAS
require
[1..n]
Business + Sistema activos y pasivo
Role Role
[2..m]
require
Postion
+ Permite jerarquías de roles (rol hereda
Role
Hierarchy TRA
require [2..n]
permisos)
require
require
Access
Rights + Separación de deberes de diferentes tipos
(dinámico/estático, temporal, …)
PTA
Permission
PTA
PermisionId:Integer
require Private AND/OR Expression
between Ti and Tj. For
Activation instance, Ti and Tj.
require Object Supervisio condition
Class n Effective execution time
of a Ti.
Time
[1..m] Workflow constraint
require
NumberOfInstance > N
TRBAC Task
Approval Cardinality
require require Active require
Access
require mode
AssignedTo: Rol Passive require require
WSId:Integer
Wiid:Integer
Activate: Boolean
Completed: Boolean Worflow Non-
[1..n]
Schema inhartable require
Hirerchy
require
WSId:integer Iinhartable require require require
[1..n]
Worflow
instance
WIId:integer
Ri,Rj:Rol
Ri>Rj. forall Ti de Rj 
Ri hereda {Ti | Ti clase Supervision o Ti clase
S-RH(s) Approval}
Supervisio
n
S-RH(a) Ri>Rj. forall Ti de Rj 
Ri hereda {Ti | Ti clase Supervision o Ti clase
Approval, y todos permisos de lectura de Rj}
Constraint Ti: Task
Tj: Task
Ti<>Tj y Ti.assignedto=Rol1 y Tj assinedto=Rol1  Ti
TS-SoD no mutually-exclusive Tj
Type Ti<>Tj y Ti.WIId=Tj.WIId y Ti.assignedto=Rol1 y
TD-SoD
SoD Ti.activate=true and Tj.activate=true  Ti no mutually-
exclusive Tj FM basado en
“Task–role-based access control model”, Sehng Oh, Seog Park
ID-SoD Ti <> Tj y Ti.assignedto=Rol1 y Ti.activate=true and
Tj.activate=true  Ti no mutually-exclusive Tj

17. Situación actual
Conclusiones
 Dar respuesta a los nuevos retos en seguridad IT para BPMS
 Integración de gestión de riesgos en BPM
 Análisis de riesgos en BPs
 Selección óptima de contramedidas con Patrones de
seguridad – Modelos de características
 Construcción del Modelo de características para control de
acceso en BPMS

18. MSc. Ángel J. Varela Vaca
Universidad de Sevilla,
E.T.S. Ingeniería Informática,
Departamento de Lenguajes y Sistemas Informáticos,
E-mail: ajvarela@us.es
twitter: a_j_varela
Linkedin: angeljesusvarelavaca
Proyecto OPBUS: http://www.lsi.us.es/~quivir/index.php/OPbus/HomePage