Una.

Introduccin
Almacenes de Datos (DW) sistemas representan una fuente nica de informacin para analizar a
travs del cual el estado y el desarrollo de una organizacin. [17] Este hecho demuestra la
necesidad de definir y hacer cumplir las medidas de seguridad en todo el proceso de desarrollo de
todo el DW. El DW est diseado por lo general despus de la fase de anlisis de requisitos junto
con el diseo conceptual, lgico y fsico.

En los ltimos aos, muchas propuestas respecto a cmo debe ser diseado DWs se han
propuesto [1]. Algunos autores sugieren que esa debera ser una fase dedicada al anlisis de los
requisitos [11], [17], [21] y [36]. Pero pocos de ellos tienen en cuenta tanto los aspectos,
funcionales y de seguridad de los requisitos no funcionales para el diseo de DW.

Normalmente, dentro de los proyectos implementados DWS aspectos de seguridad se encuentran
en las ltimas fases de diseo [42]. Sin embargo, algunos autores han sealado que los proyectos
de ingeniera de software son sumamente vulnerables cuando los requisitos de seguridad estn
mal Interpretada Durante las primeras fases del proceso de desarrollo [4], [30] y [9].

Los requisitos de seguridad son requisitos los relacionados con la proteccin de los valiosos activos
en el sistema. Estos requisitos de seguridad describen cmo se gestiona el acceso, la informacin
se puede acceder por quin y bajo qu condiciones la informacin se puede acceder a eso, y por lo
tanto son a menudo denominadas polticas de control de acceso (ACP) [8]. Las propuestas
pertinentes literatura compreende muchos cuyo objetivo es proteger DWS. Sin embargo, se
plantean las obras [7], [6] y [51] en el que los autores llaman para el diseo de la seguridad en el
ciclo de vida DW. Estas obras constituyen la proposta nico que nos permite establecer medidas
de seguridad y auditora de modelado multidimensional conceptual por medio de un modelo
semntico. El enfoque se basa en el control de acceso y auditora (ACA), el cual constituye una
medida de seguridad ACP diseo DW. A menudo conducidas especificaciones ACP sin una gua
prescriptiva [3] y [46] As, dejando a los sistemas vulnerables a la seguridad y las infracciones de
privacidad en [13]. Muchos investigadores han, por lo tanto, se reconoce la necesidad de salvar la
brecha entre el anlisis de los requisitos y las especificaciones de control de acceso [3] y [12].

Por otra parte, las propuestas de [7], [6] y [51] se han relacionado con Model Driven Architecture
(MDA) [31] un Object Management Group (OMG) Qu norma se refiere al ciclo de vida completo
de diseo, la implementacin , integracin y gestin de aplicaciones. MDA se basa en la creacin
de modelos de diseo en diferentes niveles, y las transformaciones entre ellos. La Figura 1
describe nuestro marco basado en la MDA para el desarrollo de DW seguras por [47]. Trabajos
anteriores muestran que los niveles conceptuales, lgicos y fsicos, junto con las transformaciones
necesarias mediante el uso de vistas de consultas y transformacin (QVT) [34] han estudiado y
definido (ver [51], [48], [49] y [50] para ms detalles). Sin embargo, un proceso de ingeniera
sistemtica con la que desarrollar DWs seguras que las parejas con el marco propuesto en la
Figura 1, es decir, que nos permite construir y transformar el modelo de clculo independiente
(CIM) para obtener el cdigo seguro de que an no existe.






La elaboracin del CIM es especialmente importante y crtico, ya que este modelo recoge la
mayora de las necesidades del usuario y que, una vez transformado, se les dar a otros modelos
del marco de MDA, es decir, el modelo independiente de la plataforma (PIM) se obtiene de la CIM
mediante el uso de un conjunto de directrices que hemos definido (vase la Seccin 4.4.1), y el
modelo especfico de la plataforma (PSM) y el cdigo de un Sistema de Gestin de Bases
especficas de datos (DBMS) se definen mediante la aplicacin de Ambos tambin la QVT [34] y
MOF2Text [35] Propuestas, respectivamente. Estos modelos son idealmente obtenido de manera
automtica, junto con enriquecimientos diferentes en diferentes puntos del proceso de MDA. Por
lo tanto, hacemos un llamado a la definicin de un proceso de ingeniera y reutiliza las parejas que
nuestros resultados anteriores bajo el prisma de MDA y facilitar la implementacin de una
herramienta CASE que generar asegurar el repositorio DW.

En este trabajo se propone una metodologa integral con el que desarrollar DWs seguras basadas
en el marco de MDA que llamaremos proceso de ingeniera segura para almacenes de datos
(SEDAWA). El proceso nos permite definir los requisitos de seguridad de nivel empresarial que se
transforman en todo el ciclo de vida completo DW. El enfoque se acopla con ambos, el marco de
MDA y trabaja con nuestro desarrollado previamente. Nuestro enfoque se basa en el Proceso de
Ingeniera de Software Especificacin metamodelo estndar (SPEM) [32] en el Object
Management Group (OMG). SPEM es un metamodelo proceso que nos permite describir la
ingeniera de procesos, teniendo en cuenta los ciclos de vida de los proyectos. Las principales
ventajas de nuestro proposta son: (i) la adaptacin de la i * [53] con el fin de obtener y
representar a la vez las exigencias, funcionales y de seguridad de los requerimientos no
funcionales en un entorno seguro CIM para la fase de anlisis de requisitos de los cooperantes
diseo, (ii) Que los requisitos suscit ser transformado y desarrollado a travs de las palabras de
datos del ciclo de vida completo utilizando el marco de MDA, (iii) que la metodologa se basar en
SPEM, que asegura la notacin estndar que las parejas con el Lenguaje Unificado de Modelado
(UML ), y (iv) Que nuestro enfoque ofrece una gua a travs de la cual desarrollar un efectivo
apoyo automatizado para construir DWs seguras. Reduce el riesgo lo tanto, el equipo de desarrollo
y el esfuerzo en el desarrollo de DW seguras.

Por otra parte, los enfoques metodolgicos son los ms adecuados para hacer el proceso ms
sistemtico de software y predecible si se toman en cuenta los aspectos de control de calidad. Por
lo tanto, el producto de software final es ms adecuado a las necesidades del usuario,
proporcionando una mayor calidad, un menor coste y una mayor facilidad de mantenimiento, etc.,
A las aplicaciones. El resto del trabajo se estructura a seguir. Despus de esta introduccin, la
seccin 2 se describe el trabajo relacionado. El modelo de seguridad para ADs y su relacin con la
MDA se muestra en la Seccin 3. La seccin 4 presenta nuestro proceso de ingeniera de seguridad
por medio de la metodologa que nos permite obtener y desarrollar los requisitos de seguridad en
el ciclo de vida completo DW. Nuestra metodologa se ilustra con un ejemplo relacionado con la
gestin de la empresa consorcio farmacias en la Seccin 5, que se han implementado como una
prof. de concepto en una herramienta CASE prototipo que estamos desarrollando. Las limitaciones
de nuestro proposta se tratan en la Seccin 6. Finalmente, la seccin 7 resume las principales
conclusiones y esboza nuestro trabajo futuro inmediato.

2 . Trabajos relacionados
En esta seccin, se describe el trabajo relacionado con nuestro enfoque desde tres perspectivas:
(1) los requisitos para ADs, (2) el proceso de ingeniera para ADs y (3) Propuestas para el modelado
de la seguridad en DW.

2,1. Los requisitos para ADs
Existen tres tipos de enfoques de desarrollo DW existe: por datos (de un sistema operativo en
DW), requisito impulsado por (un intento de identificar las necesidades de informacin de los
cooperantes, es decir, basado en un escenario requisito explcito) y mixta (que considera ambones
fuentes de datos y los requisitos en las primeras etapas del desarrollo). En este sentido, no han
clasificado los diferentes enfoques de acuerdo a los tres tipos de DW de desarrollo mencionados
anteriormente. En general, los principales enfoques para el anlisis de requisitos en el contexto de
DWs son [10], [24], [26], [52], [36] y [38]. Sin embargo, la proposta de [36] considera que la
seguridad slo los requisitos no funcionales (NFR) para la fase de anlisis de requisitos. El resto de
las propuestas se refieren a los requisitos funcionales. Sin embargo, los requisitos de seguridad no
se suscit desarrollado y transformado en el ciclo de vida completo DW. Por otra parte, ninguno
de los mtodos antes mencionados son parte de la ingeniera del proceso general que nos permite
obtener DWs seguras. Nosotros, sin embargo, el tomar nuestro punto de partida el trabajo [26] los
autores en el que se propone un enfoque novedoso y prometedor hacia la definicin de los
requisitos de informacin.

