Access Control in Computing Systems

Access Control in Computing Systems Dr. Indrakshi Ray Colorado State University Email: [email protected] March 18, 2009

Mandatory Access Control Lattice Based Access Control Models Commercial Security Clark-Wilson Model Chinese Wall Model Role Based Access C

Access Control Models & Techniques

Access Control


who is trying to access a protected resource?

Authentication

Access Control Models

Authorization who should be allowed to access which protected resources?

Access Control Architectures

Enforcement how does the system enforce the specified authorization?

who should be allowed to change the access?

Dr. Indrakshi Ray, Colorado State University

2009 ISEA Appraisal Workshop, IIT Guwahati, March 19, 2009 – 3 / 218

Authorization


■

One of the most important techniques for computer security ◆

Often neglected

Process of expressing access policies in computer systems ■ Expressed in terms of subjects (active entities) accessing objects (passive as well as active entities) ■



Access Control Models


■

Discretionary Access Control ◆ ◆

■ ■ ■ ■ ■ ■

Access Matrix Models HRU and TAM

Mandatory Access Control Information Flow Model Chinese Wall Lippner’s Model Clark-Wilson Model Role-based Access Control




Discretionary Access Control

Discretionary Access Control (DAC)


■

Definition [Bishop p.53] If an individual user can set an access control mechanism to allow or deny access to an object, that mechanism is a discretionary access control (DAC), also called an identity-based access control (IBAC).



DAC (cont’d)


DAC policies govern the access of subjects to objects on the basis of subjects’ identity, objects identity and permissions ■ When an access request is submitted to the system, the access control mechanism verifies whether there is a permission authorizing the access ■ Such mechanisms are discretionary in that they allow subjects to grant other subjects authorization to access their objects at their discretion

■



Access Matrix Model


Simplest language for expressing authorizations ■ Proposed in 1971 by Lampson, Graham and Denning ■ A matrix is used to express the access rights that a subject has towards an object ■

◆

Each cell in the matrix contains an expression that represents the rights



Access Matrix Model (cont’d)


OBJECTS A

S U B J E C T S

U

B

D

r, w own

r, w

V

C

r

r, w

W w, own X

E

r


r, w r

w

r, w own


Implementing Access Matrix


■

Access Control Triples ◆

■

Capabilities ◆

■

Most popular in database systems Widely used in distributed systems

Access Control Lists (ACLs) ◆

Widely used in centralized systems



Access Control Triples



Subjects

Objects

A[s,o]

U

A

r, w

U

C

r, w, own

U

E

r

V

B

r, w

W

A

w, own

W

E

r, w

X

A

r

X

B

r

X

C

w

X

D

r, w, own


Access Control Triples (cont’d)


■

Advantages ◆

Useful in database management systems that incorporates powerful secondary storage management tools as well as very good search capabilities



Access Control Triples (cont’d)


■

Disadvantages ◆

Grows large very quickly ■

◆

The considered level of granularity for subjects and objects can cause this. For example, if we have a public file that is world readable and writable, then the table contains two triples (r, w) for each subject

It may not be convenient to keep a whole authorization table in main memory because there may be many inactive subjects / objects



Capabilities


Store the access matrix by rows ■ With each subject Si in the access matrix a list of pairs is associated for each object Oj , such that A[Si , Oj ] is not null ■

◆

Each element of the list indicates an object and the privileges held by the subject on that object



Capabilities


A

r, w

C

r, w, own

E

r

B

r, w

A

w, own

E

r, w

A

r

B

r

C

w

D

r, w, own

U V W X



Capabilities


■

Advantages ◆

Easy to maintain and query system on a per subject basis ■

■

For example, it is easy to find what are all the objects that a particular subject has access to When a new subject is introduced in the system, we need to add only one entry corresponding to that subject



Capabilities


■

Disadvantages ◆ ◆

It is difficult to compute the set of subjects that have access right on a given object If an object is removed from the system, then the revocation of rights is time consuming; similarly if a new object is created, granting of rights is time consuming



Capabilities


Useful in distributed systems where objects are remotely located ■ Can be efficiently implemented using message passing techniques ■



Access Control Lists


Storing the access matric by columns ■ With each object Oj , a list of pairs is stored for each subject Si , such that A[Si , Oj ] is not null ■

◆

This is the Unix style





U

r, w

W

w, own

X

r

V

r, w

X

r

U

r, w, own

X

w

X

r, w, own

U

r

W

r, w

A B C D E





■

Advantages ◆

Easy to maintain and query the system on a per object basis ■

■

For example, all subjects granted access to a particular object can be easily found If an object is deleted, it suffices to delete only one entry in the system to reflect the change





■

Disadvantages ◆ ◆

It is difficult to compute the set of objects that a given subject can access Granting and revocation of rights on a per subject basis is difficult





Useful in centralized systems where all objects are co-located ■ Useful if the number of subjects is fairly static

■



Limitation of Access Control Matrix Model Mandatory Access Control Lattice Based Access Control Models Commercial Security Clark-Wilson Model Chinese Wall Model Role Based Access C ■

The Access Matrix Model is not dynamic ◆ ◆ ◆

■

No transfer of access right from one subject to another No changing of access rights No creation or deletion of subjects or objects

Authorization system = Authorization policies + How to change them ◆

Safety



Propagation of Access


Unrestricted Discretion

OBJECTS A

S U B J E C T S

U

B

r, w

W w, own X


r

D

r, w own

r, w

V

C

r

w, own r, w

r

E

w

r, w r, w own


Unrestricted Discretion


If a subject U has ownership (own) right on an object C, then U can confer any right on object C to any other subject, say V, including ownership right. ■ If V gets ownership right from U then V, in turn, can confer any right on object C to itself and to any other subject, say W. ■

◆

W, in turn, can do the same. Thus the right on C is propagated without restriction.





Constrained Discretion - Copy Flag

OBJECTS A

S U B J E C T S

U

B

r, w

W w, own X


r

D

