Computer Security Integrity Policies

Computer SecurityIntegrity Policies

Integrity Policies Commercial requirement • Users should not write their own programs • Programmers will develop and test programs on a non production system. • A special process must be followed to install a program from the development system onto the production system. • This must be controlled and audited. • Managers and auditors must have access to both the system state and log state.

Integrity Policies Goals • Separation of duties • If two or more steps are required to perform a critical function at least two people should perform the steps. • Separation of function • Developers do not develop new programs on production systems • Developers do not process production data on production systems • Auditing • Commercial systems emphasize recovery and accountability • Auditing involves analyzing systems to determine what actions took place and who was involved.

Biba Integrity model Basically a dual of the Bell-LaPadula model. We have a subject set S, an object set O, a set of integrity levels I, and a relation  on I. Let i : SO I return the integrity level, Relations • r : ability to read an object • w : ability to write an object • x : ability to execute a subject

Information transfer path A Information transfer path is a sequence of objects o1, … , on+1 and a corresponding sequence of subject s1, … , sn such that sjroj and sjwoj+1for all i

Low-Water-Mark Policy • s S can write to o O iff i (o)  i (s) . • If s S reads o O then i’(s)= min(i (s) ,i (o)), where i’(s) is the integrity level of s after the read. • s1 S can execute s2 S iff i (s2)  i (s1) . So • write up is prevented (prevents implant of corrupted data) • Integrity level drops on read access to lower level objects (prevents contaminating the subject: relying on less trustworthy data) • execute up is prevented.

Low-Water-Mark Policy Theorem: If there is an information path from o1 O to on+1 O , then enforcement of the low-water-mark policy requires that i (on+1)  i (o1) for all i>n. Proof The integrity level cannot go up. Proof by induction.

Low-Water-Mark Policy Problem The integrity level of a subject is non-increasing, resulting in some subjects being eventually unable to access certain objects.

Ring Policy • This ignores indirect modifications and • focuses on direct modifications. • s S can write to o O iff i (o)  i (s) . • s S can read any o O. • s1S can execute s2 S iff i(s2)  i (s1) . • Difference: Subjects can read any object.

Biba’s strict integrity Policy • s S can write to o O iff i (o)  i (s) . • s S can read o O iff i (s)  i (o) . • s1 S can execute s2 S iff i (s2)  i (s 1) . So • write up is prevented • read down is prevented (prevents relying on less trustworthy data) • execute up is prevented.

Lipner’s Integrity Matrix Model Combines BLP and Biba Two basic Security levels • Audit Manager (AM): system and management functions • System Low (SL): any process can read info at this level. Five categories • Development (D) • Production Code (PC) • Production Data (PD) • System Development (SD) • Software Tools (T)

Lipner’s Integrity Matrix Model Users Clearance levels Ordinary users (SL, {PC,PD}) Application Developers (SL, {D,T}) System Programmers (SL, {SD,T}) System Managers & Auditors (AM, {D,PC,PD,ST,T}) System Controllers (SL, {D,PC,PD,ST,T}) and downgrade privileges. Objects Class 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 categories})

Lipner’s full Model Users Security clearance Integrity clearance Ordinary users (SL, {SP}) (ISL, {IP}) Application Developers (SL, {SD}) (ISL,{ID}) System Programmers (SL, {SSD}) (ISL,{ID}) System Managers & Auditors (AM, {D,PC,PD,ST,T}) (ISL,{IP,ID}) System Controllers (SL, {SP,SD}) & downgrade privileges (ISP,{IP,ID}) Repair (SL, {SP}) (ISL,{IP}) Objects Security level Integrity level Development code/test data (SL, {SD}) (ISL,{IP}) Production Code (SL, {SP}) (IO,{IP}) Production Data (SL, {SP}) (ISL,{IP}) Software Tools (SL,{}) (IO,{ID}) System Programs (SL, {}) (ISP,{IP,ID}) System programs in modification(SL,{SSD}) (ISL,{ID}) System and Application logs (AM, {appropriate categories}) (ISL,{}) Repair (SL, {SP}) (ISL,{IP}) Three new integrity classifications: ISP (system program)  IO (operational)  ISL (system low) Two integrity categories: ID (developers) IP (producers)

