Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Corollaries: Principles That Spring from the Classics

Although the classic three security principles can be used to describe just about every security technology and practice, additional security principles have grown from them and from the experiences of security practitioners. If you examine these principles, you will see how many of your efforts for hardening and defending your information systems and their data fit into the greater picture. Put these principles together with those described earlier in this chapter, and you will be able to anticipate ways to protect your systems now and in the future.

Defense in Depth

No security device or hardening technique alone will protect your information systems. Defense in depth means using multiple layers of security. Although there is no guarantee that layering security will prevent compromise, developing such defenses has proven in the past to be more effective than relying on a single defense.

An example of defense in depth used to protect sensitive files is shown in Table 1-1, as are the Windows Server 2003 technologies that could be used to provide this protection. For this example, assume that the files in question are in a folder on server A on a private network.

WARNING: Defense in Depth Does Not Mean Every Defense Must Be Used

Use common sense when using any one approach to defense in depth. For example, I wouldn't necessarily use all of the defense strategies listed in Table 1-1. The defenses that you should use depend on the risk and the nature of the files to be protected, and they should be balanced by the need to administer the server and make the data available to those that are authorized to use it.

Psychological Acceptability

Psychological acceptability means that the security implementation does not cause fear, distrust, or undue anxiety for its users. Security that is psychologically acceptable will be more likely to be used. Examples of psychological issues with security are as follows:

Users of hand geometry biometric devices often fear that their hands will get stuck.

Users required to use a retinal scanner may fear catching some eye disease or injury to their eyes.

When fingerprint readers are introduced, users may fear that their fingerprints will be shared with some law enforcement agency or kept in a database that might be used for some nefarious purpose.

An application may seem threatening, abusive, coercive, or hostile because of its language, graphics, or the way it works. Security implementations can also produce this feeling.

Users may get unduly concerned about having to use very long passwords that they can't write down. They may fear punishment if they forget their passwords.

Do not approach these psychological issues as silly, unwarranted fears, and most especially don't reject these security approaches because they might seem psychologically unacceptable at first glance. Instead, realize that these objections and fears do exist and may be heightened or eliminated depending on the way that these security techniques are implemented. You can overcome fears with awareness and product training and by treating voiced concerns as legitimate. You can obtain acceptance if you don't ignore these concerns.

Evaluate the psychological impact of any current security implementation look for improvement. Always consider this effect when reviewing new implementations.

Least Privilege

The principle of least privilege requires that no one be given more access or rights than are necessary to do his job. Users, for example, do not need to be administrators to do ordinary work. There are applications that will not run without elevated privileges. While you work on eliminating these products, or in configuring systems to limit their privileges, you may have to continue to provide users elevated privileges. When elevated privileges are required, make them machine-dependent. There is no reason to make users domain administrators. Windows Server 2003 provides the ability to assign user rights and object (file, printer, registry, folder and, in a domain, Active Directory) rights in a granular fashion. Use this ability. In a domain, very granular administrative privileges can be designed by using Active Directory object permissions and delegating control over AD objects. Examples of least privilege include:

Creating a custom Windows group called Help Desk and assigning it permissions such as the ability to reset passwords or create user objects at an organizational unit level. By adding help desk employee user accounts to the Help Desk group, you give them these privileges but do not make them full administrators.

Limiting database server administrators to the local server administrator role.

Investigating why an application requires a user to be an administrator and giving users appropriate access to the files, folders, and registry keys that the application actually uses instead of making them administrators.

Limiting external users (customers, vendors, the public) to special servers and only to certain data and privileges on those servers.

Implement a Security Policy

If you don't establish a security policy, your security status will be subject to the whims of those with the ability to modify it. A security policy is developed based on a risk analysis of the organization and its information system needs, requirements, and assets. It must be approved and backed by management, and there must be consequences for not following it. A security policy is a formal document that expresses the will of the organization, and it should be separate from a discussion of the technology required to implement it (although it may drive technology purchases). The security policy establishes who is responsible for implementing it. Procedures must be written to specify how technology controls and standards will be implemented to enforce the security policy. Windows Server 2003 provides support for technology controls by using Group Policies, local security policies, object permissions, and other technologies.

Separation of Duties

Long before computers existed, organizations realized they must protect themselves from employees and other trusted individuals who might steal from the organization or otherwise engage in fraudulent activities. Separating duties attempts to make this more difficult by ensuring that two or more individuals are required to perform sensitive operations. For example, accounting best practices split the process of ordering supplies and paying for goods received. One group of people is allowed to issue purchase orders, and a different group must approve payment. The idea is that if one individual had both privileges, she could issue a purchase order for goods from a fake company for which she has established a bank account and then write a check in payment for a product never received. If those duties are separated, the dishonest employee would have to collaborate with at least one other individual to commit the fraud. Although this collaboration would not be impossible, it would be harder to accomplish than acting alone, and it would be easier for the company to discover it.

You should also implement separation of duties on computer systems. For example, when PKI is implemented, different groups should be assigned the role of certification authority (CA) administrator (who manages the CA policy) and certificate administrator (who manages the certificates issued by the CA). In an Active Directory forest, you should assign data administrators (those who manage users, servers, and data) and a different group of infrastructure administrators (those who manage network services and the Active Directory). Computer solutions are not always easy to deploy. The necessary distinctions between some roles may not be possible, or your organization's management structure may not allow it. For example, although you can create data administrators who cannot exercise infrastructure administrator duties, infrastructure administrators are able to manage data. More than technical controls will be necessary here.

