UML for the Design of Secure Databases: Integrating

Security Levels, User Roles, and Constraints in the

Database Design Process.

Eduardo Fernández-Medina, Alfonso Martínez, Carlos Medina, and Mario Piattini

Escuela Superior de Informática. University of Castilla-La Mancha.

Ronda de Calatrava 5, 13071, Ciudad Real. (SPAIN).
Tel: 34 926 29 53 00 (ext. 3715). Fax: 34 926 29 53 54
E-mail: { Eduardo.FdezMedina@uclm.es,
amartinez@proyectos.inf-cr.uclm.es,
cmedina@proyectos.inf-cr.uclm.es,
Mario.Piattini@uclm.es }
http://www.inf-cr.uclm.es

Abstract. In this article we argue the importance of security in databases, and

the need to consider security as a fundamental requirement in their development
to be integrated at all stages of design, instead of being an isolated and marginal
requirement. We propose an extension of the Use Case and Class models of
UML using their standard extension mechanisms (stereotypes, tagged values
and constraints) to allow us to design secure databases. We show a language for
specifying security constraints, which is called OSCL, and which is based on
OCL, and we summarize the main ideas of our methodology for designing
secure databases, which integrate those models and that language. Finally, we
describe an example where this methodology is being used in a real case by the
Data Processing Centre of the Ciudad Real Provincial Government. Both the
extended models and the language are prepared for classifying the information
into different sensibility levels and for specifying which user roles can access
the information.

1. INTRODUCTION

The communication era has made companies and enterprises evolve, and now these
have to manage the information properly in order to achieve their objectives and grow
thinking in the future. Thus, the use of the information systems and the complexity of
information requirements have grown. Often information systems deal with large data
banks, which can be especially important for the organisation. Indeed the very
survival of the organisation may depend on the correct management, security and
confidentiality of this information. Since most of data is stored in databases and data
warehouses, these are key points to examine when we come to analyse the
information security. For this reason the protection of databases is a serious aspect
which must be considered explicitly, not as an isolated aspect, but as an element
present in all the stages of the life cycle of the database construction (Devanbu and
Stubblebine, 2000).
 Banking data, judicial information, bills, insurance data, military information, and
many other types of valuable information which should be protected, are managed
and stored in databases (Brinkley and Schell, 1995). Sometimes databases store
another type of information that can be considered sensitive and must be specially
protected. This type of sensitive information usually refers to intimate or personal
aspects of individuals, like identification data, medical data or even religious beliefs,
ideologies, or sexual tendencies. Because of this, there are laws, like in Spain, the
Organic Law for the Protection of Personal Data (Organic Law, 15/1999), to protect
the individual privacy, since information systems manage databases with this type of
information. So these information systems should be equipped with mechanisms that
prevent non-authorised access to the information, fulfilling the Data Protection Laws
existing.
Data security problems have increased as a consequence of the technological
changes like access to databases via web, development of electronic commerce,
advances in data warehouses and even the use of datamining techniques
(Thuraisingham et al., 1997). As a result of these advances, for example, systems are
continually being attacked by hackers (Bellovin, 2001).
All the arguments given above point to a serious risk for the information stored in
databases, together with the results of several studies. Some of these have been
reflected in SIC (2001), and show that great areas of vulnerability exist in databases.
These studies demonstrate the disinterest of organisations concerning security in their
information systems (more than 70% of directors of developing businesses do not
know when their security policies are checked) and how little of the budget is
dedicated to security (more than 50% of companies dedicate less than 5% of their
budget to security, and less than 5% dedicate more than 15% of the budget to
security).
In consequence, we need to commit our efforts to design databases that are more
secure. In spite of all solutions that have been offered until now are very important,
they are only partial, isolated and unconnected ones, do not resolve the problem of
database protection globally, and which also do not deal with the problem at design
level. For this reason we propose a methodological point of view which allows us to
design databases taking into account security aspects from the earliest stages until the
end of development. This focus should also be an extension of the methodologies and
standards of modelling existing at the moment, since the organisations really
interested in the security of databases would have to make a great effort to adapt to a
new methodology.
At the moment, one of the more accepted standard for modeling is UML (Booch et
al., 1999). According to Muller (1999), UML can be used (via an appropriate process)
in the design of databases. For this reason the idea of equipping UML models with
security characteristics, in order to design secure databases, is attractive. Thus, a
methodology of database design based on UML language, with the addition of
security aspects, would allow us to design databases with the syntax and power of
UML and with the new security characteristics ready to be used whenever the
application has security requirements that demand them. This measure would allow us
to fulfill the conditions imposed by Chung et al. (2000) to systematically design
information security in systems by integrating security requirements in the design and
by providing the designers with models specifying security aspects. We would also be
meeting the challenges posed by Devanbu and Stubblebine (2000), which concern the
unifying of security with software engineering at the same time as we unify security
with the models of the system.
 In the following sections we will show an extension for the class and use cases
