Using Ontologies for Privacy-Awareness in Network Monitoring Workflows

Transcription

1 Using Ontologies for Privacy-Awareness in Network Monitoring Workflows Georgios V. Lioudakis Institute of Communication and Computer Systems National Technical University of Athens Workshop on Collaborative Security and Privacy Technologies Cyber Security & Privacy EU Forum 2012

2 Motivating/Supporting Initiatives FP6 IST DISCREET Discreet Service Provision in Smart Environments FP7 ICT PRISM PRIvacy-aware Secure Monitoring FP7 ICT DEMONS DEcentralized, cooperative, and privacy-preserving MONitoring for trustworthiness ETSI ISG MOI Measurement Ontology for IP Traffic 2009

3 Passive Network Monitoring Inspection of the actual network traffic using special software and/or hardware equipment Range of applications: Operation and management of communication networks Identification of performance bottlenecks Network security (IDS, ADS, ) Network planning Accounting and billing of network services Validation of SLAs Observation and fine-tuning of QoS parameters Internet research based on collected traffic traces Law enforcement (data retention, lawful interception, )

4 Passive Network Monitoring Serious drawback: privacy implications! Relies natively on personal data collection and processing Various documented privacy violation mishaps Passive Network Monitoring special characteristics: Privacy-sensitive information exceeds payload and spans across various protocol headers and other communication metadata Too much personal information can be inferred and extracted using advanced processing techniques (statistical analysis, fingerprinting, ) Specific regulations govern the underlying services and data Very high data rates and consequent performance requirements Distributed and cooperative nature of operations and infrastructures Intra-domain Inter-domain

5 Fundamentals of the Approach Realisation of Privacy by Design Privacy-aware information flows and operations Enforcement of privacy-aware access control across the flows Contextual behaviour of the system Automatic integration of protection means Anonymisation, pseudonymisation, aggregation modules Complementary actions Consideration of the semantics of various concepts, such as: Data types, roles, operational processes, purposes for data collection and processing Use of ontologies for: Information modelling Workflow modelling Access and usage control rules specification

6 Execution Phase Planning Phase DEMONS Workflow Management Architecture Workflow Model Checker Reasoner <?xml version="1.0"?> <rdf:rdf xmlns:xsp= Policies WF Planning Environment Capabilities Matching Orchestration Layer Orchestration Interface Capabilities Bus Orchestrator Orchestrator Orchestrator Components Layer Components Interface Agent Agent Agent Agent Agent Control Message Bus Context Bus

7 DEMONS Workflows A workflow consists of tasks and their interactions w = T, F C, F D, where T = t 1, t 2,..., t n, t i = a i, op i, res i w F C : control flow associations F D : data flow associations + a declared purpose pu, e.g., NetworkSecurity + User role(s) r, e.g., NetworkAdministrator Overall WF = w, r k, pu or WF = w, r k, pu m for a stored workflow template GetUser Feeback [ MPF > 0.7 ] { uf } Start CaptureTraffic DetectBotnet [ MPF > 0.7 ] { MPF, uf } ReportToAUI [ Always ]

8 Workflow Verification Mechanism Ensures that the user-specified workflow is rendered privacy compliant before entering the execution phase A three steps procedure: 1. Purpose Verification: Checks regarding purpose compliance (relevance, consistency, etc.) 2. Skin Task Verification: User-specified tasks checked individually and in relation to each other 3. Decomposition: Composite skin tasks refinement and evaluation, until the level of atomic tasks Relies on a policy-based access control model Core components: Model Checker and Reasoner

9 Planning Phase Outcome GetUser Feeback [ MPF > 0.7 ] { uf } Start CaptureTraffic DetectBotnet [ MPF > 0.7 ] { MPF, uf } ReportToAUI [ Always ] GetUser Feeback [ 0.8 > MPF > 0.7 ] ProxyMode Anonymise [ MPF > 0.7 ] BlockingMode DetectBotnet CorrelateAlerts ReportToAUI [ MPF > 0.7 ] { uf } [ 1.0 > MPF > 0.9 ] [ 0.9 > MPF > 0.8 && uf == Int-m ] InteractionMode CaptureTraffic Start InformSecurityOfficer [ 0.9 > MPF > 0.8 && uf == Dis-m ] [ Always ] DisinfectionMode

