Security Laboratory

Security Laboratory

Security Laboratory: Defense In Depth Series

Other Related Articles in Security Laboratory: Defense In Depth Series

Role Based Access Control to Achieve Defense in Depth

Stephen Northcutt based on research work by Richard Hammer and Peter Leight
Role-based access control (RBAC) is an access control method that organizations implement to ensure that access to data is performed by authorized users. Unlike other access control methods, role-based access control assigns users to specific roles, and permissions are granted to each role based on the user's job requirements. Users can be assigned any number of roles in order to conduct day-to-day tasks. For example, a user may need to have a developer role, as well as an analyst role. Each role would define the permissions that are needed to access different objects.[1]

Implementing RBAC comes with its challenges. It takes time and effort to determine the permissions each role will be assigned. A static template for rolling out RBAC cannot be used for all organizations because business needs tend to differ. Although RBAC implementation has its challenges, there are a great number of benefits. The burden of system administration can be severely decreased. For example, when a user changes job positions within a non-RBAC environment, the system administrator needs to modify the user's access from the object level. The implementation of RBAC would simply require the user to be assigned another role which would grant them permission to complete their new job. Role-Based Access Control (RBAC) is well recognized as the best practice for setting such controls.[2]

Separation of Duties reduces an organization's exposure to fraud and conflict of interest. It also insures that critical business functions do not rely on a single person. RBAC has built-in support for separation of duties. Roles determine what operations a user can and cannot perform. You can enforce a policy that states that a role cannot be both a purchaser and an approver of the same product, or that the person implementing firewall changes cannot audit those same changes. RBAC supports two type of separation of duties; static separation of duties (SSD) and dynamic separation of duties (DSD). Static Separation of Duties defines role memberships that are mutually exclusive. For example, RBAC can ensure that users cannot be members of both the purchasing role and the approving role. That is how SSD ensures that the same person cannot purchase and approve the purchase.

Dynamic Separation of Duties allows the same person to be in the purchasing role and the approving role, but they would be prohibited from approving their own purchase. They would only be able to approve the purchases of others. Another example would be restricting the person who made firewall configuration changes from auditing and approving those same changes. In the SSD model, a user may not be members of both roles. In the DSD model, a user could be a member of both roles, but could not function in both capacities for the same linked transactions.

RBAC as an architectural approach to achieve Defense in Depth requires access control at the enterprise level. The current issue with RBAC access control is that it's most commonly tied to a specific person or user. In order to utilize RBAC as a Defense-in-Depth (DiD) framework we must be able to include computer systems and networks, as well as expand our definition of objects to include data, databases, information containers, and applications. This means that we have to identify the user as they first access the protected domain via the network. As 802.1X ( an IEEE standard for port-based Network Access Control)[3] becomes more widely adopted this becomes possible, and only then can RBAC be utilized as a DiD framework. To make RBAC a complete Defense-in-Depth framework some modifications to the earlier definition must be made. The definition of a user must be extended beyond a human, or user account, to include computer systems, networks, and program agents. We also need to expand our definition of objects to include data, databases, information containers (folders, directories, drives, etc.), computer systems, networks, printers, scanners, and applications. Once these definitions are extended RBAC can be used as a true Defense-in-Depth framework allowing varied network resources to be members of roles and have permissions to perform a variety of operations on many other network resources. All of these operations can then be potentially controlled by role creation, the assignment of operations/permissions for objects, and the assignment of subjects to roles.

Many of today's vendors such as Cisco and Secure Computing have implemented RBAC into their products. Operating systems such as Windows, Solaris and HP also have built-in support for RBAC. Having the ability to granularly control access to systems will assist in implementing a stronger DiD strategy.

The computer security manager's primary application of this information is that Cisco[4] and Microsoft[5] are both heavily committed to RBAC and have agreed to work together. If you already have a Cisco/Microsoft infrastructure, when procuring other devices, make sure their implementation of 802.1X is fully interoperable with the core of your infrastructure. With IPv6 end notes it could be nearly impossible to implement defense in depth on a network without using 802.1x.[6]



The role of Network Access Control in enterprise based Role Based Access Control

From the name, Network Access Control (NAC), it is pretty easy to tell what we are looking at. Controls that allow or disallow a system to enter a network, cross a network, establish a connection to a particular host, port or service. From a technology standpoint this is pretty easy to do, the trick is to manage it. Say you have a network of 2,000 computers. Keep in mind that there are 65,536 TCP ports, 65,536 UDP ports and a bunch of other protocols as well. If we had to manage that by individual rules it would be impossible. So, the first observation the computer security manager makes about NAC is that NAC is not a technology problem, it is a policy and management problem. The second is that NAC is going to need to leverage work already done in the organization to define groups of computers since managing systems individually simply is not possible.