diagrams, as a new constraint language, called OSCL. After that, we will summarize
the database design methodology, and finally we will describe a practical case in
which the methodology has being applying.

2. Extension of UML for Designing Secure Multilevel Databases.

The aim of this section is to carry out modifications in the Use Cases and Class
diagram of UML in order to be able to design secure multilevel databases. It could be
interesting to use object oriented modeling languages, like UML, to design databases
(Muller, 1999). This is due to the fact that, using class diagrams, it is possible to
collect at a conceptual level all the semantics associated with a database, including
other object oriented aspects not contemplated in the entity-relationship model, and
which can be important for later transforming the conceptual model to the logical
scheme.
The main goal of this section is to be able to represent information about the
security level of the information elements and the user roles, which will be authorized
to access these information elements.

Extension of the Use Cases Model.

In use case models it will be necessary to represent those situations where a use case
requires special attention concerning security. In these cases it will also be necessary
to indicate which actors require specific accreditation to participate in these use case.
The extension of the use case model is carried out using stereotypes, creating
«safe-UC» which will be added below the use case symbol. For actors who participate
in a ‘secure’ use case and who need specific accreditation the stereotype «accredited-
actor» is created. The reason for using this representation is so that the diagrams will
be easily transportable, an important condition for any extension of the UML
language. See Figure 1.

Extension of the Class Model

Several kinds of security constraints related to security levels and roles exist: those
inherent in a class model for secure databases, which are not represented explicitly,
and those defined by the user which do need to be defined in the model. The principal
inherent constraints in a model are the following:
• All the elements of a model will have a security level by default: the least
restrictive.
• All the elements of the model will have a security role by default: the most general.
• All the objects will have a security level included in the range of security levels of
the class to which they belong.
• The roles assigned to an association must be the same or more restrictive than the
roles of both related classes.
• Associations will have a security level that must be equal to or superior to the level
of classes it relates. In the same way, an instance by an association will have a
 security level which is higher than or equal to that of the association and that of the
related objects.
• In a generalisation relationship, if the security level of the subclasses is omitted,
they will inherit the security level of the superclass. It is the same in the case of
roles.
• As a general rule in the generalisation relationship, the security level of the
subclasses must be greater than, or more restrictive than, the security level of the
superclass, due to the inheritance mechanism.
• In the same way, the roles assigned to the subclasses must be the same of more
restrictive than the roles assigned to the superclasses.
• All the users will have granted a security level and one or several roles. If a user
wants to access an object, this user have to have granted a security level in the
range of the security levels associated to the object, and a role which have been
assigned to the class.
• The following UML extension mechanisms are used to represent the different user-
defined constraint types.

Tagged values: This kind of extension is used to assign security levels to the
elements of a class diagram. Some examples are shown in figure 1, where security
levels are assigned to two classes, to their attributes and to the association between the
classes.

3. Specifying Security Constraints.

The idea is to construct the language, OSCL (Object Security Constraint Language)
using the standard OCL as a base and extending it to support security constraints.

Some languages for the specification of security constraints already exist, such as
ALICE (Assertion Language For Integrity Constraint Expression) (Urban, 1989),
which is associated to the technique SDMS (Semantic Data Model for Security) for
modelling security requirements (Smith, 1990; 1991). However, they are very old and
it would not be easy to integrate them into an UML-based methodology. There are
also several extensions of OCL, such as that including temporal aspects (Conrad and
Turowski, 2001), but none of them can be used for specifying security constraints.

