Privacy-based medical data protection against internal security threats in heterogeneous Internet of Medical Things

Abstract

Data and information security is considered to be an important and challenging task for any field of life. But it becomes more critical especially when it deals with the medical field due to life and health hazards. The ratio of internal security threats to external threats always remains high. A huge number of efforts and technical expertise are required in the case of attacking the system from the external environment. But it requires fewer efforts if a system is attacked internally by the stakeholders of the system. This article presents an access control model that secures the medical data of patients against internal cybersecurity threats. It allows only the legitimate users, that is, authorized patients and doctors to communicate despite the fact of physical boundaries. The proposed model implements authorization in combination with permissions and roles instead of roles only for medical staff. It removes the discrepancies in the existing access control models. The proposed model ensures communication among doctors and patients in a secure, private, and efficient manner. The model is demonstrated by using mathematical modeling along with implementation examples. The proposed model outperformed in comparison with state-of-the-art access control models.

Introduction

The medical data protection is at great risk due to the rapid growth of the Internet of Things (IoT) usage and cellular communication (4G/5G). The security of medical data is of great importance and critical task. Unauthorized access to the medical data of patients can create great harm in terms of incorrect medicine prescription that may lead to the health hazards and death of the patients. The ratio of internal security threats to external threats is high. So, internal security threats are more critical and challenging to manage as compared to external security threats.

A study on the potential for using the blockchain technology is carried out particularly for the protection of health-care data which are hosted on the cloud. Unauthorized access to the medical data of patients can create great harm in terms of incorrect medicine prescription that may lead to the health hazards and death of the patients. This is the reason that in developed and developing countries patient’s data are kept highly secure and private. ¹

For this purpose, modified version of role-based access control (RBAC) is deliberated as a good candidate. The roles, permissions, and the users are the basic elements of RBAC. The roles are integrated with the permissions and users. ² A permission assignment is an action that can be taken on an object or a resource. ³ According to the RBAC standard, ⁴ an action or the object on which this action is to be taken is not the key role player independently in RBAC but permission is only made when these two elements work jointly. RBAC limitations and weaknesses are discovered by many researchers. To overcome this weakness and limitations, various authors updated the RBAC model in various terms. A cyberspace-oriented access control (CoAC) model is proposed for cyberspace. Generalizing objects and subjects in cyberspace and then scene-based access control is developed. ⁵

The focus of this article is to secure the medical data of patients against internal cybersecurity threats. It allows only the legitimate users, that is, authorized patients and doctors to communicate despite the fact of physical boundaries. Internal data leaks stem from employees. Sometimes it can be hard to believe that an employee would willingly sabotage their own company, and although sometimes it happens willfully, most of the time it is purely accidental. The proposed model implements authorization in combination with permissions and roles instead of roles only for medical staff. It removes the discrepancies in the existing access control models. The proposed model ensures communication among doctors and patients in a secure, private, and efficient manner.

The proposed model ensures the application of dynamic separation of duty (DSD) due to contradictory permissions. The model is grounded with the idea of applying DSD based on mutually exclusive permissions (MEPs) as a replacement of roles, and this model stores the objects as a tree-like directory structure. ²

DSD in RBAC is applied due to a contradiction in interest among diverse contradicting roles which have been circumvented. DSD is forcedly applied when roles are activated to the users instead of role assignment as it was practiced in static separation of duty (SSD). The definition of DSD reveals “if a user would require activating two conflicting roles then the user may activate one of two conflicting roles in one session and the other role in another session.” ⁴

In future conceding and canceling the roles will be achieved dynamically, according to abstraction, separation, containment, automation and accountability (ASCAA) Ideologies for Next-Generation-RBAC.^5,6 The roles can be granted and revoked dynamically and optimally by incorporating DSD implementation in RBAC. RBAC is considered as a mechanism used to implement several security policies. RBAC is known as a mechanism for implementing separation of duty (SOD) because it is closely attached to it.^7,8 In this research, a model is proposed which incorporates the DSD on level of contradicting permissions. These contradictions are caused by various factors. The permissions are contradicted due to contradicting by actions and objects alone or both simultaneously. A local authentication and access control scheme (LACS) is developed where it allows machine to machine (M2M) devices to locally verify the access rights and access privileges of the users. ⁹

