E STUDIOS SOBRE ARTICULACIÓN ESCUELA EMPRESA

A key part of implementing security is identifying the users that are processing data. It is hard to limit data access to only authorized people, if you cannot reliably identify who is attempting to access the data. Today most systems authenticate users by com- paring a password value to a stored copy of the password.1 Some systems use a cen- tralized authentication service to avoid having to define users at each individual server. The proliferation of Web servers has increased the need for centralized authentication. Four main ways of authenticating Web users, as depicted in Figure 12.2 are as follows.

1. Authenticate them using a security database on the Web server.

2. Pass the authentication off to an existing backend system or database.

3. Use a dedicated authentication service such as Radius.

4. Define the users in a directory and use directory protocols for authentication. Each method has advantages and tradeoffs. Using a local security database provides speed but requires duplicate administration for multiple servers and exposes the

1. Most systems use multiple methods to allow the passwords to be stored in a nonreversible fashion. However, they still require a copy of the nonreversible password locally.

authentication database to attacks on the Web server. Accessing existing back-end systems has the advantage of allowing integration with existing security procedures. While this is good for internal users, companies might not want to add millions of customers to their existing system security systems. The addition of a dedicated authentication service allows the new Web users to be defined separately from exist- ing internal users. However, additional information still has to be defined about the users. Using a directory has the advantage of both isolating users and enabling the storage of additional attributes about the user.

One easy way to use a directory for authentication is for a Web-based application to collect the user’s authentication information (user ID and password), then use the LDAP bind operation to present them to the directory for authentication. This allows the application to verify the user’s identity without requiring a local definition of the user. The password needs to be protected from network interception using technologies like SSL. Directories are beginning to support stronger authentication methods. For example, Active Directory supports Kerberos, and the IBM SecureWay Directory supports client public key certificates. Additionally, the application can then access other attributes of the user to either personalize application usage or to provide additional application specific access control.

The directory can also be used as a central access control mechanism. If the applica- tion needs to control access to a resource, it can attempt to access a companion object

Radius or other dedicated authentication service Existing backend system Ldap directory Web server Client 3 4 2 1. Local security DB

in the directory and use the resulting access success or failure as the access control decision. So to grant use access to a resource, the administrator grants access to a sur- rogate in the directory. This method requires the directory access control model to be able to specify the desired resource protections. It is best suited for cases where the protection granularity is not required to be very fine grained. For example, the technique is good for specifying read and write protection, but not as good for con- trolling 20 different flavors of write access. Appendix F describes the access control features of several existing directories.

Program ldapauth (on the CD), illustrated in Figure 12.3, provides an example of how all three techniques can be combined. First it uses the following code to bind to the directory with the user’s ID and password.

rc = ldap_simple_bind_s(hLDAP, wcUserDN, wcPassword); if (rc!=LDAP_SUCCESS) { ... }

User has been authenticated

Once the user is authenticated, his or her telephone number is retrieved. The phone number is used to personalize the access check. The access check determines the user’s access based on his or her ability to access an organizational unit, named using their area code. (The directory objects are named OU=areacode,OU=AWLEnterprise- Directories CH12.) If the directory allows access to the directory object, then the secret message is printed.

auditEvent OU=AWLEnterpriseDirectories CH12 OU=919 CN=Pat Password Phone:919 555-1212 OU=502 OU=... . CN=USERS userDN,password Bind Get phone # Search OU=areacode Search Directory service Ldapauth

The Audit

An important component of implementing an accountability policy is to audit the data accesses that occur. Auditing can be used to achieve three goals.

Control—to document the proper working of a control method Detection—to detect a violation of policy

Repair—to record enough information to allow a security violation to be repaired Figure 12.4 shows how a single audit record can sometimes be used for all three audit purposes.

Most computer system audit records are created for control purposes. In these cases, the audit records serve mainly to document that the access controls and other secu- rity measures are working. (Namely that inappropriate accesses are being denied and legitimate requests are allowed.) Control records can sometimes be used to detect that someone is attempting to violate the security policy, for example, by recording access attempts to files and systems. The key thing to remember about control-style audit logs is that they document decisions; they do not document that legitimate authority was misused, nor do they document access that bypassed the control point. Some auditing is done for actual detection. Recent times have seen the creation of a market for network intrusion detection tools. Whereas control-style auditing docu- ments decisions, detection auditing tends to record activities, then to extract trends from that data. For example, an increase in late night traffic to an obscure ftp server

Good! We know Ed deleted the customer object.

Delete: Customer object Delete: Customer object Delete: Customer object

This is the fiftieth deleted customer object in 5 seconds. We are under attack!

At least we know which customer object was deleted so we can restore it from a backup. Repair

Detection Control

Audit log

might mean that it has been taken over by a hacker. The biggest disadvantage of detection auditing is determining what to do after you detect the policy violation. It is nice to know what has happened, but wouldn’t it have been better to have pre- vented it to begin with? The critical point is that a balance needs to be struck, espe- cially since the two techniques complement each other. The instigation of control methods can prevent most damage, and the detection technology can help identify some of the remaining cases.

Which brings us to the third reason for creating audit records, having sufficient data to be able to recover from a security breach. In general, the IT industry does very lit- tle recovery-related auditing. While there is a significant effort on reliability and disaster recovery, it is not from an auditing focus.

What types of events does auditable software need to record? Unfortunately, the only valid general answer is “It depends.” Basically, every security-relevant event needs to be recorded for later review. Each time the program makes a decision about allowing access or modification of an important piece of data, the decision should be audited. In deciding what data to record it helps the application developer to think of which purpose (control, detection, or repair) the record will be used for. The ldapauth

sample also records a Windows audit record (to the application event log) for each access it grants or denies. This record can either supplement or replace any auditing performed by the directory.

Summary

Enterprise security requires the identification of users, controlling their access to resources and data, and auditing their actions for detection, prevention, and repair of unauthorized actions. Directories provide a powerful tool that can centralize user authentication and access control, while providing additional capabilities to applica- tion designers. The desired security characteristics will need to influence the direc- tory implementation chosen as the enterprise directory. If the directory is going to be used as a security control point, it will need to be secured and managed as part of the enterprise’s security infrastructure.

133

LIFE CYCLE CONTROL

oday’s enterprise applications and their distributed operating environments are so essential, numerous, and complex that additional infrastructure is needed to manage them. A major problem in many organizations is the management of applica- tions. How do we track what applications are where and at what service level? Where do we get early detection of when they’re causing a problem? Is it possible to con- tinue to service client requests even if there is a malfunction? How do we know the nature of the problem? We need a place to make marks on a common wall. Cue the directory. A measure of human common sense doesn’t hurt either. The directory itself is a complex application after all. The term software life cycle describes the soft- ware cradle-to-grave experience. It encompasses software development, installation, configuration, management, and maintenance. This chapter takes us through the management problem of software life cycle control. The case study in Chapter 26 covers the related problem of application management.