8.4. Enforcing Privilege Management

Privilege management involves making decisions about what information is accessed, how it's accessed, and who is authorized to access it. Unlike hardware access control, these concerns deal with policy and implementation issues. Additionally, the issue of auditing is a key factor: You should ensure that your organization doesn't provide more access or privileges than individuals need to do their work.

The following sections cover user and group roles, privilege escalation, single sign-on initiatives, auditing, and access control. Each of these considerations can be used to form an effective and coherent privilege management process. These processes allow users to gain access to the information they need, to be denied access to information they don't need, and to effectively gain access to system resources.

8.4.1. User and Group Role Management

The process of user, group, and role management involves recognizing how work is accomplished in an organization. Most organizations have a high level of standardized tasks that can be accomplished without a great deal of privileged information. Some departments may routinely work with sensitive information about the organization or its customers. A clear set of rules specifying and limiting access can make the job of managing the process much simpler.

Let's take the example of a small business. Company XYZ has departments that are involved in sales, finance, manufacturing, vendor relations, and customer relations. Each of these departments has different information needs.

The sales department may not need to access all of the company's financial information. However, someone in manufacturing might need that information. The job of establishing the various privilege levels in a company can become complicated. Some individuals may need to view certain information but should be prohibited from changing it, whereas other individuals may need to update that same information.

In a company of several dozen employees, establishing access control can be difficult, but in a company of thousands, establishing access control at an individual level can be overwhelming. If each individual needs different access capabilities, thousands of access rules are required.

Most operating systems allow you to organize users into groups with similar access needs so that you can more easily manage an otherwise cumbersome access puzzle. Individuals, and even other groups, can then be embedded into top-layer groups known as security groups.

A security group can have predefined access capabilities associated with it. In this way, you can develop a comprehensive security model that addresses the accessibility needs of everyone in an organization. Figure 8.9 illustrates the group process. In this example, most individuals are placed into one of two departmental groups. The top user in the picture only has access to accounting applications on the ACCTG server, the middle user has access to both, and the bottom user only has access to the APPS server. Departmental groups access information based on established needs and predefined access.

Each department may have different access capabilities. In some cases, different roles within a department have different needs. Although you may want a supervisor to have access to information about a department's performance, you may not want a clerical worker to have that same access. It comes down to an issue of trust, experience, and need.

8.4.2. Privilege Escalation

Privilege escalation is the process of increasing permissions. Often this is done temporarily and innocently, but it can also be accomplished by exploiting local vulnerabilities.

For example, many utilities in the Unix/Linux environment require permissions beyond those given to a user, but a user must run them to accomplish their task. An example is the password utility that allows users to change their passwords. Because the passwords are stored in files that aren't normally accessible by users, during the time that the user is making the change, the utility elevates their privilege to that of a higher (root) user. After the change is made, the utility ends its run and the user ends up with the same permissions/privileges they had before.

Now suppose the utility crashed in the middle of its operation. Theoretically, this could create a situation where the user was left with the elevated privileges and could do things on the system that they otherwise could not. A privilege escalation attack looks for vulnerabilities on the system that could create this situation and then takes advantage of them.

8.4.3. Single Sign-On Initiatives

One of the big problems that larger systems must deal with is the need for users to access multiple systems or applications. This may require a user to remember multiple accounts and passwords. The purpose of a single sign-on (SSO) is to give users access to all the applications and systems they need when they log on. This is becoming a reality in many environments, including Kerberos, Microsoft Active Directory, Novell eDirectory, and some certificate model implementations.

In the case of Kerberos, a single token allows any "Kerberized" applications to accept a user as valid. The important thing to remember in this process is that each application that wants to use SSO must be able to accept and process the token presented by Kerberos.

Active Directory (AD) works off a slightly different method. A server that runs AD retains information about all access rights for all users and groups in the network. When a user logs on to the system, AD issues the user a globally unique identifier (GUID). Applications that support AD can use this GUID to provide access control.

