Advertisement

Neural Computing and Applications

, Volume 29, Issue 10, pp 887–901 | Cite as

A novel multilayer AAA model for integrated applications

  • Afshin Rezakhani
  • Hossein Shirazi
  • Nasser Modiri
Original Article
  • 116 Downloads

Abstract

Nowadays, one of the problems in current authentication, authorization and accounting (AAA) model is lack of accurate roadmap of access management in integrated applications based on operational needs. In the current systems, attributes are used as effective parameters of AAA in static form. We want to present that, in order to have an efficient AAA model, we should consider AAA requirements via multilayers security policies. In this paper, a comprehensive approach is represented which defines designing AAA not only for operational and implementation level, but also in the enterprise level. In this regard, the proposed model provides all security requirements for the establishment of appropriate application-level AAA. Some of these requirements must be obtained from regulations and threat modeling, and some of other are calculated by business processes and also operational levels. According to proposed multilayer approach, the evaluation must be considered in several dimensions. So, we’ll evaluate several aspects of the proposed model. The results show that the proposed model covers many security requirements as well. It can also be useful to enhance the information security in integrated applications.

Keywords

AAA Multilayer security policies Integrated applications Regulations 

1 Motivation

Access control is defined as the act of determining whether a particular privilege can be granted to the requester of a particular credential. The privilege can be right of access to a resource, such as a communications link, an information database, a computing machine or many other things owned by a network or service provider. The presenter of the credential can be either a device or a user [1]. AAA model is arguably the most fundamental and the most pervasive security mechanism in use today. AAA model can take many forms. In addition to determining whether a user has rights to use a resource, the AAA system may constrain when and how the resource may be used. For example, a user may have access to a network only during working hours. Some organizations may establish more complex control, such as requiring that two staff members conduct certain high-risk operations such as opening a vault or launching a missile. Access control is only one aspect of a comprehensive computer security solution, but it is one of the most visible one. Every time a user logs on to a multiuser computer system access control is enforced [2]. A business process is a combination of structured activities to achieve a specific purpose. A business process is a set of several related activities that accomplish the specific goal of enterprises.

One of the challenges that current AAA models suffer from is the lack of comprehensive vision of threats in AAA applications and lack of attention to the regulation as well as the lack of attention to business processes. In current models, there is no consideration to the requirements at the enterprise and potential threats that enter to AAA models have not been studied. In this paper, a new approach is proposed to deploy an accurate and efficient AAA for integrated applications. For this purpose, a multilayered approach is proposed. In each layer, a series of security requirements that are essential for AAA in applications are proposed and security policies have been developed for them.

2 Related works

This section explores some of the related previous works. Discretionary access control (DAC) confines access of resources inside of the group of users to which they belong. A user or subject, who is given a discretionary access to a resource, is prepared to do passing the access to another subject. This model receives the idea of user ownership [3]. One of the basic models in DAC is Lampson access control model. The access of domains to objects is determined by the access matrix. Its rows are labeled by domain names and its columns by object names [2]. Another DAC model is take-grant protection model (Schweitzer et al. [4]) that is a formal model utilized as a part of computer security to set up or discredit the safety of a given computer system that follows particular rules. It demonstrates that for particular system the topic of safety is decidable in linear time, which is in general undecidable. Mandatory access control (MAC) model [3, 5, 6] can be characterized as a method for restricting access to resources based on the sensitivity of the information contained in it and the authorization of subjects. Some MAC models such as Biba [7], BLP [8] and Dion [7, 9] take a hierarchical procedure to control access of resources or data based on information sensitivity. The RBAC model characterizes sets of fundamental RBAC components (i.e., users, roles, permissions, operations and objects) and relations as types and capacities that are incorporated in this standard. The RBAC reference model serves two needs. First, the reference model characterizes the extent of RBAC components that are incorporated in the standard. This model recognizes the minimum set of components incorporated in all RBAC systems, parts of role hierarchies, aspects of static constraint relations and aspects of dynamic constraint relations. Second, the model gives an exact and predictable language, as far as component sets and capacities for using in characterizing the useful specification [10] some of the extended models based on RBAC are temporal RBAC [11], risk-aware RBAC [12], budget-aware RBAC [13] and task bases access control [14]. The idea of attribute-based access control (ABAC) has existed for a long time. It shows a point in the space of access control that incorporates access control list, role-based access control, and the ABAC model for giving access based on the evaluation of attributes [15]. An extended attribute-based access control model with trust and privacy [16] is one of the extended attribute base access control models. The risk-adaptive access control (RAdAC) model was contrived to bring real-time, adaptable, risk-aware access control to the enterprise. It stretches out upon other prior access control models by presenting environmental conditions and risk levels into the access control decision, notwithstanding the concept of “operational need.” It consolidates information about a human user (or machine’s) dependability, information about the corporate IT foundation, and environment risk factors and utilizes all pieces of information to make an overall quantitative risk metric. RAdAC also utilizes situational components for the decision making [17]. An attribute-based framework for risk-adaptive access control models [18] develop a novel approach to capture characteristics of RAdAC using attribute-based access control. Mr. Zhang is presented his doctoral dissertation at the University of Goerg Mason of America with title of role-based access control and organization role in 2008 [19]. From his point of view about role-based access control, roles determined based on functions in the organization usually. Traditional RBAC is not extensible in scale security policies in different organizations. To resolve this problem, a family of widespread RBAC model is defined as access control model based on role and organization and it is presented as original model in this thesis. In thesis written by Zhao in 2008, the model used for access control is role-based access control in which changes have been made [20]. The purpose of this thesis is providing security policies, security of access control and security mechanisms and their integration in role-based access control model. Other research conducted in Colorado University [21]. Access control in traditional models such as mandatory access control (MAC), discretionary access control (DAC), and role-based access control (RBAC) does not function well in this scenario for some reasons. So, new models and access control technologies are needed for application of pervasive computing. Another research in access control field has been done in Purdue University of America [22]. Computing environments is turned in forms of pervasive, and need to strong and flexible system has been increased. Another activity which is studied in this part is done [23]. From his point of view, role-based access control (RBAC) has turned to today access control model and has placed many theoretical and practical aspects in itself. The next thesis which has been studied is done in Toronto University [24]. He discussed about role-based access control and dynamic separation of duties. RBAC is working on activation the roles and help users’ permissions to restrictions. Next thesis discussed about what is prepared at Kevin University by Salim in relation to access control system. In the point of view of the author of this thesis is systematic access control that people access to information to their need is prepared [25]. Try of this thesis is whenever a user with unclear dependency has a request to resource what mechanism is used to manage the access.

