A Design of MAC Model Based on the Separation of Duties and Data Coloring: DSDC-MAC

: Among the access control methods for database security, there is Mandatory Access Control (MAC) model in which the security level is set to both the subject and the object to enhance the security control. Legacy MAC models have focused only on one thing, either confidentiality or integrity. Thus, it can cause collisions between security policies in supporting confidentiality and integrity simultaneously. In addition, they do not provide a granular security class policy of subjects and objects in terms of subjects' roles or tasks. In this paper, we present the security policy of Bell_LaPadula Model (BLP) model and Biba model as one complemented policy. In addition, Duties Separation and Data Coloring (DSDC)-MAC model applying new data coloring security method is proposed to enable granular access control from the viewpoint of Segregation of Duty (SoD). The case study demonstrated that the proposed modeling work maintains the practicality through the design of Human Resources management System. The proposed model in this study is suitable for organizations like military forces or intelligence agencies where confidential information should be carefully handled. Furthermore, this model is expected to protect systems against malicious insiders and improve the confidentiality and integrity of data.


Introduction
In the Emerging Cyber Threats Report 2015 published by Georgia Tech, the attack of rogue insiders was pointed out as one of emerging cyber threats. Security incidents caused by malicious insiders bring about significant damage to companies, but solutions are not easy at all. To address such evolving threats from insiders, it is necessary to develop stronger access control technologies to detect anomalous behaviors. Due to the dynamics and uncertainty of the current network environment, access control is one of the most important factors in guaranteeing network information security. How to construct a scientific and accurate access control model is a current research focus. In actual access control mechanisms, users with high trust values bring better benefits, but the losses will also be greater once cheating access is adopted (Wang et al., 2019).
Earlier studies on access control can be grouped into three categories. First, some studies focus on controlling subjects (users, etc.) such as Discretionary Access Control (DAC) and Role-Based Access Control (RBAC) (Bertino, 2003;Ferraiolo and Kuhn, 1992;Kuhn et al., 2010;Sandhu et al., 1996;2000;United Nations, 2004), while some are about the expansion of such methods (Bertino et al., 2005;Kalinin et al., 2018;Sinha et al., 2018;Zhao and Chen, 2013) Second, techniques such as masking (Mansfield-Devine, 2014), digital watermarking (Kumar, 2019), image fusion (Gupta and Kumar, 2019) and encryption (Davida et al., 1981;Elovici et al., 2004) are aiming at strengthening the security of objects such as data. Third, those that consider both subjects and ■■ objects include Mandatory Access Control (MAC). These methods, however, do not have clear and concrete security policies on access control for objects that indeed should have been protected primarily. Especially, existing MAC models have focused only on one thing, either confidentiality or integrity. Thus, it can cause collisions between security policies in supporting confidentiality and integrity simultaneously. The collision problem of security policy between the BLP and Biba models is shown in Fig. 5. In addition, since access control policies between subjects and objects at the same security level have not been subdivided to define them specifically, it has been difficult to maintain confidentiality and integrity. Even though the Lattice-Based Access Control (LBAC) model (Sandhu, 1993) showed that BLP model (Bell and LaPadula, 1975) and Biba model (Biba, 1997) emphasizing only confidentiality and integrity can be mathematically accommodated in a lattice in terms of information flow, but it was not address that the opposite policy between their models can be complemented into one security policy. In addition, it has not been able to create policies for granular security classes of sub-jects and objects in terms of subjects' roles or tasks. Therefore, the vision or aim of this paper is to solve both the collision between security policies of BLP model and Biba model in order to guarantee confidentiality and integrity at the same time (Fig. 6). To do this, we present a complementary policy for BLP model and Biba model security policy, but we have studied a model that can provide granular access control in terms of Separation of Duty (SoD).
In order to address the ambiguity (collision) issue of security access control policies, this study presents a DSDC-MAC model that is developed using the principle of SoD and a data coloring technique. Based on the policies of the suggested model, at the aspect of tasks of users and objects are separated (integrity) and such classified individual subjects and objects are given certain colors according to their security level (confidentiality). In turn, the colors are matched with security keys (refer Fig. 8 and Fig. 9) to permit subjects to access or not to access objects (or data). In addition, detailed access control using SoD is enabled for security policies between subjects and objects with equivalent security level that previous studies have not suggested. Moreover, security can be strengthened in terms of subject and object mapping through the mechanism of granting and assigning access rights using security keys.
As shown in Fig. 1, according to the proposed concepts and principles above, the approach process for designing the DSDC-MAC model ( Fig. 1) is as follows:  The security requirements are first redefined  The existing BLP and Biba models are complemented each other  The supplemented MAC model (CBB model: Complemented BLP and Biba model) by adding Separation of Duties policy is refined  A security architecture based on the CBB model is designed and a detailed access control technique using SoD and Data coloring in detail is defined  The security keys for matching between subject and object are specified to control user's access to objects  A case studies and evaluations are discussed Next Section analyzes the access control models from relevant studies. After that, following Section addresses the DSDC-MAC model using SoD and data coloring. Next Section presents the application case of the proposed model for a Human Resources Management System (HRMS). Then, next Section compares the existing models with the proposed one.