2,2. Ingeniera de Procesos para ADs
Varias metodologas con respecto a cmo se debe construir palabras de datos que se han
propuesto en la literatura. En [18] Los estudios de caso de diferentes Data Mart (DM) se presentan
que integran el diseo de varios sistemas por medio de la arquitectura de matriz de bus. Las fases
ms relevantes dentro del ciclo de vida DW se presenta, pero el mtodo no es el proceso est
propuesta. En [11] se propone una notacin especial para el diseo conceptual y DW cmo el
esquema de DW se pueden derivar de las fuentes de datos descritos por entidad-relacin (ER)
esquemas. Aqu, los autores asumen la aplicacin relacional de los cooperantes y la existencia de
esquemas ER, que suele ser imposible. [29] muestra cmo construir un esquema en estrella (y sus
variantes) a partir de los esquemas conceptuales de las fuentes de datos operacionales. El enfoque
supone que las fuentes de datos se definen por medio de esquemas ER. MIDEA [2] constituye un
mtodo basado en un modelo MD. Un conjunto de medidas que aborden el diseo conceptual,
lgico y fsico de la DW est propuesta. Las fuentes de datos operacionales, junto con las
necesidades del usuario final, son considerados en el diseo. En [22], el mtodo de desarrollo de
DW, basado en UML y el Proceso Unificado (UP) es propuesta, que aborda el diseo y desarrollo
de todo el diseo de DW. El enfoque se basa en perfiles UML formales y nos permite definir
esquemas diversos cooperantes pueden integrarse con el fin de definir la transformacin
automtica entre ellos.

Todos los enfoques antes mencionados se ven afectados por algunos de los siguientes problemas:
no se incluyen los temas de seguridad en las palabras de datos de diseo, algunos de ellos es no
abarcan todo el ciclo de vida DW, algunos de ellos se basan en la aplicacin especfica (en el
esquema en estrella bases de datos relacionales), o bien se basan en un conjunto de pasos o fases
que permiten la automatizacin de los procesos de todo el diseo seguro de DW.

2,3. Seguridad en Almacenes de Datos
El modelo de seguridad para ADs compreende varias iniciativas para incluir la seguridad en el
diseo de DW. En [15], los autores describen un modelo prototipo para DW seguridad basado en
metadatos, cuyo principal objetivo es la reduccin de consultas de los usuarios hasta la fecha que
esas son slo para ser vistos por el usuario. Sin embargo, esto no permite la especificacin de
restricciones de confidencialidad complejas tales como negar-permitir el acceso a los grupos de
usuarios especiales que combinan y las limitaciones de seguridad. Sciore y Rosenthal [41] extender
subsidios SQL y crear un mecanismo de inferencias a travs de DW para establecer qu seguridad,
que se deriva de permisos en las tablas y vistas del sistema, estableciendo as una fcil
administracin. El intento est ms arriba que la arquitectura es yunque federados Sistemas de
Informacin (FIS) y DWS que preserva integracin de seguridad de varios niveles entre FIS y DWS
[43]. La autorizacin del rgimen DW tiene en cuenta la construccin poltica de seguridad de la
propia federacin. Kirkgze et al. [16] define un modelo basado en el Modelo de Acceso
Discrecional (DAC) que proponen un concepto de seguridad para OLAP, un modelo de seguridad
basado para ADs. De acuerdo con estas reglas de seguridad, el cubo de datos derivado se define
para cada rol. Essmayr et al. [5] muestra cmo los privilegios de acceso para los cooperantes y
OLAP se puede expresar de forma ms intuitiva que mediante el uso de sentencias de SQL de la
subvencin. Este modelo de control de acceso se centra especficamente en la usabilidad y la
expresividad. Estos enfoques [5], [15], [16], [41] y [43] son atractivas, pero slo se centran en
cuestiones prcticas como el control de la adquisicin, el almacenamiento y el acceso en el lado
OLAP. Ninguno de ellos examinar la reclamacin de la seguridad en la fase de anlisis de requisitos
ni Proponer Desarrollar un mtodo para todo el ciclo de vida DW.

Autorizacin de los modelos ms elaborados proponer iniciativas que tambin es diseo DWs
existe. Por ejemplo, Priebe y Pernul [39] proponen una metodologa de diseo de seguridad
similar a la metodologa clsica de base de datos (anlisis de requerimientos, diseo conceptual,
lgico y fsico) que cubre los requisitos y las implementaciones concretas en los sistemas
comerciales. Los mismos autores extender el UML adaptado (que utiliza los smbolos UML
estereotipos ADAPT) modelo para la fase conceptual antes mencionado [40], y especifique una
metodologa y un lenguaje de seguridad MD restriccin para el modelado conceptual de OLAP
seguridad. Estos enfoques [39] y [40] Los modelos ofrecen seguridad a nivel conceptual por medio
de restricciones de seguridad, pero bsicamente se ocupan de las operaciones OLAP. En resumen,
estas obras Aplicar las normas de seguridad considerados en su enfoque conceptual a los sistemas
de bases de datos comerciales. La metodologa propuesta se centra nicamente en la etapa de
DW conceptual del ciclo de vida, las dems etapas no son tomados en cuenta y no existe ningn
mtodo con el que se realizan.

En conclusin, ninguno de los requisitos de los enfoques existentes del modelo de seguridad que
se pueden desarrollar durante todo el ciclo de vida de DW. Ninguno de ellos consideran el control
de acceso formal se puede definir este requisito en la etapa de anlisis, y transformado y
enriquecido a lo largo del ciclo de vida de los cooperantes. Creemos que ninguno de los mtodos
antes mencionados constituyen un mtodo general que ofrece una eficaz orientacin para el
desarrollo de un soporte automtico con el cual construir DWs seguras. Por lo tanto Basamos
nuestro enfoque en el trabajo de [7] en el cual propone un nuevo modelo de seguridad y auditora
a nivel conceptual para ADs. Este modelo se adapt y transform a asumir auditora de seguridad
y medidas en el ciclo de vida completo DW (es decir, desde la fase de anlisis de requisitos para la
aplicacin final en un DBMS especfico) A raz de la norma metamodelo SPEM [32].

3 . Modelado de seguridad para almacenes de datos
Una de las principales preocupaciones en el diseo de DW es la seguridad de datos, que suele ser
visto como un requisito de no-informacin. [36] En esta seccin, nos centraremos en explicar
cmo modelar los requisitos de seguridad para los cooperantes mediante el modelo de control de
acceso y auditora (ACA). Por otra parte, reutilizamos la extensin anterior del framework i * [26]
con el fin de obtener los requisitos de seguridad y definir un modelo ACA para ADs a nivel
empresarial.

Los requisitos de seguridad son requisitos que se asocian a la proteccin de los valiosos activos en
el sistema. Que esta proteccin requiere cada acceso al sistema y sus recursos pueden controlar y
que slo el acceso autorizado puede tener lugar, y se llama modo de control de acceso (AC) [44]. El
desarrollo de un sistema de control de acceso se realiza mediante Listo polticas de control de
acceso (ACP), un modelos de control de acceso y mecanismos de control de acceso [44] que
constituyen los diferentes niveles de abstraccin. ACP requisitos de seguridad de alto nivel que
define las reglas. Modelos de control de acceso proporcionan una representacin formal de la
poltica de acceso de control de seguridad, Considerando que el mecanismo de control de acceso
se definen los de bajo nivel (software y hardware) funciones que implementan los controles
impuestos por las polticas y se declar formalmente en el modelo [44].

ACP se agrupan en tres clases principales: Control de Acceso Discrecional (DAC), Control de acceso
obligatorio (MAC) y Role-Based Access Control (RBAC) [44]. CAD polticas de control de acceso
basado en la identidad del solicitante y sobre las reglas de acceso que declaran lo que los
solicitantes se les permite hacer. MAC polticas de control de acceso basado en el mandato
Reglamento suplementos que determine la autoridad central. RBAC las polticas de control de
acceso en funcin de los roles que tienen los usuarios en el sistema y en las reglas que indican qu
accesos se permite a los usuarios en las funciones dadas.

En trabajos anteriores hemos definido un modelo de control de acceso y auditora (ACA) para ADs
mediante la especificacin de las normas de seguridad en el nivel conceptual [7]. Este enfoque se
basa en el control de acceso para garantizar la confidencialidad y la auditora, que son
componentes esenciales en el diseo de DW. Sin embargo, otra garanta incluye caractersticas
tales como el repudio de autenticacin, integridad y disponibilidad, aquello que constituyen
mecanismos comunes son de diseo independiente y dependen en mayor medida en las polticas
de la empresa. No se tienen en cuenta tanto por el modelo de ACA. El modelo ACA nos permite
representar la confidencialidad y medidas de auditora de DWs por clasificar a los sujetos y objetos
en el sistema.1 La clasificacin se basa en clases de acceso sobre la base de tres maneras
diferentes pero compatibles de usuarios Clasificar: por su nivel de seguridad, por su papel , y por
los compartimentos a los que pertenecen. La clase de acceso es un elemento de un conjunto
parcialmente ordenado de clases, en el que una clase de acceso c1 domina una c2if clase de
acceso y slo si el nivel de seguridad de c1 es mayor que o igual a la de c2, c1 de los
compartimentos de las primeras incluyen c2, y al menos una de las funciones de usuario de C1 (o
uno de sus antepasados) est definida para c2 [7].

