4 A Data Labelling System for Derived Data Control
4.3 Sensitivity Domains and Data Labelling
if r.act 6= read < NA, /0 >
else if r|= zone 6= hospital ∨ zone 6= emr. area < N, /0 >
else if r|= role ≥ Volunteer ∨ role ≥ Constable < Y, {(log(“read”, role, name, dataID)} >
otherwise < NA, /0 >
where we assume rescuers are organised in two role hierarchies, one for the ambulance services and one for the police force whose leaves are volunteers and constables, respectively. Note that the policy does not specify any target. While the compound Boolean expressions might simply include conditions to identify target objects (e.g. an equality condition on a document ID or document type) we decided not to do so because policies are associated with objects through sensitivity levels, as we will describe later. Similarly, the action may be included in the compound Boolean expressions rather than be bound directly to the policy ID. This would make for a simpler notation. Our choices come from the need to strictly organise policies and will be clarified later.
4.3 Sensitivity Domains and Data Labelling
Our solution stems from the idea that data can be protected under different domains and for different inde-pendent reasons. For example, data may be protected because it contains private or commercially sensitive information, or it may be related to public safety or national security. As in multi level security (MLS) systems and Asbestos in particular (see Section 2.3.2), we identify each of such domains (or competence areas) with a security tagand associate it with the data. When the data is modified, the amount of sensitive information it contains for each of the applied domains can either increase or decrease, as shown in Figure 4.2.
Data sensitivity can vary on a fixed range of discrete sensitivity levels for each of the defined domains.
However, multi level security and mandatory access controls might be too rigid for real-world applications, even
Domain 1 Domain 3 Domain 2 Domain n
....
Sensitivity level
Added information Removed information
Data content
Figure 4.2: Mutable information sensitivity for different domains
when discretionary policies are specified to operate within the boundaries of the mandatory policy. Exceptions cannot be dealt with and the tranquillity principle of the Bell-LaPadula model must be respected, i.e. objects’
classifications cannot be changed during normal operations.
While inspired by MLS systems, our approach does not use clearance labels. User clearance should in fact be determined at run-time depending on both context (e.g. time and location) and user attributes and not with a statically assigned label. Moreover, we consider that the classification of an object can vary if (and only if) its content is modified (in other words, as long as data is not modified, it maintains its original classification).
As such, data sensitivity class changes according to the use data is subjected to when received and accessed by recipients. To cater for changing classifications, we devised a solution where each sensitivity class is associated with a set of policies that are applied to objects with that classification. When an object’s classification changes, its applicable policies change accordingly. We associate sensitivity classes with policy sets by defining a lattice of policy sets isomorphic to the lattice of sensitivity classes. In other words, sets of policies must be ordered into a lattice according to the protection level they provide. Figure 4.3 depicts an example lattice defined over two sensitivity domains, privacy (p) and integrity (i). The example shows four ordered sets of policies, two that controls the read and write actions for the privacy domain and two that controls the read and write actions for the integrity domain. How ordered policies can be specified and a lattice created will be explained in the following section.
As in Asbestos, data classification labels representing sensitivity classes are defined as sets of (tag, level) pairs. Each (tag, level) pair is mapped to at most one policy for each action (Figure 4.3) so that the ordering of levels corresponds to the ordering of policies. In other words, each sensitivity level for each tag defines the policies that must control the usage of the so-classified objects and every lattice of data classification labels implies an isomorphic lattice of policy sets (policy lattice in short). Therefore, data is classified under a single
(
{Pread, Pwrite}, {Pread, Pwrite}) (
{Pread, Pwrite}, {Pread, Pwrite})
p = privacy tag i = integrity tag
Pread i,0 = everyone can read high-integrity content with sensitivity level 0 Pread i,1 = everyone can read high-integrity content with sensitivity level 1 Pread p,0 = everyone can read private content with sensitivity level 0
Pread p,1 = only medics and police constables can read private content with sensitivity level 1
Pwrite i,0 = everyone can write high-integrity content with sensitivity level 0
Pwrite i,1 = only police constables can write high-integrity content with sensitivity level 1 i,1 i,1
Pwrite = everyone can write private content with sensitivity level 0
Pwrite = only medics and police constables can write private content with sensitivity level 1 p,1
Figure 4.3: Mapping from lattice of data labels to lattice of policy sets
node of the lattice at any one time depending on its data classification label. Consider two types of documents being disseminated amongst rescuers at the scene of an accident. One contains personal information of a victim found in the area and the other contains information on the rescue operations. Figure 4.3 depicts the policy lattice for such documents. Initially, the documents’ labels are {(p,0) (i,0)} for documents about victims and {(p,0) (i,1)} for documents about the operations. In other words, everyone can read documents of both types, but only police constables can write information on the state of the rescue operations. According to the usages data is subjected to, its classification (i.e. its data classification label) can then either increase or decrease in the lattice (how this is realised will be shown later). In other words, the set of policies applied to the data keeps changing depending on the transformations applied to the data. For example, let us consider the case where someone writes information about her own medical history in an initially empty document about victims. The document’s classification is immediately increased to {(p,1) (i,0)} so that only medics and police constables can read and write it. This approach also allows data originators to protect data integrity as policies are not limited to control read accesses but can also control different operations that can be performed on the data to modify it (e.g. “write”).
In the following we describe how well-formed policy lattices, i.e. lattices where an increase in data classifi-cation actually corresponds to the appliclassifi-cation of a set of stricter usage control policies, can be constructed.