# ISA 562 Information System Security

## Presentation on theme: "ISA 562 Information System Security"— Presentation transcript:

ISA 562 Information System Security
Confidentiality Policies Chapter 5 from Bishop’s Book

Overview Review and background Bell-LaPadula (BLP) Policy Tranquility
Review - lattices Military systems and Denning’s Axioms Bell-LaPadula (BLP) Policy Step 1 – clearance/classification Step 2 – categories Example System – DG/UX Tranquility Controversy

Definition: POset A Poset (Partially ordered set) is a pair (A,<) where A is a set < is a partial order. Thus < is: reflexive: x<x for xeA transitive: x<y and y<z x<z for all x,y,zeA anti-symmetric: x<y and y<x x=y for all x,yeA Example: A B C D E < is a total order iff x<y x,yeA A B C

Upper and Lower Bounds of POsets
Definition: (A,<) is a POset and B  A beA is an upper bound of B iff x<b xeB ceA is a lower bound of B iff c<x xeB The upper bound b B1, B2, B3 B4 B5 B6 The set B The lower bound c

Supremas and Infimas of POsets
Definition: (A,<) is a POset and B  A b0eA is a Least upper bound (aka Supremum) of B iff (1) b0 is an upper bound and (2) b0<b for all other upper bounds b of B b1,b2, b3 b0 c0eA is a greatest lower bound (Infimum) iff c0 is an upper bound c0<b for all other lower bounds c of B Upper bounds B1, B2, B3 B4 B5 B6 The set B c0 c2, c3, c4 Lower bounds

Semi-lattices and Lattices
An upper semi-lattice is a POset in which every finite subset has a Supremum Notation: Join = /\ A lower semi-lattice is a POset in which every finite subset has an Infimum Notation: Meet = \/ A lattice is a POset that has an upper semi lattice and a lower semi lattice.

Example Lattices – Power Set Lattice
S = {a,b,c} 2S = { ,{a},{b},{c},{a,b},{b,c},{a,c},{a,b,c} } Arrows mean  (informally, included by) Special case: Total order Partial order Special case: Lattice

Product Lattices Let (L1, <1, /\1, \/1) and
(L2, <2, /\2, \/2) be two lattices. Then the product lattice is defined as: (L,<,/\,\/) where: L = L1 x L2 That is L ={(x,y): xeL1 and yeL2} (x,y) < (a,b) iff x <1 a and y <2 b

Example Product Lattice
(arrow means ) Lattice 2 (arrow means ) Lattice 2  Lattice 1 x,y < x’,y’ means y’  y and x  x’

Military-style system
Confidentiality is most important Integrity/availability important but incidental Users have clearance / files are classified [labeled] Naturally MAC-centric All information is locked in the system Asssumes: You won’t memorize something and go outside to tell others Disclosure is only possible within the system

Military-style system (Cont.)
Denning’s Axioms Security classes (clearance and classification) form a lattice Information can flow dominate

Information Flow When x reads y, information flows from y to x
When x writes y, information flows from x to y

Overview Review and background Bell-LaPadula (BLP) Policy Tranquility
Lattices Military systems and Denning’s Axioms Bell-LaPadula (BLP) Policy Step 1 – clearance/classification Step 2 – categories Example System – DG/UX Tranquility Controversy at a glance

The Bell-LaPadula Policy: The Preliminary Version
Security levels are linearly ordered (L) Top Secret: highest Secret Confidential Unclassified: lowest Subjects and Objects assigned a level in the linear order Subject: Levels are called security clearance L (s) Object: Levels are called security classification L (o) Formally they are mapping into L: Ls: Subjects  L Lo: Subjects  L

An Example security level subject object Top Secret Tamara
Personnel Files Secret Samuel Files Confidential Claire Activity Logs Unclassified Ulaley Telephone Lists Tamara can read all files Claire cannot read Personnel or Files Ulaley can only read Telephone Lists

The Simple Security Property: The Preliminary version
Simple Security Property: Subject s can read object o iff, L(o) ≤ L(s) Information flows up, not down “Read up” not allowed, “read down” allowed Sometimes called “no read up” rule Why?: Otherwise subject can get information above their level Discretionary control may also be present

The *-Property: Preliminary Version
Subject s can write object o iff L(s) ≤ L(o) “Write up” allowed, “write down” not allowed [“no write down” rule] Why? Cooperation between foreign agents [spies]