Relevant Studies
In this section, the characteristics and limitations of the MAC model among various access control models that have been studied to explain the direction and research purpose of this study are described. Next, the differences between the terminology being used in this article and the terminology of data coloring proposed in the legacy study and separation of duties are explained. Finally, the existing research methods for DB security are outlined.

Access Control Model
MAC is a model to control individual owners of objects. The centralized authority determines who should be granted access to what kinds of information and general users are unable to change access authority. Under this principle, MAC models (Kalinin et al., 2018), which determine access control rules by centralized security rules, guarantee data confidentiality and integrity that are not maintained in DAC systems that Owner decides on access control rules. However, it is difficult to determine security levels suitable for subjects and objects in advance and also not easy to apply.
Among the MAC-based models, BLP model, Biba models and LBAC models are representative. Focusing on confidentiality, the BLP prevents information from flowing from a higher security level to a lower security level. As shown in Fig. 2, the BLP model has two policies (No-read-up Policy and Nowrite-down Policy).
The BLP model allows high security subjects to read, but not write, objects of the same or lower level. Conversely, a low secure subject can write, but cannot read, objects of the same or higher level. In other ■■ words, although the confidentiality is emphasized so that a low security subject can't steal high-level data, it has a problem in terms of integrity that a low security subject can manipulate high-level documents.
On the contrary, as shown in Fig. 3, the Biba model (Biba, 1997) focusing on integrity is based on the security access class of subjects and objects. If a subject at a lower security is allowed to alter objects at higher security levels, the original reliability of data can be compromised as it is combined with less reliable information. The Biba model has No-read-down and Nowrite-up Integrity Policies.  The Biba model has a policy opposite to BLP model in Fig. 2. That is, a high security subject can use the same or lower class objects but cannot read them. Conversely, a low secure subject can read an equivalent or higher level object, but cannot write. In other words, it emphasizes integrity so that subjects with low security level cannot manipulate high-level documents, but rather, it is a model that has a problem in confidentiality that a low-security subject can steal high-level documents.
The LBAC model (Sandhu, 1993;Denning, 1976) is one of the most common models among the MAC models. To specify the multi-layer security policy, the dominate relation between the security levels and use lattice to specify the order is defined. In front, we mentioned the limitations of the security policy of BLP model and Biba model emphasizing only confidentiality and integrity respectively. Although it has been shown through several examples that each model can be mathematically accommodated within a lattice in terms of information flow, but it is not clear that the opposite of two models can be complemented into one policy.

Separation of Duties (SoD)
Headings SoD (Botha and Eloff, 2001) is a method for internal control associated with the execution of tasks. One task is divided into several duties and the duties are executed by multiple people to complete the task. This is designed to prevent any abuse of authority or mistakes that may occur in business processes. This concept (Botha and Eloff, 2001;Moon et al., 2004) started as a design principle for data protection in conventional computer systems and it has been defined as a requirement for various access control models including RBAC model. SoD was defined as separation of privilege in Saltzer and Schroeder (1975) among 8 design principles for the protection of information systems and it was also defined as a mechanism to guarantee the integrity of data by linking objects in systems to systems in the real world in Clark and Wilson (1987).
SoD literally means "separating authority" from a perspective of "subjects." To execute a task, its authority is separated and multiple people cooperate together doing their duties. From a perspective of data (objects), however, it is required to classify the objects into smallscale tasks to apply the SoD principle to them. This study suggests more segmented access control methods to secure integrity by classifying tasks classification criteria of objects into more segmented and small-scale data to apply SoD.

Data Coloring
The word, data coloring (Ceze et al., 2008), was first introduced as a technique to apply to programming models. Programmers select certain points and assign colors to them in a control flow in which the consistency of data needs to be secured. This was proposed as a programming model to control access simultaneously through data coloring. A new data coloring technique in Hwang and Li (2010) was suggested as a color matching technique to identify data and users. For the new technique, watermarking mechanism and fuzzy logic were used for cloud computing environments. In Liu et al. (2011), the data coloring technique suggested in Hwang and Li (2010) was applied as a cloud watermarking model and presented test results. In Sudha and Jamuna (2013), a cloud watermarking model using secure RSA algorithm was suggested as a regular authorization method. In other words, data coloring models that were presented in Hwang and Li (2010), Liu et al. (2011) and Sudha and Jamuna (2013) used software watermarking technology to allow the 1:1 access control between Subject (S) and Object (O) when sensitive data had to be shared in cloud environments.
Given that, earlier data coloring techniques are not suitable to classify levels of confidentiality as well as hierarchical authority levels of subjects and objects in this study.

Legacy Methods of DB Security
As shown in Fig. 4, earlier studies on the security of Database (DB) can be grouped into Subject-Oriented Methods (SOMs), Object-Oriented Methods (OOMs) and Multilevel Security (MLS) methods that combined the two types.

