Summary

•Warns that electronic mail not private

–Can be read during normal system administration

–Can be forged, altered, and forwarded

•Unusual because the policy alerts users to the threats

–Usually, policies say how to prevent problems, but do not define the threats

•What users should and should not do

–Think before you send

–Be courteous, respectful of others

–Don’t nterfere with others’ use of email

•Personal use okay, provided overhead minimal

•Who it applies to

–Problem is UC is quasi-governmental, so is bound by rules that private companies may not be

–Educational mission also affects application

Full Policy

•Context

–Does not apply to Dept. of Energy labs run by the university

–Does not apply to printed copies of email

•Other policies apply here

•E-mail, infrastructure are university property

–Principles of academic freedom, freedom of speech apply

–Access without user’s permission requires approval of vice chancellor of campus or vice president of UC

–If infeasible, must get permission retroactively

Mechanisms

•Entity or procedure that enforces some part of the security policy

–Access controls (like bits to prevent someone from reading a homework file)

–Disallowing people from bringing CDs and floppy disks into a computer facility to control what is placed on systems

Example English Policy

•Computer security policy for academic institution

–Institution has multiple campuses, administered from central office

–Each campus has its own administration, and unique aspects and needs

•Authorized Use Policy

•Electronic Mail Policy

Authorized Use Policy

•Intended for one campus (Davis) only

•Goals of campus computing

–Underlying intent

•Procedural enforcement mechanisms

–Warnings

–Denial of computer access

–Disciplinary action up to and including expulsion

•Written informally, aimed at user community

Electronic Mail Policy

•Systemwide, not just one campus

•Three parts

–Summary

–Full policy

–Interpretation at the campus

Types of Access Control

•Discretionary Access Control (DAC, IBAC)

–individual user sets access control mechanism to allow or deny access to an object

•Mandatory Access Control (MAC)

–system mechanism controls access to object, and individual cannot alter that access

•Originator Controlled Access Control (ORCON)

originator (creator) of information controls who can access information

Question

•Policy disallows cheating

–Includes copying homework, with or without permission

•CS class has students do homework on computer

•Anne forgets to read-protect her homework file

•Bill copies it

•Who cheated?

–Anne, Bill, or both?

Trust

Administrator installs patch

1.Trusts patch came from vendor, not tampered with in transit

2.Trusts vendor tested patch thoroughly

3.Trusts vendor’s test environment corresponds to local environment

4.Trusts patch is installed correctly

Trust in Formal Verification

•Gives formal mathematical proof that given input i, program P produces output o as specified

•Suppose a security-related program S formally verified to work with operating system O

•What are the assumptions?

Trust in Formal Methods

1.Proof has no errors

•Bugs in automated theorem provers

2.Preconditions hold in environment in which S is to be used

3.S transformed into executable S¢ whose actions follow source code

–Compiler bugs, linker/loader/library problems

4.Hardware executes S¢ as intended

–Hardware bugs (Pentium f00f bug, for example)

Policy Models

Abstract description of a policy or class of policies

•Focus on points of interest in policies

–Security levels in multilevel security models

–Separation of duty in Clark-Wilson model

–Conflict of interest in Chinese Wall model

Types of Security Policies

•Military (governmental) security policy

–Policy primarily protecting confidentiality

•Commercial security policy

–Policy primarily protecting integrity

•Confidentiality policy

–Policy protecting only confidentiality

•Integrity policy

–Policy protecting only integrity

Integrity and Transactions

•Begin in consistent state

–“Consistent” defined by specification

•Perform series of actions (transaction)

–Actions cannot be interrupted

–If actions complete, system in consistent state

–If actions do not complete, system reverts to beginning (consistent) state

information security

https://drive.google.com/file/d/0BzsuAfabSI9rbm1PV2MzQ1JEWjg/edit?usp=sharing

Comparison With Requirements

•             Users can’t certify TPs, so CR5 and ER4 enforce this

•             Procedural, so model doesn’t directly cover it; but special process corresponds to using TP

•           No technical controls can prevent programmer from developing program on production system; usual control is to delete software tools

•             TP does the installation, trusted personnel do certification

   CR4 provides logging; ER3 authenticates trusted personnel doing installation; CR5, ER4 control installation procedure

•           New program UDI before certification, CDI (and TP) after

•             Log is CDI, so appropriate TP can provide managers, auditors access

•           Access to state handled similarly

Comparison to Biba

•      Biba

–   No notion of certification rules; trusted subjects ensure actions obey rules

–   Untrusted data examined before being made trusted

•      Clark-Wilson

–   Explicit requirements that actions must meet

–   Trusted entity must certify method to upgrade untrusted data (and not certify the data itself)

Key Points

•      Integrity policies deal with trust

–   As trust is hard to quantify, these policies are hard to evaluate completely

–   Look for assumptions and trusted users to find possible weak points in their implementation

•      Biba based on multilevel integrity

•      Clark-Wilson focuses on separation of duty and transactions

Users and Rules

CR3     The allowed relations must meet the requirements imposed by the principle of separation of duty.

ER3     The system must authenticate each user attempting to execute a TP

–    Type of authentication undefined, and depends on the instantiation

–    Authentication not required before use of the system, but is required before manipulation of CDIs (requires using TPs)

Logging

CR4     All TPs must append enough information to reconstruct the operation to an append-only CDI.

–   This CDI is the log

–   Auditor needs to be able to determine what happened during reviews of transactions

Handling Untrusted Input