3 Proposed approach

One of the issues that should be considered in AAA model is developing access control policies in different layers. AAA policies in applications can be implemented in best way if these policies are discussed at various layers in the enterprise and a specific methodology is developed to satisfy them. The suggested layers are illustrated in Fig. 1.
Fig. 1

AAA policies in different layers

AAA policies in order to strict execution in integrated applications should be considered in different layers. Enterprise-level policies will be essential for expressing AAA policies at organizational layer. These policies will be required to meet the security requirements including regulation, high-level policies and threat modeling. At second layer, business processes will be considered and issues such as hierarchical work breakdown structures (WBS), business processes, security requirements and appropriate models for processes will be discussed. In other words, the processes of systems are determined, and after definition of security requirements for each process, an appropriate access model is chosen for them. On the third layer (operational), AAA policies which will be closer to the applications will be defined. Policies in this layer are considered in order to satisfy the higher-layer policies. These policies include defining security requirements and AAA policies at the methods existed in applications classes. Also some structures to express policies and meta-policies are determined in this layer. Policies at fourth layer (implementation layer) include the rules to implement access control and also creating standard languages to express policies which are executable in the applications. In this layer, some issues such as the definition of rules, policies and policy sets are raised. Conflict detection among these and combination algorithms in the case of conflict are such discussing issues in this layer. The considerable issues in each layer are shown in Fig. 2. We accurately discuss these layers in the next subsections.
Fig. 2

Proposed multilayer AAA model for applications

3.1 Enterprise layer access control

In this section, we consider the essential requirements for AAA in applications at enterprise layer. Some of the main goals of this layer are creating the basic structure and main modules of AAA at application. Also some strategies in best practices such as ISMS and COBIT can be discussed in this layer. Finally, expression of threats in AAA systems and policies in order to reduce these threats is some of other important considering issues in this layer.

3.1.1 AAA regulations

The regulations should be considered carefully before creating AAA for integrated applications. In fact, these regulations describe the AAA roadmap in applications design and offer more strategic guidance for AAA establishment in the application. An example in these regulations includes minimum security requirements for federal information systems provided specific rules for AAA [26, 27]. In this section, the regulations for the applications will be discussed. As we know, systems have different regulations in various areas which in AAA scope are proposed as follows:
  • Application credential management

  • Application identification and authentication management

  • Application authorization management

  • Qualifying system

  • Users credential and assignment management

3.1.1.1 Application credential management

According to National Institute of Standards and Technology Special Publication 800-63 [26, 27], a credential is “an object that authoritatively binds an identity (and optionally, additional attributes) to a token possessed and controlled by a person.” Therefore, all existing applications must be enrolled. Each application must have the sufficient permissions in the enterprise to having execution capability. Its means of a credential must be maintained over its life cycle which might include enrollment, re-enrollment, expiration or suspension. So, any application that is required to run in the enterprise should be placed in the application credential management process and its’ specification should be enrolled. In addition to enrollment of all application, some procedures in order to re-enrollment in application will be defined. Expiration process in the application is another important issue that should exist and specifies the expiration conditions of application. Finally, an application may be suspended based on specific policies. Therefore, a life cycle for maintenance of the application activities should be developed which any application’s activity is managed in this cycle.

3.1.1.2 Application identification and authentication (I&A) management
Identification and authentication are two main dimensions in AAA systems. Identification is an operation that users utilize to introduce themselves in applications and is usually in the form of a username. In the other hand, authentication is a process of acquiring or verifying the claimed identity. Authentication is first step in the process of entrance to the applications. Therefore, having a reliable server to determine the identity and access management is required. The proposed application I&A is the management of identities based on the NIST model [29] which has been developed based on the business processes. The applications I&A management that emphasizes on the PKI structure is shown in Fig. 3.
Fig. 3

Applications identification and authentication management

According to many of the frameworks, the proposed I&A management framework is based on specification of identity policies at various levels. Identity management policies at different levels can be used as roadmap of I&A management system. Because of in all systems, AAA requirements are defined according to the running processes, so the business processes are considered at the highest level of I&A management that provide a dynamic view in identity management. Processes and security requirements for each of them make a significant mapping between processes and the method of I&A. In other words, according to security requirement in business processes, appropriate identities will be diagnosed for users.

