c o m p u t e r s & s e c u r i t y 2 8 ( 2 0 0 9 ) 2 – 7

ava i lab le a t www.sc iencedi rec t .com

journa l homepage : www.e lsev ier . com/ loca te /cose

Building access control models with attributeexploration

Sergei Obiedkova,b, Derrick G. Kouriea,*, J.H.P. Eloffa

aDepartment of Computer Science, University of Pretoria, Pretoria 0002, South AfricabDepartment of Applied Mathematics, Higher School of Economics, Moscow, Russia

a r t i c l e i n f o

Article history:

Received 24 April 2007

Accepted 30 July 2008

Keywords:

Mandatory access control models

Lattice-based access control models

Concept lattices

Attribute exploration

Implications

* Corresponding author.E-mail addresses: sergei.obj@gmail.com (

0167-4048/$ – see front matter ª 2008 Elsevidoi:10.1016/j.cose.2008.07.011

a b s t r a c t

The use of lattice-based access control models has been somewhat restricted by their

complexity. We argue that attribute exploration from formal concept analysis can help

create lattice models of manageable size, while making it possible for the system designer

to better understand dependencies between different security categories in the domain

and, thus, providing certain guarantees for the relevance of the constructed model to

a particular application. In this paper, we introduce the method through an example.

ª 2008 Elsevier Ltd. All rights reserved.

1. Introduction regard an information flow policy as a finite lattice (Denning,

There are two fundamental classes of access control models:

discretionary and mandatory (DAC and MAC) (Gollmann,

2005). In discretionary models, the owner of the resource is in

charge of granting or denying any other subject or group of

subjects access to this resource. A mandatory model involves

a certain system-wide policy determining access rights so

that the users do not have full control over the access to

resources they create. MAC-based models have the advan-

tage of enforcing consistency in the way access requests are

handled, since all subjects and objects in the environment

are bound by the same rules. Thus, they are easier to control

and more reliable (albeit less flexible) than DAC-based

models, where access rights are ad hoc decisions made by

individual users.

Important examples of mandatory access control policies

are given by the Bell and LaPadula (1975) and Biba (1977)

models. Both models are based on lattices (Birkhoff, 1973) and

Denning’s axioms that must be accepted in order to be able to

S. Obiedkov), dkourie@cser Ltd. All rights reserved

1976). When describing access control models, we follow the

presentation in Sandhu (1993) and concentrate on lattice-

related aspects.

Most lattice-based access control models are employed in

a military environment. However, if the concept of security

levels are customized, for instance, to only two levels, e.g.,

private and public, these type of models become attractive for

commercial environments (Pfleeger and Pfleeger, 2003).

Interesting to note that Lloyds TSB (McCue, 2002), a major

international bank, created a multi-level security architecture

which reflects different risk exposures in different application

domains. Furthermore the commercial adoption of lattice-

based models is demonstrated in Holeman et al. (2002)

through the development of a secure multicasting system.

This system enables members of a network domain to

exchange and broadcast messages at different sensitivity

levels.

In lattice-based models, subjects and objects are assigned

security labels from a partially ordered universe, which is, in

.up.ac.za (D.G. Kourie), eloff@cs.up.ac.za (J.H.P. Eloff)..

c o m p u t e r s & s e c u r i t y 2 8 ( 2 0 0 9 ) 2 – 7 3

fact, a lattice. The information is allowed to flow only in one

direction within the lattice: for example, from entities with

labels that are lower in the lattice to labels that are higher.

Thus, the partial order of the lattice indicates which labels

should be assigned to more secure and which to less secure

entities.

In many cases, a security label is a set of categories

(projects, departments, etc.) augmented with a security level

(unclassified, secret, top secret, etc.). The lattice of all possible

combinations of security levels and subsets of categories

grows linearly in the number of levels and exponentially in

the number of categories. In the small example, we use in the

following sections, we deal with two levels and five categories,

which gives us 64 possible security labels. Doubling the

number of levels results in doubling the number of labels, but