rc, r own

r, w

V

C

r

rc r

r

E

w

r, w r, w own


Constrained Discretion - Copy Flag


If a subject U has a read-copy (rc) right on an object C, and U has ownership right on C, then U can confer the read-copy right on object C to any other subject, say V. ■ V, in turn, can then confer the read right on C to any other subject, say W. However, V cannot propagate the read-copy right to W. Thus W is prevented from propagating the access right on object C, any further. ■





Constrained Discretion - Grant Flag

OBJECTS A

S U B J E C T S

U

B

r, w

V

C

D

E

rc, r own

g

r

r, w

r, w

W w, own X


r

r, w r

w

r, w own


Constrained Discretion - Grant Flag


If a subject U has a grant (g) right on any object D, then U can confer any other right on object D to another subject V, except the ownership right and grant right. ■ Depending on the right acquired by V, it can, in turn, propagate a right further to other subjects. ■




HRU Model of Authorization System

HRU Model for Authorization Systems


■

Objective ◆ ◆

■

We want to be able to specify the dynamic propagation of access rights We want to be able to analyze the protection scheme provided by the system under the dynamic nature of the system

M.Harrison, W. Ruzzo, J. Ullman. Protection in Operating Systems, Comm. of ACM 19(8), August 1976 ◆

Introduces the concepts of authorization systems and safety of such systems



HRU Model - Protection System


■

Consists of ◆

An initial access matrix ■

◆ ◆

The initial state

A finite set of HRU commands expressed as a program that operates on the access matrix We call this the Protection Scheme / Authorization Scheme / Protection System / Authorization System



HRU Model


At any time the access matrix gives the set of access rights subjects have to objects in the system ■ The access matrix changes by the execution of authorized HRU commands as autonomously invoked by subjects ■



HRU Program




HRU Characteristics


■

The HRU program is executed only when the condition is satisfied ◆ ◆

■

condition = conjunction of tests test = presence of right in cell of access matrix

HRU commands cannot test for the absence of rights ◆

Mutually exclusive rights cannot be modeled where one right is the complement of the other

Does not specify who initiates the command ■ The initial access matrix can be an empty matrix ■



HRU Example




Another HRU Example




HRU Cases


General Mono-conditional Bi-conditional Mono-operational No creation No subject creation Monotonic


no restrictions condition part has only one term condition part has at most two terms command body has only one primitive operation no create primitive operation in command body objects can be created but not subjects no delete operation


HRU Model - Safety Problem


■

An access matrix M leaks the right r if there is a command C : M −→ M ′

that adds the right r in a cell of M that did not previously contain r ■ An access matrix M is safe with respect to the access right r if no sequence of commands can transform M into a state that leaks r



HRU Model - System State


The state of a system is the collection of the current values of all memory locations, all secondary storage, and all registers and other components of the system ■ The state of the protection system is the subset of such a collection that deals with allocation of access permissions; it is thus presented by the access control matrix

■



HRU Model – Safety of States


Definition 1: “access to resources without the concurrence of the owner is impossible” [HRU76] ■ Definition 2: “the user should be able to tell whether what he is about to do (give away a right, presumably) can lead to the further leakage of that right to truly unauthorized subjects” [HRU76] ■



Safety Problem


Inital Access Matrix

Rules for Modifying the Access Matrix

Is it possible to enter the right r in the cell A[V,C] of the access matrix

Yes / No ■

Given an access matrix M and a right r, verifying the safety of M with respect to r is an undecidable problem



Example of “Unsafe” Protection




Example (cont’d)


Suppose user Bob has developed an application program; he wants this program to be run by other users but not modified by them ■ The previous protection system is not safe with respect to this policy; consider the following sequence of commands: ■

◆ ◆

Bob: grant execute(Bob, Tom, P1) Tom: modify own right(Tom, P1)

It results in an access matrix with w ∈ A[T om, P 1]



HRU Safety Results


General Mono-conditional Bi-conditional Mono-operational No creation No subject creation Monotonic


Undecidable Decidable Undecidable Decidable, NP complete Decidable, Pspace complete Decidable, Exponential space Not known


Reaction to HRU


■

Security is hopeless ◆

■

No quite so; we do have safety results for interesting classes of systems

We are not interested in general classes of systems but only in a few specific systems ◆

Even for a speific system we need to analyze it under a variety of assumptions about behavior of individual subjects



Typed Access Matrix (TAM) Model


■

Much like HRU except ◆ ◆ ◆

All subjects and objects are strongly typed Commands have typed parameters The initiator of a TAM command is specified ■

It is assumed that whatever is listed as the first parameter, is the one to execute the TAM command



TAM Program




TAM versus HRU


■

TAM has ◆ ◆

Stronger safety properties than HRU Ease of expressiveness by means of strong typing



DAC - Summary


■

Provides discretionary access control ◆

Owner of an object has the right to pass on any access privilege on that object to other subjects ■

◆

Completely at the owner’s dicretion

Grant privilege allows any subject almost any other right to other subjects



DAC - Recent Trends


■

DAC models have been widely investigated in the database area ◆

■

First model by Griffiths and Wide

Flexibility enhanced by various extension ◆ ◆ ◆ ◆

Positive versus negative auhorization Strong versus weak authorization Implicit versus explicit Content based authorization



Positive vs Negative Authorization


Positive permissions – Grant access ■ Negative permission – Deny access ■ Useful for specifying stricter control for crucial data items ■ Problem with conflicts between permissions ■



Authorization Conflicts


Ideally make sure no conflicts ■ Negative permissions take precedence ■ Positive permissions take precedence ■ Most specific permissions take precedence ■



Implicit vs Explicit Permissons


■

Implicit permissions can be derived ◆ ◆

by a set of propagation rules exploiting subject, object and privilege hierarchies by a set of user specified derivation rules



Content-based Authorization


Content-based access control conditions the access to a given object based on its content ■ Example – A subject can access information about employees whose salaries do not exceed $30,000. ■




