Policy chains: the PoSecCo approach to policy management in Future Internet
description
Transcript of Policy chains: the PoSecCo approach to policy management in Future Internet
Policy chains: the PoSecCo approach to policy management in Future Internet
Cataldo BasilePolitecnico di Torino
<[email protected]>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