Object Security Constraint Language (OSCL).

The objective to achieve is to be able to represent multilevel systems by means of a

constraint specification language. Consequently, the language must allow the
definition of security levels for all the elements of a class model, that is to say, for the
classes, the attributes, the operations, the associations, etc, in the same way as for any
instance of all these elements. Moreover, the language must provide tools in order to
be able to specify certain properties related to the security level of the elements that
interact in a model. In the same way, this language will be able to represent a set of
security roles and to manage them in the class diagram.
Each element of a class diagram has security information. Each class will have a
security level or ranking of intrinsic levels, and a role or group of roles, and the
instances of those classes will inherit this security level and this group of roles, unless
there is an explicit constraint that indicates the contrary, although in any case it will
be a higher level than that of the class (more restrictive) and it will depend on the
characteristics of the instance. The same effect will be produced with the attributes
with respect to their values, the associations with respect to their links etc. In order to
be able to specify the security aspect in the model elements, we will access the
metamodel.
An initial modification of the language that will be useful to enable us to navigate
on the metadata of the associations is as follows:

• Type.associationEnds: Set (OCLType) (instead of set (String))

In this way we can access from one class all those that are related with the first by
means of an association.
In order to be able to carry out general specifications on a specific model or, for
example, on all the classes of a model, we need one element that acts as a “container”
and from which we can access all its classes. We will consider a new class of the type
OCL Type which represents the model and which contains all the elements of a
specific model. We will call this new class “model” and it will have three properties:

• model.securityLevels: Sequence(level)

The usual levels of security in a multilevel system are “Unclassified”,

