building access control models with attribute exploration
Post on 26-Jun-2016
212 Views
Preview:
TRANSCRIPT
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).
top related