The proposed model implements the conflicting permissions associated with hospital medical staff. The object is realized as a key entity like other entities, that is, permissions, users, and roles. The object can be considered as any of the resources like a printer, directory, file, folder, and so on. The purpose and importance of using an object with DSD are profoundly discussed in the proposed model. ² A complete hybrid model for the security of diagnostic textual data is developed. This scheme is developed by combining the Advanced Encryption Standard (AES) and Rivest, Shamir, and Adleman (RSA) algorithms. ¹⁰

State-of-the-art

An efficient medical data sharing scheme is presented by utilizing the attribute-based encryption scheme by enabling data sharing. ¹¹ A study proved that the maximum number of applications do not accept and implement recommended practices and guidelines. They even do not accept or implement legal restrictions which are imposed by current data security rules. This is one of the causes of internal security cyber threats. ¹²

RBAC has been examined in several aspects by the researchers. The combination of permissions and authorization time resulted in an optimal interoperable system in RBAC and relationship-based access control (ReBAC) models. ¹³ Another access control methodology is developed for emergency situations for doctors and nurses to access the patient’s information without overt request by merging critically aware access control (CAAC) and RBAC. ¹⁴ The cloud storage is becoming famous nowadays, and access control is a critical and challenging issue. A model, incorporating RBAC hierarchy with users and attributes of roles, saves the computational cost and the transmission cost for the users in the cloud network. ¹⁵

The security-based scheduling algorithm “security and availability-based trust relationship in RBAC” is proposed. This model uses the availability of network and states of security as factors for trust relationship. ¹⁶ For the ratification of long-listed access control policies, a first-order logic RBAC (FORBAC) model is proposed. To measure the degree of expensiveness, the analysis is conducted in European Bank. ¹⁷ The analysis of administrative role-based access control (ARBAC) is done without the limitation of the distinct administration. ¹⁸

Various RBAC limitations are explained, and then the use of mining of limitation is executed by implementing traditional data mining tools at RBAC limitations. ¹⁹ RBAC policies are implemented according to relevant data based on place and time. An automatic as well as efficient method of analysis for the administration of temporary RBAC policies is presented. The accessibility issues are translated correctly for reachability problems. ²⁰ In the cloud, the user data are selected/removed, and traditional RBAC models may result in administrative problems resulting in the growing number of users. The concept of four-dimensional (4D) role is presented to control the possibilities of information leaks and management complexity for the cloud environment. ²¹ Control of access to the cloud environment is far more challenging than others. Instead of relying on cloud providers, users can safely save their data cloud with an encryption technology. ¹¹ RBAC and its extension have been discussed and implemented due to management ease, firm security, and usability. Therefore, it is inevitable to discover its strengths and weakness with all of its potential extents.

Role inheritance/role hierarchy

The role inheritance (RI) has been discussed a lot in various research literature with different aspects (see, e.g., Sandhu et al., ³ Ferraiolo et al., ²² Moffett, ²³ and Ferraiolo and Kuhn ²⁴ ). The basic motivation behind the incorporation of role hierarchy (RH) in RBAC is that usually different roles may have some common permission/s. So, instead of dealing with the same permissions again and again in various roles, it is better to connect such roles having the same permissions with the help of RH or RI. In this way, the security administrator deals with the same permissions in a few roles. But this is not always the case that every role will share some common permission/s and stand in somewhere in RH.

