In the past, administrators often thought of security as a standalone concern. For example, an administrator might focus first on network communications, then on user accessibility, then on security, and then on disaster recovery. Today, more and more administrators are realizing the truth about security: It’s everywhere. Security is something you have to think about during every step of your design process and during every administrative task you undertake. Consider Exchange 2000 Server as an example. Exchange relies upon Active Directory to secure individual users’ mailboxes. So long as Active Directory authenticates a user, they are allowed to access their mailbox. Active Directory, in turn, provides a number of robust authentication options: complex passwords, smart cards, and so forth. You might think that setting up Active Directory with a strong authentication mechanism is all you need to do to protect the contents of users’ mailboxes.
But Exchange also communicates over your network, and probably sends email over the public Internet, as well. Those communications are carried out using the Simple Mail Transport Protocol (SMTP), which is an unencrypted, unprotected means of transmitting data. No matter how secure you make Active Directory, anyone with a basic network analyzer and access to your network can eavesdrop on every message your users send.
The point is that security vulnerabilities can come from every aspect of your network. When I work as a consultant, I try to get my client companies to think of information security, or the various ways in which information could be compromised, instead of thinking about things like authentication, file permissions, and so forth. Information security is really your goal, while authentication, file permissions, and other security mechanisms are simply mechanisms to help achieve your goal. If you try to think about the various ways in which your information can be compromised, you’ll find yourself developing a more holistic, comprehensive security infrastructure.
In this chapter, I’ll leave the information security to you, and explain the various mechanisms that Windows and the .NET Enterprise Servers offer to make information security possible. I’ll cover authentication and authorization, communications security, file and database security, auditing and recordkeeping, and encryption basics. Once you understand these mechanisms, you can start applying them to your network designs to eliminate information security vulnerabilities.
In the simplest possible terms, encryption is simply a way to scramble information so that only certain individuals can read it. The secret decoder ring you got from a box of Cracker Jack when you were a kid allowed you to perform simple encryption, and the newer versions of Windows and the .NET Enterprise Servers use much more powerful encryption techniques in a number of different ways. In fact, just about every aspect of security provided by Windows or the .NET Enterprise Servers utilizes encryption of some kind, and it’s important that you understand how that encryption works.
| Many forms of encryption can be used with digital certificates and a public key infrastructure (PKI). For more information, see “Certificate Services,” p. 111 |
Modern encryption relies on complex algorithms and mathematical formulas. An algorithm is really nothing more than a carefully defined process. For example, you might have an algorithm for driving to work in the morning that shaves 10 minutes off of your commute. Computer encryption algorithms can use hundreds of different steps, and are often so complex that they are patented by the companies or individuals that create them. These algorithms often become known by brand names, such as the Data Encryption Standard (DES), a popular encryption algorithm supported in Windows.
Most encryption algorithms rely on keys, which serve a function similar to passwords. An encryption key is often a random string of numbers and letters, although it can be words and phrases, much like a password. Most encryption algorithms can accept keys of varying lengths, and the strength of the encryption (a measure of how difficult it is to decrypt data without a decryption key) is partially measured by the length of the encryption key. That’s also one way you might measure the strength of a user’s Windows password: A two-letter password can be guessed pretty rapidly through trial and error, while a 40-letter password might require years of effort to break. Encryption keys are usually at least 40 bits long, although 56-bit keys have recently become a more common low-end. At the high end, 128-bit and even 256-bit encryption is not uncommon, and even stronger encryption is in use by some organizations.
Computers rely primarily on three types of encryption: hashes, shared secrets (and symmetric keys), and asymmetric keys. Each of these forms of encryption has a specific purpose, and each has particular strengths and weaknesses.
A hash is one of the simplest forms of encryption. It simply scrambles data according to some algorithm, often in combination with an encryption key. The same key can be used to reverse the hash, resulting in the original, unscrambled data. The effect of a hash can be thought of as something like long division: Thirteen divided by five yields a result of two, with a remainder of three. Five represents your original data, while thirteen represents that hash’s encryption key. The result represents the hashed data. So long as you have the hashed data (two with a remainder of three) and the encryption key (thirteen), you can retrieve the original data (five).
One of the most common variants of hashing is a one-way hash. This variant performs a regular hash of data, but discards part of the result. Since only a part of the hash is retained, it is impossible to undo the hash. Returning to the long division example, it’s as if you only kept the two, and discarded the remainder of three. With only the encryption key (thirteen) and a part of the hashed data (two), you can never retrieve the original data. Windows itself uses a one-way hash to encrypt passwords before storing them in Active Directory (Windows can also store passwords using reversible encryption, although this is obviously less secure since it makes passwords recoverable). Although the encryption key used in the hash is reasonably well-known, Windows doesn’t store the entire hashed result. That means it’s impossible to reverse the hash and retrieve the original password.
Note
When the encryption key and hash algorithm are well known, it is possible to break a one-way hash. For example, one common form of password-cracking is called a dictionary attack. This attack takes common words and phrases and runs them through the hash, just like the operating system does. The attacker then compares the hashed result to a hashed password. If the hashes match, then the attacker knows what the password is, because he knows what went into the hash to begin with. These dictionary attacks are the main reason users should use complex passwords that don’t contain common words, and include a combination of letters, numbers, and symbols, which are less likely to be used in a dictionary attack.
A shared secret is simply a password which is known to both the encrypting party and the decrypting party. The secret is used as an encryption key in a normal encryption algorithm, and can be used to both encrypt data and then later decrypt it. Because the key is used for both the encryption and decryption operations, it is referred to as a symmetric key (meaning both key halves—decryption and encryption—are identical).
Shared secrets work fine for encryption, especially when the secret is especially long or complex. Unfortunately, shared secrets have to be carefully protected, because once compromised, everything encrypted with the secret is compromised.
Windows uses shared secrets in its normal authentication process. A user’s logon password acts as a shared secret between the user and the authenticating domain controller. Client computers also have passwords which enable them to log on to a domain. As with other shared secrets, if someone discovers a user’s password, then the password should be changed immediately. Fortunately, Windows doesn’t use shared secrets to encrypt any data for long-term storage, so a compromised password doesn’t necessarily mean you have to re-encrypt a bunch of confidential data files.
Shared secrets are a form of symmetric key encryption. Usually, the term symmetric key refers to a digital encryption certificate, where the same certificate (key) is used both to decrypt and encrypt data. Shared secrets work the same way, although they use passwords rather than digital certificates. Windows’s Encrypting File System (EFS) uses symmetric keys—digital certificates—to encrypt and decrypt files.
The most flexible form of encryption is an asymmetric key. As the name implies, an asymmetric key consists of two halves, one of which is used for encryption, and the other for decryption. These halves are commonly referred to as a public key and a private key. The two halves always go together, and are not interchangeable with other asymmetric key pairs. The private half of the key is always protected, and never sent across a network or disclosed. The public half of the pair can be freely sent to anyone. The private key can be used for either encryption or decryption; the public key always performs the opposite function. For example, suppose that you have a public/private key pair, and that I want to send some confidential data to you. You could send me your public key, which I could then use to encrypt the data. You would then use your private key to decrypt the data when you receive it. Only your private key could decrypt the data, and as long as your private key remains safe, anything encrypted with your public key will be for your eyes only.
The complex part about asymmetric keys (other than the incredibly complex mathematical formulas involved) is the distribution of public keys. Ideally, some centralized authority would create key pairs, issue the private key to the key holder, and make the public key available to anyone who needed to use it. That centralized authority is called a public key infrastructure (PKI), and the key pairs issued by a PKI are called digital certificates.
| For more information on digital certificates and their uses, see “Certificate Services,” p. 111 |
Windows makes use of PKI in ways you might not even realize. For example, whenever you visit a secure Web site by using Internet Explorer, PKI is in action. Your browser obtains the Web server’s public key, and uses it to ensure that data encrypted with the server’s private key can be successfully decrypted—effectively verifying the server’s identity.
Encryption pops up throughout Windows and the .NET Enterprise Servers. Here’s are some of the ways that you’ll see encryption used:
Windows uses shared secrets and PKI in all forms of authentication, including regular domain logons, remote access logons, and so forth.
Windows uses encryption to encrypt the contents of a virtual private network (VPN).
Windows can use encryption as part of IPSec network-level security, encrypting network traffic between clients and servers on your network.
BizTalk Server supports the use of encrypted connections when exchanging data over the Internet.
Commerce Server supports encrypted connections to ensure the security of customer information such as credit card numbers.
Exchange Server uses encryption for both digital signatures, which verify the identify of a message’s sender, and for basic encryption, which protects the contents of a message so that only intended recipients can view it.
Mobile Information Server supports various levels of encryption for different types of mobile devices, protecting transmitted information from wireless eavesdroppers.
SQL Server can use encryption to protect the contents of stored procedures, as well as encrypted connections to protect data from eavesdropping.
While this list is by no means comprehensive, it should give you a good idea of the pervasiveness of encryption technologies in Windows and the .NET Enterprise Servers.
The core principle behind any kind of security is simple: Only allow authorized individuals to access information. The idea of only providing access to individuals with permission is called authorization. A natural companion of authorization is authentication, which is the process of validating someone’s identity. These concepts are true for all forms of security, not just computer security. For example, many companies use card-keys to secure the doors in the company’s offices. Individual employees must prove their identity to obtain a card-key, and that authentication step is usually handled during the hiring process. Once they have a card-key, employees must be authorized to open specific doors. Computer systems implement authentication and authorization a bit differently, since they don’t have the human capacity to recognize, for example, Joe’s face and let him in even though he forgot his card-key.
Many companies require users to authenticate several times throughout the day. The first authentication is usually done by logging on to a Windows domain, or perhaps a Novell Directory Services tree. Employees may have to log in a second time to access their email system, and then again to access a file server. The beauty of Active Directory and the .NET Enterprise Servers (and one of their biggest selling points) is the ability to provide employees with a single sign-on. That means Active Directory handles the authentication for all of the .NET Enterprise Servers and other network services, authenticating each employee once, and then automatically providing the employee’s credentials to other network services as required.
Windows 2000 and Windows .NET Server actually support two basic authentication methods. The first is called NTLM. NTLM is the native authentication protocol use in Windows NT domains, and is the only authentication protocol understood by the Windows NT, Windows 9x, and Windows Me operating systems. Microsoft introduced a slightly stronger version of NTLM in Windows NT 4.0 Service Pack 4, called NTLMv2. Windows 2000 introduced a new, more robust authentication protocol called Kerberos. Kerberos is actually an Internet standard protocol that has been in use in the Unix world for quite some time; Windows 2000 and higher operating systems all support Kerberos in addition to NTLM (and NTLMv2), and you can configure Windows 2000 to only accept the more secure Kerberos protocol.
In their simplest form, both protocols authenticate a user based on a single factor: their password, which is something every user knows. Passwords are the most common authentication factor in the world, and most users understand how to use them, even if not all users do a great job of selecting good passwords. Because passwords can be easily lost, and in many cases easily guessed, Windows 2000 also introduced the capability of using smart cards for authentication.
Smart cards are credit card–sized devices with a small microchip embedded in them. The chip contains a public/private key pair, which can be unlocked through the use of a personal identification number, or PIN. To log on with a smart card, a user simply inserts the card into a reader, which is attached to their computer, and types their PIN. This type of logon is called two-factor authentication, because it requires something the user knows (their PIN) as well as something they have (the smart card itself). Smart cards are much more secure, because it’s obvious when they’ve been lost, unlike a password which users might never realize has been compromised. Lost smart cards can be easily deactivated, rendering them useless to an intruder.
Less common authentication methods are based on the user’s body. Fingerprint scanners, retinal scanners, voice analyzers, and other biometric authentication methods are theoretically impossible to lose and difficult to compromise, although these methods are currently expensive and, given the current state of biometric technology, less than totally reliable.
Regardless of the authentication mechanism used, Active Directory takes the responsibility of verifying the user’s identity. Once verified, all of the .NET Enterprise Servers will take Active Directory’s word on the subject, providing the user with access to any resources that they are authorized to use.
By itself, authentication isn’t terribly useful. After all, having a domain controller agree that I am who I say I am might feel like a personal validation, but it’s not actually productive. Authorization, the mechanism of deciding what I actually have access to, is what security is all about. Of course, authorization couldn’t exist unless I proved my identity, which is why authorization and authentication go hand-in-hand.
Windows’s and the .NET Enterprise Servers’ security is based on an authorization technique called an Access Control List, or ACL. An ACL is simply a list of the users who are allowed to use a particular resource, a list of users who are specifically prevented from using a resource, and a list of what authorized users are allowed to do with a resource (such as read it, change it, delete it, and so forth).
Note
Some products allow ACLs to contain users, groups, and computers. For example, Windows itself allows all three types of entries in its file security ACLs.
The actual means of setting access permissions differs from product to product (and I’ll cover them in Part III), but the basic concepts of how an ACL work are universal. When a user attempts to access a resource, Windows (or the appropriate service) checks the ACL as follows:
If the user doesn’t appear on the list, and if the user doesn’t belong to any groups on the list, then they don’t have access.
If the user appears on the list with a “Deny” permission, or if the user belongs to a group that has “Deny” permission, then they don’t have access. Deny permissions always override any other access permissions that a user may have.
If the user appears on the list, or if the user belongs to a group that appears on the list, then they are granted the access on the list. Access permissions are usually cumulative, so if a user has Read permission, and belongs to a group that has Delete permission, then the user’s effective permissions include both Read and Delete.
Note
The preceding process is a generic description of how ACLs are used. Different products have different permissions. For example, Windows’s file permissions allow you to assign or deny specific rights, such as Read or Change. Active Directory includes permissions for various operations, such as creating new directory objects. SQL Server tracks permissions for various operations, as well as for database objects such as tables and views. In all of these cases, however, ACLs are used to determine what access a user has to each resource.
Authentication and authorization can prevent users from accessing files, but they don’t provide any protection for the files when they’re in transit over a network. In fact, some of the US government’s earliest standards for computer security required that the computer be disconnected from any type of network, ensuring that data couldn’t be compromised during transmission. Today, the idea of having a computer not connected to a network seems pointless. After all, computers are designed to work together, and networks make that integration possible. Fortunately, technology has caught up with modern security needs, providing a number of technologies to secure data while in transit.
Many network security mechanisms involved special protocols, such as the Secure Sockets Layer (SSL) protocol used to encrypt data sent between Web servers and browsers. Other common protocols have secure variations, designed to secure specific types of traffic (such as secure SMTP for encrypting email in transit). In the next two sections, though, I’ll introduce you to two generic technologies for securing just about any type of network communications: the IPSec protocol and virtual private networks, or VPNs.
IPSec is a protocol for network-level security. IPSec is built around a set of rules, which you can configure, and actions, which you also configure. For example, you might create a rule which requires all client connections to a particular server to be encrypted, and an action that allows encrypted traffic and ignores unencrypted traffic. You might create a rule that looks for a certain type of network traffic and then encrypts it (which is one way VPNs can work, as I’ll describe in the next section).
Although IPSec has obvious uses on a public network such as the Internet, where encrypting data is the only way to ensure confidentiality. IPSec also has uses on a private network. For example, your company’s research and development department might work with a lot of proprietary, confidential data. By configuring IPSec to encrypt communications between the department’s client computers and servers, you can ensure that unscrupulous employees or intruders have no access to the data, even when it’s being transmitted over the network.
VPNs are capable of turning an insecure, public network—like the Internet—into a secure network that seems like a private network. In fact, that’s where the name comes from: the ability to create a virtually private network on an otherwise insecure public network. VPNs actually have two components: a tunnel and encryption. The tunnel is a process that bundles up multiple streams of network traffic into a single stream, which is then sent to the destination. At the destination, the traffic is pulled apart into its original multiple streams. The effect is a lot like multiple lanes of highway traffic merging into a tunnel that goes under a bay or harbor, and then splitting back out into multiple lanes at the other end of the tunnel.
By itself, the tunnel offers convenience, but not security: It’s not that difficult to intercept the tunneled traffic and figure out what’s going on, if you’re a skilled network engineer. Security is provided by encryption, which simply encrypts the entire tunnel. The tunnel is decrypted at the destination, allowing the traffic to proceed normally. The end result of a VPN is many data transmissions using almost any TCP/IP protocol (SMTP, FTP, HTTP, and so on) being squashed together into an encrypted data stream. At the other end, the data stream is decrypted and expanded into the original traffic, where it can go to its final destination.
Windows supports two VPN protocols. The first is the Point to Point Tunneling Protocol, or PPTP. PPTP was invented in part by Microsoft and is pretty much found only in Microsoft products, like Windows 95 and higher. PPTP combines tunneling and encryption into a single, easy-to-configure VPN protocol. PPTP’s one major flaw is that only the contents of the tunnel are encrypted; the tunnel itself is transmitted in the clear, so an eavesdropper can at least determine that a PPTP tunnel is in use, which is one step closer toward breaking into the tunnel and compromising the contents (which would involve potentially hundreds of hours of computing time). PPTP also uses fairly weak encryption, making it more likely that a determined hacker could break through.
Windows’s second VPN protocol is the Layer 2 Tunneling Protocol, or L2TP. L2TP is an industry standard, supported by Windows 2000 and higher and by almost every non-Microsoft VPN technology on the market. L2TP only provides tunneling capabilities, not encryption; the idea is that you would also use IPSec rules to encrypt L2TP traffic, resulting in a secure tunnel. Because IPSec performs the encryption, the tunnel itself is encrypted, increasing the security of the tunnel’s contents. The downside of L2TP is that it’s more difficult to configure than PPTP, and usually requires a public key infrastructure to function properly. L2TP isn’t supported by Microsoft operating systems before Windows 2000, so PPTP is still the best option for allowing older clients to securely connect to the corporate network over the Internet.
VPN tunnels are a marvelous addition to any network that includes .NET Enterprise Servers. VPNs enable you to connect to your corporate network from home, using your regular Internet service provider (ISP), to manage all of your network resources. VPNs can also be used to secure connections between branch offices, enabling users to use their ISP as a private connection to the main office. VPNs can also secure connections between your company and its business partners, providing security for BizTalk connections, Web site traffic, and much more.
A major aspect of information security is controlling access to information contained in files and databases. In a Microsoft environment, that means utilizing NTFS file permissions and SQL Server database permissions to control access.
Note
NTFS file permissions lie underneath many of the .NET Enterprise Servers. For example, Commerce Server doesn’t implement its own security for Web pages. Instead, it simply relies on the NTFS permissions on the Web page files themselves. Application Center and Mobile Information Server work similarly, just as IIS itself does. Make sure you know how the .NET Enterprise Servers rely on Windows’s built-in file security to protect their data.
NTFS file security is in many ways the perfect implementation of ACL-based security. Every single object on an NTFS partition—every file and every folder—has its own ACL. Those ACLs can contain any number of user or group entries, and each entry can have a complete, custom set of permissions. NTFS enables you to assign Allow or Deny permissions for each operation that can be performed on a file or folder. The Deny permissions can be especially useful when combined with group permissions. For example, suppose you have a folder full of Word documents that you need to secure. Your access requirements are as follows:
Members of the Accounting group must have Read and Write access to the files.
Members of the Marketing group must have Read access to the files.
Members of the Payroll group must have Read access to the files.
Some members of the Accounting group are also members of the Payroll group. Those employees must only have Read access to the files.
These permissions are easy enough to set using NTFS ACLs. You’d apply the following permissions:
Accounting group: Allow Read and Allow Write.
Marketing group: Allow Read.
Payroll group: Allow Read and Deny Write.
Another nice feature of NTFS permissions is inheritance. Inheritance enables you to configure permissions on one object, and have those permissions flow down through the object’s children. For example, if you set permissions on the D: drive to allow Everyone the Read permission, then all subfolders and files on the D: drive would inherit that permission. You can also block inheritance on any particular file or folder, stopping it from inheriting permissions from its parent object and applying specific permissions of your own.
| For more information on NTFS file permissions, pick up a copy of Special Edition Using Windows 2000 Server. |
An important—and often-overlooked—aspect of security is the need to maintain a log of activities that impact security. Logs are invaluable in determining where a security vulnerability exists, and in determining how often a vulnerability has been exploited, and by whom. While both Windows and most of the .NET Enterprise Servers provide auditing and logging capabilities, none of these capabilities are integrated in the slightest fashion. Instead, the operating system (indeed, each aspect of the operating system) and every .NET Enterprise Server uses its own methods for auditing and logging security events. For example
Windows DNS saves information to its own event log, not the standard Windows Security event log.
SQL Server has its own internal log files for tracking security information, which must be queried from within SQL Server itself.
Exchange Server writes to the standard Windows Security event log, but you have to manually configure the level of logging you want.
The one common aspect everything shares is the Windows Security event log. While most of the .NET Enterprise Servers write security events to that log, they tend to write more detailed information to their own private logs, making security administration a bit of a chore.
In this chapter, you learned about the basic security concepts that the .NET Enterprise Servers are built upon, and about the basic security services provided by the Windows operating system. Understanding the underlying security of the Windows operating system and the basic security concepts behind the .NET Enterprise Servers will help you identify potential security vulnerabilities within your network design. Identifying vulnerabilities is, of course, the first step in eliminating them! By working with the security features of the Windows operating system and the individual .NET Enterprise Servers, you can implement the exact level of information security required by your organization.