Security Services Lifecycle Management in On-Demand Infrastructure - - PowerPoint PPT Presentation

▶
security services lifecycle management
SMART_READER_LITE
LIVE PREVIEW

Security Services Lifecycle Management in On-Demand Infrastructure - - PowerPoint PPT Presentation

Aug 27, 2022 728 likes •1.1k views

Security Services Lifecycle Management in On-Demand Infrastructure Services Provisioning Yuri Demchenko System and Network Engineering Group University of Amsterdam CPSRT 2010 Workshop 2 December 2010 CloudCom2010 Conference 30 October - 3

slide-1
SLIDE 1

Security Services Lifecycle Management

in On-Demand Infrastructure Services Provisioning

Yuri Demchenko

System and Network Engineering Group University of Amsterdam CPSRT 2010 Workshop 2 December 2010

CloudCom2010 Conference 30 October - 3 December 2010, Indianapolis

slide-2
SLIDE 2

Outline

  • Background for this research
  • On-Demand Infrastructure Services Provisioning and Composable

Services Architecture (CSA)

 CSA Service Delivery Framework and Services Lifecycle Management

  • Proposed Security Services Lifecycle Management and related security

mechanisms

  • Implementation – GAAA Toolkit and Security sessions management
  • Summary and Discussion

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_2

slide-3
SLIDE 3

Background to this research

  • Current projects

 GEANT3 JRA3 Composable Services

– European NREN infrastructure

 GEYSERS – On-demand Optical + IT infrastructure resources provisioning

– Wide participation from large European network (Telefonika, Alcatel-Lucent, Interoute) and application providers (SAP)

  • Past projects

 EGEE Grid Security middleware – gLite Java Authorisation Framework  Phosphorus project Security architecture for multi-domain Network Resource

Provisioning

– GAAA-NRP and XACML-NRP profile – Multidomain Network Resource Provisioning (NRP) model and workflow

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_3

slide-4
SLIDE 4

Use Case – e-Science infrastructure

Components of the typical e-Science infrastructure involving multidomain and multi-tier Grid and Cloud resources and network infrastructure

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_4

Initial effort to build – estimated 2 Yrs Outsource to current telco provider – approx. 2 months Target with new business model – 2 hrs

User P User K User A Instrument (Manufactoring) Visualisation Visualisation

Grid Center Grid Center Computing Cloud Cloud Storage Grid Storage T1 Grid Storage T0 Grid Storage T1

Permanent link High Speed link provisioned on demand Link provisioned on-demand

Control & Monitoring

slide-5
SLIDE 5

Use Case – e-Science infrastructure

Components of the typical e-Science infrastructure involving multidomain and multi-tier Grid and Cloud resources and network infrastructure

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_5

User P User K User A Instrument (Manufactoring) Visualisation Visualisation

Grid Center Grid Center Computing Cloud Cloud Storage Grid Storage T1 Grid Storage T0 Grid Storage T1

Permanent link High Speed link provisioned on demand Link provisioned on-demand

Control & Monitoring

On-demand infrastructure services provisioning environment

  • Security along the whole

provisioning process and service/infrastructure lifecycle

  • Manageable/user

controlled security

  • Securing remote

executing environment

  • Security context/session

management

slide-6
SLIDE 6

GEYSERS Reference Model for Infrastructure Virtualisation

Roles:

  • VIO – Virtual

Infrastructure Operator

  • VIP - Virtual

Infrastructure Provider

  • PIP - Physical

Infrastructure Provider

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_6

slide-7
SLIDE 7

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_7

Security Service Lifecycle Management in On-Demand Resources/Services Provisioning

  • On-Demand Infrastructure Services Provisioning requires definition of

Services Lifecycle Management

 Multidomain multi-provider environment  Includes standard virtualisation procedures and mechanisms

  • Requires dynamic creation of Security/Trust Federations in multi-domain

environment

 Based on available Trust Anchors

