1. 1 Security and Dependability Organizational Patterns - A Proof of Concept Demo for SERENITY A. Saidane, F. Dalpiaz, V.H. Nguyen, F. Massacci

2. Trento, 11 June 2016 2 Talk Outline 1. Introduction 2. Background S&D Organizational (SDO) Patterns SDO Patterns at runtime Serenity Runtime Framework 3. E-Health case study Description S&D Requirements Needed runtime SDO Patterns 4. Prototype Architecture Organizational Structure Manager 5. Pattern Implementation 6. Demonstration scene 2

3. Trento, 11 June 2016 3 Introduction Ambient Intelligence (AmI) systems are characterized by the combination of heterogeneity, mobility, dynamism in addition to the interaction with huge number of devices,.. Increasing difficulty to ensure Security and Dependability (S&D) in such environments  S&D requirements change at runtime  Complexity and the unbounded nature of AmI ecosystems Context awareness, Detection/Reaction at runtime, Adaptability, self-* computing Runtime use of S&D patterns

4. Trento, 11 June 2016 4 Background: S&D Organizational (SDO) patterns NOT fulfilled S&D Requirements Initial organizational structure Agents Goals Goals Resources Resources Tasks Tasks Relations: delegation, trust… Relations: delegation, trust… Fulfilled Revised organizational structure Add/Remove Agents Add/Remove Agents Add/Remove GoalsAdd/Remove Goals Add/Remove Resources Add/Remove Resources Add/Remove Tasks Add/Remove Tasks Add/Remove Relations Add/Remove Relations ContextSolution S&D Organizational Pattern S&D Organizational Pattern =

5. Trento, 11 June 2016 5 Background: S&D Organizational (SDO) patterns Secure i* (SI*)  Conceptual modeling language  Founded on i* conceptual framework  Tailored to describe secure socio-technical systems  Based on concepts such as agent, role, goal, task, trust, delegation, ownership, permission and resource  A possible language to express S&D Organizational patterns

6. Trento, 11 June 2016 6 Background: SDO patterns at runtime Definitions  Runtime pattern: a software/hardware/liveware system that applications can invoke at runtime (through the pattern interface) in order to fulfill some functional or non- functional requirements  SDO runtime pattern: A Runtime pattern providing solutions for Security and Dependability Organizational requirements Exploitation  Requires an autonomic S&D framework Autonomous pattern selection (rather than relying on experts) S&D solutions should be applied online

7. Trento, 11 June 2016 7 Background: Serenity Runtime Framework The Serenity Runtime Framework (SRF) is  An autonomic S&D framework  A result of the SERENITY project  Features Implemented as a service that listens to S&D Requests Has a library of S&D Patterns Applications perform S&D Requests that trigger a search in the S&D Patterns library The most appropriate S&D Pattern is translated into an S&D Solution that can be used by the requesting application Implemented S&D solutions are called Executable Components

8. Trento, 11 June 2016 8 Background: Serenity Runtime Framework 1. S&D Solution Request 2. S&D Library Query 3. Check preconditions 4. Activate Executable Component (EC) 5. Return EC handler 6. Send events 7. Check violations in monitoring rules 8. Respond to violations

9. Trento, 11 June 2016 9 E-Health case study: Description Bob is a 56 years old widowed man. Bob has been discharged from hospital after a cardiac arrest. Bob can take care of himself, but of course his health status needs to be monitored 24/7. To achieve this end, some AmI devices are used to monitor Bob health status. These devices regularly collect and process data in order to detect suspicious situations

10. Trento, 11 June 2016 10 E-Health case study: S&D Requirements Requirement 1: high reliability  Bob’s health monitoring should be provided with a high reliability and accuracy. Requirement 2: authorization  In case of emergency rescue teams should be autonomically authorized to access the house. teams sent by MERC require simple authentication teams sent by Emergency Response need a more complex authentication mechanism Requirement 3: need-to-know  The need-to-know property should be ensured in the management of private data displayed on monitors rescue teams can see private medical data (saturation, heart rate) social workers in charge of delivering medicines can see less data

11. Trento, 11 June 2016 11 E-Health case study: Needed runtime SDO Patterns Requirement 1: high reliability can be provided by the Redundancy for Reliability S&D pattern ContextSolution

12. Trento, 11 June 2016 12 E-Health case study: Needed runtime SDO Patterns Requirement 2: authorization can be provided by the Access Control S&D pattern ContextSolution

13. Trento, 11 June 2016 13 Prototype: Architecture 13 Organizational Structure Manager Smart Home Application MERC AmI Devices Register/Unregister Send events Set-up (roles,actors, …) Info on current situation Request info on current situation Send Alert Send monitoring info

14. Trento, 11 June 2016 14 Prototype: Architecture

15. Trento, 11 June 2016 15 Prototype: Organizational Structure Manager Organizational Structure Manager (OSM)  A fundamental component of our prototype  Stores the current organizational structure expressed in SI* language  Provides shared access to and update of the organizational structure  Contains static and dynamic information Roles are typically defined at deployment time Agents playing roles are added initially at deployment time, then updated (added or removed) at runtime Agents are expected to execute those goals that they inherit from their current roles Delegation of execution happens at runtime

16. Trento, 11 June 2016 16 Pattern Implementation We provide a description for pattern “Redundancy for Reliability”... ... and we derive general principles Reliability  the ability of a system or component to perform its required functions under stated conditions for a specified period of time [IEEE standard glossary for Software Engineering terminology]  In our pattern, it is enforced by having at least two providers for any critical service

17. Trento, 11 June 2016 17 Pattern implementation Parameters relate a class-level pattern to a specific context  the goal whose execution is expected (monitor patient health)  the agent who requests the goal (application)  the active service provider providing the goal (camera 1)  the role the provider is playing (HealthMonitor) Solution enactment description describes how to transit from the context to the solution Agent newProvider = findRedundantProvider(camera1,“HealthMonitor”); if (newProvider==null) return error; delegate execution(application, newProvider, “Monitor Patient”);

18. Trento, 11 June 2016 18 Monitoring rules are essential to detect and react to specific events that occur after the pattern has been instantiated  We should detect situations when redundancy is not provided anymore (providers failure) Reference to OSM is required to let the Executable Component (EC) change the Organizational Structure  Our OSM works with RMI: the EC needs IP address and port Preconditions are fundamental to express patterns applicability  If there is only one agent that can play role HealthManager, redundancy is not applicable

19. Trento, 11 June 2016 19 Demonstration scene Monitoring Bob Alert Bob falls down Smart Home MERC Alert: Bob falls down Reliability Requirement Smart Home Access Authorized Resource Access Requirement Rescue request

20. Trento, 11 June 2016 20 Demonstration scene Monitoring Bob Alert Bob falls down Smart Home MERC Alert: Bob falls down Redundancy Pattern Redundancy Pattern Smart Home Access Access Control Pattern Access Control Pattern Rescue request