Mandatory Access Control

DAC - Solves the Access Control Problem (?) Mandatory Access Control Lattice Based Access Control Models Commercial Security Clark-Wilson Model Chinese Wall Model Role Based Access C

File A

X : r, w Y:

File B

X:w Y : r, w

Subject Y cannot read file A



What’s Wrong with DAC?


File A

X : r, w Y:

File B

X:w Y : r, w

read

Program Goodies Trojan Horse write

Y can read the contents of file A copied onto file B



Mandatory Access Control


We must have access control at the system level that is more fundamental than anything determined by a subject ■ Definition [Bishop p.53] When a system mechanism controls access to an object and an individual user cannot alter that access, the control is a mandatory access control (MAC) [, occasionally called a rule-based access control.] ■



Bell-LaPadula (BLP) Model


Proposed by Bell and LaPadula of the Mitre corporation in 1976 ■ Model based on military requirements where subjects are provided with security clearances and objects are classified to security levels and access by subjects to objects is provided on a need to know basis

■



BLP Model – Basic Idea


Subjects are assigned clearance levels and they can operate at a level up to and including their clearance levels ■ Objects are assigned sensitivity levels ■ The clearance levels as well as the sensitivity levels are called access classes ■ An access class consists of two components ■

◆ ◆

security level category set



BLP Model – Access Class


■

Security level is an element from a totally ordered set having some ordering relation ◆

■

{Top-Secret (TS), Secret (S), Confidential (C), Unclassified (U)} with ordering relation TS S C U

Category set is a (possibly empty) set of elements dependent on the application domain ◆

{Army, Navy, Air Force, Nuclear}



Access Class – Dominance Relation


■

Access class ACi = (Li , CSi ) dominates access class ACj = (Lj , CSj ), denoted as ACi ≥ ACj if both of the following conditions hold: ◆ ◆

The security level Li precedes the security level Lj in the ordering of the security levels, that is Li Lj , and The category set CSi includes the category set CSj , that is CSi ⊇ CSj



Dominance Relation


If Li ≻ Lj and CSi ⊃ CSj we say that ACi strictly dominates ACj (ACi > ACj ) ■ If neither ACi ≥ ACj nor ACj ≥ ACi , then the two access classes are incomparable ■



BLP Model (Simplified)


■

Can be abstracted into two rules ◆ ◆

BLP Simple Security BLP * Property (Star Property)

These are necessary conditions ■ DAC rules are considered additionally to determine final access of object by subject ■



BLP Simple Security


■

A subject, S, is allowed a read access to an object, O, only if the access class of subject S (AC(S)) dominates the access class of object O ◆

■

That is AC(O) ≤ AC(S) (equivalently AC(S) ≥ AC(O))

Simple Security ≡ No read up



Access Class Examples


■ ■ ■ ■ ■ ■ ■

AC1 AC2 AC3 AC4 AC1 AC1 AC3

= = = = ≥ >
AC4



BLP * (Star) Property


■

A subject, S, is allowed a write access to an object, O, only if the access class of the object O dominates the access class of the subject S ◆

■

That is AC(S) ≤ AC(O)

* (Star) Property ≡ No write down



Trojan Horse Revisited


High Two security levels High, Low Low < High L(X) = High L(Y) = Low L(A) = High L(B) = Low

File A read

X : r, w Y:

Program Goodies Trojan Horse

X write

Low File B

X:w Y : r, w

BLP rules prevent the Trojan Horse from writing to File B although DAC allows X to write to File B



Biba Model


Counterpart of the BLP model for Integrity purposes ■ Used to enforce integrity of system resources ■



Biba Simple Integrity


■

A subject, S, is allowed a read access to an object, O, only if the access class of the subject S is dominated by the access class of object O ◆

That is AC(S) ≤ AC(O) ■

No read down



Biba * (Star) Property - Integrity Confinement Mandatory Access Control Lattice Based Access Control Models Commercial Security Clark-Wilson Model Chinese Wall Model Role Based Access C ■

A subject, S, is allowed to write to an object, O, only if the access class of subject S dominates the access class of object O ◆

That is AC(O) ≤ AC(S) ■

No write up



Information Flow Models


BLP and Biba are two examples of information flow policies ■ Information usually flows from one object to another ■ Whenever information flows from one object A to another object B, there is also information flow from the security class of A to the security class of B ■




Lattice Based Access Control Models

Lattice Based Access Control Models


■

Dorothy Denning was the first to formalize the notion of information flow policies ◆

■

Introduced the notion of lattice based access control models

Briefly the model says that the flow of information from one security class to another can be modeled as a finite lattice under certain circumstances



Information Flow Policy


■

An information flow policy is a triple , where ◆ ◆ ◆

SC is a set of security classes → ⊆ SC × SC is a binary relation on SC called the “can flow” relation ⊕: SC × SC =⇒ SC is a class combining operator or join operator on SC



Information Flow Policy


Security classes cannot be created or destroyed dynamically (objects can be) ■ It is more appropriate to call the → relation as the ”may flow” relation instead of the “can flow” relation since the connotation is that the information flow is permitted ■

◆

Infix notation is often used for the “can flow” relation. Thus (A,B) ∈ → means the same as A → B that is information can flow from security class A to security class B



Information Flow Policy - Join Operator


Specifies how to label information obtained by combining information from two security classes ■ Infix notation is also used for the join operator. That is ⊕(A,B) = C means the same as A ⊕ B = C ■



Example of Information Flow Policy


■

Isolated classes - no information is allowed to flow from one security class to another ◆ ◆

SC = {A1 , A2 , . . ., An } for i = 1 . . . n we have ■ ■

◆

Ai → Ai Ai ⊕ Ai = Ai

for i, j = 1 . . . n, i 6= j we have ■ ■

Ai → 6 Aj Ai ⊕ Aj is undefined



Example of Information Flow Policy


■

High-Low policy - just two security classes High and Low with all flows allowed except from High to Low ◆ ◆ ◆