doubling the number of categories yields 2048 labels (if we

keep the number of levels at two). The size of the security

lattice puts constraint on practical implementation, which is

part of the reason why lattice-based models are not so widely

used as they could be. Large models are hard to visualize and,

therefore, hard to maintain: the assignment of categories to

subjects and objects is likely to be error-prone, as, without

a complete picture of the model, it is difficult to check the

effect this or that assignment may have.

However, out of all possible combinations of security levels

and categories, only some are meaningful as security labels.

The model presented in Smith (1990) makes use of only 21 out

of the possible 1024 labels arising from four levels and eight

categories. This reduction suggests that the levels and cate-

gories are not mutually independent in the domain for which

the model is built. Knowing dependencies between the levels

and categories of the domain is certainly of great help for the

system designer. Hence, the challenge is to identify these

dependencies and, by extension, the realistic combinations of

security levels and categories. In Section 3, we describe

a technique from formal concept analysis (Ganter and Wille,

1999), called attribute exploration, that can help the system

developer to do so in a transparent and reliable way.

2. Lattice-based access control

Different access control models deal with different issues. The

most important concerns include the following two:

Confidentiality: prevention of unauthorized disclosure of

information.

Integrity: prevention of unauthorized modification of

information.

The Bell–LaPadula model deals with confidentiality and the

Biba model deals with integrity. Both base the policy on

security labels. We focus on a particular type of security label,

which originates in the military domain, but which makes

perfect sense in commercial and other applications.

Let (H, <) be a totally ordered set of security levels (as usual,

we use� for ‘< or¼’) and C be a set of categories. Categories can

be, e.g., names of projects or departments within a company.

A compartment is a subset of categories D 4 C. A security label is

a pair (h, D), where h ˛ H is a security level and D 4 C is

a compartment.

There is a natural partial order on the set of all possible

security labels for given levels (H, <) and categories C: (h,

D)� (g, E) if and only if h� g and D 4 E (again, we use < to

denote ‘� and s’). This partial order is obviously a lattice

(Birkhoff, 1973), i.e., every two labels have the least upper

bound and the greatest lower bound:

ðh;DÞnðg;EÞ ¼ ðmaxðh; gÞ; DWEÞ;ðh;DÞnðg;EÞ ¼ ðminðh; gÞ; DXEÞ;

where max(h, g) is the maximal and min(h, g) is the minimal

(with respect to the order < on H) of the two security levels h

and g. For the sake of conciseness, the lattice of security labels

will sometimes be called the security lattice.

Subjects (e.g., users or programs that access information)

and objects (e.g., programs or files being accessed by subjects)

of the system are assigned labels from the security lattice. The

interpretation of the partial order on the labels depends on the

model. For example, in the Bell–LaPadula model, (h, D)< (g, E)

means that (g, E) is ‘‘more confidential’’ than (h, D); hence,

a subject labeled (h, D) should not be able to read a document

labeled (g, E). The information is allowed to flow only upwards:

from entities with lower labels to entities with higher labels.

Assuming that l(e) is the security label of the entity e, this

policy is summarized by the following two rules:

– Simple-security property: Subject s can read object o only if

l(o)� l(s).

– *-property: Subject s can write object o only if l(s)� l(o).

The simple-security property ensures that a subject can

read an object only if the subject is at the same security level

as the object or higher and if the subject has access to all

categories associated with the object. The reason for intro-

ducing the *-property is to avoid the situations when, for

example, a secret subject reads a secret document and creates

its unclassified copy accessible to unclassified subjects. The

*-property guarantees that any object is accessible only to

subjects having the same security label as the creator of the

object or higher.

In the case of the Biba model, (h, D)< (g, E) stands for ‘‘(g, E)

is of higher integrity than (h, D)’’. In order to prevent

contamination of ‘‘clean’’ higher-level entities with informa-

tion from ‘‘dirty’’ lower-level entities, the information is

allowed to flow only downwards: from entities with higher

integrity to entities with lower integrity. Assuming that u(e) is