Las clases siguientes se describen con el fin de que seamos capaces de especificar el modelo ACA:

Las funciones de seguridad del usuario son utilizados por la empresa para organizar a los usuarios
en una estructura jerrquica de papel, segn las responsabilidades de cada tipo de trabajo. Cada
usuario puede desempear ms de una funcin.
Los niveles de seguridad Indique el nivel de autorizacin del usuario. Por lo general, se trata de un
elemento de un conjunto ordenado jerrquicamente, como Top Secret (TS), Secret (S),
confidencial (C), y Sin clasificacin (U), donde TS> S> C> U.
Tambin compartimentos de seguridad del usuario son utilizados por una organizacin para
clasificar a los usuarios en un conjunto de compartimientos horizontales o grupos, tales como la
ubicacin geogrfica, el rea de trabajo, etc. Cada usuario puede pertenecer a uno o ms
compartimentos.
Con el fin de ilustrar el concepto anterior tenemos que considerar dentro de la organizacin de los
niveles de seguridad TopSecret (TS) y secretos (S) y los compartimentos de seguridad de Asia (SC =
A), Europa (E = SC), el sur de Europa (SE = SC ) y Europa del Norte (SC = NS). Por otra parte,
necesitamos los objetos O1, O2 y O3 con la informacin de seguridad siguiente: O1 = {S SL, SC =
NE, SE}, O2 = {TS SL, SE SC = {SL} y O3 = TS, SC = A , NE}. El usuario del sistema se denota por U
asociada a la informacin de seguridad siguiente: U = {TS SL, SC = E}. De acuerdo con la definicin
mencionada anteriormente de la clase de acceso U domina la clase de acceso de O1 y O2, pero no
domina la clase de acceso de O3, porque hay un compartimiento de O3 que no pertenece a los
compartimentos de U.

La Explicacin era anteriormente, el modelo ACA utiliza la clasificacin se basa usuarios y niveles
de objetos, funciones y compartimentos. Por lo tanto, el modelo ACA combina los modelos MAC y
RBAC. Modelos de Mac se han estudiado ampliamente, y muchas vulnerabilidades han sido
detectadas, como su falta de flexibilidad, su polyinstantiation [14], etc. Sin embargo, la mayora de
estos problemas surgen de la necesidad de tener en ambones Examen de lectura y escritura en el
sistema. Afortunadamente, tenemos en cuenta que el solo hecho de que la operacin ser
utilizado por los usuarios finales de los sistemas de apoyo a las decisiones se lee, por lo que el
modelo apropiado es absolutamente MAC. En contraste con el modelo de MAC, el modelo RBAC
Representa una direccin prometedora y un paradigma til para muchas organizaciones
comerciales y gubernamentales. [44]

El modelo ACA se ha integrado con el perfil de UML [23] con el fin de cumplir con el perfil para
clasificar Ambos seguridad de la informacin y el usuario para el diseo de DW seguras. El perfil
nos permite clasificar Esa informacin se utiliza para representar los problemas de seguridad
importantes en el modelado conceptual de DWS.

3,1. Alineacin Diseo seguro de almacenamiento de datos con MDA
Model Driven Architecture (MDA) es un estndar del Object Management Group (OMG), que
aborda el ciclo de vida completo de desarrollo de aplicaciones mediante el uso de modelos de
desarrollo de software. MDA se basa en la idea de separar la especificacin de la operacin del
sistema a partir de los detalles de su plataforma de [31]. MDA Propone varios modelos en
diferentes niveles: el modelo de clculo independiente (CIM), el modelo independiente de la
plataforma (PIM), el modelo especfico de la plataforma (PSM) y el Cdigo. En el marco de MDA
Definir el estndar para las transformaciones entre modelos anteriores es Query / Views /
Transformation (QVT) [34].

La figura 2 muestra las extensiones propuestas con el fin de establecer una relacin entre el ciclo
de vida DW y el marco de MDA. El modelo tiene en cuenta CIM seguro el trabajo de [26], que se
basa en una extensin de la i * [53]. En la siguiente seccin se adapta esta extensin para
representar los requisitos yunque funcionales y no funcionales para DWS. Secure PIM
Corresponde a una extensin del Lenguaje Unificado de Modelado (UML) Perfil por [23]
presentado en [51]. Este perfil nos permite considerar las caractersticas principales de los
modelos MD segura a nivel conceptual. El PSM Secure corresponde con una extensin del
metamodelo Almacn comn (CWM) a nivel lgico [48] y el cdigo de seguridad Corresponde a la
implementacin a nivel fsico, es decir, con un SGBD que implemente las cuestiones de seguridad.
Recientemente hemos utilizado los metamodelos de [51] y [48] para definir las relaciones QVT con
el fin de asegurar transformada de PIM en PSM asegurar en el diseo de DWs seguras [49]. Este
conjunto de relaciones QVT ha sido validado por medio de la elaboracin del estudio de caso [50].
En la siguiente seccin, el uso indicar la aplicacin de la fase de modelado de explicar cmo mapa
CIM a PIM seguro seguro mediante la aplicacin de un conjunto de directrices que se muestran en
la Seccin 4.4.1.



4. SEDAWA: Secure Engineering process for DAta WArehouses
The secure engineering process is proposed with the purpose of defining secure requirements and
transforming them in order to develop secure Data Warehouses. The proposal integrates the entire
DWs life cycle taking into account its relationship with the MDA framework depicted in Fig. 2. This
section describes our methodology, which is based on the standard Software Process Engineering
Metamodel Specification (SPEM) [32] from the Object Management Group (OMG).
4.1. SPEM metamodel: description and notation
SPEM is a process metamodel used to describe a concrete software development process or a
family of related software development process. The SPEM specification is structured as a UML
profile, and provides a complete MOF-based metamodel [32].
The SPEM metamodel offers the constructs and semantics required for the software development
process, which involve or require the use of Unified Modeling Language (UML), such as the
Rational Unified Process (RUP). RUP is therefore a software engineering process that is iterative,
architecture-centric, and use-case-driven [20]. RUP currently captures many of the best practices in
modern software development, since it is highly suitable for a wide range of projects and
organizations. However, we do not instantiate RUP since it has some disadvantages for our
purposes. For example, requirements in RUP are captured in a textual document called the Vision
Document, unlike our proposal which uses the goal/softgoal modeling diagram. Moreover, we
describe how security requirements are elicited and modeled in early activities and developed in
later phases of the DWs development process throughout a methodology. RUP, however, only
presents a set of guidelines to capture and employ security requirements.
The SPEM stand-alone metamodel is built by extending a subset of the UML metamodel. Fig.
3 depicts part of the SPEM metamodel that we will use in our engineering process, which is
supported by the Core andProcessComponent packages.



The main SPEM classes that inherit from the Core packages classes are: WorkDefinition ( ),
which describes the work performed in the process. Its main subclass is Activity,
but Phase, Iteration, andLifecycle are also subclasses of WorkDefinition. Activity ( ) describes a
piece of work performed by oneProcessRole, which may consist of atomic elements
called Steps. ProcessRole ( ) defines responsibilities and roles over specific WorkProducts that
perform and assist in specific activities. WorkProduct ( ) or artifact is anything produced,
consumed, or modified by a process (a piece of information, a document, a model, source code,
etc.). A Phase ( ) is a specialization of WorkDefinition such that its precondition defines the phase
entry criteria and its goal (often called a milestone) defines the phase exit criteria. A
process Lifecycle is defined as a sequence of Phases that achieve a specific goal. An Iteration is a
composite WorkDefinition that represents a set of Activities focusing on a portion of the system
development that results in a release (internal or external) of the software product. See Fig. 3 for
more details.
The main SPEM packages that inherit from the ProcessComponents package are: Package (just as
in UML), which is a container that can both own and import process definition elements. A Process (
) is aProcessComponent which is intended to stand alone as a complete, end-to-end
process. Discipline is a particular specialization of Package that partitions the Activities within a
process according to a common theme (see Fig. 3).
In the sequel we present an overview of the SEDAWA methodology. The following sections give a
detailed description of the four phases that we have considered in our methodology. In each section
we define activities, steps, and work products, which will be characterized according to the
discipline that they belong to.
4.2. An overview of SEDAWA
SEDAWA is structured into four consecutive phases: elicitation, modeling, implementation and test
delivery. The iterative style should be applied to the phases of our methodology. We define five
disciplines: requirements analysis, conceptual design, logical design, physical design and post-
development review, a new discipline introduced by Lujn and Trujillo [22].
Fig. 4 illustrates our SEDAWA methodology. We use the standard icons from SPEM [32],
i.e., Phase ( ),WorkProduct
2
( ) and Activity ( ). We omit certain elements from the SPEM
metamodel in the figure for reasons of better understanding. The engineering process is described
along the two axis. The horizontal axis represents time and the dynamic aspect of the process
expressed in terms of phases and iterations. The vertical axis represents the static aspect of the
process described by disciplines which cover the entire DW life cycle, described in terms
of Activities, WorkProducts, Steps, etc.