Not possible with *-property
What is Prevented? security level subject object Top Secret Tamara Personnel Files Secret Samuel Files Confidential Claire Activity Logs Unclassified Ulaley Telephone Lists Tamara reads personnel files of all spooks working in country X, and then writes them into activity log Claire reads activity log and sells it to country X [exit spooks] Not possible with *-property

The Basic Security Theorem: The Preliminary Version
If a system is initially in a secure state, and every transition of the system satisfies 1. the simple security condition, and 2. the *-property Then every state of the system is secure To state and prove this theorem formally: Need to formalize secure state Need to formalize state transition

The BLP Model: Final version
Expand notion of security level to include categories Based on the need to know principle Security level is (clearance, category set) Example: ( Top Secret, { NUC, EUR, ASI } ) ( Confidential, { EUR, ASI } ) ( Secret, { NUC, ASI } ) (unclassified {NUC})

Security Levels as a Product Lattice
(A, C) dom (A, C) iff A ≤ A and C  C Examples (Top Secret, {NUC, ASI}) dom (Secret, {NUC}) (Secret, {NUC, EUR}) dom (Confidential,{NUC, EUR}) (Top Secret, {NUC}) dom (Confidential, {EUR}) Let C be set of classifications, K set of categories. Set of security levels L = C  K, dom form lattice Levels are the product lattice

Levels and Ordering Security levels partially ordered
Any pair of security levels may (or may not) be related by dom “dominates” serves the role of “greater than” in step 1 “greater than” is a total ordering, though Total ordering is a special lattice

The Simple Security Property: The final Version
Simple Security Property: Subject s can read object o iff L (s) dom L (o) L(s) dom L(o) iff C(s) > C(o) and K(s) > K(o) Information flows up, not down “Read up” not allowed, “read down” allowed Sometimes called no read up rule

The *-Property: The Final Version
*-Property: Subject s can write object o iff L(s) dom L(o) Information flows up, not down “Write up” allowed, “write down” not allowed Sometimes called no write down rule

The Basic Security Theorem: The Final Version
If a system is initially in a secure state, and every transition of the system satisfies (1) the simple security condition, and (2) the *-property Then every state of the system is secure

Applying BLP: Example 1 Colonel has (Secret, {NUC, EUR}) clearance
Major has (Secret, {EUR}) clearance Major can talk to colonel (“write up” or “read down”) Colonel cannot talk to major (“read up” or “write down”) Interferes with functionality! Colonel is a user, and he can login with a different Id (as a different principle) with reduced clearance Alias1 (Secret, {NUC, EUR}) Alias2 (Secret, {EUR})

BLP: Problem If I can write up, then how about writing files with blanks? Blind writing up may cause integrity problems, but not a confidentiality breach

Key Points Confidentiality models restrict flow of information
Bell-LaPadula (BLP) models multilevel security Cornerstone of much work in computer security Simple security property says no read up and *-property says no write down Both ensure information can only flow up

DG/UX System A real (and well-regarded) Unix operating system by Data General Provides mandatory access controls MAC label identify security level Initially Subjects assigned MAC label of parent Initial label assigned to user, kept in Authorization and Authentication database Object assigned label at creation Explicit labels stored as (part of the set of) attributes Implicit labels determined from parent directory

MAC Regions A&A database , audit Administrati v e Re gion Hierarch y User data and applications User Re gion le v els VP1 Site e x ecutables T rusted data VP2 V irus Pre v ention Re gion VP3 Ex ecutables not part of the TCB VP4 Ex ecutables part of the TCB VP5 Reserv ed for future use Categories Admin region no write/read except by administrative process User cannot write to system programs but can read/execute

A Directory Problem Process p at MAC_A tries to create file /tmp/x
If /tmp/x exists but has MAC label MAC_B where MAC_B dom MAC_A Create must fail: Now p knows a file named x with a higher label exists LEAK! Solution: only programs with same MAC label as directory can create files in the directory If this was only way to create files, them /tmp would have problems. For example, compilation, mail won’t work Solution: Multi-level directory

DG B2-Multilevel Directory
Directory with a set of subdirectories, one per label Not normally visible to user p creating /tmp/x actually creates /tmp/d/x where d is directory corresponding to MAC_A All p’s references to /tmp go to /tmp/d p cd’s to /tmp/a, then to .. System call stat(“.”, &buf) returns inode number of real directory System call dg_stat(“.”, &buf) returns inode of /tmp

Using MAC Labels Simple security condition implemented
*-property not fully implemented Process MAC must equal object MAC Writing allowed only at same security level Overly restrictive in practice

