Network Security Modelling Isabelle at i8 Cornelius Diekmann - - PowerPoint PPT Presentation
Network Security Modelling Isabelle at i8 Cornelius Diekmann Lehrstuhl f ur Netzarchitekturen und Netzdienste Institut f ur Informatik Technische Universit at M unchen March 27, 2013 C. Diekmann (TU M unchen) Network Security
Isabelle at i8 Cornelius Diekmann
Lehrstuhl f¨ ur Netzarchitekturen und Netzdienste Institut f¨ ur Informatik Technische Universit¨ at M¨ unchen
March 27, 2013
unchen) Network Security Modelling 1
Agenda
1
Motivation & Introduction
2
Related Work
3
Abstract Network Security Model Definition
4
Concrete Network Models
5
Implementation
6
Evaluation
7
Conclusion Slides: 64
unchen) Network Security Modelling 2
unchen) Motivation & Introduction 3
Border Firewalls
Problems Hard to administer Many corporate firewall misconfigured, even experienced admins make mistakes [Woo04, HAS06, YCM+06] In reality: “no good high-complexity rule sets” [Woo04] Coarse grained: One compromised host in the intranet subverts everything
Internet Firewall Workstation Intranet Workstation Workstation internal Fileserver Workstation Backup
unchen) Motivation & Introduction Border Firewalls 4
Border Firewalls
Problems Hard to administer Many corporate firewall misconfigured, even experienced admins make mistakes [Woo04, HAS06, YCM+06] In reality: “no good high-complexity rule sets” [Woo04] Coarse grained: One compromised host in the intranet subverts everything
Internet Firewall Workstation Workstation Workstation Workstation internal Fileserver Backup Intranet
unchen) Motivation & Introduction Border Firewalls 4
Security Components – Bishop [Bis03] Requirements Policy Mechanisms
Security Requirements
Individual, scenario specific security needs
Security Policy
How to achieve requirements
Security Mechanisms
Enforce policy
unchen) Motivation & Introduction Security Components 5
Our Goals
Mechanisms Policy Requirements Verify network’s security requirements Method to construct secure network topology Feedback: Assess quality of security requirements Usability Focus on industrial environments
Closed networks Known participants
unchen) Motivation & Introduction Security Components 6
unchen) Related Work 7
Related Work
Network Management [BJUN07, UNJB]
No formal methods, low level
Network Vulnerability Modelling [RA00]
Model checker, barely usable, unrealistic assumption
Firewall analysis [Woo04, ASH04, PCG07, YCM+06, GH05, HAS06, MGC12]
Low level, discovers known errors Assumes almighty admin, axiomatic security policy available
Information Flow Security
Programming languages [Eck12, GM82, Rus92, BS09, ML97a, ML97b, VBC+04, Den76, Den75, Fol91, Sut86, McL90, McC90, Man02] Taxonomy, security classes (lattices), composition of systems
unchen) Related Work 8
Related Work: Guttman and Herzog
Rigorous Automated Network Security Management [GH05]
Formal modeling method to check compliance of network to security goals (high level policy) “For instance, a corporation may use outbound filtering to ensure that traffic with a database server cannot be misrouted
is carried in these packets” [GH05, 2.2 Expressing security goals] n filtering routers: O(n) security goals O(1) security requirements: database’s confidentiality
False positives may occur
“[. . . ] give additional information reducing false positives. That is, the additional information will help reduce the cases in which we report that there may be violations, when in fact there is no counterexample [. . . ]” [GH05, 4.2 Deriving algorithms]
unchen) Related Work 9
unchen) Related Work Bell LaPadula 10
Bell LaPadula Model
Confidentiality and privacy security requirements Each subject is assigned a security clearance unclassified < confidential < secret < topsecret Total function sc : subject ⇒ security clearance Rules
receiver r, sender s
1 no-read-up: sc r ≥ sc s 2 no-write-down: sc s ≤ sc r
sc s ≤ sc r Network: directed graph G blp G sc ≡ ∀(s, r) ∈ edges G. sc s ≤ sc r Default configuration: Everything is unclassified
unchen) Related Work Bell LaPadula 11
Bell LaPadula Example
Host1 unclassified Host2 unclassified Host1 unclassified Host2 classified Host1 classified Host2 unclassified
unchen) Related Work Bell LaPadula 12
Abstract Network Security Model Definition
unchen) Abstract Network Security Model Definition 13
Abstract Network Security Model Definition
Encodes some type of security requirement Network Security Model – locale
1 Secure default configuration value ⊥ 2 Function eval model
semantic validity of the network
3 Function verify globals
syntactic checks
4 target focus
Offending host of offending flow. Sender or receiver. Bool
Signatures: ⊥ : ’a eval model (G : graph, nP : vertices ⇒ ‘a, gP : ‘b) : Bool verify globals (G : graph, nP : vertices ⇒ ‘a, gP : ‘b) : Bool
unchen) Abstract Network Security Model Definition 14
Abstract Network Model Definition
Checking a model: Input
G Configuration
1 Verify that the supplied graph G is syntactically valid. 2 Optional: verify that the supplied configuration only mentions
nodes of G.
3 Generate nP: Map all nodes configured by the supplied
configuration to their configuration value, map the rest to ⊥.
4 Call verify globals. 5 Call eval model.
unchen) Abstract Network Security Model Definition 15
What is ⊥?
unchen) Abstract Network Security Model Definition 16
Secure by default
⊥ is secure default parameter ⊥ can be securely inserted as configuration of all unconfigured nodes Administrator can use model without configuring all nodes Fahrplan towards secure ⊥
1 Offending flows
Valid model → Empty set Invalid model → Minimal set of flows to remove to render model valid Can be ambiguous: set of sets
2 target focus taxonomy 3 Security prerequisites for a secure default parameter
Next slide
unchen) Abstract Network Security Model Definition Secure by Default 17
Taxonomy
Offending flow
?
− → offending host
Host1 classified Host2 unclassified
Model target focus Bell LaPadula Receiver Bell LaPadula + trust Receiver Dependability Sender DomainHierarchy Sender NonInterference Receiver SecurityGateway Sender SecurityGatewayExtended Sender Sink Receiver Subnets Sender SubnetsInGW Sender Receiver → information flow security model Sender → access control model
unchen) Abstract Network Security Model Definition Secure by Default 18
Secure Default Parameter
Preliminary Considerations Secure with regard to the available information Replace configuration with ⊥
Replacement ≡ forgot to configure A default configuration must never solve an existing security violation Assigning unknown hosts a default configuration does not impose security risks
unchen) Abstract Network Security Model Definition Secure by Default 19
Secure Default Parameter
Case model invalid (eval model = False) Some security violation exists
Host1 classified Host2 unclassified Host1 top secret Host2 secret
Host1 top secret Host2 unclassified
unchen) Abstract Network Security Model Definition Secure by Default 20
Secure Default Parameter
Case model invalid (eval model = False) Some security violation exists
Host1 classified Host2 unclassified
Offending flows → offending host (target focus)
Host1 top secret Host2 secret Host1 top secret Host2 unclassified
unchen) Abstract Network Security Model Definition Secure by Default 20
Secure Default Parameter
Case model invalid (eval model = False) Some security violation exists
Host1 classified Host2 unclassified
Offending flows → offending host (target focus) Considering only validity and offending flows
Host1 top secret Host2 secret Host1 top secret Host2 unclassified
Replacing offending host’s configuration by ⊥: removes no information Must never render model valid!
unchen) Abstract Network Security Model Definition Secure by Default 20
⊥ conclusion
⊥ is secure under the given information, if
1 For all networks 2 In all invalid configurations 3 Replacing the configuration of an offending host with ⊥ does
not render the model valid.
unchen) Abstract Network Security Model Definition Secure by Default 21
⊥ conclusion
⊥ is secure under the given information, if
1 For all networks 2 In all invalid configurations 3 Replacing the configuration of an offending host with ⊥ does
not render the model valid.
Formalization:
¬eval model G nP gP ∧ f ∈ offending flows G nP gP ∧ eval model (delete edges G f) nP gP = ⇒ (¬target focus − → i ∈ fsts f − → ¬eval model G (nP(i := ⊥)) gP)∧ (target focus − → i ∈ snds f − → ¬eval model G (nP(i := ⊥)) gP)
unchen) Abstract Network Security Model Definition Secure by Default 21
⊥ conclusion
⊥ is secure under the given information, if
1 For all networks 2 In all invalid configurations 3 Replacing the configuration of an offending host with ⊥ does
not render the model valid.
Formalization:
¬eval model G nP gP ∧ f ∈ offending flows G nP gP ∧ eval model (delete edges G f) nP gP = ⇒ (¬target focus − → i ∈ fsts f − → ¬eval model G (nP(i := ⊥)) gP)∧ (target focus − → i ∈ snds f − → ¬eval model G (nP(i := ⊥)) gP)
Additional: ⊥ must be unique
unchen) Abstract Network Security Model Definition Secure by Default 21
⊥ conclusion
⊥ is secure under the given information, if
1 For all networks 2 In all invalid configurations 3 Replacing the configuration of an offending host with ⊥ does
not render the model valid.
Formalization:
¬eval model G nP gP ∧ f ∈ offending flows G nP gP ∧ eval model (delete edges G f) nP gP = ⇒ (¬target focus − → i ∈ fsts f − → ¬eval model G (nP(i := ⊥)) gP)∧ (target focus − → i ∈ snds f − → ¬eval model G (nP(i := ⊥)) gP)
Additional: ⊥ must be unique Assumptions in network security model locale
unchen) Abstract Network Security Model Definition Secure by Default 21
unchen) Abstract Network Security Model Definition Composition of Models 22
Composition of Network Security Models
Security requirements document
1 Must fulfill employee privacy on SensorNode 2 Must protect corporate trade secrets at FileServer
Composition of network security models
Pprivacy ∧ Ptrade secrets
SensorNode Privacy: classified T rade Secrets: unclassified CorporateFileServer Privacy: unclassified T rade Secrets: classified
unchen) Abstract Network Security Model Definition Composition of Models 23
\end{theory}
\begin{theory}
unchen) Concrete Network Models 24
Bell LaPadula
Confidentiality and privacy security clearance = N unclassified = 0, confidential = 1, secret = 2, . . . default: everything is unclassified, unless otherwise specified ⊥ ≡ 0 Policy: no receive up, no send down eval model (G : graph, nP : vertices ⇒ security clearance, gP : ‘b) eval model G nP gP ≡ ∀(e1, e2) ∈ edges G. (nP e1) ≤ (nP e2) verify globals G nP gP ≡ True
unchen) Concrete Network Models Bell LaPadula 25
Bell LaPadula Example
Statistics ⊥ SensorSink ⊥ PresenceSensor ⊥ Webcam ⊥ TempSensor ⊥ FireSensor ⊥ MissionControl1 ⊥ Bot1 ⊥ Bot2 ⊥ MissionControl2 ⊥ Watchdog ⊥
unchen) Concrete Network Models Bell LaPadula 26
Bell LaPadula Example
Statistics ⊥ SensorSink ⊥ PresenceSensor 2 Webcam 3 TempSensor ⊥ FireSensor ⊥ MissionControl1 ⊥ Bot1 ⊥ Bot2 ⊥ MissionControl2 ⊥ Watchdog ⊥
unchen) Concrete Network Models Bell LaPadula 26
Bell LaPadula Example
Statistics ⊥ SensorSink 3 PresenceSensor 2 Webcam 3 TempSensor ⊥ FireSensor ⊥ MissionControl1 ⊥ Bot1 ⊥ Bot2 ⊥ MissionControl2 ⊥ Watchdog ⊥
unchen) Concrete Network Models Bell LaPadula 26
Bell LaPadula Example
Statistics 3 SensorSink 3 PresenceSensor 2 Webcam 3 TempSensor ⊥ FireSensor ⊥ MissionControl1 ⊥ Bot1 ⊥ Bot2 ⊥ MissionControl2 ⊥ Watchdog ⊥
unchen) Concrete Network Models Bell LaPadula 26
Bell LaPadula Example
Statistics 3 ⊥ SensorSink 3 ⊥ PresenceSensor 2 ⊥ Webcam 3 ⊥ TempSensor ⊥ ⊥ FireSensor ⊥ ⊥ MissionControl1 ⊥ 1 Bot1 ⊥ 1 Bot2 ⊥ 2 MissionControl2 ⊥ 2 Watchdog ⊥ ⊥
unchen) Concrete Network Models Bell LaPadula 26
Bell LaPadula Analysis
Network Model: The default parameter is unique and secure according to the definition (formal proof in svn) For a correct configuration, each host is manifestly secure [McC90, Sect. V] = ⇒ the entire system is restrictive The network as a whole is secure, even in the presence of compromised hosts [McC90, Sect. V] The task of securing a complete network has been reduced to assuring that each host is assigned the correct privacy level
unchen) Concrete Network Models Bell LaPadula 27
Domain Hierarchy
Organisational structures Domain hierarchy Each establishment consists of departments which themselves consists of sub-departments A department higher in the hierarchy may issue commands to its direct or indirect sub-departments domainTree:
TUM i8 i20 CoffeeMachine TeaMachine
unchen) Concrete Network Models Domain Hierarchy 28
Domain Hierarchy
domainName: Address specific entities in the hierarchy Example: ‘TUM’–‘i8’–‘CoffeeMachine’–X Not assigned to any department: Unassigned String terminator: X Comparison via ≤ operator Partial order
TUM i8 i20 CoffeeMachine TeaMachine
‘TUM’–‘i8’–‘CoffeeMachine’–X ≤ ‘TUM’–‘i8’–X Unassigned ≤ ‘TUM’–‘i8’–X ‘TUM’–‘i8’–X ≤ ‘TUM’–‘i8’–X ‘TUM’–‘i8’–‘CoffeeMachine’–X ≤ ‘TUM’–X ‘TUM’–‘i8’–‘CoffeeMachine’–X ≤ X ‘TUM’–‘i8’–X ‘TUM’–‘i20’–X ‘TUM’–‘i20’–X ‘TUM’–‘i8’–X
unchen) Concrete Network Models Domain Hierarchy 29
Domain Hierarchy Model
Verify configuration and domainTree consistency
verify globals (G : graph, nP : vertices ⇒ domainName, gP : domainTree) verify globals G nP gP ≡ ∀v ∈ nodes G. valid hierarchy pos gP (nP v)
Commands only travel from departments to their sub-departments
eval model (G : graph, nP : vertices ⇒ domainName, gP : domainTree) eval model G nP gP ≡ ∀(e1, e2) ∈ edges G. (nP e2) ≤ (nP e1)
Default: all unconfigured nodes can freely interact with each
⊥ : domainName ⊥ ≡ Unassigned
unchen) Concrete Network Models Domain Hierarchy 30
Domain Hierarchy Example
TUM i8 i20 CoffeeMachine TeaMachine
Wolfgang TUM-X Holger TUM-i8-X Heiko TUM-i8-X CoffeeMachine TUM-i8-CoffeeMachine-X Jonas TUM-i20-X TeaMachine TUM-i8-T eaMachine-X
unchen) Concrete Network Models Domain Hierarchy 31
Domain Hierarchy Example
TUM i8 i20 CoffeeMachine TeaMachine
Wolfgang TUM-X Holger TUM-i8-X Heiko TUM-i8-X CoffeeMachine TUM-i8-CoffeeMachine-X Jonas TUM-i20-X TeaMachine TUM-i8-T eaMachine-X
unchen) Concrete Network Models Domain Hierarchy 31
Domain Hierarchy Analysis
Network Model: The default parameter is unique and secure according to the definition (formal proof in svn) Model is valid without configuration Bottom (⊥) and top (X) element exist For any two elements: a greatest lower and least upper bound exists domainName hierarchy with ≤ relation is a lattice Lattice structure already proposed by Denning [Den76] as structure for security classes = ⇒ supports the consistency of this model
unchen) Concrete Network Models Domain Hierarchy 32
SubnetsInGW
Member, InboundGateway, Unassigned
⊥ : subnets ⊥ ≡ Unassigned eval model (G : graph, nP : vertices ⇒ subnets, gP : ‘b) eval model G nP gP ≡ ∀(e1, e2) ∈ edges G. allowed subnet flow (nP e1) (nP e2) allowed subnet flow (p1 : subnets, p2 : subnets) p1 p2 result Member True InboundGateway True Unassigned Unassigned True Unassigned InboundGateway True Unassigned Member False
unchen) Concrete Network Models SubnetsInGW 33
SubnetsInGW Example
DMZfirewall ⊥ InboundGateway PublicHTTP ⊥ Member Workstation1 Member Member Google ⊥ ⊥ Workstation2 Member Member Customer1 ⊥ ⊥ Customer2 ⊥ ⊥
unchen) Concrete Network Models SubnetsInGW 34
SubnetsInGW Example
DMZfirewall ⊥ InboundGateway PublicHTTP ⊥ Member Workstation1 Member Member Google ⊥ ⊥ Workstation2 Member Member Customer1 ⊥ ⊥ Customer2 ⊥ ⊥
unchen) Concrete Network Models SubnetsInGW 34
unchen) Concrete Network Models Analysis 35
All Edges Normal Form – ENF
eval model common structure ∀(e1, e2) ∈ (edges G). P (nP e1) (nP e2) Offending Flows: List of flows which violate P
Linear Time Algorithm Unambiguous Verifies Axioms
else {{(e1, e2). (e1, e2) ∈ (edges G) ∧ ¬P (nP e1) (nP e2)}} Secure Default Parameter (target focus): ¬ P (nP e1) (nP e2) = ⇒ ¬ P (nP e1) ⊥
unchen) Concrete Network Models Analysis 36
unchen) Implementation 37
Implementation
Code Export Java Virtual Machine Network Security Modelling T
Core Logic verified Mathematical Theory Proofs Formalism
λ → ∀
=
Is a be lle
β α
H O L
External Libraries JSON Graphviz ... Compile
GraphViz: Visual feedback Interactive command line tool OpenVPN + iptables export
unchen) Implementation 38
Implementation
Java Virtual Machine
Core Logic verified External Libraries JSON Graphviz ... Network Security Modelling T
security_requirements.json Verify Debug Visualize
GraphViz: Visual feedback Interactive command line tool OpenVPN + iptables export
unchen) Implementation 38
Real world usage?
unchen) Evaluation 39
unchen) Evaluation 40
EADS: Cabin Data Network
ETH
End D evice End D evice End D evice PAX WLAN S witch S erver S atellite Gateway Ethernet S witch S witch S witch PS U PS U Access Point
ETH ETH
End D evice End D evice End D evice
ETH ETH ETH ETH ETH ETH
S witch
ETH ETH
Mobile D evice POD POD POD Gateway
ETH ETH
Upper D
ain(AC D&AIS D ) Lower D
ain(PIES D&POD D ) AR INC653 Partition S witch
ETH ETH ETH ETH ETH
End D evice End D evice AR INC653 Partition AR INC653 Partition S erver AR INC653 Partition AR INC653 Partition AR INC653 Partition S erver
ETH– Ethernet PAX– Passeng er POD– Passeng er OwnedD evice
Figure: Sample topology of the cabin data network [Han12, Figure 1]
unchen) Evaluation Cabin Data Network 41
EADS: Security Requirements
Figure: Security Requirements Document [Han12, 2.3 Topology]
unchen) Evaluation Cabin Data Network 42
EADS: Security Requirements
Figure: Our Security Requirements Document
unchen) Evaluation Cabin Data Network 43
EADS: Security Requirements
Figure: Our translated Security Requirements Document
1 DomainHierarchyTE, 3 SubnetsInGW, 4 SecurityGatewayExtended, 2 BLPtrusted
unchen) Evaluation Cabin Data Network 44
Example Model Configuration File
{" model_type": " SubnetsInGW ", " model_description ": "Lower Server and PAXwlan Subnet", " model_breach_severity ": 5, " model_params ":{ " node_properties ": [ {"node":" LowerPAXwlan ", " member_type ":" InboundGateway "}, {"node":" LowerServer ", " member_type ":"Member"}, {"node":"IFEdevice1", " member_type ":"Member"}, {"node":"IFEdevice2", " member_type ":"Member"}, {"node":" SatGwPIESD ", " member_type ":"Member"}, {"node":"SatGwPODD", " member_type ":"Member"}, {"node":"Gateway", " member_type ":" InboundGateway "} ], " global_properties ": null } }
unchen) Evaluation Cabin Data Network 45
Our Proposed Topology
SatelliteGateway UpperServerACD UpperServerAISD ACDendDev SatGwAISD 1) ACD-AISD 2) Member 5) privacy: 1 SatGwPIESD 1) ACD-AISD-PIESD 7) Member 8) SecurityGateway 9) privacy: 1 SatGwPODD 1) ACD-AISD-PIESD-PODD 7) Member UpperServerACD 1) ACD 2) Member 3) SecurityGatewayIN 4) SecurityGatewayIN 5) privacy: 1 !trusted! 6) InboundGateway UpperServerAISD 1) ACD-AISD 2) Member 3) SecurityGatewayIN 4) SecurityGatewayIN 5) privacy: 1 !trusted! 6) InboundGateway LightControlAPP 1) ACD-AISD 2) Member 4) DomainMember 5) privacy: 1 AnnouncementAPP 1) ACD-AISD 2) Member 4) DomainMember 5) privacy: 1 AnnouncementSpeakers 1) ACD 2) Member 3) DomainMember 5) privacy: 2 SmokeDetector 1) ACD 2) Member 3) DomainMember 5) privacy: 2 AirCon 1) ACD 2) Member 3) DomainMember 5) privacy: 2 CrewDisplay1 1) ACD-AISD 2) Member 3) DomainMember 5) privacy: 2 CrewDisplay2 1) ACD-AISD 2) Member 3) DomainMember 5) privacy: 2 CrewTelecomDevice1 1) ACD-AISD 2) Member 3) DomainMember 5) privacy: 2 CrewTelecomDevice2 1) ACD-AISD 2) Member 3) DomainMember 5) privacy: 2 Gateway 1) ACD-AISD-PIESD trust: 1 2) InboundGateway 5) privacy: 0 !trusted! 6) Member 7) InboundGateway Light 1) ACD-AISD 2) Member 3) DomainMember 5) privacy: 2 AircraftControlApp 1) ACD 2) Member 4) DomainMember 5) privacy: 1 TelecomApp 1) ACD 2) Member 4) DomainMember 5) privacy: 1 LowerServer 1) ACD-AISD-PIESD 6) InboundGateway 7) Member 8) SecurityGatewayIN 9) privacy: 0 !trusted! LowerPAXwlan 1) ACD-AISD-PIESD-PODD trust: 1 7) InboundGateway 10) SecurityGatewayIN IFEdevice1 1) ACD-AISD-PIESD 7) Member 8) DomainMember 9) privacy: 1 IFEdevice2 1) ACD-AISD-PIESD 7) Member 8) DomainMember 9) privacy: 1 LowerPOD1 1) ACD-AISD-PIESD-PODD 10) DomainMember LowerPOD2 1) ACD-AISD-PIESD-PODD 10) DomainMemberunchen) Evaluation Cabin Data Network 46
Evaluation: Coverage of Use Cases
To From Upper End D. Upper Server
bile D. Lower POD Lower End D. Lower Server Sat GW Upper End D. – T1, T2 – – – T1 – Upper Server T1, T2 T1, T2 T2 – – T2 T2
bile D. – T1, T2 – – – T2 – Lower POD – T1 – – – T1, T2 T1, T2 Lower End D. – T1 – – – T1, T2 T1, T2 Lower Server – T2 – T2 T2 – T2 SAT GW – T2 – T1, T2 T1, T2 T2 –
Original access matrix [Han12, Table 2]. “Traffic flows within the cabin data network. Traffic Type 1 (T1) stands for stream traffic and T2 for status updates”.
unchen) Evaluation Cabin Data Network 47
Evaluation: Coverage of Use Cases
To From Upper End D. Upper Server
bile D. Lower POD Lower End D. Lower Server Sat GW Upper End D. – dom – – – GW →
– Upper Server dom dom dom – – GW yes
bile D. – dom – – – GW →
– Lower POD – GW → PAX – – – PAX PAX Lower End D. – GW →
– – – yes yes Lower Server – GW – PAX yes – yes SAT GW – yes – PAX yes yes –
Our access matrix.
unchen) Evaluation Cabin Data Network 47
Maximal Topology
1 A maximal topology is a valid graph which fulfills all security
2 Adding any edge to the graph violates at least one security
requirement. All models are unambiguous → the maximum topology
1 Start with the fully connected graph. 2 For all models, calculate the list of offending flows. By
assumption, this list is unambiguous.
3 Remove the offending flows from the graph. 4 Repeat until all models are valid.
unchen) Evaluation Cabin Data Network 48
Evaluation: Strictness of Security Requirements
strictness = | edges Gcurrent | | edges Gmaximal |
Only additional flows to satellite uplink, no negative security implications
SatelliteGateway UpperServerACD UpperServerAISD ACDdev SatGwAISD 1) ACD-AISD 2) Member 5) 1 SatGwPIESD 1) ACD-AISD-PIESD 7) Member 8) SecurityGateway 9) 1 SatGwPODD 1) ACD-AISD-PIESD-PODD 7) Member UpperServerACD 1) ACD 2) Member 3) SecurityGatewayIN 4) SecurityGatewayIN 5) 1 !trusted! 6) InboundGateway UpperServerAISD 1) ACD-AISD 2) Member 3) SecurityGatewayIN 4) SecurityGatewayIN 5) 1 !trusted! 6) InboundGateway LightControlAPP 1) ACD-AISD 2) Member 4) DomainMember 5) 1 AnnouncementAPP 1) ACD-AISD 2) Member 4) DomainMember 5) 1 AnnouncementSpeakers 1) ACD 2) Member 3) DomainMember 5) 2 SmokeDetector 1) ACD 2) Member 3) DomainMember 5) 2 AirCon 1) ACD 2) Member 3) DomainMember 5) 2 CrewDisplay1 1) ACD-AISD 2) Member 3) DomainMember 5) 2 CrewDisplay2 1) ACD-AISD 2) Member 3) DomainMember 5) 2 CrewTelecomDevice1 1) ACD-AISD 2) Member 3) DomainMember 5) 2 CrewTelecomDevice2 1) ACD-AISD 2) Member 3) DomainMember 5) 2 Gateway 1) ACD-AISD-PIESD trust: 1 2) InboundGateway 5) 0 !trusted! 6) Member 7) InboundGateway Light 1) ACD-AISD 2) Member 3) DomainMember 5) 2 AircraftControlApp 1) ACD 2) Member 4) DomainMember 5) 1 TelecomApp 1) ACD 2) Member 4) DomainMember 5) 1 LowerServer 1) ACD-AISD-PIESD 6) InboundGateway 7) Member 8) SecurityGatewayIN 9) 0 !trusted! LowerPAXwlan 1) ACD-AISD-PIESD-PODD trust: 1 7) InboundGateway 10) SecurityGatewayIN IFEdevice1 1) ACD-AISD-PIESD 7) Member 8) DomainMember 9) 1 IFEdevice2 1) ACD-AISD-PIESD 7) Member 8) DomainMember 9) 1 LowerPOD1 1) ACD-AISD-PIESD-PODD 10) DomainMember LowerPOD2 1) ACD-AISD-PIESD-PODD 10) DomainMemberunchen) Evaluation Cabin Data Network 49
unchen) Conclusion 50
Conclusion
A formal approach to conquer network security configuration management
Mechanisms Policy Requirements
Evaluation security requirements / specification Tool support
Graphical feedback High-level language → model configuration Modular → scales Usability by design Debugging Automated topology generation
unchen) Conclusion 51
Conclusion
Real world application Isabelle rocks A formal approach to do usable stuff for the real world
unchen) Conclusion 52
References I
E.S. Al-Shaer and H.H. Hamed. Discovery of policy anomalies in distributed firewalls. In INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, volume 4, pages 2605 – 2616 vol.4, 3 2004.
What is computer security? Security & Privacy, IEEE, 1(1):67–69, 2 2003.
A role model to cope with the complexity of network configuration. INOC, 4 2007.
unchen) Conclusion 53
References II
Niklas Broberg and David Sands. Flow-sensitive semantics for dynamic information flow policies. In Proceedings of the ACM SIGPLAN Fourth Workshop on Programming Languages and Analysis for Security, PLAS ’09, pages 101–112. ACM, 2009. Dorothy Elizabeth Robling Denning. Secure information flow in computer systems. PhD thesis, Purdue University, West Lafayette, IN, USA, 1975. AAI7600514. D.E. Denning. A lattice model of secure information flow. Communications of the ACM, 19(5):236–243, 5 1976.
unchen) Conclusion 54
References III
Claudia Eckert. IT-Sicherheit: Konzepte-Verfahren-Protokolle. Number 7., ¨ uberarbeitete und erweiterte Auflage. Oldenbourg Verlag, Rosenheimer Straße 145, D-81671 M¨ unchen, 2012. S.N. Foley. A taxonomy for information flow policies and models. In Research in Security and Privacy, 1991. Proceedings., 1991 IEEE Computer Society Symposium on, pages 98 –108, 5 1991. Joshua D. Guttman and Amy L. Herzog. Rigorous automated network security management. International Journal of Information Security, 4:29–48, 2005.
unchen) Conclusion 55
References IV
Security policies and security models. In Proceedings of the 1982 IEEE Symposium on Security and Privacy, pages 11–20, 4 1982. Oliver Hanka. Cabin data network scenario. internal, 5 2012. EADS, Version 1.0.
Taxonomy of conflicts in network security policies. Communications Magazine, IEEE, 44(3):134 – 141, 3 2006.
unchen) Conclusion 56
References V
On the composition of secure systems. In Security and Privacy, 2002. Proceedings. 2002 IEEE Symposium on, pages 88 – 101, 2002.
A hookup theorem for multilevel security. Software Engineering, IEEE Transactions on, 16(6):563 –568, 6 1990.
Security models and information flow. In Research in Security and Privacy, 1990. Proceedings., 1990 IEEE Computer Society Symposium on, pages 180–187. Ieee, 1990.
unchen) Conclusion 57
References VI
Florian Mansmann, Timo G¨
Visual analysis of complex firewall configurations. In Proceedings of the Ninth International Symposium on Visualization for Cyber Security, VizSec ’12, pages 1–8. ACM, 2012. Andrew C. Myers and Barbara Liskov. A decentralized model for information flow control. SIGOPS Oper. Syst. Rev., 31(5):129–142, 10 1997. Andrew C. Myers and Barbara Liskov. A decentralized model for information flow control. In Proceedings of the sixteenth ACM symposium on Operating systems principles, SOSP ’97, pages 129–142. ACM, 1997.
unchen) Conclusion 58
References VII
Csp-based firewall rule set diagnosis using security policies. Availability, Reliability and Security, International Conference
R.W. Ritchey and P . Ammann. Using model checking to analyze network vulnerabilities. In Security and Privacy, 2000. S P 2000. Proceedings. 2000 IEEE Symposium on, pages 156 –165, 2000. John Rushby. Noninterference, transitivity, and channel-control security policies. Technical report, 12 1992.
unchen) Conclusion 59
References VIII
A model of information. In Proceedings of the 9th National Computer Security Conference, pages 175–183, 9 1986. Ulrich Ultes-Nitsche, Dominik Jungo, and David Buchmann. Verinec – Verified Network Configuration. https://diuf.unifr.ch/drupal/tns/Verinec.
August. Rifle: An architectural framework for user-centric information-flow security. In Microarchitecture, 2004. MICRO-37 2004. 37th International Symposium on, pages 243 – 254, 12 2004.
unchen) Conclusion 60
References IX
A quantitative study of firewall configuration errors. Computer, IEEE, 37(6):62 – 67, 6 2004. Lihua Yuan, Hao Chen, Jianning Mai, Chen-Nee Chuah, Zhendong Su, and P . Mohapatra. Fireman: a toolkit for firewall modeling and analysis. In Security and Privacy, 2006 IEEE Symposium on, pages 15
unchen) Conclusion 61
Finally, one beautiful picture
S a t G w A I S D S a t G w P I E S D S a t G w P O D D U p p e r S e r v e r A C D A i r c r a f t C o n t r o l A p p T e l e c o m A p p L i g h t C o n t r o l A P P A n n o u n c e m e n t A P P A n n o u n c e m e n t S p e a k e r s S m o k e D e t e c t o r A i r C o n C r e w D i s p l a y 1 C r e w D i s p l a y 2 C r e w T e l e c o m D e v i c e 1 C r e w T e l e c o m D e v i c e 2 G a t e w a y L o w e r S e r v e r L o w e r P A X w l a n L o w e r P O D 1 L o w e r P O D 2 I F E d e v i c e 1 I F E d e v i c e 2 L i g h t U p p e r S e r v e r A I S Dunchen) NIDS Configuration 62
Automated NIDS Configuration Generation
IFEdevice2 IFEdevice1 SatGwPIESD LowerPOD2 LowerPOD1 SatGwPODD LowerPAXwlan LowerServer Light CrewTelecomDevice2 CrewTelecomDevice1 CrewDisplay2 CrewDisplay1 SatGwAISD AnnouncementAPP LightControlAPP AirCon SmokeDetector AnnouncementSpeakers UpperServerAISD TelecomApp AircraftControlApp UpperServerACD Gateway 100 200 300 400 500 600 700 Accumulated Breach Rating
Accumulated security breach ratings per device of the cabin data network
unchen) NIDS Configuration 63
Thanks for your attention!
unchen) Thank You! 64