Analyzing Your Security and Privacy Needs

   

Now that you have an idea of the kinds of threats your directory may face and the tools at your disposal to protect against them, it's time to turn your attention to analyzing your environment to determine your specific needs. It's important to tailor your security design to your environment and the needs of your users. Failure to address security needs can compromise your entire service and make an otherwise successful deployment fail. On the other hand, if you design a system that imposes needless and cumbersome security constraints on your users, the service can easily become unpopular, go unused, and fail.

The key to finding the right balance is to understand your other directory design requirements (and how they affect your security design) and the security needs of your environment and your users.

Directory Requirements

Many aspects of the directory design we've discussed up to this point have an impact on security, and vice versa. Some of the more important design decisions that affect security are covered in the following sections.

Read or Write

If you allow users or applications to update the directory, you may require more security. Directory write operations are often held to a higher standard of authentication than directory read operations. For example, you might decide that simple password-based authentication is sufficient to read information from the directory, but to update that same information, a client must authenticate using a public key certificate over a protected SSL connection. With this setup, you can be confident about the integrity of the data in your directory and changes to that data received from clients . You can be less confident that only authorized users are accessing the directory, but you can still maintain some level of assurance.

Sensitivity of Data

Understanding the type and sensitivity of data in your directory is one of the most critical aspects affecting security. If your directory contains publicly readable information, there may be no need for access control. You still may need to be concerned about the integrity of the information, however.

If there are different sensitivity classes of data in your directory, you need to consider how best to protect each one. For example, you may consider name data to be public data and therefore require minimal protection. On the other hand, a directory that contains Social Security numbers or salary information calls for a much greater level of protection.

A useful design exercise is to list all the attributes that will be held in your directory and try to categorize them according to their sensitivity and the type of access and protection required for each one. Table 12.1 shows an example of this kind of categorization. After you choose your directory software, you can use this table to help design your directory access control.

Replication and Synchronization

If your directory is replicated or synchronized with other data sources, you need to be concerned about the security of the data when it is in transit. It's not much good to protect the data if you pass it among servers without similar protection. Also, if your architecture calls for copying data outside your own domain of control (for example, onto every LAN), many copies of the data will exist, not all of which will necessarily be held to the same stringent security requirements you place on your own machines. In other words, it's not much good to use directory access control to protect entries if they will be synchronized to machines controlled by some of the people against which you're protecting the entries!

Think about the network links between replicas. If they are secure, or at least free from access by users, it may be acceptable to pass directory replication updates in the clear. On the other hand, if replication updates must traverse networks accessible to users who may be potential security threats, you'll probably want to protect replication exchanges from eavesdropping, tampering, and other security threats. Replicating over connections secured by SSL might be a good choice in this situation.

Table 12.1. A Sample Categorization of Attributes by Sensitivity

Attribute

Sensitivity

Accessed by

Updated by

  cn  

Low

Everyone

Administrator

mail

Medium

Everyone

User , administrator

salary

High

User, administrator

Manager

uid

Medium

Everyone

Administrator

For planning the security of a replication architecture, we've found that network diagrams are helpful. Start by drawing a diagram representing the replicas or other copies of directory data you plan to create and indicate the security level of each network link involved. Then label each copy with its physical and administrative security levels.

Figure 12.2 shows an example of such a diagram. In this case replication updates between the master and first-level replicas may not need protection from eavesdropping because they occur over a network within the corporate data center that is physically inaccessible to users. However, replication updates between the first- and second-level replicas probably do need protection because they occur over user-accessible networks.

Figure 12.2. Replication and Network Topology

Administration

If your directory administrative model calls for delegation, you must be concerned with the privilege level granted to subordinate administrators and their ability to increase their own privilege levels.

You also need to be concerned with other aspects of the administrative environment of your directory. Recognize that you will probably need administrators of the service itself who are different from the administrators of the content held by the service. Service administrators start and stop the service and make sure that it runs smoothly, is configured correctly, and is replicated properly. Typically, this function is performed by an experienced system administrator. Content administrators are responsible for day-to-day administration of directory content, adding and deleting users, resetting passwords, and similar tasks . Typically, this function is performed by data-processing staff, administrative assistants, and sometimes users themselves . The two types of administration require different kinds of security considerations.

Understanding Your Environment

Analyzing your environment is another important prerequisite to understanding your security requirements. If you understand your environment, you will have a good idea of the kinds of threats your directory will face. On the basis of these threats and the other information you collected previously, you'll be able to choose appropriate safeguards for your directory. At a minimum, consider the user community, directory accessibility, network environment, and physical security.

The User Community

Think about the community of users who will be using your directory. Are they employees of your company who have employment contracts and other incentives not to misbehave and create directory mischief? Are they students with far too much time and cleverness on their hands? Or are they perhaps e-commerce partners who would dearly love to obtain information about each other? Obviously, different user communities require different security measures.

Directory Accessibility

Think about how widely accessible your directory needs to be. Does your directory need to be directly accessible from the Internet? If so, your firewall will need to allow users to connect directly to the server's LDAP or LDAP-over-SSL ports. When you make a server directly accessible to the Internet like this, you need to be vigilant and apply vendor security patches whenever they are made available.

In the Internet case, your directory is available for the world to access. Even if no information in your directory is accessible to users who have not authenticated, there is still a significantly increased risk of exposure to security problems. Attackers have free reign to probe your directory for weaknesses, your directory is more vulnerable to DoS attacks, and any security holes in your directory can be more easily exploited.

On the other hand, if your directory is accessed by only a set of application servers that provide the business logic for an e-commerce application, you can put the directory servers and application servers behind a firewall and prevent direct attacks on your directory servers. This arrangement increases the security of your system and is a common configuration today. However, it is not a panacea, and it effectively shifts the burden of network security to those maintaining the Web servers and application servers.