SoD and Data Coloring based MAC Model: DSDC-MAC
In order to address collision issues between policies found in MAC models such as BLP and Biba, techniques of Separation of Duties and data coloring are used in this study. Through this method, this study aims to suggest a DSDC-MAC model that can provide more segmented access controls to users (subjects) and data (objects). In doing so, security keys are used as an authorization means for subjects and objects. To do this, this section defines the access control policies of MAC models and proposes security architecture of DSDC-MAC model and finally specifies access control technique based on SoD and data coloring.

Complemented Policy Model for Solving Policy Collision: CBB Security Policy Collision between the BLP and Biba Models
The BLP model, one of the most representative MAC models, focuses on confidentiality, while the Biba model puts focus on securing integrity. If confidentiality and integrity need to be guaranteed simultaneously, all of the policies of the two models should be satisfied at the same time. In this case, as shown in Fig. 5, collisions between the access control policies of the two models occur inevitably.
The No-read-up Policy of the BLP model protects the confidentiality of higher-level secrets by preventing lower security levels from reading higher-level secrets. On the other hand, the Biba model prevents users at higher security levels from reading objects at lower security levels. General concepts of these access control policies are to prevent anything that are clearly not allowed and to allow anything that are clearly not prevented. Based on these concepts, the No-read-up Policy of the BLP model potentially means "possibleread-sibling and down." In other words, this means that reading objects at the same level or lower levels is allowed. Therefore, this exactly collides with the Noread-down Policy of the Biba model. In addition, the Nowrite-down Policy of the BLP model potentially means "possible-write-sibling and up." Again, this means that writing objects at the same level or higher levels is allowed. Therefore, this exactly collides with the Nowrite-up Policy of the Biba model.
Collisions between the policies of the BLP and the Biba models occur in the following cases.

Model "No-Read-Down" Policy
For instance, if there are some personnel who have the 2nd grade (Secret) authority in an organization, according to the BLP model policy, they can read the 2nd grade (Secret) and the 3rd grade (Confidential) information, but they are not allowed to read the 1st grade (Top Secret) information. According to the Biba model, however, the personnel can read the 2nd grade (Secret) and 1st grade (Top Secret) information, but they are not allowed to read the 3rd grade (Confidential) information. In this case, a Case 2. BLP Model "No-Write-Down" Policy ⇔

Biba Model "No-Write-Up" Policy
Like Case 1, if there are some personnel who have the 2nd grade (Secret) authority, according to the BLP model policy, they can write the 2nd grade and the 1st grade information, but they are not allowed to write the 3rd grade information. According to the Biba model, however, the personnel who have the 2nd grade authority can write the 2nd grade and 3rd grade information, but they are not allowed to write the 1st grade information. Again, a question emerges like whether the personnel who have the 2nd grade (Secret) authority should be allowed to write Top Secrets in the Biba model and this arises from "integrity." In other words, there is a contradiction in the "No-write-down" Policy of the BLP model from the perspective of integrity.

Requirements and Assumptions of Security Policy
In order to address such collision issues between policies of the BLP and Biba models and to guarantee both confidentiality and integrity, requirements for security policies should be defined as follows:  Req. 1. Subjects who have higher-level authority can access objects at the same lev el and lower levels  Req. 2. Subjects who have lower-level authority should not be allowed to access higher-level objects  Req. 3. Subjects should be prevented from accessing secretes unrelated to their task This means that in a relationship between a subject and object at the same level, a subject should be prevented from discretionarily accessing an object out of its task range. Even subjects who have higher-level authority should be also prevented from discretionarily accessing objects at lower levels out of their task range.
Assumptions for security to meet these requirements are as follows:  Ass. 1. If a subject is allowed to read an object at a higher level than its security level, confidentiality is violated  Ass. 2. If a subject is allowed to write an object at a higher level than its security level, integrity is violated  Ass. 3. In an ordinary organization, users are not allowed to handle secret information unrelated to their task  Ass. 4. In an ordinary organization, a subject who has higher-level authority assumes all the authority of subjects at lower levels

Complementary BLP and Biba Policy Model: CBB Policy Model
To meet the requirements discussed in above section, access control policies based on the MAC model are redefined as follows. In particular, the security policy rule for Req. 3 should be derived from the perspective of SoD, one of the basic principles for information security. A subject who has lower-level authority is prevented from accessing objects at higher levels. A subject who has higher-level authority can access objects at the same level or lower levels. Allowing subjects at lower levels to read objects at higher levels raises confidentiality issues. In addition, allowing subjects at lower levels to write objects at higher levels violates integrity. This policy protects both confidentiality and integrity by preventing subjects who do not have access authority from accessing objects. "Sibling" is a word for "brother or sister" or "those having parents in common." In this study, siblings mean subjects and objects at the same security level and their tasks are classified based on the Rule 1. A subject at a certain level can access objects allowed within the same task category. It cannot access objects at higher levels even within the same task category as defined in Req. 1, but it can access objects at lower levels.
An enhanced CBB policy model for access control is shown in Fig. 6. This is based on the BLP and Biba models and coupled with SoD, this model can maintain confidentiality and integrity. This model combines the priority policy for confidentiality in the BLP model and that for integrity in the Biba model. By doing so, it is possible to exclude policies that cause collisions between the two models and to map the priority policies with the policies derived from the SoD principle. In other words, in terms of confidentiality, it prevents unauthorized subjects from accessing higher level objects for "read" and in terms of integrity, it prevents unauthorized subjects from accessing higher level objects for "write". That is why it drives to provide and improve the confidentiality and integrity and at the same time. In particular, at the same level, access is granted by classifying subjects and objects in detail by separation of duties. Thus, even at the same level, access to "read" and "write" can be denied without permission, further enhancing confidentiality and integrity.
As discussed in Cases 1 and 2, contradictions in terms of confidentiality and integrity are found in the existing BLP and Biba models. The CBB policy model suggested in this study addresses such issues and the explanation for the solutions is as follows:

[Contradiction]
 Cont. 1. The "No-read-down" Policy of the Biba model has a contradiction in terms of confidentiality  Cont. 2. The "No-write-down" Policy of the BLP model has a contradiction in terms of integrity  Cont. 3. Each policy of the BLP and Biba model has a contradiction in terms of both confidentiality and integrity between subjects and objects within the same level

[Explanation]
Confidentiality is a feature to prevent subjects, who have no authority or have lower-level authority, from accessing data to be protected. The "No-read-down" Policy of the Biba model in Cont. 1 means "Possibleread-up" and gives subjects at lower levels authority to read objects at higher levels. Therefore, Cont. 1 violates confidentiality.
Integrity is a feature to prevent subjects, who have no authority or have lower-level authority, from accessing and altering data to be protected. The "Nowrite-down" Policy of the BLP model in Cont. 2 means "Possible-write-up" and gives subjects at certain levels authority to write objects at higher levels. Therefore, Cont. 2 violates integrity.
In Cont. 3, the "No-read-down" Policy of the Biba model means "Possible-read-sibling." The "No-writedown" Policy of the BLP model means "Possible-writesibling." Therefore, a subject at a certain level cannot be classified by tasks. In other words, Cont. 3 violates both confidentiality and integrity since access authority for reading and writing is allowed to multiple objects at the same level. By separating duties for subjects and object at the same level, access can be controlled.

■■
The CBB Policy model, under the "No-read/writeup" rule, does not allow subjects at certain levels to access (read/write) objects at higher levels at all. In addition, by separating duties for subjects and object at the same level, access can be controlled. Therefore, the suggested policy addresses contradictions that the existing models have.

[Formal Definition]
The formal definition of the CBB policy to accommodate Rule1 and Rule2 derived above is as follows: When and only when the security level SL(S) of a subject 'S' dominates or equal to the security level SL(S) of an object 'O' and the duty (task and/or sub_task) of a subject 'S' equal to the task of an object 'O', the subject 'S' has the "read/write/append/delete" access to the object 'O'.
Security Level (SL) consists of Upper Security Level (USL), Lower Security Level (LSL) and Sib-ling Security Level (SSL) and can have 1 to n security levels: The level or degree of access permission defines as Security Level Function: f(x), The USL function: fu, the LSL function: fl and the SSL function: fs. The access permission level is defined as follows: Where: "⇒" means "access permitted", "  " means "access denied" * Rule description: The security level of a specific subject (S) means that only an object (O) at an equal level and lower level can be accessed (2) but the object can't access to higher level (3).
When a subject (S) having a specific task is defined as a Subject in a certain task: St and an object (O) corresponding to a specific task is defined as an Object in certain task: Ot, the access permission of the security level to the object of the specific task by the subject of the specific task is defined as follows: * Rule description: A specific upper level subject (S) having a specific task (tn) is accessible to an equal level and a lower level object (O) of a specific job (4). However, the lower level subject (S) having the specific task (tn) is that the access is limited to upper level object (5) and if the task is different even if it is a higher level, it means that it is not possible to access to object of the same and lower level (6).

Duties Separation and Data Coloring based MAC Model: DSDC-MAC
As shown in Fig. 7, the security structure of the Duties Separation and Data Coloring (DSDC)-MAC model is mainly composed of security level policy; separation of duties policy; data coloring rules and the relationship among subject, security key and object are applied to. For strict authorization, access has to go through the first authorization process based on Id (identification) and Password and the second authorization process based on security key to directly apply access control policies and additionally certify access. Security Key (SK) serve as a medium to link between a subject and an object. In the processes of security key authority and delegation policy, the security keys of individual subjects are authorized and assigned and users at the relevant security level can delegate security keys to others. Simple security property and separation of duties property, as complementary BLP and Biba model (CBB) policies, address collision issues between policies that were found in earlier studies in terms of confidentiality and integrity. They are also reflected in access control policies to ensure a subject can access an object while maintaining confidentiality and integrity.

