0% found this document useful (0 votes)
20 views52 pages

CH 13

Uploaded by

cppcommunityjo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views52 pages

CH 13

Uploaded by

cppcommunityjo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 52

Computer Security: Principles

and Practice

Chapter 13: Trusted Computing and


Multilevel Security

EECS710: Information Security


Professor Hossein Saiedian
Fall 2014
Computer Security Models
• Two fundamental computer security facts
– All complex software systems have eventually
revealed flaws or bugs that need to be fixed
– It is extraordinarily difficult to build computer
hardware/software not vulnerable to security
attacks

2
Confidentiality Policy
• Goal: prevent the unauthorized disclosure
of information
– Deals with information flow
– Integrity incidental
• Multi-level security models are best-known
examples
– Bell-LaPadula Model basis for many, or most, of
these

3
Formal Security Models
• Problems involved both design and
implementation led to development of
formal security models
– Initially funded by US Department of Defense
– Bell-LaPadula (BLP) model very influential

4
Bell-LaPadula (BLP) Model
• Security levels arranged in linear ordering
– Top Secret: highest
– Secret
– Confidential
– Unclassified: lowest
• Levels consist of security clearance L(s)
• Objects have security classification L(o)

5
Bell-LaPadula (BLP) Model

• Developed in 1970s
• Formal model for access control
• Subjects and objects are assigned a security class
• Form a hierarchy and are referred to as security
levels
• A subject has a security clearance
• An object has a security classification
• Security classes control the manner by which a
subject may access an object

6
A BLP Example

Security level Subject Object


Top Secret Tamara Personnel Files
Secret Samuel E-Mail Files
Confidential Claire Activity Logs
Unclassified James Telephone Lists
• Tamara can read all files
• Claire cannot read Personnel or E-Mail Files
• James can only read Telephone Lists

Slide #5-7
7
Access Privileges

8
Multilevel Security

• Multiple levels of security and data


• Subject at a high level may not convey info
to a subject at a non-comparable level:
– No read up (ss-property): a subj can only read
an obj of less or equal sec level
– No write down (*-property): a subj can only write
into an obj of greater or equal sec level

9
BLP Formal Description
• Based on current state of system (b, M, f, H):
– Current access set b (subj, objs, access-mode);
it is the current access (not permanent)
– Access matrix M (same as before)
– Level function f: assigns sec level to each subj
and obj; a subject may operate at that or lower
level
– Hierarchy H: a directed tree whose nodes are
objs:
• Sec level of an obj must dominate (must be
greater than) its parents

10
BLP Properties
• Three BLP properties: (c = current)
1. ss-property: (Si, Oj, read) has fc(Si) ≥ fo(Oj)
2. *-property: (Si, Oj, append) has fc(Si) ≤ fo(Oj) and
(Si, Oj, write) has fc(Si) = fo(Oj)
3. ds-property: (Si, Oj, Ax) implies Ax  M[Si,Oj]
• BLP give formal theorems
– Theoretically possible to prove system is secure

11
BLP Operations
1. get access: add (subj, obj, access-mode) to b
– used by a subj to initiate an access to an object
2. release access: remove (subj, obj, access-mode)
3. change object level
4. change current level
5. give access permission: Add an access mode to
M
– used by a subj to grant access to on an obj
6. rescind access permission: reverse of 5
7. create an object
8. delete a group of objects

12
BLP Example
• A role-based access control system
• Two users: Carla (student) and Dirk
(teacher)
– Carla (Class: s)
– Dirk (Class: T); can also login as a students
thus (Class: s)
• A student role has a lower security
clearance
• A teacher role has a higher security
clearance

13
BLP
Example
Dirk creates f1; Carla creates f2
Carla can read/write to f2
Carla can’t read f1
Dirk can read/write f1
Dirk can read f2 (if perm)
Dirk can read/write f2 only as a stu

Dirk reads f2; want create f3 (comments)


Dirk signs in as a stu (so Carla can read)
As a teacher, Dirk cannot create a
file at stu classification

14
BLP
Example
cont.
Dirk as a teacher creates exam (f4)
Must log in as a teacher to read
template

Dirk wants to give Carla access to read f4


Dirk can’t do that; an admin must do
An admin downgrades f4 class to c1-s

15
BLP
Example
cont.
Carla writes answers to f5 (at c1-t level)
-- An example of write up
Dirk can read f5

16
MULTICS Example

17
BLP Categories
• Expand the model to add categories to
each security classification
• Objects placed in multiple categories
• Based on “need to know” principle
• Example categories: NUC, EUR, US
– One can have access to any of these: none,
{NUC}, {EUR}, {US}, {NUC, EUR}, … {NUC,
EUR, US}
– Categories form a lattice under the “subset of”
operation

18
The Lattice Hierarchy

Introduction to Computer Security Slide #5-19


©2004 Matt Bishop 19
BLP Dominate (dom)
Relationship

• Captures the combination of security


classification and category set
• (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})