10 Execution Phase Planning Phase Workflow Splitting and Dispatching Anonymise CaptureTraffic Start GetUser Feeback [ MPF > 0.7 ] DetectBotnet CorrelateAlerts ReportToAUI Orchestration Layer [ MPF > 0.7 ] InformSecurityOfficer { uf } WF Planning Environment [ 0.8 > MPF > 0.7 ] [ 1.0 > MPF > 0.9 ] [ 0.9 > MPF > 0.8 Reasoner Workflow && <?xml version="1.0"?> <rdf:rdf Model uf == Int-m ] xmlns:xsp= InteractionMode Checker Policies [ 0.9 > MPF > 0.8 && uf == Dis-m ] DisinfectionMode Capabilities Matching [ Always ] Orchestration Interface ProxyMode BlockingMode Capabilities Bus Orchestrator Orchestrator Orchestrator Components Layer Components Interface Agent Agent Agent Agent Agent Control Message Bus Context Bus

11 Workflows as Ontologies GetUser Feeback [ 0.8 > MPF > 0.7 ] ProxyMode Anonymise [ MPF > 0.7 ] { uf } [ 1.0 > MPF > 0.9 ] BlockingMode DetectBotnet CorrelateAlerts ReportToAUI [ MPF > 0.7 ] [ 0.9 > MPF > 0.8 && uf == Int-m ] InteractionMode CaptureTraffic Start InformSecurityOfficer [ 0.9 > MPF > 0.8 && uf == Dis-m ] [ Always ] DisinfectionMode DEMONS introduces an innovative approach for workflows description Motivation: the integration of typically disjoint BPM and scientific workflows Instead of legacy methods (e.g., BPMN), use of ontologies

12 Workflows as Ontologies GetUser Feeback [ 0.8 > MPF > 0.7 ] ProxyMode Anonymise [ MPF > 0.7 ] { uf } [ 1.0 > MPF > 0.9 ] BlockingMode DetectBotnet CorrelateAlerts ReportToAUI [ MPF > 0.7 ] [ 0.9 > MPF > 0.8 && uf == Int-m ] InteractionMode CaptureTraffic Start InformSecurityOfficer [ 0.9 > MPF > 0.8 && uf == Dis-m ] [ Always ] DisinfectionMode Class: TaskNode Annotation properties: actor, operation, resource, security policies, attributes, Object properties: describing connections with flow arrows

13 Workflows as Ontologies GetUser Feeback [ 0.8 > MPF > 0.7 ] ProxyMode Anonymise [ MPF > 0.7 ] DetectBotnet CorrelateAlerts ReportToAUI [ MPF > 0.7 ] { uf } [ 1.0 > MPF > 0.9 ] [ 0.9 > MPF > 0.8 && uf == Int-m ] BlockingMode InteractionMode CaptureTraffic Start InformSecurityOfficer [ 0.9 > MPF > 0.8 && uf == Dis-m ] [ Always ] DisinfectionMode Class: DataEdge Annotation properties: data type, condition, Object properties: source, destination

14 Workflows as Ontologies GetUser Feeback [ 0.8 > MPF > 0.7 ] ProxyMode Anonymise [ MPF > 0.7 ] DetectBotnet CorrelateAlerts ReportToAUI [ MPF > 0.7 ] { uf } [ 1.0 > MPF > 0.9 ] [ 0.9 > MPF > 0.8 && uf == Int-m ] BlockingMode InteractionMode CaptureTraffic Start InformSecurityOfficer [ 0.9 > MPF > 0.8 && uf == Dis-m ] [ Always ] DisinfectionMode Class: ControlEdge Annotation properties: parameter, condition, Object properties: source, destination

15 Workflows as Ontologies: Example GetUser Feeback [ MPF > 0.7 ] { uf } Start CaptureTraffic DetectBotnet [ MPF > 0.7 ] { MPF, uf } ReportToAUI [ Always ] Reference workflow, assuming: Purpose: BotnetMitigation Initiator: NetworkAdministrator

16 Workflows as Ontologies: Example GetUserFeedback1 ControlEdge hasdestination I I hasdestination I DataEdge hassource hassource Capture Traffic hasresource hasoperation CaptureTraffic1 hasactor I hassource MPF > 0.7 DetectBotnet1 hascondition I hassource 1 I hasdestination I DataEdge1 TaskNode hasdestination I hasdestination DataEdge2 hassource DataEdge4 I hassource I DataEdge3 hasdestination hascondition Always ReportToAUI1 I Purpose I BotnetMitigation Initiator I NetworkAdministrator

17 DEMONS Policy model The basis upon which Workflow Verification Procedure is grounded Provides the necessary knowledge for the operation of the system Two fundamental parts: Information Model, capturing all the concepts identified by the elaboration of the legal requirements and the network monitoring domain Rules, implementing the principles of necessity, proportionality, adequacy, minimisation, access limitation Fully implemented as an ontology