SC = {H, L} → = {(H,H), (L,L), (L,H)} ⊕ defined as follows ■ ■ ■ ■

H⊕H=H L⊕H=H H⊕L=H L⊕L=L



Denning’s Axioms


■

Denning showed that under certain assumptions an information flow policy forms a finite lattice ◆

A lattice is a partial order with a least upper bound (lub) and a greatest lower bound (glb)



Denning’s Axioms


The set of security classes, SC, is finite ■ The “can flow” relation, →, is a partial order on SC ■ SC has a lower bound L such that L → A for all A ∈ SC ■ The join operator ⊕ is a totally defined least upper bound operator on SC ■



Analysis of Denning’s Axioms


■

SC is a universally bounded lattice ◆

■

In practice we may end up with a partial ordered set rather than a lattice

→ being a partial order implies transitivity ◆ ◆

If A → B and B → C, then A → C That is if indirect information flow is possible from A to C via B, then there is no reason why we should not allow direct information flow from A to B





■

→ being a partial order also implies anti-symmetry ◆ ◆

If A → B and B → A then A → B It eliminates redundant security classes; there is no point having two different security classes if objects within these classes are restricted to the same information flow





■

The join operator ⊕ is required to be totally defined; this means that it is possible to combine information from any two security classes and give the result a security class ◆

To bring example 1 (isolated classes) into line with Denning’s axioms we introduce a new security class H (called system high) and define Ai ⊕ Aj = H for i 6= j



Analysis of Dennings Axioms


■

Existence of a system high class (result of the join operator being totally defined) ◆

■

Practical role for system high objects - information about global state of the system can go only in objects labeled system high

Existence of public (system low) information in any system (implied by the third axiom)



Analysis of Dennings Axioms


■

The join operator is a least upper bound (lub) operator that is ◆

for all A, B, C ∈ SC we have ■ ■

A → A ⊕ B and B → A ⊕ B If A → C and B → C, then A ⊕ B → C ◆

If information can flow individually from A and B to C then information obtained by combining information from A and B should be able to flow to C



Lattice Structures


Top Secret Hierarchical Classes

Secret

Confidential can flow dominance relation relation

Reflexive and transitive edges are implied but not shown

Unclassified Dr. Indrakshi Ray, Colorado State University


Lattice Structures


{Army, Crypto}

{Army}

{Crypto}

{} In the military and government sectors the individual set elements like Army, are known as categories while the sets of categories are known as compartments



Lattice Structures


{Army, Nuclear, Crypto}

{Army, Nuclear}

{Army, Crypto}

{Nuclear, Crypto}

{Army}

{Nuclear}

{Crypto}

{}



Lattice Properties


Product of two lattices is a lattice ■ Selecting an arbitrary subset of a lattice will not necessarily yield a lattice, but is guaranteed to yield a partially ordered set ■ Given a partial ordering we can always add extra labels to make it a lattice ■



BLP, Biba Revisited


■

BLP and Biba models are fundamentally equivalent ◆ ◆ ◆

Information flow in the Biba model is from top to bottom Information flow in the BLP model is from bottom to top Since top and bottom are relative terms, the two models are fundamentally equivalent



Equivalence of BLP and Biba


HI (High Integrity)

LI (Low Integrity)

can flow

can flow

LI (Low Integrity)

HI (High Integrity)

BIBA Lattice

Equivalent BLP Lattice



Equivalence of BLP and Biba


HS (High Secrecy)

LI (Low Secrecy)

can flow

can flow

LI (Low Secrecy)

HI (High Secrecy)

BLP Lattice

Equivalent BIBA Lattice



Combining the BLP and Biba Models


■

If a single label is used for both confidentiality as well as integrity then the two models impose conflicting constraints ◆ ◆

■

We fail to have information flow between security classes Trivial information flow policy

Use independent confidentiality and integrity labels ◆ ◆

Λ = {λ1 , λ2 , . . ., λp } is a lattice of confidentiality levels Ω = {ω1 , ω2 , . . ., ωp } is a lattice of integrity levels



Combining the BLP and Biba Models


■

The combined mandatory controls are: ◆ ◆

■

Subject S can read object O only if λ(S) ≥ λ(O) and ω(S) ≤ ω(O) Subject S can read object O only if λ(S) ≤ λ(O) and ω(S) ≥ ω(O)

This is the composite model and has been implemented in several operating system



Combining BLP and Biba Models


HS

HI

{HS, LI} {LS, LI}

can flow LS

{HS, HI}

LI can flow {LS, HI}

BLP Lattice


BIBA Lattice

can flow

Equivalent BLP Lattice


Dynamic Labels in BLP


■

Tranquility is most common ◆

■

λ is static for subjects and objects

BLP without tranquility may be secure or insecure depending upon the specific dynamics of labeling



Dynamic Labels in BLP


■

High water mark on subjects ◆ ◆ ◆

■

λ is static for objects λ may increase but not decrease for subjects this is secure amd useful in many cases

High water mark on objects ◆ ◆ ◆

λ is static for subjects λ may increase but not decrease for objects this is insecure due to disappearing objects




Commercial Security

Is Commercial Security Different?


■

Commercial firms rarely grant access on the basis of “clearances”. ◆ ◆

While this can be modeled using BLP it requires a large number of categories and security levels. It is difficult to control the proliferation of categories and security levels as the creation of categories and levels are decentralized.



Is Commercial Security Different?


■

Problem of information aggregation is insiduos. ◆

◆ ■

Commercial firms usually allow a limited amount of (innocuous) information to become public but keep a large amount of (sensitive) information confidential. By aggregating the innocuous information one can deduce much sensitive information.

Preventing this requires the model to track what questions have been asked.



Lipner’s Integrity Model


Relevant in the commercial sector ■ Tries to control the production program ■

◆

Integrity of the object is of prime importance



Requirements in Production Program


Users will not write their own programs, but will use existing production programs and databases. ■ Programmers will develop and test programs on a nonproduction system.