the integrity level of the entity e, the rules of the model are

formulated as follows (Sandhu, 1993):

– Simple-integrity property: Subject s can read object o only if

u(s)�u(o)

– Integrity *-property: Subject s can write object o only if

u(o)�u(s)

For our present discussion, it is not important whether the

information flows upwards or downwards; it only matters

that it always flows in one direction. The problem here is the

size of the security lattice, which is jHj$2jCj for security levels H

and categories C. Even for small numbers of levels and

c o m p u t e r s & s e c u r i t y 2 8 ( 2 0 0 9 ) 2 – 74

categories, the resulting lattice may be far too large for prac-

tical purposes, at least, if it is desirable to be able to get an

overview of the entire model. However, as mentioned above,

not all conceivable security labels make sense for a particular

application. On the contrary, one should expect the number of

useful security labels to be fairly small as compared to the

theoretical maximum (Sandhu, 1993). The job of the system

developer is to identify appropriate labels. In the next section,

we introduce a technique, called attribute exploration, that

can help organizing this in a semi-automatic fashion.

3. Attribute exploration as a tool for buildingaccess control models

The attribute exploration process is quite standard in formal

concept analysis (Ganter and Wille, 1999). In its simplest

version it can be summarized as follows. Given a set of objects

of a subject domain, which is known to have considerably

more (perhaps, an infinite number of) such objects, and their

unified descriptions in terms of presence or absence of certain

attributes, attribute exploration aims to build an implicational

theory of the entire domain and a representative (in a very

precise sense) set of its objects. The implicational theory of the

domain is the set of implications of the form ‘‘if an object

possesses all attributes from the set A, then it also possesses

all attributes from the set B’’ that are believed to hold for all

objects of the domain. For such a set, it is always possible to

find a canonical minimal representation, the Duquenne–Gui-

gues basis of implications, from which all valid implications

can be inferred (Guigues and Duquenne, 1986). The repre-

sentative set of objects should respect all implications from

the generated implication basis and provide a counterex-

ample for every implication that cannot be inferred from the

basis (it means, in particular, that the concept lattice of the

domain is isomorphic to the concept lattice of this relatively

small set of objects).

To show how attribute exploration can be used in our case,

we first introduce basic notions from formal concept analysis

(FCA) (Ganter and Wille, 1999).

Definition 1. A (formal) context is a triple K ¼ ðG;M; IÞ, where

G is interpreted as a set of objects, M as a set of attributes, and

the relation I 4 G�M specifies which objects have which

attributes.

The following derivation operators are defined for object

and attribute subsets:

Definition 2. For the context (G, M, I ) and sets A 4 G and

B 4 M

AI :¼�

m˛Mjðg;mÞ˛I for all g˛A�

BI :¼�

g˛Gjðg;mÞ˛I for allm˛B�

If it does not result in ambiguity, one writes A0 and B0 instead of

AI and BI.

In words, A0 is the set of all attributes shared by all objects

from A and B0 is the set of all objects that share all attributes

from B.

Definition 3. A pair (A, B), where A 4 G, B 4 M, A0 ¼ B, and

B0 ¼A, is called a (formal) concept (of the context K) with

extent A and intent B. A concept (A, B) is more general (less

specific, etc.) than a concept (C, D), if C 4 A (equivalently,

B 4 D); notation: (C, D)� (A, B).

Thus, a formal concept is characterized extensionally by

a set of objects that it covers and intensionally by the set of

attributes an object must have to be considered an instance of

this concept.

The set of all concepts of the context K ordered by � forms

a complete lattice called the concept lattice of K and denoted by

B ðKÞ. It can be shown that every complete lattice is isomor-

phic to the concept lattice of some formal context (Ganter and

Wille, 1999).

In formal context analysis, it is also possible to work with

objects described by many-valued attributes taking values

from a certain domain (as opposed to one-valued attributes

that objects simply may or may not have).

Definition 4. A many-valued context is a quadruple (G, M, W,

I ), where G and M are object and attribute sets, respectively; W