The engineering process begins with the Enterprise Architecture WorkProduct as input for activity
A1.1. The Enterprise Architecture contains designs of the business processes, organizational
structures, components, physical resources, products and services from the organization.
This WorkProduct can be used, by applying activities A1.1, A1.2 and A1.3 from the Elicitation phase
to obtain three models: (1) GOModel which contains informational requirements for DWs, i.e.,
functional requirements; (2) SOModel which contains security requirements for DWs; and
(3) GSAModel which merges the above models and constitutes a secure CIM for DWs. The
Modeling phase is conducted by activities A2.1, A2.2. Activity A2.1 receives as input
theWorkProducts GSAModel and Secure MD metamodel (whose instance will be produced, see the
metamodel shown in Appendix A). Activity A2.2 receives as input the MD
model WorkProduct obtained from activity A2.1 and the operational sources WorkProduct that will
serve to populate the secure DWs repository. The implementation phase is carried out by activity
A3.1, which receives as input the enriched secure MD modelWorkProduct obtained from activity
A2.2. In addition A3.1 receives the SECure Relational Data Warehouses (SECRDW) metamodel
(whose instance will be produced, see the metamodel shown in Appendix B) and the DBMS specific
(which will implement the secure DWs repository) WorkProducts. Finally, the testdelivery phase
contains the activity A4.1 in order to verify, test and deliver the secure DW repository.
According to SPEM our methodology is described by using the structure shown in Fig. 5 (see class
description from SPEM explained in Section 4.1). Each activity specifies WorkProduct as both input
and output, respectively. A more detailed explanation of each phase is described in the following
subsections.



4.3. Elicitation phase
The elicitation phase comprises three activities: Goal/organizational analysis (A1.1), which receives
as input the WorkProduct Enterprise Architecture. Security organizational-based analysis (A1.2)
receives as input the outputs from activity A1.1, i.e., the Goal organization model (GOModel) and
Organizational architectureWorkProducts. Finally, Goal/Softgoal analysis (A1.3) has as
input GOModel, SOModel and the security policy document, which constitutes
the WorkProducts output from A1.2. The output of activity A1.3 is the Goal/Softgoal analysis model
(GSAModel), i.e., the secure CIM (see details in Fig. 4). In order to carry out the above activities
several steps are performed for each activity, as we can see in Fig. 6, Fig. 8 and Fig. 10. During this
phase the iterative style has strong emphasis on the requirements analysis discipline. See
theGOModel, SOModel and GSAModel WorkProducts in Fig. 4. We must clarify that an explanation
of the goals that are elicited is not within the scope of this paper.



In order to define security requirements for the requirements analysis discipline we have adapted
the i

framework which permits the modeling and reasoning of the organizational environment and its
information system by using [53]. This establishes two main modeling components. The Strategic
Dependency (SD) model is used to describe the dependency relationships among various actors in
an organizational context. The Strategic Rationale (SR) model is used to describe stakeholder
interests and concerns, and how they might be addressed by various configurations of systems and
environments. However, for our purposes we only need SR models, which are depicted in Fig. 4 as
the GOModel, SOModel and GSAModel WorkProducts.
4.3.1. Goal/organizational analysis (A1.1)
Activity Goal/organizational analysis (A1.1) (see Fig. 6) is performed by
the ProcessRole requirement engineer. The input is the enterprise architecture (to discover the
domain infrastructure). Several steps are necessary to achieve its outputs (WorkProducts
GOModel and Organizational architecture). GOModelrepresents the informational requirements for
DWs, i.e., the functional requirements.
Activity A1.1 is based on the work by [26], in which the authors adapted the i

framework [53] to the

modeling of goals and information requirements for DWs. The approach is supported by a UML
profile [33] which is integrated with the Model Driven Architecture (MDA) framework of [25]. The
adaptation of the i

framework is based on two extensions of UML [33]: (i) a profile for i

and (ii) a
profile which adapts i

to the DW domain. In accordance with the UML specification [33], in Fig. 7 we

show the packages which resume the elements contained in proposal [26]. The profiles use two
kinds of extending relationships: the Extension relationship (whose arrowhead is shown as a filled
triangle) which points from stereotypes (the extending elements, labeled as stereotype) to
metaclasses (the UML extended elements, labeled as metaclass), and
the Generalization relationship (an arrowhead with a hollow triangle) between stereotypes. On the
left hand side of Fig. 7 we have represented the i

profile by means of various UML metaclasses

(i.e., Package, Class,AssociationClass, and Association) and stereotypes
(the IElement, Argumentable, and IRelationshipstereotypes). These stereotypes permit the
representation of SR and SD models belonging to the i

framework.



On the right hand side of Fig. 7 we show the i profile for DWs, which is based on a
classification of the different kinds of goals that decision makers expect to fulfill with the DWs:
(i) Strategic goals represent the highest level of abstraction. These are the main objectives of the
business process (for example, increase sales); (ii) Decision goals represent the medium level of
abstraction. They attempt to answer the question: how can a strategic goal be achieved? (for
example, determine some kind of promotion); (iii)Information goals represent the lowest level of
abstraction. They attempt to answer the question: how can decision goals be achieved in terms of
information required (for example, analyze customer purchases or examine stocks). The profile
reuses the previous stereotype Goal, as we can see in Fig. 7.
For decision makers, every goal must be specified according to the classification of goals in terms
of the strategic-decision-information hierarchy. Information requirements (Requirement as Task on
the right hand side of Fig. 7) for decision makers are derived from information goals. The profile has
added three MD elements as resources: the business process to be analyzed
(BusinessProcess stereotype), process measures under analysis (Measure stereotype), and
context of analysis (Context stereotype). These stereotypes are, therefore, derived from Resource
(see right hand side of Fig. 7).
The i

profile for DWs provides a mechanism with which to represent actors (IActor, ) and their
goals (Goal, ). The information requirements of decision makers are considered as tasks
(Task, ), and the elements needed in the DW to provide such information are considered as
resources (Resource, ). According to the type of DW element, these resources can be labeled as
BusinessProcess, Context, or Measure. We furthermore model relationships such as
means-end (MeansEnd, ) thus representing alternative means to fulfill goals, or tasks, i.e., the
possible relationships are GoalGoal and GoalTask. Decomposition (Decomposition, )
represents the elements which are necessary if a task is to be performed. Additionally, the profile
allows us to define aggregation relationships between context of analysis (for instance, the city
context can be aggregated by the country context). In order to model these relationships, we have
used the (shared) aggregation relationship of UML (Association UML metaclass, represented
as ).
4.3.2. Security organizational-based analysis (A1.2)
Once the functional requirements have been identified we need to define security requirements for
DWs by means of the following activities. Fig. 8 depicts the Security organizational-based analysis
activity, which is performed by the SecurityExpert ProcessRole and has as output the Softgoal
Organizational Model (SOModel) and the security policy document.



SOModel is built with an adaptation of the i

framework in order to represent security requirements

for DWs based on the Access Control and Audit (ACA) model. Fig. 9 depicts how the adapted
profile reuses stereotypes from the i

for DWs.



The proposed extension for i

offers mechanisms with which to represent a special security

manager actor (SecurityManager, ), who is the person in charge of the security within the
organization. Softgoals (SSoftgoals, ) are introduced to represent and refine the organizations
security policy. The elements with which it is necessary to represent the ACA model are considered
as resources (Resource, ) labeled as SCompartment (to represent the horizontal compartment
or groups of users from the organization such as geographical localization ), SLevel (to define
the clearance level, usually named TopSecret, Secret,Confidential and Unclassified) and SRole
(to represent a role from the hierarchical roles defined within the organization). See right hand side
of Fig. 9. Moreover, in order to specify constraints for resources, we introduce several tasks
(Task, ), which are labeled as SConstraintRule (to indicate additional constraints with
regard to the multilevel security policies), SConstraintAudit (to indicate future audit) and
SConstraintAuthorization (to indicate additional more elaborate constraints with regard to the
access). These constraints represent rules that contribute to the fulfillment of SSoftgoals through
the contribution link (Contribution, ). We model the refinement process of softgoals by means
of the means-end link (MeansEnd, ). Finally, each of the softgoals which has been refined is
detailed into resources (i.e., BusinessProcess, Context, or Measure) by means
of Decomposition link ( ). We also have three packages (GOModel, SOModel and GSAModel).
As was previously stated, GOModel contains the i

model for DWs (i.e., functional requirements

obtained from activity 1.1). SOModel contains the securei

model for DWs (i.e., security

requirements) and the GSAModel contains GOModel, SOModel packages and their relationships.
4.3.3. Goal/Softgoal analysis (A1.3)
It is now necessary to mix the information requirements obtained from activity 1.1 with
the SSoftgoalsobtained from activity 1.2 in the Goal/Softgoal analysis activity (1.3). Fig. 10 shows
the activity, which is defined through several steps. The output of this activity is the Goal/Softgoal
analysis model (GSAModel), i.e., a model that mixes previous models. The activity needs the
three WorkProducts obtained previously: the Goal organizational model, the Softgoal organization
model, and the Security policy document