“Confidential”, “Secret” and “Top Secret”(Castano et al., 1994) but we will allow the
designer to specify the appropriate levels for each case. To do this, we will specify a
constraint via the class “model” that indicates the ranking of possible security levels
in a specific model.
• model.securityRoles: Set (Role)
This property will allow to define all user roles that participate in the organization
where the database will be implanted.
• model.class: Set(OclType)
This property contains all the classes of a model. Therefore, it would be possible to
access all the classes of the model and carry out general specifications on them from
the class “model”.
In the following paragraphs, two properties of the “Sequence” type are used that
are not defined by the standard, and that help to make the specifications clearer and
more legible. The following is the specification of these properties:
• sequenceÆposition(element:T):integer
post:sequenceÆat(result)=element
• sequenceÆsubSequence(lower, upper:T):Sequence(T)
let low : integer=sequenceÆposition (lower)
let top : integer=sequenceÆposition (upper)
pre: 1<= low
pre: low<= top
pre: top<= sequenceÆsize
post: resultÆsize = top - low + 1
post: resultÆforAll(element:T | resultÆposition(element)
= sequenceÆ position(element) - low + 1
We have considered that the sensitive information of a class should be an intrinsic
element of the class, as maybe the attributes of the class or the operations and as a
result we have decided to broaden the class OclType giving it functionality for
specifying the level of the classes, attributes, operations and associations:
• type.securityLevels : levels
Post: model.securityLevelsÆsubSequence (type.securityLevels.lowerLevel,
type.securityLevels.upperLevel) Æ size > 0
• type.securityLevel: level
Post: type.securityLevelsÆincludes(result)
• Type.securityRoles : Set (role)
Post: model.securityRolesÆincludesAll(result)
With the first operation we specify the ranking of possible levels amongst which a
class can be found (notice that securityLevels type has got two attributes defining the
range limits, lowerLevel and upperLevel). A postcondition is used to specify that the
ranking of possible security levels must be correct and be included in the ranking of
values defined for the UML model. Although a class may have a range of security
levels it will always be characterized by one security level which will be the lowest of
the security levels that its instances can have. The second operation allows the
specification of the level of a class. For example, the class “patient” may have a range
of security levels from “confidential “ to “secret” as the level of security of the ill
person will depend on the kind of illness that this person is suffering from (e.g.
Infection: “confidential”, AIDS: “secret”, etc). However, in the absence of an explicit
security level, the level of the class “patient” will be “confidential” default. The third
property allows us to specify the set of user roles that will have access to the
information of the corresponding class. Obviously, all roles defined for a class will
have to be included in the set of roles defined for the model.
We need similar operations to specify the level of attributes, operations and
associations:
• type.attribute.securityLevels: levels
Post:
model.securityLevelsÆsubsequence (type.attribute.securityLevels.lowerLevel,
type.attribute.securityLevels.upperLevel )Æsize > 0
• type.attribute.securityLevel: level
Post: type.securityLevelsÆincludes(result)
• type.attribute.securityRoles : Set(role)
Post: model.securityRolesÆincludesAll(result)

• type.operation.securityLevels: levels
Post:
model.securityLevelsÆsubsequence(type.operation.securityLevels.lowerLevel,
type.operation.securityLevels.upperLevel )Æsize > 0
• type.operation.securityLevel : level
Post: type.securityLevelsÆincludes(result)
• type.operation.securityRoles : Set(role)
Post: model.securityRolesÆincludesAll(result)

• type.associationEnd.securityLevels: levels
Post:
model.securityLevelsÆsubsequence(type.associationEnd.securityLevels.
lowerLevel, type.associationEnd.securityLevels.upperLevel )Æsize > 0
• type.associationEnd.securityLevel : level
 Post: type.securityLevelsÆincludes(result)
• type.associationEnd.securityRoles : Set(role)
Post: model.secutiryRolesÆincludesAll(result)
With the tools that we have at our disposal up to this point, we can specify security
levels and user roles in classes, attributes, methods and associations. When the
instance of a class is created it directly inherits the security level of the class, unless
there is a restriction that obliges that class to have a higher security level than its
class. Restrictions of this type are always created taking the class containing the
element to which we wish to apply the restriction as the context. For example, in
multilevel security, restrictions of the following type are typical: the class
“Employee” has a security range of {Unclassified..Secret}. The security level of the
instances depends on the value of the category “salary”, and the greater the salary is,
the more restrictive the object becomes. The constraint will be expressed as follows:
context Employee inv:
Self.level = if salary < 200.000 then “Unclassified”
else if salary < 500.000 then “Confidential” else “Secret”
Although the most usual constraints will refer to the security levels of the
information elements, it is also possible that exist constraints on the roles of the users
who will have access to data. Let’s think for example in a situation like this:
• Patient.securityRoles = Set(Doctors, Nurses)
With the above expression we are telling that the information contained in a class
called Patient will only be accessed by users belonging to ‘Doctors‘ or ‘Nurses’ roles.
It may be possible to be a little bit more accurate in the access control and indicate
that ‘Nurses’ role members can have access to the patient information unless the
illness be cancer or AIDS. This constraint could be expressed this way:
• Context Paciente inv:
Self.securityRoles = if (illness = ‘Cancer’ or illness = ‘AIDS’)
Then Set(Doctors, Nurses)
Else Set(Doctors)
In addition to these kinds of specific constraints these will also be some security
constraints that are inherent to the model, which it will not be necessary to specify but
which must be complied with. These are as follows:
• All the objects have a security level included in the range of security levels of the
class to which it belongs. The constraint for each class is:
context Model inv:
Self.classÆforAll (C:OclType | C.allinstances Æ count (O:
Class | C.securityLevels.lowerlevel, C.securityLevels.upperlevel Æ
notExist(O.securityLevel))=0)
This constraint expresses that for each class of model, the number of instances
whose security level does not belong to the range of levels for that class will be 0.
• The associations will have a security level that must be equal or more restrictive
than the level of the classes that it relates to. In the same way, an instance of an
association will have a security level included within the range of security levels of
the association.
context Model inv:
Self.classÆfor All (C1: OclType |
C1.associationEndsÆForAll (C2:OclType |
model.securityLevelsÆSubsequence (C1.securityLevels.upperLevel,
C1.C2.securityLevels.upperlevel) Æ count <> 0 and
model.levelsÆSubsequence (C2.securityLevels.upperlevel,
 C1.C2.securityLevels.upperlevel) Æ count<>0)))

