Secure Access Control in a Multi-user Geodatabase
Abstract As GIS software is becoming widely used in a variety of applications, the need to provide confidentiality of data used by GIS arises. The faculty of the Earth Sciences and Resources Institute and the Department of Computer Science and Engineering at the University of South Carolina collaborated to study information confidentiality issues in GIS context and to define an access control model for a multi-user geodatabase within an enterprise-level GIS environment. This paper discusses our findings and difficulties during the implementation of the model to enforce access control in spatial databases created with ArcGIS 8.1, ArcSDE 8.1 and MS SQL Server 2000.
1. Introduction Geographic Information Systems (GIS) are becoming more and more widely used in a variety of application domains, creating the need for multi-user support, sophisticated data management, global connectivity, and information security. Until recently, most of the research work on GIS focused on providing powerful tools for manipulating (i.e., capturing, storing, retrieving, transforming, analyzing, and displaying) spatial data [1,2,3,4]. The most widely used GIS software are the products of Environmental Systems Research Institute (Esri) [ArcView, ArcInfo, ArcGIS], Intergraph [GeoMedia and Modular GIS Environment (MGE)] Autometric [SoftPlotter, KDMS, and SQS], MapInfo [Professional and MapBasic], and GRASS GIS [5,6,7,8]. However, most GIS provide little or no support for multilevel information confidentiality. Clearly, this is unacceptable in a large, multi-user environment where some of the data manipulated by the GIS software are confidential. Since 1999 the Earth Sciences and Resources Institute at the University of South Carolina (Esri-USC) has generated large amounts of spatial data, some of which are confidential and/or proprietary. These data need sufficient access control measures to adequately serve users of the application domain. The institute currently has undertaken an internal project to establish an enterprise level GIS environment within the institute and to create a seamless spatial data repository for the entire state of South Carolina. But until now no security measures have been adopted. With the emergence of more-and-more GIS applications, it is critical to provide mechanisms to ensure data security. GIS applications interleave with every aspect of our lives, requiring information protection. For example, consider an environmental project creating maps about flora and fauna distribution. Rare and endangered plants and animals may be more vulnerable to illegal collection if their locations are generally known. So it has long been the practice for environmental organizations and governmental agencies to keep locations of vulnerable plants and animals secret even if the locations of more common and less vulnerable organisms are made public. As distribution maps are increasingly being made available online, good quality information protection needs to be established. In addition, we need to address the issue of whether or not this is an effective means of protection even if there are no implementation problems [9]. Issues of information granularity and availability arise in these applications. The issue of granularity is also seen in the use of Selective Availability (SA) to intentionally degrade the Global Positioning System (GPS) signals received by civilians. Although GPS signals were available to civilians, they were less accurate than those the military could receive and corresponded to an area an order of magnitude greater than that identified by the original signal. SA was instituted as a security measure, but it was discontinued by the United States in 2000 in order to provide more precise locations for civilian activities such as transportation and emergency response. Information about SA can be found on the NOAA web site: http://www.ngs.noaa.gov/FGCS/info/sans_SA A different perspective on GIS security can be seen in the controversies over the increased availability of GIS data provided by local governments. For example, Frederick Country (VA) was forced to remove real estate records from its web site following an outcry of public opposition to its availability [10,11]. It should be noted that this information had already been publicly available but had been much more difficult to access before it was online; it had to be viewed in person in a county office. The impact on online access to records of this kind is leading to a revisiting of the issue of privacy and the kinds of information, both spatial and non-spatial, that should be available online. In addition, the question of how to actually protect information as required by law is of increasing importance. For example, the Urban Regional Information Systems Association (URISA) and the Federal Geographic Data Committee (FGDC) had sponsored a series of workshops last year (2001) addressing privacy concerns in governmental GIS data [12]. There are several interrelated aspects to security of GIS data, including privacy, confidentiality, secrecy, integrity, accuracy, granularity, and availability. The “traditional” GIS database has been a static database used within a single organization for data retrieval and analysis. This environment presents security problems that are relatively easy to handle. Either a user has access to the data or does not have access. While this large granularity access control is suitable for file systems, it unnecessarily limits data availability in database systems. In addition, as technology develops spatial databases can be used for purposes that increase the need for data sharing. Allowing controlled accesses to an organization’s geodatabase becomes a critical function as GIS matures [5]. Controlled accesses should incorporate both traditional DBMS and GIS services to guarantee data integrity and availability, as well as security mechanisms to protect data confidentiality. To our best knowledge no research has been published on how to enhance the GIS environment with today’s security technology. One of the reasons is that until recently GIS were mainly used in centralized locations with all of the users having the same privileges. However, the development of multi-user, globally connected GIS applications and applications in critical systems requires differentiation among the users in order to protect sensitive information. Based on the above limitations in current GIS, our objectives in this paper are:
Our concern here is not with the issues of what information should be kept confidential for privacy or other reasons. We address the question of how to enforce the policies and decisions made in whatever computing environment is used. The organization of the paper is as follows. In the following section we give a brief review of MLS/DBMS research, focusing on access control models, the system components and the security considerations. Section 3 describes the access control requirements for spatial databases. We define the access control models and discuss their feasibilities in regards to a geodatabase in Section 4. Finally we conclude and recommend future research directions in Section 5.
2. BackgroundThe three main objectives of information security are integrity, confidentiality, and availability [23]. Multilevel secure databases, i.e., databases that contain data classified at different security levels, have been studied extensively during the last 20 years [17,18,19,20,21,22]. The first defense line of security is proper access control. The three main access control models are mandatory, discretionary and role-based access control. Mandatory (or label-based) Access Control (MAC) requires that data items are classified at different security levels and that users of the database have security clearances assigned to them. When a data access is requested, the security clearance of the requesting user is compared to the security classification of the requested data item. If the access control rules are satisfied the data access is permitted, otherwise it is rejected. Discretionary (or user-based) Access Control (DAC) defines access permissions for each user of the database. It is assumed that the owners of data should be able to protect their data and grant access rights to other users. This type of access control is typically supported by operating systems at the file level (for example, the Unix file system). Recently a new type of access control, Role-Based Access Control (RBAC) [24], is attracting increased attention in both military and commercial systems. RBAC is based on modeling organizational-specific access control policies. The main components of RBAC are users, roles, permissions, user-role assignments, and role-permission assignments. Access control is enforced in terms of roles. Intuitively, when initiating a session, a user may activate any roles that he or she has been assigned to and use the union of corresponding permissions. Roles have been used in computer systems for years and several research papers focused on incorporating roles in access control models [25,26,27,28]. Furthermore, it has been shown that RBAC can be implemented using the controls available in MAC, providing high security assurance and simplifying implementation [29]. Based on the limitations of current GIS to provide sophisticated access control to data sources used by GIS, we propose the architecture in Figure 1. 
Figure 1: Proposed architecture for access control in geodatabases The model is based on exploiting the ability of ArcSDE to support interoperability between ArcGIS software and relational database systems and the use of security tools available for these databases. 2.1 System Components2.1.1 ArcGIS
2.1.2 ArcSDE
2.1.3 Geodatabase
2.1.4 ArcGIS – ArcSDE Interface
2.1.5 ArcSDE – Geodatabase Interface
2.2 Security ConsiderationsThe use of ArcSDE as mediator between a GIS application and a relational database system not only allows improved interoperation of spatial and non-spatial databases, but it also supports enhanced security administrations. In this work we focus on the security features provided by Microsoft (MS) SQL Server. In addition to the security features, such as authentication, domains, and user accounts, provided by the MS operating system [13], SQL Server provides additional security features, such as client-server encryption, SQL trace and auditing, and role-based access control [14]. The proposed security architecture is shown in Figure 2. The stars show where authentication of the user is required. First, users are authenticated by the operating system under which the GIS software runs. Then, all data accesses to the SQL Server databases must be authenticated. The reason for two layers of authentication lies in the need to have different levels of security granularity in these systems. Note that a future extension of the model could be to eliminate the need of multiple authentications, for example by using digital certificates. However, this problem is outside the scope of our current paper. 
Figure 2: Proposed security architecture 3. Access Control RequirementsIn this section, we describe our security system components and the special requirements of GIS applications. Data used by GIS include both spatial information (e.g., area boundary) and non-spatial information (e.g., land ownership). Data may be grouped according to natural regions (e.g., watershed), political regions (e.g., county), geographical features (e.g., roads, rivers), relationships among data items (e.g., ownership), etc. In addition, some of the data may be confidential, thus their release (disclosure) or usage have to be controlled. For other data items, correctness (integrity) may be the most critical requirement. It is desirable to distinguish among the database users and assign privileges based on the minimum requirements. For example, members of a project identifying flood plains might not be allowed to access ownership information of these plains. On the other hand, an insurance agent may need the ownership information to reimburse customers. Similarly, regional information for a county may be seen by anyone, but only designated county officers are allowed to modify the information. Access control is the first step towards satisfying these and similar requirements. First, we need to define the security objects and subjects and the proposed access control model. 3.1 Security objectsIn contrast to the currently available file-level granularity access control, i.e., files are either allowed or disallowed to be accessed, we propose a model, where access permissions are assigned to subtuples of the database. This flexible model will allow tuple-level security granularity as well as content-based access control. Subtuples for a given security rule form views of the base relation, thus allowing view-based access control. 3.2 Users (subjects)Users of the database system are the non-GIS users, having direct access needs to some of the SQL Server database items, e.g., a county officer updating ownership information; and GIS users, accessing the database through the GIS application, e.g., performing environmental research. These users have different access requirements according to the role they are using in a given scenario [15, 16]. We take advantage of SQL Server’s support of role-based access control and propose security administration based on the users’ roles in the system. Beside user roles, SQL Server allows application roles where accesses to the database depends on the application the user is using. Our main concern is providing seamless operation between the ArcSDE mediator and the SQL Server.
4. Access Control Models for GeodatabasesBased on practical considerations, such as ease of implementation, database support, and processing needs, we aimed to develop a model that allows view-based access control. Users of the database system should be able to access predefined sets of views, based on their authorizations. Views are built from a multi-level database and may be updated, according to the users’ privileges. Any update is then propagated back to the multi-level relation. Note, that although there are several related issues, such as inference and covert channel problem and concurrency control, in this work we focus mainly on the design principles of the multi-level secure system and its applicability for GIS. First, we considered different architectures for storing data and different methods to define security objects (views). In particular we studied three different security architectures:
4.1 Single Multi-Level Database (Multi-Level Relations)The straightforward model for multi-level database architecture would be a single database, storing and manipulating data classified at different levels (Figure 3). ArcSDE administration commands have been used to define different views of the base relations with different privileges, and users would be able to access these predefined views only according to their access permissions (privileges). Updates would be propagated back to the main database. This approach served perfectly well for secure data viewing; unfortunately, we experienced a major shortcoming of this model. Views, created by ArcSDE are not updateable by the GIS software (ArcMap). Hence, low-level users cannot add or delete any feature while viewing the data layer (feature class) in ArcMap. 
Figure 3: Architecture of single multi-level database (multi-level relations) 4.2 Replicated Multi-Level DatabaseThis model is based on separating the data into several databases, according to the classification of the data (Figure 4). Any lower level data is replicated at the higher level, thus allowing the users to see a complete database at their clearance level. The problem with this model is that it requires large storage overhead, and the propagation of updates from low-level databases to the higher levels is expensive. Nevertheless, this is one of the most secure models to be implemented. 
Figure 4: Architecture of replicated multi-level database We considered an update propagation method where all updates are logged. Low-level updates are then applied at periodic intervals on the higher security data. Clearly, in addition to the maintenance of the replicated data, we need to address issues like conflict resolution, where two updates occur on the same data item at different levels. Although we did not completely abandon this model, we consider it too expensive to implement. 4.3 Single Multi-Level Database (Uni-Level Relations)We had the greatest success by using the architecture that separates data into single level relations (Figure 5). In this model, when a user accesses the database, the database is constructed from single-level relations, such that the user can access data at the appropriate level. After the user’s session terminates, the composite database is decomposed into several single-level relations, according to the security classifications of the data. 
Figure 5: Architecture of single multi-level database (uni-level relations) Although at this stage of the work we have not implemented the modules that combine and decompose the data, we have a system working that allows separating data into single-level relations. GIS users can project these relations on top of each other. This gives the feeling that the user accesses a single relation including data classified at different levels, while in reality this is only a projection of independent data. Since there is only one copy of each data item, concurrency control and update propagation is simplified. However, we are aware of the need to provide tools to seamlessly manipulate data to provide a combined view to the users.
5. Conclusions and Future ResearchIn this paper we studied the feasibility of providing small granularity access control to sensitive GIS data. Since SDE allows the import of database files maintained by commercial database management systems, our work focused on the applicability of access control models supported by database technology. Also, since view-based access control has proved to be efficient and applicable in practice, we aimed to implement a view-based access control model for GIS applications. Our testbed was built using existing software packages: ArcGIS 8.1, ArcSDE, and MS SQL Server. Unfortunately, our attempts yielded limited results. In particular, views created by MS SQL Server cannot be interpreted by the GIS software. On the other hand, views created by the GIS software (ArcSDE) do not satisfy the security requirements we plan to achieve since low-level views were not editable (although viewable ) for lower level users. We also attempted to build models based on multi-level secure database architectures. We studied the applicability of replicated, multi-level, and single-level relations based models. We found that the model based on single-level relations was the easiest to create and maintain. We implemented an initial system based on this model, where users are allowed to access (view and edit) data only at their level or levels dominated by them. Currently the model supports a composite view of the single level relations (relations are projected on top of each other), but no tools have been implemented to provide a logical, single relation composite-view and to decompose this composite-view to single-level relations after updates. In summary, we found that it is possible to provide a smaller granularity access control than file-level to GIS data. However, this is not straightforward, and the GIS software gives minimal support. We see two possible directions for improvement:
References[1] Clarke, K.C. Analytical and Computer Cartography, 2nd edition, Upper Saddle River, NJ, Prentice Hall. 1995 [2] Burrough, P.A. Principles of Geographic Information Systems for Land Resources Assessment, Oxford, Clarendon Press. 1986 [3] Star, J. and Estes, J. E. Geographic Information system: An Introduction, Upper Saddle River, NJ, Prentice Hall. 1990 [4] Clarke, K.C. Getting Started with Geographic Information Systems, Upper Saddle River, NJ, Prentice Hall. P.353. 1997 [5] Esri Press, Understanding ArcSDE, Redlands, California, p.74, 1999 [6] Flynn, J. and Pitts, T. Inside ArcInfo, 2nd edition, OnWord Press, Albany, NY, USA, p. 476. 2000 [7] Esri Press, Building a Geodatabase, Redlands, California, p.327. 1999 [8] Zeiler, M. and Esri Press. Modeling Our World, Redlands, California, p.199. 1999 [9] Glassberg, J. Listen, Do You Want to Know a Secret (Do You Promise Not to Tell), American Butterflies, Vol. 9, No. 3. Fall 2001, p. 2 [10] Friend, D. Online Property Listings Surprise Officials, The Winchester Star, Winchester, Virginia. May 17, 2001 [11] Rehbock, L. Online Property Listings Removed, The Winchester Star, Winchester, Virginia, May 18, 2001 [12] Langlois, G. GIS Workshop Tackles Privacy. Civic.com. May 25, 2001 [13] Microsoft SQL Server – SQL Server Home, Windows 2000 Security Services, http://www.microsoft.com/windows2000/technologies/security/default.asp [14] Microsoft SQL Server – Microsoft SQL Server 2000 Security, http://www.microsoft.com/SQL/techinfo/administration/2000/securityWP.asp [15] R. Sandhu, E.J. Coyne, H.L. Feinstein, and C. E. Youman. Role-Based Access Control Models, IEEE Computer, 29(2), February 1996 [16] D. Kuhn. Role-Based Access Control on MLS Systems without Kernel Changes In Proc. Second ACM Workshop on Role-Based Access Control, 1997 [17] Multilevel Data Management Security, Air Force Studies Board, Commission on Engineering and Technical Systems, National Research Council, National Academy Press, Washington D.C. (1983) [18] Sybase Secure SQL Server Security Administrator’s Guide, Sybase, Inc.,Emeryville, C.A. (1993) [19] Trusted Oracle Administrator’s Guide, Oracle Corp., Redwood City, C.A.(1992) [20] Informix-Online/Secure Administrator’s Guide, Informix Software, Inc., Menlo Park, C.A. (1993) [21] Informix-Online/Secure Security Features User’s Guide, Informix Software, Inc., Menlo Park, C.A. (1993) [22] E. Bell and L. J. LaPadula. Secure Computer Systems: Unified Exposition and Multics Interpretations. Technical Report MTR-2997, The Mitre Corporation, Burlington Road, Bedford, M.A. 01730, USA [23] Castano, S., Fugini, M. G., Martella, G., and Samarati, P. Database Security, Addison-Wesley Publishing Company, New York, NY, p.456. 1995 [24] R. Sandhu, E.J. Coyne, H.L. Feinstein, and C. E. Youman. Role-Based Access Control Models, IEEE Computer, 29(2), February 1996 [25] R.W. Baldwin. Naming and Grouping Privileges to Simplify Security Management in Large Databases. In Proc. IEEE Computer Society Symposium on Research in Security and Privacy. IEEE Computer Society, 1990 [26] D.J. Thomsen. Role-Based Application Design and Enforcement. In Database Security IV: Status and Prospect. North-Holland, 1991 [27] D. Ferraiolo and D.R. Kuhn. Role-Based Access Control. In 15th National Computer Security Conference. NIST/NSA, 1992 [28] D. Ferraiolo, J. Cugini, and D.R. Kuhn. Role-Based Access Control: Features and Motivations. In Annual Computer Security Applications Conference. IEEE Computer Society Press, 1995 [29] D. Kuhn. Role-Based Access Control on MLS Systems without Kernel Changes. In Proc. Second ACM Workshop on Role-Based Access Control, 1997
Trademark Information Microsoft, SQL Server are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries. ArcInfo, ArcMap, ArcCatalog, ArcToolbox, ArcSDE are either registered trademarks or trademarks of Environmental Systems Research Institute, Inc.in the U.S.A. and/or other countries.
Author Information
Dr. Caroline M. Eastman, Professor
Dr. Csilla Farkas, Assistant Professor
|