Security Level Policy
Security levels of subjects and objects are determined based on those of the existing MAC models. Considering the military domain, they are classified as Top secret, Secret, Confidential and Unclassified (Ferraiolo and Kuhn, 1992;Sandhu et al., 1996). Persons in charge of each of the four security levels are described in Table 1. Objects can be files, data, etc., but data is mainly targeted for the consistency of expression here.

Separation of Duties Policy
To secure effective internal control and maintain confidentiality at each task level, tasks need to be separated according to security levels, but it is also necessary to segment access control based on the separated tasks. A subject's access authority to objects is set by tasks based on the SoD policy. A subject, here, means a user who uses an object (for instance, data).   Tasks need to be grouped into, first, super-categories by their functions and, second, sub-categories within the same super-category. Depending on the size and characteristic of an organization, super-categories are needed only in some cases and for large-sized organizations, it will be necessary to segment tasks further beyond the second-level sub-categories. If necessary, more tasks can be added to sub-categories. Of course, the more category levels are created, the more difficulties the system faces.

Data Coloring Policy
To Data coloring is a concept that was first developed to add identifiers to the confidentiality levels of data. Colors are assigned to data to allow users to intuitively recognize the confidentiality levels of data. It is possible to distinguish the levels simply by using arrays of numbers or levels as identifiers, but there is still ambiguity over how the criteria of identifiers should be set to distinguish confidentiality levels. However, it is possible to conveniently set criteria for confidentiality levels by applying the RGB coloring classification scheme suggested in this study. It is also possible to designate more segmented identifiers within each of the R, G and B groups.

