fsl: a flow-based security language tim hinrichs natasha gude martìn casado john mitchell scott...

36
FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Nicira Networks Stanford University UC Berkeley

Upload: asher-gilmore

Post on 12-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

FSL:A Flow-based Security Language

Tim HinrichsNatasha GudeMartìn CasadoJohn MitchellScott Shenker

University of ChicagoNicira NetworksNicira NetworksStanford UniversityUC Berkeley

Page 2: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Local Area Networks

Page 3: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Network Policy Examples

“Every wireless guest user must send HTTP requests through an HTTP proxy.”

“No phone can communicate with any private computer.”

“Superusers have no communication restrictions.”

“Laptops cannot receive incoming connections.”

Page 4: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

NOX: a Network Architecture(Ethane’s successor)

NetworkView

NetworkView

App 1App 1

App 2App 2

App 3App 3

OF Switch

OF SwitchWirelessOF Switch

NOX ControllerNOX Controller

PC

Off-the-shelfhosts

See [Gude2008]

Page 5: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

NOX Operation

Page 6: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

NOX Operation

SECURITYPOLICY

Page 7: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

NOX Operation

Page 8: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

FSL

FSL: Flow Security Language

FSL balances the desires to makeexpressing network policies natural and implementing policies efficient.

Page 9: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

A Datalog Variant

Syntaxh :- b1,…,bn,c1,…,cm

• h must exist.• Every variable in the body must appear in h. • Nonrecursive sentence sets.

Semantics– Statement order is irrelevant.– Every sentence set is satisfied by exactly one model.

Page 10: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Network Flows

Keywords for constraining flow route: • allow: allow the flow• deny: deny the flow• visit: force the flow to pass through an intermediary• avoid: forbid the flow from passing through an intermediary• ratelimit: limit on Mb/second

•User source•Host source•Access point source

•User target•Host target•Access point target

•Protocol

Page 11: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Keyword: deny

“No phone can communicate with any private computer.”

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-phone(Hsrc) , private(Htgt)

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-private(Hsrc) , phone(Htgt)

private(X) :- laptop(X)

private(X) :- desktop(X)

Page 12: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Keyword: visit

“Every wireless guest user must send HTTP requests through a proxy.”

visit(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot,httpproxy) :-guest(Usrc) , wireless(Asrc) , Prot=http

Page 13: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Operation

Given FSL policy and flow <us,hs,as,ut,ht,at,p>, ask

|= deny(us,hs,as,ut,ht,at,p)

|= allow(us,hs,as,ut,ht,at,p)

{X | |= visit(us,hs,as,ut,ht,at,p,X)}

{X | |= avoid(us,hs,as,ut,ht,at,p,X)}

{X | |= ratelimit(us,hs,as,ut,ht,at,p,X)}

Page 14: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

FSL Complexity

Query processing is PSPACE-complete in the size of the policy for an arbitrary query.

When queries are restricted to keywords, query processing takes polynomial time in the size of the policy.

If the tallest possible call stack (path through the dependency graph) is 1, then query processing takes linear time in the size of the policy.

Page 15: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Compilation Example

“No phone can communicate with any private computer.”

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-phone(Hsrc) , private(Htgt)

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-private(Hsrc) , phone(Htgt)

private(X) :- laptop(X)

private(X) :- desktop(X)

Page 16: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Compilation Example

bool deny (Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) {

return (phone(Hsrc) && private(Htgt)) ||

(private(Hsrc) && phone(Htgt));}

bool private(X) {return laptop(X) || desktop(X);

}

Assume the existence of functions for phone, laptop, desktop.

Page 17: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Deployment Experiences

• On a small internal network (about 50 hosts), NOX has been in use over a year, and FSL has been in use for 10 months.

• We are preparing for two larger deployments (of hundreds and thousands of hosts).

• So far, policies are expressed over just a few classes of objects. Thus, we expect policies to grow slowly with the

number of principals.

Page 18: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Questions

Page 19: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

[Gude2008] N. Gude, et. al. NOX: Towards an Operating System for Networks. Computer Communications Review 2008.

[Hinrichs2009] T. Hinrichs, et. al. Design and Implementation of a Flow-based Security Language. Under review. Available upon request.

References

Page 20: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Related Work ComparisonLimitations• Not using FOL, Modal logic, Linear logic• No existential variables• No recursion• Fixed conflict resolution scheme• No delegation• No history/future-dependent policies• Centralized enforcement• Limited metalevel operations