– Physical Resources (hosting platforms) – SLA or SLA negotiators/contractors – All other security context/credentials/keys should be derived from them

  • Access control infrastructure dynamically created and policy/attributes

dynamically configured

 Access/authorisation session/context management

  • Composable Services Architecture (CSA) as a platform for dynamically

configurable composable services provisioning

slide-8
SLIDE 8

Composable Services Architecture

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management

Slide_8

Applications and User Terminals

Composition Layer/Serv (Reservation SLA Negotiatn) Logical Abstraction Layer for Component Services and Resources Control & Management Plane (Operation, Orchestration) Composable Services Middleware (GEMBus) Network Infrastructure Compute Resources Storage Resources Component Services & Resources – Physical Resources level Proxy (adaptors/containers) - Component Services and Resources Proxy (adaptors/containers) – Composed/Virtualised Services and Resources MD SLC Registry Logging Security User Client

Composable Services lifecycle/provisioning stages

(1) Request (2) Composition/ Reservation (3) Deployment (4) Operation (5) Decommissioning

Separation of Data Plane, Control Plane, Management Plane

Control/ Mngnt Links

Data Links

Virtual Infrastructure/Resources level

slide-9
SLIDE 9

CSA Services Delivery Framework (SDF)

Composable Services Provisioning Workflow

Main stages/phases

  • Service Request (including SLA

negotiation)

  • Composition/Reservation (aka

design)

  • Deployment, including

Reqistration/Synchronisation

  • Operation (including Monitoring)
  • Decommissioning

Additional stages

  • Re-Composition should address

incremental infrastructure changes

  • Recovery/Migration can use SL-MD

to initiate resources re- synchronisation but may require re- composition

The whole workflow is supported by the Service Lifecycle Metadata Service (SL MD) Based on the TMF SDF

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management

Slide_9

Service Request/ SLA Negotiation Composition/ Reservation Deployment Operation (Monitoring) Decommissioning Registr&Synchro

Recovery/ Migration Re-Compo sition

Service Lifecycle Metadata Service (SL MD)

Provisiong Session Managnt

slide-10
SLIDE 10

TMF Service Delivery Framework (SDF)

Security Services Lifecycle Management

Slide_10

