Handling Authentication

Authentication is another one of those subjects that easily warrants a book of its own. To enforce the Rule of Least Privilege, we must have some way to uniquely identify subjects that desire access to objects. Authentication is the means by which we determine who a subject is, and authorization is the process of verifying the subject's right to access an object. Authentication and authorization are often the first means, and sometimes the only means by which organizations protect their resources. There are various grades of authentication and many methods of managing an authentication infrastructure. Here, I will cover authentication and authorization as they relate to the rules of security.

Authentication Is Everywhere

Authentication is seen everywhere in information security: at the desktop, through the firewall, in email messages, and even on an employee's ID. Since authentication is so widespread and so closely tied to the Rule of Least Privilege, it should be clear how important good authentication practices are. If authentication practices fail, we lose our ability to enforce the Rule of Least Privilege and will therefore be unable to protect our resources.

Basic Forms of Authentication

There are many forms of authentication, each with its own advantages and disadvantages. Normally, the more protection a form of authentication offers, the most costly and difficult it is to maintain. Since the purpose of authentication is to uniquely identify a person, we must base an authentication process on something unique about that person. This is normally something the person knows, like a password, or something the person has, like a token or unique thumbprint.

Table 11.1 shows some common forms of authentication and considerations for each:

Table 11.1. Common Forms of Authentication

Type of Authentication	Accuracy of Authentication	Manageability of Accounts	Direct Costs to Organization	Acceptance by Users
No authentication	None	None	None	High
Passwords	Very low	Easy Medium	Very low	Medium
One-time passwords	Medium	Medium	Medium	Low
Tokens and smart cards	High	Medium	High	Medium
Biometric thumb scan	Very high	Difficult	Very high	Medium
Biometric retinal scan	Even higher	Difficult	Very high	Low

Rule of Least Privilege

Authentication is essential to the Rule of Least Privilege. Once we have determined what a user needs to gain access to, we have some way of verifying who the user is. If two people share an account, or someone uses someone else's account through deceptive means, we have lost our ability to enforce the Rule of Least Privilege.

Rule of the Weakest Link

The Rule of the Weakest Link is a common problem when dealing with authentication. A single system can have 100 accounts with strong passwords and one account with a bad password. A hacker is simply going to look for the weakest password, making the total security for the system as bad as the weakest account. Similarly, 100 desktops may require biometric thumbprints to gain access to the domain, while a handful still use passwords; thus, the domain is only as secure as the weakest authentication mechanism.

When dealing with authentication, we must always be searching for the weakest link. Good hackers know that there are always a handful of people and devices that do not follow good password practices and they simple search for such accounts. We can increase security in this area by using proactive security measures:

• Creating good password protection policies

• Enforcing such policies through password filters, aging systems, and other password management controls

• Continually conducting password audits and searching for the weakest passwords

Another good practice is to control sensitive forms of access through higher forms of authentication. For example, a user with administrative privileges is not allowed to reboot a critical server unless he or she has performed a thumbprint authentication. The user can authenticate with a password, which gives him/her some access, but to perform critical functions, a more reliable authentication mechanism is required. This would allow for easier distribution of privileges, but still enforce higher levels of security for critical functions.

Security in Layers

Oftentimes, organizations look to password authentication as the only form of security. We know, however, that basing any practice on a single protective measure is never a good idea. We may, for example, require a user to authenticate to access a particular system. However, since we know this system should never be used from outside the network, we can also check to make sure the user is coming from an internal address. In addition, we know that this system will only be accessed between the hours of 7:00 a.m. and 8:00 p.m., so we tighten the controls even more.

Layering security within authentication is a very good practice. Someone may be able to fake authentication, but by using layering techniques, that person would need to fake it from inside the network during normal business hours as well. This gives the local security team more opportunities to catch the individual and will discourage many hackers.

Secretless Security

As we know, the best security practices are those that do not rely on secrecy to be effective. This is especially true in authentication. Passwords rely on secrecy and are thus one of the worst forms of authentication we can use. Secrets are hard to maintain, continually forgotten, and, oftentimes, given out. Even with training and a great password protection policy, password-based security is extremely unsecure.

Secure forms of authentication are those that are not based on secrets, or that combine secrets with other forms of secretless security. Biometrics and smart cards are prime examples of this form of authentication. Such technologies, however, are still extremely costly, and for the average organization, only practical in situations where high security is required. Common areas that warrant higher forms of authentication security include:

• Remote access via modems or VPNs

• Access to the most critical data centers

• Access to the most critical computers and devices

• Access to the most critical domains and networks

Centralizing Authentication

A helpful suggestion for practicing the rules of security within authentication is to centralize the authentication process as much as possible. The idea behind centralized authentication is to pass a user's credentials off to a centralized system, which returns whether or not the user passed. This pushes the entire process of entering, storing, managing, processing, and removing accounts to the centralized system. By centralizing the authentication process, an organization is better able to control and manage accounts, reducing the number of vulnerabilities and increasing the efficiency of administration. Some common benefits of centralized authentication include the ability to:

• Centrally assign and administer accounts, passwords, and other forms of authentication

• Create a chokepoint and centrally enforce good password protection measures

• Isolate account files and reduce the number of locations where passwords, keys, and other authentication information can be found by hackers

• Centrally audit passwords

• Centrally log account access

There are many methods for centralizing authentication, including several free products. Centralized authentication comes as part of most operating systems, including Windows, Novell, and some forms of UNIX. If multiple Windows systems belong to a domain, for example, the domain controller holds all domain-related account information for the users. With devices such as routers, authentication can be centralized via common protocols such as RADIUS and TACACS. Just about every Cisco device, for example, can pass authentication off to a centralized TACACS+ server. This allows for a single user to have the same login name and password across all routers, dial-up services, and VPNs within the organization.

Single Sign-On Considerations

Expanding on the centralized authentication concept is the idea of single sign-on (SSO). SSO refers to mechanisms that allow users to authenticate with one system, and via internal processes, be automatically authenticated on other systems. This means that the end-user will only need to supply his or her credentials once, and not re-authenticate with every application and device.

SSO solutions can dramatically reduce administrative costs and greatly enhance the end-user experience. SSO technologies are somewhat complex to implement, but more and more products are being made with integrated support. Over the past few years, SSO solutions have been becoming more and more popular.

The Problem with SSO

SSO presents numerous potential security issues for organizations. There are a couple fundamental rules and concepts that can be challenged by some SSO technologies. In particular, the concept of layering security should be considered before adopting any SSO technology.

SSO works to centralize the process of authenticating (and oftentimes authorizing) end-users. When an end-user authenticates to an SSO service, he or she will have automatically authenticated to various devices across the organization via SSO. This means that all authentication security relies on the SSO service. Thus, an individual would only need to fake credentials or obtain access to the SSO service to be authenticated to all devices across the organization. Once an unauthorized session is accepted by the SSO, it will automatically be accepted by other systems that live in complete trust of the SSO service. This greatly reduces the number of security layers we have protecting us.

Properly Handling the Power of Administrator/Root

There are special accounts on most systems that make it difficult to practice the Rule of Least Privilege. In the average system, there is at least one account that has complete and uncontrolled access to read, modify, delete, and execute everything on the system. The existence of such accounts is not in conflict with the Rule of Least Privilege since this level of access is required at times. However, the way in which such accounts are commonly used within organizations does violate the Rule of Least Privilege.

The Inherent Flaw

As we know, it is important to only grant as much access as someone requires and deny anything more. On average, the process of administering a system does not require ultimate and unlimited access. Common administration tasks can be fulfilled without having access to read user files, modify services, or remove critical data. Since, however, there are those rare occasions when a user is locked out of his/her files and the Administrator/Root account is needed to solve this issue, we are presented with the challenge of managing proper administrative privileges. Basically, we have two very large problems: first, the administrators have to be saints; second, the administrators have to be perfect technologists who never make mistakes or accidentally delete things.

The common organization extends far too much trust to their system and device administrators. Organizations screen them, pay them, and then trust that everything will go well. This, however, violates the Rule of Trust and has led to countless disasters for organizations that lose all their data or have everything stolen and sold to their competitors.

The Solution

There is, however, a way to solve these issues while keeping in sync with the Rules of Least Privilege and Trust. It involves special handling procedures for the specially privileged Administrator/Root accounts. We may not be able to fully control what the Administrator/Root accounts have access to, but we can control who has access to the Administrator/Root accounts. The following practices should be followed when dealing with such accounts:

• No superuser account should EVER be used unless absolutely required to perform the task at hand 99% of what the average administrator does can be performed through a power user account, or some account that has access to services, but not sensitive data.

• When a superuser account is required, permission should be granted on a case-by-case basis.

• All activities of the superuser should be logged and reported These logs should report to a system that is monitored regularly and where the individual does not have the ability to modify or delete data.

• Superuser accounts should be protected by strong authentication security measures At the very least, a strong password policy should be enforced, but preferably, other mechanisms such as one-time passwords, smart cards, or biometrics should be considered.

A Note on Superuser Services

Services on a system must be granted privileges just like any user. Oftentimes, when we install applications, services grant themselves superuser access. Why? Because vendors know that this will minimize the possibility that their services will be denied some required resource and that we will have to call technical support.

Services running as a superuser are extremely dangerous and should be avoided if at all possible. No one knows what vulnerabilities exist for each service, and when a vulnerability is discovered and exploited, we don't want an attacker to be running around with superuser privileges. Beyond that, who knows what flaws exist in the application and when and where it will choose to erase an entire system. By limiting the privileges of services, we protect ourselves from unexpected or undesirable behaviors.