■

◆

If they need access to actual data, they will be given production data via a special process, but will use it on their development system.



Requirements (cont’d)


A special process must be followe to install a program from the development system onto the production system. ■ The special process must be controlled and audited. ■ The managers and auditors must have access to both the system state and the system logs that are generated.

■



Principles of Operation


Separation of duty. ■ Separation of function. ■ Auditing. ■



Separation of Duty


■

If two or more steps are required to perform a critical function, at least two separate persons should perform the steps. ◆ ◆ ◆

Moving a program from the development stage to the production system is an example. A separate “installer” is more likely to catch a problem than the original developer. If developer wants to subvert production data with a corrupt program, a separate certifier will be able to catch it.



Separation of Function


■

The same person should not perform two or more different functions in the system. ◆ ◆

Developers do not develop new programs on production systems because of the potential threat to production data. Developers do not process production data on the development system.



Auditing


■

Auditing is the process of analyzing systems to determine what actions took place and who performed them. ◆

This is needed for recovery and accountability.



Lipner’s Integrity Matrix Model


Combined BLP with Biba to address the concerns of the commercial sector. ■ Defined two security levels

■

◆ ◆ ■

Audit Manager (AM): system audit and management functions are at this level. System Low (SL): any process can read information at this level.

Defined five compartments



Lipner’s Compartments


■ ■ ■ ■ ■

Development (D): production programs under development and testing but not yet in production state. Production Code (PC): production process and programs Production Data (PD): data covered by the integrity policy System Development (SD): system programs under development but not yet in production use Software Tools (T): programs provided on the production system not related to the sensitive or protected data.



User to Security Level Assignment


Ordinary users will use production code to modify production data; their clearance is (SL, {PC, PD}). ■ Application developers need tools for developing their programs and to a category for the programs that are being developed; their clearance is (SL, {D, T}). ■ System programmers use tools to develop system programs; their clearance is (SL, {SD, T}). ■



User to Security Level Assignment


System Managers and auditors need high system clearance as they must be able to access all logs; their clearance is (AM, {D, PC, PD, SD, T}). ■ System controllers must have ability to downgrade code once it is certified for production so other entities cannot write to it; thus the clearance is (SL, {D, PC, PD, SD, T}) and downgrade privilege

■



Object to Security Level Assignment


Objects are assigned to security level based on who should access them. ■ Objects that may be altered have two compartments ■

◆ ◆

That of the data itself. That of the program that may alter it.



Object to Security Level Assignment


■ ■ ■ ■ ■ ■ ■

Development code/test data – (SL, {D,T}) Production code – (SL, {PC}) Production data – (SL, {PC, PD}) Software tools – (SL, {T}) System programs – (SL, {φ}) System programs in modification – (SL, {SD, T}) System and application logs – (AM, {appropriate category})



Security Level for Logs


■

All logs are append only. By the BLP *-property, their classes must dominate those of the subjects that write to them. Hence each log will have its own category. ◆

Simplest way to prevent log compromise is to put all logs at the highest security level.



Lipner’s Lattice


S: System Manager O: Audit Trail

S: System Control

S: Repair S: Production Users O: Production Data

S: Application Programmers

S: System Programmers

O: Development Code & Data

O: System Code in Development

O: Repair Code

O: Production Code

O: Tools

O: System Program



Lipner’s Lattice


The position of the audit trail at lowest integrity demonstrates the limitation of an information flow approach to integrity ■ System control subjects are exempted from the Star property and allowed to

■

◆ ◆

Write up with respect to integrity or Write down with respect to confidentiality



Lipner’s Use of BLP


With the two security levels and five compartments, the model satifies the five commercial security requirements. ■ However, it allows little flexibility in special purpose software

■

◆ ■

A program for repairing an inconsistent or erroneous production database cannot be an application-level software.

To remedy this Lipner integrates his BLP model with the Biba model (Combined Model)



Integrity Levels and Compartments


■

Three integrity levels ◆ ◆ ◆

■

System Program (ISP): the classification for system programs Operational (IO): the classification for production programs and development software System Low (ISL): the classification at which users log in

Two integrity compartments: ◆ ◆

Development (ID): development entities Production (IP): production entities



New Security Compartments


■

The previous security category T (tools) allowed application developers and system programmers to use the same programs without being able to alter these programs. ◆

The Integrity compartments now distinguish between production and development so the compartment T can be eliminated.

Production code and production data can be collapsed into the same compartment. ■ This results in 3 security compartments in the combined model. ■



New Security Compartments


Production (SP): production code and data ■ Development (SD): same as previous security compartment Development (D) ■ System Development (SSD): same as previous compartment System Development (SD) ■



Lattice Based Models


In practice we will always need to violate the direction of information flow ■ This is done by downgrading objects by passing them through a sanitizing process which is typically a trusted subject

■

◆

For example – declassifying confidential objects




Clark-Wilson Model

Clark-Wilson Model of Integrity


■

Data integrity ◆ ◆ ◆ ◆

■

Quality Correctness Authenticity Accuracy

System integrity ◆

Successful and correct operation of system



Integrity in Clark Wilson Model


Integrity defined by a set of constraints ■ Data is in a consistent state when it satisfies these constraints ■

◆ ■

For some data integrity may not matter

If all relevant data is in consistent state, system integrity is satisfied



Separation of Duty


■

No single person or entity should perform a task from beginning to end but the task should be divided among two or more people or entities



Well-formed Transactions


■

User should not be able to manipulate data arbitrarily but only in constrained, well-defined ways that preserve the integrity of the data



Principle of Least Privilege


■

An entity should be able to access only such information or resources that are necessary to its legitimate purpose



CW Model Components


■

CDI: Constrained Data Items ◆

■

Data that is subject to integrity controls

UDI: Unconstrained Data Items ◆

These data items are not subject to integrity controls



CW Model Components (cont’d)


■

IVP: Integrity Verification Procedures ◆

■

These procedures test if the CDIs conform to the integrity constraints

