security and dependability organizational patterns - a proof of concept demo for serenity
Post on 03-Jan-2016
32 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
Trento, April 20, 2023 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
Trento, April 20, 2023 4
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>
Trento, April 20, 2023 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
Trento, April 20, 2023 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
Trento, April 20, 2023 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
Trento, April 20, 2023 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
Trento, April 20, 2023 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
Trento, April 20, 2023 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
Trento, April 20, 2023 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
Trento, April 20, 2023 12
E-Health case study: Needed runtime SDO Patterns
Requirement 2: authorization can be provided by the
Access Control S&D pattern
Context Solution
Trento, April 20, 2023 13
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
Trento, April 20, 2023 14
Prototype: Architecture
Trento, April 20, 2023 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
Trento, April 20, 2023 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
Trento, April 20, 2023 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”);
Trento, April 20, 2023 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
Trento, April 20, 2023 19
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
Trento, April 20, 2023 20
Demonstration scene
Monitoring Bob
AlertBob falls down
Smart Home
MERC
Alert: Bob falls downRedundancyPattern
RedundancyPattern
Smart HomeAccess
Access ControlPattern
Access ControlPattern
Rescue request
top related