Identity registration and proving are two important parameters at the second level which includes processes to register an identity and the process of proving the identity. The token management is considered in the next level that contains determining appropriate software/hardware tokens for business processes, key generation and so on. Finally, the fourth layer will be managing the development and implementation of various tokens including required protocols, development mechanism and assessment mechanism. The token authentication feature allows developers to secure the authentication mechanism by protecting it with a temporary authentication access. This feature increases the security to the network by providing a time-bound access without revealing the password to the login user [28]. According to Hastings and Franklin [29], the following provides guidance for selecting tokens in public safety scenarios and is divided into user authentication, remote user authentication and remote device authentication. The type of authentication solution employed by an organization should be commensurate with the amount of risk posed to a particular information system. This solution should also be compatible with an organization’s existing or developing IT infrastructure. Token types based on their categories are considered in Table 1.
Table 1

The token types in applications I&A

 

Purpose

Explanation

Token types

1

Local user authentication

Local authentication occurs when a user inputs a PIN or uses a biometric reader (e.g., sensor for reading fingerprints, camera for iris scanning, microphone for speaker authentication) to access their mobile device, typically granting access past a lock screen

PINs, passwords, and gestures

Physical tokens

Biometrics

2

Remote user authentication

Passwords, smartcards and biometrics can be used for remote user authentication for mobile devices. Remote authentication differs from local authentication in that many untrustworthy entities exist between the user and the entity performing verification. It is common for remote authentication protocols to send information over an untrusted network

PINs, passwords and gestures

Biometrics

One-time password devices

Attached contact smartcard reader

NFC smartcard

Application cryptographic tokens

Removable hardware security modules

Embedded hardware security modules

3

Remote device authentication

Remote device authentication will be the method of authentication mobile devices use to gain access to the nationwide public safety broadband network (NPSBN). Application and hardware tokens can be leveraged for remote device authentication and used in a manner similar to remote user authentication

Similar to remote user authentication

3.1.1.3 Application authorization management
To have proper AAA for the integrated applications, it is needed to manage the accessibility to the resources such as menus and databases, and these accessibilities should be modified in accordance with the needs of the managers. In this regard, it is suggested that the policies are specified based on attribute-based AAA model. The managers define the accessibility permissions based on the attributes in the applications. The architecture of the access management systems based upon ISO 10181 [30] is shown in Fig. 4.
Fig. 4

Access control architecture

As displayed in this figure, to give the accurate permission to the requesters, it is needed to utilize the shown procedure to have the management on the resources. To manage the requester’s access, it is needed to send the request to policy enforcement point (PEP). This unit is provided based upon the response to the policy decision point (PDP), as the user interface gives the logical response to the requester. PDP decides by two main units of policy administration point (PAP) and policy information point (PIP). In PAP, all the policies are written by the owners and this unit plays the role of user policies knowledgebase. Another unit, Policy Information Point should exist beside PDP for decision making that determine the attributes of the requester. In fact, PDP gives the permission of accessibility based upon the policies in PAP and the information in PIP.

3.1.1.4 Qualifying-condition management

A qualification is either a condition that must be met or a statement that puts a limit on a claim. Both kinds of qualification are restrictive. Qualifying-condition module consists of all situations that roles are defined according to them. These roles can include multiple attributes. For example, a role can be defined for all of users as: “The commander of a battlefield is defined as all users in a location1 that their degree is higher from a threshold1.” Therefore, all roles and conditions that are needed in the application should be defined and managed.

3.1.1.5 Users credential management
According to FICAM [31], credentialing generally involves five major components. First, an authorized individual sponsors an individual or entity for a credential to establish the need for the credential. Then, an individual enrolls for the credential, a process which typically consists of identity proofing and the capture of biographic and biometric data. The types of data required may depend on the credential type and the usage scenario. Additionally, this step may be automatically fed based on authoritative attribute data collected and maintained through identity management processes and systems, since enrollment for a credential requires much of the same data collection that is required as part of identity management. Subsequently, a credential must be produced and issued to an individual. After defining roles and users, a mechanism for assigning users to their roles should be defined. Upon registration and receiving credential, according to situations one or more roles will be added to users profile dynamically. This profile will be important for user access permission. Finally, a credential must be maintained over its life cycle, which might include revocation, reissuance/replacement, re-enrollment, expiration, PIN reset, suspension or reinstatement [31]. Thus, the steps in creating users’ credential are shown in Fig. 5.
Fig. 5

Creating users credential

3.1.2 AAA in best practices

Best practices can state the best recommends based on practical experience in the field of information security in all aspects. AAA can use these experiences as a strategic guidelines for implementation of AAA system. Some of these best practices are as follows:
  • ISO 27000 AAA guidelines

ISO 2700X standard can be applied to the enterprises with different scales [32]. Many enterprises evaluate their information security risks and then implement appropriate control according to their needs by using ISO 2700X guidelines. ISO 27005 controls to access management are given in Table 2.
Table 2

AAA guidelines in ISO 27000

ISMS access control controls

9.1.2 Physical entry controls

9.1.3 Securing offices, rooms, and facilities

11.1 Business requirement for access control

11.2 User access management

11.4 Network access control

11.5 Operating system access control

11.6 Application and information access control

12.4 Security of system files

  • COBIT AAA guidelines

COBIT provides a comprehensive framework that assists enterprises in achieving their objectives for the governance and management of enterprise IT. Simply stated, it helps enterprises create optimal value from information technology (IT) by maintaining a balance between realizing benefits and optimizing risk levels and resource use. COBIT 5 enables IT to be governed and managed in a holistic manner for the entire enterprise, taking into account the full end-to-end business and IT functional areas of responsibility, considering the IT-related interests of internal and external stakeholders [33]. Thus, the COBIT can be used in the management of AAA strategies which is shown in Table 3.
Table 3

AAA guidelines in COBIT

COBIT 4.1 Control objectives in access control

DS5.2 IT security plan

DS5.4 User account management

DS11.3 Media library management system