Introduction to Computer Security Slide #5-20


©2004 Matt Bishop 20
An Example of dom
Relationship
• George is cleared into security level (S,
{NUC, EUR})
• DocA is classified as (C, {NUC})
• DocB is classified as (S, {EUR, US})
• DocC is classified as (S, {EUR})
• George dom DocA
• George dom DocB
• George dom DocC

Introduction to Computer Security Slide #5-21


©2004 Matt Bishop 21
Reading Information - New
• Information flows up, not down
– “Reads up” disallowed, “reads down” allowed
• Simple Security Condition
– Subject s can read object o iff L(s) dom L(o)
and s has permission to read o
• Note: combines mandatory control (relationship of
security levels) and discretionary control (the
required permission)
– Sometimes called “no reads up” rule

Introduction to Computer Security Slide #5-22


©2004 Matt Bishop 22
Writing Information - New
• Information flows up, not down
– “Writes up” allowed, “writes down” disallowed
• *-Property (Step 2)
– Subject s can write object o iff L(o) dom L(s)
and s has permission to write o
• Note: combines mandatory control (relationship of
security levels) and discretionary control (the
required permission)
– Sometimes called “no writes down” rule

Introduction to Computer Security Slide #5-23


©2004 Matt Bishop 23
Biba Integrity Model
• Various models dealing with integrity
• Strict integrity policy:
– Simple integrity: modify only if I(S) ≥ I(O)
– Integrity confinement: read only if I(S) ≤ I(O)
– Invocation property: invoke/comm only if I(S1)
≥ I(S2)

24
Biba Integrity Model
• Simple integrity: modify only if I(S) ≥ I(O)
• Integrity confinement: read only if I(S) ≤
I(O)
• Invocation property: invoke/comm only if
I(S1) ≥ I(S2)

25
Clark-Wilson Integrity Model
• Two concepts
– Well-formed transactions: a user can manipulate
data in constrained ways
– Separation of duty: one can create a transaction
but not execute it
• CDI: constrained data items (loan app;
checks)
• UDI: unconstrained items
• IVPs: procedures that assure all CDIs conform
to integrity/consistency rules
• TPs: transactions that change CDIs
• Very practical; used in commercial world

26
Certified and Enforcement
Rules
• C1: IVPs must ensure that all CDIs are in
valid states
• C2: All TPs must be certified (must take a
CDI from a valid state to a valid final state)
– (Tpi, CDIa, CDIb, CDIc, …)
• E1: The system must maintain a list of
relations specified in C2
• E2: The system must maintain a list of
(User, Tpi, (CDIa, CDIb, …))

27
Certified and Enforcement
Rules
• C3: The list of relations in E2 must be
certified to meet separation of duties
• E3 The system must authenticate each user
when executing a TP
• C4: All TPs must be certified
• C5: Any TP that takes UDI as in input value
must be certified to perform valid
transaction
• E4: Only the agent permitted to certify
entitles is allowed to do so

28
Clark-Wilson Integrity Model
Certification (C) and
Enforcement (E) rules

29
The Chinese Wall Model
• Hybrid model: addresses integrity and
confidentiality
• Addresses conflict of interest (CI or CoI)
• Model elements
– subjects: active entities interested in accessing
protected objects
– information
• objects: individual data items, each about a corp
• datasets (DS): all objects concerning one corp
• CI class: datasets whose corp are in competition (conflict
of interest or CI)
– access rules: rules for reading/writing data

30
The Chinese Wall Model
• Not a true multilevel secure model
– the history of a subject’s access determines
access control
• Subjects are only allowed access to info
that is not held to conflict with any other
info they already possess
• Once a subject accesses info from one
dataset, a wall is set up to protect info in
other datasets in the same CI

31
Simple sec rule (read): S can

Chinese Wall Model


read O if O is in the same DS as
an object already accessed by S
OR O belongs to a CoI from which
S has not yet accessed any info

*-property (write): S can write


O only if S can read O and all objects
that S can read are in the same DS
as O.

Question: what can John or


Jane write to?

32
CW-*-Property
s can write to o iff both of the following hold:
1. The CW-simple condition permits s to read o
2. For all unsanitized objects o, if s can read o,
then CD (o) = CD (o)
– All s can read are either within the same CD, or
sanitized
Alice Bob Neither Alice nor bob can write
Bank
Gasoline

Citibank Bank of Bank of Shell Mobil Sunoco Texaco


America the West

33
How Does Information Flow?
• With the two conditions (CW simple security
condition and CW *-property) in place, how
can information flow around the system?
• Main Results
– In each COI class (e.g. Bank), a subject can only
read objects in a single CD (e.g. Citibank)
– At least n subjects are required to access all
objects in a COI class with totally n CDs

34 34
How Does Information Flow?
(Cont’d)
• Information flows from o to o’ if s reads o and
writes o’
• information in an unsanitized object can only flow
inside that CD; information in sanitized objects
can flow freely