Some roles may stand alone independently without inheriting or get inherited other roles. In RH, the permissions of junior roles are assigned to the senior roles. But the junior roles cannot have permissions of their senior roles. If there will be a situation when the user assigned to junior role needs to have and activate the role of senior role, then the system will be unable to handle this situation. To overcome this problem, a role delegation process is introduced in the study by Na and Cheon. ²⁵ In this methodology, the senior role will be assigned to the user assigned to the junior role on a temporary basis. After activating the senior role, the role will be revoked and will not be available to the user having junior roles. This will happen in special circumstances to keep the system in running position. Afterward, it may be required by the system to approve the role of delegation process by the user assigned to a senior role.

It will be an error-prone and hectic job for the security administrators to assign or revoke the same permissions again and again to different roles due to the absence of RHs. There may be a tree of roles as per the structure of the organization. The roles stand on different levels like senior most, junior most, senior or junior levels, and so on. Each role has a certain number of permissions. There is a sound possibility in RI that a specific role inherits a certain number of permissions from another role or on the other side another role inherits a certain number of permissions from this specific role.

We would discuss a few important aspects of RH. RH does not come under the core RBAC module. There is a separate module given in ANSI INCITS 359-2004 ⁴ called Hierarchical RBAC that deals with RH. RH is also a kind of powerful access control feature same as user-role and permission-role assignment. If there will be two roles “R₁” and “R₂” and we say that “R₁” inherits “R₂,” then it means that all the permissions of role “R₂” will be present in the role “R₁.” The role “R1” will be at a higher level of hierarchy due to inheritance and the role “R₂” will be at a lower level relative to the role “R₁.”

So, the roles that stand at a higher level of the hierarchy have all the permissions of the roles standing at a lower level of the hierarchy. But on the other side, the role which is standing at a lower level of the hierarchy will have all the users assigned to the role standing at higher levels. It means the users who are authorized for higher-level roles will also be authorized for lower-level roles automatically as a result of implementing RH. The roles in RH standing at higher role levels will be bigger in terms of a number of permissions than the roles standing at lower levels. Some very interesting properties of RI are discussed in the study by Jansen. ²⁶ The authors also discussed the effects of RH on RBAC constraint, that is, SOD.

In actual practice, a role can be fully inherited or it can be partially inherited that means it may be possible in a real scenario that a role inherits some but not all the permissions of another role. If a role inherits all the permissions of another role, then it is called as full inheritance, and if a role does not inherit all the permissions of another role, then it is called as partial inheritance. There are many variations in RH discussed in the literature (see, e.g., Moffett and Lupu, ²⁷ Baldwin, ²⁸ Nyanchama and Osborn, ²⁹ and Nyanchama and Osborn. ³⁰ )

There are a lot of benefits of implementing RH in RBAC. The administrator can easily manage to deal with assigning/revocation of permissions and users to/from roles. There are certain types of RHs based on generalization, aggregation, and organization. ²³

In Figure 1, we have shown an abstract organizational structure in the form of RH. There will be inheritance relations among roles and the relations will be defined in terms of permissions. It means that if a role “General Manager” inherits the role “Manager Finance,” then all the permissions of role “Manager Finance” will be available to the user who is assigned to the role “General Manager” due to RI. On the same but reverse pattern, all those users who will be assigned to role “General Manager” will also be eligible to activate role “Manager Finance” due to RI. Thus, the user “Charlie” assigned to the role “General Manager” is a senior role the user will also be assigned to the role “Manager Finance” due to the implementation of RI as shown in Figure 1.

Figure 1.

Role hierarchy.

The more powerful roles stand at the top of the hierarchical tree and they are called as senior roles. On the same pattern, less powerful roles stand at the bottom of the hierarchy tree and they are called as junior roles.

There are basically two types of RHs on the basis of constraints. First is the general role hierarchy (GRH), and the second one is the limited role hierarchy (LRH). GRH gives the concept of multiple inheritances, which means that a role can be inherited from permissions of multiple roles and in the same manner inherit user membership of roles from multiple roles.

But LRH does not support the concept of multiple inheritances. If there will be any constraint applied on a role in an RH, then in the case of LRH, the effect will be up to single immediate descendant only. There will be no third role between two roles in this type of RH.

Proposed model