4.4. Modeling phase
This subsection comprises two activities which cover the conceptual stage for the DW design. The modeling
phase is carried out by the use of two activities. Both the information and the security requirements defined at
the business level (i.e., secure CIM) must be transformed into the conceptual level, i.e., into the corresponding
secure PIM.
As was mentioned in the previous section, the PIM corresponds with an extension of the UML presented
in[51], which the information is clearly organized into secure facts and secure dimensions. These secure facts
and dimensions are modeled by SFact (represented as ) and SDimension ( ) stereotypes,
[Link] and SDimension are related through shared aggregation relationships
(the Association UML metaclass) in class diagrams. While an SFact is composed of measures or secure fact
attributes (SFactAttribute stereotype, SFA), with regard to SDimensions, each aggregation level of a hierarchy
is specified by classes stereotypes such as SBase ( ). Each SBase class can contain several secure dimension
attributes (SDimensionAttribute, SDA) and must also contain a secure descriptor attribute
(SDescriptor attribute, SD). An association stereotyped as Rolls-upTo (Rolls-UpTo)
between SBaseclasses specifies the relationship between two levels of a classification hierarchy. Within this,
role R represents the direction in which the hierarchy rolls up, whereas role D represents the direction in
which the hierarchy drills down. The information about all users who are entitled to access the MD model are
represented as instances of the UserProfile class (stereotype UserProfile, ). The UML metamodel which
supports the secure PIM is shown in Appendix A.
This proposal allows us to classify both, information and users in order to represent the main security aspects
in the conceptual modeling of DWs. Security information is defined for each element of the model
(SFact, SDimension, SFactAttribute, etc.) specifying a sequence of security levels a set of user compartments
and a set of roles. Moreover, the constraints (AuditRule, AuthorizationRule and SecurityRule) are modeled
through the UML notes. These constraints are defined following the syntax of the ARs, AURs and SIARs
rules from the ACA model (more details in [7], [6] and [51]). We shall now present activities A2.1 and A2.2.
4.4.1. Secure Data Warehouse design (A2.1)
Fig. 11 shows activity 2.1 which is called the Secure Data Warehouse design. The goal of this activity is to
map the secure CIM obtained during the elicitation phase onto the secure MD model, i.e., the output is the
secure MD model (secure PIM). As input the activity has the WorkProducts GSAModel (secureCIM) and the
Secure MD metamodel (see Appendix A). The activity takes place in several steps.

In order to map secure CIM onto secure PIM we need to apply a set of QVT relations, which is part
of our future work. We shall limit our efforts to defining a manual transformation between secure
CIM (GSAModel) and secure PIM based on the guidelines presented below.
In the sequel we suggest several guidelines for transforming the secure CIM into the secure PIM:
Guideline G1: Related to actors.
Guideline G2: Related to BusinessProcesses.
Guideline G3: Related to Measures.
Guideline G4: Related to Contexts.
Guideline G1:
Actors in the GSAModel (secure CIM) are mapped onto the userProfile class of the MD
model. By default the userProfile class will contains three
attributes: securityLevel (SL), securityRole (SR) andsecurityCompartment (SC). According
to the ACA model, these attributes allow us to represent the security information for each of
the systems users.
Guideline G2:
Create an SFact class for each BusinessProcess in the GSAModel. The name of
the SFact in the MD model will be the name of the BusinessProcess in the GSAModel.
Several guidelines are given to obtain the security information associated with the SFact in
the MD model.
Guideline G2.1:
SLevel, SRole and SCompartment decomposition associated with
the BusinessProcess resource through an SSoftgoal dependency in GSAModel are
mapped as SL, SR and SC classes associated with the SFact that represents the
corresponding BusinessProcess.
Guideline G2.2:
Each SConstraintRule task that makes a positive contribution to an SSoftgoal, which
constitutes anSSoftgoal dependency for the BusinessProcess in the GSAModel is mapped
as a SecurityRule class associated with the SFact in the MD
model. SConstraintAudit and SConstraintAuthorization tasks in the GSAModel are dealt
with in an analogous manner.
Guideline G3:
Each resource labeled with the stereotype Measure associated through the Strategic,
Decision and Information goal with the BusinessProcess detected in guideline G2 is
mapped as SFactAttribute for the SFact that corresponds with the BusinessProcess.
Guideline G3.1:
SLevel, SRole and SCompartment decomposition associated with the Measure resource
through aSSoftgoal dependency in GSAModel are mapped as SL, SR and SC classes
associated with theSFactAttribute which represents the corresponding Measure.
Guideline G3.2:
Each SConstraintRule task that makes a positive contribution to an SSoftgoal, which
constitutes anSSoftgoal dependency for the Measure in the GSAModel is mapped as
a SecurityRule class associated with the SFact that contains
the SFactAttribute corresponding to
the [Link] and SConstraintAuthorization tasks associated
with Measure in the GSAModel are dealt with in an analogous manner.
4.4.2. Enriched Secure Data Warehouse design (A2.2)
Activity 2.1 has been used to obtain a secure PIM, whose elements
are BusinessProcess, Context andMeasure. Logically, we cannot identify the whole MD model,
because the level of granularity is very low (observe in Fig. 18 that certain classes do not have any
attributes). Hence, we need to enrich this secure PIM with operational data sources that will
populate the DW repository. Fig. 12 shows activity 2.2, which guarantees as output an enriched
secure MD model, i.e., an enriched secure PIM. This activity receives as input two WorkProducts:
the secure MD model and operational data sources. The goal of this activity is to revise other
detailed technical aspects and constructors which do not belong to the organizational model, taking
into account the operational data sources available.


During this activity the expert modeler and the project manager ProcessRoles need to increase the
descriptive level of the secure MD model WorkProduct. The needs of the final users of the DWs are
revised again in order to match technical details not contained in the secure MD model, i.e., to
match complex end users queries with the secure MD model. User needs are not only needs which
are taken into account in order to define a secure DWs. The secure DWs repository will be
populated with operational sources (data sources) such as Online Transaction Processing (OLTP)
systems, external data sources (syndicated data, census data), etc. Hence, we need to examine
the available operational sources and compare them with the secure MD model (secure
PIM) WorkProduct. As result, new classes, new associations between them and new attributes can
be added to the secure MD model. Therefore, we need to value the security policy according to the
new valuable assets, and to establish new security information (SL, SR and SC) and additional
constraints to the secure MD model. Once executed the steps included in activity 2.2 have been
executed, we have as output the enriched secure MD model as output WorkProduct.
4.5. Implementation phase
This phase is devoted to obtaining code for specific DBMS through activity 3.1, which is based on
previous work related to MDA. The implementation phase covers the logical and physical stages of
the DW design. As was explained in the previous subsection, the secure PIM is modeled by using
the metamodel proposed by Villarroel et al. [51]. Depending upon the MDA, the secure PIM must be
transformed into a secure PSM. In order to define the secure PSM for the logical level we use the
metamodel presented in [48], in which we extended the relational package from the Common
Warehouse Metamodel (CWM). The extended metamodel is called the SECRDW metamodel
(see Appendix B) which permits the representation at the logical level of all the security and audit
measures captured during the conceptual modeling stage of the DWs design.
The SECRDW metamodel defines a container SSchema which is inherited from
Schema. SSchema is a collection of STables and securityProperties and is aimed at security at the
model level. A ColumnSetrepresents any form of relational data. An STable and UserProfile are
inherited from Table, which containsColumns. The UserProfile table contains columns through
which to specify the access properties (securityProperty) that the user has. UserProfile,
unlike STable, is unique and has no association with the other tables in the system.
A ForeignKey associates columns from one table with columns from another table.
The PrimaryKey class inherits from the UniqueConstraint.
The PrimaryKey and ForeignKeymetaclasses are owned by the STable metaclass (see metamodel
shown in Appendix B). Certain metaclasses are used to represent security and audit measures in
the metamodel. The SecurityPropertymetaclass inherits from the Class (from the Core) metaclass
and specializes in SecurityLevels,securityCompartments and securityRoles classes. Furthermore,
other classes are also used to represent security constraints, authorization rules and audit rules in
the metamodel: the AuditConstraint class, theARConstraint class and the AURConstraint class,
which inherit from the SecurityConstraint metaclass. The aforementioned classes, along with the
associations between them, can be observed in Appendix B.
Fig. 13 defines activity 3.1, which is called secure code implementation. The activity comprises
several steps, which guarantee the transformation of the MDA between the enriched secure PIM
and the secure PSM, and between the secure PSM and the secure code. Hence, the activity has as
output the secure PSM and the secure code has as output WorkProducts. The Secure MD
metamodel, the secure MD model, the SECRDW metamodel and, the DBMS
specific WorkProducts are the inputs of this activity.


