computer security integrity policies n.
Skip this Video
Loading SlideShow in 5 Seconds..
Computer Security Integrity Policies PowerPoint Presentation
Download Presentation
Computer Security Integrity Policies

Computer Security Integrity Policies

209 Views Download Presentation
Download Presentation

Computer Security Integrity Policies

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Computer SecurityIntegrity Policies

  2. Integrity Policies Commercial requirement differ from military requirements: the emphasis is on integrity. – Lipner’s five requirements • Users will 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.

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

  4. Biba Integrity model Basically a mathematical 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

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

  6. Low-Water-Mark Policy • s S can write to o O iffi (s) i (o). • 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 iffi (s1)  i (s2). So • write up is prevented (prevents implanting 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. (otherwise a less trusted invoker could control the execution of the invoked subject, corrupting it even though it is more trustworthy.)

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

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

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

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

  11. 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 programs under development and testing, not in use yet • Production Code (PC) -- production processes and programs • Production Data (PD) – data covered by the integrity policy • System Development (SD) – system programs under development / testing, not in use yet • Software Tools (T) – programs provided on the production system not related to sensitive or protected data

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

  13. 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 = eor p = a • ( p = ror p = w ) andfc(s) dom fo(o) ). • Also DAC!

  14. 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!

  15. Lipner’s Integrity Matrix Model Lipner’s model combines Biba and Bell-LaPadula. Bell-LaPadula model: • ss - 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}).

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

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

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

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

  20. 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)

  21. The CW Model Security procedures are defined by five 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.

  22. The CW Model Integrity is enforced by four 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.