Your decision about how much security is required depends more on the consequences of a security breach and the attractiveness of your data and organization as a point of attack. If your organization is prominent ( especially among the computer-literate), you can count on being a more likely candidate for attack by the mischievous or malicious. Typically, attacks of this kind are motivated by a desire for notoriety (or sometimes revenge , in the case of a disgruntled ex-employee, for example). There is little chance that a security breach will go unnoticed; one of the goals of the attacker is to make his or her breach of your security known.

If the data held in your directory is especially valuable , you can count on being a prime candidate for attack. This kind of attack motive can be more problematic because it is often in the attacker's best interest to conceal the fact that any security breach has taken place. Indeed, attackers in search of credit card numbers, competitive analysis information, or other sensitive information may find the information they steal worthless if the fact that it has been stolen is revealed.

The Network Environment

One of the most vulnerable points in your directory service can be the network over which clients access the directory and over which directory servers communicate with each other to pass replication updates or perform other server-to-server communication. You need to understand these vulnerabilities and their implications for security.

To improve your understanding, create or obtain a map of your network's topology, such as the one shown in Figure 12.2. Make sure you understand all the paths between your servers and between servers and clients. If these paths are susceptible to eavesdropping by unauthorized entities, you must find another way to protect directory data as it travels on the network. One such vulnerable configuration that needs protection is a network in which your server and client machines all share a single Ethernet segment. Any client on this network can easily listen in on traffic not intended for it. A good option might be to require SSL for client/server and server/server communication. With this requirement, eavesdropping does an attacker no good because the traffic is encrypted.

If these paths are not susceptible or at least are not wide open to access, SSL may not be required. An example of this situation might be a configuration in which your server network is physically secure. Perhaps a fiber- optic link (difficult to tap) connects your server network with your user networks, and your user networks consist of switched Ethernet hubs connecting user machines. In this environment it is much more difficult to eavesdrop on traffic not intended for you. However, it is not impossible , especially if one of the other servers on the server network is compromised and a hostile network sniffer program is installed.

Physical Security

The physical security of your servers is important. As we pointed out previously, securing your network and administrative procedures does not necessarily do you a lot of good if the physical security of your directory server machines is not protected. You can take various steps to ensure a high level of security.

Make sure that your server is kept in a room accessible only to authorized users. In high-security environments, you may want to employ cryptographic smart cards or biometric security procedures to permit entry to the room and use of the server. A retinal scanner is an example of a biometric security device.

Understanding Your Users

A factor often overlooked in security design is the needs of your user community. Understanding how your users will use the directory and view the data it contains, and what their security expectations are, will go a long way toward helping you design a security infrastructure that will make them happy. And their satisfaction, in turn, will go a long way toward making your directory service successful and yourself happy.

How your directory will be used, both by users and applications, can have a significant effect on the security needed by your directory. For example, a directory used for phone book searches and other noncritical tasks certainly has lower security requirements than a directory used to support e-commerce transactions for a high-volume business-to-business Web site.

How your users view the data in your directory is also a relevant factor. A directory that contains personal, but not secret, information about users may not need high security in your point of view, but your users may feel differently. You should be sensitive to these needs. Your users may have a sense of ownership about the data in the directory and strong feelings about how it should be protected from unauthorized access and certainly from unauthorized tampering. They may also feel differently about specific attributes such as home addresses and phone numbers. Be prepared to defend your security policy for each attribute in your directory, or be prepared to have a flexible policy that can be changed by request on a per-user basis. Document your policy and share it with your users.

Designing a flexible access control policy can be helpful. For example, suppose that your directory is accessible both inside and outside your organization and contains both home and work address and phone information. The possible access combinations for these sets of information, for clients inside and outside your organization, are given in Table 12.2. If you were to poll your user community, you would probably find out that there are plenty of users who want each combination.

Table 12.2. Possible Access Combinations for Home and Work Information Inside and Outside an Organization
 

Accessible Inside?

Accessible Outside?

Home information

Yes

Yes

 

Yes

No

 

No

Yes

 

No

No

Work information

Yes

Yes

 

Yes

No

 

No

Yes

 

No

No

Some of these combinations may appear strange , but chances are that each one is desired by one or more of your users. For example, it may seem unusual to want home information accessible to outsiders but not to your fellow employees. But one reason might be that publishing a home telephone number to colleagues could encourage them to call you at home ”which you might want to discourage; however, you might want friends across the world to have access to your home phone number.

How do you provide a flexible access control system that allows your users to choose the model most appropriate for their needs, yet without creating undue administrative burden for either them or you? Although there is no single answer to this question, it is important to understand the capabilities of your software's access control features and how they deal with situations like this.

Understanding Your Corporate Policies and Applicable Laws

When designing security and privacy policy for your directory, you need to be aware of corporate policies that apply, as well as any relevant state or federal laws.

For example, your corporation may have a written policy that describes who may have access to sensitive employee information. Your directory's access control configuration needs to comply with this policy. In addition, legal requirements may be imposed by state and federal governments concerning the privacy of your directory data.

It's always a good idea to sit down with the relevant departments in your organization, most likely the Human Resources department and your Legal department, and get them to sign off on your security policy. If your organization has a chief security officer (CSO), be sure to involve him or her as well. Maintain a good working relationship with these groups and be sure to involve them when any unusual events occur. For example, if you become aware of a security breach, or you are approached by a law enforcement official with a search warrant , you should immediately inform all these groups and keep them apprised throughout the resolution of the situation.

   


Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 2002
Pages: 242

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net