TP: Transaction Procedures ◆ ◆

These procedures are used to change the CDIs They take the system from one valid state to another



Certification Rules and Enforcement Rules


■

Ensure integrity is achieved and is preserved ◆ ◆

Certification Rules – Integrity monitoring rules enforced by the administrator Enforcement Rules – Integrity preserving rules guaranteed by the system



Certification Rules


C1 - IVP Certification – The system will have an IVP for validating the integrity of any CDI ■ C2 - Validity – The application of a TP to any CDI must maintain the integrity of that CDI. CDIs must be certified to ensure that they result in a valid CDI ■



Certification Rules (cont’d)


C3 - Modification – A CDI can only be changed by a TP. TPs must be certified to ensure they implement the principles of separation of duties & least privilege ■ C4 - Journal Certification – TPs must be certified to ensure that their actions are logged ■ C5 – TPs which act on UDIs must be certified to ensure that they result in a valid CDI

■



Enforcement Rules


E1 - Enforcement of Validity – Only certified TPs can operate on CDIs ■ E2 - Enforcement of Separation of Duty – Users must only access CDIs through TPs for which they are authorized ■ E3 - User Identity – The system must authenticate the identity of each user attempting to execute a TP ■ E4 - Initiation – Only administrator can specify TP authorizations ■



Discussion - Handling Untrusted Inputs


■

Any TP that takes as input a UDI may perform only valid transformations, or no transformations, for all possible values of the UDI. The transformation either rejects the UDI or transforms it into a CDI ◆

For example, in a bank ATM, numbers entered at the the keyboard are UDIs so cannot be input to TPs as such. TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI



Discussion - Separation of Duty


■

Only the certifier of a TP may change the list of entities associated with that TP. No certifier of a TP, or of an entity associated with that TP, may ever have execute permission with respect to that entity ◆

Enforces separation of duty with respect to certified and allowed relations.



Discussion - Ensuring Integrity


■

Provides an assurance that CDIs can be modified only in constrained ways. ◆

■

Ensured by rules C1, C2, C5, and E1 and E4

Provides an ability to control access to resources ◆

Ensured by rules C3 and E2 and E3.



Discussion - Ensuring Integrity (cont’d)


■

Provides an ability to ascertain after the fact that changes to CDIs are valid and the system is in a valid state ◆

■

Provided by rules C1 and C4

Provides an ability to uniquely associate an user to her/his action ◆

Enforced by rule E3



Summary


Model of integrity suitable for many commercial scenarios ■ Problem with difficulty to implement well-formed transactions ■




Chinese Wall Model

Chinese Wall Policy


Example of a commercial security policy for confidentiality ■ Mixture of free choice (discretionary) and mandatory controls ■ Requires some kind of dynamic labeling ■ Brewer-Nash model (1989) for Chinese Wall policy ■

◆

Claim that the Chinese Wall policy cannot be represented correctly by a lattice based model



Chinese Wall Policy


Arises in the financial segment of the commercial sector, which provides consulting services to other companies ■ Consultants have to deal with confidential company innformation for their clients ■ Objective of the Chinese Wall policy is to prevent information flow that cause conflict of interest for individual consultants

■



Chinese Wall Policy


All Objects

BANKS

Oil Companies Conflict of Interest Classes Company Datasets

A

B

X

Individual Objects


Y

A consultant can access information about at most one company in each conflict of interest class


BN Simple Security – Read Access


■

Subject S can read object O only if ◆ ◆

Object O is in the same company dataset as some object O′ , previously ready by subject S (that is O is within the wall), OR Object O belongs to a conflict of interest class within which subject S has not yet read any object (that is O is in the open)



BN * Property – Write Access


■

Subject S can write object O only if ◆ ◆

Subject S can read object O by the simple security rule, AND No object, O′ , can be read which is in a different company dataset to the one for which write access is required



Reason for BN * Property


Alices’ Wall

Bob’s Wall

Bank A Oil Company X

Bank B Oil Company X

Cooperating trojan Horses can transfer Bank A information to Bank B objects, and vice versa, using Oil Company X objects as intermediaries



Implication of BN * Property


■

Either ◆

■

Subject S cannot write at all

Or ◆

Subject S is limited to reading and writing one company dataset



Dynamic Aspect of Chinese Wall


■

A fresh new consultant hire can access information about any company in the database ◆

■

Thus he/she can start at any level

As the new hire advances, he/she acquires more information ◆

With BN model therefore we have to have a different consultant for every company dataset



Why This Impasse?


■

Failure to clearly distinguish user labels from subject labels ◆ ◆

Users should be trusted Subjects can contain Trojan Horses so cannot be trusted



Users, Principals and Subjects


USER


PRINCIPAL 1

PRINCIPAL 1’s SUBJECTS

PRINCIPAL 2


PRINCIPAL n





A principal is basically a login session ■ A user is essentially a collection of principals ■ A subject is basically a process running on behalf of the principal ■

◆

A principal can be a collection of several subjects





Alice.BANK A Alice.OIL COMPANY X

Alice.OIL COMPANY X Alice Alice.BANK A

Alice.novice

USER Dr. Indrakshi Ray, Colorado State University

PRINCIPALS 2009 ISEA Appraisal Workshop, IIT Guwahati, March 19, 2009 – 155 / 218

Chinese Wall Lattice


■

To properly understand and enforce information security policies we must distinguish between ◆ ◆

policy applied to user and policy applied to principals and subjects

The Brewer-Nash star property should apply to Alice’s principals not to Alice the user ■ A lattice implementation of Chinese Wall should allow dynamic creation of principals rather than dynamic labelling of subjects ■



Chinese Wall Lattice


■

We have to define ◆ ◆ ◆

■

The set of security classes The security class combining operator The can-flow relation

Achieved with the help of 9 Axioms



Axioms 1 and 2


■

Axiom 1: ◆

■

There are “n” conflict of interest classes COI1 , COI2 , . . ., COIn