DS11.6 Security requirements for data management

DS12.2 Physical security measures

DS12.3 Physical access

AI7.6 Testing of changes

  • ITIL AAA guidelines

As we know, ITIL is a set of experiences of successful managers in information technology companies and organizations in worldwide that is designed to manage IT infrastructure in order to get the best value from them by understanding that what roles, policies, strategies, processes and functions should be considered. In fact, ITIL is a framework that is obtained of best practices and has been collected under APMG management [34]. Thus, the key performance indicators of ITIL in information security and specially access management should be specified that is shown in Table 4.
Table 4

AAA guidelines in ITIL

 

ITIL access control controls

SO

Appendix F: Physical access control

SO

4.5.4 [Access management] policies/principles/basic concepts

SO

4.5 Access management

6.6.9 Access management roles

Appendix F: Physical access control

SO

5.5 Network management

5.8 Directory services management

SO

7.6 Access management

SO

6.5 Application management

SO

4.3.4.3 Configuration management system (definitive media library)

4.5.4.9 [Service validation and testing] design considerations

3.1.3 Threat modeling

Threat modeling is an approach to applications security analysis. This type of modeling is a structured approach that enables designers to detect, assess and correct the risks associated with the applications. Threat modeling is based on the view that any system or organization has valuable resources and assets that exposed to internal and external threats. However, according to the threats, security countermeasures can be created to reduce their effects. Therefore, we should be able to create use cases and misuse cases, and then, the security policies can be made. Using misuse cases/abuse cases can be useful in reducing the threats on AAA plugin. In this part, threat modeling is utilized to improve the security of AAA plugin. The proposed model in this layer is classified into misuse and abuse in detecting the threats. The abuses are insider and misuses are the outsider threats.

3.1.3.1 Specific insider threats
An insider threat is a malicious threat to an organization that comes from people within the enterprise, such as employees, former employees, contractors or business associates, who have inside information concerning the enterprise’s security practices, data and computer systems [41]. This category of threats is created by insider users in the enterprise and can be intentional or unintentional. Insider threats that are also known as abuse can have tremendous effects on AAA plugin. We propose to classify the abuses on AAA plugin as follows:
  • Suppressed attributes

The XACML language is used in data-centric-level AAA. This language is based on ISO/IEC 10181 and introduces blocks for AAA management. These blocks include PEP, PIP, PDP and PAP. PDP makes the suitable decision based on comparing the requester attributes and policies existing in the PAP. Sometimes requester attributes are not recognizable for PDP. In such cases, PDP may make the wrong decision. In this case, it is said that suppression of attributes has occurred. In this case, for some reasons, PDP is not able to identify the attributes of the subject. Of course, here the emphasis is on those factors that cause threat from inside of the enterprise. Some the insider factors that are able to affect the incidence of these threats are tools and technologies used to create the privacy in the applications. The privacy engineering technology does not allow publishing the user attributes. From this perspective, the threat in the AAA plugin is an abuse.
  • Decentralized policy

The structure provided by XACML allows decentralized access management. This means that it is possible to use the decentralized repositories for AAA policy specification based on the physical location of the users. Sometimes decentralized policies might create conceptual conflicts. This type of conflict can cause unauthorized access. For example, suppose that based on policies of computer department, the access of group assistants to changing information is unauthorized. However, based on the policies of physic department, group assistants are authorized to access the same information. Now, if the two departments are merged, policy conflict is caused and it leads to unauthorized access. This type of threat that is caused by decentralized management is abuse.
  • Not applicable result

Not applicable result occurs when the PDP based on the attributes obtained for a subject cannot assign a policy to it. In this case, it is said that the result of the AAA plugin is not applicable. Many applications convert the not applicable result to permit. This means of if no policy is found for the requester, the AAA system gives permission authority to the requester. This type of conversion is a threat that can cause unauthorized access that is a kind of abuse. The reason for classifying the threat as an abuse is that they are created by the insider weaknesses.
  • Role hierarchical violation

As we know, role-based access control (RBAC) is defined at different levels. An RBAC that can support inheritance hierarchy in the roles is called RBAC1. Sometimes inheritance of one or more roles might be done wrongly due to the insider user mistakes and lead to unauthorized access. This wrong inheritance is an insider threats and abuse. For example, suppose the role R3 inherits R2 instead of inheriting the role R1. This wrong inheritance has two devastating result. First R3 will have all unwanted authorities of R2. At second, it cannot adopt R1 authorities.
  • Constraints violation

Obviously, in RBAC model the constraints are significant on RBAC2. There are various type of constraints defined in AAA. For example, assume that the role R1 is authorized to modify T1 only when there is a new request. Current RBAC model authorizes R1 to modify T1, but it is unable to apply the constraint based on a new request. So, many constraints are not applied in RBAC and this creates an abuse to the system.
3.1.3.2 Specific outsider threats
In this section, the outside threats applied on AAA plugin are considered and classified. This type of threats is called misuse that can play a very destructive role in the performance of applications AAA plugin. Different types of misuse threats in the proposed model are as follows.
  • Suppressed attributes

As was seen in the previous section, suppression of attributes is a kind of insider threat. Here it is mentioned that this threat can also be utilized by outsiders on the AAA plugin and considered as a misuse. Sometimes the lack of identifying subject attributes is not due to inside reasons and depends on the outsider causes. Among the factors that cause outsider threats are denial of service (DOS) attacks to repository that disables their services. Failure of the servers that maintain the attributes of the subjects causes the PDP not to be able to receive the necessary information to make suitable decisions.
  • Unauthorized disclosure

