Information Technology Reference
In-Depth Information
Data Classification
One common approach to the classification of data and resources is to
label them as Public, Confidential, Secure, Top Secret, or some such
impressive term. Access control and distribution policies are then defined
for each type. While the policies relating to the handling of a particular
classification may be well thought out, the problem that is often faced is
how to select the correct classification in the first place. Except for trivial
or obvious cases, users remain confused about how to classify data. This
tends to make them over cautious and classify data more stringently than
the situation demands. This affects information flow to both internal and
external parties, the latter being denied information, which they could
safely have accessed. Or they could classify it lower to avoid the hassles
of getting various permissions.
Sometimes, specific data attributes and fields, or combination of fields,
are classified as sensitive. The existence of such fields in any table or
database gets the entire table or database classified as sensitive. The actions
triggered by such classification may be onerous — say, “encrypt every-
thing” — something difficult to implement for various reasons.
Incorrect classification can have unexpected side effects related to
social behavior. Certain categories of classification become a sign of
importance of the content itself — if a memo were important, it would
be “Top Secret,” and so on. What was meant to be a dir ective for
distribution is taken up as a signal of its priority. The reverse logic is then
applied and people automatically assume that memos for public distribu-
tion contain “less important” information. Sometimes, the cost of main-
taining the classification apparatus with all its arbitrariness and
impreciseness is not worth the security it provides.
Exceptions
There is a struggle between having a sound and stringent security policy
on paper, which cannot be implemented, or having a more realistic policy.
The policy remains on paper for legal coverage reasons. Anything infea-
sible or too bothersome is then handled through an exception mechanism
that reviews and grants exceptions to the security requirements on a case-
by-case basis. Large applications may operate for long periods of time
under exceptions that keep getting renewed. This may be a clever way
of solving a tricky problem: operating under an exception satisfies adher-
ence to the security policy because exceptions are part of the security
policy. This is a practical way of operating as long as all parties understand
that getting an exception has not made the risk go away.
