Adaptive Security for Risk Management Using Spatial ... - Springer Link

Adaptive Security for Risk Management Using Spatial Data Mariagrazia Fugini1, George Hadjichristofi2, and Mahsa Teimourikia1 1

Department of Electronics, Information and Bioengineering, Politecnico di Milano, Milan, Italy {mariagrazia.fugini,mahsa.teimourikia}@polimi.it 2 Department of Computer Science and Engineering, Frederick University, Nicosia/Limassol, Cyprus [email protected]

Abstract. This paper presents the design principles for adaptive security for areas where changing conditions trigger events signaling risks that might require modifying authorizations of risk management teams. Spatial resources and information of the areas to be protected are considered in sample scenarios, and principles of security design are introduced building on ABAC (Attribute Based Access Control). Adaptivity of security rules applying to subjects who intervene in the risk area is the core of our security model so as to make it responsive to risks by dynamically granting privileges to subjects to access resources. Keywords: environment risk, adaptive security, context, ABAC, xacml, spatial data.

1

Introduction

Resource and people management for safety in risky environments is increasingly relevant [1]. In particular, during risky events, data and individual confidentiality and privacy should be preserved, while allowing dynamic adaptation of security rules (e.g., augmenting permissions of risk management teams) to face risks. Furthermore, spatial data are currently widely used to monitor and manage various aspects of people’s life, and various countries have been setting up their own Spatial Data Infrastructures and Geographical Information Systems [2]. On the other hand, adaptivity of security models are topics currently popular in various areas of research, such as data management and web applications [3]. In this paper, we address adaptation of security rules to environmental risks: subjects can receive enhanced access privileges temporarily on resources to handle the risk, and then return to the “normal” situation having these privileges revoked. The proposed security model takes into account events occurring in a monitored area, which may lead to a risky situation and may modify the security needs. For example, if a risk of fire arises, monitoring cameras should be enabled to provide detailed images at a higher level of precision than usual; namely, security rules should be adaptive to the area sensed. We model adaptivity by introducing Contexts that H. Decker et al. (Eds.): DEXA 2014, Part I, LNCS 8644, pp. 343–351, 2014. © Springer International Publishing Switzerland 2014

344

M. Fugini, G. Hadjichristofi, and M. Teimourikia

indicate which security rules apply in a given situation without violating the need-toknow principles. Context allow operations on objects by subjects to be expanded while remaining within a security domain. Contexts are activated for risk and deactivated upon the conclusion of risk. Security modeling is based on Attribute-Based Access Control (ABAC) where security attributes include spatial information and are considered at various levels of detail so that they can be inspected at various zoom levels according to the severity of the risk and according to the defined access privileges. Based on ABAC, we address the definition of an XML Schema for subject/object entities to be used with XACML policy language [4]. For risk modeling, we rely on our proposed solutions in [5]. In [6], we have considered aspects related to security of spatial information, referring to GIS. In this paper we complement that approach by focusing on adaptive security derived from knowledge about an area where geo referenced spatial objects are included.

2

Related Work

The issue of providing security to people and locations according to what happens in an area is an open issue [7]. Security of physical objects and data, which have a location in an area, is treated in works such as [8], where cloud computing services and subjects’ authorizations to geographic data are studied. The location datasets are transformed before being uploaded to the service provider. Authors in [9] propose to enhance security of spatial data in information sharing systems based on workflow services using XML key management, XML digital signatures, and geospatial extensible access control markup languages. Research on spatial data security focuses on security of data management, sharing and transmission, and on Subject access control. However, few papers tackle adaptive authorizations considering what happens in the environment. Secure data management in GIS repositories is a relevant issue [9,10]. Role-Based Access Control (RBAC) [11] has been extended for spatial data management in the GEO-RBAC model [12] where spatial entities model Objects, Subject’s positions, and geographically bounded roles. Roles are activated based on the position of the Subject only, and other aspects such as time, risks, emergencies, etc. do not affect the authorization decisions like in our proposal. Coming to security models, recently, there has been considerable interest in Attribute Based Access Control (ABAC) [13] due to the limitations of the dominant and mostly used models such as Mandatory Access Control (MAC), Discretionary Access Control (DAC), and Role-Based Access Control (RBAC) [10]. ABAC takes into account the attributes of entities (subjects and objects), environmental conditions, and operations to authorize a certain request. ABAC can successfully encompass the benefits of MAC, DAC, and RBAC while surpassing their issues [11]. This research adopts the ABAC model [13], where fine-grained authorization is possible with no need to explicitly define the relationship between each object and subject, as in RBAC. XACML policy language [4] is adopted since it avoids conflicts between policies and rules. Additionally, the proposed model allows us to activate/deactivate security rules through the use of Contexts, as security domains, which include

