Towards Activity-Centric Access Control for Smart Collaborative Ecosystems
TTowards Activity-Centric Access Controlfor Smart Collaborative Ecosystems
Maanak Gupta
Department of Computer Science,Tennessee Technological UniversityCookeville, TN, [email protected]
Ravi Sandhu
Institute for Cyber Security and NSF C-SPECC Center,Department of Computer ScienceUniversity of Texas at San Antonio, TX, [email protected]
ABSTRACT
The ubiquitous presence of smart devices along with advancementsin connectivity coupled with the elastic capabilities of cloud andedge systems have nurtured and revolutionized smart ecosystems.Intelligent, integrated cyber-physical systems offer increased pro-ductivity, safety, efficiency, speed and support for data driven ap-plications beyond imagination just a decade ago. Since severalconnected devices work together as a coordinated unit to ensureefficiency and automation, the individual operations they performare often reliant on each other. Therefore, it is important to controlwhat functions or activities different devices can perform at a par-ticular moment of time, and how they are related to each other. Itis also important to consider additional factors such as conditions,obligation or mutability of activities, which are critical in decidingwhether or not a device can perform a requested activity. In thispaper, we take an initial step to propose and discuss the concept ofActivity-Centric Access Control (ACAC) for smart and connectedecosystem. We discuss the notion of activity with respect to the col-laborative and distributed yet integrated systems and identify thedifferent entities involved along with the important factors to makean activity control decision. We outline a preliminary approachfor defining activity control expressions which can be applied todifferent smart objects in the system. The main goal of this paper isto present the vision and need for the activity-centric approach foraccess control in connected smart systems, and foster discussionon the identified future research agenda.
CCS CONCEPTS • Security and privacy → Security requirements ; Access con-trol ; Authorization . KEYWORDS
Smart Connected Ecosystems, Security and Privacy, Activity-CentricAccess Control, IoT, Collaborative Systems
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from [email protected].
Conference’17, July 2017, Washington, DC, USA © 2021 Association for Computing Machinery.ACM ISBN 978-1-4503-XXXX-X/18/06...$15.00https://doi.org/10.1145/nnnnnnn.nnnnnnn
ACM Reference Format:
Maanak Gupta and Ravi Sandhu. 2021. Towards Activity-Centric AccessControl for Smart Collaborative Ecosystems. In
Proceedings of ACM Confer-ence (Conference’17).
ACM, New York, NY, USA, 10 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn
Cyber Physical Systems (CPS) and connected technologies are trans-forming how humans interact with engineered systems. These sen-sors and Internet of Things (IoT) based systems are built and dependupon the seamless integration of physical and computational com-ponents along with the emerging technologies of Artificial Intelli-gence (AI) and Machine Learning (ML) to support fully automateddata driven ecosystems. Innovative smart CPS applications in thedomain of energy, healthcare, transportation, building, agriculture,aeronautics and medicine, have offered convenience, comfort andefficiency for application developers and end users. As such ac-cording to the United States National Science Foundation, a “smartand connected community” is, in turn, defined as a community thatsynergistically integrates intelligent technologies with the naturaland built environments, including infrastructure, to improve the so-cial, economic, and environmental well-being of those who live, work,learn, or travel within it.
Everyday life is becoming increasinglydependent on these systems, often with dramatic improvements.Ensuring the trustworthiness, security and privacy of informa-tion is a formidable challenge in regard to both technical and policyaspects. Deployment of secure mechanisms for critical infrastruc-tures and CPS is important to assure resilience and protection fromadversaries including state supported entities and foreign basedactors. While cybersecurity is a strong national priority and muchprogress has been made to ensure protection from cyber-attacks,CPS security raises a host of new challenges. The convergence ofphysical and cyber world has introduced new attack modes whichare automated, hard to analyze and engender substantial risk inmaintaining the integrity of physical as well and cyber resources.Important challenges to secure CPS and IoT include threat mod-eling, proposing mathematically grounded fundamental securityapproaches along with continuous vulnerability assessment, anddesigning adaptable autonomous defense mechanisms to thwartrapidly evolving cyber and physical threats in this growing, con-nected, collaborative and distributed ecosystem.Access control mechanisms have been extensively used to limitunauthorized access to resources and secure communication amongobjects. Several cloud and edge assisted IoT and CPS architectureshave been proposed supporting traditional access control modelssuch as Discretionary (DAC) [1], Mandatory (MAC) and Role Based a r X i v : . [ c s . CR ] F e b onference’17, July 2017, Washington, DC, USA Gupta and Sandhu. Access Control (RBAC) [2], as well as more fine grained such asAttribute-based access control (ABAC) [3, 4] offering flexibilityin distributed and dynamic environments. However, traditionalaccess control models are not well suited to address access controlrequirements in distributed systems where resources are managedby different entities, and are connected via single or multi cloudplatforms. Such environments and applications will proliferate aswe move to more data driven and automated world. We believe it isnecessary to adopt a different viewpoint to develop access controlapproaches for such task and activity driven connected systemswhich work collaboratively to fully automate the entire ecosystem.
In a connected ecosystem, different operations and workflows in acoordinated unit are usually interdependent and collaborative. Anactivity is a unit of work which is performed by a device, reflectingits current state. For example, consider an aerial drone perform-ing digital imaging or soil health scanning of a large farm. Here digital imaging and soil health scanning are the activities whichare initiated by a subject (which can be a user or another smartdevice) via an operation. Activity is considered the fundamentaloperation in our proposed approach. Some activities can be relatedto each other and consequently should be done in a particular ordersuch as before, concurrent or after other activities. Some activitiesmay only be initiated by certain users or devices, or can only bedone during a particular time slot, or there may be a threshold onan activity’s occurrence (i.e. how many times or at what rate theactivity is allowed). Therefore, such relation and contextual factorsamong different entities involved in requesting an activity mustbe considered to decide if the activity is allowed or denied in thesystem at a particular moment of time. The current proposed ac-cess control models including discretionary, role based or attributebased solutions proposed for IoT and CPS connected ecosystemdo not capture the notion of activity, i.e the current state of thedevices in the system, to control a new requested operation whichwill result in activities performed by different co-related devices.The main contributions of this paper are as follows. • We highlight key distinctions of the proposed activity-centricaccess control approach for collaborative systems comparingit with related but fundamentally distinct access controlsystems designed for enterprise and social computing. • We propose the notion of an activity with respect to the con-nected ecosystem and define what are the different abstrac-tions involved along with the contextual factors importantto make an activity control decision. • We provide an activity-centric access control framework byidentifying different relationships among various activitiesin a connected collaborative ecosystem. • We also offer our preliminary thoughts and an approach indefining an activity control expression which can be appliedto different smart objects in the system. • We highlight future research needs and outline an agendato fully develop, mature and use the ACAC security modelsin smart collaborative ecosystems. The rest of the paper is organized as follows. Section 2 discussesbackground with respect to the prior related models proposed indifferent domains, and explains how our proposed approach is fun-damentally different from these prior approaches. Section 3 definesactivity primitives and relationship characterization among differ-ent activities in a connected and collaborative ecosystem, alongwith factors impacting an activity-centric access control decision.Section 4 provides an approach to specify the proposed activitycontrol expression, followed by a future research agenda in Section5. Section 6 summarizes and concludes our work.
In this section, we discuss some prior related models and explainhow our approach is different from these.
Task-Based Authorization Control (TBAC).
The TBAC model [5]enables “active security” concept, which offers the abstractionsand mechanisms for the active runtime management of security, astasks progress to completion especially relevant in workflows andtransactions environments. Here the permissions are constantlymonitored and activated-deactivated in accordance with emergingcontext associated with progressing tasks, providing tighter just-in-time need to do permissions. TBAC supports the fundamentalabstraction of an authorization step which is a single act of grantingpermissions (similar to a signature in the paper forms by an individ-ual), referred to as enabled-permissions . Further, these permissionsare good only for a limited period of time, and an associated periodof validity and lifecycle is associated with every authorization step.When a usage count reaches its limit, the associated permissionis deactivated and the corresponding action is no longer allowed.Each authorization step corresponds to some activity or task withinthe broader workflow context.
Usage Control (UCON).
The UCON model [6–9] covers obliga-tions, conditions, continuity (ongoing controls) and mutability ofattributes, to determine an access control decision. Obligations re-quire some action by the subject so as to achieve or sustain access,such as clicking accept on the terms of conditions of a license agree-ment. Conditions cover the environmental factors that predicateaccess such as the time of the day or risk level. In addition, conti-nuity reflects continuous enforcement of access control is done byevaluating usage requirements throughout usages. The model alsosupports change in the attributes of the users and objects as side-effects of subject’s actions. In case of attributes mutability, updatesare supported before (pre), during (ongoing) or after (post) usages.Access control decision-making is done either before (pre) or dur-ing (ongoing) exercise of the requested right. The UCON modelsupports applications such as trust management, digital rights man-agement and privacy protection within a unified framework.
Activity-Centric Access Control (ACON).
The ACON model [10, 11]is motivated by social computing systems (SCSs) like Facebook,in which a user performs activities not only on shared content Both ACON and our new model ACAC are acronyms for Activity-Centric AccessControl. Given their motivations and intended application domains we believe thisreuse of the underlying term will not cause confusion. Where necessary the acronymscan be used to disambiguate. owards Activity-Centric Access Controlfor Smart Collaborative Ecosystems Conference’17, July 2017, Washington, DC, USA but also against target users (a user pokes another or recommendsfriends). Furthermore, in SCS, there are activities performed bythe system to provide services and resources that can promoteuser interactions or sustain the SCS provider’s business. TheseSCS’s activities also need to be evaluated for control decision sinceusers may not want their shared information to be used for SCS’sanalysis or may not want to receive some of these SCS services.From access control point of view, both users’ control activities andsystems’ automated activities are rather unique to SCSs and seldomconsidered in traditional access control models. This work proposesactivity as a key concept for access control in SCSs. ACON supportspersonalized user privacy control by utilizing individualized userpolicies/attributes and resource policies/attributes.
Our proposed approach for activity-centric access control offersdistinct but converging synergy with the above mentioned models,offering run-time access control considering the context, usageand various activities occurring (or have occurred) in the broadercollaborative and connected smart ecosystem context. The coreconcept of
Activity is central to our proposed framework and isnatural for smart devices. An activity on a device is initiated due toan operation from a subject (a device or a user), performing a short-lived or prolonged function (aka task). In a collaborative ecosystemsuch tasks (or activities) will typically be related with each other.For instance, in smart farming or smart manufacturing domainsone activity may lead to another related activity, or the occurrenceof an activity may restrict the initiation of another activity. As anexample, water sprinkler cannot be turned ON while weed sprayingis taking place. To our understanding no prior research has provideda perspective to support access control in IoT and CPS collaborativeenvironment with activity as the central notion.With respect to TBAC, our approach considers the relationamong different activities occurring in the system to determinean access decision to perform a new activity requested by the sub-ject. This condition is checked in addition to the permission for thesubject to perform an activity. This is distinct from TBAC model,which does not consider relationship among other concurrent activ-ities, but rather is focused on workflow dependencies amongst tasks.Further, TBAC only considers one object to have run-time controlof permissions, while in ACAC multiple dependent activities canoccur on different objects. UCON offers obligations from the users(subjects) and environmental conditions, which is different thanthe pre or post obligations of activities as required in our proposedapproach. In addition, this obligation can be from the same subject,or different users/devices in the system. For example, to start anactivity A from Tom on object Ob1, Bob has to start activity C onobject Ob2. Similarly, conditions can be beyond just the environ-mental or system factors, and may also include other activities orthe relationship among user/devices which have initiated differentactivities in the system. Limit controls on activities are supported,such as where a user can perform certain activity only twice a dayor an activity can be allowed only twice irrespective of the initiatingsubject. The ACON model was designed taking into considerationsocial computing systems. However, it does not consider the current activities in the system to limit new activities. Also, the activities inthe SCS are not persistent for a length of time, and are more similarto short-lived actions. In our proposed framework, an operationwill result in an activity which will sustain for a longer duration oftime, for example, water spraying will done for 1 hour. The activity-centric framework for smart connected ecosystem is fundamentallydifferent from the related and established using similar notations. The goal of smart and connected ecosystems is to bring new levelsof economic opportunity and growth, safety and security, healthand wellness, accessibility and inclusivity, and overall quality oflife, by offering data driven applications to end users. Further, thesetechnologies are combined with elements of the physical world(e.g., machines, devices, structures) to create smart and intelligentsystems that offer increased effectiveness, productivity, and speed.These connected yet distributed systems are supporting services indomains including manufacturing, energy, transportation [12, 13],medical, city, building, and agriculture [14, 15], offering data drivenand intelligent AI driven efficient environments. With emergence offully automated manufacturing and CPS domains, trustworthinessand security when considering a action related to AI and operationsin the system is critical. Different cloud service providers, includingAmazon Web Services, Google Cloud IoT, and Microsoft Azure ,have dedicated IoT and CPS platform catering to diverse applica-tions and use-cases supporting both cloud and real-time edge-baseduser applications and services.Access control mechanisms are essential to secure data and re-sources in a connected shared ecosystem. These models and mech-anisms offer solutions to restrict which smart device can be con-trolled by other resources, which can share data and with whom,what applications can gather the data from on-field devices, cloudcommunication and data exchange etc. Controlling which users ap-plications or devices can operate or access other connected devices,get data from other devices, securing data [16, 17] in the cloudor local edge gateway and also in the transit are important con-cerns that need to be addressed. This problem magnifies when dataand resources are distributed [18] and spread across different enti-ties administered by different units. Several approaches have beenused in enforcing access control policies, including cryptographicmechanisms [19], capabilities, access control lists, and policy basedsolutions. Access control reference monitor will allow operationsonly if it has a policy that grants permission for requested opera-tions. Attribute-based access control (ABAC) [3, 4, 20] supports finegrained authorization capabilities for resources offering flexibil-ity in a distributed multi-entity environment where the attributesof entities along with contextual information are used for accessand communication authorization decisions. Several cloud serviceplatforms including AWS and Google Cloud provide policy based[21, 22] security solutions to control among different smart entitiesand applications in the connected ecosystem. https://aws.amazon.com/iot/ https://cloud.google.com/iot-core https://azure.microsoft.com/en-us/overview/iot/ onference’17, July 2017, Washington, DC, USA Gupta and Sandhu. Figure 1: Overview of an Activity.
In the past, numerous access control models [23–27] and mecha-nisms [28, 29] have been proposed to address authorization needsin both edge and cloud assisted IoT and CPS architectures. Ouaddahet al [30] presented a comprehensive review of IoT access controlmodels, whereas survey based studies [31] in smart home IoT havealso highlighted the need for novel perspective of access controlbased on the relationship among the device owner and the subject.Work by Fernández et al [32] proposed a novel data collection andsharing model for cloud-IoT architectures providing plug-in mod-ule to support IoT application development. Convergent AccessControl framework was recently proposed by Bhatt and Sandhu[33] which highlights the need for synergistic convergence of ac-cess control models at both policy and enforcement layers whichcan address the evolving access control requirements of dynamicapplications for future smart communities.
In this section we describe a preliminary ACAC framework withinwhich specific formal models, policy languages and enforcementarchitectures can subsequently be developed. Our approach is tomotivate various components of this framework by identifyinginteresting use-cases. We first discuss different entities which willbe relevant in activity-centric models, and then discuss the identi-fied characteristics reflecting relationship among activities in theconnected collaborative ecosystem.
Figure 1 provides an overview of an activity (or state) transitionfrom inactive to spraying. This intuitive illustration inspires thefollowing discussion regarding activity primitives.
What is an Activity?
An activity is the current state of a device.It signifies what the device is currently performing. A device canperform one activity, or it can perform multiple activities at a timesimultaneously. For example, a smart manufacturing machine may have robotic arm for packaging and cooling fan to lower the tem-perature of the packed product. Similarly a clustered object [12, 13],like a smart car can have multiple sensors within it, and thereforecan have multiple activities simultaneously initiated by differentsensors inside it. Intuitively an activity is a long continuous eventoccurring for some time. It embodies the coarse-grained state ofthe entity, relevant to making decisions about authorized opera-tions that transition amongst different activities of the entity. Thefine-grained state of the entity will typically involve additional pa-rameter. For example, in Figure 1 the drone in the spraying activitystate will have speed, heading, altitude and so on as parameters ofits fine-grained state.
What are the entities involved in an activity?
An activityinvolves sources who initiate or request the activity, objects onwhich the activity is requested, and an operation performed bythe subject which results in the initiation or change the state ofobject to start a new activity. In addition, there could be variousconditions which must be satisfied to allow an activity. These con-ditions can impact other activities in the system, or may need atwo step approach to get approval from the owner/manager ofthe device. Further, environmental and contextual factors will alsoplay an important role to permit or deny an activity on an object.Sometimes, an activity may not need a source to initiate an activity,but an event which triggers an activity to happen. For example, ifsomeone breaks the window glass, a sensor will start the alarming activity or vibrating sensor due to low fuel level in the oil tank.
How an activity is initiated?
An activity is the result of anoperation requested by different subjects or can result from event(s)in the system. The operation requested by a subject or event willresult in the start or abort of an activity performed by the smartobject. Such subjects can be users in the system or various otherobjects which can request an operation on other objects to performan activity. For example, in smart farming ecosystem a soil mois-ture sensor can request a "TURN ON" operation on water sprinkler which can result in activation of sprinkling activity on water sprin-kler provided the moisture sensor has the permissions along withchecking that the requested activity itself is allowed based on otherconditions in the entire collaborative system. An activity on anobject can also be initiated as a result of other activity on same ordifferent related objects. For example, opening the air panes in agreenhouse at 2 am on a snow day will trigger the alarm on farmmanagers’ phone.
Associated conditions, obligations and mutability.
To al-low an activity on a device, there could be pre-, current- or post-conditions which must be satisfied in the connected ecosystem.These conditions can be other activities, system constraints, obli-gation to start or abort an activity, limits on the number of timesan activity can be requested etc. to enable a particular activity. Forexample, a sibling can turn off the smart speaker of his/her brotherif playing after 12 am. Also, if a sibling is studying in the room,the smart speaker is not allowed to be turned on, i.e. the currentactivity of the sibling limits the activity of other siblings. Further,environmental conditions may involve factors, for example, if thehumidity level is less that a particular value, then only humidifiercan be turned ON by the humidity sensor. In addition, limits onactivities can also be supported, for example, pest spraying is onlyallowed twice a week, irrespective of who requests the activity. owards Activity-Centric Access Controlfor Smart Collaborative Ecosystems Conference’17, July 2017, Washington, DC, USA
In a collaborative environment, different functions and activitieswork together offering a real automated, smart and efficient CPS.These activities can be disjoint, or mutually exclusive but can alsobe inter-dependent on each other in particular order, precedenceor other relationship characterization.In this section, we illustrate how different activities in the systemcan be characterized. Our discussion primarily characterizes therelationship using only two activities, but this can be extended toany number of activities in the connected ecosystem. Also, theseactivities can be completely separate or unrelated which can ini-tiated on multiple different or the same device (in case a smartobject supports multiple activities, for example, an aerial droneperforming thermal imaging and pest spraying). Further, the roleor relationship (owner of the object) of activity requesting subject(user or device) with respect to the object on which the activity isrequested along with other factors (discussed later), will determinethe activity access control decision. The proposed characterizationmay have overlapping use case scenarios but are important to haveseparate discussion for each relationship. In this discussion, we willonly characterise related activities as shown in Figure 2 (leaf nodes)and discuss other relevant factors in the subsequent section.1.
Ordered:
These set of activities are only allowed if initiatedin a particular order. In this type of activity relation, if anactivity A needs to be started on an object, then either ac-tivity B must already be initiated or must be started afteractivity A is complete on same or different device. Theseordered and interdependent activities can be requested bysame or different subjects, which is immaterial. Sequentialactivities cannot be started out of order, and can also haveconsequential impact for future activities. For example, insmart farming, thermal imaging is activated on the aerialdrone by autonomous tractor only after the drone is donewith the pest spraying. Or turning on water sprinkler is al-lowed only after tractor has ploughed a farm. Each activity(thermal imaging or water sprinkling) cannot be activatedwithout checking the requisite preceding activities. In thisexample, the issuing source is irrelevant, but can be impor-tant in different scenarios (e.g., farm manager request maynot be constrained to be in this order).2.
Concurrent:
These set of activities must always happensimultaneously or alternately are allowed to happen simul-taneously. This involves activities which are related to eachother, or the activities which are completely disjoint andhave no impact (relation) among themselves. It is also pos-sible, that activities can be allowed to be concurrent but ondifferent devices, and not on the same device. In this case,if an activity A has started, then activity B must also be ini-tiated in parallel. For example, when the nutrient sprayingactivity is started, the sensor measuring the nitrogen level inthe soil must also be activated so that crops do not receiveover supply of nutrients. These activities are allowed to beinitiated on the same device also which has the capability tospray as well as to record the nitrogen level. The concurrentactivities may be initiated by same subject, or require dif-ferent subjects to start activities concurrently. In that case,
Figure 2: Activity Relation Characterization if a subject A tries to start an activity, it may trigger a re-quest or alert to another subject B who should initiate otherconcurrent activity(s).3.
Temporary:
These related activities can be allowed some-times based on the conditions depending on the context(environmental factors) or the acting user/subject (could bethe administrator of the business unit). This is applicable toactivities which can happen on same or different devices,and possibly on the relationship among the device ownerand the acting user. For example, an activity A is allowedwith activity B temporarily, only when the issuing user is theadmin of the object, and if there is an alert/emergency in thesystem. In case of a greenhouse, roof ventilation system canbe closed by the farm manager while the pesticide spray ishappening only during a tornado warning. Otherwise, thesetwo activities can never be allowed to happen at the sametime outside the tornado condition.4.
Precedence:
There can be an activity which always takeprecedence over other set of activities. If such an activityis requested, it is possible that some existing (or current)activities in the system are aborted (pre-empted or haltedtemporarily) while some can be continued. It is also possiblea new activity may only be allowed for certain amount oftime, or if the context is important, and other halted activ-ities can continue after activity is complete. One activitymay supersede another, for example, calling 911 by parentusing Alexa if fire has been detected in the house. This isalways allowed, irrespective of what other activities, for ex-ample, playing music, is currently active on Alexa. Anotherexample, if a nutrient solution unit is ON (i.e mixing a newconcentration), then all nutrient spraying actuators in thefield must be stopped. This may not be the case for actua-tors located in farm area not supplied by the unit. Sprayingactuators can continue after nutrient mixing is complete.5.
Dependence:
These set of activities have dependence oneach other. Such dependence can be concurrent, precedingor succeeding. Therefore, concurrent can be considered as asub-case for these set of activities. In this case, for instance,an activity A should be active to allow requested activityB or it can be case such that activity A will be allowed but onference’17, July 2017, Washington, DC, USA Gupta and Sandhu. activity C will also start either in parallel or after. Similarly,there could be a case when some activities can never beallowed to perform together. For example, the humidifier inthe air cooling system can operate only along with thermalshading activity in greenhouse bay unless activated by thegreenhouse manager. Similarly, after the pest spray activityis done by the aerial drone, weed scanning activity mustalways be initiated, and the thermal imaging activity by thecameras should be stopped.6.
Conditional:
These related activities can only be allowedif any particular condition (or conditions) is satisfied. Theseconditions can be related to the location of the objects onwhich the activities are initiated, or if the requested relatedactivities are on same or different device, or permitting a newactivity may require another set of activities to be startedor stopped. As an example, an activity A is allowed withactivity B, only if they are performed on different deviceslocated in different rooms. Also at the same time activityC must be initiated by the administrator. In smart farming,ventilation system in the greenhouse can only be turned onafter the pest spraying activity has been completed, and notbefore 1 hour after spraying. In another case, a sibling canraise the thermostat temperature to 75 in his brothers’ roomif he is sleeping alone, and his current location is inside thesame room.7.
Incompatible:
These set of activities can never be allowedto take place simultaneously, or one after the other, or maybe not within a time span. This can also be true irrespec-tive of who initiated it, or any contextual emergency. Forexample, on the same crop field, pesticide spraying by thedrone and water spray by the sprinkler cannot be allowed tohappen together, or within 2 hours after any of the activitieshas been completed. Similarly, fogging in the greenhouseand opening windows cannot be performed together. Anautonomous tractor cannot be issued operations to ploughthe crop field and remove weeds at the same time. By andlarge, these activities can never be allowed together unlessspecial conditions need.As shown in Figure 2 the relationship between activities canbe mainly characterized based on whether they are on the sameor on different devices. If a new activity is initiated on a devicewhich is different than the devices on which existing activities arerunning, and the devices are independent, then there is no conflictfor activity to be allowed. If related activities are initiated on de-pendent devices, access control decision to allow the activity or notshould be based on other activities in the system. This branch issimilar to the characterization in which activities are requested onsame device. Further, in case the activities are unrelated and do notimpact each other, it is immaterial if they are on same or differentdevice. Such activities are allowed. As discussed in the previoussubsection, various relations among activities in the ecosystem con-trol how and which activities are allowed. Therefore, dependenceamong devices/objects and among the activities is important tomake a decision. The independence of the objects can be based onthe location, for example if they are on separate farm areas or indifferent manufacturing units, or it can be functionality of devices.
Figure 3: Factors Impacting Activity in Collaborative System
Similarly, some activities may be allowed to be performed together,but on different devices.These aforementioned characteristics can be combined and havenumerous different combinations to express different security con-ditions. In addition, there are other factors which will require finergrained policy expression as discussed in the following subsection.It should be noted that this characterization is not exhaustive, andnew cases (relationships) will arise and mature as we examine addi-tional use cases in the proposed notion of activity-centric models.
The activities allowed or denied in the system can depend on mul-tiple factors including other activities (as discussed in previoussubsection), users or devices requesting the activity, environmentalfactors, dependence among different objects, count on the activityperformed over a period of time, and user or device permissions.Some questions which need to be considered to allow a new activityin the system include: a) Where is the activity allowed to perform?For example, a child may be allowed to turn on smart speaker inhis room, but may not be allowed to do the same when father (orany other relation) is watching TV in living area; b) Who is allowedto do it? This can be based on the identity of the user or it can alsobe dependent on the relation between the device owner and therequesting user or device; c) When is the activity allowed? It couldbe an emergency, high system risk, number of times the activityhas been requested in a time frame or anomaly in the system. Itshould be noted that before any other factor is checked to initiatean activity, it is imperative to ensure that the user or the device hasthe permission to perform the operation on an object to trigger theactivity. If the subject does not have the permission the requestedactivity should be denied regardless of other circumstances.As illustrated in Figure 3, there are several other factors whichalso contribute in the activity decision. Identity, attributes or re-lationship of
Users or Subjects who initiated or are requesting anactivity in the system are among these. A smart farm owner canstart the water sprinkler which will result in aborting the pest sprayactivity initiated by the temporary worker. However, this may notbe the case when owner the started the pest spray activity andworker tries to water sprinkle. Therefore, role and attributes of theuser and subjects are critical along with the relation among activ-ities. There can be a relation between object and source (user orsubjects) or among different objects which may be impacted by theactivity request. For example, they can belong to the same owner,or same farm, same production unit, same room, same household owards Activity-Centric Access Controlfor Smart Collaborative Ecosystems Conference’17, July 2017, Washington, DC, USA etc. In addition, similar to UCON [7], a user/device may have a threshold limit on how many times a particular activity can be initi-ated. This limit can be per device which are allowed to activate theactivity (drone can pest spray only once or weed detector sensorcan initiate pest spray once via drone), or it can be system wide,such as pest spraying is only allowed twice a day irrespective ofhow it was initiated or who performed the activity. In addition, the‘age’ of the device in the ecosystem may also increase or decreaseits permissions on the set of activities it can perform. A new useror device can be authorized to a limited set of activities. As theuser or device gets older (meaning it has been associated with theorganization or the functional unit for a longer time), the set of per-missions can increase. Continuity of activities will also be impactedwith the request for new activities, in that an ongoing activity maybe halted or aborted. This property (inspired by UCON) is called“continuity” and has to be captured in modern access control for thecontrol of relatively long-lived activity or for immediate revocationof activity. In addition, activities can also be restricted within a timewindow, for example, activity A cannot be allowed within 4 hourspost completion of activity B.
In this section, we sketch a preliminary approach to representpolicies controlling activities in the system using activity controlexpressions. We will provide a generalized structure and represen-tation of expression using different characterization scenarios andaccess control factors as discussed in the preceding sections. Ourattempt is not so much to come up with a formal policy language,but rather to have a sample overview of how such activity-centricpolicies can be represented.A generalized activity control expression defined per smartobject in the ecosystem can be specified as follows.Object:
ObjectX ⟨ (op, sourceX, activityX),( 𝑝𝑟𝑒 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 ),( 𝑐𝑢𝑟𝑟𝑒𝑛𝑡 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 ),( 𝑟𝑒𝑠𝑢𝑙𝑡𝑖𝑛𝑔 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 ),( 𝑐𝑜𝑛𝑡𝑒𝑥𝑡𝑢𝑎𝑙 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 ) ⟩ where 𝑝𝑟𝑒 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 , 𝑐𝑢𝑟𝑟𝑒𝑛𝑡 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 and 𝑟𝑒𝑠𝑢𝑙𝑡𝑖𝑛𝑔 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 canbe expressed as ⟨ ( 𝑝𝑟𝑒 _ 𝑠𝑡𝑎𝑡𝑒, 𝑜𝑏 𝑗𝐴, 𝑠𝑜𝑢𝑟𝑐𝑒𝑌 ), ...... ⟩ , ⟨ ( 𝑐𝑢𝑟 _ 𝑠𝑡𝑎𝑡𝑒, 𝑜𝑏 𝑗𝐵, 𝑠𝑜𝑢𝑟𝑐𝑒𝑍 ), ...... ⟩ , and as ⟨ ( 𝑛𝑒𝑤 _ 𝑠𝑡𝑎𝑡𝑒, 𝑜𝑏 𝑗𝐶, 𝑠𝑜𝑢𝑟𝑐𝑒𝑋 ),.. ⟩ respectively.This generalized policy is defined for object ObjectX, stat-ing that sourceX is allowed to perform an operation op whichwill change the state of ObjectX to a new activity activityX,iff the 𝑝𝑟𝑒 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 and 𝑐𝑢𝑟𝑟𝑒𝑛𝑡 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 are satisfied to-gether with the 𝑐𝑜𝑛𝑡𝑒𝑥𝑡𝑢𝑎𝑙 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 , and the resulting con-ditions for the approval of this requested activity activityXis stated in 𝑟𝑒𝑠𝑢𝑙𝑡𝑖𝑛𝑔 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 . These conditions capture thepre- and current conditions for ObjectX as well as other re-lated/dependent objects ( objA, objB, .... ) and their correspondingactivities ( 𝑝𝑟𝑒 _ 𝑠𝑡𝑎𝑡𝑒, 𝑐𝑢𝑟 _ 𝑠𝑡𝑎𝑡𝑒, 𝑛𝑒𝑤 _ 𝑠𝑡𝑎𝑡𝑒 ) as well as the subjects( sourceY, sourceZ, .... ) which initiated that activity in the collabora-tive system. In addition, the 𝑐𝑜𝑛𝑡𝑒𝑥𝑡𝑢𝑎𝑙 _ 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝑠 can be definedin first order propositional logic formula with a suitable policylanguage such as value(nitrogen) > ∧ value(weather) = severe . It should be noted that usage control for each activity (the number oftimes the activity can be performed during a particular time-frame,for example, water spraying can only be performed twice a dayirrespective of which subject is requesting) along with per sourceactivity control (a subject may only be allowed to activate an activ-ity only three times in a week) must also be expressed in activitycontrol policy expression. Following are some examples of usingthe generalized activity control expressions in different scenarios. Activity Example 1:
A soil moisture sensor can issue operationTURN ON to a water sprinkler and change its state to active (i.e.water sprinkler is running), only if the water sprinkler is currentlyin an inactive state which was changed by farm-manager (this is apre-condition).
Object : Water Sprinkler ⟨ (TURN-ON, moisture sensor, Spraying),(cur_inactive, Water Sprinkler, farm-manager) ⟩ . Activity Example 2:
A weed detector sensor can issue operationSPRAY ON to an Aerial Drone and change its state to Spraying, ifthe Nitrogen sensor in the field is active (i.e sensing nitrogen levelin soil) enabled by farm-manager and the nitrogen level in soil isless than 50.
Object : Aerial Drone ⟨ (SPRAY-ON, weed detector, Spraying),(cur_active, Nitrogen sensor, farm-manager),(value(nitrogen-level) < ⟩ . Activity Example 3:
Thermal imaging is activated on the AerialDrone by autonomous tractor only after the drone is done with thespray which was initiated by weed detector, and as a consequenceof the start of the new activity (i.e Thermal-imaging) the sprayingshould be stopped.
Object : Aerial Drone ⟨ (IMAGING-ON, autonomous tractor, Thermal imaging),(cur_spraying, Aerial Drone, weed detector),(new_inactive-spraying, Aerial Drone, autonomous tractor) ⟩ .Here, it should be noted that the resulting activity i.e. sprayingto stop is due to the new activity (Thermal imaging) requestedby autonomous tractor. Therefore, autonomous tractor is also thesource for inactive spraying on Aerial Drone object. Activity Example 4:
Turning ON Pest Spray after Tractor hasploughed a farm (assuming worker issued command for the tractorto plough) is allowed irrespective of source of the activity request.
Object : Pest Spray ⟨ (TURN-ON, ANY, Spraying ),(pre_ploughing, Tractor, worker) ⟩ . Activity Example 5:
The filtering process can be started on smartOil Filter by the production manager, if the oil tank valve is closed.
Object : Oil Filter ⟨ (TURN-ON, production manager, Filtering),(cur_close, Oil tank Valve, ANY) ⟩ . onference’17, July 2017, Washington, DC, USA Gupta and Sandhu. Activity Example 6:
Air Conditioner cooling in the pharmaceuticalfacility cannot be turned on by the thermostat if the moisture sensoris inactive, and the current temperature is greater than 75.
Object : Air Conditioner ⟨ (TURN-ON, thermostat, Cooling),(cur_active, moisture sensor, ANY),(value(temperature) > ⟩ . Activity Example 7:
Oil pumping by the smart valve can be activatedonly after hydrotreating is performed by the hydrotreater unit byworker. After oil pumping, outlet valve should remain closed.
Object : Tank Pump ⟨ (TURN-ON, valve, pumping),(pre_hydrotreating, hydrotreater-unit, worker),(post_closed, outlet valve, ANY) ⟩ . Activity Example 8:
Robotic Arm must be inactivated when produc-tion belt accelerometer is vibrating.
Object : Robotic Arm ⟨ (Inactive, ANY, Inactive),(cur_vibrating, production belt, ANY) ⟩ .Here, ANY is used when the sensor does not need a subject toinitiate an activity. Here the belt started vibrating due to someevent. Therefore activity can be initiated by subjects or an event. Activity Example 9:
A user with mobile phone can only be allowedto unlock the door alarm if parent has inactivated the alarm.
Object : Door ⟨ (UNLOCK, mobileX, Inactive),(cur_inactive, alarm, parent) ⟩ . Activity Example 10:
Bob can turn off the smart speaker of Tom ifplaying after 12 am.
Object : Speaker ⟨ (TURN-OFF, Bob, Inactive),(Active, Speaker, Tom) ,(value(Time) > ⟩ . Activity Example 11:
A child may be allowed to turn on smartspeaker in his room, but may not be allowed to do the same whenparent is watching TV in living area (this is current condition).
Object : Speaker ⟨ (TURN-ON, Child, Active),(cur_inactive watching, TV, Parent) ∨ (cur_active watching, TV, Parent) ∧ location(TV) != living area ⟩ .The aforementioned policies represented are defined per object,which is not the optimal way to design such a policy based solu-tion which may have hundreds of smart objects in a connectedecosystem to be controlled. One approach to define these policy isper object type , which is similar to an attribute assigned to objectswhich have alike functionality or perform same activity. We canalso separate objects into object groups , so as to have similar objectsinto one category and define a policy per group. Such number ofgroups will be less, easier to administer and define policy per group.Similar groups can be created for subjects or source of the operationwho requested the activity. A sample policy per object and sourcegroups may be represented as follows. Activity Example 12:
Window in a greenhouse cannot be openedby any user or sensor during the pest spraying activity initiated by
Figure 4: PEI Models Framework [34] any user on any device. (Here Window is the object type, or groupof all windows in the greenhouse.)
Object-Type : Window ⟨ (TURN-ON, ANY, Open),(cur_inactive Pest Spraying, ANY, ANY) ⟩ .In this section, we illustrated our first attempt in an informalmanner to create and design activity control expressions with exam-ples in different connected and collaborative domains. Additionalresearch is needed to express these policies in a more understand-able and structured manner. So far we have proposed a novel perspective and approach to ad-dress access control needs in dynamic and activity oriented collab-orative ecosystem considering activities as the fundamental entity.We discussed activity characterization, and highlighted core re-quirements to define activity-centric access control (ACAC) systemfocusing on the conceptual foundational principles in an informalway. In this section, we highlight future research directions neededto fully mature activity-centric models in connected CPS. We willuse the PEI framework [34] as illustrated in Figure 4 to highlightthe research requirements. These are the Policy (P), Enforcement(E) and Implementation (I) layers, and formal models are neededto express and analyze the security policy at each of these threelayers. Following we highlight some open research questions.
Formal mathematically grounded models and outline abstractionssimilar to RBAC96 [2] and ABAC [3] are needed to define differententities included in proposed ACAC request decision. It is desirableto define a meta-model which provides the foundation for designingextensible and adaptable access control models which can fit intodifferent CPS domains. These models should address the core issuesof pre, current and post activities along with condition, obligations, owards Activity-Centric Access Controlfor Smart Collaborative Ecosystems Conference’17, July 2017, Washington, DC, USA mutability and usage needs per user or activities. Subjects, objects,and operations can be divided into several detailed componentswith different perspectives. In addition, the foundational modelsmust address the principles of next generation access control [33].This reflects the need for security models at layer 1 and 2 in thePEI model shown in Figure 4. The main motivation for developingformal models is to focus on the real policy needs of the applicationwithout being distracted by implementation details and practicalrealities of smart connected systems.
It is important to identify different cloud, edge, or hybrid architec-tures to enable deployment of the formal models. Such architecturewill be formulated based on the application needs. Further, fed-erated and collaborative architectures also need to be developedto enable cross enterprises, cross domain interaction and commu-nication among smart devices and controlling their activities inshared connected ecosystems such as co-operatives. This will alsodeal with the approximations and additional servers introducedby the distributed nature of real-world distributed systems. Thegoal should be to make the approximations explicit and control-lable since perfect correspondence to the idealized models layeris impossible. Different architectures are possible based on wherethe policies are maintained, evaluated, and enforced. Enforcementis key issue and is particularly critical for IoT devices which areresource constrained.
Policy and activity control expression languages must be developedexpressing the policies specifiable by the formal operational andadministrative models developed. In addition, the policies must beflexible and extensible to apply in different domains. These policiesmust consider not only the subjects, objects and activities, but alsoconsider conditions and obligations along with usage control toaddress the mutability aspect of an activity. The policy languagesupporting the activity control expression must be able to captureif the activity is not requested beyond a numerical threshold, orby the threshold per subject. Theory must be developed for con-straints specifications such as separation of duty and cardinalityconstraints regarding contextual risk factors. An initial approachwould be develop a framework to first understand different kindsof constraints. Such policy language is also important to repre-sent multiple relationships and characterization among differentactivities as discussed in Section 3.
Administrative models provide facilities to create entities, and de-fine conditions, contextual factors, activities and correlations, re-lationships etc. in the system. Such models enable specification ofwho can decide on devices and activities which impact differentsections and working units in a single large domain. For example,a device in the greenhouse of the farm may be impacted by thefood processing unit in the same farm, but these are managed bytwo different security administrators. So, how will the activitiesbe checked if they impact objects in these two sub-units. Can theowner of the object, or the manager of the location of the object make such decision? Who will allow to authorize the activity? De-vices can be administered by the owner of the device, but can alsodelegate administration to someone else after initial setup. For ex-ample, a farm owner can temporarily delegate activity access rightsto temporary workers. It is important to examine if ABAC andRBAC like administrative models can work in the activity focuseddomains, or an activity based approach is needed to develop similarmodels for proposed ACAC models. These questions becomes moreinteresting in distributed domains administered by different users,where multiple activities are happening concurrently.
Bhatt and Sandhu [33] proposed access control convergence re-flecting the need for crossbreed or hybrid of established and newaccess control models to support dynamic and distributed futureconnected systems. In such domains, attributes of different entities,relationships between different entities, and other features must becaptured to provide dynamic and fine-grained access control thatcan be adapted and enforced in a wide range of applications. Similarconvergence is also needed for activity-centric models. Since theactivities provide a two step check, one if the subject is allowed toperform an operation to start an activity, and second, if there areactivities, constraints or obligations among activities is satisfied,to allow or deny an activity, such convergence is natural. The goalshould be to develop and evaluate such hybrid approaches, anddetermine their applicability and expressiveness to support policiesamong different distributed applications and CPS domains. AI aims to support automated security defense solutions. Similarlyresearch is needed to develop AI and data driven systems basedon activity logs and other important data points to automaticallydefine the relationship among different activities in the system, anddevelop a self-adaptive AI based ACAC mechanisms. Data fromthe connected ecosystem can be used to define the activity-centricpolicies, or AI models can be trained to make a decision withoutthe need for explicit policies as such. However, how to ensure ifthe AI models will work as intended or decide correctly is also aresearch question. Attempts have been made to develop data drivensystem [35, 36] which allow to generate optimal access controlpolicies for autonomous systems. Similar frameworks are neededfor activity-centric access controlled CPS systems. This supportsresearch at the implementation layer in Figure 4.
It is important to conduct the theoretical analysis of both administra-tive and operational activity-centric models that will be developed.A primary safety question is whether, a system can reach to a statewhen certain activities be allowed by subjects under certain condi-tions. Because some of the smart domains (such as water treatmentfacility) are very critical, it is imperative to ensure that activitiesrelationships, along with pre or post conditions must always besatisfied. A sample safety question can be, is it possible that systemreaches to a state where two conflicting activities are allowed bydifferent subjects, for example, pest spray and water spray in asmart farm. onference’17, July 2017, Washington, DC, USA Gupta and Sandhu.
The developed models and mechanisms for the proposed activity-centric access control must be adaptive to be applied in differentsmart and connected domains. In our activity control expression,we have attempted to reflect some activities in smart farming, man-ufacturing and homes. We firmly believe that other CPS domainssuch as transportation [37], building, healthcare, energy, defense,robotics etc. will have similar concept of interconnected activitiesalong with notion of obligation and conditions among differentsmart entities. Once a core formal model is developed, these shouldbe extended to various smart, distributed and collaborative systems.
Activities are an integral part of a connected and coordinated CPS.Different sensors, actuators and smart devices perform various ac-tivities in the system which collectively result in the automation ofan entire ecosystem. These fully integrated and collaborative sys-tems respond in real time to meet challenges of growing distributedbut synergistic smart systems supported by IoT. This paper outlinesour first attempt towards a vision of activity-centric access controlframework for smart connected ecosystems. The core idea is tohow the current or preceding activities along with other importantfactors including usage, conditions and obligations for activitieslimit access control for new activities requested by users or deviceson different smart objects. We discuss and characterize relationsamong various activities. In addition, a preliminary attempt is madeto define activity control expressions in different smart use-caseswhich offers a structure considering pre, current and post activitiesalong with contextual conditions to control activities. We outline afuture research agenda envisioning development of formal modelsand policy languages along with enforcement architectures for theproposed activity-centric access control solutions.
ACKNOWLEDGEMENT
This research is partially supported by NSF CREST Center GrantHRD-1736209 at UTSA, and by the NSF Grant 2025682, FacultyResearch Grant Program and NASA Grant 80NSSC20M0186 at Ten-nessee Technological University.
REFERENCES [1] Ravi S Sandhu and Pierangela Samarati. Access control: principle and practice.
IEEE communications magazine , 32(9):40–48, 1994.[2] Ravi S Sandhu. Role-based access control. In
Advances in computers , volume 46,pages 237–286. Elsevier, 1998.[3] Xin Jin, Ram Krishnan, and Ravi Sandhu. A unified attribute-based access controlmodel covering DAC, MAC and RBAC. In
IFIP Annual Conference on Data andApplications Security and Privacy , pages 41–55. Springer, 2012.[4] Maanak Gupta and Ravi Sandhu. The
GURA G Administrative Model for Userand Group Attribute Assignment. In
International Conference on Network andSystem Security , pages 318–332. Springer, 2016.[5] Roshan K Thomas and Ravi S Sandhu. Task-based authorization controls (TBAC):A family of models for active and enterprise-oriented authorization management.In
Database security XI , pages 166–181. Springer, 1998.[6] Jaehong Park and Ravi Sandhu. Towards usage control models: beyond traditionalaccess control. In
Proc. ACM SACMAT , pages 57–64, 2002.[7] Ravi Sandhu and Jaehong Park. Usage control: A vision for next generationaccess control. In
International Workshop on Mathematical Methods, Models, andArchitectures for Computer Network Security , pages 17–31. Springer, 2003.[8] Jaehong Park and Ravi Sandhu. The UCON-ABC usage control model.
ACMTrans. Inf. Syst. Secur. , 7(1):128–174, February 2004.[9] Alexander Pretschner, Manuel Hilty, and David Basin. Distributed usage control.
Commun. ACM , 49(9):39–44, 2006. [10] Jaehong Park, Ravi Sandhu, and Yuan Cheng. ACON: Activity-centric accesscontrol for social computing. In , pages 242–247. IEEE, 2011.[11] J. Park, R. Sandhu, and Y. Cheng. A user-activity-centric framework for accesscontrol in online social networks.
IEEE Internet Computing , 15(5):62–65, 2011.[12] Maanak Gupta and Ravi Sandhu. Authorization framework for secure cloudassisted connected cars and vehicular internet of things. In
Proc. of the 23nd ACMon Symposium on Access Control Models and Technologies , pages 193–204, 2018.[13] Maanak Gupta, James Benson, Farhan Patwa, and Ravi Sandhu. Dynamic groupsand attribute-based access control for next-generation smart cars. In
Proceedingsof the Ninth ACM Conference on Data and Application Security and Privacy , pages61–72, 2019.[14] Sina Sontowski et al. Cyber attacks on smart farming infrastructure. In
Proc. ofthe IEEE Conference on Collaboration and Internet Computing (CIC) , 2020.[15] Maanak Gupta, Mahmoud Abdelsalam, Sajad Khorsandroo, and Sudip Mittal.Security and privacy in smart farming: Challenges and opportunities.
IEEE Access ,8:34564–34584, 2020.[16] Maanak Gupta, Farhan Patwa, and Ravi Sandhu. An attribute-based accesscontrol model for secure big data processing in hadoop ecosystem. In
Proceedingsof the Third ACM Workshop on Attribute-Based Access Control , pages 13–24, 2018.[17] Maanak Gupta, Farhan Patwa, and Ravi Sandhu. Object-tagged RBAC modelfor the Hadoop ecosystem. In
IFIP Annual Conference on Data and ApplicationsSecurity and Privacy , pages 63–81. Springer, 2017.[18] Vincent C Hu, D Richard Kuhn, and David F Ferraiolo. Access control foremerging distributed systems.
Computer , 51(10):100–103, 2018.[19] Elisa Bertino. IoT Security A Comprehensive Life Cycle Framework. In ,pages 196–203. IEEE, 2019.[20] Maanak Gupta and Ravi Sandhu. Reachability Analysis for Attributes in ABACwith Group Hierarchy. arXiv preprint arXiv:2101.03736 .[21] Smriti Bhatt, Farhan Patwa, and Ravi Sandhu. Access control model for AWSinternet of things. In
International Conference on Network and System Security ,pages 721–736. Springer, 2017.[22] Deepti Gupta et al. Access control model for Google cloud IoT. In
IEEE 6th IntlConference on Big Data Security on Cloud (BigDataSecurity) , pages 198–208, 2020.[23] Asma Alshehri and Ravi Sandhu. Access control models for cloud-enabledinternet of things: A proposed architecture and research agenda. In
IEEE 2ndInternational Conference on Collaboration and Internet Computing (CIC) , pages530–538, 2016.[24] Imane Bouij-Pasquier, Abdellah Ait Ouahman, Anas Abou El Kalam, andMina Ouabiba de Montfort. SmartOrBAC security and privacy in the Internet ofThings. In , pages 1–8. IEEE, 2015.[25] Yuan Tian et al. Smartauth: User-centered authorization for the internet of things.In { USENIX } Security Symposium , pages 361–378, 2017.[26] Ning YE et al. An efficient authentication and access control scheme for percep-tion layer of internet of things.
Appl. Math , 8(4):1–8, 2014.[27] Maanak Gupta, James Benson, Farhan Patwa, and Ravi Sandhu. Secure V2V andV2I communication in intelligent transportation using cloudlets.
IEEE Transac-tions on Services Computing , 2020.[28] Roei Schuster, Vitaly Shmatikov, and Eran Tromer. Situational access controlin the internet of things. In
Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security , pages 1056–1073, 2018.[29] Yunhan Jack Jia et al. ContexloT: Towards Providing Contextual Integrity toAppified IoT Platforms. In
NDSS , volume 2, pages 2–2, 2017.[30] Aafaf Ouaddah, Hajar Mousannif, Anas Abou Elkalam, and Abdellah Ait Ouah-man. Access control in the Internet of Things: Big challenges and new opportu-nities.
Computer Networks , 112:237–262, 2017.[31] Weijia He et al. Rethinking access control and authentication for the homeinternet of things (IoT). In { USENIX } Security Symposium , 2018.[32] Maribel Fernández et al. A Data Access Model for Privacy-Preserving Cloud-IoTArchitectures. In
Proceedings of the 25th ACM Symposium on Access ControlModels and Technologies , pages 191–202, 2020.[33] Smriti Bhatt and Ravi Sandhu. Convergent access control to enable secure smartcommunities. In
IEEE International Conference on Trust, Privacy and Security inIntelligent Systems and Applications (TPS-ISA) , pages 148–156, 2020.[34] Ravi Sandhu. The PEI framework for application-centric security. In
Proceedingsof the 5th IEEE International Conference on Collaborative Computing: Networking,Applications and Worksharing , pages 1–5, 2009.[35] Valentina Salapura et al. Generative policy framework for ai training datacuration. In
IEEE International Conference on Smart Computing (SMARTCOMP) ,pages 475–477, 2019.[36] Amani Abu Jabal et al. Polisma-a framework for learning attribute-based accesscontrol policies. In
European Symposium on Research in Computer Security , pages523–544. Springer, 2020.[37] Maanak Gupta, Feras M Awaysheh, James Benson, Mamoun Al Azab, FarhanPatwa, and Ravi Sandhu. An attribute-based access control for cloud-enabledindustrial smart vehicles.