is a set of attribute values; and I 4 G�M�W is a ternary

relation satisfying the following condition:

ðg;m;wÞ˛I and ðg;m;vÞ˛I0w ¼ v:

Many-valued attributes must first be transformed into

a series of one-valued attributes by means of plain conceptual

scaling. For a many-valued attribute m, define a scale Sm¼ (Gm,

Mm, Im), where Gm is the set of all possible values of the attri-

bute m, i.e., {wjw ˛ W and dg ˛ G:(g, m, w) ˛ I} 4 Gm. The rela-

tion Im translates every value of m into a subset of Mm. Then,

the many-valued context (G, M, W, I) is replaced by the one-

valued context

ðG; Wm˛Mfmg �Mm; JÞ;

where ( g, (m, n)) ˛ J if and only if there is w ˛ W such that ( g, m,

w) ˛ I and (w, n) ˛ Im.

We can express an access control model of the type dis-

cussed above by a formal context, whose object set contains

entities (subjects and objects) and the attribute set consists of

the security level and categories. The only many-valued

attribute is the security level. Since security levels are totally

ordered, it is natural to use an ordinal scale to transform the

many-valued security level attribute into a number of one-

valued attributes. Given a set of security levels H¼ {h1,., hn}

with hi< hj (i.e., hj corresponds to a higher level than hi) if i< j,

we use the context (H, H,�) as a scale. For example, we use the

following scale for n¼ 5:

Security Levels h1 h2 h3 h4 h5

h1

� h2 � � h3 � � � h4 � � � � h5 � � � � �

In the context obtained using this scale, each security level h

becomes a one-valued attribute and an entity gets this attri-

bute if its security level is h or higher.

c o m p u t e r s & s e c u r i t y 2 8 ( 2 0 0 9 ) 2 – 7 5

Definition 5. A security context is a formal context (E, H W C,

I ), where

– E is the set of entities (subjects and objects);

– (H, <) are security levels;

– C are categories;

– for all e ˛ E and h ˛ H, (e, h) ˛ I if and only if he is the

security level of e and h� he;

– all e ˛ E and c ˛ C, (e, c) ˛ I if and only if the category c is

assigned to the entity e.

The concept lattice of a security context defines an access

control model. The problem here is that, in practice, the

security context is unavailable at the design time and, in the

case of open systems allowing introduction of new entities

throughout the lifetime of the system, the security context

can never be available in its entirety.

However, given that we deal with a finite number of fixed

categories and levels, the concept lattice of this theoretically

infinite security context will be finite. This means that there is

a finite context whose concept lattice is isomorphic to the

concept lattice of the security context. There is a technique,

called attribute exploration, that allows one to identify such

a finite representation context. To see how it works, we need to

give the definition of an implication:

Definition 6. An attribute (object) implication is an expression

A / B, where A, B 4 M (respectively, A, B 4 G). The implica-

tion A / B holds in a context K if and only if A0 4 B0.

In words, an attribute implication A / B holds in a context

K if every object of K that has all attributes from A also has all

attributes from B (similarly, for object implications).

Definition 7. A set C 4 M respects an attribute implication

A / B if and only if A ? C or B 4 C (similarly, for object

implications). If every set that respects all implications from

an implication set S also respects an implication A / B, we

say that A / B (semantically) follows from S.

From an implication set S, another implication set U, called

the Duquenne–Guigues basis of S, can be derived in a canonical

way so that all implications of S semantically follow from U

and vice versa (Guigues and Duquenne, 1986). In this sense, S

and U are equivalent, while the Duquenne–Guigues basis of S is

defined so that it includes the smallest possible number of

implications among implication sets equivalent to S.

A family of attribute sets respecting all implications from

a certain set S is closed under intersection, and, hence, it

forms a lattice. In fact, attribute sets respecting all implica-

tions of a formal context K are precisely intents of the concept

lattice of K (see Definition 3). Thus, it is possible to reconstruct

the concept lattice of a context from the Duquenne–Guigues

