Section 3.2. System Access: Logging into Your System
3.2. System Access: Logging into Your SystemThe first way a system provides computer security is by controlling access to that system. Who's allowed to log in? How does the system decide whether a user is legitimate? How does the system keep track of who's doing what in the system? Trying to log into a system is a kind of challenge/response scenario. You tell the system who you are, and the system requests that you prove it by providing information that matches what the computer has stored about you. In security terms, this two-step process is called identification and authentication. 3.2.1. Identification and AuthenticationIdentification is the way you tell the system who you are. Authentication is the way you prove to the system that you are who you say you are. In just about any multi-user system that involves local area networks, and in most desktop and laptop PCs, you must identify yourself, and the system must authenticate your identity, before you can use the system. There are three classic ways to do so:
3.2.1.1. Multifactor authenticationMultifactor authentication is a way to cascade the three methods listed previously such that if an attacker gets past one safeguard, they still have to pass another. Passwords are still, far and away, the authentication tool of choice. In a multifactor authentication system, username and password would be augmented with one of the other two systems. In fact, almost every time authentication devices such as tokens and biometric devices are used, they usually supplement, not replace, conventional login IDs and passwords. See Chapter 9 for additional discussion of authentication devices. 3.2.2. Login ProcessesIn most systems, you identify yourself to the system by entering some kind of unique login identifier or username, followed by a password. The identifier is typically a name, initials, department, or an account number assigned by the system administrator based on your own name and/or group. The password is typically a string of letters and/or numbers known only to you. The exact method of the username/password authentication process varies depending on the network operating system. Generally, however, it involves one or more of the following:
3.2.2.1. Password Authentication ProtocolIn Password Authentication Protocol (PAP), the user provides a username and password, and these are compared with values stored in a table to see if they match. PAP is essentially the same as the classic Unix login. With PAP, login information is transmitted in the clear, that is, unencrypted, or using clear text. 3.2.2.2. Challenge Handshake Authentication Protocol (CHAP)The Challenge Handshake Authentication Protocol (CHAP) is a type of authentication in which the device doing the authenticating, usually a network server, sends the client program an ID value and a random number, and both the sender and peer share a predefined secret word, phrase or value. The client strings together the random value (or nonce), the ID, and the secret, and calculates a new value from them using what is called a hash function. This new value is sent to the authenticator, which has built the same string and calculated a similar hash. The authenticator compares the result with the value it received from the client. If the values match, the peer is authenticated. To increase security, the authenticator can be set to repeat the challenge-response process periodically throughout the communications session. 3.2.2.3. Mutual authenticationMutual authentication can be thought of as two-way authentication. The client authenticates to the server, and then the server authenticates to the client or workstation. This allows the server to verify that the user is at an authorized workstation. If not, access is denied. Mutual authentication can prevent masquerade attacks, in which identity is pretended in order to gain access, or man-in-the-middle attacks, in which an attacker represents itself to the server as a valid client, and to the client as the valid server, taking advantage of the information flow to steal secrets or inject malicious data. 3.2.2.4. One-time passwordThe one-time password (OTP) is a variation of the username/password combination. With OTP, the user creates a password, and the system creates a variation of the password each time a password is required. In this way, the same password is never used twice. With OTP, even if an attacker learns a password by snooping, he won't be able to use it again. 3.2.2.5. Per-session authenticationSetting up an authentication method that requires the client to reauthenticate for each exchange of information is burdensome, but it provides a great deal of security. One way to do per-session authentication is to increment a counter with every transmission. Because the password changes constantly, this form of authentication protects against attackers who snoop. 3.2.2.6. TokensA token can strengthen the authentication process by providing a "what you have" layer to the authentication process. A token or token card is usually a small device that supplies the response to a challenge that is received when trying to log on. One type of a token is a credit card-size device with a built-in keypad. At login, the server issues a challenge with a number. The user keys this number into the token card, and the card displays a response. The user inputs this response and sends it to the server, which calculates the same result it expects to see from the token. If the numbers match, the user is authenticated. Other tokens are based on time. They display a number that changes at regular intervals, usually several times each hour. The user logs in by entering her username and password, along with the time-based value from the token. If the value from the token matches a value the server has calculated, the account is authenticated, and access is granted. The disadvantage of tokens is their small size and their price. If the token breaks or becomes lost, a replacement will be needed to gain access. Depending on the manufacturer and quantity purchased, tokens can run from $30 to $100 each. Software-based tokens are also available. At login, users enter a personal identification number (PIN), with which the soft token creates a one-time password. The PIN is never transmitted. The software token protects itself by refusing to work if an incorrect PIN is entered too many times. 3.2.2.7. BiometricsBiometrics, using personal measurements such as fingerprints, hand outlines, iris and retina scanners, voice recognition, handwriting analysis, and keyboard analysis can be a one-stop shop for authentication, but it is seldom used that way. Biometric technologies are most effective if used as a "what you are" layer of authentication on top of a "what you know" or "what you have" layer. Biometric systems are prone to false positives (saying you are who you aren't) and false negatives (saying you aren't who you are), and most systems have an index of reliability that is calculated by combining the two ratios. Biometrics could be great for verifying a username or password, however, so look for more of it soon. Biometrics is covered in greater detail in Chapter 9. 3.2.2.8. Remote access (TACACS and RADIUS)Even though broadband connections such as cable and DSL are becoming more widespread, dial-up type access is still widely used. To allow remote users to connect to the network, many businesses use modem banks that allow users to dial into the network. These connections must be secured and audited, and users must be able to be authenticated easily, in order to keep information available. But instead of a hundred or a thousand potential clients, anyone with a telephone and a computer becomes a potential login. Specialized login and authentication systems have been developed to meet this need. Here are two of them:
Handling large amounts of login traffic can bog down a server. These protocols allow a network server to offload the user authentication and authorization to a central server. A typical enterprise network may have an access server attached to a modem pool, along with a RADIUS or TACACS server to provide authentication services. Remote users dial into the access server, and the access server sends authentication requests to the RADIUS or TACACS server. The RADIUS or TACACS server then authenticates users and authorizes access to internal network resources. Remote users are clients to the access server, and the access server is a client to the RADIUS server. In addition to providing authentication, both services can track users, the duration of sessions, the protocols used during sessions, ports used, addresses contacted, and even the cause of session termination. Because these services can create logs, the audit trail can be examined to determine who is accountable for each individual session. Essential information about dial-up activity can be organized, charted, and examined. This means that authentication, authorization, and accounting functionality is often delegated to RADIUS or TACACS. TACACS is documented in RFC 1492. RADIUS is defined in RFC 2139 (RADIUS Accounting, April 1997) and RFC 2865 (Remote Authentication Dial In User Service (RADIUS), June 2000). 3.2.2.9. DIAMETERDIAMETER is a protocol that authenticates remote dial-up users, and also provides authorizations and accounting. DIAMETER grew out of the RADIUS protocol, which has limitations in how it can connect. RADIUS works only with modem-based protocols such as Serial Line Interface Protocol (SLIP) and Point to Point Protocol (PPP). In the past, RADIUS functionality was adequate; today's environment, however, uses smart phones and hand-held devices that feature different protocols, so more flexible access methods are required. DIAMETER adds new features to RADIUS, such as the ability to ask for additional logon information beyond basic authentication. DIAMETER uses the initial logon and authentication to identify a user, and then queries the user for additional information that might be used to strengthen the authentication, or gives her access to additional systems. DIAMETER supports the following extensions to various network services:
DIAMETER is described in various Internet Engineering Task Force (IETF) draft standards, including:
3.2.2.10. KerberosOne of the most important and complicated authentication schemes is a network authentication protocol developed in the 1980s at the Massachusetts Institute of Technology (MIT), called Kerberos. Kerberos provides secure transport across insecure media, such as the Internet. Named after the three-headed watchdog guarding the underworld in Greek mythology, Kerberos follows a three-step login process:
3.2.3. PasswordsIn spite of all the options, far and away the most common method for authentication is the username/password combination, as is found on any Unix, Linux, or Windows system. For example, Unix systems display the prompt: login: and expect a first or last name or some prearranged combination of both, such as first initial followed by up to seven letters of the last name, or any other handle you've been given, in response. After you enter your login ID, the system prompts for a password: Password: You type the password (which is ordinarily never echoed, or displayed, on the terminal screen, unless it is by a series of asterisks, which may or may not correspond to the number of keystrokes). The system then authenticates your identity by verifying that the entered password is valid for your account. You'll be able to proceed only if the password you enter matches the password stored for you in the system.
Passwords are your first defense against intruders. To protect your system and your data, you must select good passwords, and you must protect them carefully. This all assumes that you are the only user of your computer. If you share a computer with multiple users, say workers on different shifts, or supervisors who keep accounts on your machine to aid maintenance, any one of the passwords could be the target of the attack.
3.2.3.1. Protecting passwordsAccess decisions are the heart of system security, and access decisions are based on passwords, so it's vital that your system protect its passwords and other login information. Most security administrators protect passwords in three important ways: they make passwords hard to guess, they make login controls hard to crack, and they protect the file in which passwords are stored. Making passwords hard to guess is a matter of user training and occasionally testing to see if the system yields to a common dictionary attack. Such penetration testing can smoke out users who have weak, easily guessed passwords. Making passwords hard to steal is a matter of hiding the file in which they are stored, and in some cases, performing a one-way encryption called a message digest, or hash which stores the passwords in an encrypted form. 3.2.3.2. Protecting your login and password on entryMost vendors offer a whole smorgasbord of login controls and password management features that the system administrator can mix and match to provide optimal protection of a particular system. Because these security features are commercially attractive and relatively easy to implement, most systems tend to have a lot of them. Examples of such features are shown in Table 3-1.
3.2.3.3. Protecting your password in storageEvery system needs to maintain its authentication data. Typically, valid passwords are stored in a password file. This file is accessed only under certain limited circumstanceswhen a new user is registered, when you change your password, or when you log in and need to be authenticated. As a security protection against imposters or compromised passwords, in most cases, administrators cannot access stored passwords. The best they can do is reset a password to a temporary value, such as "letmein" or "password," and require a user to change the temporary password at the next login. Protection of passwords is extremely critical to system security. Systems commonly use both encryption and access controls to protect password data.
3.2.3.4. Password attacksThere are two primary methods of password cracking. The first is to try to guess a password by trying every possible combination of characters, one attempt at a time (a so-called brute force attack). Like everything else, this process has been automated. Crackers now use computers to do the guessing. In theory, the longer the password, the longer it takes to try every combination. For example, with a password containing eight random characters, there are 2.8 trillion combinations. Even a fast computer could take weeks to saw through all possible combinations. The second method is a dictionary attack. The dictionary attack works because most users don't select random, or even decently secure passwords. Most users typically pick passwords that are laughably easy to guesstheir initials, their childrens' names, their license plates, etc. Studies indicate that a very large percentage of users' passwords can easily be guessed. With the help of online dictionaries of common passwords (English words, names of people, animals, cars, fictional characters, places, and so on), crackers are quite likely to be able to guess a good many of the passwords most people are likely to choose. But if you select a good password (see the sidebar "Hints for Picking Passwords"), an intruder shouldn't be able to guess itwith or without a dictionary. 3.2.4. AuthorizationOnce you've been authenticated, the system uses your ID (and the security information associated with it) to determine what you're allowed to do in the computer or on the network. The process of determining your bounds is called authorization. For example, if you try to modify a sensitive file, the system checks your authenticated user ID against the list of IDs representing users who are authorized to read and write the data in that file. Only if your ID appears in that list will the system allow you to access the file. Systems typically maintain a file containing information about your privileges and characteristics; in some systems, this is called a security profile, an authentication profile, or a user list. Your profile might tell the system what your clearance is (e.g., SECRET), whether you're allowed to change your own password, whether you can log in on weekends, whether you can run backup programs and other privileged programs, and a myriad of other information. In some cases, your profile is in the same file as the password list; in other cases, the information might be kept in separate files. In any case, it's vital that your system protect this information; any compromise can jeopardize the security of the entire system. One of the important pieces of information that appears in your authentication profile or user list is an indication of what kind of user you are. Most systems support several categories of users, or roles; a typical set includes regular users, a system administrator, and an operator. Highly secure systems may define a security officer as a separate category. Each category of user has specific privileges and responsibilitiesfor example, specific programs the user can run. The system administrator, for example, may effectively be able to do anything in the system, including overriding or circumventing security requirements and creating new, spurious accounts for the use of attackers. (The power of the system administrator is a major issue in secure systems; see the discussion of administrative controls and least privilege in Chapter 5.) 3.2.4.1. Sensitivity labelsEvery subject and object in a system supporting mandatory access controls has a sensitivity label associated with it. A sensitivity label consists of two parts: a classification and a set of categories (sometimes called compartments). For example, the label shown in Figure 3-1 has both parts. Figure 3-1. Sensitivity label that consists of two parts The classification is a single, hierarchical level. In the so-called military security model (based on the Department of Defense multilevel security policy), there are four distinct levels:
Each classification is more trusted than the classification beneath it. The actual definition of classifications is up to a site's system administrator or security officer. If your site is processing government classified information, your labeling setup has to support the military model. But in general, labels represent whatever set of classifications and categories make sense in your own environment. For example, at a commercial site, you might define this corporate hierarchy:
Or you might define gradations in levels of trust:
Or:
The categories or compartments are nonhierarchical and represent distinct areas of information in your system. Together, the categories make up a category set or a compartment set. A set may contain an arbitrary number of items. In a military environment, you might have categories such as:
In a commercial environment, your categories might correspond to company departments, product names, ad campaigns, or any other setup you wish to implement:
The idea is that even someone who has the highest classification isn't automatically cleared to see all information at that level. For example, to see information in the ANTI-TERRORISM category, you must "need to know" that information.
3.2.4.2. Access modelsThere are two general models of access you are likely to encounter. The Bell-LaPadula model is optimized for confidentiality and is used in defense circles; the Biba model is optimized for integrity and is used in financial transactions and business. 3.2.4.2.1. Bell-LaPadula modelIn 1973, David Bell and Leonard LaPadula first described the DoD multilevel military security policy in abstract, formal mathematical terms, as mentioned in Chapter 2. In their Bell and LaPadula model, they used mathematical notation and set theory to define the concept of a secure state, the modes of access, and the rules for granting access. They called it the Basic Security Theorem. In that model, a subject's (usually a user's) access to an object (usually a file) is allowed or disallowed by comparing the object's security classification with the subject's security clearance. The three basic rules are as follows:
The *-property, or star property, states that a subject is allowed write access to an object (usually a file) only if the security level of the object is greater than or equal to the clearance level of the subject. This makes it impossible for data from a highly cleared subject to become available to users with a lower security clearance in an object (file/directory) with a low security level. Without this rule, a user with a high security clearance could copy sensitive data into a low security clearance documentthus allowing "confidential" data to be written down, or to flow from a "top secret" to an "unclassified" level. Sometimes this is called the write up rule or no write down rule or the confinement rule. The simple security condition is so named because it is not hard at all to grasp. The simple property states that a user (a subject) may only read a file (an object) if she has a security level equal to or greater than that of the file. It means that someone with a "secret" security level cannot read a file with a "top secret" security level; but can read a file with a "secret" or "confidential" security level. Sometimes this is called the read down rule or no read up rule. The tranquility property states that the security level of an object cannot be changed while it is being processed by a computer system. This keeps a program or attack from modifying the sensitivity of a file while it is open and vulnerable. 3.2.4.2.2. Biba modelThe military model is not the best for all cases. Another model you should know about is the Biba model, sometimes called the Bell-LaPadula upside down model. In business and banking, the integrity of data (that is not slipping a decimal point) may be of greater importance than secrecy. (For instance, if one purchases 10 million shares of a company's stock, it will likely be in the financial pages soon as a major transaction, so secrecy is not terribly likely. But during the transaction, it would not be good to shift the decimal a spot and change each share's price by 10 cents, which would alter the sale price by an amount even Bill Gates might notice.) Whereas in Bell-LaPadula, a highly secured individual is not allowed to write documents with lower security to avoid letting information flow down, the Biba model denies a user of a lesser sensitivity from writing documents of a higher sensitivity. It is assumed that the accuracy and trustworthiness of data increases with the sensitivity of the document. To write up would be to risk contaminating higher integrity data with lower integrity data. Similarly, for a higher sensitivity user, to read lower integrity data could result in polluting a higher integrity document.
3.2.5. Access Control in PracticeFortunately, you, the user, are isolated from the mathematical intricacies of access control models. These principles are codified in one of several access control mechanisms. There are at least three basic types of access controls that provide different levels of protection to the files in your system:
With discretionary access control (DAC) you decide how you want to protect your files and whether to share your data. With the more complex mandatory access control (MAC), the system protects your files. In a MAC system, everything has a label; using the security policy relationships established for your organization, the system decides whether a user can access a file by comparing the label of the user with the label of the file. Role-based access control (RBAC) grants you certain privileges based on your job function. If you are an accountant, you are allowed access and control similar to the other accountants. The following sections describe these access control types. 3.2.5.1. Discretionary access controlDiscretionary access control is an access policy that restricts access to files (and other system objects such as directories and devices) based on the identity of users and/or the groups to which they belong. What's discretionary about discretionary access control? In contrast to mandatory access control, in which the system controls access, DAC is applied at your own discretion. With DAC, you, the file owner, can choose to give away your data; with MAC, you can't. Not only does DAC let you tell the system who can access your data, it lets you specify the type of access allowed. For example, you might want to let everyone in the system read a particular file, but you might want only yourself and your manager to be able to change it. Most systems support three basic types of access:
3.2.5.1.1. OwnershipThere are many types of discretionary access control. One simple method involves ownership of files, directories, and devices. If you create a file, you're the owner of the file. Your login ID, or some other identifier, is entered in the file header. A system might base all its access decisions on file ownership. If you're the owner of the file, the system lets you read and change the file. If you're not the owner, you have no rights to the file. This is a simple scheme, but not a very practical one. For one thing, it doesn't let you share the file. Virtually every system keeps track of file ownership and bases many access decisions on it (for example, regardless of other mechanisms, the system might let you delete a file only if you're the file owner). 3.2.5.1.2. Self/group/public controlsIn many systems, you control access to your files by dividing the world of users into three categories and telling the system what the users in each category can do to your file. Some systems call these self/group/public controls. In Unix, they're called user/group/other (UGO) controls:
3.2.5.1.3. File permissionsEach file has a set of bits called file permissions associated with it. File permissions often have the meanings shown in Figure 3-2. Figure 3-2. Self/group/public controls If you list your files (with the correct option) in a Unix or Linux system, you'll see such file permissions as the following: -rw-rw-r-- 1 frank r&d 81904 Nov 7 13:25 UPDATES If a dash (-) appears in place of a permission, the user does not have the corresponding permission to read, write, or execute the file. For instance, in the example, the file owner (frank) can read and write the UPDATES file (rw-), members of the file group (r&d) can read and write the file (rw-), and the rest of the world can only read the file (r--). (Ignore the first dash above; it has a special meaning to Unix.) Consider a few more examples. The CHESS file contains a game; its permissions look like this: -rwxrwxrwx 1 libr games 61799 May 19 10:11 CHESS Everyone can read, write, and execute this file. The SRC95 file is a segment of code that several people in the r&d group are working on; its permissions look like this: -rw-rw---- 1 sarah r&d 55660 Dec 19 11:42 SRC95 The owner and the other members of the group can read and change the file; no one else can access it. The self/group/public controls are a good way to protect files. But what happens if you need to protect a file in different ways for different users, or if you want to keep one user from accessing a file? If Sarah owns the FLAG file and wants Joe (a member of her group) to be able to read and change it, she'll specify the following permissions: -rw-rw---- 1 sarah r&d 22975 Jan 19 10:14 FLAG If Sarah wants Joe to be able to read FLAG, and Mary to be able to read and change it, she could make Mary the owner of the file (with r and w permissions) and leave Joe as a member of the group that can read (r) only. But what if Joe's group contains other users who aren't trusted enough to read FLAG? How can Sarah exclude the sinister Sam, for example? Discretionary access control may seem burdensome, but it is highly flexible. With some complicated maneuvering, it's possible to accomplish these goals with self/group/public controls, but the more special cases you have, the more unwieldy this kind of file access becomes. The system we will explore next offers little such flexibility. 3.2.5.2. Mandatory access controlMandatory access control is an access policy supported for systems that process especially sensitive data (e.g., government classified information or sensitive corporate data). Systems providing mandatory access controls must assign sensitivity labels to all subjects (e.g., users, programs) and all objects (e.g., files, directories, devices, windows, sockets) in the system. A user's sensitivity label specifies the sensitivity level, or level of trust, associated with that user; it's often called a clearance. A file's sensitivity label specifies the level of trust that a user must have to be able to access that file. MACs use sensitivity labels to determine who can access what information in your system. Together, labeling and MAC implement a multilevel security policy a policy for handling multiple information classifications at a number of different security levels within a single computer system. In the past, military systems were set up to handle one, and only one, level of security. The policy for such systems, known as a system high policy, required everyone who used the system to have the highest clearance required by any data in the system. A system that handled SECRET data, for example, could not be used by anyone who did not have a SECRET clearance (regardless of how well protected the SECRET data was). Although many government sites still operate in system high mode, others support multiple security levels. This is done by dividing, or compartmentalizing, the data. Such systems support simultaneous use by users with the highest and the lowest clearances (or, potentially, with no clearances at all), and with access to many different types of sensitive compartmented intelligence (SCI). Although this section tries to touch on the major issues involved with labeling, security levels, and MAC, these are complicated topics, with a lot of security history behind them. Appendix C discusses briefly how the Orange Book specified requirements in these areas. 3.2.5.2.1. Data import and exportIn a mandatory access control system, it's very important to control the import of information from other systems, and the export of information to other systems. MAC systems have a lot of rules about data import and export. They also control which system devices you can use to copy and print information; for example, you might not be allowed to print sensitive information on a printer located in a public area of your building. There are also rules for labeling devices and printed output (with banner pages and page headers and trailers). The discussion of specific labeling requirements is discussed in Appendix C. 3.2.5.3. Access decisionsIn a MAC system, all access decisions are made by the system. Unlike DAC, which allows you to specify, at your own discretion, who can and cannot share your files, MAC puts all such access decisions under the control of the system. The decision to allow or deny access to an object (e.g., a file) involves an interaction between all three of the following:
When you try to read the LOGISTIC file, the system compares your clearance to the file's label to determine whether you'll be allowed to read it. Although multilevel security systems provide many benefits, they're the source of many frustrations as well. For example, under some circumstances, you may write a file and then find you can't read it! 3.2.5.4. Role-based access controlRole-based access control determines a user's access based on that user's role. For instance, financial managers may need to access all accounting data: taxes, payroll, receivables, collections, credit. A clerk in accounts receivable, however, will need only a subset of the accounting data, and an engineer over in R&D will need very little of it. The role a user is assigned to is based on the least privilege concept. The role is defined with the least amount of permissions or functionalities that is required to get the job done. If the privileges for a role change, permissions can be added or removed. This offers greater flexibility by changing the role instead of changing the user's permissions. Since a user can belong to more than one role at a time, there is the chance for conflict. One role may allow access to a resource where another role denies access to that resource. Conflicts like this need to be corrected on a user-by-user basis. As a general rule, the least permissive combinations are used. 3.2.5.5. Access control listsIt would be reasonable to ask how the models mentioned in the previous section are implemented. Access control lists (ACLs) are lists of users and groups, with their specific permissions. They offer a more flexible way of providing discretionary access control. ACLs are implemented differently on different systems. For example, in a Unix-based trusted system that uses a Unix security, you'd protect PAYROLL with ACLs in the form: <john.acct, r> <jane.pay, rw> where:
If john is in the acct group, he can only read the file. If he belongs to any other group, by default he has no access. Similarly, if jane is in the pay group, she can read and write the file. ACLs usually support wildcard characters that let you specify more general access to files. For example, you might specify: <*.*, r> to indicate that any user (*) in any group (*) can read (r) the file. You might specify: <@.*, rw> to indicate that only the owner (@) of the file can read (r) and modify (w) it. In some systems, you can indicate that a particular user is specifically not allowed to access a filefor example, by specifying a null character or the word none or null in place of an access character such as r or w. <sam.*,none >
3.2.6. Directory ServicesAs I described previously, several systems are used to keep track of authorized users. Some of these systems, such as biometrics, are still waiting to catch on. Others, such as the username/password, are getting fairly aged. One of the improvements to occur in login technology is the integration of Authentication, Authorization, and Accounting (AAA) technologies. These improved directory systems keep track of the identity of each user, as well as attributes of that user, such as contact information, personal attributes, including what they can access, in some kind of directory services database. A directory service is essentially a large database that stores information about all the objects in a network and information about how these objects interact. Objects can be users, groups, hardware, or software. One common directory service is Active Directory, used by Windows servers and domain controllers. The Active Directory implementation helps to organize all objects and resources in the network environment while acting as the central point for security as well. Active Directory provides a means to audit all the events that happen on login servers (domain controllers). Audit policies can be set to monitor specific activities, create reports, and notify specific personnel of these events. Group policies can be defined that govern groups of users and computers. These policies can be applied to sites, domains, or organizational units that are defined within the Active Directory structure. Most current authentication services depend on a system of parameters defined in the ISO X.500 standard that defines a standardized way to keep a user and her attributes and permissions easily accessible. The X.500 standard is a comprehensive system, so much so that an X.500 directory is usually accessed using a lighter, simpler tool called Lightweight Directory Access Protocol (LDAP). This section describes X.500, and then discusses the use of LDAP, its applications, its problems, and its possibilities. 3.2.6.1. Email examplePerhaps the easiest way to gain appreciation for directory-based authentication is to consider the situation faced by email administrators in the days before LDAP and X.500. Imagine that a large company merges with another large company. Now imagine that the two companies use different email systems that are only nominally compatible. Every user must appear (have a mailbox) on each system, in order to log on. That means that two sets of administrators must frantically import the complete user list of the other company into each other's systems. This also means, however, that each user ends up with two mail clients that must be checked frequently. Both halves of the new company will have a hard time efficiently communicating with each other, to say nothing of the confusion that will be faced by clients and customers. Obviously, one way to simplify this situation is to import all users into one or the other mail system. This may not be the best approach, however, because email servers seem to operate in clusters that communicate amongst themselves according to users' locations and system load. Migrating to one system or the other may force massive infrastructure changes and the possible interruption of services as the system is cut over. It may be easier just to scale up the systems on both sides and then sort it out later, using some kind of gateway servers to translate between the two systems. Using an LDAP directory, however, all users appear in a common database that the system automatically replicates to login servers all over the network. Mail stores can be forwarded as users move from city to city. Changes to personal information, such as surnames, or changes in preferred salutation, or job title, can be updated in one place, and the change will propagate to wherever it is needed. 3.2.6.2. About X.500ISO X.500 is an international standard. There are two outstanding features of X.500:
X.500 treats every listed computer and user as an object. Server "Framingham 12," backup operator "tdiaz," and System Admin "IMJasmine" are all objects. Every object has attributes. "Framingham 12" may have the IP address attribute of 200.16.212.12. User tdiaz has the attribute of belonging to the Backup Operator group. Admin Jasmin may have the firstname attribute of Ina and the lastname attribute of Jasmine. Ideally, the database schema for each class of object should be consistent. If there is a need to modify the schema to accommodate items of data from one company that are not present in the other, this should not be an unbearable task. The second outstanding feature of X.500 is its hierarchical structure. Individuals and computers are given common names (CN). A common name is the name you or I might call something. Objects with common names are gathered into container objects called Organizational Units (OU). OUs are combined to form objects called organizations (O). The organizations in the hierarchy are grouped into objects called countries (C). Countries exist on the root, which is the top of the filesystem. This hierarchical structure is spelled out in Figure 3-3. Figure 3-3. Discretionary access control with an access control list The directory information tree (DIT) is not intended to be a general-purpose database. It is optimized for frequent reading but infrequent writing. It resembles a database, but the standard was developed to store information about objects relevant to telecommunications. The advantage of the X.500 hierarchical system is that it standardizes the storage of files regarding user attributes and permissions. This makes it easier to share directory data or to copy it. Whether an object is a single user or an entire corporate division, copying addresses is as easy as directing that a copy of the required object be moved into the new directory tree, and all the subsidiary objects will follow. And once the copy gets moved, it is readily usable. Each X.500 site has its own directory system. The administrators at each site need to keep only their own site's data up to date. Users access the local X.500 system only. If the person being sought works at the local site, their entry will be found in the local X.500 system. If the person works at a remote site, the local X.500 system automatically contacts the remote X.500 system to retrieve the information. X.500 switching between local and remote access is transparent to the user. If the X.500 access to the remote sites proves to be too slow, the systems can be configured to automatically copy data to each other, and to regularly update the data. This process is called replication.
The X.500 directory system can store lots of information, such as telephone and fax numbers, physical addresses, computer addresses, positions, responsibilities, and so on. The system can also be extended to store customized information. This large amount of data, and the inherent complexity of X.500, has led to the broad acceptance of a lightweight directory access protocol, called LDAP.
3.2.6.3. Lightweight Directory Access ProtocolThe Lightweight Directory Access Protocol (LDAP) standard defines a network protocol for accessing information from a directory. When it became apparent that directories would need to be standardized, IBM, Microsoft, Lotus, and Netscape agreed to support LDAP. LDAP was designed to adapt the complex X.500 directory system to the needs of modern networks, including the Internet. With LDAP, directory servers run on host computers on the Internet, which means that client programs that are LDAP-compliant understand the LDAP protocol, and can log on to the LDAP server and look up directory entries. LDAP servers first index all the data in their entries. Then, when they process a query, they run the data through filters. These are short, user-configurable statements that describe what should be included or discarded. The filters weed out unneeded entries, leaving the user with just the selection she wants. It can be a person, a group, or an exotic set, such as "every user in the Pacific Northwest who says they have a portable 802.11 appliance." Users can also select how much data they want returned in their queries so that their answer fits their needs, such as last name, first name, business title, email, and phone number. 3.2.6.3.1. The LDAP namespaceIn the LDAP protocol, each listing in the directory is called an entry. Each entry can have one or more attributes. Each attribute has a type, and one or more values. Here's an entry: cn = mylittletestentry objectclass = person Where cn stands for commonName; mylittletestentry is the value of commonName for this entry; and the entry is given a type by use of an objectClass attribute. The system and users tell one entry from another by giving it a name. Entries are named by one of their attributes. cn=mytestentry is this entry's relative distinguished name (RDN). 3.2.6.3.2. HierarchyThe LDAP namespace, like X.500, is hierarchical. This means that the full name of an object must include the path of the object. This full name is called the distinguished name (DN). (It may help to think of "distinguished" in this case as meaning "fully and uniquely identified" rather than "outstanding, noteworthy, or gray-haired.") 3.2.6.3.3. LDAP storage capabilitiesAlmost anything can be stored in an X.500 directory. This can include text, ID photographs, biometric information used for identification and authentication, web addresses, FTP addresses, and other pointers. However, the more information is stored, the more memory is required. Different types of data are held in attributes of different types. Each attribute type has a particular syntax. User-defined attributes, syntaxes, and object classes, make it possible for security administrators to make the directory fit their needs precisely. LDAP is particularly useful in situations where the Internet is an integral part of the network or its authentication scheme. LDAP contains protocols that allow it to be self-replicating over multiple sites. These updates travel over the network as if they were regular network traffic. 3.2.7. Identity ManagementOne would think that with X.500 and LDAP, that directory-based login had reached perfection. Such is not the case. What happens to a given user who must interact with four or five networks in the course of a day? The administrative burden is heavy, even just keeping up with all the logins and the required changes and rotations. The burden is shared by network administrators, who have to maintain several databases for user logins and keep them all in sync. It would be much easier if a user could be authenticated and authorized by one process in a single database, and then have the network generate appropriate logon tokens or certificates that could serve many purposes. This would roughly be the equivalent of the Microsoft Passport system, in which a single logon authenticates the user in many services. This emerging trend in single-point authentication and authorization is called identity management, or sometimes federated identity management. It is called federated because it provides unificationone standard login serving across several different applications, say a network logon, telephone long distance accounting, an email password, and a PIN, to gain access to secured areas. At the root of identity management is a human need to reduce the burden of tracking multiple passwords; an economic need to avoid supporting and maintaining several different databases for the same pool of people; and a legal need to protect the privacy of users who may have private information, such as emergency medical information or information on disabilities or health conditions, stored in company directories. For instance, a switch could ensure that employees who are visually handicapped will receive corporate email announcements in a format suitable for text-to-speech software. Software and standards for building interoperable identity-management systems are evolving rapidly; for example, the Security Assertion Markup Language (SAML) provides a common path to share end-user credentials. An example of an early deployment of a SAML integration application is a project between Boeing and Southwest Airlines that gives the airline's mechanics single sign-on, web-based access to repair manuals stored on Boeing's corporate networks. Service Provisioning Markup Language (SPML) is another new protocol nearing ratification. It is important because it promises to integrate systems that provision user accounts. 3.2.7.1. Financial and legal pressuresOrganizations today face increased regulatory pressure to protect user privacy, ensure the accuracy of corporate financial data, and audit and log their efforts to ensure compliance with new laws. The laws of greatest concern at present are the Sarbanes-Oxley Act (adherence to standards in financial record keeping), the Gramm-Leach-Bliley Act (protection of personal financial data), the Health Insurance Portability and Accountability Act (secure transmission and storage of medical records), the Family Educational Rights and Privacy Act (privacy of student records), and the U.S. Patriot Act (antiterrorism and law enforcement). In the United Kingdom, there is the U.K. Data Protection Act and Regulation of Investigatory Powers Bill, as well. Businesses are struggling to adapt to these sometimes sweeping changes, especially regarding issues of privacy. It is far easier to control personal information in one well-secured database than it is when protected information is spread over a series of disparate databases. As owners and executives wake up to the possibility of fines and perhaps even imprisonment for failure to heed these new laws, the executive visibility of advanced management and control of records and data increases in importance and funding. |
EAN: 2147483647
Pages: 121
- Chapter I e-Search: A Conceptual Framework of Online Consumer Behavior
- Chapter IV How Consumers Think About Interactive Aspects of Web Advertising
- Chapter V Consumer Complaint Behavior in the Online Environment
- Chapter VIII Personalization Systems and Their Deployment as Web Site Interface Design Decisions
- Chapter XVI Turning Web Surfers into Loyal Customers: Cognitive Lock-In Through Interface Design and Web Site Usability