XACML as a default has no plan to maintain confidentiality in the communications between the actors and the AAA plugin. This threat is a misuse and can cause problems in the AAA plugin or lead to unauthorized disclosure between the actors.
  • Message replay

A different kind of misuse threats created by outsiders is message replay. Adversary subjects can save requests and replay them at the time of the attack.
  • Message insertion

In this type of threat, the outsider hostile person sends the messages among the valid messages between the actors and causes various problems.
  • Message modification

In this type of threat that is considered as misuse, adversary subject can take special action to modify the messages between the actors. This type of threat is very dangerous because the hostile person can convert deny decision to the permit.
  • PDP DOS

Another outsider threat utilized on AAA plugin is attacking the PDP. In this type of threat, the adversary outsider user through the applications executed in the enterprise tries to send a lot of messages to PDP through various loops which are considered a DOS attack. Given that this threat can be organized by people outside of enterprise, it is a misuse and causes failure of the PDP.
3.1.3.3 Public threats
In addition to the specific threats that are designed for AAA plugin, some threats are applied as public threats. Some of the significant threats are defined based on Table 5.
Table 5

Public threats in AAA plugin

ID

Vulnerability specification

1

A1 Injection

2

A2 Broken authentication and session management

3

A3 Cross-site scripting (XSS)

4

A4 Insecure direct object references

5

A5 Security misconfiguration

6

A6 Sensitive data exposure

7

A7 Missing function-level access control

8

A8 Cross-site request forgery (CSRF)

9

A9 Using components with known vulnerabilities

10

A10 Invalidated redirects and forwards

3.2 Business process layer access control

The second layer in the proposed AAA model is determining the access control requirements in the business process layer in the integrated applications. In this layer, the main subsystems should be identified in a hierarchical structure. Determining subsystems can help to create dynamic AAA policies. Each subsystem includes a number of processes that a flow diagram can be considered for them. The AAA model is not similar at all processes necessarily, since the security requirements may vary in each process. Thus, we are facing a variety of security requirements at the process layer that must be managed in such a way that an appropriate AAA model is selected for each process. In this layer, security requirements have been considered and appropriate AAA model is suggested. AAA model is not necessarily identical in each process and dynamically specified according to processes security requirements. This approach addition to reducing security risk causes a dynamic AAA in applications. The following concepts will be important:
  • WBS hierarchical structure in the system

  • Determination of business processes for each subsystem

  • Determination of security requirements for each process

  • Determination of appropriate access control model for each process

Therefore, as shown in Fig. 6, an appropriate AAA model for each process is selected based on three key factors: security requirements, AAA models and business processes. In other words, for each business process the specific security requirements is reviewed, and according to them, a proper AAA model is proposed. As an example in a specific application, the security requirements include consideration of requester name and also requester role. In this case, role-based AAA model is selected to appropriate access management.
Fig. 6

Selecting the appropriate access control model

3.3 Operational layer access control

As was seen in the business layer, according to security requirements in the business processes, an appropriate access control model was selected. In the operational layer, information domain(s) related to each process should be determined. For the determined information domain(s), domain objects and application-level operations (methods) will be developed. In this layer, activities are handled by information domains such as .Net namespaces. Thus, each activity consists of one or more namespace for its functionality. We map activities to information domains and also map tasks to classes (domain objects), and objects are utilized for handling the tasks. In the methods of classes, access is managed and controlled.
In addition to the discussed cases above, the requirements that AAA model needs at this layer for policy making are expressed. Policies and meta-policies are also defined (the meta-policies are developed accordance with policy management). For example, we can express some meta-policies such as date of creating policy, date of affectivity, modification date and date of policy expiration. The set of requirement and policies is shown in Table 6.
Table 6

Policy and meta-policy components in operation layer

Policy levels

Type of policy

Comment

Policy requirement

Policy components

Operational policy

NLP

Operational level natural language policy

Pertinent policy in local level

Operational situation

Pertinent policy in global level

Local situation

Local security risk

Local operational need

Subject attributes

Resource attributes

Environment attributes

Process attributes

Activity attributes

Privilege attributes

MP

Operational level meta-policy

Policy definition authority

Policy effective condition

Policy update condition

Policy revocation condition

Policy author

Combination security risk and operational need

Deconflict methods

Policy effective date

Policy update date

Policy revocation date

Attribute priorities

3.4 Implementation layer access control

The lowest layer of the proposed model is the layer of policies implementation. In this layer, based on high-layer policies, executable AAA policies will be created in the applications. Some issues which are relevant in this layer are as follows:
  • Policy sets, policies and rules

In the implementation layer of proposed AAA model, policies are defined in a number of policy sets. Each policy set includes a number of policies, and also each policy is introduced through a number of rules. The proposed language to express the above-mentioned cases is XACML that is standard markup language for expressing AAA policies.
  • Conflicts detection and combination

The important step applied in policy management is detection the conflicts between rules, policies and policy sets and making necessary decisions in case of conflicts. For this purpose, we must search the rules and analyze them and detect their conflicts. Conflict is diagnosed when there are two or more rules that the set of all attributes which are the same, but one rule issues the access permission while the other one does not. The important point is that after conflict rule diagnosis, the conflict between policies should also be found, and finally, the conflict between policy sets is also detected. As it can be observed, conflicts are discovered in three stages. Following the discovery of any conflict, the combination algorithm must be applied on them. This combination algorithm depending on the higher-level policies can be selected among the strategies such as permit override, deny override and first applicable [35].

4 Evaluation