The permission-based mutual exclusion must be implemented instead of role-level mutual exclusion. For this, it is necessary to address the level of permissions. DSD is dependent on contradictory permissions as compared to conflicting roles. This technique helps to resolve the disputes among conflicting roles which is proved to be a more applied and challenging approach. Therefore, the disputes must be referred to as conflicting permissions in RBAC standard rather than the conflicting roles. ⁴

There are usually a huge number of objects in an organization. The permissions are a combination of operations and resources. Therefore, this is a very difficult task to create permissions manually by a security administrator. In an organization, there is a limited list of actions, but the list of objects is too long to handle. The number of objects increases with the passage of time in the life of an organization. Therefore, objects can be hundreds of thousands in number. An algorithm is suggested to ensure that the mutually exclusive roles (MERs) and other constraints are mutually enforced to SOD. The proposed algorithm ensures the stability of the RBAC models in relation to the processes.

DSD is mobilized and implemented automatically. The researchers have figures about the ratio of conflicting roles to the total number of roles in the user’s population. A few (3%–4%) of the population of the user roles exist. This proportion is indicated in their case studies that may differ from the study. ³¹

The admin does not need to clearly explain the contradictory permissions that the same object is given MEP with the same object. It will be fair for the security administrator to save many attempts and time that was manually used to sign in through several MEPs. As opposed to the classic RBAC, a model is presented to users as a role-driven and self-assigned role. They also pointed out the lack of induced role structure and other existing RHs.

Pulur et al. ¹³ and Abo-alian et al. ¹⁴ added a workflow setting for multiple MERs to verify the dispute at runtime. This applies DSD to the level of contradictive permissions. We present the model, which applies DSD for such contradictive permissions having different objects. A specific security framework which is service-oriented is developed for Medical Services in IoT. ³² Majority of authentication protocols may not be applicable to wireless medical sensor networks (WMSN) for providing user’s anonymity. An architecture for patient-monitoring health-care system in WMSN is proposed, and design of an anonymity-preserving mutual authentication protocol for mobile users is provided. ³³ Anonymity preserving remote patient authentication scheme usable in E-health care systems is proposed. It validates the security of the proposed scheme using Burrows–Abadi–Needham (BAN) logic that ensures secure mutual authentication and session key agreement. ³⁴

The proposed medical data protection access control (MDPAC) model gives authority to the security administrator to assign users to roles, permissions to roles and actions to objects or resources. The administrator assigns various categories of patients to medical staff including medical doctors and nurses. The medical staff then access the electronic medical record (EMR) to prescribe medicine and clinical tests, view clinical test reports, and discuss the reports with other specialized medical staff with the consent of patients. All this access is granted based on MDPAC, where RBAC is working underlaying. All the updates are stored in the hospital database. Only the authorized medical staff will be able to access the patient data. The patients are also able to access their own data through remote monitoring or telemedicine in the environment of the IoT. The critical patients can be monitored remotely from anywhere by the hospital medical staff. The senior medical staff can have the authority of junior medical staff in the case of emergency if the senior medical staff has been assigned to a higher authority role.

The proposed model is different in many aspects. The main emphasis of the proposed model is on the MEPs rather than MERs. Achievement of the proposed model is the automatic assignment of conflicting permissions. The security administrator describes the list of contradictions as manual permissions, rather than contradictory permissions. According to conflicting actions, conflicting permissions set are created automatically.

Figure 2 shows the process of the proposed model at a glance. The security admin first assigns the operations to many resources (objects) that may have directory, child directory, and file. An operation is allocated to an object or objects. Then, the conflict of interest is being checked from the hospital database. The hospital has two types of staff: one who deals directly with patients, and second who deals with management only. So, the authorized medical staff (doctors and paramedical staff) are given access to the EMR of patients under the updated RBAC model, whereas the authorized patients also can get access to their records but under updated RBAC that is MDPAC.

Figure 2.

Medical data protection access control model.