Goal: Automation of the whole service delivery and operation process (TMF SDF, http://www.tmforum.org/ServiceDeliveryFramework/4664/home.html) End-to-end service management in a multi-service providers environment End-to-end service management in a composite, hosted and/or syndicated service environment Management functions to support a highly distributed service environment, for example unified or federated security, user profile management, charging etc. Any other scenario that pertains to a given phase of the service lifecycle challenges, such as on-boarding, provisioning, or service creation

CPSRT2010 Workshop, 2 December 2010

slide-11
SLIDE 11

SDF Reference Architecture (refactored from SDF)

Security Services Lifecycle Management

Slide_11

SDF Service Repository (ISS) SDF Service Lifecycle Metadata Coordination (ISS) SDF Service Design Management (ISS) SDF Service Deployment Management (ISS)

SDF Service Provisng Mngnt (MSS)

SDF Service Instance SDF Service Lifecycle Metadata Repository (ISS)

Design Operate Deploy

SDF Service Resource Fulfillment (ISS) SDF Service State Monitor (ISS) SDF Service Resource Monitor (ISS) SDF Service Resource Usage Monitor (ISS) SDF Service Quality/ Problem Mngnt (MSS) SDF Service Usage Mngnt (MSS) Composite Services provisioned on-demand

9 3 7 6 6 8 4 2 1 10 16 15 14 13 12 11 17

SDF MSS SDF ISS

1 – Service Instance 2 - Service Management Interface 3 – Service Functional Interface 4 - Management Support Service (SDF MSS) 8 - Infrastructure Support Service (ISS) DESIGN stage 9 - Service Repository 10 - Service Lifecycle Metadata Repository 16 - Service Design Management DEPLOYMENT stage 10 - Service Lifecycle Metadata Repository 11 - Service Lifecycle Metadata Coordinator 17 - Service Deployment Management OPERATION stage 5 - Service Provisioning Management 6 - Service Quality/Problem Management 7 - Service Usage Monitor 12 - Service State Monitor 13 - Service Resource Fulfillment 14 - Service Resource Monitor 15 - Resource Usage Monitor

CPSRT2010 Workshop, 2 December 2010

slide-12
SLIDE 12

Composable Services Architecture – Lifecycle stages workflow

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management

Slide_12

Composable Services lifecycle/provisioning stages

(1) Request (2) Composition/ Reservation (3) Deployment (4) Operation (5) Decommissioning MD SLC – Service Lifecycle Metadata GEMBus – GEANT Multidomain Bus

Control/ Mngnt Links

Data Links

Applications and User Terminals

Composition Layer /Serv (Reservation SLA Negotiatn) Logical Abstraction Layer for Component Services and Resources Control & Management Plane (Operation, Orchestration) Composable Services Middleware (GEMBus/GESB) Network Infrastructure Compute Resources Storage Resources Component Services & Resources Proxy (adaptors/containers) - Component Services and Resources Proxy (adaptors/containers) – Composed/Virtualised Services and Resources MD SLC Registry Logging Security User Client

1 1 2 2 2 2 2 3 3 3 3 3 3 4 2 4 4 4 4 4

Serv Serv Serv

slide-13
SLIDE 13

Security Services Lifecycle Management

Slide_13

Security Services Lifecycle Management Model

(compliant to CSA SDF/lifecycle model)

Security Service request and generation of the GRI that will serve as a provisioning session identifier and will bind all other stages and related security context. Reservation session binding that provides support for complex reservation process including required access control and policy enforcement. Deployment stage begins after all component resources have been reserved and includes distribution

  • f the security context and binding the reserved resources or services to GRI as a common

provisioning session ID. Registration&Synchronisation stage (optional) specifically targets possible scenarios with the provisioned services migration or failover/interruption. In a simple case, the Registration stage binds the local resource or hosting platform run-time process ID to the GRI as a provisioning session ID. Operation stage - security services provide access control to the provisioned services and maintain the service access or usage session. Decommissioning stage ensures that all sessions are terminated, data are cleaned up and session security context is recycled.

Service Request (GRI) Reserv Session Binding Deploy- ment & RsrBind Operatn Access Decom- mision Registr Synchro (Opt)

CPSRT2010 Workshop, 2 December 2010

slide-14
SLIDE 14

Security Services Lifecycle Management

Slide_14

Relation between SecuritySLM and general SLM

Additional SSLM stages and mechanisms to ensure consistency of the security context management Security Service Request that initiates creation of the dynamic security association and may use SLA security context. Reservation Session Binding with GRI (as part of Planning stage) that provides support for complex reservation process including required access control and policy enforcement. Registration&Synchronisation stage (as part Deployment stage) specifically targets possible scenarios with the provisioned services migration or failover/interruption. In a simple case, the Registration stage binds the local resource or hosting platform run-time process ID to the GRI as a provisioning session ID. SecServ Request (GRI) Reserv Session Binding Deploy- ment & RsrBind Operatn Access Decom- mision Registr Synchro (Ext) Service Request (GRI) Operate Maintain Decom- mision Design Development Reservation Deployment (a) Services Lifecycle Stages (b) Security Services Lifecycle Stages

CPSRT2010 Workshop, 2 December 2010

slide-15
SLIDE 15

Relation between SSLM/SLM stages and supporting general and security mechanisms

Security Services Lifecycle Management

Slide_15

SLM stages

Request Design/Reservation Development Deployment Operation Decomissioni ng

Process/ Activity SLA Nego tiation Service/ Resource Composition Reservation Composition Configuration Orchestration/ Session Management Logoff Accounting

Mechanisms/Methods

SLA

V V

Workflow

(V) V

Metadata

V V V V

Dynamic Security Associatn

(V) V V

AuthZ Session Context

V (V) V

Logging

(V) (V) V V

CPSRT2010 Workshop, 2 December 2010

slide-16
SLIDE 16

Implementation suggestions

Extend existing GAAA-Toolkit pluggable Java library to support dynamic Security/AAI infrastructure creation and integration with provisioned VI

  • Provides GAAA Authorisation API (GAAAPI) functions with extended AuthZ and

session management functionality

Support for SDF workflow and Security Services Lifecycle Management

  • Needs general infrastructure services such as Metadata SLM

Define and implement Common Security Service Interface (CSSI)

  • Supports both internal applications calls and Web service integration via Spring

security

  • Implements GSS-API and extends it with GAAAPI functionality

Use standard Messaging, Transport and Network security mechanisms provided by implementation platform

  • Implementation platform selection – ESB/WS/SOA (Fuse, Apache ServiceMix, etc.)

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_16

slide-17
SLIDE 17

GridNets2009, 8-9 September 2009, Athens

Multidomain Network/Complex Resource Provisioning (NRP/CRP) – Provisioning sequences

NRPS – Network Resource Provisioning System NSP – Network Service Plain DC – Domain Controller IDC – Interdomain Controller Provisioning sequences

  • Agent (A)
  • Polling (P)
  • Relay (R)

Token based policy enforcement

GRI – Global Reservation ID AuthZ tickets for multidomain context mngnt T - Token

  • AAA – AuthN, AuthZ, Accounting Server
  • PDP – Policy Decision Point
  • PEP – Policy Enforcement Point
  • TVS – Token Validation Service
  • KGS – Key Generation Service

NSP/AAA

PEP

User Client

DC/NRPS

NE PEP NE PEP NE

Agent (AAA)

P R A

Service (AAA) plane Control plane

Dest Host Appli- catio n

Network plane

DC/A AA

PAP

PDP

PAP PAP

PDP PDP TVS TVS TVS

DC/NRPS DC/NRPS

NSP/AAA NSP/AAA

slide-18
SLIDE 18

GridNets2009, 8-9 September 2009, Athens

Multidomain Complex Resource Provisioning (СRP) – Stage 1 – Path building and Advance Reservation

AAA – AuthN, AuthZ, Accounting Server PDP – Policy Decision Point PEP – Policy Enforcement Point TVS – Token Validation Service

IDC/AAA

PEP

User Client

DC/NRPS

NE PEP NE PEP NE

Service (AAA) plane Control plane

Dest Host Appli- catio n

Network plane

DC/A AA

PAP

PDP

PAP PAP

PDP PDP TVS TVS TVS

DC/NRPS DC/NRPS

GRI GRI GRI IDC/AAA IDC/AAA

IDC – Interdomain Controller DC – Domain Controller NRPS – Network Resource Provisioning System NE - Network Element Token based signalling and access control

GRI – Global Reservation ID AzTicket – AuthZ ticket for multidomain context mngnt AT – Access Token Pilot Token type 3 used at the Stage 1 Reservation for signalling and interdomain context communication

* As container for GRI and AzTicket

Pilot Token type 4 used at the Stage 2 for setup information communication

slide-19
SLIDE 19

GridNets2009, 8-9 September 2009, Athens

Multidomain Complex Resource Provisioning (СRP) – Stage 2 – Deployment (setup and key distribution)

AAA – AuthN, AuthZ, Accounting Server PDP – Policy Decision Point PEP – Policy Enforcement Point TVS – Token Validation Service IDC – Interdomain Controller DC – Domain Controller NRPS – Network Resource Provisioning System NE - Network Element Token based signalling and access control

GRI – Global Reservation ID AzTicket – AuthZ ticket for multidomain context mngnt AT – Access Token Pilot Token type 3 used at the Stage 1 Reservation for signalling and interdomain context communication

* As container for GRI and AzTicket

Pilot Token type 4 used at the Stage 2 for setup information communication IDC/AAA

PEP

User Client

DC/NRPS

NE PEP NE PEP NE

Service (AAA) plane Control plane

Dest Host Appli- catio n

Network plane

DC/A AA

PAP

PDP

PAP PAP

PDP PDP TVS TVS TVS

DC/NRPS DC/NRPS

GRI GRI GRI IDC/AAA IDC/AAA

PT4(AzTick) PT4(AzTick)

slide-20
SLIDE 20

GridNets2009, 8-9 September 2009, Athens

Multidomain Complex Resource Provisioning (СRP) – Stage 3 – Access Control (using access tokens)

Token based signalling and access control

GRI – Global Reservation ID AzTicket – AuthZ ticket for multidomain context mngnt AT – Access Token Pilot Token type 3 used at the Stage 1 Reservation for signalling and interdomain context communication

* As container for GRI and AzTicket

Pilot Token type 4 used at the Stage 2 for setup information communication

AAA – AuthN, AuthZ, Accounting Server PDP – Policy Decision Point PEP – Policy Enforcement Point TVS – Token Validation Service IDC – Interdomain Controller DC – Domain Controller NRPS – Network Resource Provisioning System NE - Network Element

IDC/AAA

PEP

User Client

DC/NRPS

NE PEP NE PEP NE

Service (AAA) plane Control plane

Dest Host Appli- catio n

Network plane

DC/A AA

PAP

PDP

PAP PAP

PDP PDP TVS TVS TVS

DC/NRPS DC/NRPS

GRI

AT

GRI GRI

AT AT

IDC/AAA IDC/AAA

AT

PT4(AzTick) PT4(AzTick)

slide-21
SLIDE 21

GridNets2009, 8-9 September 2009, Athens

СRP Stages and Authorisation Session Types

Requires consistent security and session context management Global Reservation ID (GRI) is created at the beginning of the provisioning session (Reservation stage) and binds all sessions

GRI generated

Reservation Deployment Access/Use Decommissioning Access Session Provisioning session Reservation Session Access Control Policy SLA, WS- Agreement Accounting, Billing Network Config. AccessToken PilotToken4 PilotToken0-3

slide-22
SLIDE 22

GridNets2009, 8-9 September 2009, Athens

Access Token and Pilot Token Types

AType 0 – Simple access token (refers to the reserved resources context) AType 1 – Access token containing Obligations collected from previous domains PType 0 – Container for GRI only PType 1 – Container for communicating the GRI during the reservation stage

  • Contains the mandatory SessionId=GRI attribute and an optional Condition element

PType 2 – Origin/requestor authenticating token

  • TokenValue element contains a value that can be used as the authentication value for the token
  • rigin
  • TokenValue may be calculated of the (GRI, IssuerId, TokenId) by applying e.g. HMAC function

with the requestor’s symmetric or private key.

PType 3 – Extends Type 2 with the Domains element that allows collecting domains security context information when passing multiple domains during the reservation process

  • Domains’ context may include the previous token and the domain’s trust anchor or public key

PType 4 – Used at the deployment stage and can communicate between domains security context information about all participating in the provisioned lightpath or network infrastructure resources

  • Can be used for programming/setting up a TVS infrastructure for consistent access control

tokens processing at the resource access stage

slide-23
SLIDE 23

GridNets2009, 8-9 September 2009, Athens

XML Token Format – Access and Pilot Tokens

  • Support inter-domain security/session context communication to allows

multidomain provisioning scenarios

  • Ensure Integrity of the AuthZ decision
  • Keeps AuthN/AuthZ context
  • Allow Obligated Decisions (e.g. XACML Obligations)
  • Supports simple delegation scenarios
  • Can be used for establish session-based trust relations between domains
  • Allows easy mapping to SAML and XACML related elements
slide-24
SLIDE 24

GridNets2009, 8-9 September 2009, Athens

Chaining Pilot Tokens in multidomain signalling

* Pilot Token type 3 issued by domain UVA Domain1 “viola” Resource Requestor Domain2 “uva” Domain3 “uclp”

<AAA:AuthzToken xmlns:AAA="http://www.aaauthreach.org/ns/AAA" Issuer=http://testbed.ist-phosphorus.eu/uva/AAA/TVS/tokenpilot SessionId="740b241e711ece3b128c97f990c282adcbf476bb" TokenId="dc58b505f9690692f7a6312912d0fb4c" type="pilot-type3"> <AAA:TokenValue>190a3c1554a500e912ea75a367c822c09eceaa2f </AAA:TokenValue> <AAA:Conditions NotBefore="2009-01-30T08:57:40.462Z" NotOnOrAfter="2009-01-30T09:21:40.462Z"/> <AAA:DomainsContext> <AAA:Domain domainId="http://testbed.ist-phosphorus.eu/viola"> <AAA:AuthzToken Issuer="http://testbed.ist-phosphorus.eu/viola/aaa/TVS/token-pilot« SessionId="2515ab7803a86397f3d60c670d199010aa96cb51" TokenId="c44a2f5f70346fdc2a2244fecbcdd244"> <AAA:TokenValue>dee1c29719b9098b361cab4cfcd086700ca2f414 </AAA:TokenValue> <AAA:Conditions NotBefore="2009-01-30T07:57:35.227Z" NotOnOrAfter="2009-01-31T07:57:35.227Z"/> </AAA:AuthzToken> <AAA:KeyInfo> http://testbed.ist-phosphorus.eu/viola/_public_key_ </AAA:KeyInfo> </AAA:Domain> </AAA:DomainsContext> </AAA:AuthzToken>

slide-25
SLIDE 25

Future work and Discussion

  • Definition of and reference implementation of the Common Security

Services Interface (CSSI)

 As extension to industry adopted GSS-API  Incorporate GAAA-AuthZ (RFC2904) Authorisation interface  Extends for Session Security Context Management and dynamic

trust/security association management

  • Wide range of formalisation and modeling work
  • Implementation in projects GEANT3 and GEYSERS
  • CSA and Security Services Lifecycle Management model is proposed as

a possible deliverable for OGF ISOD RG

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_25

slide-26
SLIDE 26

Additional Information

  • TMF SDF Lifecycle Management model

Security Services Lifecycle Management

Slide_26

CPSRT2010 Workshop, 2 December 2010

slide-27
SLIDE 27

AuthN/AuthZ Infrastructure (AAI) in GEYSERS

Basic CSSI services

Data encryption Digital signature Authentication Authorization Policy management Security session and context management

Called from services (or part of core interfaces)

SLI (SML-LICL) CCI (NCP-LICL) NLI (NCP-LICL) LPI (LICL-PHY) NIPS-UNI SML NCP LICL VITM NIPS Server CCI NIPS-UNI SLI NLI PHY LPI GEYSERS Security (AAI) CSSI

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_27

slide-28
SLIDE 28

PEP: Policy Enforcement Point PDP: Policy Decision Point PAP: Policy Administration Point DACS: Dynamic Access Control Service

GEYSERS AAI Reference Model

AuthN Service PDP PAP AuthN DB Token Validation Service (TVS) SecCtx Handler

AAI Gateway

PEP Dyn AC Service Mngnt

Common Security Services Interface (CSSI)

Config, Attr Trust/Key Mngnt

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_28

slide-29
SLIDE 29

GEMBus Infrastructure for Composable Service

GMI provides common dynamically configurable messaging infrastructure for Composable services communication

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management

Slide_29

GEMBus Infrastructure Services GEMBus Component Services

Service 2

(CSrvID, SesID)

GEMBus Registry Composition & Orchestration Logging Service Service 1

(CSrvID, SesID)

Service 3

(CSrvID, SesID)

Service 4

(CSrvID, SesID)

ESB GEMBus Messaging Infrastructure (GMI) Routing Configur ation

Interceptors (AspOrient)

Security Service

Message Handling

slide-30
SLIDE 30

Example Service Composition – Service NX

CSrvID, SesID – bind component services into the

  • n-demand

provisioned Composed service NX

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management

Slide_30

Role and place for Composition and Orchestration * Composable services or GEMBus infrastructure service

UserClient

(CSrvID,SesID)

Service 4

(CSrvID,SesID)

Service 3

(CSrvID,SesID)

Service 1

(CSrvID,SesID)

Service 2

(CSrvID,SesID)

UserClient

(CSrvID,SesID)

Frontend CompSrvNX

(CSrvID,SesID)

Service 4

(CSrvID,SesID)

Service 3

(CSrvID,SesID)

Service 1

(CSrvID,SesID)

Service 2

(CSrvID,SesID)

Composed Service NX

(CSrvID,SesID)

Composed Service NX

(CSrvID,SesID)

User Interface

slide-31
SLIDE 31

GEYSERS Reference Model

Role:

  • VIO
  • VIP
  • PIP

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_31

slide-32
SLIDE 32

Role of GEYSERS actors with respect to its architectural layers

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_32

slide-33
SLIDE 33

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_33

GEYSERS Service Delivery Framework (SDF)

  • Service provisioning workflow by VIP:

 Creation of the Virtual Infrastructure (VI)  May include more engineers support

  • Service provisioning workflow by VIO:

 Creation and operation of the Virtual Infrastructure on-demand for specific project,

tasks or user groups

 Should be completely automatic

  • Should also include activities/stages for infrastructure re-planning, restoration

and migration

  • Adopted TeleManagement Forum Service Delivery Framework (TMF SDF)
  • GEYSERS Project - http://www.geysers.eu/
slide-34
SLIDE 34

GEYSSERS Service Delivery Framework/Workflow

Geysers SDF supports both Geysers infrastructure development and deployments and its

  • peration for on-demand

Infrastructure services provisioning by VIO

Security Services Lifecycle Management

Slide_34

Service Request/ SLA Negotiation Planning (Design) Deployment (Instant& Config&Synchro) Operation &Monitoring (by VIO) Decommissioning Service Request/ SLA Negotiation Planning (Compos/Reserv) Deployment Operation (Monitoring) Decommissioning Registr&Synchro

Network+IT Services Provisioning Workflow by VIO

Recovery/ Migration

Re- Planning

Services Provisioning Workflow by VIP

Recovery/ Migration Re- planning CPSRT2010 Workshop, 2 December 2010

slide-35
SLIDE 35

Existing framework in on-Demand Infrastructure Services Provisioning and Lifecylce Management

TMF standardised frameworks, practices and procedures

  • SDF - Service Delivery Framework
  • SLA management
  • NGOSS – New Generation Operations System Services (including eTOM)

Microsoft Security Development Lifecycle (SDL) Framework

  • Primarily focused on the product development process by engineers/programmers

(Training) – Requirements – Design – Implementation – Verification – Release – (Response)

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_35

slide-36
SLIDE 36

SDF main stages and phases

Main stages/phases

  • Service Request (including SLA negotiation)
  • Planning (including Composition, Reservation and Design)
  • Deployment (including Reqistration/Synchronisation)
  • Operation (including Monitoring)
  • Decommissioning

Additional stages

  • Re-Composition should address incremental infrastructure changes
  • Recovery/Migration can use SL-MD to initiate resources re-synchronisation but may require re-

composition

The whole workflow should be supported by the Service Lifecycle Metadata Service (SL MD)

CPSRT2010 Workshop, 2 December 2010

Security Services Lifecycle Management Slide_36