Showing posts with label Integrity Policies. Show all posts
Showing posts with label Integrity Policies. Show all posts

Saturday, January 11, 2014

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)

–           s1 Î S can execute s2 Î S iff i(s2) ¡Â i(s1)

•      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


Chapter 6: Integrity Policies

•      Overview

•      Requirements

•      Biba’s models

•      Clark-Wilson model

Overview

•      Requirements

–   Very different than confidentiality policies

•      Biba’s model

•      Clark-Wilson model

Requirements of Policies

•              Users will not write their own programs, but will use existing production programs and databases.

•              Programmers will develop and test programs on a non-production 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.

•              A special process must be followed to install a program from the development system onto the production system.

•              The special process in requirement 3 must be controlled and audited.


•              The managers and auditors must have access to both the system state and the system logs that are generated.