The proposed model is implemented in important concepts. The DSD has been implemented at the level of controversial permissions, and the second directory tree structure uses objects to store objects. MDPAC deals with DSD because of the obviously associated permissions. When there are several MEPs having different objects, then there is a need to declare contradictions, this model is applied to implement DSD. The “Dissimilar Objects” means that there are two distinct and unique objects and entities of objects can or cannot belong to a similar object category.

Proposed model description

The DSD is applied to the MEPs, and on the contrary, as the usual normalized roles will be in mutual exclusion (ME) but the external role does not affect ME.

The users can enable all the permissions in this way which do not create a conflict of interest with permission of another role, although they can be allowed under an MER.

The Security Manager announced these types of contradictions as MERs, which create a conflict of interest with the permission of another conflicting role. A complete set of contradictory permissions of the role are made members of the main role of this normalized role. Whenever the user executes permission that belongs to the normalized role, the system brings all the normalized roles into the memory. These are permitted which are conflicting to the targeted permission.

Table 1 discusses the comparative analysis of the state-of-the-art access control models with the proposed model MDPAC. The analysis is done with reference to the advantages and limitations of access control models. MDPAC has a minimum number of limitations which do not affect the security of organizations but other models have severe flaws that lead to security breaches also.

Table 1.

Comparative analysis of access control models.

Model	Advantages	Limitations
Mandatory access control (MAC) model	A security administrator has total control over access thus MAC provides tight security.	MAC does not ensure separation of duty dynamically, least privilege principle, and the implementation of validated reliable components.
Discretionary access control (DAC) model	Access control list (ACL) determines the access toward resources which is based on authentication of the users.	The scalability is very low in the case of big organizations having a large number of resources and subjects.
Role-based access control (RBAC) model	RBAC is rich having tight security of big and complex organizations thereby reducing cost and complexity.	Across extended administrative domain of an organization.
Attribute-based access control (ABAC) model	Additional parameters are added in ABAC that includes resource data, requested data, dynamic data of attributes, that is, machine IP, access time, and so on.	ABAC only implements confidentiality or scalability of data at one time.
Proposed model (MDPAC)	The proposed model implements access control on the basis of conflicting permissions and roles.	Applicable to three levels of role hierarchy only.

MDPAC: medical data protection access control.

Generally, in the case of implementing MDPAC, the organizational needs may vary. MDPAC gives three different artifacts at this point. We recommend that whenever the user attempts to execute a normalized role, there will be a need to check if the user has already executed any other normalized role before or not which will be mutually exclusive to the requested permission. If any of the conflicting permissions from any other normalized role has been activated, then the system does not allow the user to execute the targeted permission. Yumin claimed that an easy way of managing RBAC management should be presented. Its approach to organizing RBAC uses a tree structure. To organize DSD, it is shown that the tree-based data structures reduce the density and administrative efforts at large amount.^9,10

Formal specifications of the proposed model

RBAC has been modeled in ALLOY. ¹⁸ It specifies RBAC as conflict-free. ¹⁹ MDPAC has been formally specified as follows: ²⁰

• TOTAL_USERS, TOTAL_ROLES, NET_PRMS, NET_OPS, and NET_OBS (total number of users, total number of roles, net number of permissions, net number of operations, and net number of objects, respectively).

• $U\_A\subseteq \mathrm{TOTAL}\_\mathrm{USERS}\times \mathrm{TOTAL}\_\mathrm{ROLES}$ , assignment of users to roles in a many-to-many relationship.

• NET_PRMS=2^{(NET_OPS×NET_OBS)}, which denotes the permission set.

• $P\_A\subseteq \mathrm{NET}\_\mathrm{PRMS}\times \mathrm{TOTAL}\_\mathrm{ROLES}$ . This denotes permission role assignment in terms of many-to-many relationship.

• TOTAL _SESSIONS = the session SET.

• OUTER_ROLE = this is a set of non-conflicting permissions which is a subset of a set TOTAL_ROLES

• OUTER_ROLE⊆TOTAL_ROLES

• INNER_ROLE = This is a set of conflicting permissions which is the subset of total number of roles.