The secure PSM corresponds with the logical level, which is designed according to the specific
properties of the DBMS such as Relational Online Analytical Processing (ROLAP), Multidimensional
Online Analytical Processing (MOLAP) or Hybrid Online Analytical Processing (HOLAP).
Nevertheless, Kimball and Ross [17]assures us that the most common representation is through the
relational platform (i.e., ROLAP systems). Unfortunately, other metamodels for PSMs such as
MOLAP or HOLAP have to be extended in order to support security issues. Also, the definition of
the transformation between previous PSMs can be defined (see future work in Section 7). In
relational systems the main schema types with which to represent DWs are star, snowflake and fact
constellation schemas. Therefore the first step is to decide the schema type with which to represent
the secure DWs. In our context we have decide to use a star schema. The QVT relations applied to
the enriched secure PIM will allow us to obtain the secure PSM automatically. At this point the
revision of all the security measures obtained by using the QVT relations is appropriate, since new
needs may appear. We shall now examine the security advantages for the specific DBMS that will
store the secure DWs repository, i.e., Oracle, DB2, etc. Finally the secure code for a specific DBMS
is automatically obtained by applying the proposal Model2Text[35], which is part of our future work
(see Section 7).
4.6. Testdelivery phase
This phase is comprised solely of the activity verification and validation performed by
the ProcessRolesexpert modeler and project manager. The activity does not produce
new WorkProducts as output. The work carried out during the testdelivery phase has a direct
relationship with the post-development review discipline. This discipline allows us to look back at
the development of DWs, revise the documentation created, and attempt to identify both
opportunities for improvement and major successes that should be taken into account [22].
Fig. 14 defines activity 4.1 through the various steps carried out by the ProcessRoles expert
modeler and project manager. Numerous testing techniques in the specialized literature have been
proposed but it is accepted that they can be carried out the use of verification and validation
methods [37]. The objective of verification testing is primarily to ensure that the secure DWs has
been correctly built. The defects found must be corrected. The objective of validation testing is to
determine whether the secure DWs has been built correctly. In other words, does the secure DW
perform as was expected? During validation testing, test data and so on will be created [37].


Several steps are undertaken in order to carry out activity 4.1. Internal validation and external
verification as expressed in [28] are the main issue when verifying that all requirements have been
correctly implemented. Internal verification must identify potential conflict among security
requirements and the remaining requirements, and detect incomplete, inconsistent,
incomprehensible, or ambiguous requirements specification. Several techniques can be used when
performing the verification process such as peer reviews, checklists or Fagans methods [27].
Moreover, conflicts can be detected and solved by using the proposal of [19] through the graph-
based approach for the specification of Access Control policies. Vulnerabilities are discovered by
analyzing threats to and attacks on both the requirements and the DW repository (i.e., at both,
business and application-levels). One of the best known techniques through which to model
threats/attacks are attack trees, which contain threats, and their possible attacks [45]. This issue will
be studied (see section dealing with Future work). Once the vulnerabilities have been found and
emended we verify the quality acceptance level by testing the DWs with users. If the quality is
assured and the users and maintainers have received training then we decide to release and
deliver the final secure DWs.
5. A pharmaceutical consortium: an example of application
In this section, we apply our secure engineering process (SEDAWA) to the context of a
pharmaceutical consortium. This consortium manages several pharmacies which offer various types
of services to the community, and wishes to control all aspects related to the sales of medicines
through medical prescriptions. A patients prescription contains the patients data, information
related to its illness and the medicine that should acquire. In order to satisfy the demands that
presupposes the previous problem is required a secure DWs.
In the following subsections we apply the four phases that comprises the process. Our process is
iterative and incremental thereby is necessary to plan the iterations that will be executed. In this
section we consider only one iteration in order to make more understandable the example.
5.1. Elicitation phase: example
This phase comprises three activities (A1.1, A1.2 and A1.3). The WorkProduct output
is GSAModel (i.e., secure CIM).
5.1.1. Activity A1.1
Fig. 15 shows the GOModel obtained as WorkProduct output from activity A1.1. The business
process is related to one main actor, the marketing manager via the strategic goal increase
prescription sales. Two different decision goals are derived from this strategic goal: decrease
prescription price and give incentive to pharmacist. The following information goals have been
obtained from each of these decision goals: decrease prescription price and analyze prescription
price. The derived information requirements are as follows: analyze price by patient, prescription
and pharmacy, and analyze sales by pharmacy, prescription and pharmacy_type. In Fig. 15, each
of these elements are defined as goals (strategic, decision and information goals) or tasks
(information requirements). Furthermore, several resources are associated with the information
requirements where necessary, such as measures and context of analysis. The measures are
Sales and Price. The elements that represent context of analysis are
Prescription, Pharmacy andPharmacy_Type, but these are related to each other, since they
represent means of aggregating the Pharmacy data. Patient is also a context of analysis, but has
no relationship to the other Contexts. Fig. 15represents the functional requirements for DWs.
According to MDA it represents a CIM without security.

5.1.2. Activity A1.2
The security requirements for DWs are obtained by applying activity A1.2. Hence, we focus on the
sales prescription process as a security policy, which is performed by the SecurityManager actor via
the guarantee the security for the sales prescription process SSoftgoal. By using a refinement
process, three new softgoals are obtained: guard the security of use of certain medication and
consumers rights, maintain privacy of sales, price and patients data and impose a clearance level
on prescription process (see Fig. 16). Various responsibilities are discovered in this process.
Hierarchical relations are therefore defined, of which the most general is PharmacyEmployee, which
is then specialized into the Pharmacist (Pharma) andAdministrative (Admin) roles. Horizontal
groups (compartments) within the organization are detected:pharmacovigilanceCenter (pharmaC),
which is responsible for the security of the use of certain
medicationsand commercialManagerCenter (commercialC), which is responsible for
commercialization and supply. Restriction levels are established by means of TopSecret (TS)
and Secret (S). Note in Fig. 16 how the security resources are associated with their
corresponding SSoftgoals. Fig. 16 represents the WorkProductoutput (SOModel) from activity A1.2.

5.1.3. Activity A1.3
By means of activity A1.3 the WorkProducts output from activities A1.1 and A1.2 are merged in
theWorkProduct GSAModel. Fig. 17 shows how GOModel and SOModel are merged by means of
theDependency association ( ). The requirements shown in Fig. 15 are associated with
the SSoftgoalscontained in Fig. 16. If we are to fulfill previous SSoftgoals we need to associate
resources contained
inGOModel (i.e., Sales_Prescription, Patient, Price, Prescription, Pharmacy_Type and Sales) with
theSSoftgoals contained in SOModel. For example, impose maximum level of restriction on the
sales prescription (marked in Fig. 17 with the number 1) and Guarantee the secure use of
medication norms (marked in Fig. 17 with the number 5). The remaining SSofgoals which establish
associations with resources from GOModel are dealt with analogously (see the SSoftgoals marked
with the numbers 2, 3 and 4 in Fig. 17). The aforementioned SSoftgoals are, therefore, achieved
through a Dependency association between theSecurityManager and
the MarketingManager. Sales_Prescription is associated with the Impose maximum level of
restriction on the sales prescription SSoftgoals whose SLevel is TopSecret.



Other SSoftgoals are, moreover, associated with resources
(Patient, Price, Prescription, Pharmacy_Typeand Sales). Sales_Prescription and Prescription are
very valuable assets, and therefore, need additional restrictions. Fig. 17 shows how
the SOModel has been modified with the SRule and Audit constraints, which are labeled
as SConstraintRule, SConstraintAudit, respectively. SRule contributes to the fulfillment of
theSSoftgoal impose maximum level of restriction on the sales prescription, so according to the
dependency association defined, it is related to both the BusinessProcess
Sales_Prescription and Context Prescription, respectively. The same reasoning assures that
the Context Prescription will be related to the Auditconstraint. Moreover, other SSoftgoals are
associated with resources (Patient, Price, Prescription,Pharmacy_Type and Sales). These are dealt
with in an analogous manner.
According to MDA Fig. 17 can be seen as a secure CIM because its represents both functional and
non-functional requirements in the same model. In accordance with the classification for users of
the ACA model introduced in Section 3, each of the systems user will
have securityLevel, securityRole andsecurityCompartment. Hence, we can conclude that a user has
access to Sales_Prescription if his/her access class dominates the access class
of Sales_Prescription, i.e., his/her security level is TopSecret (in this restricted case).
We have developed a prototype case tool in order to assessment the secure engineering process
by using Eclipse development platform framework.
5.2. Modeling phase: example
The modeling phase guarantees both, map secure CIM (WorkProduct GSAModel obtained from
A1.3) onto secure PIM and enrich it with the operational data sources that will populate the DW
repository.
5.2.1. Activity A2.1
In order to define a map between a secure CIM (represented in Fig. 17) and a secure MD model
(secure PIM), we apply a set of guidelines which correspond with the steps from activity 2.1. As we
can see in Fig. 17 we have only one actor, denoted as MarketingManager, which will be an instance
of the UserProfile class. The values of SL, SR and SC for each actor are (for the moment) unknown
due to the granularity at this level.
We also have only one BusinessProcess (see the GSAModel depicted in Fig. 17). According to G2
theSales_Prescription BusinessProcess should be mapped onto the Sales_Prescription
SFact (see Fig. 18). Note in Fig. 17 how the SecurityManager depends on the MarketingManager to
achieve the SSoftgoalsmarked with the numbers 1 and 2. According to G2.1 the Sales_Prescription
SFact is associated with the SLSecret (S) and TopSecret (TS), which are represented in its heading
(see Fig. 18). According to G2.2 theSales_Prescription SFact is associated with the SecurityRule 1,
which is modeled in Fig. 18 by using a UML note.



