# Mandatory Access Control, part 2
The policies we have examined so far have been primarily concerned with
maintaining secrecy of data. We are also interested in policies that
ensure integrity of data. For instance, a bank is probably much more
interested in ensuring that customers not be able to change account
balances than it is in ensuring that account balances be kept secret.
Although the latter is desirable, unauthorized data modification can
usually cause much more harm to a business than inadvertent disclosure
In 1987, Clark and Wilson examined how businesses manage the integrity
of their data in the "real world" and how such management might be
incorporated into a computer system. In the commercial world, we need
security policies that maintain the integrity of data. In this
environment, illegal data modification occurs due to fraud and error.
And there are two classical techniques to prevent fraud and error.
The first technique is the principle of *Well-formed Transactions*.
Users may not manipulate data arbitrarily, but only in constrained ways
that preserve or establish its integrity. An example of this is
double-entry bookkeeping. This involves making two sets of entries for
everything that happens. Another example is the use of logs. Rather than
erasing mistakes, the sequence of actions that reverses the mistake is
performed and recorded on the log. A record of everything that has
occurred is maintained. Using well-formed transactions makes it more
difficult for someone to maliciously or inadvertently change data.
Another technique to prevent fraud is the principle of *Separation of
Duty*. Here, transactions are separated into subparts that must be done
by independent parties. This works to maintain integrity as long as
there is no collusion between agents working on different subparts. A
typical transaction might look as follows:
- A purchasing agent creates an order. The agent sends the order to
both the supplier and the receiving agent.
- The supplier ships the goods to the receiving department. The
receiving clerk checks the goods that were received against the
original order and updates the inventory records.
- The supplier also sends an invoice to the accounting department. The
accountant checks the invoice against both the original order and
what the shipping clerk said was received. If they match, the
accountant pays the bill.
In this scenario, no one person can cause a problem that will go
unnoticed. The separation of duty rule being employed here is: A person
who can create or certify a well-formed transaction may not execute it.
The question now becomes: How can we employ these commercial principles
in computer systems? Clark and Wilson gave a set of rules for doing so.
They postulate *trusted procedures* (TPs), which are programs that
implement transactions. We summarize the Clark-Wilson rules as:
1. All subjects must be authenticated.
2. All TPs (and the operations they perform) must be logged—i.e., must
3. All TPs must be approved by a central authority.
4. No data may be changed except by a TP.
5. All subjects must be cleared to perform particular TPs by a central
Note how these rules exemplify the gold standard: they address
authentication, audit, and (the final three rules) authorization.
Two other features of the Clark-Wilson model are:
- Data managed by a system may be either *constrained*, meaning it is
governed by the Clark-Wilson rules, or *unconstrained*, meaning that
it is not governed by the rules.
- A system may implement *integrity verification procedures* (IVPs),
which test whether data is in a valid state. All TPs must guarantee
the truth of IVPs.
## Role-based Access Control
In the real world, security policies are dynamic. Access rights, whether
discretionary or mandatory, need to change as the responsibilities of
users change. This can make management of rights difficult. When a new
user is authorized for a system, the appropriate rights for that user
must be established. When a user changes job functions, some rights
should be deleted, some maintained, and some added.
Role-based access control (RBAC) addresses this problem by changing the
underlying subject–object model. A *role* is a job function or
title—i.e., a set of actions and responsibilities associated with a
particular working activity. Now, instead of an access control policy
being a relation on subjects, objects, and rights, a policy is a
relation on roles, objects, and rights; this is called a *right
assignment*. For example, the role "5430 TA" might be assigned the right
to grade 5430 homeworks. Further, subjects are now assigned to roles;
this is called a *role assignment*. Each subject may be assigned to many
roles, and each role may be assigned to many subjects. Finally, roles
are hierarchical. For example, the role "5430 Professor" should have all
the rights that a "5430 TA" does, and more.
Roles are similar to groups in Unix file system DAC. A group is a set of
users with which some rights are associated. The same is true of a role.
But in some implementations, a user is always a member of a group,
whereas a subject may activate or deactivate the rights associated with
any of the subject's roles. This enables finer-grained implementation of
the Principle of Least Privilege. Subjects may login with most of their
roles deactivated, and activate a role only when the rights associated
with the role are necessary. Also, roles may be hierarchical, inheriting
rights from other roles; that is not typically true of groups, even
though it would be possible to implement.
## Clinical Information Systems
*Clinical* aka *medical* information systems have been transitioning
from paper records to electronic records over the last couple decades,
and there have been widespread concerns about privacy as a result.
Doctors and other medical providers, here called *clinicians*, have an
ethical responsibility to maintain confidentiality about their patients'
health concerns. Electronic medical records could endanger that
confidentiality, and their aggregation across multiple clinics could
reveal information that even patients themselves do not know and
certainly never consented to reveal. The British Medical Association
(BMA) asked security researcher Ross Anderson to investigate security
policies for clinical information systems. Here, we summarize [his
The objects in these systems are medical records, and the subjects are
the clinicians. Each record is accompanied by an access control list,
indicating the clinicians that may access the record. Being on the ACL
conveys the right to read the record and the right to append to the
record. Only clinicians are authorized to access records—not
administrators, lawyers, insurance companies, etc. Anyone other than a
clinician instead would receive a copy of the record as it existed at a
particular point in time, and they could modify that record however they
like. One clinician in the ACL is considered the *responsible*
clinician. Only that clinician may modify the ACL. In theory, patients
do have read access to their record, but in practice patients are not
given user accounts on these system, so clinicians instead can print out
the record (or copy it to a USB drive) to share with the patient.
Clinicians often work as teams. So the subjects in ACLs might be groups
as opposed to individual clinicians. Membership in these groups is
sometimes static (e.g., all the nurses at a clinic), and sometimes
dynamic (e.g., any clinician currently on duty in the patient's ward).
Records are created by clinicians. This happens when patients register
at a clinic, or are referred by another clinic. The clinician who
creates the record is added to the ACL and marked as responsible. A
referring clinician would also be added to the record.
In part for audit purposes, records are stored in an append-only format
that makes it possible to reconstruct the record as it existed at any
point in time. Every access to a record is also recorded in the record,
noting the accessing subject's identity, and the time of the access.
That identity must uniquely identify the subject, rather than being a
Clinicians may append new information to records, and that information
must be attributed to the clinician. In theory patients have the right
to register an objection to any information appended to the record. In
practice, that feature is not supported by software; instead, the
clinician would enter the objection on behalf of the patient, and give
the patient a copy of the record to confirm it. Information that is
life critical, such as a Do Not Resuscitate order, may require approval
by a second clinician as well as the patient.
Information that is added to a record might be derived from another
record—perhaps a record about the same patient, or about a related
patient (e.g., a mother and newborn child). By default, such copying
from record A to record B is permitted only if B's ACL is a subset of
A's. That is, the set of readers could become restricted by the copy,
but not enlarged. But if the patient involved in record A consents, the
copying could be allowed regardless. That is, patients may declassify
information about themselves.
Patients with highly sensitive medical conditions may opt to have
separate medical records created regarding those conditions, and for
those records to have more restricted ACLs. In this case, some
clinicians will be operating with limited information about the
patient's health, which could have negative impacts. So the patient's
main records could beneficially indicate to any accessing clinician that
the clinician might want to ask the patient whether there any other
details the patient might want to reveal. Even that single bit of
information—to ask the patient that question—could itself
leak information. In the Netherlands, for example, such a practice led
to pension funds being able to infer that patients had cancer.
Records may eventually be deleted, but entries within records live as
long as the record lives. Clinicians will want to keep records at least
until the possibility of legal liability of malpractice expires. Most
records must be kept at least for eight years. It's unclear whether
patients may insist that records be destroyed.
Patient consent is required whenever a record is created, its ACL is
modified, or responsibility is transferred. In each case, the patient
must be notified of all the subjects on the ACL. This consent is usually
obtained by a blanket release in advance when the patient registers at
the clinic. In some situations, especially in emergencies when
live-critical care needs to be provided by whatever clinician is
available, consent may instead be bypassed. Typically that results in
an after-the-fact notification to the patient, perhaps in an annual
report issued to the patient by the clinic. That affords the patient
the opportunity to at least detect unauthorized access.
It is risky to give any one clinician access to too many records: that
clinician might become corrupted, be blackmailed, or be duped into
running a Trojan horse. What's "too many"? That's hard to quantify.
It's not uncommon for all clinicians at hospital (maybe 2,000) to be
able to access all patients (maybe a million or more). But now suppose
that just 300 hospitals are networked together to use the same clinical
information system. Naively that would mean 600,000 staff have access to
about 300 million records, i.e., the entire population of the US. That
seems to be an unjustifiable risk.
1. Consider the transaction model process described above in the notes
on Clark-Wilson. Explain how that model defends (or does not defend)
against each of the following kinds of fraud.
* An untrustworthy employee in the front office getting paid by issuing a
purchase order to a fake company, delivering no goods, and later submitting
an invoice against that purchase order.
* An untrustworthy employee on the loading dock accepting a delivery but
not recording that fact, thereby allowing the delivered goods to be stolen
instead of transferred into inventory.
* A dishonest supplier delivering goods that had not been ordered but are
nevertheless accepted, thereby creating grounds to be paid.
* An untrustworthy supplier or an accomplice in the billing department submitting
a second invoice against a given purchase order, thereby creating
grounds to be paid double.
2. A doctor might become dependent upon a pain-killing medicine and prescribe
it to him or herself. Discuss how to use RBAC to prevent this situation.
3. Compare and contrast each of the following with the notion of roles that
* Groups, as used with ACLs.
* Compartments, as used with MLS labels.
4. Describe the users, roles, permissions, role inheritance, and constraints
for each of the following systems.
* A course web site that serves notes, problem sets, solution sets, and grades
on assignments and exams.
* A bank information system that serves information about customer accounts
as well as directory and payroll information about the staff.
* A hospital information system that serves patient health records, patient
billing information, directory and payroll information about the staff, purchase
orders and inventory of drugs and other supplies.