Chapter 16 - Product Security

This chapter introduces some of the security features of the Microsoft Windows NT operating system and explains how to use them with Microsoft SQL Server 7.0 and other applications in the BackOffice family of products. The chapter focuses on how these components use Windows NT security features. It also provides information about the enabling technologies that make it easy for applications to use the security features and the basic security principles on which the features rest.

 

Security in the Enterprise Environment

The Microsoft approach to security is based on six fundamental principles:

authentication

Identifies the user, and the all-important single-logon automatically promulgates this identity to all local and remote services.

access control

Restricts access to data based on that identity.

cryptography

Protects the privacy and integrity of data, especially when in transit across a network.

firewalls

Restrict traffic between your LAN and an external network, such as the Internet.

system integrity

Ensures the underlying security software cannot be tampered with.

auditing

Records security events.

 

Authentication and Access Control

The root of enterprise security lies in controlling access to data—that is, in controlling each user's ability to see, modify, and delete data. Data can be extremely diverse, including:

• E-mail, address books, or collaborative documents (such as those in Microsoft Exchange) 

• Heterogeneous data stored in centrally managed relational databases (such as Microsoft SQL Server) 

• Communications with host mainframes (perhaps managed by SNA Server) 

• Information on a Web site (perhaps accessed by Internet Information Services) 

• Documents that you download using Windows NT Remote Access Service 

• Simple memos on your desktop computer 

Although there is no single security mechanism for handling all of these cases, the principles for handling them are relatively simple and stem from a basic, well-understood set of threats.

Security starts with legitimate users: employees, system administrators, business partners, and customers. You do not trust them all with the same information. The process of identifying these users is called authentication (or simply logging on). As with most commercial operating systems, passwords dominate authentication in the Windows NT arena, though smart card authentication may soon be available as a common, cost-effective alternative. Although the public key certificates (see "Certificates" later in this chapter) are often a critical component in network-wide authentication, a password or smart card always unlocks the first door.

Single-logon is perhaps the most important property of Microsoft authentication. Under single-logon, you first log on to the workstation running Windows NT. For the duration of your logon session, your identity is automatically and securely passed to all the local and network services you request. With single-logon you do not have to remember alternative usernames or passwords, or use them in interactions that can compromise them. Single-logon also makes it easier to incorporate advanced authentication techniques, such as smart cards. Although single-logon may sound simple, it requires a great deal of infrastructure and is a key goal of the enabling technologies, which are described later in this chapter.

Establishing the user's identity is only half the challenge. The other half is attaching information to various data objects denoting who can and cannot access that object and in what manner (read, write, delete, change access control permissions, and so forth). Access Control Lists (ACLs) appear throughout the Windows NT enterprise environment, and those on the Windows NT native file system (NTFS) are the very basis of its security. Briefly, an ACL is a list of Windows NT users or user groups with access permissions for an object. The permissions are usually targeted to the object the ACL protects. For example, shared printers typically have Print and Manage permissions, and files and directories have Read and Write permissions. In some cases users who create an object manage its ACL, but in other cases management is restricted to administrators.

Cryptography and Firewalls

Although authentication and access control provide adequate protection with regard to legitimate users, security is also concerned with unidentified, illegitimate, and usually unseen attempts to penetrate a system. These attempts pose two major threats. The first threat involves attacking data that is in transit across a network (or perhaps stored in an intermediary location, such as a mail server). The attack may involve eavesdropping on your data, modifying it, or attempting to impersonate you on the network. The only solution to this type of threat is cryptography.

The second threat seeks to introduce a malicious program (for example, a Trojan horse or virus) into your system, and is particularly virulent in the Internet environment. Microsoft Internet Explorer contains special cryptographic technology (Authenticode) and security zones that screen certain kinds of downloaded programs and scripts against common networking threats, and the system integrity of Windows NT make it inherently less prone to viruses than its predecessors.

Assuring Your Privacy

Encryption ensures that network elements cannot eavesdrop on your communications by "scrambling" the data. Microsoft currently uses the RC4 algorithm from RSA, Inc., and the U.S. Government standard DES algorithm for most of its encryption (the cryptographic infrastructure is open so that alternative algorithms are easily added). RC4 is a "symmetric" algorithm that requires both sender and receiver to have the same shared secret, or encryption "key." The standard key lengths, which determine the degree of protection, are 40- and 128-bits (the latter is subject to U.S. export control). Although 40-bit keys can be compromised by known, determined attacks, compromising 128-bit keys by means other than flaws in the RC4 algorithm would be extremely difficult. RC4 and DES are long-standing algorithms and have no publicly known flaws.