With regard to Measures, we have the Price and Sales (see GSAModel in Fig. 17) which are
mapped asSFactAttributes in the MD model, as Fig. 18 shows. In Fig. 17 we can see
that SecurityManager depends onMarketingManager to achieve the SSoftgoals marked with the
number 4. Hence, according to G3.1 these attributes are associated with the SR Admin (see Fig.
18). These Measures do not have associated security constraints
(SConstraintRule, SConstraintAudit and SConstraintAuthorization).
In Fig. 17 we have two Contexts of analysis: (i) the Patient Context is transformed into the Patient
SDimension in the MD model (see Fig. 18) and (ii) the Pharmacy, Pharmacy_Type and Prescription
Contextsrepresent the SDimension Pharmacy. According to G4.1 the Pharmacy Context represents
the SBase root of the SDimension Pharmacy (see Fig. 17). If we apply G4.2,
the Prescription and Pharmacy_Type Contextsare mapped as SBases in the MD model. The UML
aggregations between them and the Pharmacy Contextare mapped as a Rolls-upTo association
between the corresponding SBase classes in the MD model (seeFig. 18).
In Fig. 17 we can see that SecurityManager depends on MarketingManager to achieve
the SSoftgoalsmarked with the numbers 1, 3 and 5. Hence, according to G4.3, the Prescription
Context is associated with the SL TopSecret (TS), the SR Pharma and the SC PharmaC (see Fig.
18). According to G4.4 thePrescription Context is associated with the AuditRule 2 and
the SecurityRule 3, which are represented in the MD model shown in Fig. 18 by using UML notes.
These constraints are obtained by taking into account theSSoftgoals dependency marked in
the GSAModel (see Fig. 17) with the numbers 1 and 5, between
theSecurityManager and MarketingManager.
5.2.2. Activity A2.2
As was previously stated, the activity 2.2 contrasts the secure PIM (obtained from activity A2.1) with
the operational data sources available. The WorkProduct output from activity A2.2 is the Enriched
secure MD model (enriched secure PIM). This activity is carried out manually, with which the
designer can retouch the incipient secure MD model (secure CIM) obtained from activity A2.1.
If we continue with the example that we have been developing, it now follows that we apply activity
A2.2. Fig. 19 shows an instance of our enriched secure PIM (see metamodel shown in paragraph
A), which makes part of the DW that is required for the previous problem more complete. The SFact
Sales_Prescription(stereotype SFact) contains all the sales information in one or more pharmacies,
and can be accessed by users who have Secret or topSecret security levels, play
an Administrative or Pharmacist role and belong
topharmacovigilanceCenter, healthOversightCenter (the committee which guards the health of the
companys clients) and commercialManagerCenter compartments. The sales attribute can only be
accessed by users who perform the administrative role (tagged values SR of sales attribute) and
belong to thecommercialManagerCenter compartment, and access to this attribute will therefore be
forbidden to other users who are (pharmacist and maintenance employees or belong to other
differentcommercialManagerCenter compartments). The income attributes can only be accessed by
users who perform the administrative role (tagged value SR of income attribute). Other static user
classifications for the conceptual model classes defined in Fig. 19 are:


The SFact Sales_Prescription which contains
three SDimensions (Pharmacy, Patient and Medication), which contains SBase hierarchies. Access
to these SBase hierarchies is established in the same way as was done with the SFact.
The UserProfile has been completed in order to store information about all users who will have
access to this secure MD model.
Several security constraints have been specified by using the previously defined constraints,
stereotypes and tagged values. The following paragraphs correspond to notes 1, 2 and 3 in Fig. 19:
1.
For each instance of the SFact class Sales_Prescription, if the type of payment is through
insurance then the security compartment will be commercialManagerCenter (commercialC,
tagged value SC). This constraint is only applied if the user makes a query whose
information comes from DataPharmacy.
2.
We would like to record, for future audit, the subject, object and time of every frustrated
access attempt upon Prescription.
3.
For each instance of the SBase class Prescription, if the prescription is of the type
socialSecurity, then the security level will be Secret (Secret, tagged value SL).
5.3. Implementation phase: example
By means of this phase is obtained the secure PSM (relational) and the corresponding code for
specific DBMS. The Implementation phase comprises only the activity A3.1.
5.3.1. Activity A3.1
By using the PIM in Fig. 19 as a starting point, we apply a set of QVT relations [49] (contained as
step within the activity A3.1) through which to achieve an instance of the secure PSM. The
transformation ensures thatSFact and SDimensions are transformed into STables with their
associated security information. TheUserProfile class is transformed into a
classical Table from CWM. Fig. 20 represents a star schema at the logical level, which corresponds
with an instance of the relational metamodel from the CWM extended in [48].



The SFact Sales_Prescription is represented in Fig. 20 by means of the STable Sales_ Prescription.
All of its columns are represented in this table along with all the associated security information,
which restricts access both to the table itself and to its columns. All the hierarchy that conforms to
an SDimension must be represented by means of a single STable. Observe in Fig. 20 that
the Pharmacy STable contains asSColumn the attributes from the SBases
DataPharmacy, Pharmacy_Type and Prescription classes fromFig. 19. This occurs in an analogous
manner with the Patient and Medication SBases classes. In order to build a star scheme
the Sales_Prescription table must contain columns such as Foreign Key(FK) which
represent Primary Key (PK) in the tables that correspond with SDimensions at the PIM level.
The security information (SL, SR and SC) represented in the classes from Fig. 19 is modeled at the
logical level in the title of the table itself (See Fig. 20).
The SecurityRule1, AuditRule2 and SecurityRule3 security constraints that appear in Fig. 19 are
transformed into instances of the SecurityConstraint from the extended relational metamodel. These
instances are modeled in Fig. 20 by means of UML notes with the
names ARConst1 and AURConst2, respectively. ThesecurityRule3 attempts to change the security
for the SBase Prescription class, thus establishing new values for securityLevel (SL). As we
observed in Fig. 19, the security of the SBase Pharmacy class has been assigned to the SColumns
NumPres, nameP and type. Hence, the constraint is transformed and applied to SColumns
NumPres, nameP and type. Consequently, the SecurityRule3 is transformed into
threeARConstraints, which appear in Fig. 20 under the names
of ARConst3.1, ARConst3.2 and ARConst3.3, which are associated with the SColumns
NumPres, nameP and type, respectively.
To illustrate the step related to obtain code for a specific DBMS (contained as step within the
activity A3.1), we shall briefly show the possibilities that Oracle 11g DBMS offers in order to
implement security and audit measures by means of Oracle Label Security (OLS11g), Virtual
Private Databases (VPD) and Oracle Fine-Grained Auditing (FGA). We shall only explain the
security aspects that our extension contemplates, and to do this we have first created a security
policy named MyPolicy along with valid levels, compartments and hierarchical groups. See Fig.
21.



In Fig. 21a we show how User1 satisfies the security properties for the Sales_Prescription
STable. Fig. 21b shows how we define and establish the security information for
the Sales_Prescription table by labeling functions from OLS, although it is not possible to consider
security at the column level. The ARConst 1 is implemented by means of the labeling function
represented in Fig. 21c. The FGA allows us to define and implement the AudConst 2 (see Fig. 21d).
In AudConst 2 we cannot implement the logType because FGA does not allow us to choose it.
5.4. Testdelivery phase: example
This phase comprises only one activity. As we said above, we have only developed one iteration to
make more understandable the example. Hence, we assume that all steps belonging to activity
A4.1 have been executed, i.e., all informational and security requirements have been correctly
implemented, both the repository and the requirements do not have vulnerabilities, we achieve
good acceptance level of quality and we delivery the final secure DWs to the end users.
With the aforementioned comment we finish the development of the secure DWs corresponding to
the pharmaceutical consortium example. In the next section we show how the prototype CASE tool
that we are developing is applied to the example.
5.5. Applying a prototype case tool
Currently we are developing a prototype case tool based on the Eclipse
3
development platform
(see Fig. 22). We employ several of its plug-ins implementing the MDA standard: for instance, the
model development tools (MDT) for supporting UML and UML profile, the eclipse modeling
framework (EMF) for specifying the CWM extended [48], ATLAS Transformation Language
(ATL)
4
project in order to specify the secure CIM-secure PIM and secure PIM-secure PSM
transformations and MOFScript to design model-to-codeMOF2Text[35] mappings to automatically
implement the final secure DWs. We have combined the aforementioned defined plug-ins to provide
an integrated development environment (IDE) to design secure DWs projects based on the secure
engineering process proposed in Section 4.



