ISA 562 Internet Security Theory and Practice

ISA 562 Internet Security Theory and Practice Integrity Policies Chapter 6 of Bishop’s book

Overview • Background • Biba’s models • Strict Integrity Policy • Low-Water-Mark Policy • Combining Biba and BLP • Lipner’s model • Clark-Wilson model

Background (1) Business tends to Focus on integrity rather than confidentiality Subjects and objects may be labeled with integrity levels I, where i1 ≤ i2 means i2 dominates i1. Higher level = more trustworthy = higher integrity • Subject: program on Windows CD (trusted) vs. downloaded Java applet (untrusted) • Object: system logs (trusted) vs email attachment from unknown sender (untrusted)

Background (2) Integrity policy vs. confidentiality policy • Integrity levels ≠ security levels (they may overlap) A General with secret clearance is trusted A company like GE is trusted but not normally allowed to upload military secrets (unless they have a contract) Information flows differently: • Information is disclosed (flows down) when: • Read-up: a visitor (unclassified) reads personnel files (secret) • Write-down: a cryptographer (secret) writes an activity log (unclassified) • Information is corrupted (flows up) when: • Read-down: IE (trusted) opens a file having a virus (untrusted) • Write-up: a downloaded Java applet (untrusted) writes something into Windows registry (trusted) secret unclassified trusted untrusted

Strict Integrity policy: The Biba Model • If BLP prevents information from flowing down (disclosed) • BLP-upside-down will prevent information from flowing up (getting corrupted) Biba information flow  or dominate High Integrity Some integrity Suspicious Garbage

information flow High Integrity read Some integrity Suspicious write Garbage Biba = BLP Upside-down • BLP=read-down and write-up, • Biba= read-up and write-down Biba

Notation S=Subjects, O=objects, I= integrity levels i1 ≤ i2 says i2 dominates i1 min(i1 , i2 ) is the lesser of i1 and i2 i (s), i (o) = integrity level of s  S and o  O. s ro says s can read o swo says s can write o, sxs’ says s can execute s’

Strict Integrity Policy (formal) Biba’s Model For any sS and o O • s r o iff I (s) ≤ I (o) (read-up) • s w o iff I (o) ≤ I (s) (write-down) • s1x s2 iff I (s2) ≤ I (s1) (execute-up) • execute is a special type of read • Why? = execution does not corrupt code! • Can add compartments and discretionary controls to get full dual of BLP

Information Flow An information transfer path is a sequence of objects o1, ..., on+1 and corresponding sequence of subjects s1, ..., sn such that siroi and siwoi+1 for all i, 1 ≤ i ≤ n. • Whensir oiinformation flows fromoi to si • Whensiw oiinformation flows fromsi to oi+1 • Thus information can flow from o1 to on+1 along this path by successive reads and writes o1 o2 o3 On On+1 Sn s1 s2 s3 …… information flow write read

Information Flow Result • If there is any information transfer path from o1O to on+1O, then strict integrity policy implies that i (on+1) ≤ i (o1) holds for all n 1. • No object can be corrupted, either directly (write up) or indirectly (first read down then write equal) o1 high integrity s1 o2 s2 o3 s3 …… On Sn On+1 low integrity write read

Theorem: Information Flow (Theorem 6.1 from Bishop) If there is an information transfer path from o1 O to on+1 O, then strict integrity policy implies that i (on+1) ≤ i (o1) holds for all n 1. Proof: By induction For n=1: Case 1:s1r o1and s1w o2 then by definition, i (on+1) ≤ i (o1) Case 2:s1w o1 and s2r o2Is this possible? No

Proof continued…. The inductive case: Suppose the result is true for n: Want to prove for (n+1): By the inductive hypothesis, i (on) ≤ i (o1) Need to show i (on+1) ≤ i (o1) Do so by proving i (on+1) ≤ i (on) Case 1: sn+1r on+1and sn+1w on+2 then by definition, i (on+1) ≤ i (on) - we are done ! Case 2: sn+1w on+1orsn+1r on+2 Is this possible? No