Evaluation of the proposed method is multimodal which consider in several levels. We consider diversity of evaluation metrics in several levels consist of enterprise, business, operational and implementation level. First, we consider the functionality of access authority at data-centric level. Also its vulnerabilities from the perspective of threat modeling and then policies to reduce the threats will be applied. Acunetix tool for monitoring threats and observations reduction of these threats are used. Finally, a formal evaluation will be done by using Alloy model checker.

4.1 Abuse case and misuse case diagrams

As we know, threat modeling is an important part of application security testing. For having secure application, the threat modeling is used to find security vulnerabilities. At first, the processes required for access authority at data-centric level are determined, and then, their abuse and misuse cases are plotted. In the case study, access authority process in data-centric level is developed. Misuse case is a business process modeling used in the software development industry. The term misuse case is derived from and is the inverse of use case. In misuse and abuse case diagrams, it is possible to present the threats and solutions to reduce the threats along with the functionalities of AAA plugin. The abuse and misuse case diagrams of the above-mentioned scenario are discussed in Figs. 7 and 8.
Fig. 7

Abuse case diagram in data-centric-level AAA

Fig. 8

Misuse case diagram in data-centriclevel AAA

4.2 Vulnerability detection and reduction

Acunetix is one of the most popular security testing tools to monitor Web application and has been introduced as one of the best vulnerability detection applications. Acunetix provides warnings based on access to malicious purposes in the following four levels:
  1. 1.

    High: is the highest level of vulnerability which is very dangerous and gives an attacker full control on application.

     
  2. 2.

    Medium: the level of vulnerability is less than the previous one, but there is still the possibility of controlling application.

     
  3. 3.

    Low: has low risk and normal hackers cannot access to the application.

     
  4. 4.

    Information: is a warning to prevent stealing information.

     
Now, by using this tool, we examine the vulnerabilities in the discussed case study. Policies in order to reduce the vulnerabilities will be applied and then will re-examine vulnerabilities on AAA plugin. The results are shown in Fig. 9. As can be seen by enforcing security policies, the vulnerabilities which are explained in Sect. 3.1.3.3 are reduced significantly. This means that the AAA plugin should be able to reduce its potential threats.
Fig. 9

Threat levels

4.3 Formal verification

To create significant formal verification, a special scenario should be defined to express proposed approach and see the results. Field manual (FM) is set of definitions and detailed developed instructions which are considered for different military missions. This set can be used in determine business processes and activities in missions. One scope in an aerial C4I system is processes scenario which explains air assault operation. In this regard, according to FM 3-90, the process which is shown in Fig. 10 is defined in an operation air assault in business layer [42].
Fig. 10

Business process in operation air assault scenario

In FM 3-90 field manual, the goal is that some airplanes backed by attack helicopters gather some of military forces with equipment and their war stuffs from one area and descend them in a suitable place. Then, these forces (backed by the helicopters) do their entrusted mission on enemy targets. So, in this way five-state business process is defined. In the first state of this business process, there is planning of the operations staging which includes planning mission and selection routes to achieve plane loading area. Second state of process is loading planning in which loading area is specified and planes and attack helicopters are ready to move after control and support of aerial part and pick up people and military equipment. Third state includes planning of air movement which includes routing to the destination and supporting of planes. Fourth step is landing planning which includes selection of landing area and supporting attack helicopters to recognize exit way of the area. Finally, fifth state of business process includes tactical planning which includes commander intentions, battle organization, fire and its effect and attack helicopters supporting.

It is used Alloy model checker to formal verification of this approach in above scenario. Alloy design is done by application design group of MIT University by leadership of Jackson [36]. Alloy checker model has different application areas such as switching design in telecommunication networks, finding security holes and access control. One area in which Alloy offers particular advantage over model checkers is for analyzing systems with configurations that are underdetermined or that can change dynamically. So, we utilize it for checking the counterexamples in our proposed model. In the above scenario, we are defined specific rules and policies, and then, the conflicts in proposed model are checked. Commands for defining the targets and policies are shown in Table 7. As it is seen, we suggest defining the flows as processes and also the states as activities besides target elements.
Table 7

The alloy commands for process-driven policies modeling

Scope

Commands

Target definition

abstract sig Target {

  subjects: set Subject,

  resources: set Resource,

  actions: set Action,

  flows: set Flow,

  states: set State

}

Rule definition

abstract sig Rule {

  ruleTarget: one Target,

  ruleEffect: one Effect

}

Policy definition

abstract sig Policy {

  policyTarget: one Target,

  rules: set Rule,

  ruleCombiningAlgo: one CombiningAlgo

}

Policy set definition

abstract sig PolicySet {

  policySetTarget: one Target,

  policies: set Policy,

  policySets: set PolicySet,

  policyCombiningAlgo: one CombiningAlgo

}

After modeling the rules and policies according to above scenario, it is the time of verification and finding conflicts between rules and policies. In determining the existed conflicts in the rules and policies, processes act as a discriminator and it causes to solve wrong conflicts problem in older models. At below, instructions are shown to consider rules and policies conflicts. So, we show the needed functions [37] to detect conflicts between rules and policies in Table 8. As can be seen, the assertions of RulesConsistency and PoliciesConsistency are used to detect inconsistencies between rules and policies. This is done by calling other required functions such as InconsistentRules and InconsistentPolicies. With running the RulesConsistency assertion, by command “check RulesConsistency”, the counterexamples between the defined rules are detected.
Table 8

The Alloy commands for process-driven policy validation

Scope

Commands

Elements match predicate definition

pred elementMatch(e1: Element, e2: Element){

  all a2: e2.attributes.Value

    {some a1: e1.attributes.Value

     {a1 = a2 and a2.(e2.attributes) in a1.(e1.attributes)}}

}

Targets match predicate definition