■■
Red, Green and Blue (RGB) colors are expressed as hexadecimal codes on a web page. Color values are specified as three pairs of two-digit hexadecimal values representing red, green and blue. When creating webbased colors, such hexadecimal notations are used and they start with a special symbol (#). The structure of color notations is shown in Table 3.
Around 16 million colors can be created through the 256 levels of RGB combinations. This can be utilized as a very systematic classification method using the webbased color notations above. Table 4 shows security colors that are defined by wrapping the security levels of data (Table 1) with RGB colors. For instance, "red" color is assigned to "top secret" data, creating a security color, "SC_R" (SecurityColor_Red). General data categorized as "unclassified" are actually not the target objects of protection and thus they are excluded here and even from security keys later. Based on Table 1, security colors in Table 4 represent security levels of subjects and objects.

Subjects and Objects Matching by using Color and Task (Duties)
To provide segmented access controls, color codes are given to objects and subjects. Access can be controlled through the mechanism of matching the same color codes. In other words, individual security colors of subjects and objects (Table 4) are further segmented into color values by separating tasks (super-and sub-category tasks). Their color values are defined (Table 3) and individual identifiers of access authority are given as shown in Table  5. With these color codes, it is possible to easily identify security levels and tasks of subjects and objects and their access authority can be segmented by tasks. Codes shaded in gray are highlighted for convenience to intuitively recognize the colors of classified identifiers and thus they have nothing to do with the titles of identifiers. The color codes by tasks in Table 5 are generated based on the Rules 3 and 4 and the rule in Table 6.
Security colors are given to each security level and task and the rules for identification are as shown in Rules 3 and 4. The color values of security levels and tasks are as follows: SC_R: #FF0000, SC_G: #00FF00, SC_B: #0000FF

Rule 3: (Assigning RGB Basic Color Codes to
Individual Security Levels) Web-based colors are identified by the location of "FF" within 6-digit color codes and security levels are basically classified based on this. If "FF" comes in the 1st and 2nd digits, this means red; in the 3rd and 4th digits, green; and in the 5th and 6th digits, blue.

Rule 4: (Assigning Detailed Color Codes to Category
Levels of Each Task) The first two digits "nn" within color codes (excluding FF) are identifiers for super-category tasks and the second two digits "mm" are those for subcategory tasks. With these segmented task identifiers, access can be controlled specifically.
Examples to assign color codes based on Rule 4 are as shown in Table 6.

Subjects Subject-Object Matching by Using Security Keys
Process of Subject-Object Matching Figure 8 shows the matching process of color codes assigned to subjects and objects. Through the ID/Password authorization of users, their preauthorized security level and SoD category (task) are identified. Objects are data that belong to higher and lower tasks stored within the database table and schema. Tasks can be matched with subjects through keys or attributes that have color code values. Security keys between subjects and objects are tools to verify the security levels and SoD that were pre-authorized and assigned to subjects. When an authorized subject wants to authorize additional security keys, authority is granted to the user to access objects matched with the authorized security levels and duties.

Definition of Security Key
As shown in Fig. 9, security key is an essential medium that links subjects and objects at certain security levels based on proper rules (formulas 7~21 below). This serves as a dual-lock tool for the additional authorization of users along with the ID/PW method. In other words, security key is a means to ensure users access objects (data) allowed to them according to their security levels. This can be realized using methods like One Time Password (OTP). In order to provide security policies on access control using security keys, those keys should be matched with colors of security levels in Table 5 and by doing so, access of subjects (users) to objects (data) can be controlled. Based on the rules to control access authority (formulas 17~21), certain access authority is granted to users when the security colors of their security keys are the same as or higher than their level within the same task category. Table 7 shows how subject, security key and object can be matched by security levels using data coloring. Here, the security levels of the keys are defined using a data coloring technique and the abbreviation of 'SK_(color of a certain level)' is used for security key.       Integer (1~n,m), n, m: hexadecimal (0~E/excluding 'F') ** Excluding 'F' in hexadecimal values is to avoid collision with the color level identifier, "FF".

Subject-Object Matching by Using Security Key
Subject, object (Table 5) and security key (Table 7) are classified with colors respectively and identified with color codes. 'L, m, n' in Formula 9 is determined by the number of subjects in each security level. Table 8 shows the mutual matching mechanism among subject, security key and object with tasks (SoD) added to Table 7.
SoD and data coloring are added to formulas (7), (8), (9) and (10) on security level above and the relationship among security color, security key and user can be defined as follows:

Authority-Based Policy Definition
For further segmented access controls, the access authority of subjects, of which tasks are separated by security levels, to objects should have more detailed rules for access based on the security policy of Rules 1 and 2 as follows. Depending on the characteristics of organizations, their tasks may need to have only onelevel classification (super-category only). In this case, access authority can be assigned based on Rule 5. If the tasks need to be classified into two-level categories (supper-and sub-category), Rule 6 can be applied. Rule 7 is applied to assign or delegate access authority within the same task level. * Description: A subject that is classified to a certain security level and sub-category task and certified as SC_tn_m is given access authority to objects below its relevant security level within its sub-category task.
* Description: A subject that is classified to a certain task authority level of a certain security level and certified as SC_tn is not allowed to access objects at the same security level in other tasks. Only when access authority to other tasks is additionally delegated to it, to put it another way, when a subject certified as SC_tn+m is additionally given a delegated access authority (tm) other than its original task (tn), the subject is allowed to access objects below the security level of tm within the task category.
* Description: A subject that is classified to a supercategory of a certain security level and certified as SC_tn is given access authority to objects that are classified as sub-category tasks under the super-category task at the security level. However, this rule can be applied when there is a need to restrict access to specific subordinate functions to those who have authority of specific higher level tasks according to the confidential classification policy of the organization.

Authority-based Access Control
The relationship among subject, security key and object classified under the SoD principle and security levels is shown in Fig. 10. The figure also shows examples of access attempts that are not allowed under their respective access authority. Access attempts ②, ③ and ④ (except ①) are blocked under Rules 1-2 and 5-6. In the case of attempt ①, a subject at the Secret level within Task #2 accesses an object within the same task category with a valid security key. Attempts ②, ③ and ④, however, try to reach objects out of their task categories and thus their access is blocked under the access control policy. Fig. 10: Categories of and relationship between subject, security key and object However, Attempts ② and ③ are to access objects out of their task categories and thus they are blocked under the access control policy. Attempt ④ is allowed if it is the "No -write-down" Policy of the BLP model and the "No-read-down" Policy of Biba model, but it is blocked under the policy of the CBB model suggested in this study.

Authority Delegation (Security Key Delegation)
Authority delegation can be executed only by subjects who have security keys to objects at certain levels. A subject who has access authority to certain data under the SoD principle is able to delegate the authority to unauthorized subjects at the same level (meaning sibling subjects in separately classified tasks) and other subjects at higher levels in other tasks.
In delegating authority, the policies defined in "Complementary BLP and Biba policy" section should not be violated. If a subject receives a request to permit authority delegation from those at the same level or higher levels, the subject should delegate its security keys to them after checking whether there is any violation of the defined policies or not. The results of delegation, as data to identify relevant subjects, objects and delegated security keys, is sent to and saved at a repository for access control policies and utilized as data for review.

Case Study
This chapter shows an application cases by applying the proposed method to the Human Resources management System (HRMS). As a case study, the example case of handling confidential information due to the characteristics of the MAC model is desirable, but it is difficult because it includes sensitive data related to military agency.

Human Resources Management System (HRMS)
The suggested DSDC-MAC model was applied to a Human Resources Management System (HRMS) to verify its reliability. The HRMS handles sensitive personnel information such as social identification, contact number, passport information, HR history, work performance, annual salary, etc. Since such information needs to be classified by task areas and security levels, it is suitable to apply the DSDC-MAC model to this system. Figure 11 shows general task areas of the HRMS including employment management, HR operation/ management, absence control, performance evaluation management and payment management. Under the 5 super-categories of tasks, sub-categories are classified respectively and further detailed data are also included.

DSDC-MAC-based HRMS Access Control Model Domain Task Category and Security Leveling of HRMS
First, tasks are separated and data security levels are determined. The areas of the separated tasks are defined based on the SoD classification in Table 2 (chapter 3) and the HRMS task categories in Fig. 11. In order to set security levels on data units in detail, data groups are included in the sub-category classification. Data security levels are set using the security levels in Table 1. The items shown in Table 9, except the subject and object columns, define task categories and security levels. For instance, "Candidate Information" is a sub-task of the super-category "Employment Management," and "n1) Contact No." in the Task and Data item under the subcategory is the sub-data group of "Candidate Information." The detailed data under the group is classified as "Confidential," and thus only those in charge of the task are allowed to access the data.

Separation of Duties by Subject and Object of HRMS
Subjects and objects are linked to the HRMS task categories and data defined above as shown in Table 9.
In particular, subjects are divided into worker and manager in charge of each task (department) and vice president or president who has higher responsibility. Generally, the higher work position, the higher responsibility. Persons at higher-level positions tend to have higher security levels. Thus, worker is given the 3rd-grade security level (Confidential) and manager, the 2nd-grade security level (Secret). More sensitive information is classified as the 1st-grade security level (Top secret) and president or vice president is given the security level. In particular, "n2) Social ID No." in Table  9 is very sensitive data and thus its security level is classified as "Top Secret" to ensure that the information is controlled by the highest-level manager. Subjects who can access the data are limited to "Vice President." In other words, the data can be accessed only by subjects who are allowed to handle the "Personal Information" task which is one of the sub-category tasks of the super-category task, "Human Resources Operation Management," and who at the same time have access authority to Top Secret. If necessary, data can be entered or altered by others through authority delegation.

Data Coloring of HRMS Objects
A data coloring technique is applied to the subjects and objects (Table 9) of the HRMS defined by tasks above and Table 10 shows the results. Security colors by security levels are mapped based on Rule 3 and Table 4 and those by task categories are mapped based on Rule 4 and Table 5. "Personal Information" is one of the subtasks of the super-category "Human Resources Operation Management," and "n3) Contact No." in Table  10 is one of the sub-data groups under Personal Information. The security level of the detailed data is set as "Confidential" to ensure that they can be accessed by only persons in charge of the task. Under Rules 3 and 4, identifiers (RGB color codes) are also given to the data using the data coloring technique.      Task   Definition of Security Keys of Subjects for Accessing HRMS Objects Table 11 shows the HRMS security keys for each object to access objects and they are defined based on Table 7 and 8 and formulas 7~16 using data coloring and SoD. "n4) SK_B_t1" in Table 11 is defined as the security key that has access authority both to t1, the identifier of the supper-category task called "Employment Management," and objects classified as the 3rd-grade security level (Confidential). This security key is granted only to users at the related security level in the same task category, that is, "Employment office worker." Here, the security key is a means to identify subjects and objects when subjects try to access objects that they are allowed to do so. This can be also used as a tool to authorize subjects, allowing them to validly access to objects according to the defined rules.

Authority-Based HRMS Policy Definition
Based on the subject, object and security key defined above, access authority policies for the HRMS can be defined under Rules 5-7 as follows: The policies above stipulate that subjects who have access authority to Task#1 (Employment Management) are allowed to access data below the security level. In other words, subjects who have the Red security level (1st-grade/Top Secret) in Task#1 can access data classified as 1st, 2nd and 3rd grades as well as generallevel data within the relevant task category.
Such access policies above define all the individual task categories and under task categories, subjects, objects and security keys are linked and defined accordingly.

Evaluation
In this section, it focus the primary characteristics of the access control model, compare the proposed model with the legacy MAC models and discuss the characteristics and limitations of the proposed model.

Discussion on the Access Control Policies with Case Study
Looking at the HRMS case and access control policies of the DSDC-MAC model, the Employee manager with green authority of task classification t1 has authority to read and write about the 3nd grade data as well as 2nd grade of t1. However, T2's 2nd grade (Green) secrets, which can only be accessed by HRO Managers of the same class, are not accessible under the separation of duties policy. In addition, Employment office workers with t1 (blue) authority with the same task are not authorized to read, write, or access 2nd grade (Green) secrets. This indicates that a low level of confidentiality can improve the confidentiality and integrity by not being able to read or write higher level secrets. Moreover, even if a subject has the same level of authority, if the job is different, it can further ensure confidentiality and integrity so that it cannot be read or written. However, in case of legacy BLP and Biba model, there has problems as follows. If it is BLP model, Employment Office Worker of 3nd grade (Blue Level) cannot read "Green" Data of 2nd grade, but "Write" is possible, so there is integrity problem. In the Biba model, Employment office workers cannot "write" data of 2nd grade, but "read" is possible, which is a confidentiality problem. Furthermore, both models are capable of "write" and "read" at the same level, which makes it possible to read or modify secrets irrelevant to the job, which leads to problems of confidentiality and integrity. On the other hand, the proposed DSDC-MAC model can solve above problems.

Comparative Evaluation with the Existing Methods
The DSDC-MAC model is evaluated in comparison with other MAC models, including BLP, Biba and Lattice-based access control model as shown in Table  12. The proposed model was compared with existing studies mainly from two aspects, including confidentiality/ integrity and model design.
From the confidentiality and integrity aspect, more detailed classification on subjects and objects was required to support these features. Compared with earlier studies, it is basically possible to classify subjects and objects in detail according to security levels in the BLP, Biba and lattice-based models. Those models, however, failed to classify the items further as the proposed model in this study did by applying the SoD principle.
Especially, coupled with the method of security keys, this model provides dual-lock access control tools unlike other models. For flexibility, the proposed model allows authorized users with security keys can delegate their authority to sibling subjects in other task categories and those at higher levels. Using the access control policy repository, the results of the requests and approvals for authority delegation can be used for review later afterwards.
In addition, the BLP model emphasizes confidentiality and the Biba model emphasizes integrity respectively. Thus, these models did not meet confidentiality and integrity at the same time. On the other hand, the Lattice model has been shown to be mathematically acceptable within one Lattice to solve the limitations of the security policies of the BLP and Biba models. Therefore, the Lattice model appears to support both confidentiality and integrity simultaneously.  (Sandhu, 1993;Proposed Assessed items LaPadula, 1975) From the aspect of model design, no suggestion was found in earlier studies on identifiers of subjects and objects. In this study, however, accurate identifiers were presented using a data coloring technique. In addition, other studies have not supported strict authorization and secure key management.
Furthermore, other legacy studies did not have specific case studies or implementation models and were only described as illustrative levels. However, this study presented a case study through HRMS system.

Characteristics and Limitations
The main features of the proposed DSDC-MAC model and policies are as follows:  SoD-driven access control While earlier studies use a vertical method for access control based on security levels (Top Secret/Secret/Confidential/Unclassified) only, access control can be further segmented horizontally even within the same security level based on tasks in the proposed model  Security color-focused access control The proposed model support identifiers of data by security levels and task categories using data coloring, providing object-oriented access control based on security colors  Mapping subjects and objects based on security keys The proposed model guarantees subjects dual-lock authorization tools using security keys. With security colors and keys, subjects and objects can be identified and their access can be controlled, thus supporting dual-lock security control  Complementary BLP and Biba (CBB) model policy By suggesting a new CBB policy model, the proposed model can address contra diction issues associated with confidentiality and integrity that are found in the BLP and Biba models. With this mechanism, security can be further improved  In addition to complementing confidentiality and integrity policies by Data Coloring and Separation of Duty, this study provides one of the contributions to provide dual-lock access control through Security Key. However, it did not examine in detail the implementation method of optimized security key and only mentioned that security key implementation such as OTP is possible. Thus, further follow-up studies are needed The followings are some potential limitations found in the proposed model:  The proposed model lacks standardized specifications on the security policies using SPL. (Access Control Language for Security Policy)  The proposed model has to be implemented or built in existing DBMS systems To implement the results of this study in real settings, it is essential to apply them in commercialized DBMS systems, but there is some difficulty in implementing it in reality. It was difficult to apply key modules suggested in this study to commercialized products such as Oracle and more time and efforts should be put into applying them to open source DBMS systems. More optimized methods to implement security keys in reality should be also suggested

Conclusion
This study suggested a DSDC-MAC model and security policies that can improve both the confidentiality and integrity of MAC models such as BLP and Biba using SoD and data coloring techniques. Based on the policies of the proposed model, tasks of subjects and objects were classified and security colors were given to each of the classified subjects according to their security levels. The colors were matched with security keys to prevent or allow subjects to access objects (or data). By applying the principle of SoD-based access control, ambiguity in access control within the same security level was removed. It was possible to segment security and access controls for subjects and objects using a data coloring technique. Collisions between security policies can be prevented by simultaneously supporting confidentiality and integrity based on MAC models. In addition, it becomes convenient to identify data security levels and manage access control by assigning security colors to individual task data. At the same time, it is possible to provide dual-lock access control along with security keys. The model can be applied to the design and construction of an organization's internal systems or organizations that deal with a lot of confidential information, such as the military or intelligence agencies that only provide specific information to specific personnel. In particular, it will be an effective countermeasure against insider threats.
The Complementary BLP and Biba (CBB) security policies in the suggested model need to be further specified using an access control language in a follow-up study. The efficiency and usability of the proposed model should be analyzed further by applying it to settings such as object-oriented DB. Furthermore, it will be also necessary to implement a DBMS system equipped with the security structure of such databases. In addition, the present model has been studied to ensure confidentiality and integrity at the same time, but does not consider availability, one of the third triad of security. Therefore, in the system implementation stage applying the proposed model, it is necessary to conduct research so that a valid licensee has no restriction on service use in consideration of 'availability'. In addition, a study on both the implementation of the security key ■■ optimized for the presented model and also the complexity analysis of the proposed approach method is required. Based on these future studies, a practical case study is needed to verify the applicability of the proposed model to specific institutions.

Chee-Yang Song:
Harmonized the entire development of the article and revised the manuscript.
Soon-Book Lee: Worked on most of the parts, introduction, design and evaluation of the research method and to the writing of the manuscript.
Yoo-Hwan Kim: Contributed to the design of the research plan and content, related work and engaged in the literature view.
Jin-Woo Kim: Participated in design of research model and to writing case study.

Ethics
This manuscript is original and has not been published elsewhere. The corresponding author confirms that coauthors have review and approved the article and there are no ethical issues in the future.