Adaptive Security for Risk Management Using Spatial Data

345

security rules of interest for given event(s) that can include a risky or emergency situation. Authors in [11] elaborate on risk-based adaptive access control (RAdAC) to semi-automatically adjust security risk to provide access to resources accounting for operational needs, risk factors, and situational factors. The risks treated here are security risks relating to the dynamic balance between the need to access information in view of mission priorities, risk, and cost of information compromise, and the overall operational and threat status of the system.

3

Security and Risks

We define the Subject as an entity taking actions in the system, namely requiring the execution of an operation upon an Object. We define the Object (also referred to as a resource) as a geo-referenced (spatial) entity to be protected from unauthorized use, such as data, devices, services, physical objects, areas, etc. Access control or authorization is the decision to permit or deny a Subject access to Objects 1 . Privileges represent the “authorized behavior of a subject”; they are defined by an authority. We have elementary actions (e.g., “read” privilege on environment objects, which will map into ''view'', ''read'', ''zoom in/out'' privileges, depending on the technology used for monitoring the environment, and the set of privileges defined therein) and complex activities (e.g., re-position a camera or rescue a person). For example, in an airport, there are parking areas, main buildings and so on, which can suffer from various types of risks. The airport itself is a spatial object with blueprints, security exits, surveillance sensors, and localization devices. The Security Manager is a Subject in charge of monitoring the airport and of planning/executing risk interventions. The Security Staff is a Subject to be cleared to access services that locate a risky event, or people/objects exposed to risk. The Security Manager has the highest clearance and can access Objects with virtually no limitations in a risk context; the Security Staff has lower clearance and can execute some security actions (e.g., launch an alarm) on a limited set of objects. These Subjects can receive an upgrade in their security level if a risk occurs: for instance, the Security Staff can gain the zoom-in privilege on additional areas upon risks and have this privilege revoked when the risk ceases. Contexts establish the security policies, namely for which Subject attributes which operations can be executed on which Objects attributes. Contexts in the airport can be: Risk; Flight (some flights can be blocked); Cargo Context (ground personnel can operate in reserved areas). By monitoring the environment, some events are triggered, which activate and/or deactivate Contexts allow dynamic changing the security rules and/or the subject/object attributes (e.g., to increase the security clearance attribute of a subject).

4

Security Model

When an environment at risk is considered, complex problems regarding planning and management of security need be handled since the authorizations of subjects can vary 1

The terms access control, authorization and security will be used synonymously throughout this paper. In particular, security is equaled to confidentiality and we place less emphasis on integrity aspects and other security properties.

346


dynamically e.g., to locate and analyze situations for decision making (context analysis) about risks. Moreover, security problems related to spatial data are becoming more and more imperative, especially in public security, or in applications for smart environments [9]. In what follows, we describe our security model for risks, including spatial objects attributes in the security model. 4.1

Security Model Components