Figure 8.10 illustrates this process in more detail. In this instance, the database application, e-mail client, and printers all authenticate with the same logon. Like Kerberos, this process requires all the applications that want to take advantage of AD to accept AD controls and directives.

In this way, the user doesn't have to have separate sign-on, e-mail, and application passwords. Using AD simplifies the sign-on process for users and lowers the support requirements for administrators. Access can be established through groups, and it can be enforced through group memberships.

On a decentralized network, SSO passwords are stored on each server and can represent a security risk. It's important to enforce password changes and make certain passwords are updated throughout the organization on a frequent basis.

8.4.4. Privilege Decision Making

The process of making decisions about privilege is important. It must be clear and unambiguous to be effective. In the case of a highly centralized environment, a single department or person is responsible for making decisions about access that affect the entire organization. In a decentralized environment, decision making is spread throughout the organization.

The people who are the most aware of the security needs should conduct the decision-making process. This process can involve everyone in the organization.

If someone is unable to accomplish the work they need to do, then the security system isn't working. On the other hand, it's important that personnel receive access only to the information they really need. Establishing a standardized policy or set of policies is important; these policies, and their effects, must be well documented and enforced.

From time to time, individuals may need special access to information that they wouldn't normally be given. For example, an office or clerical person might need to gather information for a special report. Specialized access should be granted only for the period of time during which they need the access. A separate account with these special privileges is usually the best way to manage these types of situations. When the special project is finished, the account can be disabled or deleted. This ensures that privileges don't become associated permanently with a user or a department. Security professionals who ensure that only authorized access occurs can monitor special accounts to reduce the potential for a security violation to occur.

Systems administrators are also subject to privilege issues. If an organization has multiple servers, it may not want administrators to have access to all the servers for administrative purposes. In larger organizations, company-wide access could create a serious security risk. As a rule, you should grant administrative access only to specific systems and possibly grant it only at specific times. Again, doing so limits a company's exposure to security violations.

8.4.5. Auditing

Auditing is the process of ensuring that policies, procedures, and regulations are carried out in a manner consistent with organizational standards. A periodic security audit of user access and rights review can help determine whether privilege-granting processes are appropriate and whether computer usage and escalation processes are in place and working. Think of an auditor as a consultant charged with helping to ensure that procedures are followed.

An auditor who is doing a good job should pull no punches and should offer concrete suggestions on how to improve. These suggestions may pertain to areas of improvement in contingency planning, to security and access problems, or to physical control issues. The information an auditor provides is extremely valuable; acting on it can save your organization time and aggravation. You may not like the results of the audit, but they can be used as a valuable tool to help improve the organization.

Many will argue over the correct steps to go through when performing an audit. The specifics may differ, but the following general steps should always be undertaken: Plan for the audit, conduct the audit, evaluate the results, communicate the results and needed changes, and follow up.

The following sections discuss the need to verify that users are given appropriate permissions to accomplish the work they're assigned.

8.4.5.1. Privilege Auditing

Privilege audits verify that accounts, groups, and roles are correctly assigned and that policies are being followed. An audit should verify that access is established correctly, security is in place, and policies are effective. A privilege audit might entail a complete review of all accounts and groups to ensure that they're correctly implemented and up-to-date.

The problems associated with the transfer of an individual in an organization are common. When a personnel transfer occurs, the transferred user needs to be removed from old groups. Failing to do so can result in privilege creep, which occurs when an individual accidentally gains a higher level of access than they would normally be entitled to or need.

8.4.5.2. Usage Auditing

Usage auditing verifies that systems and software are used appropriately and consistently with organizational policies. A usage audit may entail physically inspecting systems, verifying software configurations, and conducting other activities intended to prove that resources are being used appropriately.

A major concern (although not primarily a security concern) is the issue of installed software and licensing. Illegal use of unlicensed software can carry stiff penalties. Examining systems on a periodic basis verifies that only the software an organization is licensed to use is installed.

