Security and Dependability Organizational Patterns - A Proof of Concept Demo for SERENITY

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

2. Talk Outline • Introduction • Background • S&D Organizational (SDO) Patterns • SDO Patterns at runtime • Serenity Runtime Framework • E-Health case study • Description • S&D Requirements • Needed runtime SDO Patterns • Prototype • Architecture • Organizational Structure Manager • Pattern Implementation • Demonstration scene 2

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. NOT fulfilled Fulfilled S&D Organizational Pattern • Initial organizational structure • Agents • Goals • Resources • Tasks • Relations: delegation, trust… • Revised organizational structure • Add/Remove Agents • Add/Remove Goals • Add/Remove Resources • Add/Remove Tasks • Add/Remove Relations Context Solution Background: S&D Organizational (SDO) patterns S&D Requirements S&D Organizational Pattern = <context, requirements, solution>

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. 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. 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. 2. S&D Library Query 1. S&D Solution Request 5. Return EC handler 3. Check preconditions 8. Respond to violations 4. Activate Executable Component (EC) 6. Send events 7. Check violations in monitoring rules Background: Serenity Runtime Framework

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. 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. E-Health case study: Needed runtime SDO Patterns Requirement 1: high reliability can be provided by the Redundancy for Reliability S&D pattern Context Solution

12. E-Health case study: Needed runtime SDO Patterns Requirement 2: authorization can be provided by the Access Control S&D pattern Context Solution

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

14. Prototype: Architecture

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. 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. 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. 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. Demonstration scene Alert Bob falls down Monitoring Bob Alert: Bob falls down Reliability Requirement Smart Home Smart Home Access Authorized Resource Access Requirement MERC Rescue request

20. Demonstration scene Alert Bob falls down Monitoring Bob Alert: Bob falls down Redundancy Pattern Smart Home Smart Home Access Access Control Pattern MERC Rescue request