We give the security model components and outline the access control mechanisms, for which we refer to the architecture of security controls in Figure 1 (details on the architecture are in [4]). Subject s: a user, application or process wanting to perform an action on a resource/object. A subject holds three groups of attributes: 1) General Attributes: define the general characteristics of a subject, such as its identity, name, job title, and etc. 2) Geo Attributes: define the location and spatial properties of a subject, such as location, reachable positions, etc. Geo attributes can be given at various levels of granularity, i.e., for privacy reasons, the exact location of the subject might be hidden while the subject’s logical position, usual location, and the places that the subject is allowed to have access to are visible; 3) Security Attributes: define the security-related properties of the subject, such as security clearances, highest-possible security clearance, privileges that the subject can grant/receive in different circumstances, roles which can be active at a given instant, and so on. Security attributes include conditions such as time restriction for the role to be active: under a time restriction, the role should not remain active after the time has elapsed the defined boundaries. As an example, a Security Manager in the airport can be described in XML as in Figure 2. Although the geo location of the subject is available, we can know only in which building the Security Manager is, rather than the detailed coordinates of his/her position in an area, since the granularity is defined to be at the building level. He/she can be usually found in office T21, and he/she is allowed also to be in building no. 2 while he/she cannot access (DeniedPosition) the cargo area. The secClearance attribute is defined in terms of levels Ln, in which n∈ , where the smaller the index the lower the security clearance of the subject. The Security Manager in this example has security clearance L4 and can have a maximum security clearance equal to L7 so that during the dynamic assignment of security clearances this subject has a threshold. His role of security manager is deactivated at a given time instant (and can be activated in case of a risky event), and the role of manager is active only during his office hours. Object o: in our definition, objects are any resource to be protected. However, in this paper we are particularly concerned with spatial objects, namely entities which are geo-referenced. Spatial Objects (SObs) are entities (maps, streets, buildings, areas) analyzed in special locations. Objects hold three groups of attributes (OA): 1) General Attributes can be object specific and differ depending on the type of the object; 2) Geo Attributes, support the identification of places where resources are located and record relevant quantities and densities. Geographic Attributes are for instance geo referenced coordinates (latitude, longitude), and levels of granularity (they exist at various zooming levels) available in the repository, and the objects in the vicinity; 3) Security Attributes define restrictions on information privacy, owner, level of sensitivity, and so on.

Adaaptive Security for Risk Management Using Spatial Data

347

Fig. 1. Access Control Mechanism with Contexts SM1ID >

L7

23.55 32.22 Building

Security Manager Deactive

21 BuildiingN2… Cargo<

Manager > Active OfficeHours

L4

Fig. 2. Subjects Security Attributes XML Schema

348


Figure 3 shows a simplified version of a passenger terminal as a SOb that is based on our XML schema of an object entity to be used with XACML. Passenger Terminal has a location and can be accessed at three layers of granularity. Terminal 2 and etc. are objects in its vicinity. Its owner is a Resource Manager referenced by the id. The sensitivityLevel (Sn, n∈ ) indicates the sensitivity of the resources: the higher the index of sensitivityLevel, the more sensitive the resource. The Passenger Terminal has sensitivity level S4. The minimum sensitivity level can be S3, avoiding the sensitivity to decrease below a given threshold during dynamic level assignments. TimeRestriction indicates that the resource can be accessed during a certain time slot (office hours in this example). Groups cluster resources facilitating the definition of security rules. E.g. objects can be in the following groups: static (they do not move in the space), moving, and geo-referenced. Each group has its own peculiar attributes. For example, a spatial (geo-referenced) object can have coordinates, level of details on the map, and objects in the vicinity. A moving object has time-varying coordinates, while a static object has fixed location coordinates.

Terminal1 Passenger al

Termin-

ResourceManagerID S4 S3

Office Hours

23.55

32.22

Terminal

3

StaticObject SpatialObject

Terminal2

Fig. 3. Objects Security Attributes XML Schema