Complete Mediation

Complete mediation means applying a thorough solution. If, for example, you will use EFS to encrypt files, you should understand that access to EFS encrypted files is available to the user who encrypted them and any user who knows that user's account and password. Training, the use of a strong password policy, and other efforts will be necessary to make the solution robust. As a second example, consider that the use of local accounts to protect a computer becomes useless if an attacker obtains physical access to the computer and is able to use a boot disk to boot to another OS and a password insertion utility to change the Administrator password on the computer. A password insertion utility does not crack passwords; instead, it replaces the current Administrator password with one of the attacker's choosing or makes it blank. Techniques exist to mitigate this type of attack, such as removing the floppy drive and other types of bootable accessible drives such as CD-ROMs. To protect the computer, you must apply physical security. Approach all security solutions with this in mind. Can the security you implement be easily bypassed? What is necessary to close that hole?

Keep Up-To-Date

In today's world, it sometimes seems as if every day brings some new threat to information systems. You must keep up-to-date on these threats and understand your own systems to know if current security provides adequate protection, or if other measures such as applying a patch or changing a configuration must be done. Patching against known vulnerabilities and keeping service packs current is the primary activity here. However, knowledge of current infrastructure and its security hardening status is also an important issue.

Use Open Designs

Open designs are designs that are well documented. This means that anyone can study them and make their own informed decisions on what they can do to offset any actual or perceived vulnerabilities or to reject the use of the design. Encryption technologies were once based on keeping the encryption process secret. It is now believed that the encryption algorithms should be available so that anyone can study them. Instead of secret processes, keeping the encryption keys secret prevents decryption.Chapter 5 of this book.

Reduce the Attack Surface

Take this lesson from military historians and practitionersthe smaller the attack surface available to the enemy, the less chance your attacker has of overcoming you. Not only is there less to defend, but vulnerabilities, even those unknown to you, cannot be used against you if they are not present. In information systems, you can reduce the attack surface by not installing services and applications that are not required, disabling those services that cannot be removed, and configuring applications to provide fewer features. Do not, for example, install IIS on non-web servers. Do not add services offered by IIS unless they are required. (By default, IIS is not installed, and when you install it, it is installed with few capabilities.) In addition, inspect services turned on by default. If they are not required, disable them. This principle can also be applied to other technologies. For example, you should remove drives and disable unnecessary USB and serial ports, and you should teach employees how to respond to social engineering attacks.

Fail-Safe Defaults

Security doesn't always work, but if a security device or application fails, it should not allow open access. The easiest example of this principle is the firewall. If a working, properly configured firewall is disabled, it should prevent access to the internal network. This dictum does not mean that a firewall should fail unless it is configured properly. (If an administrator opens all ports to the Internet, no firewall will prevent him.) It does not mean that when an administrator decides to turn off protections such as anti-virus or remove configuration such as file permissions, the application should somehow protect him from the consequences.

Trust but Audit

To manage information systems, trust must be granted to users and administrators. Privileges of any sort can be abused, either through ignorance or malice. Thus, you should audit information systems to observe the behavior of trusted individuals and groups of users.

Provide Training and Awareness for Everyone

The more that you learn about security, the more you will recognize the importance of people in the security equation. It matters little what security you apply if you have not hardened your users to correctly respond to social engineering attacks and to avoid insecure practices such as sharing account IDs and passwords. Administrators have elevated privileges on systems and yet often lack basic information security training. This is not a sound practice. Instead, develop security awareness appropriate for different groups of users and insist that all of them take advantage of it. Specialized security training may be necessary for those who implement security or those who work with sensitive data and systems. However, specialized training for the few cannot take the place of broad training programs for all.

Economy and Diversity of Mechanism

This principle may appear at first to present a conundrum. How can you use few security mechanisms and yet use many different ones? It also may appear to conflict with other principlesHow can you use defense in depth if you must economize? The fact is that you sometimes may have to choose which principle to employ and how far to go with it.

Economy of mechanism does not mean that you should apply the cheapest or least intrusive solution. It simply means that where simple security solutions exist, or where you can do less work for the same or close to the same results, do so. You don't have to read and analyze every bit of code that you run. You define trusted code sources and select applications that can be protected. Correct documentation is far better than millions of lines of actual code that you must digest.

Diversity of mechanism means that you should avoid using the same solution for everything or the same applications and hardware. The intent is to prevent a vulnerability or security failure from allowing an attacker access to everything. For example, if an external firewall and an internal firewall are used to provide a zone in which Internet-accessible computers such as web servers are located, both firewalls provide protection for hosts on the internal network. Best practices indicate that a different firewall should be used at each location. Should the external firewall be compromised, an attacker probably would not be able to use the same vulnerability to compromise the internal firewall. Diversity of mechanism is often interpreted as preventing your network from running only one operating system. Thus, you could apply this principle to Windows networks by using other types of clients and servers on the network. You can also make a strong argument in both the firewall and operating system examples for the need for technical experts in different firewalls and OSs. If they are not available, then the networks will actually be more vulnerable because security may be improperly applied or not applied at all.