This expression specifies that for all the classes of a model it is essential that all the
associations with another class must have a security level higher or equal to that of the
related classes.
• The generalization mechanisms allow us to refine classes (superclasses) into more
specific groups that inherit the properties of the first groups (subclasses). The
accepted rule for the relation of generalization is that the security level of the
subclasses must be greater than or be more restrictive than the security level of the
superclass. The specification of this constraint is as follows:
context Model inv:
Self.classÆfor All (C1: OclType | C1.SuperTypes Æ ForAll
(C2: OclType | Model.levels Æ Subsequence (C1.securityLevels.upperlevel,
C2. securityLevels.upperlevel)Æcount<>0))
Similar operations could be expressed for roles (as commented above), but to
specify role constraints, it would be necessary to have a ‘Tree’ type with several
operations that allow to manage it, but OCL language is very simple and does not
count with this type of structures. As role constraints will not be very common, we
have preferred not to extend the language with ‘Tree’ type.

4. Methodology overview

The techniques shown in the precedent sections have been integrated into a secure
databases design methodology (Fernández-Medina et al., 2001). That methodology is
based upon the Unified Development Process (Jacobson et al., 2000) and keeps the
essence of most important topics. Thus, secure databases design methodology will be
guided by use cases, it will be centred in the architecture, and it will be iterative and
incremental. As a new main feature, it must be emphasized the incorporation of
multilevel and role security concepts since the design process, which implies
considering the security aspect from the earliest database design stages.

This methodology counts on the following main processes:

1. Requirements capture: In this process a system requirements analysis is carried out,

paying special attention to security requirements.
2. System analysis: The goal of this stage will be to formalize the captured
requirements in the previous stage by means of a class diagram. This class diagram
will also have got the necessary structures for specifying the security required by
the permanent information elements. At this stage it will also be generated a series
of security constraint specifications written in OSCL.
3. System design: Since the various class diagrams and the set of security
specifications which have been obtained in the last stage, at this one, we will get a
description of the multilevel relational schema, and a specification of different
processes (triggers and stored procedures) that are charged with control the
security constraints fulfilment.
4.
 In order to give practical support to the methodology, a tool in Visual Basic has
being developed, making good use of the Rose Extensibility Interface (REI). Its
functionality is to be able to grant the security features to the various Rational Rose
98 / 2000 model elements. These can be applied to the use case diagram elements and
to the class diagram ones as well. Use cases, classes, associations, attributes and
methods will be able to be modified.
The tool allows the user to create a security level list, to assign an abbreviation
(called mnemonic) for each one of them, as to modify its priority in that list. Besides,
it allows the user to save the list in disk, making it portable to other models.
As it happens with the security levels, it allows the creation of a security role
hierarchy, and to save it, in order to be also portable to other models.
In the class diagram, when a security level range or a role is assigned, the tool
verifies that the assignment do not be less restrictive that the existing one in the
superclasses, what would be illegal, and in the case of an association, that do not
infringes the related classes level (see figure 2). That way the security integrity in the
model is kept, and illegalities as the precedent are not allowed at this level. Besides,
the tool when is run, makes a checking of the legality of the assigned security, and if
in some case is not legal, the superclasses level overwrites the subclasses one in order
that not to be inconsistencies in the model.
Moreover, the tool will include a little OSCL language checking motor in an
upcoming version. It allows specifying OSCL constraints for the model elements and
checking these to be written properly.
A detailed study of the functionality of the tools that support OCL has been carried
out (Toval et al, 2001) and it will be used to choose the most appropriate tool for
extending it for the new characteristics incorporated by OSCL.

4. Practical case:

During its construction build phase, the methodology has been used to design several
small databases. Now that has been finished, we try to use it for designing a real
database, already set up and of a considerable size. This will provide us with
interesting feedback, and there by enable us to improve the methodology.

The database belongs to an application for accounting called SICAL. This