18 Information Model: Abstract Entities Purposes hasinputdata DataTypes mayactforpurposes mayservepurposes hasoutputdata hasinputalerts AlertTypes Roles Operations hasoutputalerts OrganisationTypes providesoperations Context MachineTypes hostscontainers OperationContainerTypes Various internal associations resulting in hierarchies

19 assignedwithroles isoforganisationtype isofmachinetype implementsoperation isofcontainertype isofdatatype isofalerttype Information Model: from Abstract to Concrete Entities Abstract Level mayactforpurposes Roles Purposes mayservepurposes DataTypes hasinputdata hasoutputdata AlertTypes hasinputalerts Operations hasoutputalerts Context Organisation Types MachineTypes hostscontainers providesoperations OperationContainer Types Data Users Operation Instances Alerts Organisations Machines hostscontainers providesoperationinstances OperationContainers Concrete Level

20 israw israw Information Model as an Ontology Example: Data Types hierarchies DataType YES YES isa IPv4Address lessdetailedthan contains IPv4Address NetworkID SourceIPv4 Address 6

21 israw israw Information Model as an Ontology Example: Data Types hierarchies DataType YES Ontological Class YES isa IPv4Address lessdetailedthan contains IPv4Address NetworkID SourceIPv4 Address 6

22 israw israw Information Model as an Ontology Example: Data Types hierarchies DataType YES YES isa IPv4Address lessdetailedthan contains IPv4Address NetworkID SourceIPv4 Address Individuals of the DataType class 6

23 israw israw Information Model as an Ontology Example: Data Types hierarchies DataType YES YES isa IPv4Address lessdetailedthan contains IPv4Address NetworkID SourceIPv4 Address Object properties 6

24 israw israw Information Model as an Ontology Example: Data Types hierarchies DataType YES YES isa IPv4Address lessdetailedthan contains IPv4Address NetworkID SourceIPv4 Address 6 Annotation Properties

25 Actions Whatever takes place in the context of DEMONS operation is seen as an operation of an actor on a resource Action Actor Operation Resource

26 Actions and Tasks By adding the organisation Org or the organisation type OrgT within which the action takes place: act i = a i, op i, res i, org An action act i being a part of a workflow w constitutes a task t i : t i = a i, op i, res i, org w or act i, w Not all the fields in the tuple need to be populated For instance, act i = *, op i, *, org, implies the execution of op i in org regardless the actor and resource Actions and tasks are atomic or composite following the hierarchical relations of operations

27 Three Levels of Abstraction R Op OpI hasactor Action hasoperation OpCT OpC U Op OpI R OpCT Op OpC U OpI AlT DT D Al MT M hasresource OrgT hasorganisation Org Abstract Concrete

28 Rules Permission Prohibition pu act preact cont postact Obligation DEMONS rules are defined over actions At every possible level of abstraction

29 Rules Permission Prohibition pu act preact cont postact Obligation act Act is the action that the rule applies to

30 Rules Permission Prohibition pu act preact cont postact Obligation pu Pu is the purpose for which act is permitted/ prohibitted/ obliged to be executed

31 Rules Permission Prohibition pu act preact cont postact Obligation preact Act is a structure of actions that should have be preceded in order for the rule to be enforced (e.g., another action, paths, etc.)

32 Rules Permission Prohibition pu act preact cont postact Obligation cont Con is a structure of contextual parameters (real time parameters + attributes evaluation)

33 Rules Permission Prohibition pu act preact cont postact Obligation postact Act refers to the action(s) that must be executed following the enforcement of the rule

34 Rules Permission Prohibition pu act preact cont postact Obligation Authorisations inherited across the Information Model s hierarchies Organisation concept not involved in the rule s body but included within each action The rule structure anticipates inter-domain scenarios, as act, preact and postact may take place within different organisations

35 Rules Permission Prohibition pu act preact cont postact Obligation Pre- and Post- Actions: single actions or Actions connected with logic operators AND, OR, NOT not implying sequence constraints Complex structures of actions named Skeletons Critical or non-critical Pre- and Post- Actions can be either tight or loose

36 Rules: Separation and Binding of Duty SoD / BoD Definition Permission Prohibition pu act preact cont postact Obligation Contextual constraints Static and dynamic SoD and BoD Defined by means of access and usage control rules Described as constraints between act and preact SoD and BoD apply to any combination of a, op, res, org act & a, op, res, org preact elements Contextual constraints apply (e.g., withinsameworkflow)

37 Rules: Ontological Representation Permission Prohibition pu act preact cont postact Obligation referstopurpose Purposes Rule appliesunder Context requirespreaction appliesforaction prescribespostaction Actions

38 For more information: Thank you for your attention! Any questions?