Key management is the process of distributing keys between sender and receiver, and there are many common key management protocols. Sometimes both parties already know a secret user password that can be used as the seed for an encryption key. Other protocols use previously established keys to transmit the encryption key. Public key algorithms are particularly well suited for this purpose. Like referees at a sporting event, the best key management is unseen by its users.

Assuring the Integrity of Your Data

Integrity is protection against malicious modification of data. Integrity techniques attach a cryptographic signature to the message that both identifies the sender and ensures that the message has not been modified in transit. Microsoft technology currently uses the RSA public key and MD5 hash algorithms, a technique that dominates the Internet community. In a public key cryptosystem, each user has a matched pair of keys: a private key they keep secret, and a public key they publish freely. The public key is presented in a certificate signed by a Certification Authority (CA) that attests to the key's authenticity.

The unique property of public key ciphers is deceptively simple: Data encrypted by the private key can be decrypted only by the public key, and data encrypted by the public key can be decrypted only by the private key. For example, if you encrypt a message for a colleague with her public key, only she can decrypt it.

A hashing algorithm produces a small value (usually 16 bytes) from an arbitrarily long stream of data. We call this value a "hash" or, more formally, a "message digest." Its unique property is that it is computationally infeasible for someone to construct a data stream that reproduces a specific hash value. For example, if you compute a hash from a document you send to a colleague and then transmit the hash value securely, your colleague could determine if the document had been tampered with by recomputing its hash and comparing it with your original. Although a nefarious intermediary (traditionally named "Mallet") might modify the document in transit, the intermediary simply cannot produce a fake document that has the same hash value.

The only question left is how to securely transmit the hash, but that is easy: You encrypt it with your private key and send the result as a signature that accompanies the document. Your colleague uses your public key to decipher the transmitted hash and checks the document as before. Although it may not be obvious, there is no way Mallet can modify the document or its signature that your colleague's software will not detect.

Microsoft uses this common, basic integrity algorithm in many situations. Perhaps the most visible is the Authenticode technology that ensures that Microsoft ActiveX, Java, and other active components downloaded from the Web come from identifiable sources and have not been tampered with. Public keys and hash algorithms are also used for symmetric key management and to ensure that a communicant is genuine and not a masquerader.

Secure Sockets Layer (SSL) is a popular protocol that incorporates both encryption and integrity. While SSL is predominantly used for Web traffic, Microsoft's cryptographic enabling technologies, called Secure Channel and Security Support Provider Interface (S-Channel and SSPI), make it available to all applications. Microsoft also supports Private Communication Technology (PCT), an improved version of SSL and Transport Layer Security (TLS), an upcoming Internet standard that merges SSL and the ideas in PCT. Throughout the rest of this chapter, this entire collection of protocols is referred to as SSL.

Certificates