Citibank Bank of Bank of Shell Mobil Sunoco Texaco


America the West

o3 sanitized
o1 o2 o3
o1 o2 o3 unsanitized

35 35
Compare CW to Bell-
LaPadula
• CW is based on access history, BLP is
history-less
• BLP can capture CW state at any time, but
cannot track changes over time
– BLP security levels would need to be updated
each time an access is allowed

36 36
Trusted Systems
• Trusted system: A system believed to enforce a
given set of attributes to a stated degree of assurance
• Trustworthiness: Assurance that a system deserves
to be trusted, such that the trust can be guaranteed in
some convincing way, such as through formal analysis
or code review
• Trusted computer system: A system that employs
sufficient hardware and software assurance measures
to allow its use for simultaneous processing of a range
of sensitive or classified information

37
Reference Monitors
(Trusted Systems)

Properties of the RM:

Complete mediation: security


rules enforced on every access
Isolation: RM and DB are protected from
unauthorized access
Verifiability: RM’s correctness can be
proven

38
Trojan Horse Defence

security levels are assigned at login


sec levels: sensitive and public data
Trojan must have the same sec level

A “normal” OS vs a trusted OS with RM


(sec levels assigned at login thus can’t
write down)

39
MLS Security for Role-Based
Access Control
• Role-based access control (RBAC) can
implement BLP MLS rules given:
– Security constraints on users:
For all users u, sec-level(u) is defined
– Constraints on read/write permissions:
All objects have a defined r and w access permission
– Read and write level role access definitions
Each role r defined has r-level(r) and w-level(r)
– Constraint on user-role assignments
Clearance of a user must dominate the r-level and be
dominated by the w-level

41
MLS in Database Security
• Classification by table and column

42
MLS in Database Security
• Classification by row and cell

43
Database Security: Read
Access
• DBMS enforces simple security rule (no read
up)
• Easy if granularity is entire database or at
table level
• Inference problems if have column granularity
– If can query on restricted data can infer its existence
– SELECT Ename FROM Employee
– SELECT Ename FROM Employee WHERE Salary > 50K
– Solution is to check access to all query data
• Also have problems if have row granularity
– Null response indicates restricted/empty result
• No extra concerns if have
44
element granularity
Database Security: Write
Access
• Enforce *-security rule (no write down)
• Have problem if a low clearance user
wants to insert a row with a primary key
that already exists in a higher level row:
– Can reject, but user knows row exists
– Can replace, compromises data integrity
– Polyinstantiation and insert multiple rows with same key,
creates conflicting entries but plausible (and implemented in
many DBs)

• Same alternatives occur on update


• Avoid problem if use database/table
granularity
45
Trusted Platform Module
(TPM)
• Concept from Trusted Computing Group
• Hardware module at heart of hardware/
software approach to trusted computing
• Uses a TPM chip on
– motherboard, smart card, processor
– working with approved hardware / software
– generating and using crypto keys
• Has 3 basic services: authenticated boot,
certification, and encryption

46
TPM Functions

47
Common Criteria (CC)
• ISO standards for security requirements
and defining evaluation criteria to give:
– Greater confidence in IT product security
– Formal actions during process of:
• development using secure requirements
• evaluation confirming meets requirements
• operation in accordance with requirements
• Evaluated products are listed for use

53
CC Requirements
• Have a common set of potential security
requirements for use in evaluation
• Target of evaluation (TOE) refers
product/system subject to evaluation
• Functional requirements
– define desired security behavior
• Assurance requirements
– that security measures effective correct
• Requirements: see pages 471-472

54
Assurance
• “Degree of confidence that the security
controls operate correctly and protect the
system as intended”
• Applies to:
– product security requirements, security policy,
product design, implementation, operation
• various approaches analyzing, checking,
testing various aspects

58
Common Criteria (CC)
Assurance Levels
• EAL 1: functionally independently tested
• EAL 2: structurally tested (includes review of
design and vulnerability analysis)
• EAL 3: methodically tested and checked (design
testing)
• EAL 4: methodically designed, tested, and
reviewed (high level to low level vulnerability
analysis)
• EAL 5: semiformally designed and tested
• EAL 6: semiformally verified design and tested
• EAL 7: formally verified design and tested (formal
analysis and formally showing correspondence)

59
Evaluation Parties & Phases

• Evaluation parties:
– sponsor - customer or vendor
– developer - provides evidence for evaluation
– evaluator - confirms requirements satisfied
– certifier - agency monitoring evaluation process
• Phases:
– preparation (initial contact)
– conduct of evaluation (structured process)
– conclusion (final evaluation)
• Government agency regulates: NIST, NSA jointly
operate Common Criteria Eval and Validation
Scheme (US CCEVS)
61
Summary
• Bell-LaPadula security model
• other models
• Reference monitors & trojan horse defence
• multilevel secure RBAC and databases
• Trusted platform module
• Common criteria
• Assurance and evaluation

62

You might also like