basis of the set of implications holding in the context (we call

this the Duquenne–Guigues basis of the context).

The goal of attribute exploration over a context K is to

generate the Duquenne–Guigues implication basis of K and an

associated representation context (i.e., a context the concept

lattice of which is isomorphic to the concept lattice of K). The

process is interactive. In the general setting, the computer

suggests implications one by one and the user (the expert)

accepts them or provides counterexamples. Attribute explo-

ration can work even if the initial set of objects is empty. It is

designed to be as efficient as possible, i.e., to suggest as few

implications as possible without any loss in completeness of

the result. This is achieved by generating implications from

the Duquenne–Guigues basis in the order consistent with the

subset ordering of implication premises (from smaller to

larger premises). Then, if the user rejects an implication A / B

at some step, it does not affect any implication whose premise

is not a superset of A: if such implications are in the basis, they

will remain there.

We will introduce the method using the example from

(Lipner, 1982). A more formal description, including algo-

rithmic issues, can be found in, e.g., (Ganter, 1999).

In Lipner (1982), he proposed a specification of the Bell–

LaPadula access control model for commercial applications.

Lipner used two security levels: Audit Manager (AM) and

System Low (SL). AM is the highest level of the two; it is

reserved for system audit and management functions. Five

categories are defined as follows:

– Development (D): production programs under develop-

ment that are not yet in use;

– Production Code (PC): production processes and

programs;

– Production Data (PD): data covered by integrity policy

– System Development (SD): system programs in develop-

ment but not yet in use

– Software Tools (T): programs on production system not

related to protected data

In order to translate this into a security context in the sense

of Definition 5, we use the following simple scale for the

security levels:

SL AM

SL

� AM � �

Scales for many-valued attributes may serve to provide

background knowledge for attribute exploration. Indeed, such

a scale describes all possible combinations of one-valued

attributes replacing the many-valued attribute. Advanced

versions of attribute exploration can take into account this

knowledge represented by so-called cumulated Horn clauses

and, thus, reduce the number of questions asked (Ganter and

Krausse, 1999): a question is not asked if the answer follows

from the background knowledge combined with already

accepted implications. In the case of security levels, the

Duquenne–Guigues basis provides a complete axiomatization

of the corresponding scale; hence, our background knowledge

is entirely implicational. In general, assuming that l ˛ H is the

lowest security level, the Duquenne–Guigues basis of the

context (H, H, �) is as follows:

Ø/flg

fl;hg/fkjk � hg

c o m p u t e r s & s e c u r i t y 2 8 ( 2 0 0 9 ) 2 – 76

for all h ˛ H such that dj ˛ H(l< j< h). In the example we use,

there are only two levels; therefore, the basis consists of only

one implication reflecting the fact that all objects have the SL

attribute:

Ø/fSLg (1)

We start with the context (Ø, {AM, SL, D, PC, PD, SD, T}, Ø).

The first question asked by attribute exploration is whether all

objects should have all attributes, to which the answer is,

clearly, ‘‘no’’. The first counterexample we provide is of an

object we call the ordinary user (ou), who can read production

data and execute production codedall at the system low level;

ordinary users do not write their own programs, but use

existing programs and databases (hence, do not need software

tools): ou0 ¼ {SL, PC, PD}.

Next, the program asks us whether all objects have at least

all the same attributes as ordinary users, i.e., SL, PC, and PD.

Since this is not true, e.g., for application developers, who

should not have direct access to production data, we add an

object ad to our context, where ad0 ¼ {SL, D, T}. Application

developers work on their development system; if they need

access to actual data (for testing purposes), they should use it

only on the development system.

The only thing in common between ordinary users and

application developers is that they work at the System Low level.

Without background knowledge, the system would ask us if

every object has the SL attribute, that is, is at least at the System

Low level. However, given background knowledge in Eq. (1),

there is no need to ask this question. Hence, the next question is

if everyone having access to software tools (T) must also have

access to production programs in development (D), to which the

counterexample is system programmers (sp): sp0 ¼ {SL, SD, T}.

