OPBUS: A framework for improving the dependability of risk-aware business processes
•Download as PPT, PDF•
1 like•348 views
Slides for thesis defense.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to OPBUS: A framework for improving the dependability of risk-aware business processes
Similar to OPBUS: A framework for improving the dependability of risk-aware business processes (20)
Recently uploaded
Recently uploaded (20)
OPBUS: A framework for improving the dependability of risk-aware business processes
- 1. OPBUS: A Framework for Improving the Dependability of Risk-Aware Business Processes Ángel Jesús Varela Vaca Supervised by Dr. Rafael Martínez Gasca
- 2. Goal:Goal: qualityquality improvement of businessimprovement of business process managementprocess management Introduction 2
- 3. Outline 3
- 4. Outline 4
- 5. Motivation 5
- 6. Motivation 6
- 7. Motivation 7
- 8. Motivation 8
- 9. Motivation 9
- 10. BPM life-cycle 10 Business Procesos Modeling Validation, Simulation, Verification Process Mining Business Activity Monitoring Implementation Test & Deployment Operation, Monitoring, Maintenance Enactment Configuration Design & Analysis Evaluation
- 11. Design and Analysis 11 •Determine, analyze and evaluate risks Design & Analysis • Validation analysis • Verification analysis • Performance analysis • Diagnosis analysis Risk assessment [10-20] [10-20] [10-20] [10-20] [10-20] [15-30] [50-60] [15-30]
- 12. Configuration 12 •Selection and implementation of countermeasures. Configuration Risk treatment Select the best configuration to treat non- acceptable risks.
- 13. Enactment 13 Enactment •Ensure the delivering of correct business process services in presence of faults. Fault Tolerance
- 14. Outline 14
- 15. OPBUS: The framework 15 Enactment Configuration Design & Analysis Evaluation Feature Oriented Domain Analysis Feature Oriented Domain Analysis Model-based fault diagnosis Model-based fault diagnosis Model-based fault diagnosis Model-based fault diagnosis
- 16. Model-based Fault Diagnosis 16 SD M1: x = a*c M2: y = b*d M3: z = c*e A1: f = x+y A2: g = y+z OM a = 2 b = 2 c = 3 d = 3 e = 2 f = 10 g = 12 Conflicts {A1, M1, M2} {A1, A2, M1, M3} Diagnoses {A1} {M1} {M2, A2} {M2, M3}
- 17. Model-based Fault Diagnosis 17 17 DiagnosesDiagnoses ObservationsObservations Structural Relations Structural RelationsModelModel BM x = a*c y = b*d z = c*e f = x+y g = y+z Structural relations ARR1: f-a*c-b*d=0 ARR2: g-b*d-c*e=0 ARR3: f-g-c*(a-e)=0 A1 A2 M1 M2 M3 ARR1 1 0 1 1 0 ARR2 0 1 0 1 1 ARR3 1 1 1 0 1 Obs a = 2 b = 2 c = 3 d = 3 e = 2 f = 10 g = 12 Diagnoses {A1} {M1}
- 18. Feature-Oriented Domain Analysis 18 Example of SSL/TSL enforcement for strong encryptation # allow all ciphers for the initial handshake, # so export browsers can upgrade via SGC facility SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL <Directory /usr/local/apache2/htdocs> # but finally deny all browsers which haven't upgraded SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128 </Directory>
- 19. Constraint Programming 19 Model-based fault diagnosis Model-based fault diagnosis Feature Oriented Domain Analysis Feature Oriented Domain Analysis
- 20. Outline 21
- 21. 22 Context
- 22. Name Modelling Security Dimensions Cost Objectives Threats Vuln. Controls Automatic analysis Risk estimation Control flow Cope et al. 2010 BPMN √ √ √ Muehlem et al. 2005 EPC Partial Partial Partial √ √ Lambert et al. 2006 IDEF √ √ OPBUS * √ √ √ √ √ √ √ √ Churilov et al. 2006 EPC √ √ Rodriguez et al. 2006 UML √ √ Menzel et al. 2009 BPMN √ √ √ Jakoubi et al. 2009 Any √ √ Partial √ Partial Neubauer et al. 2005 Any √ Partial Partial √ Sackman et al. 2008 Any √ √ Partial Partial Partial Fenz et al. 2009 Petri-Nets √ Partial √ Neubauer et al. 2008 Any √ √ √ √ Partial √ Xue Bai et al. 2012 BPMN √ √ √ Partial √ √ 23 Related work
- 27. 28 Risk-aware Business Processes Business process model extended with risk information and properties.
- 28. 29 Risk-aware Business Processes AUTOMATIC RISK CONFORMANCE
- 29. 30 Risk estimation of BP models = f(Value , Frequency, Consequence) A1 Integrity: [1-5] Vulnerability: CWE-255: Credentials Management Name: CVE-2010-2370 Description: Oracle BPM allows remote attackers to affect integrity, related to BPM Frequency: [1-5] Consequence: [1-5] Vulnerabilities: CWE-255 How to calculate the risk of a BP model?
- 30. 31 Risk estimation of BP models S.-M. Huang et al., “Enhancing conflictS.-M. Huang et al., “Enhancing conflict detecting mechanism for Web Services ...”,detecting mechanism for Web Services ...”, Inform. Softw. Technol. (2007)Inform. Softw. Technol. (2007)
- 31. 32 Risk estimation of BP models A1 A2 A3 A4 A5 BP1 = A1 D1 D1 A2 MAX( A3 A4 A5 + + + , ) + ) / 5 ( Estimating risk of BP models
- 32. 37 Risk evaluation of BP models A1 A2 A3 A4 A5 D1 ✔
- 33. 38 Diagnosis of non-conformance of risk
- 34. 39 Determination of PEFs Determination of PEFs
- 35. 40 CSP Model Risk-Aware BP model CSP model Automatic Transformation
- 36. 41 CSP Model Automatic Transformation Risk-Aware BP model CSP model
- 37. 42 CSP Model Automatic Transformation Risk-Aware BP model CSP model
- 38. 43 CSP Model Risk-Aware BP model CSP model
- 39. 45 Identifying PEFs, Activities & Artifacts
- 40. 46 Automatic Diagnosis – MDA Model-driven Architecture approach Different risk evaluation strategies: •FMEA, MAGERIT, CRAMM, Customized, … Multiple platforms for Constraint Programming: •Choco, COMET, CPLex, … Different strategy of searches: •Exhaustive, local search, hybrid …
- 41. Implementation and Results 47 Tools development of eclipse plug-in: • Customizable BPMN editor • Integration Multi-CP solvers • Validation capabilities: structural faults. • Automatic and dynamic transformations and diagnosis of non-conformances
- 43. Outline 49
- 44. Context 50 A1 A2 A3 A4 A5 D1 Identify threats, vulnerabilities and elements of BPs to be treated What security controls must be configured together with business processes in order to correct non-conformance of risks Manual Time-consuming
- 45. Problem statements 51 How to formalize security countermeasures? How to select adequate security controls according to requirements/objectives/goals of organizations? Security patterns • Textual • Informal • Natural language Inference mechanisms • Feature-Oriented Domain Analysis (FODA) • Constraint Programming Techniques • Multi-objective strategy (cost-benefit, MTTR-development time, …) Extended & Formalized • Feature models
- 46. Modelling security patterns 52 Name Security GoalsSecurity Goals Security IntentionSecurity Intention Problem Context Solutions Forces Feature model: Domain of configurationsOperators: SELECT CHECK Integrity, Confidentiality, Availability, … Data integrity, Fault Tolerance, Enforce Authentication, … Vulnerability: CWE-523: Unprotected Transport of Credentials Operators: OPTIONAL MANDATORY
- 47. Security controls – Confidentiality & Integrity & Authentication 53 Nombre Description Security Goals: Confidentiality, Integrity, Authentication Security Intention: Enforcerment SSL/TLS Problem CWE-523: Unprotected Transport of Credentials CWE-523: Unprotected Transport of Credentials
- 48. Security controls – Confidentiality & Integrity & Authentication 54 Enforcement of SSL/TLS Standards SSL v2.0, TLS v1.0, TLS v1.1, SSL v3.0 Cipher Suite: high variability Nombre Description Security Goals: Confidentiality, Integrity, Authentication Security Intention: Enforcerment SSL/TLS Problem CWE-523: Unprotected Transport of Credentials
- 49. Security controls – Confidentiality & Integrity & Authentication 55 SSL/TLS enables: Confidentiality: encrypting data Integrity: message authentication code Authentication: digital signatures and/or certificate. Lot of cross-tree constraints !!! Metrics:
- 50. Security control – Availability & Integrity 56 CWE-390: Detection of Error Condition Without Action Name Description Security Goals: Availability, Integrity Security Intention: Fault Tolerance Problem CWE-390: Detection of Error Condition Without Action
- 51. Security control – Availability & Integrity 57 Fault tolerance: Error detection Recovery management Metrics:
- 52. Security control – Authorization 58 Name Description Security Goals: Authorization Security Intention: Enfocerment Authorization Problem CWE-89 - SQL injection CWE-79 - Cross-site Scripting • CWE-89 - SQL injection • CWE-79 - Cross-site Scripting
- 53. Security control – Authorization 59 Name Description Security Goals: Authorization Security Intention: Enfocerment Authorization Problem CWE-89 - SQL injection CWE-79 - Cross-site Scripting Enforcement of Authorization: Information filtering via Web Application Firewalls (WAFs) Configuration rule set: High variability SecRuleREQUEST_HEADERS:Host "^$" "phase:2,rev:'2.2.4',t:none,block,msg:'Empty Host Header',id:'960007',tag:'PROTOCOL_VIOLATION/MISSING_HEADER_HOST',severity:'5',setvar:'tx.m sg=%{rule.msg}',setvar:tx.anomaly_score=+% {tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+% {tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/MISSING_HEADER-% {matched_var_name}=%{matched_var}" SecRuleREQUEST_HEADERS:Host "^$" "phase:2,rev:'2.2.4',t:none,block,msg:'Empty Host Header',id:'960007',tag:'PROTOCOL_VIOLATION/MISSING_HEADER_HOST',severity:'5',setvar:'tx.m sg=%{rule.msg}',setvar:tx.anomaly_score=+% {tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+% {tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/MISSING_HEADER-% {matched_var_name}=%{matched_var}" Example of rule
- 54. CSP model 60 Formal models CP // Variables Boolean C1,C2,C3,C4,C5,C6,C7 Integer x,y,z; // Feature model C1 ↔ C2 C3 → C1 C2 ↔(C6 ∨ C7 ∨ C8) C5 → C6 // require // Extra functions C1 → x = y + z C4 → z = value1 C5 → z ≥ r11 z ≤ r12˄ C6 → y = value2 C7 → y = value3 C8 → y ≥ r21 y ≤ r22˄ // Operation Maximize(x) Transformation
- 55. Performance & Analysis Results 61 Feature Model (FM) Number of Features Mandatory Optional XOR Or Void feature model Legal configurations Time (ms) Fault Tolerance (FT) 17 8 1 7 0 × 7 9 SSL/TLS 49 10 0 42 5 × 3.683 4.699 WAF 62 6 6 57 4 × 241.920 77.427
- 56. Analysis & Performance results 62 Feature Model Optimization criteria Configurations Time (ms) SSL/TLS Single Objective: Minimize (ALE) 13.138 2.041 Single Objective: Maximize (AROR) 5.268 1.255 Single Objective: Minimize (Cost) 1.800 2.394 Multi-objective: Maximize (AROR) + Minimize (ALE) 5.268 5.257 Multi-objective: Minimize (Cost) + Minimize (ALE) 0 406 Multi-objective: ~Minimize (Cost) + Minimize (ALE) 108 880 Fault Tolerance Single Objective: Minimize (MTTR) 4 39 Single Objective: Maximize (Risk Reduction) 58 42 Multi-objective: Minimize (MTTR) + Maximize (Risk Reduction) 36 39 # Digital Signature Certificate CipherSuite Protocol Objective PSK SRP Anon. X.509 OpenPGP KeyChange Method CipherEnc MAC ALE Cost 1 √ RSA TLSv1.0 2.000 45 2 √ RSA MD5 TLSv1.0 2.000 45 3 √ RSA IDEA-128 SHA-1 TLSv1.1 2.000 50 4 √ Fortezza SHA-256 TLSv1.1 2.000 50 5 √ DHE_RSA 3DES 168 SHA-1 TLSv1.1 2.000 50
- 57. Outline 63
- 60. Fault Tolerance Layer (FTL) 66 Recovery mechanisms Dynamic Binding Replication and redundancy Software diversity Check-pointing Error detection Detect Discrepancies Fault Diagnosis
- 61. Error Detection & Fault Diagnosis 67 A1 A2 A3 A4 A5 FTL
- 62. FTL – Error Detection & Fault Diagnosis 68 A1 A2 A3 A4 A5 C1 ≡ A1 = x + y C2 ≡ A1 = d C3 ≡ A2 = d * z MAXIMIZE(C1,C2,…) A1, A2
- 63. Recovery – Dynamic binding 70 + Primary-backup FTL
- 68. FTL - Summary 75 Recovey DiagnosisDiagnosis Check-pointsCheck-points No. ReplicasNo. Replicas MiscMisc MTTRMTTR Dynamic BindingDynamic Binding 2/12/1 DB-RedundantDB-Redundant BinderBinder 2/12/1 CompensationCompensation handlershandlers N-VersioningN-Versioning NN AdjudicatorAdjudicator Check-pointingCheck-pointing 2/12/1 CompensationCompensation handlershandlers + = + +
- 69. Outline 76
- 70. Final Remarks 78 Risk-AwarenessRisk-Awareness DependabilityDependability Flexibility & AgilityFlexibility & Agility Efficiency &Efficiency & OptimizationOptimization Risk extensionRisk extension Risk analysisRisk analysis Risk treatmentRisk treatment IntegrityIntegrity ConfidentialityConfidentiality AvailabilityAvailability ReliabilityReliability AutomationAutomation AdaptableAdaptable Multi-platformMulti-platform Model-Based DiagnosisModel-Based Diagnosis Constraint ProgrammingConstraint Programming FODAFODA BPMBPM QualityQuality BPMBPM QualityQuality
- 71. Outline 79
- 72. Best Paper AwardBest Paper Award DEPEND’10 (Best Paper Award) DEPEND’10 (Best Paper Award) CISIS’10 (CORE B)CISIS’10 (CORE B) Publications and Research findings 80 DX’10DX’10 SECRYTP’11 (CORE B)SECRYTP’11 (CORE B) RCIS’11 (CORE B)RCIS’11 (CORE B) IJAS ‘11 Google Scholar IJAS ‘11 Google Scholar CISIS’12 (CORE B)CISIS’12 (CORE B) AEI’12AEI’12 IST ‘13 JCR (2012) 1.250 IST ‘13 JCR (2012) 1.250 JSS ‘13 JCR (2011) 0.836 JSS ‘13 JCR (2011) 0.836 JSS ‘11 JCR (2010) 1.293 JSS ‘11 JCR (2010) 1.293 ConferenceConference WorkshopWorkshop Journal in third reviewJournal in third review Journal PublishedJournal Published
- 73. Research stay and projects 81
- 75. THANK YOU FOR YOUR ATTENTIONTHANK YOU FOR YOUR ATTENTION Ángel J. Varela VacaÁngel J. Varela Vaca Universidad de Sevilla,Universidad de Sevilla, E.T.S. Ingeniería Informática,E.T.S. Ingeniería Informática, Departamento de Lenguajes y Sistemas Informáticos,Departamento de Lenguajes y Sistemas Informáticos, E-mailE-mail:: ajvarela@us.esajvarela@us.es LinkedinLinkedin: angeljesusvarelavaca: angeljesusvarelavaca ProyectoProyecto OPBUSOPBUS:: http://www.lsi.us.es/~quivir/index.php/OPbus/HomePagehttp://www.lsi.us.es/~quivir/index.php/OPbus/HomePage THANK YOU FOR YOUR ATTENTIONTHANK YOU FOR YOUR ATTENTION Ángel J. Varela VacaÁngel J. Varela Vaca Universidad de Sevilla,Universidad de Sevilla, E.T.S. Ingeniería Informática,E.T.S. Ingeniería Informática, Departamento de Lenguajes y Sistemas Informáticos,Departamento de Lenguajes y Sistemas Informáticos, E-mailE-mail:: ajvarela@us.esajvarela@us.es LinkedinLinkedin: angeljesusvarelavaca: angeljesusvarelavaca ProyectoProyecto OPBUSOPBUS:: http://www.lsi.us.es/~quivir/index.php/OPbus/HomePagehttp://www.lsi.us.es/~quivir/index.php/OPbus/HomePage
Editor's Notes
- Buenos dias, voy a comenzar la presentación de la tesis titulada “OPBUS: A framework for Improving the Dependability of Risk-Aware Business Processes” esta tesis ha sido supervisada por el Dr. Rafael Martínez Gasca.
- Early analysis and evaluation of risks pre-emptive error detection and fault handling El objetivo fundamental de esta tesis es proporcionar una mejora de la calidad gestión de procesos de negocio. Para conseguir esto proponemos dar una visión más completa de la seguridad dotando de mecanismos que nos permita ya desde etapas tempranas de diseño, analizar los riesgos de seguridad de los modelos, generar planes de tratamientos; además de utilizar mecanismos preventivos de tolerancia a fallos en tiempo de ejecución, para asegurar la correcta ejecución de los procesos aún en presencia de fallos Construcción de documentos Accesibles 18/02/2009
- Meter PDCA ciclo TQM relacionar con OPBUS ------------ Este es el esquema de la presentación que está compuesta por diferente etapas. En primer lugar motivaremos el trabajo realizado en esta tesis, dando un contexto y los diferentes problemas. Luego detallaremos nuestras propuestas dividida en 4 partes, como conclusión daremos unas consideraciones finales al trabajo realizado y presentaremos los resultados y el curriculum presentados en esta tesis.
- Comenzaremos con las motivaciones.
- Para las organizaciones es fundamental alcanzar sus objetivos, y para ello es fundamental que sus procesos sean lo más confiable posibles. Para ello es necesario que sean precisos, y menos sensible a fallos (click ratón) posible ya que un fallo impicaría una desviación de los objetivos de la organizacion (click ratón), incluso pérdidas económicas
- Motivar con un ejemplo real, de problema de seguridad, Motivar que los problemas de seguridad se pueden ir propaganado sobre el proceso. Debido a ese carácter de servicio externalizado que se integra y es utilizado por terceras partes, implica que los procesos estén amenazados y sujetos a posibles vulnerabilidad de seguridad que también poner en peligro la consecución de los objetivos (click ratón) Sin embargo por lo general estos aspectos quedan en un segundo plano dentro del marco de BPM. (click de ratón).
- Motivar con un ejemplo real, de problema de seguridad, Motivar que los problemas de seguridad se pueden ir propaganado sobre el proceso. Debido a ese carácter de servicio externalizado que se integra y es utilizado por terceras partes, implica que los procesos estén amenazados y sujetos a posibles vulnerabilidad de seguridad que también poner en peligro la consecución de los objetivos (click ratón) Sin embargo por lo general estos aspectos quedan en un segundo plano dentro del marco de BPM. (click de ratón).
- Hablar de ISO 27001 y 9001 como gestión de la seguridad y de la calidad. Debido a ese carácter de servicio externalizado que se integra y es utilizado por terceras partes, implica que los procesos estén amenazados y sujetos a posibles vulnerabilidad de seguridad que también poner en peligro la consecución de los objetivos (click ratón) Sin embargo por lo general estos aspectos quedan en un segundo plano dentro del marco de BPM. (click de ratón).
- Debido a ese carácter de servicio externalizado que se integra y es utilizado por terceras partes, implica que los procesos estén amenazados y sujetos a posibles vulnerabilidad de seguridad que también poner en peligro la consecución de los objetivos (click ratón) Sin embargo por lo general estos aspectos quedan en un segundo plano dentro del marco de BPM. (click de ratón).
- La definición y gestión de procesos de negocio se realiza de acuerdo con un proceso cíclico dividido en fases. Se inicia en la fase de diseño y análisis, donde se modelan los procesos de negocio, incluyendo la validación y verificación mediante la simulación de la ejecución de los procesos sólo diseñados. A continuación, son implementados en la fase de configuración mediante la configuración de un sistema de información consciente de los procesos, lo que implica la comprobación de la aplicación. En la fase de incorporación al derecho interno, los procesos de negocio se implementan utilizando el sistema configurado, y la ejecución de instancias de proceso se lleva a cabo. Por último, en la fase de evaluación, los procesos son monitoreados y analizados para evaluar y mejorar los modelos de procesos de negocio y sus implementaciones. En esta tesis nosotros nos centraremos en la fases de diseño y análisis, configuración y puesta en marca. (click ratón)
- Como hemos mostrado anteriormente las técnicas de análisis de procesos permite detectar defectos y fallos en diseños y ejecución, pero centrados en aspectos topológicos y semánticos del proceso. Nosotros proponemos usar técnicas de análisis de riesgos que unidas a técnicas de diagnosis nos permitan analizar y evaluar posibles riesgos que llevarían a una no conformidades de los procesos. Esto es, una desviación de los objetivos de riesgos establecidos. (click ratón).
- Una vez determinados estos riesgos, proponemos una serie de mecanismos automáticos para la generación de configuraciones (click ratón) que aseguren la mitigación de estos riesgos y que además se adecúen a las necesidades/objetivos del negocio. (click ratón).
- Ya en fase de operación y puesta en marcha, (click ratón) proponemos dotar de tolerancia a fallos durante la ejecución de los procesos, mecanismos que nos permitan identificar posisbles fallos, aislarlos usando diagnosis de fallos y lanzar un mecanismos de recuperación que permita asegurar la ejecución de estos procesos. (click ratón)
- A continuación vamos a describir nuestras contribuciones (click ratón)
- Hemos definido un framework (OPBUS) para ampliar y mejorar la calidad del desarrollo de procesos en BPM. Primeramente hemos introduciendo mecanismos para el análisis, evaluación y tratamiento de riesgos en etapas de diseño y configuración. (click ratón) Mientras que ya en etapas de despliegue y operación (click ratón), hemos dotado a de mecanismos de tolerancia a fallos que permiten detectar, aislar fallos en procesos y ejecutar acciones de recuperación. (click ratón)
- Como hemos indicado anteriormente nuestras propuestas se centran en la aplicación de técnicas de diagnosis. Nosotros usaremos la diagnosis basada en modelos, de la cual existen dos comunidades principalmente. (click ratón) La comunidad DX, que se basa en la realización del diagnóstico de las discrepancias entre el comportamiento observado (click ratón) y el modelo original del sistema a diagnosticar. (click ratón)
- Mientras que la comunidad FDI, define un modelo de relaciones estructurales off-line (click ratón) y usa este modelo como base para realizar la diagnosis del modelo (click ratón x2).
- Para la implementación y automatización de nuestras contribuciones hemos decidido usar Constraint Programming, ya que como veremos más adelante este tipo de modelos es ampliamente usado en diagnosis y además por su potencia, eficiencia y versatilidad debido a que posee múltiples tipos de búsqueda (exhaustiva,busqueda locales, tabu, etc.) , mecanismos de optimización (Funciones objetivo) y de razonamiento lo hacen idónea para nuestras contribuciones (click ratón)
- A parte de aspectos de análisis en procesos, es importante tratar de aspectos de en la ejecución de los procesos ya que pueden surgir amenazas y vulnerabilidades no consideradas en los análisis realizados y esto podría provocar una desviación de los objetivos del negocio. Tradicionalmente la taxonomía de la dependability nos proporciona los aspectos y mecanismos para tratar los fallos, errores y defectos producidos en los sistemas mediante una serie de mecanismos. Un mecanismo interesante es la tolerancia a fallos, que tiene como objetivo proporcionar una correcta ejecución de los servicios aún en presencia de fallos. Sin embargo, la tolerancia a fallos por lo general es tratada a nivel de sistemas físicos y muy escasamente tratada en aspectos de ingeniería de procesos como es la gestión de procesos. (click ratón)
- Ahora pasaremos a describir la primera contribución (click ratón).
- Las procesos de negocio son analizas teniendo en cuenta aspectos relacionados con su comportamiento. Aunque no se tiene en cuenta aspectos relacionados con los riesgos de seguridad de los procesos de negocio, estos objetivos deben tener un reflejo directo en los procesos y dotar de mecanismos que nos permitan sobre el modelo mismo identificar dónde se produciran las no conformidadas con respecto los objetivos (click ratón).
- En la literatura existes aproximaciones que intenta dotar a los procesos de extensiones para documentar los análisis de riesgos, sin embargo existe una ausencia generalizada de herramientas que nos permita realizar una evaluación automático de riesgos de seguridad sobre los procesos.
- Los principales problemas a los que nos enfrentamos son: 1º Como dotamos a los proceso de consciencia de los riesgos, dotaremos de una extensión de los modelos que completaremos con herramientas para la evaluación automática de estos modelos. 2º Como realizamos una evaluación de riesgos de estos modelos, nuestra propuesta debe tener en cuenta los diferente métodos de estimación existentes y también tener en cuenta los aspectos topológicos del proceso. (click ratón)
- Primeramente propondremos una extensión del modelo de procesos basado en BMM y profiles de UML para calida de servicio y tolerancia fa llos. (click ratón)
- BMM define un modelo o esquema que relaciona que los objetivos del negocio con su realización mediante BPs (click raton), pero además incluye evaluaciones como factores de impactos (esto es riesgos), que pueden afectar a la consecución de los procesos. (click ratón)
- El perfil de UML nos permite: (click ratón) Estimar el valor de los activos Identificar los diferentes vulnerabilidades asociadas y escenarios de amenazas Posibles tratamientos ya implantados (click ratón) Mediante un proceso de estimación podemos asociar un riesgo a estos activos, además de establecer los criterios de riesgos para dicho modelo. Como podremos realizar con esta extensión una estimación de riesgos para un proceo de negocio. (click ratón) ---- Aquí meter resultado gráfico
- Indicar que todo lo que se ha añadido al modelo nos servirá para automatizar el proceso de conformidad.
- El proceso de estimación de riesgos se basa en una formula de riesgo. (click ratón) Existen múltiples maneras de estimar estos riesgos. Por ejemplo FMEA es una metodología permite obtener el riesgo teniendo en cuenta sólo características de severidad ocurrencia y detección de una amenaza, pero no tiene en cuenta los aspectos relacionados con el activo. (click ratón) Sin embargo existen otro tipos de metodologías como las CRAMM,OCTAVE y MAGERIT que proponen otros métodos. Nosotros hemos propuesta una formula típica basada en el activo y las amenazas relacionadas con la vulnerabilidades asociadas a ese activo. Además es posible tener en cuenta posibles contramedidas introducidas a la hora de calcular este riesgo. (click ratón) ---- CUIDADO CON LAS PREGUNTAS QUE NOS PUEDEN VENIR AQUI, QUE CONOCEN YA AHP Y ANP, NO SE TIENEN EN CUENTA LAS DEPENDENCIAS?? NUESTRA RESPUESTA ES QUE ESO LO HABRÁ TENIDO QUE TENER EN CUENTA EL ANALISTA DE SEGURIDAD CUANDO HA VISTO EL PROCESO DE NEGOCIO Y LE HA PUESTO A CADA ACTIVIDAD SU RIESGO. FIN DEL MENSAJE.
- He propuesto una serie de patrones para la estimación del riesgo de un proceso, estos patrones se pueden combinar para determinar la estimación del riesgo de un proceso de negocio. (click ratón).
- Ese es el proceso para generar el riesgos individual de lo q puede ser un activo, (click ratón) pero un proceso de negocio tiene un orden de ejecución y no todas las tareas proporcionan el mismo valor de riesgo, es por tanto que deberemos tener en cuenta el control flow a la hora de realizar la estimación de riesgos (click ratón) --- Pones una formula que tendría que ser PUESTA POR HUMANO DE FORMA FACIL VIENDO EL PROCESO DE NEGOCIO, PERO ESTAMOS EN LA FASE AUTOMÁTICA, NO HAY HUMANOS. LA CUESTIÓN AHORA ES CÓMO OBTENEMOS ESTA FORMULA, PUES CON LOS PEF, POR ELLO AQUI DEBERÍAMOS HABLAR DE ELLOS PARA OBTENER EL RIESGO DEL PROCESO DE NEGOCIO Y ahora PARA CADA PEF DEL PROCESO DE NEGOCIO CONCRETO Y PARA LA DIMENSION CONCRETA VEMOS QUE TENGA UN NIVEL DE RIESGO PARA ESA DIMENSION INFERIOR PARA CUALQUIER PEF
- He propuesto una serie de patrones para la estimación del riesgo de un proceso, estos patrones se pueden combinar para determinar la estimación del riesgo de un proceso de negocio. (click ratón).
- He propuesto una serie de patrones para la estimación del riesgo de un proceso, estos patrones se pueden combinar para determinar la estimación del riesgo de un proceso de negocio. (click ratón).
- He propuesto una serie de patrones para la estimación del riesgo de un proceso, estos patrones se pueden combinar para determinar la estimación del riesgo de un proceso de negocio. (click ratón).
- He propuesto una serie de patrones para la estimación del riesgo de un proceso, estos patrones se pueden combinar para determinar la estimación del riesgo de un proceso de negocio. (click ratón).
- El objetivo del calculo del riesgo del procesos es para determinar si cumplen con los objetivos de riesgos establecidos (click ratón) esto nos permitirá determinar si el proceso posee no conformidades. Sin embargo ahora el problema es (click ratón) ¿qué elementos del modelo son los que producen esta no conformidad? Para esta tarea hemos definido un proceso de diagnosis para la identificación de manera más fina, es decir, qué elemento del camino y que tareas de ese camino, se encuentra las no conformidades del modelo.
- El proceso de diagnosis es el siguiente: - en primer lugar se identifica los caminos que tiene no conformidades - en segundo lugar, de entre las actividades y artefactos en este camino se determina quien es no conforme a los objetivos. Este proceso se ha automatizado mediante el uso de técnicas de programación con restricciones. (click ratón)
- He propuesto una serie de patrones para la estimación del riesgo de un proceso, estos patrones se pueden combinar para determinar la estimación del riesgo de un proceso de negocio. (click ratón).
- Dominios propiedades ---- La transformación toma la información del modelo de proceso de negocio extendido (click ratón) junto con los objetivos, el tipo de estrategia para calcular el riesgo, para definir el modelo de restricciones (click ratón)
- Dominios propiedades ---- La transformación toma la información del modelo de proceso de negocio extendido (click ratón) junto con los objetivos, el tipo de estrategia para calcular el riesgo, para definir el modelo de restricciones (click ratón)
- Dominios propiedades ---- La transformación toma la información del modelo de proceso de negocio extendido (click ratón) junto con los objetivos, el tipo de estrategia para calcular el riesgo, para definir el modelo de restricciones (click ratón)
- Dominios propiedades ---- La transformación toma la información del modelo de proceso de negocio extendido (click ratón) junto con los objetivos, el tipo de estrategia para calcular el riesgo, para definir el modelo de restricciones (click ratón)
- Aquí podemos observar un fragmento de transformación donde se generan las variables, dominios y restricciones para un modelo en COMET. (click ratón)
- Una vez obtenido el modelo de CSP este es ejecutado determinando las diferente soluciones parca
- Hemos definido una aproximación MDA que nos permite flexibilizar nuestra propuesta a través de transformaciones que nos permitan elegir: (click ratón) Qué plataforma de restricciones utilizar. Qué estrategia de búsqueda aplica. Qué estrategia de estimación de riesgos utilizar. Estas transformaciones nos permite generar un modelo de restricciones más adaptable y flexible. (Click raton)
- Como resultado principal de esta contribución se ha desarrollado una herramienta que permite generar de manera gráfica el modelo de procesos de negocio extendido, transformarlo a modelo de restricciones y ejecutar el proceso de diagnosis. (click ratón)
- Esta herramienta muestra los resultados de la diagnosis de manera gráfica además de proporcionar los valores resultado de la ejecución del modelo de restricciones. (click ratón) Esta herramienta se ha utilizado como soporte en la certificación ISO 27001 para el analisis de riesgos de estos procesos. (click ratón)
- A continuación vamos a describir la segunda contribución, que persigue la generación de contramedidas para mitigar los riesgos en procesos de negocio (click ratón).
- Una vez identificados los riesgos, amenazas y vulnerabilidades (click ratón) a tratar, qué contramedidas deben ser configuradas para corregir estas no conformidades localizadas anteriormente. (click ratón) ---- Muñequito catalogo de contramedidas Herramienta para eliminar este muñequito
- Los problemas que encontramos fueron: 1º Como representamos los controles/contramedidas para procesos de negocio(click ratón) Para lo cual decidimos definir un modelo basado en patrones de seguridad, pero estos patrones por lo general son muy informales y se representan en lenguaje natural. Nosotros decidimos realizar una formalización mediante un modelo extendido con una formalización basado en modelos de características. 2º Como seleccionamos los controles, qué mecanismos de razonamiento o inferencia utilizamos en base a estos patrones Para esto lo primero necesitamos definir un conjunto de controles para ser utilizados en procesos de negocio, para posteriormente aplicar mecanismos de inferencia basado en constraint programming y análisis de modelos de características que nos permitan seleccionar los controles que más se adecuen a las necesidades del negocio.
- El modelo propuesto consiste en un patrón de seguridad que contiene: - definición de los objetivos de seguridad sobre los atributos de seguridad sobre los que el patrón actuará - definimos las intenciones de seguridad que son aspectos relacionados con los objetivos de seguridad a tratar. - Problema vendrá definido por descriptores de vulnerabilidades a tratar por el patrón, en nuestro caso vamos a utilizar descritores ya conocido y extraidos de un diccionario de vulnerabilidad muy extendido como es de la Common Weakness Enumeration. - Contexto describe el entorno y sus propiedades, nosotros hemos propuesto formalizado usando modelos de características, como hemos visto en la introducción estos modelos pueden representarse mediante modelos formales basado en programación con restricciones. - Solución: describe qué se quiere obtener con la aplicación del patrón, nuestro caso hemos definido dos operadores de SELECT para seleccionar una configuración concreta, y CHECK para comprobar o terminar de definir una configuración específica. Forces: indica requisitos de obligatoriedad y opcionalidad sobre las características definidas en el patrón. Una vez definido como será nuestro modelo de contramedida, hemos definido un catalogo de contramedidas para procesos de negocio para mitigar ciertos objetivos de seguridad. (click ratón)
- Otro aspecto a tratar es la confidencialidad y la integridad de datos, por lo general estos aspectos de confidencialidad e integridad no son configurados o tratados en los BPMS por defecto, sin embargo estos aspectos se pueden tratar con la configuración de protocolos seguros de comunicación. Estos protocolos pueden mitigar vulnerabilidades a nivel de transporte de aspectos de confidencialidad, integridad y autenticación. Para esto lo más normal es configurar protocolos como SSL/TLS que nos permiten definir credenciales suites de cifrado a utilizar por el protocolo. Para esto se ha definido un modelo para la configuración de la suite de cifrados para diferentes versiones de estandares SSL y TLS. Al igual que para el anterior patrón se han definido una serie de métricas que atribuidas sobre el modelo nos permitirán seleccionar una configuración en función del COST o el retorno de la inversión obtenida.
- Otro aspecto a tratar es la confidencialidad y la integridad de datos, por lo general estos aspectos de confidencialidad e integridad no son configurados o tratados en los BPMS por defecto, sin embargo estos aspectos se pueden tratar con la configuración de protocolos seguros de comunicación. Estos protocolos pueden mitigar vulnerabilidades a nivel de transporte de aspectos de confidencialidad, integridad y autenticación. Para esto lo más normal es configurar protocolos como SSL/TLS que nos permiten definir credenciales suites de cifrado a utilizar por el protocolo. Para esto se ha definido un modelo para la configuración de la suite de cifrados para diferentes versiones de estandares SSL y TLS. Al igual que para el anterior patrón se han definido una serie de métricas que atribuidas sobre el modelo nos permitirán seleccionar una configuración en función del COST o el retorno de la inversión obtenida.
- Otro aspecto a tratar es la confidencialidad y la integridad de datos, por lo general estos aspectos de confidencialidad e integridad no son configurados o tratados en los BPMS por defecto, sin embargo estos aspectos se pueden tratar con la configuración de protocolos seguros de comunicación. Estos protocolos pueden mitigar vulnerabilidades a nivel de transporte de aspectos de confidencialidad, integridad y autenticación. Para esto lo más normal es configurar protocolos como SSL/TLS que nos permiten definir credenciales suites de cifrado a utilizar por el protocolo. Para esto se ha definido un modelo para la configuración de la suite de cifrados para diferentes versiones de estandares SSL y TLS. Al igual que para el anterior patrón se han definido una serie de métricas que atribuidas sobre el modelo nos permitirán seleccionar una configuración en función del COST o el retorno de la inversión obtenida.
- Una vulnerabilidad típica puede ser la detección de una condición sobre la que no se ha realizado ninguna acción, en la definición de esta vulnerabilidad se definen una serie de soluciones entre las que se encuentra la aplicación de técnicas de tolerancia a fallos. La toleracia a fallos nos permite actuar sobre aspectos de seguridad relacionados con la disponibilidad y la integridad de los datos. Para esto hemos definido un modelo de características que nos permiten configurar la infraestructura necesaria de tolerancia para procesos de negocio. Estos modelos además se han atribuido con una serie de métricas como son el tiempo tiempo de recuperación o (MTTR) o el risk reduction que puede producirse el usar una característica u otra. Esta atribución con métricas nos puede ayudar a seleccionar una configuración u otra. Por ejemplo podemos querer seleccionar una configuración de tolerancia a fallos que nos permita mitigar cierto cantidad de riesgos o que contenga al menos un MTTR determinado. (Click ratón).
- Una vulnerabilidad típica puede ser la detección de una condición sobre la que no se ha realizado ninguna acción, en la definición de esta vulnerabilidad se definen una serie de soluciones entre las que se encuentra la aplicación de técnicas de tolerancia a fallos. La toleracia a fallos nos permite actuar sobre aspectos de seguridad relacionados con la disponibilidad y la integridad de los datos. Para esto hemos definido un modelo de características que nos permiten configurar la infraestructura necesaria de tolerancia para procesos de negocio. Estos modelos además se han atribuido con una serie de métricas como son el tiempo tiempo de recuperación o (MTTR) o el risk reduction que puede producirse el usar una característica u otra. Esta atribución con métricas nos puede ayudar a seleccionar una configuración u otra. Por ejemplo podemos querer seleccionar una configuración de tolerancia a fallos que nos permita mitigar cierto cantidad de riesgos o que contenga al menos un MTTR determinado. (Click ratón).
- La autorización son mecanismos utilizados dentro de los procesos a través de la definición de roles y permisos, sin embargos hay mecanismos que pueden mejorar estos mecanismos de autorización evitando vulnerabilidades como los SQL injection o cross site scripting. La configuración adecuada de un firewall a nivel de aplicación a través de la definición de reglas de controlo, puede llevar a una mejora considerable de los mecanismos de autorización evitando código malicioso. Para esto hemos definido un modelado de características para la configuración de reglas para firewalls de aplicación más utilizado hoy día como puede ser Modsecurity o IronBee. A continuación una vez formalizado los diferentes controles de seguridad que podremos aplicar y las métricas sobre los mismo, pasamos a definir un análisis para determinar las mejores configuraciones (click rátón).
- La autorización son mecanismos utilizados dentro de los procesos a través de la definición de roles y permisos, sin embargos hay mecanismos que pueden mejorar estos mecanismos de autorización evitando vulnerabilidades como los SQL injection o cross site scripting. La configuración adecuada de un firewall a nivel de aplicación a través de la definición de reglas de controlo, puede llevar a una mejora considerable de los mecanismos de autorización evitando código malicioso. Para esto hemos definido un modelado de características para la configuración de reglas para firewalls de aplicación más utilizado hoy día como puede ser Modsecurity o IronBee. A continuación una vez formalizado los diferentes controles de seguridad que podremos aplicar y las métricas sobre los mismo, pasamos a definir un análisis para determinar las mejores configuraciones (click rátón).
- Se ha definido un proceso de análisis para determinar configuraciones: 1º Por un lado podemos obtener todas las configuraciones posibles (sin tener en cuenta métricas de selección), como las que se observan en el tabla adjunta podemos observar el número de configuraciones totales obtenidas para cada modelo. También tenemos que destacar el rendimiento del CSP obteniendo escaso tiempo de ejecución para cada modelo. 2º Vamos a obtener configuraciones determinadas centrandonos en un objetivo, multiples objetivos. Para este caso si tendremos en cuenta las métricas introducidas.
- Se ha definido un proceso de análisis para determinar configuraciones: 1º Por un lado podemos obtener todas las configuraciones posibles (sin tener en cuenta métricas de selección), como las que se observan en el tabla adjunta podemos observar el número de configuraciones totales obtenidas para cada modelo. También tenemos que destacar el rendimiento del CSP obteniendo escaso tiempo de ejecución para cada modelo. 2º Vamos a obtener configuraciones determinadas centrandonos en un objetivo, multiples objetivos. Para este caso si tendremos en cuenta las métricas introducidas.
- En la primera tabla podemos observar diferentes búsqueda con uno o varios objetivos y el número de configuraciones resultantes obtenidas para estos modelos. Queremos destacar que el objetivo siempre se ha centrado en las métricas introducidas en el modelo y puede darse el caso de no conseguir obtener una configuración debido a que los objetivos restringen demasiado el problema por lo que debemos relajar uno de los objetivos para intentar determinar alguna configuración válida. En la segunda tabla observamos un conjunto de configuraciones obtenidas para SSL/TLS para la búsqueda de minimización de coste y minimización de ALE, las dos primeras configuraciones son las optimas y las otras son algunas de las más próximas al objetivo.
- A continuación pasamos a explicar la tercera contribución, cuyo objetivo es definir la infraestructura de tolerancia a fallos para procesos de negocio.
- Partimos de unos procesos que han sido analizas y las contramedidas han sido definidas en un paso previo, por lo que estos procesos ahora deben ponerse operativos. (click ratón) Sin embargo, podemos encontrarnos con amenazas y vulnerabilidades inesperadas que cambian el comportamiento del proceso o los resultados del mismo. Por lo que proponemos dotar a estos procesos en marcha de mecanismos de tolerancia a fallos. (click ratón)
- Los procesos por lo general interaccionan con el exterior a través un bus de servicios que nos permite la interoperabilidad con terceras partes, servios, etc. Tendremos que definir una infraestructura de tolerancia a fallos que nos permita asegurar antes que los procesos conecten con otros servicios o usuarios, la correcta ejecución de los procesos.
- Para esto hemos definido una capa de tolerancia a fallos (FTL). (click ratón) Para implementar la tolerancia a fallos necesitaremos al menos dos componentes básicos: un detector de errores y mecanismos de recuperación. El detector de errores nos indicará si ha habido cambios de comportamiento o resultados inexperados, y además vamos a introducir un diagnosticador que nos permita identificar en que parte exacta del proceso se está fallando. Como mecanismos de recuperación, usaremos: Técnicas de replicación y redundancia de servicios en conjunto con técnicas de enlazado dinámico de servicios. Ténicas de diversidad de software basadas en Nversionado. Técnicas de check pointing Vamos a describir cada una de los componentes, en primer lugar explicaremos como se ha desarrollado la detección de errores y la diagnosis del fallo. (click ratón)
- La detección del error se produce cuando los resultados del proceso son comparados con un oraculo (click ratón), entonces se determina que existe una discrepancia y un comportamiento inexperado, (click ratón) con lo que se pasa al aislamiento del fallo (click ratón)
- Las observaciones entradas y salidas del modelo, y el comportamiento de los servicios son modelados en un CSP (click ratón) cuyo objetivo es determinar que componente está fallando (click ratón) Una vez determinado los componentes que están fallando debemos desplegar los mecanismos de recuperación (click ratón) Posible pregunta ¿ Como se obtiene el modelo CSP ?
- (click ratón) Este primer mecanismos de recuperación está basado en replicación y redundancia de servicio (click ratón) , esto es se usa un servicio como primario y en caso de que está fallando, mediante un enlazado dinámico en tiempo de ejecución se cambiará la invocación de este servicio por otro de respaldo. Las ventajas de este sistema es que sólo se usa un respaldo y bajo demanda, mientras que la lógica introducida por el enlazado dinámico y con un número alto de fallos puede introducir mucho overhead en la ejecución de los procesos. (click ratón)
- (click ratón) Este primer mecanismos de recuperación está basado en replicación y redundancia de servicio (click ratón) , esto es se usa un servicio como primario y en caso de que está fallando, mediante un enlazado dinámico en tiempo de ejecución se cambiará la invocación de este servicio por otro de respaldo. Las ventajas de este sistema es que sólo se usa un respaldo y bajo demanda, mientras que la lógica introducida por el enlazado dinámico y con un número alto de fallos puede introducir mucho overhead en la ejecución de los procesos. (click ratón)
- Esta solución está basado en técnicas de diversidad, donde cada llamada a servicio, es un cmponente Nversionado, compuesto por la invocación a tres variantes que tienen la misma funcionalidad pero que están implementados de diferente maneras. Mediante un mecanismos de adjudicación se hace obtiene el resultado. Las ventajas de esta solución que si tenemos un numero determinado de variantes la diagnosis no es necesario. Mientras que si el numero de variantes es muy elevado la lógica del adjudicador puede complicarse, además de tener que implementar muchas variantes de un mismo servicio. (click ratón)
- La aproximación check pointing usa dos componentes básicos: Puntos de controlo, que para nuestro caso serán sensores de integridad que guardarán los resultados intermedios del modelo, y mediante mecanismos de compensación y lanzamiento de errores soportados por los procesos, realizaremos un roll back, para reejecutar ciertas partes que según los sensores se detectaron resultados erroreneos. Las principal ventaja que la distribución de sensores mejora la diagnosis del fallo, porque obtenemos un grano más fino, pero como y donde localizar los sensores en sistemas tan distribudios es una tarea que puede ser demasiado compleja. Por otro lado el lack introducido por los compensation puede ser considerable. (click ratón)
- Se han realizado un análisis de rendimiento de las diferente propuestas con y sin mecanismos de recuperación, con uno y varios hilo de ejecución y variaciones de cientos y miles de invocaciones a los procesos por cada hilo. En la gráfica podemos se puede observar el MTTR (overhead de recuperación) para cada solución con respecto a la solución sin FT. En el caso de pocas invocaciones el overhead es casi despreciable sin embargo a medida que se incrementa el número de invocaciones este overhead dependiendo de la solución se incrementa considerablemente. (click ratón)
- En esta gráfica obtenemos los resultados marcando la diferencia entre el overhead de un hilo y varios hilos. Donde se puede decir que más número de hilos incrementa el overhead pero el diferencial con respecto a la solución con un hilo de ejecución nos permite indicar que su comportamiento se estabiliza.
- (click ratón) Este primer mecanismos de recuperación está basado en replicación y redundancia de servicio (click ratón) , esto es se usa un servicio como primario y en caso de que está fallando, mediante un enlazado dinámico en tiempo de ejecución se cambiará la invocación de este servicio por otro de respaldo. Las ventajas de este sistema es que sólo se usa un respaldo y bajo demanda, mientras que la lógica introducida por el enlazado dinámico y con un número alto de fallos puede introducir mucho overhead en la ejecución de los procesos. (click ratón)
- A continuación pasaremos a dar las consideraciones finales de esta presentación. (click ratón)
- Se ha propuesto un marco para la mejora de calidad de los procesos a través de la mejora de la confiabilidad. Intentamos siempre dotar de herramientas automáticas que doten de conciencia de seguridad a los procesos y que ayuden a la toma de decisiones con respecto a los riesgos de seguridad. Herramientas que nos permiten identificar no conformidades con respecto a los objetivos del negocio. Herramientas que permiten obtener configuraciones acordes a las objetivos del negocio Herramientas que nos permiten asegurar las ejecución Hemos innovado utilizando diagnosis basada en modelos y en el análisis de características que nunca se han utilizado para tareas de seguridad en procesos de negocio. Además se ha intentado automatizar cada una de las propuestas a través del paradigma de la programación con restricciones.
- Se ha propuesto un marco para la mejora de calidad de los procesos a través de la mejora de la confiabilidad. Intentamos siempre dotar de herramientas automáticas que doten de conciencia de seguridad a los procesos y que ayuden a la toma de decisiones con respecto a los riesgos de seguridad. Herramientas que nos permiten identificar no conformidades con respecto a los objetivos del negocio. Herramientas que permiten obtener configuraciones acordes a las objetivos del negocio Herramientas que nos permiten asegurar las ejecución Hemos innovado utilizando diagnosis basada en modelos y en el análisis de características que nunca se han utilizado para tareas de seguridad en procesos de negocio. Además se ha intentado automatizar cada una de las propuestas a través del paradigma de la programación con restricciones.
- A continuación vamos a mostrar las publicaciones resultantes y el curriculum del doctorando (click ratón)
- En las diferente contribuciones de esta tesis han sido respaldadas mediante contribuciones internacionales y nacionales: Para la primera contribución se ha publicado dos comunicaciones a congresos internacionales indexados categoria B en CORE y una publicación en el Workshop de diagnosis más importante en el area DX. Además se ha realizado una publicación JCR en la revista Journal System an Sotware Para la segunda contribución se ha publicado una comunicacion a congreso internacionales indexados categoria B en CORE y una publicación en el Workshop nacional. Además se ha realizado una publicación JCR en la revista Information System Technologies Para la tercera contribución se han realizado publicaciones en congresos internaciones uno categori B en CORe y otro recibiendo el premio a mejor articulo en el congreso. Además se ha realizado una publicación en la revista International Journal on Advances in Security. Como resumen del curriculum se han publicado o colaborado en la publicación de: 5 revistas 3 indexadas JCR, 2 indexadas accesibles en Google Scholar 16 congresos, 8 categoría B, 1 Core C y 1 publicación recibiendo el mejor articulo.
- Para el desarrollo de esta tesis se ha realizado una estancia de investigación el prestigioso HPI, bajo la supervisión de C. Meniel y se ha participado en tres proyectos a nivel nacional (click ratón)
- Además queremos resaltar que se ha conseguido: Una beca predoctoral de excelencia de 4 años Los resultados de investigación se han utilizado para la certificación y renovación de la certificación de la ISO/IEC 27001 en proyectos de investigación a través de fidetia. Además se está trabajando en un futuro para la psible aplicación de estos resultados en futuros productos mediante transferencia con la empresa Intelliment Security Queremos también destacar que nuestra investigación está teniendo continuidad como resultado de la investigación de otros investigadores con los cual colaboramos activamente. (click ratón)
- Muchas gracias ….