Overview • Background • Biba’s models • Strict Integrity policy • Low-Water-Mark policy • Combining Biba and BLP • Lipner’s model • Clark-Wilson model

Low Water Mark Policy Motivation: to relax strict integrity policy but still have the information flow claim valid Two versions: • Subject low-water-mark policy relaxes the read by allowing subjects to read down • Object low-water-mark policy relaxes the write by allowing subjects to write up

SubjectLow Water Mark Policy Idea:s can read down, but once it does, its integrity level drops (so it cannot corrupt other objects) Example: After a machine reads emails infected with worm, the machine is no longer trusted and isolated Rules: For any s  S and o  O • s r o and s reads o impliesi (s) = min(i (s), i (o)) • s w o iff i (o) ≤ i (s) (write-down) • s x s2 iff i (s2) ≤ i (s1) (execute-up)

ObjectLow-Water-Mark Policy Idea:s can write up, but the integrity level of any object s writes will drop Example: After a virus is detected, whatever files were written by the virus are no longer trusted and therefore are deleted Rules: For any s  S and o  O • s r o iff i (s) ≤ i (o) (read-up) • s w o and s writes o impliesi (o) = min(i (s), i (o)) • s x s2 iff i (s2) ≤ i (s1) (execute-up)

subject low-water-mark policy preventss1from corrupting o2 object low-water-mark policy detects the corruption of o2 o2 s1 o2 o1 s1 o1 s1 s1 o2 o2 o1 o1 Information Flow Result Theorem: With the subject/object low-water-mark policy, the information flow result also holds i (on+1) ≤ i (o1) holds in the following cases: read write

Problems • With subject low-water-mark policy, subjects’ integrity levels never increases • After some actions, no subject will be able to access objects at high integrity levels • With object low-water-mark policy, objects can be easily corrupted • After some actions, all objects will be at the lowest integrity level • Implementation needs mechanisms to warn subjects about corruption (of the subject itself or the object being written by it)

Combining Biba and BLP • Important: security levels (BLP) and integrity levels (Biba) are two different things • Whether they overlap one another depends on applications • When they do overlap, enforcement of BLP and Biba may conflict • What if they are exactly the same? • See Exercise 3 in Bishop

Combining Biba and BLP (Cont’d) • What if they are exactly reversed? • Secret and un-trusted: a downloaded software is un-trusted and should not be read/executed by everyone • Unclassified and trusted: system binaries are trusted and can be executed by anyone • Then both rules and the levels are dual, so BLP and Biba work in the same way • Read-down in BLP becomes read-up in Biba • Write-up in BLP becomes write-down in Biba

Typical Commercial Requirements • Users do not write their own programs, but use existing production programs and databases. • Programmersdevelop and test programs on a non-production system; if they need access to production data, they are given data via a special process and can only use it on the development system. • A special process must be followed to transfera program from the development system onto the production system. • The special process of requirement 3 must be controlled and audited. • The managers and auditors must have access to both the system state and system logs that are generated.

Lipner’s Lattice (BLP+Biba) • A realistic example showing that BLP and Biba can be combined to meet commercial requirements • How does it combine BLP and Biba? • Uses disjoint sets of security levels and integrity levels • BLP goes first, and adds in Biba only when necessary

The BLP Part • 2 security clearances/classifications • AM (Audit Manager): system audit, management functions • SL (System Low): any process can read at this level • 3 Security categories • SP (Production): production code, data • SD (Development): same as D • SSD (System Development): same as old SD • Security level=(classification,category)

The Biba Part • 3 integrity classifications • ISP (System Program): for system programs • IO (Operational): production programs, development software • ISL (System Low): users get this on log in • 2 integrity categories • ID (Development): development entities • IP (Production): production entities • Integrity level=(classification,category)

Subjects’ Levels at a Glance

Objects’ Levels at a Glance

