Security in general and database protection from unauthorized access in particular, are crucial for organizations. It has long been accepted that security requirements should be considered from the early stages of the development. However, such requirements tend to be neglected or dealt-with only at the end of the development process. The Security Modeling Tool presented in this study aims at enforcing developers, in particular database designers, to deal with database authorization requirements from the early stages of development. This software demonstration shows how the Security Modeling Tool assists to define organizational security policies and use them during the application development to create a secured database schema.
Data is the most valuable asset for an organization as its survival depends on the
correct management, security, and confidentiality of the data [
To overcome these lacks, we provide a methodology that guides developers in the incorporation of particular organizational security policies, as well as verifying their correct application. In addition, the methodology enables the developer to transform the result into code.
The methodology incorporates ideas from two areas of expertise: in the area of
methodologies for system development, we adopt the principle of integrating data and
functional modeling at the early stages of the development, suggested by the
Functional Object-Oriented Methodology (FOOM) [
The developed methodology is supported by the Security Modeling Tool (SMT), which was tailored for its needs and was equipped with the required facilities. SMT enables the modeling of security patterns and enforces their correct use during application development. The knowledge captured in the security patterns is used to automatically verify that the application models are indeed secure, according to the defined patterns. Having a verified model, secure database schemata can be automatically generated.
The SMT is an Eclipse plug-in. The SMT uses, internally, libraries provided by
other Eclipse plug-ins to complete many tasks. For instance, Eclipse Modeling
Framework [
The rest of this paper is structured as follows: Section 2 provides an overview on the methodology, Section 3 presents and illustrates the use of the Security Modeling Tool, and Section 4 summarizes and proposes ideas for future work. 2
The methodology can be roughly divided into four phases: preparation, analysis, design, and implementation. Fig. 1 presents the methodology scope in terms of the tasks (presented in ellipse) to be performed in each phase and the generated artifacts (presented in rectangle). The preparation phase occurs at the organizational level, whereas the other three occur at the application development level.
l e v liitzaeaaLnon itrrnoaaepP g r O s li s y a n l A e v e L t n e m p o lv n e e ig ilitnoD seD a c p p A n o itt a n e m e l p m I
[!OK] [OK]
At the organizational level, also termed the preparation phase, we define security policies in the form of security patterns. These security patterns provide general access control policies within the organization. Once the patterns are specified, the transformation rules are defined, depicting how to transform a logical model, based on the pattern, into a database schema. The artifacts created in this phase are reusable and may be applied to various applications.
The application level deals with the development of any application within the
organization. In the analysis phase of the development of an application, two models
are defined, according to the FOOM methodology [
Organizational Level - The Preparation Phase During the preparation phase, security patterns along with their transformation rules are specified. These patterns will serve as guidelines for application developers as well as a verification template, and they provide the infrastructure for the transformation process. The transformation rules depict how an application model will be transformed into a secure database schema.
Security Pattern Specification. Similarly to the classical pattern approach, security
patterns are specified in a structured form. The standard template aids designers, who
are not security experts, to identify and understand security problems and solve them
efficiently. In order to specify the patterns, we use a common template introduced by
Schumacher [
Following that, the functional model of the application is defined using extended
use cases (EUC). An EUC is similar to a FOOM transaction [
The EUCs enable the analyst to define, among other things, the roles of the various users of the EUC and their access privileges. As in ordinary UC, for every EUC diagram we also prepare a description. The template for an EUC description is extended compared to an ordinary UC description, as it includes definitions of access authorization.
For each class included in an EUC we define: a) the roles, i.e. the authorized operators of the EUC; b) the type of access authorization (e.g., add, read, update or delete); and c) the attributes involved in that operation. Fig. 6 shows an example of an EUC with definition of access authorization. The right side shows a certain EUC diagram; the left side shows part of the EUC description; the bottom shows a part of the security specifications: in a form of a table we show, for each class that participates in the EUC, the security specifications.
Eventually, all the security specifications, defined for all the EUCs are aggregated in one table. The Design Phase. During this phase, the initial class diagram is refined, by the designer, to include the security specification, adhering with the organizational policies. Namely, the authorization rules are added to the initial class diagram as specified by the patterns, and the relevant elements are classified via stereotypes according to the predefined patterns, as presented in Fig. 7. During this task, additional changes to authorization rules may be applied and fine grained restrictions may be specified using the templates that were defined in the patterns. Fig. 8 illustrates the use on the instance (row) level template that was defined in Fig. 3. To use the template, the designer merely instantiates it and provides the missing parameters. In the SMT, these parameters are listed at the bottom of the view. The SMT also provides a preview of the templates after the missing parameters were specified, for instance in OCL and PL/SQL.
After creating a refined data model, we need to check if it adheres to the security policies as defined by the specified security patterns. The SMT provides automatic verification that is based on the ADOM validation algorithm. If the application is invalid, an error message is presented, explaining the verification errors. An example of two such errors are: 1) multiplicity error: access type is not specified to the Privilege class StudentR_CourseOffering, and 2) OCL error: StudentR role has the SYSDBA privilege.
The Implementation Phase. During this phase the transformation rules, which were defined during the preparation phase, are used to translate the verified application model into a database schema. 4
We have presented the Security Modeling Tool, which supports the development of secured database schemata upon the methodology we have developed. This tool utilizes security patterns for enforcing security on database application design. The tool guides developers on how to incorporate security aspects, in particular authorization, within the development process with pre-defined security patterns. It handles the specification and implementation of the authorization aspect from the early stages of the development process, leading to a more secure system design.
Currently, we are in a process of applying the methodology along with its supporting tool within an industrial environment. This will enable us to introduce improvements in the methodology and the tool. In future work, we plan to enrich the methodology and tool to support other non-functional requirements (e.g., in the security era it might include privacy, encryption, and auditing). In addition, we plan to apply the methodology to the code level, similarly to the way we apply it to database schemata; yet, we intend to incorporate behavioral specification as well.