• INNER_ROLE ⊆ TOTAL_ROLES

• INNER_RS is set of inner roles.

• session_inner_role(s: TOTAL_SESSIONS)→2 ^TOTAL_ROLES . This is representing TOTAL_SESSIONS “s” on a set of TOTAL_INNER roles.

• Executes = This is a function that executes a certain permission.

• ¬ Executes = This function does not let a user to execute a certain permission.

• Executed = This function returns the Boolean value that the user has already executed a certain permission.

• ¬ Executed = This function returns the Boolean value that the user has not already executed a certain permission.

• M_EXP = This function makes two permissions as conflicting permission.

• M_EX_OP = This function makes two operations as conflicting. Its implementation defines whether this will not be executed against same object, different objects, or both simultaneously.

• IS_PARENT_TO = This function calculates parent–child relationship.

• USER_RQST_EXECUTE = This function is a request from a user to execute a certain permission.

Methodology

The administrator assigns operations to many resources (objects) that may have a directory, child directory, and file. An operation is allocated to an object or objects. Thereafter, an object is assigned to various actions. While allocating the operations in the case of a directory, the administrator mentions the status of assignment to actions affecting all directories, or its effect remains only on the targeted directory. New permissions are created owing to this assignment. The system administrator now allows for several MEPs, according to the two contradictory permissions. Both permissions have different mutually assigned specific objects, but the actions may differ. Therefore, the system stores the information regarding these clearly announced MEPs. ³

Whenever a user requires a role to be activated as permission, the MDPAC model verifies whether the permission is already conflicting with another permission. In such a case, where the MDPAC model does not detect any such permission, MDPAC provides user access. Thus, the MDPAC model will allow the user to execute targeted permissions if another conflicting permission has not been activated. Moreover, in the case of controversial permission already having been activated, the MDPAC model does not allow for the activation of any such targeted permissions. The storage of various items under various directories is illustrated in Figure 3. Three permissions, namely P₁, P₂, and P₃, are created by assigning three operations to directories (Dir.L1.1, Dir.L1.0, and Dir.L2.0), as indicated in Figure 3. The creation of permissions is confined to only those directories in which the inner directories are not affected by this assignment. Thereafter, the administrator creates two permissions, namely P₁ and P₂, as conflicting permissions. ³

Figure 3.

Conflicting permissions due to dissimilar objects.

All directories are treated as objects. Whenever a user desires permission P₁ to be executed, it is determined that it conflicts with permission P₂. Therefore, the MDPAC model determines that a user activates P₂, already having the same object in permission P₂. By assuming that the permission has already been executed by the user, an “Access denied” message is received.

Therefore, the MDPAC model implements DSD exclusively applied to the MEP declaration level, which has a different object. The MDPAC model applies DSD to the controller security administrator, as well as the various permissions declared by an automatic declaration of MEPs. The MDPAC model achieves the automatic assignment of conflicting permissions. The security administration describes the list of contradictions as manual permissions, rather than contradictory. According to the conflicting actions, conflicting permission set is created automatically. The MDPAC model is explained by means of an example. Assume that we are dealing with a management information system that enables different permissions with different users. In Figure 3, items are protected under the tree structure; therefore, when any action is implemented in any directory, objects and directories are immediately promoted. A scenario exists when user U₁ has the role R₁ and wishes to write to File.txt with permissions P₁ and P₂, which indicates the user intention for activating P₁. Figure 4 illustrates the user intention in the Dir.L3 directory.

Figure 4.

Executing conflicting permissions requested by users.

When the system receives permission from the user, the system request for an investigation is a controversial action in the list of conflict-related actions, namely “viewreport.” The system determines that, in its list, the action “viewreport” is known, and there are two conflicting actions, namely “consulting” and “prescribing” as indicated in Table 2.

Table 2.

Conflicting actions list.

No.	Action to execute	Conflicted action
1	Consulting	Updating
2	Prescribing	ViewReport
3	Prescribing	Updating
4	ViewReport	Consulting