pred targetMatch (t: Target, r: Request) {

  some e: t.subjects | elementMatch[r.subject, e]

  some e: t.resources | elementMatch[r.resource, e]

  some e: t.actions | elementMatch[r.action, e]

  some e: t.flows | elementMatch[r.flow, e]

  some e: t.states | elementMatch[r.state, e]

}

Rule response function definition

fun ruleResponse (r: Rule, req: Request): Effect {

  targetMatch[r.ruleTarget, req] => r.ruleEffect

  else NotApplicable

}

Policy response function definition

fun policyResponse (p: Policy, req: Request): Effect {

  targetMatch[p.policyTarget, req]

  => ruleCombinedResponse[p, req]

  else NotApplicable

}

Inconsistent rules predicate definition

pred InconsistentRules (p: Policy, req: Request) {

        some r: p.rules | ruleResponse[r, req] = Permit

        some r: p.rules | ruleResponse[r, req] = Deny

}

Inconsistent policies predicate definition

pred InconsistentPolicies (s: PolicySet, req: Request) {

        some p: s.policies | policyResponse[p, req] = Permit

        some p: s.policies | policyResponse[p, req] = Deny

}

Rules consistency checking

assert RulesConsistency {

        no p: Policy, req : Request | InconsistentRules[p,req]

}

Policies consistency checking

assert PoliciesConsistency {

        no s: PolicySet, req: Request | InconsistentPolicies[s,req]

}

4.4 Comparison

Now, we compare the proposed method with other models. This comparison is done based on the number of features including threat modeling and best practice support. As seen in Table 9, the proposed method covers more parameters than other methods.
Table 9

The comparison of proposed method with other models

Models

Thread modeling

Best practice

Access management regulation

Business process

Application level

Multilevel policy specification

Implementation facility

MLBPM [39]

NS

NS

NS

FS

NS

FS

LS

Guide to ABAC [15]

LS

NS

LS

FS

FS

LS

LS

IFBSLA [40]

NS

NS

NS

FS

NS

LS

LS

BP-XACML [38]

NS

NS

NS

LS

LS

NS

FS

(Proposed method)

FS

FS

FS

FS

FS

FS

FS

FS full support, LS low support, NS no support

5 Conclusion

Nowadays, access control has an important role in the management of access to resources in the networks and applications. The establishment of access control in applications is important particularly. In this paper, a multilayered approach to improve AAA is proposed. In the proposed model, the enterprise layer is very important and has less attention in other models which includes the regulation, best practices and threat modeling. In other words, the regulations in the specification of AAA policies, use of best practices such as ITIL and also policies to reduce the threats of the AAA system are debatable. AAA solutions in business process, operational and implementation layers were also considered. The proposed model in the enterprise layer is implemented based on misuse cases and evaluated by using the penetration testing tools. In the lower layers, we used the Alloy model checker to prove the formal model. The proposed approach creates a comprehensive and accurate AAA in the integrated applications according to their security requirements.