CR5     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.

–    In bank, numbers entered at keyboard are UDIs, so cannot be input to TPs. TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI

Separation of Duty In Model

ER4     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

Certification Rules 1 and 2

CR1     When any IVP is run, it must ensure all CDIs are in a valid state

CR2     For some associated set of CDIs, a TP must transform those CDIs in a valid state into a (possibly different) valid state

–    Defines relation certified that associates a set of CDIs with a particular TP

–    Example: TP balance, CDIs accounts, in bank example

Enforcement Rules 1 and 2

ER1     The system must maintain the certified relations and must ensure that only TPs certified to run on a CDI manipulate that CDI.

ER2     The system must associate a user with each TP and set of CDIs. The TP may access those CDIs on behalf of the associated user. The TP cannot access that CDI on behalf of a user not associated with that TP and CDI.

–    System must maintain, enforce certified relation

–    System must also restrict access based on user ID (allowed relation)

Clark-Wilson Integrity Model

•      Integrity defined by a set of constraints

–    Data in a consistent or valid state when it satisfies these

•      Example: Bank

–    D today’s deposits, W withdrawals, YB yesterday’s balance, TB today’s balance

–    Integrity constraint: D + YB –W

•      Well-formed transaction move system from one consistent state to another

•      Issue: who examines, certifies transactions done correctly?

Entities

•      CDIs: constrained data items

–    Data subject to integrity controls

•      UDIs: unconstrained data items

–    Data not subject to integrity controls

•      IVPs: integrity verification procedures

–    Procedures that test the CDIs conform to the integrity constraints

•      TPs: transaction procedures

–    Procedures that take the system from one valid state to another 

Biba’s Model

•      Similar to Bell-LaPadula model

–           s Î S can read o Î O iff i(s) ¡Â i(o)

–           s Î S can write to o Î O iff i(o) ¡Â i(s)

–           s₁ Î S can execute s₂ Î S iff i(s₂) ¡Â i(s₁)

•      Add compartments and discretionary controls to get full dual of Bell-LaPadula model

•      Information flow result holds

–          Different proof, though

•      Actually the “strict integrity model” of Biba’s set of models

LOCUS and Biba

•      Goal: prevent untrusted software from altering data or other software

•      Approach: make levels of trust explicit

–    credibility rating based on estimate of software’s trustworthiness (0 untrusted, n highly trusted)

–    trusted file systems contain software with a single credibility level

–    Process has risk level or highest credibility level at which process can execute

–    Must use run-untrusted command to run software at lower credibility level

Biba Integrity Model

•      Set of subjects S, objects O, integrity levels I, relation ¡Â Í I ´ I holding when second dominates first

•      min: I ´ I ® I returns lesser of integrity levels 

•      i: S È O ® I gives integrity level of entity

•      r: S ´ O means s Î S can read o Î O

•      w, x defined similarly

Intuition for Integrity Levels

•      The higher the level, the more confidence

–   That a program will execute correctly

–   That data is accurate and/or reliable

•      Note relationship between integrity and trustworthiness

•      Important point: integrity levels are not security levels

Basic Security Theorem, Step 2

•      If a system is initially in a secure state, and every transition of the system satisfies the simple security condition, step 2, and the *-property, step 2, then every state of the system is secure

–    Proof: induct on the number of transitions

–    In actual Basic Security Theorem, discretionary access control treated as third property, and simple security property and *-property phrased to eliminate discretionary part of the definitions — but simpler to express the way done here.

Problem

•      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”)

•      Clearly absurd!

Solution

•      Define maximum, current levels for subjects

–    maxlevel(s) dom curlevel(s)

•      Example

–    Treat Major as an object (Colonel is writing to him/her)

–    Colonel has maxlevel (Secret, { NUC, EUR })

–    Colonel sets curlevel to (Secret, { EUR })

–    Now L(Major) dom curlevel(Colonel)

•    Colonel can write to Major without violating “no writes down”

–    Does L(s) mean curlevel(s) or maxlevel(s)?

•    Formally, we need a more precise notation

Chapter 5: Confidentiality Policies

Overview

•      Goals of Confidentiality Model

•      Bell-LaPadula Model

•      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

Bell-LaPadula Model, Step 1

•      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)

Example

Reading Information

•      Information flows up, not down

–   “Reads up” disallowed, “reads down” allowed

•      Simple Security Condition (Step 1)

–   Subject s can read object o iff L(o) ¡Â L(s) 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

Writing Information

•      Information flows up, not down

–   “Writes up” allowed, “writes down” disallowed

•      *-Property (Step 1)

–   Subject s can write object o iff L(s) ¡Â L(o) 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

Basic Security Theorem, Step 1

•      If a system is initially in a secure state, and every transition of the system satisfies the simple security condition, step 1, and the *-property, step 1, then every state of the system is secure

–   Proof: induct on the number of transitions

Bell-LaPadula Model, Step 2

•      Expand notion of security level to include categories

•      Security level is (clearance, category set)

•      Examples

–   ( Top Secret, { NUC, EUR, ASI } )

–   ( Confidential, { EUR, ASI } )

–   ( Secret, { NUC, ASI } )

Levels and Lattices

•      (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

–    lub(L) = (max(A), C)

–    glb(L) = (min(A), Æ)

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

Reading Information

•      Information flows up, not down

–   “Reads up” disallowed, “reads down” allowed

•      Simple Security Condition (Step 2)

–   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

Writing Information

•      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