Overview Review and background Bell-LaPadula (BLP) Policy Tranquility
Review - lattices Military systems and denning’s Axioms Bell-LaPadula (BLP) Policy Step 1 – clearance/classification Step 2 – categories Example System – DG/UX Tranquility Controversy at a glance

Principle of Tranquility
Raising object’s security level Information once available to some subjects is no longer available Usually assume information has already been accessed, so this does nothing Lowering object’s security level The declassification problem Essentially, a “write down” violating *-property Solution: define set of trusted subjects that sanitize or remove sensitive information before security level is lowered

Types of Tranquility Strong Tranquility Weak Tranquility
The clearances of subjects, and the classifications of objects, do not change during the lifetime of the system Weak Tranquility The clearances of subjects, and the classifications of objects, do not change in a way that violates the simple security condition or the *-property during the lifetime of the system Pros and Cons: Strong tranquility enforces MLS principles, but is inflexible Weak tranquility moderates restrictions

Example DG/UX System Only a trusted user (security administrator) can lower object’s security level In general, process MAC labels cannot change If a user wants a new MAC label, needs to initiate new process Cumbersome, so user can be designated as able to change process MAC label within a specified range

Controversy McLean: “value of the BLP is much overrated since there is a great deal more to security than it captures. Further, what is captured by the BST is so trivial that it is hard to imagine a realistic security model for which it does not hold.” given assumptions known to be non-secure, BST can prove a non-secure system to be secure He invented a completely reversed version of BLP, which is non-secure and yet self-consistent

Discussion The Basic Security Theorem show that obeying stated rules preserve security Key question: what is security? Bell-LaPadula defines it in terms of 3 properties (simple security condition, *-property, discretionary security property) Theorems are assertions about these properties Rules describe changes to a particular system instantiating the model Showing system is secure requires proving that rules preserve these 3 properties

Rules and Model Nature of rules is irrelevant to model
Model treats “security” as axiomatic Policy defines “security” This instantiates the model Policy reflects the requirements of the systems McLean’s definition differs from BLP and is not suitable for a confidentiality policy Analysts cannot prove “security” definition is appropriate through the model

What Is Modeling? Two types of models
Abstract physical phenomenon to fundamental properties Begin with axioms and construct a structure to examine the effects of the axioms BLP Model was developed as a model of the first type McLean assumed it was developed as a model of the second type

Towards Proving the Basic Security Theorem
System security state: (b,m,f,h) b e P(SxOxP): Rights that may be exercised m e M: AC Matrix of the current state f e F: Current subject and object clearances + categories h e H: Current hierarchy of objects R: Requests D = {y, n, I (illegal) e (error)} : outputs V: set of states W  R x D x V x V : set of runs RN, DN, VN : sequences of requests, answers, states S (R,D,W,z0): a run of the system

Example: State 1, and transition
L ={high, low}, K={all} S={s}, O={o}, P={r, w} For every f e F, fc(s)=(high,{all}) or (low,{all}) For every f e F, fo(o)=(high,{all}) or (low,{all}) Changes to S={s,s’}, (s’,w,o) e m1 Before writing s’ writing, b1 does not change

Example: processing requests
Suppose s’ requests r1 to write to o: succeed Transition from v0 to v1=(b2,m1,f1) where b2={(s,o,r),(s’,o,w)} so x=r1,y=yes,z-(vo,v1) S request r2, writing to o: denied, so x=(r1,r2) Y=(yes, no) Z=(v0,v1,v2) where v2=v1

The Simple Security Property
Simple Security Property: (s,o,p) e SxOxP satisfies the simple security property relative to f (written scc REL f ) iff P=e or p=a /* asking for empty or read */ R=r or p=w and fs(s) dom fo(o) /*asking for read or read/write and the subjects level dominates that of the object */

More notation A state satisfies the simple security condition if all elements of B satisfy the simple security condition Define b(s:p1,..,pn) the set of all objects that have access to p1,…pn. That is: b(s:p1,..,pn)={oeO| (s,o,p1)eb\/…\/(s,o,pn)eb}

The *- Property *-Property: (b,m,f,h) satisfy  seS
b(s:a)≠ø  oeO b(s:a) fo(o) dom fc(s) b(s:w)≠ø  oeO b(s:w) fo(o) = fc(s) b(s:r)≠ø  oeO b(s:r) fc(s) dom fo(s) Says: If a subject can write an object, then the objects classification dominates that of the subject clearance (write up) If a subject can also read then they must be the same If a subject can read then subject clearance must dominate objects classification