Confidentiality, Integrity, and Availability

The 3 basic actions of a person on an item of data: viewing (confidentiality), modifying (integrity), using (availability).

Confidentiality

Ensuring confidentiality raises several open questions:

• Who determines which people or systems are authorized to access a system.
• Whether authorized access covers part or all of a data collection.
• Whether an authorized party can access pieces of data out of context.
• Whether an authorized party can disclose data they access to other parties.
• Who owns data generated indirectly, e.g. the fact that a user clicked a link on a web page.

Modeling Confidentiality

A general statement on confidentiality: a person, process, or program is (or is not) authorized to access a data item in a particular way.

The security model consists of:

• Subject
  The person, process, or program.
• Object
  The data item.
• Access mode
  The kind of access, such as read, write, or execute.
• Policy
  The authorization.

Confidentiality Violations

Examples:

• An unauthorized person, process or program accesses a data item.
• An authorized person accesses data they are not authorized to access, a privilege violation.
• A person accesses data in a manner allowing inference of data whose access is unauthorized, e.g. a medical condition inferred through pharmaceutical purchases.
• An unauthorized person learns of the existence of a piece of data, e.g. a company takeover inferred through updates to financial reports.

Integrity

Interpretations of an item’s integrity:

• Precise.
• Accurate.
• Unmodified.
• Modified only in acceptable ways.
• Modified only by authorized people.
• Modified only by authorized processes.
• Consistent, internally consistent.
• Meaningful and usable.

Availability

Availability applies to both data (information) and services (information processing).

An item of data or a specific service is available iff:

• It is present in a usable form.
• It has enough capacity to meet the service’s needs.
• It is making clear progress, and if in wait mode, has a bounded waiting time.
• The service completes in an acceptable period of time.

Availability overlaps with related non-functional requirements: capacity, performance, fault tolerance, usability.

Access Control

Builds on the paradigm, reference monitor, and matrix/ACL/capability/RBAC mechanisms covered in Access Control. The models below extend that base for specific computer security objectives.

BLP Model

Enforces data confidentiality in multi-level systems. By David Bell and Leonard La Padula.

Every subject has a clearance level. Every object has a classification level. Levels form a lattice.

A class is a pair $\langle \text{rank}, \text{compartment} \rangle$ assigned to both subjects and objects.

• Rank
  A sensitivity level, e.g. top secret, secret, confidential, restricted, unclassified.
• Compartment
  A category grouping related information, e.g. a project name or region.

Class $D_1 \le D_2$ iff $\text{rank}_1 \le \text{rank}_2$ and $\text{compartment}_1 \subseteq \text{compartment}_2$. This dominance relation applies to subjects (clearance) and objects (classification) alike.

Rules:

• Simple security property, no read up
  A subject can read an object only when the subject clearance dominates the object classification.
• Star property, no write down
  A subject can write an object only when the object classification dominates the subject clearance.

Information flows only upward. A discretionary access matrix applies on top. Declassification needs a trusted subject outside the rules. Says nothing about integrity.

Biba Model

Enforces data integrity. By Kenneth Biba. The dual of the BLP model, with integrity levels replacing secrecy levels.

Rules:

• Simple integrity property, no read down
  A subject can read an object only when the object integrity level is at least as high as the subject integrity level.
• Star integrity property, no write up
  A subject can write an object only when the subject integrity level is at least as high as the object integrity level.

Information flows only downward in integrity. Untrusted data cannot reach a high-integrity subject.

Separation of Duty

Separation of duty requires that a sensitive action need approval from 2 or more distinct authorized people, so no single person can act alone.

• A check over $10,000 is only valid if signed by 2 authorized people.
• The 2 signers must be different people.
• The policy involves both role membership and an inequality between the signers, which a matrix entry cannot express.

Chinese Wall Model

Prevents conflict of interests in shared information systems. By David Brewer and Michael Nash.

Objects are grouped into company datasets. Company datasets are grouped into conflict-of-interest classes.

Access is history-based, so the accessible set differs per subject and shrinks over time.

Rules:

• Read
  A subject can read an object only when the object is in a company dataset the subject already accessed, or in a conflict class the subject has not yet touched.
• Write
  A subject can write an object only when the subject cannot read any object in a different company dataset.

Effect: no fixed lattice. The policy is dynamic and per-subject.

Examples:

• Lawyers $L_1$ and $L_2$ work at the same firm.
• If company $C_1$ competes with $C_2$, $L_1$ and $L_2$ can each work for either $C_1$ or $C_2$, but no lawyer can work for both competing firms.
• Whether a permission is granted depends on which other permissions that subject has already used.

Capabilities in Amoeba

Amoeba is a distributed capability-based operating system, implementing the capability concept across multiple processors connected by a network.

• Each object resides on a server, identified within a capability by a server port and an object number, alongside a rights field and a check field.
• The check field is an unforgeable random value the server uses to verify a capability was not forged, letting protection be enforced entirely by the user-level server process, without special OS support.
• An owner capability grants every right. The owner can derive a capability with fewer rights, whose check field is computed from the original so the server can still verify it.

Unix File Security

Every Unix file has an owner and a group, with read, write, and execute permissions set separately for owner, group, and other. Only the owner or root can change a file’s permissions.

• Each process carries a real, effective, and saved user ID.
• The effective ID determines the process’s actual permissions.
• The setuid bit on an executable file lets a process temporarily run with the file owner’s identity instead of the caller’s.

Setuid scripts are a bad idea, historically prone to race conditions where an attacker changes the contents of a program after it begins executing but before it loads.

Windows Access Control

Windows NTFS extends the same access list idea: each object carries a security descriptor with an owner, a group, and a discretionary access control list (DACL) of allowed users and groups, checked by priority of explicit deny, explicit allow, inherited deny, then inherited allow.

• A security identifier (SID) replaces the Unix UID as the identity of a principal.
• An impersonation token lets a thread temporarily adopt another user’s security context, similar in purpose to Unix setuid.