application is a management program used by the Data Processing Centre of the
Ciudad Real Provincial Government (Spain) for the accounting administration of the
official provincial organisms that depend on this Government. The objective of this
application is to control the budgeted expense plan of the Government, the budgeted
income, all the operations not included in the budget, the resources coming from the
exterior, the treasury, the aspects related to the general accounting, the internal
administration of the system, the opening of processes and the printing of documents
by the application users. SICAL has thirteen modules, of which the most important
are:
1. Budgeted expense plan: It is responsible for the management of budgeted
expenses.
2. Budgeted income: It is responsible for the management of the budgeted incomes.
3. Resources of other entities: Resources provided by organizations external to the
government.
4. Treasury is responsible for the management of payments and receipt of payments.
5. Third parts: It is responsible for the data management of persons and entities
external to the Government.
6. System administration: It is responsible for the configuration of the system itself.

This system is totally set up, it is fully functional and security features that have
been taken into account are minimal. These features make the system ideal for the
application of the secure database methodology in an experimental manner. Although
the objective of the methodology is to design databases from the beginning, it can also
be applied to an already created one by using the existing system specification for
obtaining the requirements.
Since the applied methodology is iterative and incremental, in the first iteration, a
specific module is chosen and all the stages of the methodology will be carried out.
Then, increments will be performed by considering new modules and reviewing and
improving the modules already considered.

After studying the characteristics of each of the thirteen application modules, we

have chosen as the most relevant from the security point of view the Budgeted
Expense, Budgeted Income, Resources of other entities, and System Administration.
For each and every one of them a new design has been performed, in which we have
included:
− A use cases study (applying security features yet).
− Class modelling: It has been studied the semantic information, the security
information (levels and roles), and the constraints for each module of the
considered ones.

Use cases study:

Below, it is described in a very concise way the outcome of applying the Requirement
Capture activity workflows:
• Looking for actors: The following actor types have been detected:
• Workers: Internal Provincial Government staff. These workers can in their turn
be of two types, with experience and without experience.
• Third Parts: Databases that store data about physical and juridical persons
external to the Provincial Government (banks, town halls, suppliers, etc.).
• Corporation: Database with internal information of the Provincial Government
itself.
• System Administrators: Staff dedicated to the internal system management.
They could be of two types, Superusers and Normal Administrators.
• Looking for use cases: It has been taken as use cases the subapplications defined in
the system specification. In figure 0 we can see an example of the use case main
diagram from the Budgeted Expense module.

• Describing use cases: Each composite use case has been divided into the
corresponding subcases.
• Analysing the security in the use cases and in the actors: In this phase a first study
of the security aspect has been done. As secure use cases have been catalogued
those that are going to manage any kind of sensitive information from the point of
view of the security. The actors that generate these use cases will be called
Accredited Actors. As we can see in the figure 0, some of these cases appear with
 the <<safe UC>> stereotype, which points out that the security in those use cases
will have to be studied in detail as we advance in the methodology stages. In same
way, some actors appear with the <<Accredited Actor>> stereotype, which will
indicate that those actors will have to own a specific accreditation level to be able
to carry out a certain use case.
• Structuring the use case model: It has been created a main diagram with the most
general use cases from each module. Each composite use case has associated a use
case subdiagram, where containing use cases and their relationships are specified.
• Looking for relationships among use cases: It has been studied the relationships
among the different use cases and have been represented in the diagrams and the
subdiagrams made in Rational.
• Use cases review: Once finished the design of each module use cases, the results
have been discussed with several experts of the SICAL system, to corroborate their
exactness and to change those which were not correct. The new security
characteristics have been also commented, for not starving of any kind of
functionality to the new application. Besides, the whole use case diagram was
reviewed, in order to join criteria, to extend in security questions, to detect
important use cases that had not been taken into account, etc.

Class Modeling:

We are currently working in this phase. Being about an iterative and incremental
methodology, the study of the class diagrams for each module has been performed
after finishing the corresponding analysis of their use cases. In figure 1 we can see an
example of the diagram created for one part of the Expense Budget module.
As it can be seen in the figure 1, the security levels for each class have been yet
incorporated. These security levels are the ones that will be later used for restricting
the access to determined sensible information, from the security point of view.
The assignation of security levels will be horizontal and vertical, taking into
account security levels and the roles of the different people who manage the SICAL
application (see table 1).
As a final step in this phase, security restrictions for the sensible information must
be also established. For it, we base on the established levels in the class diagram and
in the considered roles. The constraints will be made in the OSCL language. This part
is almost finished and only a few little adjustments are still to be done (see figure 1).