Axiom 2: ◆

Each conflict of interest class COIi consists of mi companies ■

That is COIi = {1, 2, . . ., mi }



Axiom 3


■

Labels for Objects ◆

■

Label each object in the system with the companies from which it contains information. Obviously an object cannot contain information from two companies from the same conflict of interest class

A security label is an “n” element vector [i1 , i2 , . . ., in ], where each ik ∈ COIk or ik = ⊥ (null) ◆

LABELS = {[i1 , i2 , . . ., in ] | i1 ∈ COI′1 , . . ., in ∈ COI′n , where COI′1 = COI1 ∪ {⊥}, . . ., COI′n = COIn ∪ {⊥}



Axiom 3 – Illustration


■

Example ◆ ◆

■

Assume 5 different COI classes An object which contains information only from company #4 in COI3 will be labeled by the vector [⊥, ⊥, 4, ⊥, ⊥]

Note ◆

A label which has all ⊥ elements corresponds to public information



Axiom 4


■

Special label for system high ◆

EXTLABELS = LABELS ∪ {SYSHIGH}



Axiom 5


■

Dominance relation among labels ◆ ◆

Let lj [ik ] represent the ik th element of label lj (∀lp ,lq ∈ LABELS)[(lp ≥ lq ⇐⇒ ∀ik = 1, . . ., n (lp [ik ] = lq [ik ]) ∨ (lq [ik ] = ⊥)]

◆

That is lp dominates lq provided that lp and lq agree wherever lq 6= ⊥



Axiom 5 - Examples


[1,3,2] is a label for an object with information from company #1 in COI1 , company #3 in COI2 and company #2 in COI3 ■ [1,3,⊥] is a label for an object with information from company #1 in COI1 , company #3 in COI2 and no information from any company in COI3 ■ [1,3,2] > [1,3,⊥]

■



Axiom 5 - More Examples


[1,3,1] > [⊥,⊥,1] ■ [⊥,3,⊥] and [⊥,2,⊥] are incomparable (that is none dominates the other)

■



Axiom 6


■

To account for system high ◆ ◆

(∀l ∈ EXTLABELS)[SYSHIGH ≥ l] That is SYSHIGH dominates all other labels



Axiom 7


■

Compatible labels ◆ ◆

lp , lq ∈ LABELS are compatible iff (∀k = 1, . . ., n)[(lp [ik] = lq [ik ]) ∨ (lp [ik ] = ⊥) ∨ (lq [ik ] = ⊥)] Intuitively information from compatible incomparable classes can be combined without violating the Chinese Wall policy



Axiom 7 Example


■

[⊥,3,⊥] and [⊥,2,⊥] are incompatible ◆

■

[1,⊥,2] and [1,2,⊥] are compatible ◆

■

They are also incomparable They are incomparable, though

[1,3,1] and [⊥,⊥,1] are compatible ◆ ◆

They are also comparable By definition comparable labels are compatible



Axiom 8


■

Class combining (or ⊕) operation ◆

Compatible labels are combined as follows – if lp is compatible with lq then lp ⊕ lq = ls , where ls [ik ] =

(


lp [ik ] if lp [ik ] 6= ⊥ lq [ik ] otherwise


Axiom 8 (continued)


■

Class combining (or ⊕) operation ◆

Incompatible classes are combined as follows – if lp is incompatible with lq then lp ⊕ lq = SYSHIGH

◆ ◆

If lp ≥ lq then lp ⊕ lq = lp If lq ≥ lp then lp ⊕ lq = lq



Axiom 8 Example


■

[1,⊥,2] is compatible with [1,2,⊥] ◆

■

[1,⊥,2] ⊕ [1,2,⊥] = [1,2,2]

[1,2,⊥] ≥ [1,⊥,⊥] ◆

[1,2,⊥] ⊕ [1,⊥,⊥] = [1,2,⊥]



Axiom 9


■

Class combining with respect to SYSHIGH ◆

(∀l ∈ EXTLABELS)[l ⊕ SYSHIGH = SYSHIGH]



Example of a Chinese Wall Lattice


SYSHIGH

[1, 1]

[1, 2]

[2, 1]

[2, 2]

[1, ⊥]

[⊥, 1]

[⊥, 2]

[2, ⊥]

[⊥, ⊥]



Assigning Labels to Users


The label of a user is a high water mark that can float up in the Chinese Wall lattice starting with [⊥, ⊥, . . ., ⊥] ■ With each user a set of principals are associated, one at at each label dominated by a user’s label ■

◆ ◆

For example if Alice, the user, has a label [1, 2], then Alice has the following set of principals – Alice.[1, ⊥], Alice.[⊥, 2] and Alice.[⊥, ⊥] Alice can log in as any one of these principals at any given time.




Role Based Access Control

Role Based Access Control Models


■

Owner-based discretionary access control (DAC) ◆

■

Mandatory access control (MAC) ◆

■

Origins: military

Role based access control (RBAC) ◆

■

Origins: academia

Origins: business

There is more to access control than DAC / MAC



Owner Based DAC


■

Owner has all-or-nothing power ◆

Superuser fallacy

Spaghetti of intent ■ Negative permissions make for messier spaghetti ■ Trojan horses can subvert intent ■



Military Style MAC


Enforce one-directional information flow in a lattice of security labels ■ Rigid and simple-minded ■ Can be used for

■

◆ ◆ ◆

Confidentiality Integrity Aggregation (Chinese Wall)



RBAC


■

A user’s permissions are determined by the user’s roles rather than ◆ ◆

■

user’s identity (DAC) user’s clearance (MAC)

Facilitates ◆ ◆

administration of permissions articulation of policy



RBAC


Policy neutral ■ Policy oriented ■

◆ ◆ ◆ ◆ ■

least privilege separation of duties encapsulation of primitive permissions separation of administration and access

Roles are a semantic construct around which to build policy



RBAC


RBAC is a framework to help in articulating policy ■ The main point of RBAC is to facilitate security management ■



RBAC96 Family


RBAC3 Role Hierarchies + Constraints

RBAC1 Role Hierarchies

RBAC2 Constraints

RBAC0 Vanilla RBAC Dr. Indrakshi Ray, Colorado State University


RBAC0


User-Role Assignment USERS

Permission-Role Assignment ROLES

1 0 0 1 0 1 0 1 0 1

....

PERMISSIONS

SESSIONS

1 0 0 1



Permissions


■

Primitive permissions ◆

■

Abstract permissions ◆

■

read, write, append, execute credit, debit, inquiry

System permissions ◆

auditorObject permissions



Permissions


Permissions are positive ■ No negative permissions or denials ■

◆ ■

handled by constraints in RBAC2

No duties or obligations ◆

outside scope of access control



Roles as Policy


■

A role brings together ◆ ◆

■

a collection of users and a collection of permissions

These collections will vary over time ◆

A role has significance and meaning beyond the particular users and permissions brought together at any moment



Roles versus Groups


Groups are often defined as a collection of users ■ A role is ■

◆ ◆ ■

a collection of users and a collection of permissions

Some authors define role as a collection of permissions



Users


■

Users are ◆ ◆

■

human beings or other active agents

Each individual should be known as exactly one user



User-Role Assignment


A user can be a member of many roles ■ Each role can have many users as members ■



Sessions


A user can invoke multiple sessions ■ In each session a user can invoke any subset of roles that the user is a member of ■



Permission-Role Assignment


A permission can be assigned to many roles ■ Each role can have many permissions ■



Management of RBAC


■

Option 1: ◆

■

USER-ROLE Assignment and PERMISSION-ROLE Assignment can be changed only by the chief security officer

Option 2: ◆

Use RBAC to manage RBAC



RBAC1


Role Hierarchies


Permission-Role Assignment ROLES

1 0 0 1 0 1 0 1 0 1

....

PERMISSIONS

SESSIONS

1 0 0 1



Hierarchical Roles


Primary-Care Physician

Specialist Physician Physician

Health-Care Provider



Private Roles


Supervising Engineer Specialized HW Engineer

Specialized HW Engineer

Hardware Engineer

Software Engineer Engineer



RBAC2



ROLES

1 0 0 1 0 1 0 1 0 1

.... 1 0 0 1


Permission-Role Assignment PERMISSIONS

SESSIONS CONSTRAINTS


Constraints


■

Mutually Exclusive Roles ◆ ◆

Static Exclusion: The same individual can never hold both roles Dynamic Exclusion: The same individual can never hold both roles in the same context



Constraints


■

Mutually Exclusive Permissions ◆ ◆

Static Exclusion: The same role should never be assigned both permissions Dynamic Exclusion: The same role can never hold both permissions in the same context



Constraints


■

Cardinality Constraints on User-Role Assignment ◆ ◆ ◆

At most k users can belong to the role At least k users must belong to the role Exactly k users must belong to the role



Constraints


■

Cardinality Constraints on Permissions-Role Assignment ◆ ◆ ◆

At most k roles can get the permission At least k roles must get the permission Exactly k roles must get the permission



RBAC3


Role Hierarchies


ROLES

1 0 0 1 0 1 0 1 0 1

.... 1 0 0 1


Permission-Role Assignment PERMISSIONS

SESSIONS CONSTRAINTS



Access Control in Pervasive Systems

Pervasive Computing Example




Application Characteristics


■

Collaboration among large number of entities spanning multiple organizations ◆ ◆ ◆

Many unknown and unanticipated parameters Possibly ad hoc Dynamic in nature

Use of knowledge of surrounding physical spaces ■ Use of mobile, sensor and embedded devices ■

◆ ◆

Strongly interconnected Computation and communication resource crunch



Why Traditional Access Control Models Fail? Mandatory Access Control Lattice Based Access Control Models Commercial Security Clark-Wilson Model Chinese Wall Model Role Based Access C ■

No well-defined security perimeter ◆

■

Entities and their interactions are not known a-priori

Applications are very dynamic in nature ◆

Access control configuration may change dynamically

Access depends on environmental context such as space and time ■ Need to make access decisions based on potentially incomplete information ■



Extending RBAC Model to Include Space and Time Mandatory Access Control Lattice Based Access Control Models Commercial Security Clark-Wilson Model Chinese Wall Model Role Based Access C



Extending RBAC #2




Extending RBAC #3




Extending RBAC #4




Access Control for Unknown Entities


Tradeoff between providing access and degree of risk involved ■ Limit access depending on how much entity can be trusted

■

◆ ◆

How to measure trustworthiness of entities How to incorporate trust values in access control




Using Trust Relationships for Access Control

New Model of Trust




Representing Trust


■

Based on Jøsang’s opinion model ◆ ◆

■

Encompasses other belief models like Dempster-Shafer Explicitly includes uncertainty in algebraic operations on opinions

Represented as an opinion triple hb, d, ui ◆ ◆ ◆

b: strength of opinion trustee is trustworthy d: strength of opinion trustee is un-trustworthy u: amount of uncertainty in opinion



Opinion Triangle Interpretation




Factors Influencing Trust


■

Properties ◆

■

Experience ◆

■

Measures observable / verifiable physical characteristics of the trustee Measures the interactions that the trustee has with the trustee in a given period of time

Recommendation ◆

Measures the interactions that other trustworthy recommenders have about the trustee



Trust Expression




Trust Based Access Control


RH

USERS ROLES Human Roles

Human

Trust Constraints

UA Device Roles

Device

SOD PA Trust Values

Human Permission

OBJECTS

Device Permission

PO PERMISSIONS

SOD




Ending Remarks

Open Challenges


■ ■ ■ ■ ■

What constitutes secure operation in a dynamic enviornment? What types of access control models are suitable for dynamic coalitions? How do we analyze conflicts among access control policies? How do we get assurances that access control policies are providing adequate protection? How do we enforce access control in mobile, distributed enviornments?

