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 + YBW

      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.