From a security perspective, some software is more vulnerable to exploitation than other software. If vulnerable software is installed, it may create a back door or other unauthorized usage problem. Periodically inspecting systems to ensure that software updates are current and that only approved software is installed is a good idea.

Usage audits also examine network usage. Is your network being used for illicit purposes? Is pornography present in your environment? Any number of other problems may also be discovered. By performing audits, you can help deter potentially embarrassing or even illegal activities from occurring in your environment.

8.4.5.3. Escalation Auditing

Escalation audits help ensure that procedures and communications methods are working properly in the event of a problem or issue. Escalation is primarily focused around the issue of gaining access to decision makers in a time of crisis. These types of audits test your organization to ensure that it has the appropriate procedures, policies, and tools to deal with any problems in the event of an emergency, catastrophe, or other need for management intervention.

Disaster recovery plans, business continuity plans, and other plans are tested and verified for accuracy. These types of plans require constant care or they become dated and ineffective. An audit can help ensure that all bases are covered and that your plans have a high likelihood of success when needed.

A good way to determine if your escalation audits are working is to test them. Many organizations develop scenarios to verify that mechanisms are in place to deal with certain situations. If the president of the organization is out of town or unavailable, who has the authority to make a decision about transitioning to an alternative site? If such issues can be worked out in advance, they're much less difficult to deal with in emergencies.

Performing a Usage Audit Your company has undergone its umpteenth reorganization. Many people have been moved to new positions within the new organizational chart. You've been asked to verify that users can access the information they need to perform their jobs. You also need to make sure that any inappropriate access is removed. To successfully complete your assignment, you'll need to inspect every user account and group to verify which user accounts belong to which groups. You also need to verify that each group has the appropriate access to the servers and other resources needed to accomplish their assignments. In many newer systems, you can accomplish this by inspecting the access groups that users belong to and by adding or deleting user accounts as appropriate. If you're using a network that doesn't support security groups, you'll need to modify the access rights of each account individually.

8.4.5.4. Administrative Auditing

One of the most overlooked components of an audit involves administrative elements. It is important to document the procedures undertaken during the classification of information (classifying information was discussed in Chapter 6), and who is involved in this process. You must also document who is involved in investigations, when it is suspected that something is awry, and the procedures they follow—known as due diligence.

This section of the audit should also address change management—the structured approach that is followed to secure the company's assets. Details here should include the controls that are in place to prevent unauthorized access to, and changes of, all IT assets. Among the assets you must be able to demonstrate appropriate controls on are all those related to Personally Identifiable Information (PII). PII exists within your databases for all users, customers, vendors, and contacts and includes such things as their phone number, address, credit card number, employee status, and so on. In general, any attribute of any person is considered PII and is thus subject to privacy protection—and liability—issues.

8.4.5.5. Auditing and Log Files

One operation you will need to perform when working with log files if you are going to evaluate entries from security applications is carefully monitoring their size. In some operating systems, the files are allowed to grow indefinitely (until the drive runs out of space), while in others the size is fixed and older entries are overwritten by new ones. Most Windows server-based operating systems, for example, set the security log to a maximum size and overwrite the file as needed.

If you are running Windows 2003/2008, it is recommended that you start Event Viewer and right-click on the Security Log object. Choose Properties from the popup menu and change the Maximum Log Size entry to as large as you can afford and select Do Not Overwrite Events. Each time you audit the log entries (at least weekly is recommended), choose to manually clear the file once you are certain there are no alarms you should respond to.

The log files created by crucial network services such as DNS need to be routinely examined regularly. The DNS service, when running on Windows Server 2003/2008 for example, writes entries to the log file that can be examined using Event Viewer. Just as the size and overwrite options were set for the Security Log object, it is recommended those same actions be taken for the DNS Server logs as well.

A firewall, whether software or hardware, often creates log files the same as most other services when enabled. Given the importance of the firewall and its purpose, the entries written to those logs should be held in high esteem and evaluated regularly. These log files can be created anywhere a firewall is running, from a workstation to an appliance.