5. Conclusions and future work:

Nowadays database security is taking a special importance. In our own opinion,

database security, from the confidentiality point of view, should try to be solved in a
methodological way. To achieve this, databases should have to be designed in a
manner that had into account the information security levels. For this, firstly a series
of modeling techniques and a security constraints specification language have been
defined. These have been integrated into a complete methodology for designing
secure databases. In the lasting part, we show the achieved results by applying this
methodology to an actual case of an accounting information system hosted by a public
organ in Spain.
 One of the objectives of applying the methodology to a real case is to improve the
methodology itself, since we expect that a feedback is raised as a result of the
problems or the incompatibilities derived from its practical application.
At the moment we are refining and extending the new OSCL language to enable it
to support other types of security constraints in relation to control of access to
information depending on certain roles in the organization, or certain timetables,
exceptions etc.
We are also working on the improvement of the aspects related to security levels
specialization; nowadays, the possibility of including specifications related to the
roles subject is being analysed. Thus, for example, an assignment of a security level
that now is expressed as Self.Class="level" could be expressed as
Self.Class.role="level". Working in this way, a better information access control and a
better flexibility would be obtained.
The future work will consist of finishing this project, following the presented
initial scheme (see figure 3). Looking at this diagram we can see the reengineering
process the SICAL system has been submitted to. In the doter square it can be found
the system design scheme. In the first phase the feedback between the logical
modelling and the conceptual one is produced, and this feedback is repeated until that
it is arrived to a point where it is separated from the old system and a new system
starts to be built (here is where phase 2 starts). In the phase 3 lays the physical
implementation; this phase is already detached from the methodology. In parallel to
the totally of this process, a continuous feedback between the whole system and the
methodology development is made. In the short term, the main task will be the
conclusion of phases 1 and 2, because they are the most important in the initial
objectives.
As we have just seen, the last part of the project will be focused on the
implementation of the new database. Before starting this phase, we will have to
decide the platform in which the database will be implemented over. The different
commercial possibilities that actually exist into the management systems of databases
are being studied; the Oracle 9i application, called Oracle Label Security (Moran
2001) is thought that it is one of the most adequate, because it has very interesting
functionalities related to the multilevel security matter. However, we do not discard
the use of other different management system and to adapt to our necessities (for
example, Oracle Label Security does not tightly fulfil the requirements that our
system has to consider, only the security at row level and not at attribute level).

With regard to the tool functionality, we are be thinking it allows to obtain

automatically the definition of the conceptual information of the relational multilevel
databases as in XML as in Oracle Label Security, applying the defined rules in the
secure databases design methodology.
Besides, a possible extension is to create a complete compiler of the OSCL
language, and not only the possibility of verifying the expressions to be written and
built well. It could be proposed this compiler to generate SQL code.

6. Acknowledgements:

This research is part of the DOLMEN project supported by CICYT (TIC2000-1673-

C06-06).
7. Bibliography