The algorithm then asks if everyone having access to system

programs in development (SD) should have access to software

tools (T), and it seems reasonable to agree with this, as software

tools are needed for program development.

Proceeding as above, we accept six implications and

provide two counterexamples before the attribute exploration

stops (see Table 1).

The resulting lattice is shown in Fig. 1.

This lattice contains eight nodes, which is significantly less

than 64 nodes theoretically possible for a lattice on two

security levels and five categories. The information flow policy

defined by this lattice can also be summarized by the six

Table 1 – An example of attribute exploration

# Question Answer Counterexample

/ / / /

4 {SD} / {T}? Yes

5 {PD} / {PC}? Yes

6 {PC} / {PD}? No: Production code

pc0 ¼ {SL, PC}

7 {PC, T} / {AM, D, PD, SD}? No: System controllers

sc0 ¼ {SL, D, PC, PD, SD, T}

8 {PC, T} / {D, PD, SD}? Yes

9 {D} / {T}? Yes

10 {D, SD, T} / {PC, PD}? Yes

11 {AM} / {D, PC, PD, SD, T}? Yes

implications we have accepted and one implication from the

background knowledge:

Ø / {SL}

{SD} / {T}

{PD} / {PC}

{PC, T} / {D, PD, SD}

{D} / {T}

{D, SD, T} / {PC, PD}

{AM} / {D, PC, PD, SD, T}

The first of these implications simply states that the lowest

security level is SL. The last implication suggests that there is

only one security label involving the highest security level,

AM, namely, the system top label; in other words, subjects at

the AM level have access to everything. Then, for example,

implications {SD} / {T} and {D} / {T} mean that subjects

dealing with system or production programs in development

must also have access to software tools, since they need them

to write programs.

In a well-structured domain, the result of attribute explo-

ration does not depend on particular objects entered as

counterexamples. Indeed, if we use attribute exploration to

study properties of finite lattices, as it was done in (Reeg and

Weiß, 1990), then we will end up with the same implication

theory over these properties, no matter what finite lattices we

provide as counterexamples (but, of course, only if our coun-

terexamples are valid and the implications we accept do hold

in reality). In the case of access control models, such guar-

antees are somewhat more tentative. The reason is that here,

unlike with properties of finite lattices, there is no objective

reality to be uncovered; the implications we accept are part of

the model we are building, and we have different options for

which implications to include in it. There simply does not

have to be one model that is perfect for the chosen applica-

tion. Hence, the decisions we make when answering ques-

tions during attribute exploration can lead to different

models. In any case, we have to explicitly consider these

questions, which reduces the possibility of overlooking some

details. The model we build is available in the form of a lattice,

but also as a set of rules summarized by the Duquenne–Gui-

gues basis, which provides a nice summary of the access

Fig. 1 – A lattice obtained by attribute exploration.

c o m p u t e r s & s e c u r i t y 2 8 ( 2 0 0 9 ) 2 – 7 7

control policy and which can be reviewed at any time should

the need arise.

4. Conclusion and further work

In this paper, we suggested that attribute exploration from

formal concept analysis can be used to build lattice-based

access control models in an interactive fashion. The method

brings some order into the work of system developers forcing

them to consider one by one dependencies between security

labels. At the same time, it tries to minimize the required

effort by following the implications in the minimal (Duqu-

enne–Guigues) basis.

To use attribute exploration, the system developer first

needs to identify security categories and levels. Alternatively,

it is possible to identify subjects and objects and use object

exploration, which is a dual of attribute exploration: it asks the

user to confirm or reject object implications and provide

attributes as counterexamples. Security categories and levels

can be derived in this way. In our example, a object implica-

tion ou / ad can be understood as ‘application developers

can access anything that can be accessed by ordinary users’. If

we reject this implication, we have to devise a category

accessible to ordinary users, but not application developers (or

a higher security level for ordinary users than for application

developers); for example, this will be the category PD

(production data) in our case. Thus, we can start with a small

set of subjects and objects and a small set of categories and

