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

Trento, April 20, 2023 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


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


Background: S&D Organizational (SDO) patterns

NOT fulfilled

S&D Requirements

Initial organizational structure

• AgentsAgents

• GoalsGoals

• ResourcesResources

• TasksTasks

• Relations: delegation, trust…Relations: delegation, trust…

Fulfilled

Revised organizational structure

• Add/Remove Agents Add/Remove Agents

•Add/Remove GoalsAdd/Remove Goals

• Add/RemoveAdd/Remove Resources Resources

• Add/RemoveAdd/Remove Tasks Tasks

• Add/RemoveAdd/Remove Relations Relations

Context Solution

S&D Organizational

Pattern

S&D Organizational Pattern = <context, requirements, solution>


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


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


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


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


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


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


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


E-Health case study: Needed runtime SDO Patterns

Requirement 2: authorization can be provided by the

Access Control S&D pattern

Context Solution


Prototype: Architecture

13

Organizational Structure Manager

Organizational Structure Manager

Smart Home ApplicationSmart Home Application

MERCMERC

AmI Devices

Register/Unregister

Send events

Set-up(roles,actors, …)

Info on current situation

Request info on current situation

Send AlertSend monitoring info


Prototype: Architecture


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


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


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”);


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


Demonstration scene

Monitoring Bob

AlertBob falls down

Smart Home

MERC

Alert: Bob falls downReliability Requirement

Reliability Requirement

Smart HomeAccess

Authorized Resource Access

Requirement

Authorized Resource Access

Requirement

Rescue request


Demonstration scene

Monitoring Bob

AlertBob falls down

Smart Home

MERC

Alert: Bob falls downRedundancyPattern

RedundancyPattern

Smart HomeAccess

Access ControlPattern

Access ControlPattern

Rescue request

Documents

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