Steve Sutton, Trusted Systems Services, Inc.
October 1997
This article introduces you to the world of Microsoft® security, with its wealth of enterprise security features centered around the Microsoft Windows NT® operating system. We won't presume to tell you why you need security—if you didn't already know you probably wouldn't be reading this. But it's no secret that few computers work in isolation anymore and the degree to which the world community of electronic systems is increasingly linked is more profound than most of us appreciate. And the targets are more tempting and valuable. To keep your work product and sensitive plans safe and secure you need the best state-of-the-art security available—soundly implemented, conforming to standards, and easily administered. This is precisely the task to which Microsoft has set itself, and this paper is your starting point to understanding the results.
Our story centers around the Windows NT operating system and its family of enterprise applications, the BackOffice® suite. We'll see how these applications use and rely upon the Windows NT security features while using a consistent framework for extending the security model to provide features unique to their arena. We'll also demonstrate key enabling technologies that make it easy for all applications to take advantage of Microsoft security. While you may never use these technologies directly, they ensure that a broad selection of secure, reliable applications from Microsoft and others will always enrich the Windows NT environment. We also set out the basic security principles upon which all this rests.
Our vantage is both broad and long-term and we leave many details to other forums. Some features we present are relatively new and a few are not yet delivered. Microsoft security targets established or emerging standards whenever possible (too many to even list in this document), and Microsoft actively contributes to the standards that ensure open security, especially in the Internet community. For more information, you can peruse the Microsoft security Web site at http://www.microsoft.com/security. This site has quick links that expand on most of the technology we'll present.
Although there are a mind-boggling number of detailed security features in today's commercial environment, they all stem from a few basic principles that form the cornerstone of Microsoft's security approach. 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, and firewalls restrict traffic between your LAN and an external network like the Internet. System integrity ensures the underlying security software cannot be tampered with and auditing records security events.
The root of enterprise security is controlling which users can see, modify, and delete which data. It's as simple as that. Data can be as diverse as e-mail, address books, or collaborative documents (like those in Microsoft Exchange); the wealth of heterogeneous data stored in centrally managed relational databases (like Microsoft SQL Server™); your communications with host mainframes (perhaps managed by SNA Server); your Web site, which may contain both internal and public information (Internet Information Server); the "take-home" documents that you use Windows NT Remote Access Service to download from your office; or a simple personnel memo on your desktop PC. While there's no "one-size" security that fits all these cases, the principles are relatively simple and stem from a basic set of threats.
Security starts with legitimate users: your employees, system administrators, business partners, and customers. You don't trust them all with the same information. We call the process of identifying these users authentication, or in some situations, simply logging on. Like most commercial operating systems, passwords dominate authentication in the Windows NT arena, though "smart card" authentication will soon be available as a common, cost-effective alternative. Although the "public key" certificates we later discuss 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 your workstation running Windows NT or Windows® 95. (Note: Windows NT-based networks fully accommodate Windows 95-based clients, even supporting common features like single-logon. However, Windows 95 simply does not have the security strength of Windows NT on the desktop and we largely omit it from our discussion.) 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 don't have to remember a plethora of alternative user names or passwords, or enter them in vulnerable interactions that could compromise them. Single-logon also makes it easier to incorporate advanced authentication techniques, like smart cards. While single-logon may sound simple, it requires a great deal of infrastructure and is a key goal of the enabling technologies we discuss later.
Establishing the user's identity is only half the battle. 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 each. The permissions are usually targeted to the object the ACL protects. For example, shared printers have "Print" and "Manage" while files and directories have the more familiar "Read" and "Write" permissions. In some cases users who create an object can manage its ACL while in others this is restricted to administrators.
There are unidentified, illegitimate, and usually unseen penetrators who pose two major threats. The first attacks data in transit across a network (or perhaps while stored in intermediary locations, like a mail server)—whether they simply eavesdrop on your data, actively modify it, or attempt to impersonate you on the network. As a sage once noted, there are only three solutions to this threat—cryptography, cryptography, and cryptography—and Microsoft devotes a great deal of its security energies to this technology. There are many public standards driven mainly by the Internet community like the Internet Engineering Task Force (IETF), and Microsoft actively supports these efforts.
The second threat seeks to introduce malicious programs onto your system: Trojan Horses, viruses, and other assorted vermin. These are particularly virulent in the Internet environment. Microsoft's cryptographic Authenticode™ technology woven into Internet Explorer, and Internet Explorer's new Security Zones that selectively screen certain kinds of downloaded programs and scripts are two examples that counter common networking threats. Windows NT system integrity makes it inherently less prone to viruses than its predecessors.
Although you've probably read many summaries of cryptography, the topic is obligatory in this sort of document. Perhaps our perspective will clarify a few points. 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, although as we see later, 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 is unthinkable. 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 like a user password, which 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.
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 Certificate Authority (CA) that attests to the key's authenticity. (More below.) The unique property of public key ciphers is deceptively simple:
Data encrypted by the private key can only be decrypted by the public key and data encrypted by the public key can only be decrypted by the private key.
(You might want to reread this a few times.) For example, if you encrypt a message for a colleague with his or her public key, only that person could decrypt it. (Most public key ciphers are slow compared to symmetric key ciphers, and they're seldom used for encrypting large amounts of data like this.)
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. While a nefarious intermediary (traditionally named "Mallet") might modify the document in transit, that intermediary simply cannot produce a fake document that has the same hash value.
The only question left is how to securely transmit the hash. Easy—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's no way Mallet can modify the document or its signature that cannot be detected by your colleague's software.
Microsoft uses this common, basic integrity algorithm in many situations. Perhaps the most visible is the Authenticode technology that ensures that ActiveX™, Java, and other active components downloaded from the Web come from identifiable sources and have not been tampered with. (More later.) Public keys and hash algorithms are also used for symmetric key management and to ensure that a communicant is genuine—not a masquerader.
SSL is a popular protocol that incorporates both encryption and integrity. While it is predominantly used for Web traffic, Microsoft's cryptographic enabling technologies, S-Channel and SSPI, make it available to all applications. PCT is an improved version of SSL supported by Microsoft and TLS is an upcoming Internet standard that merges SSL and the ideas in PCT. We loosely refer to this collection of protocols as "SSL."
The distribution and management of "certificates" are central to the successful deployment of public key technology. In our example, how does your colleague reliably obtain your public key? If you send it unprotected, Mallet can change it in such a way as to completely compromise your communication without you or your colleague ever knowing. A certificate holds your name, your public key, and other information, all of which are signed by a Certificate Authority (CA) using a private key and the integrity algorithm we just described. If your colleague reliably knows the public key of that CA, they can verify that the certificate you send them has not been tampered. For example, most mail systems simply package the sender's certificate with the mail message. The recipient software first verifies the certificate, then uses its public key to check the integrity of the message.
It may seem that we've only put off the issue: How do you reliably obtain the CA's certificate that holds the public key? Well, you just have to use some previously established, secure communication path. There are many techniques. For example, Microsoft delivers many commercial CA certificates preinstalled in the Internet Explorer. The issue is one of logistics—you only have to obtain a relatively 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 other CA's certificates.
You also need confidence that the CA uses a degree of diligence when signing a user's key. It's 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's 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.
You can think of a firewall as a filter that restricts both the direction and kind of requests that can pass between your LAN and an external network like the Internet. The more effective firewalls "proxy" specific services, where 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 can also hide your internal network addresses from the external network and reject packets from specified external network addresses. There's little question that security-minded LANs should use a firewall, and we see more when we describe Microsoft's Proxy Server.
While we can make these ideas sound simple, it's not easy to seamlessly integrate them into an enterprise environment. The secret is in the pervasive cryptographic support that Microsoft is building into the Windows NT security environment, whether it's the Personal Store that securely groups a user's keys and certificates together for storage, Microsoft's new Certificate Server that lets you issue and manage your company's own certificates, or the latest version of CryptoAPI that fully supports certificate management. Cryptography is all in the infrastructure, and we will see many examples as our story progresses.
System integrity ensures that the software and hardware portions of the system that are responsible for enforcing its security cannot themselves be compromised by regular users or their programs. Unlike common desktop operating systems like MS-DOS®, Windows 95, and the Macintosh® OS, 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 bedrock upon which all other security protections rely, and it is a strong argument for deploying Windows NT Workstation on the desktops of sensitive facilities.
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 basis of Microsoft's security environment lies in Windows NT security features and enabling technologies. BackOffice and other applications take advantage of both. An "enabling technology" is a set of software libraries that encapsulate 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 itself, as well as from applications developed either by Microsoft or independent third-party developers. While enabling technologies don't by themselves make your system more secure, they are key in assuring a strong, consistent, ongoing stream of security applications for the Windows NT environment. The BackOffice applications have diverse heritages and new releases tightly integrate into the Windows NT security environment, replacing older and less consistent security features. Windows NT 5.0 introduces an unprecedented level of security integration.
The most fundamental security control in a widespread network is which users have access to which computers, whether for local logon (where you're working at a computer) or for remote access to shared network resources. The Windows NT domain structure fundamentally and primarily governs this policy.
Administrators assign each Windows NT-based computer, whether a server or desktop PC, 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 like 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 their administrators agree, one domain can trust a second domain; if so, accounts from the second domain can access computers in the first, just like the first's own accounts. 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 strong controls on that usage). User names across a multidomain network need only be unique within a domain and are implicitly prefixed by their domain name, like "SALES\JJones," where SALES is the domain and JJones the user. Trust is one-way. In our current example, accounts from the first domain cannot access the second's computers. However, two domains can trust one another. A domain can trust and be trusted by more than one other domain.
There are many popular practices for structuring domain trust relationships, or "domain models," and some are based on criteria other than security—for example, a network browser groups computers and their shared resources by their domain. However, the fundamental security of domains is both simple and essential: Who can access which computers.
There are two features that further allow administrators to control who can access which 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 its default assignments seldom change. However, two rights are particularly noteworthy: the rights to log on locally and 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.
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 even to perform 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 can sometimes 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, demonstrating you know the name and password of an account that's allowed on the remote computer. And without a remote session your programs can obtain no significant services.
Once you've 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. BackOffice and other Microsoft applications universally use this fundamental security model, and Microsoft strongly encourages all BackOffice-compatible applications to do so as well.
Prior to Windows NT 5.0, a server could not forward your identity and capabilities on to another remote server. Windows NT 5.0 includes an authentication technique called Kerberos that gives servers this ability. Kerberos was developed at MIT and is a respected Internet standard.
Under single-logon, you log on only once, so that logon should be quite strong. Windows NT uses a technique called the "trusted path," typically found only in highly secure operating systems. The trusted path prevents the common "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, users of Windows NT are trained to always call up the logon window by pressing the CTRL, ALT, and DEL keys simultaneously. When they do, Windows NT reliably displays its Security Window into which they can safely enter their password. (You also use the Trusted Path to change your password and log off, which prevents similar spoofs.) Windows NT 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's called every time a user changes a password. The program receives the new password and can ensure that it meets certain strength criteria, like its length or the random nature of its 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 of users who choose unsecure passwords. GINA is a replaceable program that is an integral part of Windows NT local logon system. Although not for the novice, vendors can supply alternative GINA modules that strengthen the logon process. The prime example is to support the smart card authentication we discuss later, or biometric authentication devices like fingerprint or retinal scanners.
All objects in the Windows NT environment can have an Access Control List (ACL), which lists users or groups and the kind of access each is allowed to 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. (The Windows NT Registry is an extensively used hierarchical storage for system and application control information.) These house all software that enforces Windows NT security; thus ACLs are key in protecting the system's integrity. (Windows NT sometimes uses encryption for additional protection, for example, of 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 can also specify the ACL to be given by default to all newly created objects in the directories they manage.
ACLs protect other objects, like file shares and printers, and as we see later most BackOffice applications extend the ACL model to data they manage. It's often necessary for an application to have a customized ACL format for objects that it manages. In both cases the purpose and intent is the same.
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 that manage user accounts and Server Operators that look after day-to-day server operations. Windows NT administration is based simply upon membership in certain groups so you can flexibly devise network-wide administrative roles. For example, you can include domain administrators from the local domain and even remote domains to the administrators who control your LAN workstations. Or you could create a group for accounts that only administer user workstations but not the more critical network servers.
Windows NT and its applications can record an extensive set of system events in their security log. Administrators define an audit policy that designates which of a set of six categories the system records (logons and logoffs, user and group management, and so forth). They can also attach auditing information (which looks much like an ACL) to any Windows NT object, typically NTFS files and directories, and registry keys. When the object category is selected, this information determines when the system audits access to the object based on the user or group of the accessor and the success and/or failure of the operation. You can even stipulate that the system shuts down if the audit trail exceeds allowed storage (although this is wisely left as an option).
As an enabling technology, 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, and we can look forward to powerful, third-party audit trail analysis tools.
The Remote Access Service (RAS) lets remote users dial into 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 normal office account. Overall, working from the road is identical to working from one's office—and it's secure.
Administrators designate which accounts can use RAS. They can also set up RAS to automatically "call back" a specific number for each account, which 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- or 128-bit RC4 cipher. You can also 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 their PPTP RAS server. This virtual private network scenario allows a remote user to securely access a central network over the unsecure Internet.
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 need to 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 just discussed uses the NTLM challenge/response protocol to ensure that passwords never appear on the network unencrypted.
Windows NT uses Microsoft's SMB protocol for file and printer sharing and many other remote services. A new version of SMB applies integrity protection to this protocol with an algorithm similar to the one we presented earlier. (Note: This enhanced SMB protocol was introduced in Windows NT 4.0 Service Pack 3. Its author has proposed it as a standard for the Common Internet File System (CIFS) that would allow file sharing across diverse platforms.) While it does not encrypt (hide) one's data, it prevents a broad range of attacks that seek to modify data in transit or impersonate the client's identity.
Windows NT 3.51 is one of the few commercial operating systems that has successfully completed the C2 evaluation process by the U.S. government, as well as the FC2/E3 evaluation under its companion European criteria, ITSEC. Why should you care? C2 ensures that the base operating system has certain important security features, but more importantly, it's an opinion from an independent, trained, experienced, unbiased team of government security analysts, a team that has the full cooperation of the Microsoft developers and has access to source code, internal design documents, and the core software architects. The team works through meetings with these designers to gauge Microsoft's expertise, commitment, and thoroughness toward security. This team concentrates on fundamental security architecture guided by the Trusted Computer Systems Evaluation Criteria, the "Orange Book." The team summarizes its study in a Final Evaluation Report, which is as good an illustration of Windows NT security architecture as you'll find.
C2 evaluation is therefore not a detailed search for security bugs, but rather an opinion that the overall security architecture is sound. One cannot "run the system in C2 mode"—there's no such thing. One could turn off the features that were excluded from the evaluation, but even this misses the point of the evaluation process. C2 is a measure of Microsoft's commitment and support to produce a system whose fundamental architecture is subjected to independent analysis. The resultant C2 and its companion ratings lend an important degree of confidence that this system is properly architected for security. For more information, see http://www.microsoft.com/ntserver/guide/securitysummary.asp.
Upcoming additions to Windows NT, particularly those that will be introduced in Windows NT 5.0, bring many new security features:
We'll also see public key technology and certificate management more tightly bound into Windows NT, wider use of SSL, and some small but nice refinements to its audit log. You can learn more about all these features in Microsoft Windows NT Distributed Security Services: Secure Networking Using Windows NT Server Distributed Services Technology Preview (See the "Distributed Security" section of the PDC 97 Conference Papers in the MSDN™ Library).
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 common enabling software.
Cryptography is the essential component of networking security. Unfortunately, it's 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 base CSP that supports stronger encryption strength when legal. This also lets you upgrade your security to hardware devices, like 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 not only portable but can better physically protect a user's all-important secret keys.
Microsoft delivers a basic set of CSPs with Windows NT. (Note that you may need special third-party licenses if you develop and sell products using these algorithms.) 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: SSL, PCT, and the upcoming standard that merges them, TLS. S-Channel is layered on top of CryptoAPI for key and certificate management services. ISVs and developers can use this S-Channel to add these strong cryptographic protocols to any client/server application.
Traditionally, on a single-logon system like Windows NT, users had only to remember their logon passwords. However, increased security in heterogeneous environments adds a lot more that they have to lug around, including their private keys and certificates, trusted CA certificates, credit card and bank account numbers, other personal identification information (like a driver's license number), 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 Windows NT, the Protected Store (P-Store) is the technology that enables all this.
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, storage could be the user's Windows NT profile, a preferences file, a diskette, or a smart card. The 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 and Outlook™ Express (Internet Explorer's mail client) to follow soon. The Personal Information Exchange (PFX) protocol securely transfers the contents of a P-Store from one location to another. For example, a user may need to copy it from an office computer to a home computer.
Smart cards are a key component of future public key cryptography in Windows NT 5.0. A smart card is about the size of a credit card and can hold a processor and local memory—a simple computer. It usually plugs into a slot on the computer or its keyboard. Smart cards can be tamper-resistant, with any attempt to dismantle the card erasing its memory. Many companies are developing smart cards for Windows NT, and Microsoft participates in the industry-wide and ISO committees that are standardizing them.
Microsoft delivers the enabling technology that lets third-party vendors readily adapt their smart cards to Windows NT. Applications write to standard smart card interfaces that hide the details of the individual card so that properly written applications can transparently use a variety of smart cards. CryptoAPI SAPI types that are currently implemented in software can be readily converted to smart cards without changing the applications that build on the CryptoAPI (a good example of why Microsoft created CryptoAPI in the first place!).
From a security perspective, smart cards can hold a user's private keys, passwords, and other secret information (which is stored only on the smart card), trusted CA certificates, and other useful information, like the addresses of shared certificate stores and Certificate Revocation Lists. Smart cards can perform the ciphers themselves, which means that the highly secret crypto keys never leave the card, even temporarily. They are ideal storage for the Wallet.
Smart cards can also strengthen user authentication through the GINA interface we mentioned earlier. Smart card logon usually requires that the user insert a card and type a short password, often called a "PIN." Authentication depends upon "something the user holds and something they know." Stealing the card or discovering the PIN alone does not allow a penetrator to log on.
Removing the smart card from its slot can lock the system just as users of Windows NT can now do from the security window. This means you can easily take your card with you when you leave your desk temporarily, keeping your session protected and undisturbed.
With prices falling and the full support of the Windows NT infrastructure, smart cards will quickly become a popular and critical security component of Windows NT enterprise networks. (See http://www.microsoft.com/SmartCard for details.)
As intranets become more secure, client applications (like Web browsers and e-mail programs) and servers (like Web servers and e-mail hosts) become more complicated because different situations require different types of authentication and cryptography. While an application writer could learn each scheme and code it directly into a program, there's a much better way. Microsoft's Security Support Provider Interface (SSPI) makes common network authentication and cryptographic data protection schemes available to both client/server writers through simplified software libraries. Programs that use SSPI do not need to encode the details of specific authentication or crypto 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 overall moniker 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:
Distributed and client/server applications use SSPI in several ways, from calling its SSPs directly to selecting security options when using DCOM, RPC, and other popular Internet APIs. DCOM (Distributed COM) and RPC (Remote Procedure Call) are enabling technologies that make it easier for people to create distributed applications—applications with cooperating components that run on different computers, perhaps even different operating systems (like Windows NT, UNIX, or Macintosh). For example, Windows NT remote administration uses RPC extensively. DCOM and RPC manage and hide the nitty-gritty details of how the different parts communicate. 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.
Perhaps a simple example will help. Most authentication protocols begin by exchanging a series of packets between the client and server:
SSPI also supports server impersonation, so at this point the server might impersonate the client user—that is, begin working under the client user's identity. If client and server are cryptographically protecting their data, each will pass each outgoing packet 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.
While we've given you a little more technical description than you may have wanted, we'd like to leave you with a feel for the degree to which Microsoft is integrating its enabling security technologies and the importance of providing these services to secure applications.
A key component of certificate management is that a Certification Authority (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. While there are several companies that provide this service, large Windows NT-based networks want and need their own certificate authorization services. Enter Microsoft's new Certificate Server.
You can think of Certificate Server as a tool kit for CAs. It accepts certificate requests from users in a variety of popular, standard formats (like e-mail), subjects the request to any number of "approval modules" that the CA can easily add to the server, then constructs and returns the CA to the user. Each site adds its own approval modules, although other vendors will likely market standard modules. A module might engage in an e-mail dialog with the user's listed e-mail address, or send a request to an assistant who researches the requester (perhaps even visits them in person) and awaits the results. Certificate Server can also manage Certificate Revision Lists. Certificate Server's value is not only the cost savings of creating certificates in-house, but also that it allows you to establish the certification policies important to your organization. You could even use Certificate Server to establish your own public certification service.
In the early days of the Web, when you clicked on a hyperlink your browser simply printed its contents to your screen. No danger there. But today your browser may invisibly download and locally run a whole bunch of little programs that ostensibly manage the presentation of the page on your screen. These "active" Web page elements, including ActiveX controls, Java applets, and good old-fashioned *.EXE files, pervade the Web and are the wave of the future. Their presence as local programs is automatic and not apparent, which is the way it should be.
How do you know these active elements don't attempt some skullduggery on your system? They run under your identity with your capabilities and, invisibly, can do everything you can do: delete files, or, perhaps worse, mail them off somewhere. They can even install a permanent, malicious program on your computer, a "virus." You certainly don't indiscriminately download software from unfamiliar bulletin boards and run it. (Well, okay, maybe we do sometimes. But we know better.)
Microsoft's Authenticode technology uses the simple cryptographic integrity features we presented earlier to help ensure that your browser only accepts active elements you deem "safe." Briefly, 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's certificate on their workstation. (It most likely comes preinstalled in the browser.) Vendors sign their active elements using the integrity algorithm we described earlier.
Your browser can now determine two important things: that an active element comes from a genuine member of that organization, and that it has not been tampered with from the time the vendor signed it. You can easily instruct your browser to ignore elements that fail these tests, or perhaps to 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? Consider an analogy. Suppose you visit your favorite software shop and buy a shrink-wrapped package from a software house that produces a wide selection of PC programs. Do you have any reservations about its safety? Probably not, for the simple reason that it's just not likely that the program is actively malicious. No legitimate software house would risk its business by selling what it knows or suspects to be tainted programs. Of course, someone could have tampered with the shrink-wrap and substituted a fake CD-ROM, or maybe the software doesn't really come from the company whose name is on the box. But the answer to these rhetorical questions is, "It's just not likely."
Authenticode assurance is analogous but even stronger. It's infinitely harder to tamper with cryptographic signatures than shrink-wrap, and the software industry organization attests that this is a genuine software vendor that willingly joined its organization. If shrink-wrap tampering is "not likely," then Authenticode tampering is "highly unlikely." (While initially intended for the Web, someday those shrink-wrapped CD-ROMs you buy from that little shop may also have an Authenticode signature!)
Java offers some additional security possibilities. Java applets don't 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." (Perhaps "prison cell" would be a better metaphor.) With the proper Java security model this can be an effective security restraint. However, it inevitably trades 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's no question that for some applets, the sandbox is an effective protection. But there's also no question that in general, it's not enough. Authenticode does not have this trade-off and needs not make concessions to usability.
While enabling technologies bespeak the promise, applications must demonstrate the reality. Many applications in BackOffice came from somewhere else and were initially designed before Windows NT became the enterprise force it is today. Microsoft is making a concerted, company-wide effort to tightly integrate these applications into Windows NT security, and the Windows NT 5.0 time frame will bring these all together nicely.
We now turn to key examples of how these products leverage the Windows NT infrastructure and its enabling technologies. There are mounds of information about each of these products on the Microsoft Web site, and most have their own security white papers.
IIS is a classic Web server, but to appreciate its security role we need only look at its full name. It's a network server of information, much like a remote database server. Indeed it's often coupled with a more classic database server like Microsoft's SNA Server that handles the "heavy-duty," back-end work of managing huge amounts of data. As an information server, IIS's security duties fall squarely within our basic principles: identify the user, apply access control, secure the network, and audit the results.
We start with single-logon authentication. When you use IIS with Microsoft Internet Explorer (or another compatible browser) the server and browser can cooperate to achieve single-logon authentication. All actions IIS performs for the user are done under the user's account, whether reading Web pages, delivering ActiveX elements, or processing forms. When you run IIS on the Windows NT native file system (and you always should), the file system ACLs absolutely constrain what IIS, running as that user, can read and write.
You can configure IIS to support three kinds of authentication. The first and strongest is the one we've just described, Windows NT Challenge/Response. With compatible browsers, IIS can also support "Basic Authentication" in which the browsing user enters a name and password that IIS validates against its Windows NT accounts and assumes that identity. (Under this scheme, passwords cross the network unencrypted, so it's not very secure.) IIS can also forego authentication and run under a special "anonymous" account. This does not mean that anonymous logons are uncontrolled. Rather, they can only access objects whose ACLs allow access to the anonymous account. You just don't know who the user really is.
IIS 4.0 can require SSL client authentication, which ultimately results in IIS receiving the user's certificate. As administrator, you can map specific certificates, or certificates whose name has a certain format, into Windows NT accounts. As before, IIS then performs all its services for this user under that account.
In IIS 4.0, you can assign security controls to any file or directory on the system. But you typically organize your Web site into distinct areas and apply controls to each area as a whole. You can designate the authentication methods for each area. You can also require SSL and limit the network clients that can access the area by network name or address. You can set overall access controls for the area that it protects in addition to the file system ACLs. For example, you can set all information in an area read-only, or specify that the area has no executable scripts. IIS can even log all transactions for a particular area in its own log.
We mentioned that IIS can use SNA Server as a backend database server. With Kerberos, IIS can pass the single-logon authentication along to SNA, which, as we see below, can also perform its actions under the user's identity, giving strong access control at the database itself.
Microsoft Proxy Server is a firewall that controls which of your LAN users can access which services on an external intranet like the global Internet. Typically, you install Proxy Server on a Windows NT Server computer on your LAN that has a second network interface to an external TCP/IP-based network—the intranet. You instruct Proxy Server which network addresses are "internal" (your LAN) and by default all the rest are "external." Proxy Server has no effect on communications between communicants within its internal world. Proxy Server closely integrates with IIS.
Proxy Server 1.0 includes two basic services, the WinSock and Web proxies. WinSock is the most general. WinSock is the Microsoft library that most network client programs use to access TCP/IP intranets. Proxy Server installs a special version of these libraries on the LAN's workstations that directs all external communication to the Proxy Server. WinSock proxy can therefore handle all client programs that use WinSock, which are the great majority of network client programs designed for Windows-based networks.
The client WinSock libraries and Proxy automatically negotiate the user's identity and thus fully implement single-logon. Proxy then applies access control to these requests based on the user account and the network service—for example, Web, FTP, or Telnet. (The "port" number in the request identifies the service because most network services use a standard port number.) The access control is quite simple. You first define the set of network services that you wish Proxy to allow and assign port information to each. For example, Web servers conventionally use TCP port 80. To grant your LAN users access to Web servers on the external intranet, you define a service named, for example, "HTTP" and assign it TCP port 80. (Fortunately, Proxy comes preconfigured with all the popular Internet services.) You then construct an ACL for each of these services—a list of Windows NT users and groups to which Proxy grants access. You can think of these services as Proxy's "objects"—that to which it applies ACLs. Proxy Server's Web Proxy handles only Web (HTTP) traffic and supports all browsers that use an Internet-standard proxy protocol called the CERN proxy protocol.
A few general security notes:
Microsoft Proxy Server 2.0 includes a variety of new security features:
Microsoft Exchange Server is a scalable, secure, messaging and groupware server that fully leverages the security infrastructure of Windows NT. Microsoft Exchange Server manages three basic services:
A large enterprise organizes itself into Exchange "sites." Exchange Server automatically replicates information throughout a site, backs it up, and applies certain fail-safe protections. It can also replicate information between sites. Exchange Server natively implements Internet-standard messaging protocols like SMTP, POP3, NNTP, and LDAP, and supports a wide variety of off-the-shelf Internet clients as well as Microsoft clients like Microsoft Outlook. Exchange Server also works with Microsoft's Internet Information Server (IIS) to give Web browsers ready access to data stored within Exchange Server.
Microsoft Exchange Server fully supports Windows NT single-logon and user groups. Clients logging on to Exchange Server use Windows NT's Challenge/Response authentication to validate their user's Windows NT logon identity. Exchange then grants the user access to Exchange resources based on that identity. Exchange enforces access controls on all its objects, including mailboxes, public folders, and directory items. For example, a mailbox has "Users" permissions that allow reading and deleting messages, "Send As" to send mail with the mailbox as the return address, and "Permissions Admin" to manage the ACL on the mailbox.
Microsoft Exchange Server ensures network privacy for network traffic, whether client-to-server or server-to-server. Exchange Servers use secure RPC to encrypt traffic among themselves and Exchange clients can optionally use secure RPC to encrypt communication to their server. Network encryption is also provided for Internet-standard protocols by layering SSL over protocols such as HTTP, POP3, NNTP, and LDAP.
Exchange clients (including the Microsoft Outlook desktop information manager) also provide end-to-end security for e-mail. The versions of Microsoft Exchange and Outlook clients included with Exchange Server contain "Advanced Security" software that lets you easily sign and encrypt your e-mail digitally. Digital signing uses the MD5 algorithm and encryption uses either the CAST (40- or 64-bit for North American clients, 40-bit only for international clients) or DES cipher (56-bit, North American only). Signature and key-exchange functions use the RSA public/private key cipher. Because all users' public certificates are published in the Exchange Directory, secure e-mail can easily be sent to others in your organization. Users can also "trade" certificates over the Internet through e-mail. This lets you send secure e-mail over the Internet to users of Exchange or Outlook in other organizations.
Before clients can sign or encrypt mail, they need to obtain their personal crypto keys and certificates. Microsoft Exchange Server includes a complete Key Management Server (KMS), with two main functions: to serve as a X.509 Certificate Authority for your Exchange organization and to provide secure key recovery for all users' private encryption keys. (This is based on software licensed from Entrust Technologies.) This key recovery function uses two public key sets for each user: one to digitally sign messages they produce, and a second to transmit decryption keys to recipients. The KMS generates the latter key set and archives it in a secure database for future recovery. If a user loses the private key file, forgets the password to the file, or leaves the company, an authorized KMS administrator can recover the user's private keys so that access can again be gained to previously encrypted e-mail. Signing key sets are generated privately by the client and the private signing key is never given to the server. This prevents administrators from being able to forge employees' electronic signatures, while still retaining the ability to recover user encryption keys.
Future releases of Microsoft Exchange Server and Microsoft Outlook clients will expand on these features, and move them forward to comply with emerging standards. In particular, these features will be expanded to include industry-standard secure e-mail formats (S/MIME), and industry-standard certificate formats (X.509 V3).
Microsoft 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, like the Web servers. SQL Server is an interesting security story and perhaps best illustrates the convergence of BackOffice products around Windows NT. SQL Server's popularity predates Windows NT, and therefore SQL Server had to implement most of its own security. With the emergence of version 7.0 and Windows NT 5.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 so that front-end servers like IIS can pass on the client user's identity to SQL Server. It also implements its own internal roles, which are similar to Windows NT groups. SQL Server uses these roles largely for internal administration and the advantage is that you don't need to clutter the Windows NT group list with groups largely internal to the server.
SQL Server applies access control to the database elements it manages (tables, views, stored procedures, as well as 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 a number of internal administrative roles, and includes a number of other database-specific security features. Future plans include using Secure RPC to encrypt network traffic.
SNA Server (SNA is a traditional protocol used to access mainframe computers) lets your regular Windows-based workstations act as terminals into traditional mainframe computers, in which a window on your Windows workstation becomes a terminal connection to a remote mainframe. SNA Server is the connector that manages the traffic between Windows clients on its Windows NT-based network and, through an SNA connection, a group of mainframes.
SNA Server integrates with Windows NT security to provide single-logon to the mainframes. SNA Server stores the mapping between Windows NT accounts to mainframe user credentials that it uses to log the user on to the mainframes (at least when the mainframe protocols allow). These credentials are always encrypted when on the Windows NT-based network. SNA Server also controls overall access to mainframes based on the Windows NT user identity.
With the help of a few third-party programs, SNA Server can also synchronize passwords between Windows NT accounts and their corresponding host accounts. When a user changes a password in either location, SNA Server automatically changes it in the other.
SNA Server leverages Microsoft's Secure RPC protocols and can encrypt all traffic over the Windows NT-based network. This gives rise to an interesting configuration, in which an SNA Server sits next to its mainframes in a locked room but attaches to a wide-area Windows NT network, which could even include remote (RAS) connections. The Windows NT cryptographic and authentication umbrella fully protects the distributed system as a whole. With the Windows NT wealth of cryptographic services, secure sites might prefer this configuration to encrypted SNA networks.
Authenticode forms an integral part of Microsoft Internet Explorer security. You can instruct Internet Explorer to check Authenticode on all active elements and whether to give you the option of running the element anyway if the check fails. Internet Explorer also shows the complete certificate including its CA to help make your decision.
As we mentioned above, Internet Explorer and Microsoft's Web server (IIS) can also work together to fully implement single-logon. The Web server can automatically use the browsing user's Windows NT logon identity for access to all Web pages and services. They use the Microsoft Challenge/Response protocol for authentication so unprotected passwords never pass over the network. They can also require SSL, which adds additional protection for the user's credentials. These features achieve the overall goals of single-logon authentication, access control, and encryption.
Internet Explorer 4.0 introduced a new feature called zones. There are about one dozen detailed security actions you can direct Internet Explorer to perform on active elements. Each directs Internet Explorer to run or ignore the element, or query the user for the decision. Internet Explorer predefines three typical sets of these parameters, which it names: High (the most restrictive), Medium, and Low (most permissive). Zones let you specify which settings apply to which Web address, but in a structured and easy-to-use manner. You begin by dividing the Web sites you visit into four zones and assign one of the standard sets of parameters to each zone. (You can also build a custom set for a zone, but you seldom need to.) The four standard zones are:
Internet Explorer fully supports the latest version of SSL and PCT. You can also direct Internet Explorer to use only SSL in certain zones.
Finally, while these features are powerful, it's hard to assume that day-to-day users can deal with even the simple ones. Must they each judge the degree to which they can trust the sites they visit? Microsoft's Internet Explorer Administration Kit lets site administrators centrally manage the Internet Explorer installations at their site. With this kit, administrators can centrally configure all these security settings and essentially prevent users from changing them. For more information, check out the Microsoft Internet Explorer 4.0 white paper at http://www.microsoft.com/ie/press/whitepaper/iwhite/white005.htm.
Electronic mail is the proverbial example of the need for cryptographic technology. Although there's never been a lack of raw crypto technology, until S/MIME there's never been an industry-wide standard strong enough to infiltrate the amazingly wide world of e-mail clients. S/MIME is a widely supported standard for signing and encrypting e-mail. It provides all the basic cryptographic protections we presented earlier: encrypting (data hiding), integrity, and ensuring the identities of both sender and receiver. S/MIME incorporates standard public and private key ciphers, hash functions, and the certificate technologies.
At Microsoft we've fully supported the S/MIME effort and have announced S/MIME functionality in Outlook and Outlook Express e-mail clients. While conformance to S/MIME is the goal, the secret to the success of Outlook is its utilization of the entire Microsoft public key and certificate infrastructure. It is perhaps one of the best examples of "putting it all together."
There are many other success stories. For example, Microsoft's FrontPage® Web authoring product has an extension that lets Web administrators control access to their Web content in simple terms by assigning Windows NT accounts and groups permission to author, browse, and administer the Web content. These are simple features that completely use the IIS single-logon authentication, impersonation, and the Windows NT file system ACLs. The Enterprise Edition of Microsoft Site Server is a comprehensive package that assists businesses in establishing electronic commerce and shopping sites on the Web. Site Server implements virtually no security itself because it completely leverages IIS and Windows NT security, as well as commercial transaction security products like SET for credit card payments.
We can now put our picture together. We've seen the basic principles upon which Microsoft is building its security architecture. They are basic, time-honored, effective, and state-of-the-art, and target the network environment. The features of the Windows NT operating system are the bedrock of system security, its domain-based security features kept secure by its underlying kernel architecture and pervasive access control lists. Microsoft's enabling technologies bring common but complicated security technology (including those used within Windows NT itself) within easy grasp of application programs. This ensures you an ongoing selection of consistently secure applications.
Finally, BackOffice and its companions tightly integrate into and leverage the Windows NT security environment and complete our security picture. We hope that by now that you agree that the Microsoft Windows NT security environment is one worthy of protecting your enterprise networking environment.
Thanks for considering our story.
This article was written for Microsoft by Steve Sutton, president of Trusted Systems Services, Inc., and author of the popular book Windows NT Security Guide (Addison-Wesley, 1997).
The information contained in this document represents the current view of Microsoft Corporation on the issue discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.