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

1. Policy chains: the PoSecCo approach to policy management in Future Internet Cataldo Basile Politecnico di Torino <cataldo.basile@polito.it> Pisa - June 9, 2011

2. Posecco scenario: Future Internet seen from a Service Provider (SP) security reqs from customers security reqs fromlaws and regulations SP-customers security reqs from suppliers Service Provider sec reqs from mgmt Service Service Service service application application application application application DB DB Supplier system system system SP-staff Supplier network

3. Abstraction layers: PoSecCo vs. Enterprise Architecture PoSecCo Enterprise Architecture

4. Policy chain • connects separated policy abstraction to form a policy chain: Changes of laws, regulations, standards, customers, … runtime Changes of settings inproductive systems

5. Governance meta-model • Stakeholder Model • defines the stakeholders involved in the security requirements management process • System Meta Model • static concepts relevant for the security requirements management process (e.g., Business andIT 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 stakeholder • Process View: requests and change events

6. Implementing the policy chain: policy refinement: • examples from end-user partners (Crossgate, Deloitte) • “manage private data according to customer privacy law” • 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 ABSTRACT = device dependent / syntax independent Example (packet filter): from 10.0.0.2:80/TCP to 10.0.7.15:any/any ALLOW from 10.1.1.24:any/anyto 10.1.4.78:any/any ALLOW DENY all high-level refinement • 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 • Example • sub-service App1 ‘securelyreach’ sub-service WebFrontEnd • or • 10.1.1.7 ‘reach’ 10.1.2.23:80/TCP landscape configuration

7. EffectPlus: building a common understanding • collaboration: standardize policy languages • business 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 enforce • allow conflict analysis, complex refinement process, backtracing • common format for configurations (2012) • filtering, channel protection, access control devices • Policy Common Information Model • bind to landscape description • common outcome: define policy meta-models for EU projects • maximum freedom to extend and customize policies according to other projects needs • input: policy models from other projects • collaboration: documents circulation of policy-related topics, meetings and synchronization events

8. Landscape Refinement • topology aware • many refinement modules one for each security property • e.g., reachability, channel protection, Access Control (= different requirements) • implement refinement strategies at the lowest level • and optimize configurations in distributed systems • logical associations • topology-independent relations (between network elements) • Kommunikation SUN cluster 1 ‘reach’ Kommunikation SUN cluster 1 • 10.0.0.7 ‘reach’ 10.10.1.15 • SAP II EDI process engine ‘securelyreach’ WebEDI Business process Engine • optional attributes • time (weekdays,8.00-19.00), protection level (HIGH/MEDIUM/LOW), … • formats depend on the security property • outcome for other projects: a set of modules to be used as configuration generation services • input: support for virtualization and cloud

9. Refinement Strategies: service4 securely ‘reach’ service2 • basic VPN (tunnel mode) • no impact on service performance • sub-services may cipher data at the application layer • topology-independent, non invasive • impact on performance • 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 no channel protection if services are in the same physical machine (isolation)

10. Ontology-based refinement • extend the landscape description with semantically rich concepts and logically connect them • landscape: network and topology, FI and service-related, external service providers concepts; policyandrefinement concepts (strategies) business business and governance meta model business concepts … policy concepts IT layer designer/user dependentconcepts Abstraction context dependentconcepts (FI, services, virtual, etc.) landscape landscape concepts

11. EffectPlus: building a common understanding • 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 concepts • collaboration: merge with non-PoSecCoontologies • 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 analysis • collaboration: PoSecCo and virtualization • improve the model in other scenarios • e.g., cloud computing

13. Disclaimer