Essentially there are two ways to implement NAC, a standards based solution (802.1x) or with a controlling appliance. Since vendors do not implement standards evenly, one pretty much has to go with a vendor solution, and the most well known vendor is Cisco. Please consider the following from a Network Computing report, "Sixty-five percent of respondents were familiar with, or already using, Cisco NAC (CNAC). Clearly leading the race for brand recognition, Cisco Systems also ranks highest in terms of customer expectations for interoperability and framework preference, with one important exception: when asked about the importance of adhering to a NAC framework or standard, customers responded strongly for Cisco NAC, but responded even more strongly for adherence to any industry standard."[1] So, the bottom line, at least for 2008, if you are talking NAC, you are probably talking about the Cisco Network Access Control Appliance. If you are implementing NAC with an appliance, it controls the network access devices (switch, router, firewall etc ) and they control the end systems.

One of the most important architectural decisions to make concerning the implementation of NAC is whether to place the NAC appliance server In Band or Out of Band.
In Band is where it is always in the flow of traffic between a trusted segment and untrusted segment(s). In this case, the NAC appliance acts like a firewall and is the enforcement agent. This potentially is higher security but puts a greater load on the appliance. It is the easiest to configure. If you have older or multi vendor switches, this is the sensible solution.
Out of Band is where the appliance intervenes with the traffic when a conversation is starting between two devices on the network and then if it approves, it turns the work over to a network switch. It might be possible for an attack of some sort to start after that point so in theory this is a bit less security, but it is a lot less load on the NAC appliance and almost certainly less latency in the network. Out of band pretty much requires modern Cisco switches and is very difficult or even impossible to establish if endpoints are using VPNs.[2]
NOTE: Strictly speaking, Out of Band means using an entirely different network; however, the Cisco folks have slightly misused the term and it appears to be sticking. For instance, in a true out of band network you might implement "centralized monitoring and management solutions using serial console access (also known as console port management or serial console)[that] have been developed to ... reduce the risk of downtime, and lower operational costs. Today’s serial console access systems have port densities and security features that make them a good choice for cluster management."[3] The advantage of true out of band is that it still allows network command and control if the primary network goes down or suffers in a major attack. With a major NAC deployment you might have appliances both in band and out of band using the Cisco definition above.

The next critical architectural decision to make refers to adjacency. If the appliance is deployed within a layer 2 hop of the endpoints it is managing, it can see the MAC addresses; this is called layer 2 adjacency and is simple and safe but may require more appliances. Layer 3 adjacency means the NAC appliance only sees the IP addresses. This can allow a device to manage a larger number of networks and save potentially money, but this may be more difficult to install and the device would miss MAC address trickery such as connection hijacking or ARP switch poisoning.

NAC Host Security Policies

Since we are talking about controls that allow or disallow a system to enter a network, cross a network, establish a connection to a particular host, port or service, we should understand up front it is likely that we are going to impact some user somewhere on the network we need to take the same care with NAC policy that we do with any other security policy. Ensure senior management is involved, establish broad buy-in from all of the business units, make sure the policy approval committee includes members from collective bargaining, audit, HR, legal as well as IP operations. Determine roles that users have, (remember the point of this paper is NACs part in Role Based Access Control). Are there security domains, enclaves that need more or less protection? You will want to have a working acceptable use policy.[4]

First What, then Who

One of the great things about NAC is that you can use it to enforce good user behavior WRT their computers. This is particularly important in organizations that do not have desktop lockdown and strong configuration management. You can tell users to keep their anti-virus up to date, or to keep their systems patched, but do they listen? NACs can be set up to check the configuration of the endpoint system as it tries to connect to the network. If the anti-virus is not running, or is out of date, the user can be connected to a quarantine network until there system meets established policy. In terms of RBAC this can be thought of as the Quarantine Role. In Quarantine, you would probably allow access to, anti-virus vendors, and little else. After the system meets your site's established configuration, only then, does the user get to authenticate, once they authenticate, they are assigned to a role. Common roles might be:
Guest or contractor
VPN user
Admin employee
IT systems employee
Network engineer
Printers and other exempt devices ( devices that do not support 802.1X at this time ). "Exceptions need to be made for all devices which cannot install the client or open a web browser. Nintendo, XBoxes, printers, IP data loggers, security cameras, all need to be manually entered into the system by Ethernet address and assigned a role to control the access the device needs. This could be painful, depending on how good your documentation already is ;-) But it's doable, and helps you gain a good picture of what devices are already there without your knowledge."[5]

Using the principle of least privilege, you allow roles to access certain services, but the default is to deny. In the same way that you can use groups to manage role based access on a server, we can manage access across a network. Before purchasing a NAC appliance, validate for yourself that it can inter operate with your Windows Active Directory and any other source of group information, you do not want to manage access in two locations.