Access Controls
Lauren Collins, kCura Corporation
Application of security policies for computers and their systems and procedures leads into the mechanism of access control. The fundamental goal of any access control instrument is to provide a verifiable system for assuring the protection of information from unauthorized or inappropriate access, as outlined in one or more security policies. Generally, this translation from security policy to access control implementation is dependent on the nature of the policy and involves the inclusion of confidentiality and integrity. Systems are responsible for verifying the authenticity of an individual to gain access to a space, or to detect and exclude a computer program failing a spoof test as an access control. Two-factor authentication occurs when elements representing two factors are required for identification. The ways in which someone may be authenticated fall into three categories, based on what are known as the factors of authentication: something the user knows, something the user has, and something the user is. This chapter endeavors to inform the reader about the different types of access controls that are being used, and to describe their pros and cons.
Keywords
access; access controls; mandatory access control; role-based access control; discretionary access control; logical access controls; physical access control; infrastructure; authentication systems; authentication
1 Infrastructure Weaknesses: DAC, MAC, and RBAC
The dichotomy between types of companies and implementing layers of security led to the use of three types of access control mechanisms: discretionary access control, mandatory access control, and role-based access control.
Discretionary Access Control
Discretionary access control (DAC), also known as file permissions, is the access control in Unix and Linux systems. Whenever you have seen the syntax drwxr-xs-x, it is the ugo abbreviation for owner, group, and other permissions in the directory listing. Ugo is the abbreviation for user access, group access, and other system user’s access, respectively. These file permissions are set to allow or deny access to members of their own group, or any other groups. Modification of file, directory, and devices are achieved using the chmod command. Tables 11.1 and 11.2 illustrate the syntax to assign or remove permissions. Permissions can be assigned using the character format:
Table 11.1
Notation to Add, Remove Access, and how to Explicitly Assign Access.
| + | add access |
| − | remove access |
| = | access explicitly assigned |
In DAC, usually the resource owner will control who access resources. Everyone has administered a system in which they decide to give full rights to everyone so that it is less to manage. The issue with this approach is that users are allowed not only to read, write, and execute files, but also to delete any files they have access to. This author has so often seen system files deleted in error by users, or simply by the user’s lack of knowledge. This is an instance where DAC could be seen as a disadvantage, or less advantageous.
Mandatory Access Control
Mandatory access control (MAC) regulates user process access to resources based on an organizational security policy. This particular policy is a collection of rules that specify what types of access are allowed on a system. System policy is associated with MAC comparably to how firewall rules are associated with firewalls. Security-enhanced Linux (SELinux) is a Linux kernel implementation of a supple MAC mechanism called type enforcement. These policies restrict users and processes to the minimal amount of privilege required to perform tasks. Type enforcement uses a type identifier and assigns it to every user and object; these authorizations are defined in a SELinux policy.
The SELinux implementation of MAC exercises a type of enforcement mechanism that necessitates every subject and object be assigned an identifier. We will use the terms subject and object for this example. Consider the subject as a user or a process, and the object as a file or a process. Characteristically, a subject cannot access an object unless the type identifier assigned to the subject is authorized to access the object. The default policy is to deny all access that is not specifically allowed. Authorization is determined by rules defined in the SELinux policy. The following is an example of rule-granting access:
where the subject http daemon is assigned the type identifier of httpd_t and is granted permissions ioctol, read, gettattr, and lock for any file object assigned in the type identifier httpd_sys_content_t. Basically, the http daemon is allowed to read a rule that is assigned the type identifier httpsd_sys_content_t. This is a simpler rule; there are thousands of rules, varying in complexity. There are also many types of identifiers for use with subjects and objects. SELinux adds type enforcement to standard Linux distributions. To access an object, the user must have both the appropriate file permissions (DAC) and the correct SELinux access. ELinux security context covers three capacities:
By running the ls command with the -Z switch, conventional file information is displayed along with the security context for each element in the subdirectory. See the following example, where the security context for the index.html file encompasses user_u as the user, object_r as the role, and httpd_sys_content_t as the type identifier:
Role-Based Access Control
Role-based access control (RBAC) is a method whereby only authorized users can gain access to an environment and the sessions contained in the environment, as shown in Figure 11.1. Some refer to RBAC as role-based security due to the roles an organization creates to assign permissions to users, who perform specific functions, and such users acquire their roles and rights when their account is created. In Active Directory, either the users are in a department that assigns rights by department or the users have customized access based off their role to perform a job function. Referring to the model in Figure 11.1, use the following conventions:
• Permission (P)—authorization to access a resource or utility
• Session (SE)—mapping, including S, R, and/or P
• Partial Instructional Role Hierarchy (RH)—≥(where x≥y requires x to inherit permissions of y)
1. Subjects are allowed multiple roles.
2. Roles are allowed to contain multiple subjects.
3. Roles are allowed to assign multiple permissions.
4. Permissions can be allocated to multiple roles.
Whereas a constraint positions a provisional rule on the possibility of inherited permissions from contrasting rules; it can thus be utilized to attain applicable partitions of duties. As such, a user should not be permitted to both create a login or to empower such an account creation. RBAC is comprised of three principal guidelines:
1. Role assignment: A subject can implement permission once the subject has been designated or has allocated a role.
2. Role authorization: A subject’s dynamic role requires permission for the subject. Refer to rule 1, above, which warrants users only inherit roles for which they are sanctioned.
3. Permission authorization: A subject can employ permission merely if the permission is approved for the subject’s functional role. Refer to rules 1 and 2; rule 3 confirms users can only carry out permissions for which they are allowed.
Several additional controls can be applied on top of the former three rules, and roles can be combined in a hierarchy where higher level roles consider permissions retained by subroles. In larger organizations, typically those with over 500 users, administrators tend to combine MAC or DAC.
As previously mentioned, RBAC can be referred to as an adaptable secure access control. RBAC diverges from access control lists (ACLs) in that it appoints permissions to exclusive operations for users to perform their job functions, rather than to low-level data objects. Let’s say an access control list could be utilized to allow or deny write access to a certain file system, but it is unable to dictate how that file could be changed.
As an example, in financial systems, an operation may seek to create a new trading account or to create a new database for a particular trading product. The assignment of the permission to perform a particular operation is meaningful in this instance, since the operations are so granular with meaning to an application. You would not want college interns creating new trading accounts utilizing real money and would prefer that only an administrator of the risk department had those rights. Even concerning trading limits, imagine if traders could go into the application and raise their trading limits themselves. Risk controls are put into place to protect assets and rights.
RBAC is well suited to separate liabilities, ensuring that more than two people are involved in authorizing critical operations. Integrating RBAC benefits access control policies and aids the IT infrastructure where Active Directory, SQL Server, and any other proprietary applications are concerned.
Logical Access Controls
Logical access controls tools are used for credentials, validation, authorization, and accountability in an infrastructure and the systems within. These components enforce access control measures for systems, applications, processes, and information. This type of access control can also be embedded inside an application, operating system, database, or infrastructure administrative system. Physical access control is a mechanical form and can be thought of physical access to a room with a key. The line is often unclear whether or not an element can be considered physical or logical access control. Physical access is controlled by software, the chip on an access card and an electric lock grant access through software. Thus, physical access should be considered a logical access control. A benefit of having logical access controlled centrally in a system allows for a user’s physical access permissions to be instantaneously revoked or amended. For example, when an employee is fired, his or her badge access can be disabled, as can the employee’s multiple system access accounts. Persons in possession of the proper access card, the appropriate security level, and in some cases a pin are granted entry to a room once the credentials are checked against a database.
Physical Access Controls
Physical access control is a mechanical form and can be thought of physical access to a room with a key. The line is often unclear whether or not an element can be considered a physical or a logical access control. When physical access is controlled by software, the chip on an access card and an electric lock grants access through software (see checklist: An Agenda for Action for Evaluating Authentication and Access Control Software Products), which should be considered a logical access control. That being said, incorporating biometrics adds another layer to gain entry into a room. This is considered a physical access control. Identity authentication is based on a person’s physical characteristics. The most common physical access controls are used at hospitals, police stations, government offices, data centers, and any area that contains sensitive equipment and/or data.
A significant element surrounding physical access controls as opposed to conventional security solutions is its capacity to capture multifaceted and detailed images of physical traits, encode such traits in files, and evaluate sets of data within seconds. Homeowners are now considering this layer of security since loved ones and belongings are sacred, and this layer of security is not possible to forge. Physical access controls not only enhance security but also allow for efficiency, only requiring one form of authentication, a physical trait (fingerprint, retina, palm of hand). This eliminates the risk of a card being stolen or a PIN being hacked.
2 Strengthening the Infrastructure: Authentication Systems
Authentication might involve confirming the identity of a person or software program (see checklist: An Agenda for Action for Evaluating Authentication and Access Control Software Products). The introduction to this chapter mentioned three categories authentication may fall under. Whether it is knowledge specific to a user, a piece of information the user has, or the position the user is in, each of them aims to verify the user’s identity. Each authentication factor covers a range of elements used to authenticate or verify a person’s identity prior to being granted access. Examples include a computer approving a transaction request, electronically signing a document or other work product, administrators granting authority to users with management approval, and a chain of authority that must be established to keep the controls in place and consistent. Security investigations have determined that the standard for verification must include components from at least two factors, and preferably three. Three authentication factors are as follows:
1. Ownership factors: something tangible the user has (ID card, security token, software token, phone or cell phone)
2. Knowledge factors: a piece of information the user knows (password, pass phrase, PIN, or a challenge response, such as a security question only the user knows the answer to)
3. Physical factors: a physical trait of an individual (fingerprint, retinal pattern, signature, voice, or another biometrical identifier)
A common example of a two-factor authentication is when one uses his or her ATM card and has to enter a PIN. Some organizations not only require a username and password to authenticate to the VPN, but also give employees a token with a random set of numbers that change every 30 seconds. The author has visited multiple data center facilities, and while some differ in their choice of the second authentication factor, all data centers require two-factor authentication. While one data center may require use of a badge and your pointer finger fingerprint, others may use a PIN along with a biometric hand scan. Additionally, a handful of facilities include a third factor for authentication, a mantrap. The mantrap screens the person’s height, weight, facial features, and retina. These facilities institute higher security standards and are generally financial or governmental collocation sites.
Kerberos and CHAP
Kerberos is a secure method for authenticating a request for a service in a network. Kerberos was developed in the Athena Project at the Massachusetts Institute of Technology (MIT). Based on the name of the Needham-Schroeder protocol, Kerberos is named after a three-headed dog who guarded the gates of Hades in Greek mythology. Kerberos lets a user request an encrypted "ticket" from an authentication process that can then be used to request a particular service from a server. The user’s password does not have to pass through the network. MIT offers a download for both the client and server versions of Kerberos, or you can buy a copy.
One weakness is that Kerberos requires the continuous availability of a central server. Knock out the Kerberos server and no one can log in. This problem can be mitigated by using multiple Kerberos servers. The technology is also sensitive to clock settings and won’t work properly unless the clocks of the involved hosts are synchronized. Default configuration requires that clock times be no more than 10 minutes apart. Additionally, the administration of the protocol is not standardized and differs between server implementations. And since the secret keys for all users are stored on the central server, a compromise of that server will jeapardize all users’ secret keys.
Big data is a hot subject these days, and without question an increasing number of enterprise information security teams are going to be asked about the security-related ramifications of big data projects. There are many issues to look into, but here are a few ideas to make the big data environment more secure during architecture and implementation phases:
1. Create data controls as close to the data as possible, since much of this data isn’t “owned” by the security team. The risk of having big data traversing your network is that you have large amounts of confidential data—such as credit-card data, Social Security numbers, and personally identifiable information (PII)—residing in new places and being used in new ways. Also, you’re usually not going to see terabytes of data siphoned from an organization, but you should be concerned about the search for patterns to find the content in these databases. Keep the security as close to the data as possible and don’t rely on firewalls, IPS, DLP, or other systems to protect the data.
2. Verify that sensitive fields are indeed protected by using encryption so that when the data is analyzed, manipulated, or sent to other areas of the organization, you’re limiting risk of exposure. All sensitive information needs to be encrypted once you have control over it.
3. After you’ve made the move to encrypt data, the next logical step is to concern yourself with key management. There are a few new ways to perform key management, including creating keys on an as-needed basis so you don’t have to store them.
4. In Hadoop designs, review the Hadoop Distributed File System (HDFS) permissions of the cluster and verify that all access to HDFS is authenticated. When first implemented, Hadoop frameworks were notoriously bad at performing authentication of users and services. This allows users to impersonate as a user the cluster services themselves. You can be authenticated to the Hadoop framework using Kerberos, which can be used with HDFS access tokens to authenticate to the name node.
Challenge-Handshake Authentication Protocol (CHAP) is an authentication scheme used by Point-to-Point Protocol (PPP) hosts to authorize the identity of remote users and clients. CHAP occasionally validates the identity of the client by using a three-way handshake. This occurs simultaneously as the initial link is established, and can take place randomly at any time. Substantiation is based on a shared secret—for example, the user or client’s password. Steps in the CHAP authentication scheme are as follows (reference Table 11.3):
1. Once the link has been established, the authenticator sends a “challenge” message to the peer.
2. The peer then responds with a determined value using a one-way hash function on the challenge and the secret combined.
3. The authenticator checks the response against the expected answer, or calculation of the expected hash value. If the values match, the authenticator acknowledges the authentication. If it does not match, the connection is terminated.
Randomly, the Authenticator Sends Another Challenge to the Peer and Repeats the Steps Mentioned Above
The ID chosen for the random challenge is also used in the corresponding response, success, and failure packets. A new challenge with a new ID must be different from the last challenge with another ID. If the success or failure is lost, the same response can be sent again and will trigger the same success or failure indication. For MD5 as hash, the response value is MD5(ID||secret||challenge), the MD5 for the concatenation of ID, secret, and challenge.
Wireless Security Access Controls
The IT Department has just been notified that the company wishes to allow personnel to access the company network from personal devices. A common approach to achieve this is to create separately named networks, (SSIDs), and corresponding VLANs inside your wired network. Segregating VLANs will separate the traffic between the other network traffic. Public wireless can be placed on a separate VLAN rather than private wireless, and there could also be a Mobile Wireless VLAN added to separate laptop wireless traffic from mobile devices.
However, you still want network access protection and a secure and simple way for key personnel to register their own devices for secure access to a private wireless network. Ask your wireless vendor if it sells a visitor management feature or a registration portal capable of walking personal devices through authorization and Wi-Fi provisioning. Another method for network access protection and wireless access control could be using a Mobile Device Manager (MDM) to drive these tasks.
WPA2-Personal requires every device to supply a Pre-Shared Key (PSK) derived from a passphrase. For example, devices on your trading floor might be required to supply the same random string of 20 characters known only to your IT department and configured during deployment. This method is often combined with MAC address filtering, so that only known devices with the right PSK are granted access. However, MAC address filters are easily bypassed, as are PSKs that are too short or too easy to guess. WPA2-Enterprise requires every device to complete an 802.1X log-on process that can support various authentication methods. For example, each device on your trading floor might be required to prove its identity with a unique digital certificate. Alternatively, each device might be required to supply a unique username and password configured during deployment and known only to your IT department. With this Wi-Fi access control method, you will be able to tell which individual machines are logged on. When used with certificates, WPA2-Enterprise is less vulnerable to password sharing and reuse, which are common problems when employees know a valid username/password or PSK and simply configure those into personal devices.
3 Summary
Although only the most commonly used access mechanisms are discussed in this chapter, many extensions, combinations, and different mechanisms are possible. Trade-offs and limitations are involved with all mechanisms and access control designs, so it is the user’s responsibility to determine the best-fit access control mechanisms that work for their business functions and requirements.
Also included in this chapter are the most commonly used access control policies. Since access control policies are targeted to specific access control requirements, unlike access control mechanisms, specific limitations cannot be inherently associated with them. And like access control mechanisms, it is up to the users to select the best policies for their needs. In addition to the limitations and issues, quality biometrics depends not only on the consideration of administration cost, but also on the flexibility of the mechanism helping the user in assessing or selecting among access control systems.
Finally, let’s move on to the real interactive part of this chapter: review questions/exercises, hands-on projects, case projects, and optional team case project. The answers and/or solutions by chapter can be found in the Online Instructor’s Solutions Manual.
Chapter Review Questions/Exercises
True/False
1. True or False? The dichotomy between types of companies and implementing layers of security led to the use of three types of access control mechanisms: denial of access control, mandatory access control, and role-based access control.
2. True or False? Discretionary access control (DAC), also known as file permissions, is the access control in Unix and Windows systems.
3. True or False? Mandatory access control (MAC) regulates user process access to resources based on an organizational security policy.
4. True or False? Role-based access control (RBAC) is a method whereby only authorized users can lose access to an environment and the sessions contained in the environment.
5. True or False? Role-based access controls tools are used for credentials, validation, authorization, and accountability in an infrastructure and the systems within.
Multiple Choice
1. What is a mechanical form and can be thought of as physical access to a room with a key?
2. What might involve confirming the identity of a person or software program?
3. What is a secure method for authenticating a request for a service in a network?
4. What requires every device to supply a Pre-Shared Key (PSK) derived from a passphrase?
5. What is an authentication scheme used by Point-to-Point Protocol (PPP) hosts to authorize the identity of remote users and clients?
Exercise
Problem
Which type of authentication is best?
Hands-On Projects
Project
Is the access control and authentication software compatible with existing systems and devices?
Case Projects
Problem
Does access control and authentication software offer an acceptable trade-off between security and convenience?
Optional Team Case Project
Problem
How easy is it to upgrade and expand access control and authentication software?