apply object and attribute exploration interchangeably to

enlarge both sets and build a realistic model. The construction

of a specialized tool that implements this technology specifi-

cally for building access control models may be a matter of

future work.1

An example given in Lipner (1982) combines the Bell–

LaPadula and Biba models in order to address the confidenti-

ality and integrity requirements within one model. We

showed in Obiedkov et al. (2006) how this combination can be

achieved in terms of formal concept analysis and how attri-

bute exploration can be designed for it. Further experiments

are needed to evaluate the relevance of the proposed

approach.

r e f e r e n c e s

Bell D, LaPadula L. Secure computer systems: mathematicalfoundations and model. Report M74–244. Bedford, MA: MitreCorporation; 1975.

Biba K. Integrity considerations for secure computer systems.Report TR-3153. Bedford, MA: Mitre Corporation; 1977.

Birkhoff G. Lattice theory. Am Math Soc Coll Publ; 1973.Providence, R.I.

1 A general-purpose implementation of attribute explorationwithout background knowledge is available, e.g., as part of theConcept Explorer system developed by Serhyi Yevtushenko:http://sourceforge.net/projects/conexp.

Denning D. A lattice model of secure information flow. CommACM 1976;19(5):236–43.

Ganter B, Krausse R. Pseudo models and propositional horninference. Technical Report MATH-AL-15-1999. Germany:Technische Universitat Dresden; 1999.

Ganter B, Wille R. Formal concept analysis: mathematicalfoundations. Berlin: Springer; 1999.

Ganter B. Attribute exploration with background knowledge.Theor Comp Sci 1999;217:215–33.

Gollmann D. Computer security. Chichester: John Wiley & SonsLtd; 2005.

Guigues JL, Duquenne V. Familles minimales d’implicationsinformatives resultant d’un tableau de donnees binaires. MathSci Humaines 1986;95:5–18.

Holeman S, Manimaron G, Davis J, Chakrabarti A. Differentallysecure multicasting and its implementation methods. ComputSecur 2002;21(8):736–49.

Lipner S. Nondiscretionary controls for commercial applications.In: Proceedings of IEEE Symposium Security and Privacy. IEEECS Press; 1982. p. 2–10. Los Alamitos, CA.

McCue A. LloydsTSB to offer smartcard security, http://www.vnunet.com/2118641; 2002.

Obiedkov S, Kourie DG, Eloff JHP. On lattices in access controlmodels. In: Scharfe H, Hitzler P, Øhrstrøm P, editors. ICCS2006. LNAI, vol. 4068. Heidelberg, Berlin: Springer-Verlag; 2006.p. 374–87.

Pfleeger P, Pfleeger SL. Security in computing. Prentice Hall; 2003.Reeg S, Weiß W. Properties of finite lattices. TH Darmstadt:

Diplomarbeit; 1990.Sandhu R. Lattice-based access control models. IEEE Comp 1993;

26(11):9–19.Smith G. The modeling and representation of security semantics

for database applications. Ph.D. thesis, George MasonUniversity, Fairfax, VA; 1990.

Sergei Obiedkov is an associate professor at the Department

of Applied Mathematics and Computer Science, Higher School

of Economics, in Moscow, Russia. He has a degree in theo-

retical and applied linguistics and a PhD in theoretical

computer science. Sergei spent a year as a postdoctoral fellow

at the Department of Computer Science, University of Pre-

toria, and it was during this time that the present article was

researched and produced.

Derrick G. Kourie is a professor in the Department of

Computer Science at Pretoria University. His interests include

algorithm construction, finite automata and software

engineering.

Jan H.P. Eloff is Head of the Department of Computer Science

in the Faculty of Engineering, Built Environment and Infor-

mation Technology at the University of Pretoria, South Africa.

He is one of the co-founders of the Information & Computer

Security Architectures (ICSA) research group at the University

of Pretoria and is a Principal Researcher at SAP Research. He is

a member of Technical Committee 11 (Information Security)

of the International Federation for Information Processing

(IFIP).