1. Bellovin, S. (2001). Computer Security. An end State?. Communications of the ACM, Marzo.
Vol. 44, Nº 3, pp. 131-132.
2. Booch, G., Rumbaugh, J. and Jacobson, I. (1999). The Unified Modeling Language, User
Guide. Addison-Wesley, Reading, Mass.
3. Brinkley, D. and Schell, R. (1995). What Is There to Worry About? An Introduction to the
Computer Security Problem. Information Security, An integrated collection of essays. Eds.:
Abrams, M., Jajodia, S. and Podell, H. IEEE Computer Society. California.
4. Castano, S., Fugini, M., Martella, G. and Samarati, P. (1994). Database Security. Addison-
Wesley.
5. Conrad, C. and Turowski, K. (2001). Unified Modeling Language: Systems Analysis, Design
and Development Issues. Chapter 10: Temporal OCL: Meeting Specification Demands for
Business Components. Eds. Siau, K. y Halpin, T. Idea Group Publishing. United States of
America.
6. Chung, L., Nixon, B., Yu, E. and Mylopoulos, J. (2000). Non-Functional Requirements in
Software Engineering. Kluwer Academic Publishers. Boston/Dordrecht/London.
7. Devanbu, P. and Stubblebine, S. (2000). Software Engineering for Security: a Roadmap. The
Future of Software Engineering. Ed: Finkelstein, A. Pp. 227-239.
8. Fernández-Medina E., Piattini M., and Serrano M. (2001), Seguridad en Bases de Datos,
Fundación Dintel, (CHAPTER 2).
9. Jacobson I., Booch G., and Rumbaugh J. (2000) El proceso unificado de desarrollo, Addison
Wesley.
10. Moran R. (2001), Oracle Label Security Administrador’s Guide, Release 9.0.1, Oracle
Corporation.
11. Muller, R. (1999). Database Design for Smarties. Using UML for Data Modeling. Morgan
Kaufmann Publishers, inc. San Francisco, California.
12. Organic Law 15/1999, of December, 13 of Personal Data Protection. BOE núm 298, of
December, 14th 1999.
13. SIC (2001). Seguridad en Informática y Comunicaciones. April. Nº 44. P. 6.
14. Smith, G.W. (1990). The Semantic Data Model for Security: Representing the Security
Semantics of an Application. Proceedings of the Sixth International Conference Data
Engineering, IEEE, pp. 322-329.
15. Smith, G.W. (1991). Modeling Security-Relevant Data Semantics. Proceedings of de IEEE
Transactions on Software Engineering, Vol. 17. Nº 11, November, pp. 1195-1203.
16. Thuraisingham, B., Schlipper, L., Samarati, P., Lin, Jajodia, S. and Clifton, C. (1997).
Security issues in data warehousing and data mining: panel discussion, in Database Security
XI: Status and Prospects. (eds. T.Y. Lin and S. Qian), Chapman and Hall, London, pp. 3-16.
17. Toval A., Requena V., Fernández J., (2001) OCL Emerging Tools, Programmers Report (to
appear).
18. Urban, S.D. (1989). ALICE: an Assertion Language for Integrity Constraint Expression.
Proceeding of Conference on Computer Software Applications.
9. Figures

<<Safe-UC>>
spend budget

<<Safe-UC>>
worker jus tify pays

<<Safe-UC>>
spend proyects thirds «Databas e»

<<Safe-UC>>
compromis e of spend of pos terior
execirses

worker
«Accredited-Actor»

control of remanet credits

corporation
«Database»

<<Safe-UC>>
cons ult to s pend budget

They are pays similiar to justify

pays; they are 4 phases:
<<Safe-UC>> - Advance payment opened
advance payment fix box - Advance payment constitution
- Funds reposition
- Advance payment cancelation

<<Safe-UC>>
bill register

Fig. 0. Main diagram from the Expense Budget

Self.SL=(if Self.Server then S else SC)

Users {SL = TS; Roles = Superuser}

**password : c {SL = TS}
**NIF : c {SL = TS}
Name : c
Surname : c
Departament : c
Security Level : c {SL = TS}
Role : c
Comments : c

0..*
1..*

Computer {SL=SC..S; Roles = Administrator, Worker}

Printers {SL = S; Roles = Comun Administrator} **Identificator : c
**Identificator : c Domain : c {SL = S}
Network : boolean IP : c {SL = C}
Domain : c Mark : c
Mark : c Model : c
Model : c Failures : c
Failures : c Operative System : c
Last update : c Installed Programs : c {SL = C}
Peripheral : c
Instalation Date : c
Server : boolean
S.O. configuration : c {SL = SC}

Fig. 1. Class Diagram of Computer Administration

 Fig 2. Assigning security features to the class diagram elements.

Phase 2 Multilevel Phase 3

Implementation in a Specific
Logical
System (Oracle Label Security…)
Modelling

Conceptual Logical Implementation

Modelling Modelling

Phase 1
Existing System

Secure Database
Methodology

Fig. 3. Initial Scheme

10. Tables

Table 1. Considered roles

Roles
Government Workers

Administra Workers

With Experience
Without Experience

Superuser
System

tors

Common Administrator