In Windows XP, for example, the firewall log and its settings can be accessed by opening Windows Firewall in the Control Panel and then choosing the Advanced tab. Beneath Security Logging, choose Settings and you can set such attributes as the size of the log file, and its name. To view the file, choose Save As, then find the file in the dialog box that opens, right-click on it and choose Open.

Most antivirus programs also create log files when they run that should be regularly checked. Not only do you want to verify that the program is running, but that the definition file(s) being used is current. Pay attention to the viruses that are found and deleted/quarantined, as well as any files that are being skipped.

Log files should be regularly checked from every antivirus program running, from the workstation to the server and you can educate users on how to routinely examine their own log files. With Sophos Anti-Virus, for example, users right-click on the icon that appears in their taskbar, and choose Open Sophos Anti-Virus from the popup menu. Next, they click Configure Sophos Anti-Virus and choose View log. Changes to the default logging settings are made by choosing Configure log and tweaking the settings that appear in the dialog box shown in Figure 8.11.

8.4.5.6. Reporting to Management

An audit should always conclude with a report to management. This report should outline any organizational strengths and weaknesses as they existed at the time of the audit. The audit should also explain any violations of policy, recommendations for improvement, and recommendations for the organization overall. This report is a vital part of the process, and it provides a mechanism that can be used to develop corrective action plans and updated policies.

8.4.6. Access Control

The three primary methods of access control are Mandatory (MAC), Discretionary (DAC), and Role-Based (RBAC). A fourth method, Rule-Based Access Control (which also uses the RBAC acronym) is gaining in popularity. Each of these methods has advantages and disadvantages to the organization from a security perspective.

The method you choose will be greatly affected by your organization's beliefs about how information needs to be shared. In a high-security environment, the tendency would be to implement either a MAC or RBAC method. In a traditional business environment or school, the tendency would be to implement a DAC method. You should do some consulting within the organization to understand how a particular department and how the entire organization wants to implement access control models. Doing so will allow you to gather input from all concerned parties regarding how access guidelines should be established and how security should be implemented.

In the following sections, we'll look at each of these methods from a business perspective. You learned about the technical aspects in earlier chapters.

8.4.6.1. Mandatory Access Control

Mandatory Access Control (MAC) is clearly an inflexible method for how information access is allowed. In a MAC environment, all access capabilities are predefined. Users can't share information unless their rights to share it were established by administrators; administrators must make any changes that need to be made. This process enforces a rigid model of security.

For a MAC model to work effectively, administrators and network designers must think relationships through carefully. The advantage of this model is that security access is well established and defined, making security breaches easier to investigate and correct. A well-designed MAC model can make the job of information control easier and can essentially lock down a network. The major disadvantages of this model are the lack of flexibility and the fact that its needs change over time. The inability of administrative staff to address these changes can sometimes make the model hard to keep up.

8.4.6.2. Discretionary Access Control

In a Discretionary Access Control (DAC) model, network users have some flexibility regarding how information is accessed. This model allows users to dynamically share information with other users. The method allows a more flexible environment, but it increases the risk of unauthorized disclosure of information. Administrators have a more difficult time ensuring that information access is controlled and that only appropriate access is given out.

8.4.6.3. Role-Based Access Control

Role-Based Access Control (RBAC) models approach the problem of access control based on established roles in an organization. RBAC models implement access by job function or by responsibility. Each employee has one or more roles that allow access to specific information. If a person moves from one role to another, the access for the previous role will no longer be available. RBAC models provide more flexibility than a MAC model and less flexibility than the DAC model. They do, however, have the advantage of being strictly based on job function as opposed to individual needs.

8.4.6.4. Rule-Based Access Control

Rule-Based Access Control (RBAC) uses the settings in pre-configured security policies to make all decisions. These rules can be to deny all but those who specifically appear in a list (an allow list), or deny only those who specifically appear in the list (a true deny list). Entries in the list may be actual usernames, IP addresses, hostnames, or even domains. Rule-Based models are often being used in conjunction with Role-Based to add greater flexibility.