Thereafter, the system detects whether any contradictory actions are allocated to the parent directories of the target directory. The system indicates that one of the contradictory processes, namely “prescribing,” is defined as the target directory parent, as illustrated in Figure 4.

Following this confirmation, the system detects whether this permission is allowed in a parent directory of the target directory, by assigning “prescribing” to the user. This system examines P₂, which can be set to the user of the action and object. It is necessary to know the status of the execution of conflicting permissions by the same user.

We enable the conflicting permissions against the active permissions executed by user U₁, as indicated in Table 3. Therefore, after implementing DSD, the required results are obtained regarding MEPs, as opposed to the scenario in which the security manager disputes permission as an MEP manually. Permissions are announced, as the MDPAC model performs optimization in the form of time and efforts for security administrators, where they announce several controversial permissions such as MEPs.

Table 3.

History of activated permissions.

User	Operation	Resource	Activation status
U2	Consulting	Dir.L5.abc.exe	Positive
U3	Prescribing	Dir.L10.xyz.doc	Positive
U1	Prescribing	Dir.L3.File.txt	Positive
U4	ViewReport	Dir.L6.fm.doc	Positive

Checking access

The step-by-step procedure for checking access is described as follows.

• After successful authentication, a user U requests the execution of a certain permission P, which falls under role R.

• The system verifies whether or not the requested user U is eligible and approved to execute the targeted permission. If the authorization test is not performed successfully, the user is not allowed to execute a certain action on a specific object, and an “Access denied” message is displayed to the user.

• However, following a successful authorization test, the system verifies the list of all permissions conflicting with the requested permission, which means it is determined whether it falls under an inner role.

• The first possibility is that the targeted permission is not in conflict with any other permission in the system, in which case the system allows the user access to execute the targeted permission.

• The second possibility is that the targeted permission is found to be conflicting with any other permission, in which case, two further possibilities exist, as follows.

• The first case is that a user did not already execute another conflicting permission, and the system permits any user to execute the targeted permission by granting access.

• The second case is that the user has already executed another conflicting permission, and the system does not allow the user to execute the targeted permission by simply denying access to the user.

Therefore, in this manner, user access is verified regarding the execution of specific permission.

MDPAC model properties

The MDPAC model is characterized by two properties, namely the “soundness property,,” which deals with safety, and the “completeness property,” regarding liveness. The soundness property protects the MDPAC model components and proves that the system does not perform badly. Addressing the completeness property proves the model availability, and a positive outcome is evident. We present these features formally and informally in the following sections.

Soundness property

The soundness property ensures that the system remains safe after implementing the MDPAC model. The soundness property is described formally as follows

$$\begin{array}{c}\forall p1,p2\in \mathrm{NET}\_\mathrm{PRMS},\hfill \\ u1\in \mathrm{TOTAL}\_\mathrm{USERS},r1\&r2\in \mathrm{TOTAL}\_\mathrm{ROLES}\hfill \\ u1\in r1,r2,p1\in r1,p2\in r2,\hfill \\ p1\in r1\_\mathrm{Inner},p2\in r2\_\mathrm{Inner}:M\_\mathrm{EX}\_\mathrm{PRM}(p1,p2)\hfill \\ {}^{\wedge }u1\_\mathrm{rqst}\_\mathrm{EXECUTE}(u1,r1,p1)^\hfill \\ \mathrm{EXECUTED}(u1,r2,p2)\Rightarrow \neg \mathrm{EXECUTEs}(u1,r1,p1)\hfill \end{array}$$

The user may be outside the role of any authorized permission, without any restrictions, which may be carried out without any restrictions or trials. If certain permission that conflicts with any other permission is requested to be activated, the conflicting permission must not be activated by the same user.

Completeness property

This property ensures that, if a user wishes to execute certain permission, this permission is not in a state of conflict with other permission