Lipner’s full Model --- exercise Users Security clearance Integrity clearance Ordinary users (SL, {SP}) (ISL, {IP}) Application Developers (SL, {SD}) (ISL,{ID}) System Programmers (SL, {SSD}) (ISL,{ID}) System Managers & Auditors (AM, {D,PC,PD,ST,T}) (ISL,{IP,ID}) System Controllers (SL, {SP,SD}) & downgrade privileges (ISP,{IP,ID}) Repair (SL, {SP}) (ISL,{IP}) Objects Security level Integrity level Development code/test data (SL, {SD}) (ISL,{IP}) Production Code (SL, {SP}) (IO,{IP}) Production Data (SL, {SP}) (ISL,{IP}) Software Tools (SL,{}) (IO,{ID}) System Programs (SL, {}) (ISP,{IP,ID}) System programs in modification(SL,{SSD}) (ISL,{ID}) System and Application logs (AM, {appropriate categories}) (ISL,{}) Repair (SL, {SP}) (ISL,{IP}) For read access: s(subject)  s(object) & i(subject)  i(object) Controllers do not have read access to development code, or production code For write access: s(subject)  s(object) & i(subject)  i(object) Controllers do have read access to development code and production code Who can help the controllers move development code to production code?

Reminder:The Bell-LaPadula model ss-property: (s,o,p) SOP satisfies the ss-property relative to the security level f iff one of the following holds: • p = eorp = a • p = rorp = wandfc(s) dom fo(o). • Also DAC!

Reminder: The Bell-LaPadula model Define b(s: p1,…,pn) to be the set of objects that s has access to. *-property: For each sSthe following hold: • b(s:a) ≠[o b(s:a) [fc(o) dom fc(s)] ] (write-up) • b(s:w) ≠[o b(s:w) [fc(o) = fc(s)] ] (equality for read) • b(s:r) ≠[o b(s:r) [fc(s) dom fo(o)] ] (read-down) • Also DAC!

Lipner’s Integrity Matrix Model Lipner’s model combines Biba and Bell-LaPadula. Bell-LaPadula model: • Simple security property • * property For example: an ordinary user can execute production code; if he needs to alter production data, the *-property dictates that the data be in (System Low, {Production Code, Production Data}).

Lipner’s Integrity Matrix Model Objects Class 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 categories}) Logs are append only. By the *-property their class must dominate those of the subjects that write to them

The Clark-Wilson (CW) Model This model addresses data integrity requirements for commercial applications, e.g. bank transactions. Integrity requirements are divided into, • internal consistency: properties of the internal state that can be enforced by the computer system. • external consistency: the relation of the internal state to the real world: enforced by means outside the system, e.g. auditing.

The CW Model Integrity is enforced by, • well formed transactions: data items can be manipulated only by a specific set of programs; users have access to programs rather than data items. • separation of duties: users have to collaborate to manipulate data and collude to penetrate the system.

The CW Model In the Clark-Wilson model, • Subjects must be identified and authenticated, • Objects can be manipulated only by a restricted set of programs, • Subjects can executeonly a restricted set of programs, • A proper audit log has to be maintained, • The system must be certified to work properly.

The CW Model In the Clark-Wilson model • Data items are called Constrained Data Items (CDIs), • Data items not subject to integrity controls are Unconstrained Data Items (UDIs), • A set of integrity constraints constrain the values CDIs, • CDIs can only be manipulated by Transformation Procedures (TPs) • The integrity of a state is checked by Integrity Verification Procedure (IVPs)

The CW Model Security procedures are defined by 5 Certification rules: • Integrity Verification Procedures must ensure that all Constrained Data Items are in a valid state when the IVP is run. • Transformation Procedures must transform valid CDIs into valid CDIs. • The “allowed” access relations must meet the requirements imposed by the principle of separation of duty. 4. All TPs must write to an append-only CDI log. 5. Any TP that takes a UDI as input must either convert it into a CDI or reject it.

The CW Model Integrity is enforced by the 4 Enforcement rules • The system must maintain and protect the certified relations: (TPi:CDIa,CDIb, … ) and ensure that only Transformation Procedures certified to run on a Constrained Data Item manipulate that CDI. • The system must maintain and protect the list of entries: (User,TPi:CDIa,CDIb, … ) specifying the TPs that users can execute. • The system must authenticate each user requesting to execute a TP. • Only the certifier of a TP may modify the respective entities associated with that TP. No certifier of a TP may have execute permission with respect to that entity.

Computer Security Integrity Policies