References

  1. 1.
    Nakhjiri M, Nakhjiri M (2005) AAA and network security for mobile access: radius, diameter, EAP, PKI and IP mobility. Wiley, LondonCrossRefGoogle Scholar
  2. 2.
    Bertino E, Ghinita G, Kamra A (2011) Access control for databases: concepts and systems. Found Trends Databases 3(1–2):1–148zbMATHGoogle Scholar
  3. 3.
    Majumder A (2014) Taxonomy and classification of access control models for cloud environments. In: Mahmood Z (ed) Continued rise of the cloud. Springer, London, pp 23–53Google Scholar
  4. 4.
    Schweitzer D et al. (2007) A visual approach to teaching formal access models in security. In: Proceedings of national colloquium for information systems security education. Boston University, Boston. Academic ConferencesGoogle Scholar
  5. 5.
    Aluvalu R (2015) A survey on access control models in cloud computing. In: Satapathy SC (ed) Emerging ICT for bridging the future—proceedings of the 49th annual convention of the computer society of India. Springer, Berlin, pp 653–664Google Scholar
  6. 6.
    Jafarian JH (2008) A context-aware mandatory access control model for multilevel security environments. In: Harrison MD, Sujan M (eds) Computer safety, reliability, and security. Springer, Berlin, pp 401–414CrossRefGoogle Scholar
  7. 7.
    Yadav A, Shah R (2015) Review on database access control mechanisms and models. Int J Comput Appl 120(18):21–24Google Scholar
  8. 8.
    Van Tilborg H, Jajodia S (2011) Encyclopedia of cryptography and security, 2nd edn. Springer, BerlinCrossRefzbMATHGoogle Scholar
  9. 9.
    Jafarian JH, Amini M (2009) CAMAC: a context-aware mandatory access control model. ISC Int J Inf Secur 1(1):35–54Google Scholar
  10. 10.
    Kamboj P (2016) Analysis of role-based access control in software-defined networking. In: Pant M (ed) Proceedings of fifth international conference on soft computing for problem solving. Springer, Berlin, pp 687–697Google Scholar
  11. 11.
    Sharma et al (2013) AMTRAC: an administrative model for temporal role-based access control. Comput Secur 39(1):201–218MathSciNetCrossRefGoogle Scholar
  12. 12.
    Chen L (2012) Risk-aware role-based access control. In: Meadows C, Fernandez-gago C (eds) Security and trust management. Springer, Berlin, pp 140–156CrossRefGoogle Scholar
  13. 13.
    Salim F et al (2013) Budget-aware role based access control. Comput Secur 35(1):37–50MathSciNetCrossRefGoogle Scholar
  14. 14.
    Zhou X, Wang Z (2007) An access control model of workflow system integrating RBAC and TBAC. In: Wang W (ed) Integration and innovation orient to e-society. Springer, Berlin, pp 246–251Google Scholar
  15. 15.
    Hu VC et al (2014) Guide to attribute based access control (ABAC) definition and considerations. NIST Special Publication 800-162, USAGoogle Scholar
  16. 16.
    Smari W, Clemente P, Lalande J (2014) An extended attribute based access control model with trust and privacy: application to a collaborative crisis management system. Future Gener Comput Syst 31(1):147–168CrossRefGoogle Scholar
  17. 17.
    Almutairi A, Sarfraz M, Ghafoor A (2015) Risk-aware management of virtual resources in access controlled service-oriented cloud datacenters. IEEE Trans Cloud Comput PP:1Google Scholar
  18. 18.
    Kandala et al (2011) An attribute based framework for risk-adaptive access control models. In: Sixth international conference on availability, reliability and security (ARES). IEEE, Vienna, pp 236–241Google Scholar
  19. 19.
    Zhang Z (2008) Scalable role & organization based access control and its administration. Doctoral thesis. George Mason University, USAGoogle Scholar
  20. 20.
    Zhao L (2008) A role-based access control security model for workflow management system in an e-healthcare enterprise. Doctoral thesis. The Florida Agricultural and Mechanical University, USAGoogle Scholar
  21. 21.
    Toahchoodee M (2010) Access control models for pervasive computing environments. Doctoral thesis. Colorado State University, USAGoogle Scholar
  22. 22.
    Kirkpatrick M (2011) Trusted enforcement of contextual access control. Doctoral thesis. Purdue University, USAGoogle Scholar
  23. 23.
    Chen L (2011) Analyzing and developing role-based access control models. Doctoral thesis. University of London, United KingdomGoogle Scholar
  24. 24.
    Turkmen F (2012) Exploring dynamic constraint enforcement and efficiency in access control. Doctoral thesis. University of Trento, CanadaGoogle Scholar
  25. 25.
    Salim F (2012) Approaches to access control under uncertainty. Doctoral thesis. Queensland University of Technology, Australian StateGoogle Scholar
  26. 26.
    Nistgov (2016) Nistgov. Retrieved 1 April, 2016, from http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf
  27. 27.
    Nistgov (2016) Nistgov. Retrieved 1 April, 2016, from http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
  28. 28.
    Cisco (2015) Token authentication. In: Cisco (ed) Authentication, authorization, and accounting configuration guide, Cisco IOS Release 15M&T. Cisco Systems, San Jose, pp 321–326Google Scholar
  29. 29.
    Hastings N, Franklin J (2015) Considerations for identity management in public safety mobile networks. National Institute of Standards and Technology (NIST), MarylandCrossRefGoogle Scholar
  30. 30.
    Isoorg (2016) ISO. Retrieved 13 August, 2016, from http://www.iso.org/iso/catalogue_detail.htm?csnumber=23615
  31. 31.
    Federal Chief Information Officers Council & The Federal Enterprise Architecture (2011) Federal identity, credential, and access management (FICAM) roadmap and implementation guidance, 2 edn. Federal Chief Information Officers Council and the Federal Enterprise Architecture, USAGoogle Scholar
  32. 32.
    ISO/IEC (2014) ISO/IEC 27000:2014, Information technology—security techniques—information security management systems: ISO/IECGoogle Scholar
  33. 33.
    Information Systems Audit and Control Association (2012) COBIT 5 for information security. ISACA, Rolling MeadowsGoogle Scholar
  34. 34.
    Rezakhani et al (2011) Mapping ITIL services to ontology-based model to more use in enterprises. In: 5thSASTech, Khavaran Higher-education Institute. Khavaran Higher-education Institute Publisher, Mashhad, pp 1–8Google Scholar
  35. 35.
    Oasis-openorg (2016) Oasis-openorg. Retrieved 1 April, 2016, from http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
  36. 36.
    Jackson D (2011) Application abstractions: logic, language, and analysis (Revised Edition edn). Mit PressGoogle Scholar
  37. 37.
    Mankai M, Logrippo L (2005) Access control policies: modeling and validation. In: Proceedings of the 5th NOTERE conference. Notre Dame: University of Notre Dame Press, Gatineau, pp 85–91Google Scholar
  38. 38.
    Alissa K (2015) BP-XACML an authorisation policy language for business processes. In: Foo E, Stebila D (eds) Information security and privacy. Springer, Berlin, pp 307–325CrossRefGoogle Scholar
  39. 39.
    Nuffel DV, Backer MD (2012) Multi-abstraction layered business process modeling. Comput Ind 63(2):131–147CrossRefGoogle Scholar
  40. 40.
    Boulares S (2015) Information flow-based security levels assessment for access control systems. In: Benyoucef M (ed) E-technologies. Springer, Berlin, pp 105–121Google Scholar
  41. 41.
    Wikipediaorg (2016) Wikipediaorg. Retrieved 11 July, 2016, from https://en.wikipedia.org/wiki/Insider_threat
  42. 42.
    United States Government US Army (2015) Field manual FM 3-99 airborne and air assault operations. Army Field Manual, USAGoogle Scholar

Copyright information

© The Natural Computing Applications Forum 2016

Authors and Affiliations

  • Afshin Rezakhani
    • 1
  • Hossein Shirazi
    • 1
  • Nasser Modiri
    • 2
  1. 1.Information, communications and Security Technologies ComplexMalek-Ashtar University of TechnologyTehranIran
  2. 2.Department of Computer EngineeringIslamic Azad University, Zanjan BranchZanjanIran

Personalised recommendations