Actions and Activities a: these are operations2 that can be executed by Subjects on Objects in a given Context. We consider: simple operations (read, write, execute, zoom-in/out); complex operations, called activities, which model a task, a process, an application, or a physical action. Examples of activities in an airport are “Redirect the airplane to another runway”, or “Turn the fire alarm protocol on”. In the schema below we define the zoom-in action; for actions also we specify our own XML schema to be used with XACML policy language.

2

“Operation” here denotes a security privilege.


349

zoom-in Zoom-in Zooming in, to view more detailed leveled of a spatial object

In order to receive a permission to execute an action/activity, a request is submitted to a Policy Enforcement Point (PEP), as in Figure 1. This request is specified by three elements: the requesting subject (access subject), the action/activity to be permitted, and the object to be accessed. A sample request is the Security Manager (subject) with id of SM1ID, wants to zoom-in (action) on the Terminal area (object) with id = Terminal1. Context c and Security Rule r: The Context delimits which security rules apply when risks occur. To adopt XACML, security rules in each Context are defined by the DefineRule(a, c, authDecision) function, where ‘a’, ‘c’ and ‘authDecision’ are the action/activity, context, and authorization decision, respectively. These rules exist in isolation in the Policy Administration Point (PAP) (Figure 1). As an example, a rule can specifythat the Risk Manager subjects, endowed with security clearance >= L3, can turn on (activity) the alarms (object o) whose sensitivity level is “L3”) (o.Group = “alarm”) (o.SensitivityLevel < “S4”).

Risk rk: Some factors that change dynamically can signal the occurrence of a risk situation, which can be recognized by monitoring the environment [5] based on parameters such as: type, level, and location of the risk factors. It is then possible to decide how to adapt the security rules to handle the risk rk. Risk detection is performed in the environment by monitoring factors which possible trigger events. Event ev: Changes in the environment captured by monitoring devices can trigger events (see Figure 1). Events activate/deactivate Contexts. Events may also cause the modification of the attributes of subjects and objects within the Context, according to what the Subjects/Objects relationships in the Context were before the event and those to be established after the event to manage the risk. Events play a key role in dynamic adaptation of security in response to changes in the environment. 4.2

Adaptive Security

Events are recognized by a generic “event checker” module (Figure 1) which requires risk management for an a-priori unpredictable situation. Re-assignment of security rules is carried out dynamically as soon as the event is identified. Permissions related to security are associated to an authorization policy, which determines which security rules apply during risk management. In particular, specific events due to some conditions may activate/deactivate Contexts as well as change the attributes of Subject/ Object, as in Figure 1. Activation/deactivation of Contexts adaptively determines

350


