Policy chains: the PoSecCo approach to
policy management in Future Internet
Cataldo Basile
Politecnico di Torino
<[email protected]>
Pisa - June 9, 2011
Posecco scenario: Future Internet
seen from a Service Provider (SP)
sec reqs
from mgmt
Service
Provider
security reqs
from customers
security reqs from
laws and regulations
SP-customers
Service
Service
Service
service
application
application
application
application
application
DB
SP-staff
security reqs
from suppliers
system
DB
system
system
network
2
Abstraction layers:
PoSecCo vs. Enterprise Architecture
PoSecCo
Business
IT layer
Landscape
Enterprise Architecture
• customers, suppliers,
countries laws and
regulations, business
reqs, business data, roles
• IT services
• applications, subservices
• structured data
• hardware, network
topology, security
capabilities
Business
•product services, market segment, strategic
goals, strategic projects, interactions with
customers, interactions with suppliers
Process
•business processes, organization units, roles
and responsibilities, information flows, sites
Integration
Software
Technology
•applications, application domains, technical
services, IS-Functionality, information objects,
interfaces
•software components, datastructures
•hardware, network, software platforms
3
Policy chain
high-level security
requirements and
business- and legaldriven policies
connects separated
policy abstraction to
form a policy chain:
detection and
analysis of req
conflicts
selected IT policies
and controls to fulfill
requirements
technology-specific
security
configurations to
implement controls
on a given IT
landscape
matching reqs
against suppliers
refinement /
selection of
security controls
optimized
configuration
generation
runtime
analysis of reqs and
landscape changes
system validation and
audit
4
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 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
stakeholder
Process View: requests and change events
5
landscape
configuration
high-level refinement
Implementing the policy chain:
policy refinement:
• examples from end-user
partners (Crossgate, Deloitte)
Business policy
“manage private data
according to customer privacy
law”
harmonization and
• set of statements in form
refinement
ABSTRACT = device dependent / syntax
•subject-verb-object (options) form
independent
Change and•intermediate
Configurationformat
Management (CCM)
a relationship
• subject
and
may bebetween
groups ornetwork elements
is•express
used
to:objects
Example software
(packet filter):
(individuals)
categories
of individuals
•update
landscape
description
1.
from
10.0.0.2:80/TCP
IT policy
•relationships
areenforcement
associated to security properties
• interesting
for policy
•create
change
requests
to 10.0.7.15:any/any
ALLOW
•topology independent
purposes
the productive
landscape with help of
2. from•audit
10.1.1.24:any/any
• may (implicitly)
express relations
standardized,
comparable
to 10.1.4.78:any/any
ALLOW checklists and checks.
Example
3.
DENY
all
ontology-based
sub-service App1 ‘securely reach’ sub-service
Example:
refinement
WebFrontEnd
high security
services ‘securely reach’ their
or
sub-services
10.1.1.7 ‘reach’ 10.1.2.23:80/TCP
logical associations
landscape
configuration
configurations
6
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
7
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 ‘securely reach’ 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
8
Refinement Strategies:
service4 securely ‘reach’ service2
•basic VPN (tunnel mode)
•no impact on service performance
sub-services
end-to-end
may cipher
security
data(transport
at the application
mode)SSL/TLS)
layer,
layer
• topology-independent,
••configure
easy to configure
Ipsec +non
IKEinvasive
• impact ••may
on
may
performance
impact
impacton
onperformance
performance
no channel protection if
services are in the same
physical machine
(isolation)
9
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; policy and refinement concepts (strategies)
business
business and governance meta model
…
business
concepts
IT layer
designer/user
dependent
concepts
context dependent
concepts
(FI, services,
virtual, etc.)
landscape
landscape concepts
Abstraction
policy concepts
10
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-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 analysis
collaboration: PoSecCo and virtualization
improve the model in other scenarios
e.g., cloud computing
11
THANK YOU!
Disclaimer
EU Disclaimer
PoSecCo 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 Disclaimer
The 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.
13
14
Descargar

Title of the presentation