The distribution and management of certificates are central to the successful deployment of public key technology. In the example, how does your colleague reliably obtain your public key? If you send it unprotected, Mallet can change it and compromise your communication without your knowledge (or your colleague's). A certificate holds your name, your public key, and other information, all of which are signed by a Certification Authority (CA) using a private key and the integrity algorithm. If your colleague reliably knows the public key of that CA, she can verify that the certificate you send her has not been tampered with. For example, most mail systems simply package the sender's certificate with the mail message. The recipient software first verifies the certificate, and then uses its public key to check the integrity of the message.

It may seem that the issue has been deferred: How do you reliably obtain from the CA the certificate that holds the public key? The answer is that you have to use a previously established, secure communication path. There are many techniques for doing this, for example, Microsoft delivers many commercial CA certificates preinstalled in Internet Explorer. You only have to obtain a small number of CA certificates. Your software automatically uses these to verify the user certificates signed by those CAs. You can even have CAs that verify and sign the certificates of other CAs.

You also need confidence that the CA uses a degree of diligence when signing a user's key. It is poor practice for a CA to sign a certificate with an intentionally supplied false name. However, there are limits to what CAs can ensure, and certificates often contain a value that denotes the degree of diligence. It is also important for the CA to be able to revoke certificates. The usual technique is for the CA to regularly publish Certificate Revocation Lists that are downloaded by various CA validation agents.

Firewalls

You can think of a firewall as a filter that restricts the direction and type of requests that can pass between your LAN and an external network such as the Internet. The more effective firewalls serve as a "proxy" for specific services; that is, a program on the firewall serves as intermediary between the LAN and entities on the external network for a specific service like Web browsing. Proxy programs understand the details of the communication and can apply sophisticated restrictions on the data. Firewalls also can hide your internal network addresses from the external network and reject packets from specified external network addresses.

Cryptography Support in Windows NT

The Windows NT security environment provides pervasive cryptographic support for these ideas. For example, Personal Store securely groups a user's keys and certificates together for storage, Certificate Server lets you issue and manage your company's own certificates, and CryptoAPI fully supports Certificate Management.

System Integrity and Auditing

System integrity ensures that the software and hardware responsible for enforcing the system's security cannot themselves be compromised by regular users or their programs. Unlike many desktop operating systems, Windows NT is built around a security kernel that ultimately protects the system itself. The security kernel also enforces the access controls that protect all sensitive files and data outside the kernel, making the protection complete. System integrity is the foundation upon which all other security protections rely.

The importance of an audit trail, a tamper-proof record of security-related events, speaks for itself. Windows NT has a rich auditing system, and many applications produce security logs particular to their services.

The Windows NT Security Environment

The basis of Microsoft's security environment lies in Windows NT security features and the technologies that enable them. The BackOffice family of products and other applications take advantage of both. An enabling technology is a set of software libraries that encapsulates certain algorithms or procedures that the operating system makes available to other applications and system services. These enabling technologies can be used by other parts of the operating system and also by applications developed either by Microsoft or independent, third-party developers. Although enabling technologies do not by themselves make your system more secure, they are crucial to assuring a strong, consistent, ongoing stream of security applications for the Windows NT environment.

 

Windows NT Security Features

This section provides information about the security features of Windows NT.

Domains and Accounts

The most fundamental security issue in a computer network is posed by the question: Which computers can a given user access? For both local and remote users, the answer to this question is governed primarily by the domain structure of Windows NT.

Administrators assign each Windows NT–based computer, whether a server or desktop computer, to a single Windows NT domain. (This is usually permanent, but it can change.) Each domain has a Windows NT Domain Controller that serves as a repository for security information, most notably a set of domain-wide user accounts and group definitions. A user's account holds a logon name, password, capabilities, and other information, such as the user's real name. Each account in a domain can locally log on to and remotely access each computer in the domain, although there are other controls that can restrict access on an account-by-account basis.

If the administrators agree, one domain can trust another. When this happens, accounts in the second domain have the same access to computers as accounts in the first domain. In setting up the trust, the first administrator is in effect saying, "Your users may access the computers in my domain" (although there are many limitations on that access). Usernames across a multidomain network must be unique only within a domain and are implicitly prefixed by their domain name, such as SALES\JJones, where SALES is the domain and JJones the user. Trust is one-way. In the current example, accounts from the first domain cannot access the computers in the second domain. However, two domains can trust each other, and a domain can trust, and be trusted by, more than one other domain.

There are many popular practices for structuring domain trust relationships (domain models) and some are based on criteria other than security, for example, network browsers group computers and their shared resources by domain. In all cases, however, the fundamental security of domains is based on the same question: Which computers can a given user access?

There are two features that further allow administrators to control access to computers. User rights are special capabilities that administrators assign to accounts that can use a given computer. Most rights are used internally by Windows NT, and the default assignments seldom change. However, two rights are noteworthy: the right to log on locally and the right to log on remotely. These allow each computer to tightly limit each kind of logon. Further, each account has an optional list of workstations to which its user can locally log on.

Remote Sessions and Single-Logon

When you locally log on to a Windows NT–based computer, your logon session runs under the name you present along with your password at logon. When you attempt to access a remote computer (for example, connecting to one of its shared directories or printers, or performing remote administration), the remote computer transparently authenticates you and establishes a remote session for your activities there. If the domain structure allows, the remote account is the same as your local one. Otherwise, you sometimes can specify a name and password of an account that is allowed on the remote computer. But under no circumstances can you establish a remote session without being authenticated—that is, without demonstrating you know the name and password of an account that is legal on the remote computer. And without a remote session your programs can obtain no significant services.

After you have been logged on to the remote computer, remote server applications can assume the identity of your user account through a simple process called impersonation. When they do so, they are running under your permissions and capabilities, and their actions are appropriately constrained by controls in the remote environment, for example, ACLs on the remote file systems. This is our first and perhaps best example of how the Windows NT environment implements single-logon and propagates it to server applications. A server in this scenario need know nothing about authentication or accounts. It simply impersonates its client user (whose name it may not even choose to discover), and the Windows NT environment restricts the program's actions accordingly. The BackOffice family of products and other Microsoft applications universally use this fundamental security model, and Microsoft strongly encourages all BackOffice-compatible applications to do so as well.

Logon and Password Management

Under single-logon, you log on only once, so that logon should be quite strong. For this purpose, Windows NT uses a technique called trusted path, which is typically found only in highly secure operating systems. The trusted path prevents what is commonly called the spoofing scheme, in which a malicious program already running on a computer presents what appears to be a legitimate logon window in order to capture a user's password. Under the trusted path approach, users of Windows NT are trained always to call up the logon window by pressing the CTRL+ALT+DEL keys simultaneously. When they do, Windows NT reliably displays its Security Window, which allows them to safely enter the password. (You also use the trusted path approach to change your password and log off, which prevents similar spoofs.) Windows NT also includes a variety of password controls, including the ability to lock an account when its password appears to be under attack.

There are two important enabling technologies that can strengthen Windows NT logon and password management: PASSFILT and GINA. PASSFILT lets an administrator install a trusted program that is called every time a user changes a password. The program receives the new password and can ensure that it meets certain strength criteria such as length and the use of randomly chosen characters. Microsoft includes an optional PASSFILT module in Windows NT that enforces an example password policy. This addresses the time-honored but still troublesome problem posed by users who choose nonsecure passwords. GINA is a replaceable program that is part of the Windows NT local logon system. Although not for the novice, vendors can supply alternative GINA modules that strengthen the logon process. Prime examples include support for smart card authentication (see "Enabling Technologies" later in this chapter) and biometric authentication (devices such as fingerprint or retinal scanners).

Access Control Lists

All objects in the Windows NT environment can have an Access Control List (ACL). An ACL defines a set of users and groups, and the kind of access each has on the object. The most visible and important ACLs are those that protect all elements in the Windows NT native file system format (NTFS) and the Windows NT registry. These house all software that enforces Windows NT security, and ACLs are therefore important in protecting the system's integrity. (Windows NT sometimes uses encryption for additional protection, for example, its user accounts and other key security data.)

Users have full control of ACLs on the files, directories, and other objects they create, and use simple window interfaces to manage them. They also can specify the ACL to be given by default to all newly created objects in the directories they manage.

ACLs protect other objects, such as file shares and printers, and most of the BackOffice applications extend the ACL model to data they manage. It is often necessary for an application to have a customized ACL format for the objects it manages. In both cases the purpose and intent are the same.

Central Administration and Roles

Windows NT uses a simple administrative hierarchy. Full administrators, members of the local Administrators group on each computer, have complete power over that computer. Windows NT Server includes several operator roles each of limited power, for example, account operators who manage user accounts and server operators who look after day-to-day server operations. Windows NT administration is based simply on membership in certain groups so you can devise network-wide administrative roles flexibly. For example, you can include domain administrators from the local domain (or remote domains) to the administrators who control your LAN workstations. You also can create a group for accounts that administer only user workstations and not the more critical network servers.

Security Audit Trail

Windows NT and its applications can record an extensive set of system events in the security log. You can define an audit policy that designates which of six categories the system records (logons and logoffs, user and group management, and so on). You also can attach auditing information (which looks much like an ACL) to any Windows NT object (this is typically done for NTFS files, NTFS directories, and Registry keys). An object's category determines when the system audits access to the object-based on the user and group, and the success or failure of the operation. You can even stipulate that the system shut down if the audit trail exceeds the allowed storage.

Microsoft provides extensive software libraries that allow trustable programs to insert their own custom audit records into the audit trail. The libraries also give audit tools easy, high-level access to the security log.

Remote Access Service and Point-to-Point Tunneling Protocol

Remote Access Service (RAS) allows remote users to dial in to a Windows NT RAS server and use the resources of its network as if directly connected. In its simplest mode, users logging on to Windows NT remotely simply check a small box on their logon window that automatically establishes the RAS connection and authenticates the session. RAS uses the Windows NT standard single-logon technique, and users can log on under their office account. Overall, working from the road is identical to working from one's office, and it is secure.

Administrators designate which accounts can use RAS. They also can set up RAS to automatically "call back" a specific number for each account. This ensures that a user's remote access comes only from a specific phone number. RAS uses the Windows NT standard "challenge/response" logon, which prevents passwords from passing over the communication link. RAS clients and servers can require that all communication be encrypted, currently by the 40-bit or 128-bit RC4 cipher. You also can limit remote access to the resources of the RAS server itself (as opposed to its networks).

Microsoft's Virtual Private Networking technology uses the industry-supported Point-to-Point Tunneling Protocol (PPTP) to extend the use of RAS to the Internet. Instead of dialing directly into the RAS server using a telephone line, the remote RAS client dials a local Internet service provider and establishes an Internet link to the provider's PPTP RAS server. This virtual private network allows a remote user to securely access a central network over the nonsecure Internet.

Basic Protocol Security

Not all networks are prone to attack, and Windows NT does not impose performance penalties by applying cryptographic techniques to all network traffic. Instead, its philosophy is to support specific applications that must cryptographically protect data in transit across a network. However, it does use some common-sense and basic cryptographic techniques in its standard, underlying protocols.

Local logon requests are encrypted when they pass between the workstation and its domain controller. This helps ensure that passwords are not exposed and that interlopers cannot interfere with the primary authentication process. The remote (or secondary) authentication we discussed uses the NTLM challenge/response protocol to ensure that passwords never appear on the network unencrypted.

Windows NT uses the Microsoft SMB protocol for file and printer sharing and many for other remote services. SMB also applies integrity protection to this protocol. The protection does not encrypt data, but it does prevent a broad range of attacks that seek to modify the data while in transit or to impersonate the client's identity.

C2 and Its Companions

Windows NT is one of the few commercial operating systems that has successfully completed the U.S. Government C2 evaluation process, as well as the FC2/E3 evaluation under its companion European criteria, Information Technology Security Evaluation Criteria (ITSEC). This is important for two reasons. First, it ensures that the base operating system has certain important security features. Second, and more importantly, it provides an opinion about the system's security from an independent, trained, experienced, and unbiased team of government security analysts. This team has had the full cooperation of Microsoft developers and core software architects, as well as access to source code and internal design documents. The team, which meets regularly with the developers and architects to gauge Microsoft expertise, commitment, and thoroughness with regard to security, concentrates on fundamental security architecture and is guided by what is commonly called the "Orange Book" (Trusted Computer Systems Evaluation Criteria).

The C2 evaluation process is therefore not a detailed search for security bugs, but rather an opinion that the overall security architecture is sound. For more information, see https://www.microsoft.com/ntserver/techresources/security/default.asp.

Planned Additions to Windows NT

Future releases of the Windows operating system may bring many new security features, for example:

• Expanded Domain Trust Relationships 

  To ease domain administration in larger sites, a future version of Windows may allow administrators to group domains so that each domain implicitly trusts every other domain in the group, and that accounts in a domain can be used in all other domains in the same group. 

• Kerberos and Public Key Authentication 

  Invisible to most users, Kerberos offers a variety of expanded authentication capabilities. For example, it allows servers to pass client user identities for use by other servers in a multitier client/server arrangement and allows mutual client/server authentication. It also allows users of the Windows operating system to securely access remote services other than Windows NT services that use this popular technology. Future versions of the Windows operating system may also authenticate users using public keys and certificate technology, including SSL. This facilitates authentication from sources other than Windows operating systems sources and eliminates some of the disadvantages of traditional passwords. 

• Active Directories 

  The Active Directory is logically a single, network-based storage hierarchy based on X.500 standards (and, of course, protected by ACLs, which have some interesting new properties of their own). When upgrading from Windows NT 4.0 to Windows 2000 or later, many security parameters may migrate to the Active Directory from their current location in the Windows NT Registry, including all user accounts. This significantly enhances central security administration. Administrators also can delegate detailed operations to lesser administrative users who must perform specific functions; for example, letting a help desk attendant assign a new password to a user without otherwise changing the user's privileges. Because these privileges are based on the ACLs that protect the Active Directory elements, managers can devise custom administrative hierarchies that fit their own particular needs. 

• Encrypted File System 

  Future versions of the Windows operating system may allow users automatically to encrypt information stored in the native NTFS file system format in much the same way they can automatically compress files today. It has provisions for data recovery that allow trusted administrators to recover data if users forget their own encryption keys or leave the company. This is a welcome and essential feature for people who use laptops or removable hard drives.

Enabling Technologies

In many ways, enabling technologies are the most exciting part of this security story because they portend a rich, ongoing stream of trusted applications that are more economical, more secure, and easier to administrator because they take advantage of the Windows NT security infrastructure. This section about enabling technologies begins with the Microsoft cryptographic application programming interface, CryptoAPI, and a public key security protocol called Secure Channel
(S-Channel).

CryptoAPI and Secure Channel

Cryptography is the essential component of networking security. Unfortunately, it is a difficult technology to learn and implement. Microsoft created the CryptoAPI to address this problem. The CryptoAPI is a set of software libraries with high-level cryptographic interfaces (APIs) that manage the many details of key management, formatting, and cipher algorithms, presenting applications with a single interface that serves different underlying ciphers. CryptoAPI uses Cryptographic Service Providers (CSP), plug-in cipher modules that cryptographers create and market. In short, CryptoAPI joins application developers, who know little of cryptography but need to use it, with cryptographers who develop the base technology.

Each CSP implements a specific set of cryptographic algorithms. Microsoft provides a base CSP that includes a full complement of cryptographic ciphers and hash functions licensed from RSA Data Security, Inc. Under CryptoAPI, you can replace one CSP with another of the same type without affecting any of the applications that use that type. For example, Microsoft provides an enhanced version of the RSA-based CSP that supports stronger encryption. This also allows you to upgrade your security to hardware devices such as smart cards, by simply replacing the CSP.

A second advantage of the CryptoAPI is that it fully encapsulates the storage and protection of crypto keys and the ciphers themselves. A CSP can implement its schemes either in software or on smart cards. Smart cards present significant security advantages over software because they are portable and can better physically protect a user's secret keys.

Microsoft delivers a basic set of CSPs with Windows NT (you may need special third-party licenses if you develop and sell products using these CSPs). All BackOffice applications are moving quickly to fully utilize CryptoAPI. The recently released CryptoAPI 2.0 includes a complete set of certificate management APIs that implement the latest X.509 certificate formats.

Secure Channel (S-Channel) is a security service provider module that implements the popular public key security protocols between Web clients and servers. These include SSL, PCT, and TLS (an upcoming standard that merges SSL and PCT). S-Channel is layered on top of CryptoAPI for key and certificate management services. Independent software vendors and developers can use S-Channel to add these cryptographic protocols to any client/server application.

P-Store, Microsoft Wallet, and PFX

Traditionally, on a single-logon system such as the Windows NT operating system, users were required to remember only their logons and passwords. However, increased security in heterogeneous environments imposes additional burdens. These include private keys and certificates, trusted CA certificates, credit card and bank account numbers, other personal identification information (such as driver's license numbers), and data that helps their applications use this information automatically and transparently. There needs to be a single place to store* and *protect this information that applications can share. On the Windows NT operating system, the Protected Store (P-Store) is the technology that meets this need.

P-Store is a set of software libraries that allow applications to fetch and retrieve security and other information from a personal storage location, hiding the implementation and details of the storage itself. For example, the storage location could be the user's Windows NT profile, a preferences file, a diskette, or a smart card.

Microsoft Wallet is a generic name for a window application that serves as the user interface to the P-Store. Microsoft Site Server already uses the Wallet with Microsoft Internet Explorer.

Personal Information Exchange (PFX) is a protocol that securely transfers the contents of a P-Store from one location to another, for example, from an office computer to a home computer.

SSPI, Secure RPC, and DCOM

As intranets become more secure, client applications (such as Web browsers and e-mail programs) and servers (such as Web servers and e-mail hosts) become more complicated because different situations require different types of authentication and cryptography. Microsoft's Security Support Provider Interface (SSPI) makes common network authentication and cryptographic data protection schemes available to both client and server applications through simplified software libraries. Programs that use SSPI do not need to encode the details of specific authentication or cryptographic schemes. Instead, the SSPI libraries do all the complicated work.

A Security Support Provider (SSP) is a library that manages a particular scheme. Applications interact with all SSPs through a common SSP interface (hence, the name SSPI), which further hides the details of the specific scheme. SSPs rely heavily on other enabling technologies like CryptoAPI and S-Channel whenever possible. SSPI currently includes four SSPs:

Kerberos

Kerberos is the cryptographic, industry-standard mutual authentication protocol.

NT LAN Manager (NTLM)

NTLM is the traditional password-based authentication protocol for Windows-based networks. Although this time-honored standard continues to be supported, Kerberos will gradually replace its use for newer, Windows NT environments.

SSL (Including PCT and TLS)

SSL is a cryptographic protocol for mutual authentication and data protection popular today only in the Web community, but nonetheless a strong, general-purpose security protocol.

Distributed Password Protocol (DPA)

DPA is a password-based authentication protocol used by many commercial online services such as The Microsoft Network. Its advantage is that users can use the same credentials (name and password) to log on to more than one online service.

Distributed and client/server applications use SSPI in several ways, from calling its SSPs directly to selecting security options when using Distributed COM (DCOM), Remote Procedure Call (RPC), and other popular Internet APIs. DCOM and RPC are enabling technologies that make it easier for users to create distributed applications. (Distributed applications use cooperating components that run on different computers, and perhaps even different operating systems, such as Windows NT, UNIX, or Macintosh). For example, Windows NT remote administration uses RPC extensively. DCOM and RPC manage and hide the details of how the different parts communicate with each other. Both DCOM and RPC have simple options that automatically use SSPI authentication and message encryption. These options are sometimes called "Secure DCOM" or "Secure RPC." These are among the easiest ways to use SSPI.

For example, most authentication protocols begin by exchanging a series of packets between the client and server.

1. The SSPI client begins by calling a particular SSP requesting an initial client request packet. The SSP formulates the packet and instructs the client to deliver it to the server. The client and server never look inside these packets. Each simply delivers a packet to the other for processing by the other's SSP module. The server sends the packet to its corresponding SSP as an initial client request.

2. The server SSP returns a packet to the server with instructions to send the packet back to the client SSP. This packet might, for example, contain the challenge used in a challenge/response protocol. 

3. Finally, the client SSP formulates the last packet and instructs the client to send it to the server. In our example, this includes the response to the challenge. The server passes this final packet to its SSP, which then informs the server that the authentication succeeded. (In our example, the client's SSP produced a response to the challenge that only the user's password could produce.)

SSPI also supports server impersonation, so at this point the server might impersonate the client user—that is, it might begin working under the client user's identity. If the client and server are cryptographically protecting their data, each one passes each of its outgoing packets to the SSP for encryption or signing, and each incoming packet for decryption or signature checking. In this case the initial exchange usually negotiates the encryption keys for the session.

Certificate Server

Certificate Management refers to the process whereby public and private encryption keys are securely and reliably managed by a Certification Authority (CA). A key component of this process is that the CA creates a user's certificate (essentially, signs the user's public key) after verifying that the user has presented a legitimate name (often a full name or e-mail address). Although there are several companies that provide this service, large Windows NT–based networks want and need their own certificate authorization services. This need is met by Microsoft's Certificate Server (CS).

You can think of CS as a toolkit for CAs. It accepts certificate requests from users in a variety of popular, standard formats (such as e-mail), subjects the requests to any number of "approval modules" that the CA easily can add to the server, and then constructs and returns a certificate to the user. Each site adds its own approval modules. A module might engage in an e-mail exchange with the user's listed e-mail address or send a request to an assistant who researches the requester. CS can also manage Certificate Revision Lists. The value of CS is that it decreases costs by creating certificates in-house and also allows you to establish the certification policies important to your organization. You can even use it to establish your own public certification service.

Authenticode and Java Security

In the early days of the Web, when you clicked a hyperlink, your browser printed the link's contents on your screen. But today your browser may invisibly download and locally run a number of small programs that manage the presentation of the page on your screen. These active Web page elements, including ActiveX controls, Java applets, and .exe files, pervade the Web and are the wave of the future. Their presence as local programs is automatic and transparent.

Unfortunately, you have no way of knowing whether these active elements attempt to act maliciously on your system. They run under your identity with your capabilities and can do everything you can do. This can include deleting files, e-mailing files to third parties, and installing malicious programs on your computer.

Microsoft's Authenticode technology uses the simple cryptographic integrity features presented earlier to help ensure that your browser accepts only active elements you think are safe. Reputable software vendors join a software vendor organization and receive a certificate signed by the CA of the organization. People who browse the Web install that CA certificate on their workstation. (It usually comes preinstalled in the browser.) Vendors sign their active elements using the integrity algorithm described earlier.

Your browser can now determine two important things: first, that an active element comes from a genuine member of that organization and, second, that it has not been tampered with since the vendor signed it. You can easily instruct your browser to ignore elements that fail these tests or allow only elements from a list of vendors you specify. Microsoft Internet Explorer can check Authenticode on any active element (ActiveX, Java, and so forth).

Is this sufficient assurance? Suppose you visit your favorite computer store and buy a shrink-wrapped program from a software vendor that produces a wide selection of PC programs. You probably have no reservations about the safety of the software because you have no reason to think it is malicious. No legitimate software house risks its business by selling what it knows or suspects to be a tainted program. It is always possible, of course, that someone tampered with the package or substituted a fake CD-ROM, but that is unlikely.

Authenticode assurance is analogous but even stronger. It is more difficult to tamper with cryptographic signatures than with shrink-wrapped software, and the software vendor organization attests that the software vendor is genuine and willingly joined the organization. If shrink-wrap tampering is unlikely, then Authenticode tampering is as unlikely.

Java offers some additional security possibilities. Java applets do not necessarily gain full access to your system. Your browser (more properly, the local software that runs the Java applets) can limit these applets, for example, preventing them from writing onto your file systems. The scope of a Java applet is often called its sandbox. With the proper Java security model this can be an effective security restraint, but it involves an inevitable trade-off against the capabilities of the applet. For example, when you prevent an applet from writing to your hard drive you may be removing its ability to give you the services it is designed to provide. Internet Explorer 3.0 fully enforces the standard Java "sandbox," and Microsoft is working with industry groups to make the sandbox walls more flexible.

There is no question that for some applets, the sandbox is an effective protection. But there is also no question that in general, it is not enough. Authenticode does not have this trade-off and need not make these concessions to usability.

SQL Server Security

As this illustration shows, all four components of the BackOffice family of products leverage the security infrastructure and enabling technologies of Windows NT, but these remarks are restricted to SQL Server.

 

SQL Server 7.0 is a distributed, client/server, relational database server that supports the popular SQL query language. It often serves an enterprise back-end server for a variety of network client applications, such as Exchange Server. SQL Server is an interesting security story and perhaps best illustrates the convergence of BackOffice products around Windows NT. The popularity of SQL Server predates Windows NT, and therefore SQL Server implemented most of its own security. With the emergence of SQL Server version 7.0, SQL Server is now firmly integrated into the Windows NT security environment.

SQL Server fully supports Windows NT single-logon and user groups and will later leverage Kerberos authentication. It also implements its own internal roles, which are similar to Windows NT groups. SQL Server uses these roles for internal administration, and the advantage is that you do not need to clutter the Windows NT group list with groups internal to the server.

SQL Server applies access control to the database elements it manages (tables, views, stored procedures, and column-level permissions). Relational databases have a traditional format they use to present this access control, and therefore the format is different from other Windows NT ACLs, but the intent and degree of control are the same. You can assign a variety of database-specific permissions to Windows NT users, groups, or SQL Server roles. As in the Windows NT file system ACLs, you can also allow a group to control access to database element.

SQL Server creates a full transaction log, supports many internal administrative roles, and includes many other database-specific security features. Future plans may include using Secure RPC to encrypt network traffic.

Windows NT and Enabling Technologies

Microsoft's security architecture is based on fundamental security principles manifested in the security features of the Windows NT operating system; these principles are supported by various enabling technologies that bring powerful security technology within easy grasp of application programs. The BackOffice suite and its companion applications leverage this technology to create and support a powerful set of consistently secure applications that are illustrated here.

 

For more information about security, see https://www.microsoft.com/security/.