which security rules apply according to the detected event(s). There can be multiple rules per Context and different Contexts can share the same rules. Since we adopt XACML as the policy language, such conflicts can be avoided using the policy combining rules defined in XACML. As we mapped our contexts into the definition of entity in XACML, the set of activated contexts are relevant to the entity, and therefore, the policy combination algorithms can be applied to avoid conflicts between the activated contexts. For events, we adopt ECA (Event-ConditionAction) [14] rules which indicate that in case of an event, if the condition holds, then a certain action(s) should take place3. The event is triggered by the change in the environment conditions and is detected by the event checker of Figure 1. The Action is the activation/deactivation of a Context(s) or/and modifications in the attributes of subjects/objects by the function ChangeAttr(attribute, subject/object, value). To activate/deactivate contexts dynamically, we have context selection rules, as in Figure 1, that are pre-defined (and that apply at the occurrence of events (dynamically at run time). A function ContextSelection(ev,Context-activate,Context-deactivate) is the template for Context activation/deactivation. As an example, suppose we have the following ECA statement: Event : ‘fire’ Conditions : (rk.Type: ‘explosion’)^(rk.Level: ‘high’)^(e.TimeOfDay: ‘AfterOfficeHours’) ^ (e.locateSubjects(em.Position) != 0) Actions: Activate RiskContext, Deactivate FlightContext, ChangeAttr( s.SecurityClearance, s.Role: ‘RiskManager’, ‘L0’), ChangeAttr( e.TimeRestriction, e.TimeRestriction :’OfficeHour’, ‘none’)

The conditions indicate the case of ev fire, and risk rk of type explosion with high level of danger, if subjects (people) are in the environment e, and the office hour is elapsed, then, the risk context should be activated, and the flight context deactivated4 . And subject s with role Risk Manager should get a higher clearance L0 while the time restrictions should be removed from object o, which had such an attribute. Considering S, O, A, andC as the set of all subjects, objects, actions/activities (operations), and contexts, respectively, we define a policy model based on ABAC. Regarding the single subject s∈S , object o∈O, action/activity a∈ A, and context c∈C a security rule is defined at the security level as follows: SecurityRule: CheckAccess (s:S, a:A, o:O, c: C) Considering the operation, attributes related to the subject, object and the rules in the context, CheckAccess returns a tuple meaning that the operation a ∈A is allowed for subject s∈ S on object o∈O in context c∈C. If such a tuple is not found, the action is denied.

3

4

Note that here the “action” as in the ECA paradigm, is different from “action” defined in our model (denoting the operation). We assume that activation and deactivation procedures exist to check if the context is already activated or is not


5

351

Conclusions and Future Work

This paper presented adaptive security modeling motivated by the need for smart environments to dynamically authorize actors in facing risks. Based on the ABAC and on XACML policy language, security rules can change dynamically according to Contexts which delimit how subjects can enlarge their access privileges on (spatial) objects on the basis of predefined security policies. We intend to focus on the topics of binding environmental and spatial information, on the dynamics of assigning authoritative roles to administrators, and on ways to handle conflicting Context switching. Future work focuses on implementation of the XML schemas to be included in our developed web application described in [5]).

References 1. Chourabi, H., Nam, T., Walker, S., Gil-Garcia, J., Mellouli, S., Nahon, K., Scholl, H.: Understanding smart cities: An integrative framework. In: The 45th Hawaii International Conference on System Science (HICSS), pp. 2289–2297 (2012) 2. Murti, K., Tadimeti, V.: A simplified GeoDRM model for SDI services. In: The International Conference on Communication, Computing & Security (2011) 3. René, M., Schmidtke, H., Sigg, S.: Security and trust in context-aware applications. In: Personal and Ubiquitous Computing, pp. 1–2 (2014) 4. Rissanen, E.: eXtensible access control markup language (XACML) version 3.0., OASIS standard (2012) 5. Fugini, M., Raibulet, C., Ubezio, L.: Risk assessment in work environments: modeling and simulation. Concurrency and Computation: Practice and Experience 24(18), 2381–2403 (2012) 6. Dessì, N., Fugini, M., Garau, G., Pes, B.: Architectural and security aspects in innovative decisional supports. In: ITAIS 2013 Conf. (2013) 7. Li, G.: Research on security mechanism of sharing system based on geographic information service. In: The International Conference on Information Engineering and Applications (IEA), pp. 345–351 (2013) 8. Smith, K.: Environmental hazards: assessing risk and reducing disaster. Routledge (2013) 9. Tompson, J., Kennedy, S.: Where exactly is the target market? Using geographic information systems for locating potential customers of a small business. Entrepreneurial Practice Review 2(4) (2013) 10. Jin, X., Krishnan, R., Sandhu, R.: A unified attribute-based access control model covering DAC, MAC and RBAC. In: Cuppens-Boulahia, N., Cuppens, F., Garcia-Alfaro, J. (eds.) DBSec 2012. LNCS, vol. 7371, pp. 41–55. Springer, Heidelberg (2012) 11. Kandala, S., Sandhu, R., Bhamidipati, V.: An attribute based framework for risk-adaptive access control models. In: Sixth International Conference on Availability, Reliability and Security, ARES (2011) 12. Xiong, Z., Xu, J., Wang, G., Li, J., Cai, W.H.: UCON application model based on role and Security. In: ARES (2011)