Privacy and Security Considerations

As discussed in Chapter 12, Privacy and Security Design, different data elements have different security needs. Some data elements contain highly sensitive information and should be protected from unauthorized access and tampering. Other data elements do not contain sensitive information, and they need only to be protected from unauthorized modification. The coexistence process itself may present another way to compromise your data. In this section we explore issues related specifically to your directory coexistence strategy, including the privacy of the join attribute, the security of links in the coexistence process, and the security of data sources.

Tip

Design your directory coexistence procedures with security in mind. A poorly designed directory coexistence process often presents backdoor holes that can be used to compromise the security of your directory and the other data sources. Make sure the systems with which your directory exchanges data are as secure as the directory itself, and vice versa. Also be sure to secure the processes and links between the different systems.

The Join Attribute

As described earlier in this chapter, joining data among multiple directories is much easier when you have one or more join attributes that are common among all the directories. The more likely you are to have unique join attribute values, the more accurate the joining process will be and the less the administrative burden placed on directory administrators will be. This fact argues for choosing a unique join attribute if possible.

The most convenient attribute to use is often the Social Security number or something similar. However, SSNs are sensitive information that should be protected carefully . SSNs are issued by the U.S. government for tax identification purposes, but they are also used by many banks and other institutions as something akin to a password. If a person's SSN falls into the wrong hands, all kinds of trouble can follow, such as stolen identity, ruined credit, and unauthorized access to personal information. For those reasons, most users consider SSNs to be private information, and they will certainly be upset if care is not taken to protect their private information.

SSNs are also not immutable; they can change for various reasons. Finally, SSNs are not universal; not everyone has one, and you may not have access to SSNs for all the people represented in your directory. Non-U.S. employees , customers, and others may not have SSNs or want to give theirs to you. Therefore, the SSN may not be the best choice for a join attribute. But sometimes it is the only realistic choice you have.

When designing your directory coexistence processes, you must take care to protect sensitive join attributes such as a U.S. Social Security number. Consider who has access to the sensitive join attribute at all stages of the coexistence process. Do you really need to use SSNs, or is there another less sensitive attribute or set of attributes that would work just as well? Could you use a hashed form of the SSN, providing a measure of privacy protection? Does the coexistence process expose the join attribute to other less trusted directory or database administrators? These questions and others all need to be answered .

Data Transport

Another common security trouble spot in the directory coexistence process is the procedures used to transfer information between your directory service and the data sources. If these transfers are not protected with the same care that is used to protect data in the directory service itself, an attacker can potentially gain unauthorized access to data or even insert fraudulent data into the directory service.

There are a variety of techniques for protecting the transfer of data. If directory coexistence is maintained via LDAP, the normal security features of your directory, such as access control and Secure Sockets Layer (SSL) or Transport Layer Security (TLS) communication, can be applied. This is probably the best approach from a security standpoint; it minimizes the possible avenues of attack and allows you to focus your security design on the directory service itself. It also minimizes potential directory downtime that can be caused by non-LDAP data import.

If you choose an offline technique for transferring data to and from your data sources, consider other ways to protect the transfer. Several techniques are available, such as secure file transfer (for example, using the Unix scp or sftp commands), Secure Shell (the ssh command), encrypting the data itself and then transferring it via unprotected means, and so on. These techniques are described in more detail in Chapter 12, Privacy and Security Design.

Data Source Security

A final consideration in the protection of your directory coexistence solution is the security of the data sources themselves . If the data sources are not secured, there may be little point in securing the same data in your directory service. The reverse argument also applies: You should avoid making your directory service a security weak point. An attacker may simply be able to access or change data in the data source, bypassing all the security you have labored to implement for your directory service.

For example, suppose your directory obtains telephone number information from a telephone operations database. If this information is considered sensitive, you might protect it in your directory service via authentication, access controls, and other techniques. A determined attacker bent on inserting invalid phone number data for another user cannot do it through the directory but may be able to do it through the telephone operations database. After the data is changed in the telephone operations database, it will find its way into your directory service via your synchronization procedures.

Be sure to consider more than just physical and technology-related security issues. Personnel and procedural security are also important. The most secure data source in the world can be compromised if an attacker is able to call up an administrator and talk him or her into making unauthorized changes. Masquerading as a legitimate user, trickery , flattery, and downright bribery are all potential weapons at an attacker's disposal. Make sure your procedures guard against such attacks and that your personnel are aware of the possibilities. Maintaining audit logs and similar information about update and synchronization activity will help in tracking down the root cause if your data does come under attack.