$$\begin{array}{c}\forall p1,p2\in \mathrm{NET}\_\mathrm{PRMS},\hfill \\ u1\in \mathrm{TOTAL}\_\mathrm{USERS},\hfill \\ r1\&r2\in \mathrm{TOTAL}\_\mathrm{ROLES},\hfill \\ u1\in r1,r2,p1\in r1,p2\in r2,\hfill \\ p1\in r1\_\mathrm{Inner},p2\in r2\_\mathrm{Inner}:\hfill \\ M\_\mathrm{EX}\_\mathrm{PRM}(p1,p2)\hfill \\ \hat{u}1\_\mathrm{rqst}\_\mathrm{EXECUTE}(u1,r1,p1)^\hfill \\ \neg \mathrm{EXECUTED}(u1,r2,p2)\Rightarrow \hfill \\ \mathrm{activates}(u1,r1,p1)\hfill \end{array}$$

The completeness property is formally described as given earlier. If a conflict of interest is created with another permission, and that permission has not been executed by the same user, access should be allowed to execute such permission.

Results and discussion

The proposed model is proved to be efficient, dynamic, and secure as compared to other authorization models. This model implements the behavior of mutual exclusion at the permission level instead of the role level. The results are compared to the state-of-the-art access control models that include mandatory access control (MAC), discretionary access control (DAC), attribute-based access control (ABAC), and RBAC models as shown in Figures 5–7. The proposed model outperformed as compared to the state-of-the-art access control models.

Figure 5.

Proposed algorithm execution time against hierarchy levels.

Figure 6.

Algorithm memory consumption time against hierarchy levels.

Figure 7.

Algorithm CPU cycle consumption against hierarchy levels.

In Figure 5, the results of the execution time of the proposed model are compared with other models. MDPAC takes lesser time to execute as compared to the state-of-the-art algorithms which show the efficiency of the proposed algorithm.

The proposed algorithm is implemented on various hierarchy levels. The more resources are required as we move more in-depth to the hierarchical levels. When we compared the results of the proposed algorithm with other state-of-the-art algorithms, the proposed algorithm consumes fewer resources as compared to others.

In addition, due to the simple logic of the proposed model, the execution time is lesser as compared to the other models. MDPAC is proved to be dynamic, efficient, and usable as compared to other state-of-the-art algorithms. Figure 6 shows the comparison of memory consumption of MDPAC with other algorithms. It performed better as compared to the other algorithms. Figure 6 shows that MAC and proposed model remained close to each other but still MDPAC outperformed among all state-of-the-art algorithms.

Figure 7 compares the consumption of CPU cycles by MDPAC with other state-of-the-art algorithms. It shows that the proposed algorithm is again found better in consumption of this resource. This time again MAC and proposed algorithm remained close to each other.

Conclusion and future work

The MDPAC model gives authority to security administrator to assign users to roles, permissions to roles, and actions to objects or resources. The administrator assigns various categories of patients to medical staff including medical doctors and nurses. The medical staff then accesses the EMR to prescribe medicine and clinical tests, view clinical test reports, and discussion of the reports with other specialized medical staff with the consent of patients. All this access is granted based on MDPAC where RBAC is working underlaying. All the updates are stored in the hospital database. Only the authorized medical staff will be able to access the patient data. The patients are also able to access their own data through remote monitoring or telemedicine in the environment of the IoT.

The critical patients can be monitored remotely from anywhere by the hospital medical staff. The senior medical staff can have the authority of junior medical staff in the case of emergency if the senior medical staff has been assigned to a higher authority role. MDPAC has been proved to be an efficient, dynamic, and usable system. It has been compared with state-of-the-art algorithms and found efficient in terms of CPU cycle consumption, memory consumption, and algorithm execution time. Based on these parameters, MDPAC has proved its significant impact on the access control in terms of security and easiness.

The proposed model inherits actions from the parent directory. For future works, this is a good point to start from. A limitation of the proposed model is that copying and moving the directory resource is not incorporated in this model. Whenever a copy or directory movement takes place the action assignment should also have to be updated. It is a good point to continue with this research in the future.