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 Modelling 1

Agenda Motivation & Introduction 1 Related Work 2 3 Abstract Network Security Model Definition Concrete Network Models 4 5 Implementation Evaluation 6 7 Conclusion Slides: 64 C. Diekmann (TU M¨ unchen) Network Security Modelling 2

Motivation & Introduction C. Diekmann (TU M¨ 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 Backup internal Intranet Firewall Fileserver Workstation Workstation Workstation Workstation C. Diekmann (TU M¨ 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 Workstation Workstation Firewall Intranet Workstation Backup internal Workstation Fileserver C. Diekmann (TU M¨ unchen) Motivation & Introduction Border Firewalls 4

Security Components – Bishop [Bis03] Requirements Policy Mechanisms Security Requirements Individual, scenario specific security needs e. g. Specified in requirements document e. g. Confidentiality of trade secrets in our database Security Policy How to achieve requirements e. g. Mechanism’s configuration e. g. Firewall rule set Security Mechanisms Enforce policy e. g. Firewall, VPN, ... C. Diekmann (TU M¨ unchen) Motivation & Introduction Security Components 5

Our Goals Requirements Policy Mechanisms 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 C. Diekmann (TU M¨ unchen) Motivation & Introduction Security Components 6

Related Work C. Diekmann (TU M¨ 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 e. g. I know all available exploits 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 C. Diekmann (TU M¨ 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 outside its networks since much sensitive business information 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] C. Diekmann (TU M¨ unchen) Related Work 9

The famous Bell LaPadula Model C. Diekmann (TU M¨ 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 C. Diekmann (TU M¨ unchen) Related Work Bell LaPadula 11

Bell LaPadula Example Host1 Host2 unclassified unclassified Host1 Host2 unclassified classified Host1 Host2 classified unclassified C. Diekmann (TU M¨ unchen) Related Work Bell LaPadula 12

Encoding Security Requirements Abstract Network Security Model Definition C. Diekmann (TU M¨ 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 ( G : graph , nP : vertices ⇒ ‘a , gP : ‘b ) : Bool eval model ( G : graph , nP : vertices ⇒ ‘a , gP : ‘b ) : Bool verify globals C. Diekmann (TU M¨ 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 . C. Diekmann (TU M¨ unchen) Abstract Network Security Model Definition 15

Security Prerequisites What is ⊥ ? C. Diekmann (TU M¨ 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 C. Diekmann (TU M¨ unchen) Abstract Network Security Model Definition Secure by Default 17

Taxonomy Host1 Host2 ? classified unclassified − → offending host Offending flow 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 C. Diekmann (TU M¨ 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 C. Diekmann (TU M¨ unchen) Abstract Network Security Model Definition Secure by Default 19

Host1 Host2 top secret secret Host1 Host2 top secret unclassified Secure Default Parameter Case model invalid ( eval model = False ) Some security violation exists Host1 Host2 classified unclassified C. Diekmann (TU M¨ unchen) Abstract Network Security Model Definition Secure by Default 20

Host1 Host2 top secret secret Host1 Host2 top secret unclassified Secure Default Parameter Case model invalid ( eval model = False ) Some security violation exists Host1 Host2 classified unclassified Offending flows → offending host ( target focus ) C. Diekmann (TU M¨ unchen) Abstract Network Security Model Definition Secure by Default 20

Secure Default Parameter Case model invalid ( eval model = False ) Some security violation exists Host1 Host2 classified unclassified Offending flows → offending host ( target focus ) Considering only validity and offending flows Host1 Host2 top secret secret Host1 Host2 top secret unclassified Replacing offending host’s configuration by ⊥ : removes no information Must never render model valid! C. Diekmann (TU M¨ 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. C. Diekmann (TU M¨ unchen) Abstract Network Security Model Definition Secure by Default 21