Fig. 22 shows the tools that we have implemented as proof of concepts of our secure
engineering process. On the left-hand side of the figure, the Pharmacy Secure Data Warehouse
project have been initiated, which automatically creates the secureCIM, securePIM,
securePSM and secureCODE folders within the EclipseWorkspace. If we create the pharmacy
project for defining the secure CIM, then within the secureCIM folder appears the [Link] and
[Link] files (see left hand side of the figure). The [Link] file allows us to define
the GSAModel, GOModel and SOModel diagrams (see the middle part of the Fig. 22) by using the
corresponding tools, which appear on the right hand side of the own figure. The [Link] file
allows us to editing the created diagram by using the UML model editor from Eclipse. The figure
also, shows on the right hand side the necessary tools in order to define GOModel and SOModel. In
the upper part of the figure appears the classical menu bar from Eclipse, which have been adapted
to support the Transform and Secure Transform menu options. The Transformation (Secure
Transformation) menu option corresponds with the DWs development without security (with
security). The Secure Transformation menu option includes theIDW Secure CIM to Secure MD PIM
(ATL), Secure MD PIM to SECRDW <CWM> PSM (ATL) andSECRDW <CWM> PSM to SQL Secure
CODE (MOFScript) in order to transform the secure CIM into the secure PIM, the secure PIM into
the secure PSM and the secure PSM into the secure CODE, respectively. The OCL Validation
menu option implements and checks the associated constraints to the metamodels employed.
6. Limitations of SEDAWA
Our secure engineering process contributes to automatize the development of secure DWs
projects. Nevertheless, our proposal has some limitations:

The step related to the transformation of secure CIM to secure PIM requires a manual
retouch in order to contrast the secure PIM with the operational data sources obtained. This
is because the CIM model has a very high abstraction level.

The architecture can be completed with other secure relational paradigms as secure PSM
(for instance, MOLAP or HOLAP systems) and the corresponding MDA transformation.

The prototype CASE tool which supports our process needs to be completed and validated
with real projects.

Our process is only based on direct engineering methods. The proposal could be enriched
by developing methods in order to offer direct and reverse engineering methods.

In our approach, security is based on access control to guarantee confidentiality and audit
in the DWs design. However, other security aspects, such as integrity, reliability and
availability could be taken into account out of the Data Warehouse design.

Other kind of non-functional requirements such as cost-benefit and performance are not
included within our process.
In the following section we describe as future work some of the aforementioned limitations of our
secure engineering process (SEDAWA).
7. Conclusion and future work
In this paper we have proposed a secure engineering process for DWs, by eliciting and developing
both functional and security aspects as non-functional requirements at the business level. This
approach is outlined as follows. First a secure CIM is built by using the three activities supported by
an adaptation of thei

framework. Second, the secure CIM is transformed and developed by using

QVT transformations throughout the DW life cycle. Our methodology is MOF-compliant as a result
of the application of SPEM, i.e., according to the four layer architecture from OMG, it belongs to the
M1 layer. The greatest contribution of this work is that all the security and audit requirements
elicited during the early phases are modeled, developed and defined throughout the entire DW life
cycle. We believe that both the time and effort invested in the development of DWs are lessened,
the transition between different models and the final implementation is guaranteed, and that it is
possible to attain interoperability, portability, adaptability and reusability by employing MDA
technology.
Our immediate future work consists of several tasks: defining a formal MDA transformation by using
QVT between secure CIM and secure PIM, defining several secure PSMs, such as secure
Multidimensional Online Analytical Processing (MOLAP) and secure Hybrid Online Analytical
Processing (HOLAP), adapting the Model2Text approach in order to transform models into code for
specific DBMS such as Oracle, SQL Server or MySQL, which may be exploited by using Pentaho or
SQL Server Analysis Services, and complete the CASE tool developed in order to automatically
implement secure DWs. We shall also propose new methods with which to detect vulnerabilities
and contradictions between security rules defined by the ACA model at different levels of design.
Acknowledgements
This work has been partially supported by the META-SIGN Project (TIN2004-00779) from the
Spanish Ministry of Education and Science, by the QUASIMODO and MISTICO Projects from the
Regional Science and Technology Ministry of Castilla-La Mancha and by the ESFINGE Project
(TIN2006-15175-C05-05) of the Ministry of Science and Innovation (Spain).
Appendix A. UML Metamodel for the secure PIM
Fig. B.1 shows the UML metamodel whose instances serve as secure PIM in activities A1.2 and
A1.3 from the modeling phase (see Section 4.4). The metamodel allows us to represent the main
security information, constraints and security rules associated with SFact, SBase, SFactAttribute,
etc., classes in the conceptual modeling of secure DWs.



Secure facts and secure dimensions are represented by SFact and SDimension classes,
[Link] classes are specified as composed classes by means of aggregation
relationships of n SDimensionclasses. SDimension classes are composed of classification hierarchy
levels; every classification hierarchy level is specified by a class called SBase class. Roll-
UpTo association represents the relationship between two levels of a classification hierarchy. The
categorization of SDimensions is represented by means of specialization associations
between SBases classes. FactAttributes and SDegenerateDimension represent attributes for
the SFact class. SOIDs, SDescriptors,
and/or SDimensionAttributes represent SBaseattributes. SDegenerateDimension attributes are
defined in the SFact. A SDegenerateFact represents a UML association class attached to a many-
to-many aggregation relationship between a SFact class and aSDimension class, which can
contains SFactAttributes and SDegenerateDimensions. The metamodel includes six data types to
define the tagged values contained within the SecureClass and SecurityPropertyclasses in order to
establish security information in the systems classes (SFact, SBase, etc.). TheUserProfile class
may contains attributes in order to specify security information associated to an systems user.
Other tagged values (LogType, LogInfo, etc.) allow us to define security rules
(AuditRule,AuthorizationRule and SecurityRule) which are associated
with SecureClass and SecurityProperty to impose additional restriction in the system.
See [51], [6] and [7] for more details. Secure facts and secure dimensions are represented
by SFact and SDimension classes, respectively. SFact classes are specified as composed classes
by means of aggregation relationships of n SDimension classes. SDimension classes are
composed of classification hierarchy levels; every classification hierarchy level is specified by a
class called SBase class. Roll-UpTo association represents the relationship between two levels of a
classification hierarchy. The categorization of SDimensions is represented by means of
specialization associations
between SBases classes. FactAttributes and SDegenerateDimension represent attributes for
the SFactclass. SOIDs, SDescriptors,
and/or SDimensionAttributes represent SBase [Link] attributes are
defined in the SFact. A SDegenerateFact represents a UML association class attached to a many-
to-many aggregation relationship between a SFact class and aSDimension class, which can
contains SFactAttributes and SDegenerateDimensions. The metamodel includes six data types to
define the tagged values contained within the SecureClass and SecurityPropertyclasses in order to
establish security information in the systems classes (SFact, SBase, etc.). TheUserProfile class
may contains attributes in order to specify security information associated to an systems user.
Other tagged values (LogType, LogInfo, etc.) allow us to define security rules
(AuditRule,AuthorizationRule and SecurityRule) which are associated
with SecureClass and SecurityProperty to impose additional restriction in the system.
See [51], [6] and [7] for more details.
Appendix B. Relational CWM Metamodel for the secure PSM
Fig. B.2 shows the extended Relational Metamodel from CWM whose instances serve as secure
PSM (relational) in activity A3.1 from the Implementation phase (see Section 4.5). The metamodel
allows us to represent, at the logical level, all the security and audit rules captured during the
conceptual modeling stage of the DWs design.



The SSchema (SCatalog) classes specialize in the schema (catalog) classes to allow a
secure schema (catalog). STable and the UserProfile specializes in the Table metaclass.
The SColumn specializes in theColumn metaclass. The UserProfile table is a special table that
stores information about users who have access to the systems. Several data types are defined in
order to define the classes inherited from
theSecurityProperty (SecurityLevels, SecurityRoles and SecurityCompartments)
and SecurityConstraints(AuditConstraint, ARConstraint, AURConstraint) metaclasses. The
associations between SecurityPropertywith STable and SColumn allow us to establish information
security by means
of securityLevel,securityCompartment and securityRole. SecurityConstraint (which inherits
from Constraints metaclass) allows us to
define AuditConstraint, ARConstraint and AURConstraint. AuditConstraint is useful both as a
deterrent against misbehavior and as a means by which to analyze user behavior by employing the
system to find out possible attempted or actual violations. AuditConstraint is essential to record the
accesses to tables and columns which are performed by users. ARConstraint allows us to define
rules for specifying multilevel security policies in tables and columns. AURConstraint enable us to
specify access to the tables and columns, thus permitting us to specify much more elaborate
security models. The associations betweenSecurityConstraint with STable and SColumn allow us to
establish security rules by using AuditConstraint,ARConstraint and/or AURConstraint. See [48] for
more details.