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

Trento, 11 June 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

Trento, 11 June 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

Trento, 11 June 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 =

Trento, 11 June 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

Trento, 11 June 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

Trento, 11 June 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

Trento, 11 June 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

Trento, 11 June 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

Trento, 11 June 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

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

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

Trento, 11 June 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

Trento, 11 June Prototype: Architecture

Trento, 11 June 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

Trento, 11 June 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

Trento, 11 June 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”);

Trento, 11 June 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

Trento, 11 June 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

Trento, 11 June 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