Security Policies
To know that an operating
system maintains the security we expect, we must be able to state its security
policy. A security policy is a
statement of the security we expect the system to enforce. An operating system
(or any other piece of a trusted system) can be trusted only in relation to its
security policy; that is, to the security needs the system is expected to
satisfy.
We begin our study of
security policy by examining military security policy because it has been the
basis of much trusted operating system development and is fairly easy to state
precisely. Then, we move to security policies that commercial establishments
might adopt.
Military Security Policy
Military security policy is based on protecting
classified information. Each piece of information is ranked at a particular
sensitivity level, such as
unclassified, restricted, confidential, secret, or top secret. The ranks or
levels form a hierarchy, and they reflect an increasing order of sensitivity,
as shown in Figure 5-1. That is, the
information at a given level is more sensitive than the information in the
level below it and less sensitive than in the level above it. For example,
restricted information is more sensitive than unclassified but less sensitive
than confidential. We can denote the sensitivity of an object O by rankO. In the rest of this chapter
we assume these five sensitivity levels.
Information access is limited by the need-to-know rule: Access to sensitive
data is allowed only to subjects who need to know those data to perform their
jobs. Each piece of classified information may be associated with one or more
projects, called compartments,
describing the subject matter of the information. For example, the alpha
project may use secret information, as may the beta project, but staff on alpha
do not need access to the information on beta. In other words, both projects
use secret information, but each is restricted to only the secret information
needed for its particular project. In this way, compartments help enforce
need-to-know restrictions so that people obtain access only to information that
is relevant to their jobs. A compartment may include information at only one
sensitivity level, or it may cover information at several sensitivity levels.
The relationship between compartments and sensitivity levels is shown in Figure 5-2.
We can assign names to identify the compartments, such as snowshoe,
crypto, and Sweden. A single piece of information can be coded with zero, one, two,
or more compartment names, depending on the categories to which it relates. The
association of information and compartments is shown in Figure 5-3. For example, one piece of information
may be a list of publications on cryptography, whereas another may describe
development of snowshoes in Sweden. The compartment of this first piece of
information is {crypto}; the second is {snowshoe, Sweden}.
The combination <rank;
compartments> is called the class or classification
of a piece of information. By designating information in this way, we can
enforce need-to-know both by security level and by topic.
A person seeking access to sensitive
information must be cleared. A clearance
is an indication that a person is trusted to access information up to a certain
level of sensitivity and that the person needs to know certain categories of
sensitive information. The clearance of a subject is expressed as a combination
<rank; compartments>. This combination has the same form as the classification
of a piece of information.
·
the clearance level of the subject is at least as high as that of
the information and
·
the subject has a need to know about all compartments for which the
information is classified These conditions are equivalent to saying that the
subject dominates the object.
To see how the dominance
relation works, consider the concentric circles in Figure
5-3. According to the relationships depicted there, information
classified as <secret;{Sweden}> could be read by someone cleared for
access to <top secret;{Sweden}> or <secret;{Sweden, crypto}>, but
not by someone with a <top secret;{crypto}> clearance or someone cleared
for <confidential;{Sweden}> or <secret;{France} >.
Military security enforces
both sensitivity requirements and need-to-know requirements. Sensitivity
requirements are known as hierarchical requirements
because they reflect the hierarchy of sensitivity levels; need-to-know
restrictions are nonhierarchical because compartments do not necessarily reflect
a hierarchical structure. This combinational model is appropriate for a setting
in which access is rigidly controlled by a central authority. Someone, often
called a security officer, controls clearances and classifications, which are
not generally up to individuals to alter.
Commercial Security Policies
Commercial enterprises have
significant security concerns. They worry that industrial espionage will reveal
information to competitors about new products under development. Likewise,
corporations are often eager to protect information about the details of
corporate finance. So even though the commercial world is usually less rigidly
and less hierarchically structured than the military world, we still find many
of the same concepts in commercial security policies. For example, a large
organization, such as a corporation or a university, may be divided into groups
or departments, each responsible for a number of disjoint projects. There may
also be some corporate-level responsibilities, such as accounting and personnel
activities. Data items at any level may have different degrees of sensitivity,
such as public, proprietary, or internal; here, the names may vary among
organizations, and no universal hierarchy applies.
Let us assume that public information is less
sensitive than proprietary, which in turn is less sensitive than internal.
Projects and departments tend to be fairly well separated, with some overlap as
people work on two or more projects. Corporate-level responsibilities tend to
overlie projects and departments, as people throughout the corporation may need
accounting or personnel data. However, even corporate data may have degrees of
sensitivity. Projects themselves may introduce a degree of sensitivity: Staff
members on project old-standby have no need to know about project new-product,
while staff members on new-product may have access to all data on old-standby.
For these reasons, a commercial layout of data might look like Figure 5-4.
Two significant differences
exist between commercial and military information security. First, outside the
military, there is usually no formalized notion of clearances: A person working
on a commercial project does not require approval for project MARS access by a
central security officer. Typically, an employee is not conferred a different
degree of trust by being allowed access to internal data. Second, because there
is no formal concept of a clearance, the rules for allowing access are less
regularized. For example, if a senior manager decides that a person needs
access to a piece of MARS internal data, the manager will instruct someone to
allow the access, either one-time or continuing. Thus, there is no dominance
function for most commercial information access because there is no formal
concept of a commercial clearance.
So far, much of our
discussion has focused only on read access, which addresses confidentiality in
security. In fact, this narrow view holds true for much of the existing work in
computer security. However, integrity and availability are at least as
important as confidentiality in many instances. Policies for integrity and
availability are significantly less well formulated than those for
confidentiality, in both military and commercial realms. In the two examples that
follow, we explore some instances of integrity concerns.
ClarkWilson Commercial Security Policy
In many commercial applications, integrity can
be at least as important as confidentiality. The correctness of accounting
records, the accuracy of legal work, and the proper timing of medical
treatments are the essence of their fields. Clark and Wilson [CLA87] proposed a policy for what they call well-formed transactions, which they
assert are as important in their field as is confidentiality in a military realm.
To see why, consider a company that orders and pays for materials.
A representation of the procurement process might be this: A purchasing clerk
creates an order for a supply, sending copies of the order to both the supplier
and the receiving department.
The supplier ships the goods, which arrive at the receiving
department. A receiving clerk checks the delivery, ensures that the correct
quantity of the right item has been received, and signs a delivery form. The
delivery form and the original order go to the accounting department.
The supplier sends an invoice to the accounting department. An
accounting clerk compares the invoice with the original order (as to price and
other terms) and the delivery form (as to quantity and item) and issues a check
to the supplier.
The sequence of activities is
important. A receiving clerk will not sign a delivery form without already
having received a matching order (because suppliers should not be allowed to
ship any quantities of any items they want and be paid), and an accounting
clerk will not issue a check without already having received a matching order
and delivery form (because suppliers should not be paid for goods not ordered
or received). Furthermore, in most cases, both the order and the delivery form must
be signed by authorized individuals. Performing the steps in order, performing
exactly the steps listed, and authenticating the individuals who perform the
steps constitute a well-formed transaction. The goal of the ClarkWilson policy
is to maintain consistency between the internal data and the external (users')
expectations of those data.
Clark and Wilson present their policy in terms
of constrained data items, which are
processed by transformation procedures.
A transformation procedure is like a monitor in that it performs only
particular operations on specific kinds of data items; these data items are
manipulated only by transformation procedures. The transformation procedures
maintain the integrity of the data items by validating the processing to be
performed. Clark and Wilson propose defining the policy in terms of access triples: <userID, TPi,
{CDIj, CDIk, ...}>,
combining a transformation procedure, one or
more constrained data items, and the identification of a user who is authorized
to operate on those data items by means of the transaction procedure.
Separation of Duty
A second commercial security
policy involves separation of responsibility. Clark and Wilson [CLA87] raised this issue in their analysis of
commercial security requirements, and Lee [LEE88]
and Nash and Poland [NAS90] added to the
concept.
To see how it works, we
continue our example of a small company ordering goods. In the company, several
people might be authorized to issue orders, receive goods, and write checks.
However, we would not want the same person to issue the order, receive the
goods, and write the check, because there is potential for abuse. Therefore, we
might want to establish a policy that specifies that three separate individuals
issue the order, receive the goods, and write the check, even though any of the
three might be authorized to do any of these tasks. This required division of
responsibilities is called separation of
duty.
Separation of duty is commonly accomplished
manually by means of dual signatures. Clark and Wilson triples are
"stateless," meaning that a triple does not have a context of prior
operations; triples are incapable of passing control information to other
triples. Thus, if one person is authorized to perform operations TP1
and TP2, the Clark and Wilson triples cannot prevent the same person
from performing both TP1 and TP2 on a given data item.
However, it is quite easy to implement distinctness if it is stated as a policy
requirement.
Chinese Wall Security Policy
Brewer and Nash [BRE89] defined a security policy called the
Chinese Wall that reflects certain commercial needs for information access
protection. The security requirements reflect issues relevant to those people
in legal, medical, investment, or accounting firms who might be subject to
conflict of interest. A conflict of interest exists when a person in one
company can obtain sensitive information about people, products, or services in
competing companies.
The security policy builds on
three levels of abstraction.
·
Objects. At the lowest level are elementary objects, such as files.
Each file contains information concerning only one company.
·
Company groups. At the next level, all objects concerning a
particular company are grouped together.
·
Conflict classes. At the highest level, all groups of objects for
competing companies are clustered.
With this model, each object
belongs to a unique company group, and each company group is contained in a
unique conflict class. A conflict class may contain one or more company groups.
For example, suppose you are an advertising company with clients in several
fields: chocolate companies, banks, and airlines. You might want to store data
on chocolate companies Suchard and Cadbury; on banks Citicorp, Deutsche Bank,
and Credit Lyonnais; and on airline SAS. You want to prevent your employees
from inadvertently revealing information to a client about that client's
competitors, so you establish the rule that no employee will know sensitive
information about competing companies. Using the Chinese Wall hierarchy, you
would form six company groups (one for each company) and three conflict
classes: {Suchard, Cadbury}, {Citicorp, Deutsche Bank, Credit Lyonnais}, and
{SAS}.
The hierarchy guides a simple access control
policy: A person can access any information as long as that person has never
accessed information from a different company in the same conflict class. That
is, access is allowed if either the object requested is in the same company
group as an object that has previously been accessed or the object requested
belongs to a conflict class that has never before been accessed. In our
example, initially you can access any objects. Suppose you read from a file on
Suchard. A subsequent request for access to any bank or to SAS would be
granted, but a request to access Cadbury files would be denied. Your next
access, of SAS data, does not affect future accesses. But if you then access a
file on Credit Lyonnais, you will be blocked from future accesses to Deutsche
Bank or Citicorp. From that point on, as shown in Figure
5-5, you can access objects only concerning Suchard, SAS, Credit
Lyonnais, or a newly defined conflict class.
The Chinese Wall is a commercially inspired
confidentiality policy. It is unlike most other commercial policies, which
focus on integrity. It is also interesting because access permissions change
dynamically: As a subject accesses some objects, other objects that would
previously have been accessible are subsequently denied.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.