The Lattice (Lipner’s Lattice) S: System Managers O: Audit Trail Only 9 out of 192 labels are used LEGEND S: Subjects O: Objects S: System Control S: Application Programmers O: Development Code and Data S: System Programmers O: System Code in Development S: Repair S: Production Users O: Production Data O: Tools O: Repair Code O: Production Code O: System Programs

What Does it Achieve? • Ordinary users can execute (read) production code but cannot alter it • Ordinary users can alter and read production data • System managers need access to all logs but cannot change levels of objects • System controllers need to install code (hence downgrade capability) • Logs are append only, so must dominate subjects writing them • These meet stated requirements • (verify if you want)

Clark-Wilson Integrity Model • Time-proven accounting practices are extrapolated to computer world • Integrity policy are given as high-level rules • Remember these are policy – no need to ask “how?” • Example: Bank • Objective: today’s deposits - today’s withdrawals + yesterday’s balance = today’s balance • Policy level 1: transactions must meet this objective • Policy level 2: users execute only those transactions • Policy level 3: certifiers must ensure users do so • Policy level 4: logs will monitor that certifiers are doing their job!

Clark-Wilson Integrity Model (Cont’d) • The key contribution is that this hierarchical structure reduces the dependency on special trusted subjects • Certifiers will enforce users to run only good transactions, and logs will in turn monitor certifiers • But who will then monitor log auditors? • Trust is always needed

Elements of the model • UsersActive agents • CDIsConstrained Data Items • (data that need integrity) • UDIsUnconstrained Data Items • (data that don’t need integrity) • TPs Transformation Procedures • (like commands in Access Control Matrices, but for debit, credit) • IVPsIntegrity Verification Procedures • (run periodically to check integrity of CDIs)

How The Elements Interact Verify integrity USERS Transform: valid  valid IVPs TPs CDIs UDIs

Enforcement Rules at a Glance Certification Rules CR1 IVPs verify CDI integrity CR2 TPs preserve CDI integrity CR3 Separation of duties for ER2 CR4 TPs write to log CR5 TPs upgrade UDIs to CDIs Enforcement Rules ER1 CDIs changed only by authorized TP ER2 TP run only by authorized users ER3 Users are authenticated ER4 Authorizations changed only by certifiers

Certification Rules 1,2,3 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 • A relation certified associates a set of CDIs with a particular TP • Say (before1,after1), (before2, after2) …(beforen, aftern) • Example: TP withdraw money, CDIs accounts, in bank example CR3 The allowed relations must meet the requirements imposed by the principle of separation of duty (SoD) SoD: The principle that says different duties that may result in compromising integrity must not be permitted to be executed by the same process, subject or entity

Certification Rules 4 and 5 CR4 All TPs must append enough information to reconstruct the operation to append-only CDI. • Because the auditor needs to be able to determine what happened during reviews of transactions • Like write-ahead logs in databases CR5 Any TP that takes as input a UDI and (1): either rejects the UDI or (2): transforms it into a CDI. • Example: In a bank, deposit amounts entered at keyboard are UDIs. TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI

Enforcement Rules 1 and 2 ER1 The system must maintain the certified relations and must ensure that only TPs are 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 maintain allowed relation, which restricts access based on user ID

Enforcement Rules 3 and 4 ER3 The system must authenticate each user attempting to execute a TP • Authentication not required before use of the system, but is required before manipulation of CDIs 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 CDI associated with that TP, may ever have execute permission on the TP/CDI • Enforces separation of duty with respect to certified and allowed relations

Key Points • Commercial world needs integrity • Biba model • Dual of BLP (or BLP-upside-down) • Integrity levels distinct from security levels • Information flows differently • Can be combined with BLP • Lipner’s lattice combines the two to meet commercial requirements • Clark-Wilson model • Accounting approaches ported to computer world • Enforcement hierarchy reduces dependency on trusts

ISA 562 Internet Security Theory and Practice