Novel language features• Access control decisions are constraints.• Conflict resolution produces constraint set

For citations, see [Hinrichs2009].

Page 21: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Backup

Page 22: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

FSL Features

• Logical language: Distributed policy authorship• External references• Conflicts, conflict detection, conflict resolution• Incremental policy authorship via priorities• Analyzability• High Performance: 104-105 queries/second

Layered language:

Logic Data

Keywords

Conflicts

Prioritization

Page 23: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Conflicts

Conflicts are vital in collaborative settings because they allow administrators to express their true intentions.

Authorization systems cannot enforce conflicting security policies.

denyavoid

visitallow

ratelimit

denyavoidvisitallowratelimit

Page 24: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

FSL Usage Overview

CombinedPolicy

AnalysisEngine

AuthorizationSystem

Policy1

Policyn

Page 25: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Conflict Resolution

• No conflicts: conflicts are errors.

• Most restrictive: choose instructions that give users the least rights.

• Most permissive: choose policy instructions that give users the most rights.

• Cancellation: a flow with conflicting constraints has no constraints.

Page 26: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Conflict Resolution as a Tool

Fixing the conflict resolution mechanism allows certain policies to be expressed very simply.

Example (Open Policy): allow everything not explicitly denied.

allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot)

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-

phone(Hsrc) , private(Htgt)deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-

private(Hsrc) , phone(Htgt)

Page 27: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Incremental Policy Authoring

To tighten a FSL policy, one needs only to add statements to it.

The conflict resolution strategy ensures that the most restrictive constraints are used.

To relax a FSL policy, it is therefore insufficient to simply add statements.

Page 28: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Prioritized Policies

Borrow a mechanism from Cascading Style Sheets (CSS).

To relax security incrementally, FSL allows one policy to be overridden by another policy.

P1 < P2

A request constrained by P2 is only constrained by P2.

Page 29: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Example

P1

P2

allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) Usrc=ceo

allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :- superuser(Usrc)

superuser(bob)superuser(alice)deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :- phone(Hsrc) , private(Htgt)

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :- private(Hsrc) , phone(Htgt)

private(X) :- laptop(X)private(X) :- desktop(X)

visit(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot,httpproxy) :- guest(Usrc) , wireless(Asrc) , Prot=http

allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,ssh) :- guest(Usrc) , server(Htgt)

Page 30: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Cascaded Policy Combination

Combined Policy

Policy1,1

Policy1,2

Policy1,m1…

Policyn,1

Policyn,2

Policyn,mn…

Page 31: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Cascaded Policy Combination

Combined Policy

Policy1

Policyn

1. Flatten cascades.2. Combine results.

Page 32: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Features

• Distributed policy authorship• External references• Conflict detection/resolution• Incremental policy authorship via priorities• Analyzability• High Performance: 104 queries/second

Layered language:

Logic Data

Keywords

Conflict Resolution

Prioritization

Page 33: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Analysis Algorithms

Flattened Cascade: a policy cascade expressed as a flat policy.

Group Normal Form: every rule body consists only of external references (and =).

Conflict Conditions: conditions on external references under which there will be a conflict.

Conflict-free Normal Form: equivalent policy (under conflict resolution) without conflicts.

Page 34: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

10-5 seconds

true && false 2.7 x 10-9

function f (x y) (x && y)) f(true,false) 3.8 x 10-8

equalp (“mary had a little lamb”, “Mary Had A Little Lamb”)

2.1 x 10-6

samep (p(X,Y,X,a), p(Z,T,Z,a)) 6.7 x 10-6

matchp (p(X,Y,X,a), p(b,c,b,a)) 7.3 x 10-6

mgup (p(X,c,X,a), p(b,T,Z,a)) 1.3 x 10-5

unifyp (p(X,c,X,a), p(b,T,Z,a)) 2.7 x 10-5

Operation Avg. Seconds

Page 35: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Implementation Tests

Flows/s Mem (MB)

Rule Matches

0 rules 103,699 0 0

100 rules 100,942 1 2

500 rules 85,373 1 4

1,000 rules 76,336 2 10

5,000 rules 54,416 9 30

10,000 rules 46,956 38 52

Page 36: FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford

Ongoing Work

Currently, each flow initiation requires contacting a central controller.

The route for that flow is cached at the router.

Working to generalize this caching scheme. Each trip to the central controller caches more than

just the route for one flow.