Policy chains: the PoSecCo approach to policy management in Future Internet

Cataldo BasilePolitecnico di Torino

<cataldo.basile@polito.it>Pisa - June 9, 2011

2

Posecco scenario: Future Internet seen from a Service Provider (SP)

Service Service Service service

application application

applicationapplication

application

system system system

DB DB

network

Serv

ice

Prov

ider

security reqsfrom customers

Supplier

Supplier

SP-customers

sec reqsfrom mgmt

SP-staff

security reqsfrom suppliers

security reqs fromlaws and regulations

3

PoSecCo Enterprise Architecture

Abstraction layers: PoSecCo vs. Enterprise Architecture

•product services, market segment, strategic goals, strategic projects, interactions with customers, interactions with suppliers

Business

•business processes, organization units, roles and responsibilities, information flows, sites

Process•applications, application domains, technical services, IS-Functionality, information objects, interfaces

Integration

•software components, datastructuresSoftware

•hardware, network, software platformsTechnology

•customers, suppliers, countries laws and regulations, business reqs, business data, roles

Business•IT services•applications, subservices•structured data

IT layer

•hardware, network topology, security capabilities

Landscape

4

Policy chain

high-level security requirements and

business- and legal-driven policies

selected IT policies and controls to fulfill

requirements

technology-specific security

configurations to implement controls

on a given IT landscape

detection and analysis of req

conflicts

matching reqs against suppliers

refinement / selection of

security controls

optimized configuration

generation

analysis of reqs and landscape changes

system validation and audit

Changes of settings inproductive systems

Changes of laws,

regulations, standards,

customers, …

connects separated policy abstraction to form a policy chain:

runtime

5

Governance meta-model

Stakeholder Modeldefines the stakeholders involved in the security requirements management process

System Meta Model static concepts relevant for the security requirements management process (e.g., Business and IT services)security related information (e.g. security requirements and risks) attached to a functional concept (e.g., a business process or an IT resource)

a System Model describes the status of the organisation at a certain point of time including its security status (e.g. actual security requirements)

View Model: the portion of the system model seen by each stakeholderProcess View: requests and change events

6

Business policy

harmonization and refinement

IT policy

ontology-based refinement

logical associationslandscape

configuration configurations

Implementing the policy chain: policy refinement:

• examples from end-user partners (Crossgate, Deloitte)“manage private data according to customer privacy law”

ABSTRACT = device dependent / syntax independent

Example (packet filter):1. from 10.0.0.2:80/TCP

to 10.0.7.15:any/any ALLOW2. from 10.1.1.24:any/any

to 10.1.4.78:any/any ALLOW3. DENY all

• set of statements in form• subject-verb-object (options) form

• subject and objects may be groups or categories of individuals• interesting for policy enforcement purposes• may (implicitly) express relations

Example:high security services ‘securely reach’ their sub-services

land

scap

e co

nfigu

ratio

nhi

gh-le

vel r

efine

men

t

Change and Configuration Management (CCM) software is used to:•update landscape description •create change requests•audit the productive landscape with help of standardized, comparable checklists and checks.

•intermediate format •express a relationship between network elements (individuals)•relationships are associated to security properties•topology independent

Examplesub-service App1 ‘securely reach’ sub-service WebFrontEndor10.1.1.7 ‘reach’ 10.1.2.23:80/TCP

7

collaboration: standardize policy languagesbusiness policy format (October 2011)

no official or de facto standards (BPMN?)

IT policy language and formal models (2012)according to the different security properties to enforceallow conflict analysis, complex refinement process, backtracing

common format for configurations (2012)filtering, channel protection, access control devicesPolicy Common Information Model

bind to landscape description

common outcome: define policy meta-models for EU projectsmaximum freedom to extend and customize policies according to other projects needs

input: policy models from other projectscollaboration: documents circulation of policy-related topics, meetings and synchronization events

EffectPlus: building a common understanding

8

topology awaremany refinement modules one for each security property

e.g., reachability, channel protection, Access Control (= different requirements)

implement refinement strategies at the lowest leveland optimize configurations in distributed systems

logical associationstopology-independent relations (between network elements)

Kommunikation SUN cluster 1 ‘reach’ Kommunikation SUN cluster 110.0.0.7 ‘reach’ 10.10.1.15SAP II EDI process engine ‘securely reach’ WebEDI Business process Engine

optional attributestime (weekdays,8.00-19.00), protection level (HIGH/MEDIUM/LOW), …

formats depend on the security propertyoutcome for other projects: a set of modules to be used as configuration generation servicesinput: support for virtualization and cloud

Landscape Refinement

9

Refinement Strategies: service4 securely ‘reach’ service2

end-to-end security (transport mode)•configure Ipsec + IKE•may impact on performance

end-to-end security (transport layer, SSL/TLS)• easy to configure• may impact on performance

•basic VPN (tunnel mode)•no impact on service performance

no channel protection if services are in the same physical machine (isolation)

sub-services may cipher data at the application layer• topology-independent, non invasive• impact on performance

extend the landscape description with semantically rich concepts and logically connect them

landscape: network and topology, FI and service-related, external service providers concepts; policy and refinement concepts (strategies)

10

Ontology-based refinement

landscape concepts

policy concepts

business concepts

business and governance meta model

Abst

racti

on

context dependentconcepts

(FI, services, virtual, etc.)

designer/userdependentconcepts

business

IT layer

landscape

…

11

landscape meta-models (initial model in October 2011)input: landscape descriptions in other projects

security ontologies (initial model in October 2011)input: ontologies to represent policy-related and landscape conceptscollaboration: merge with non-PoSecCo ontologies

collaboration: build components on top of the PoSecCo refinement architecture

use PoSecCo refinement models and tools as services

collaboration: formal models for refinement, conflict analysis, enforceability analysiscollaboration: PoSecCo and virtualization

improve the model in other scenariose.g., cloud computing

EffectPlus: building a common understanding

THANK YOU!

13

EU DisclaimerPoSecCo project (project no. 257129) is partially supported/co-funded by the European Community/ European Union/EU under the Information and Communication Technologies (ICT) theme of the 7th Framework Programme for R&D (FP7).

This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of its content.

PoSecCo DisclaimerThe information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law.

Disclaimer

14