<B>Special Feature:</B> Protecting Your Applications

• 10/07/1998

The simple and familiar username and password box, well-known to every Windows NT user, hides a complex and feature-rich security environment. The key to understanding this complex environment is to accept that users are the center of the Windows NT security model. Every time a program attempts to use a printer, read a file, or access a shared network resource, the program must do so on behalf of a user on a local computer. All security under Windows NT is based on three things: the user's account, the resource that is secured, and the rules that express what permissions the user has for that resource.

An important part of this security architecture provides authentication for each Windows NT user. Today, using the familiar username and password box, users are authenticated against a database of accounts. The crucial database is called the Security Accounts Manager (SAM). It stores Windows NT’s local and group accounts information, as well as the authentication information -- usually passwords -- needed to use them. This means that the SAM contains all the information needed to act as a single point of entry for Windows NT systems. When Windows NT 5.0 is delivered, an expanded set of authentication options will be available to developers; the sidebar on Windows NT 5.0 security, "Security: The Transition to NT 5.0," explores some of those new options.

Once Windows NT has authenticated a user, all further access to the system takes place via access tokens generated by the Local Security Authority (LSA). The access tokens consist of a special security identifier (SID), along with information specifying the user groups in which groups the user belongs, default security permissions and other information. It is the access token, not the username and password combination, that is passed around the network as a user's passport for access to services and network objects.

The core of all further security under Windows NT is the Security Reference Monitor (SRM). When a user presents an access token with a request to access a file or use a printer, the SRM acts as passport control: allowing access to those who have permission, denying it to all others. Like any control authority, the SRM also logs the activities of those who make requests of the system.

The user-centric nature of Windows NT security has profound implications for those who need to build security into applications. For instance, an administrator cannot prevent access to a SQL Server database from Excel. While an administrator can easily establish what rights a particular user has regarding the database, if the user has the proper permissions he or she can use any tools to execute that access.

In meeting their customer's needs, many software designers recognize that either the application's information itself is sensitive or that the underlying business processes need protection. To meet specific security or confidentiality requirements, many application designers invent their own schemes of storing usernames and passwords to control and log access. This allows application designers to guarantee that their programs provide a layer of security in addition to their basic functionality.

Security facilities emerge at many levels: at the operating system, in the database software, or customized for the application itself. These options give application developers fine-grained control over user access and permissions. The cost of this control is reflected in the complexity of administration of a custom security environment and the rebellion of users who are forced to remember a plethora of user accounts and passwords.

Through the Win32 API, Windows NT allows application designers to use the same routines that the operating system uses to manage security. Application designers say that the programming tools "expose" Windows NT's security infrastructure by making it possible to use the same tools that Window NT does.

The security component of the API consists of more than 100 routines that an application designer can use. The breadth of this support shows one of the key problems facing the application designer who chooses to strike out on his or her own and design a specialized security architecture. Designing a secure username and password scheme is complex by itself; combining it with rules for file access and sharing resources such as printers makes building your own security services a Herculean task.

To understand how Windows NT security can be used by applications, you simply need to understand the basics of how the security API works. Every resource in the system that can be protected -- such as files, printers, processes, and behind-the-scenes resources such as threads and pipes -- is called an object. Every object in the system is given a security descriptor. The security descriptor has information about the object's owner, a primary group identifier, rules for what happens if a process with system-level privileges needs access to the object, and a set of rules for general access called the discretionary access control list (ACL).

The discretionary ACL is crucial to those building applications that use Windows NT's embedded security services. The Windows API provides a large number of routines that allow a program to query access rights and set new permissions and other security parameters. These routines enable developers to use Windows NT's underlying security for custom security needs rather than write entirely new access control code.

Karan Khanna, product manager of the Windows NT security team for Microsoft Corp., says that the goal of the API is to expose Windows NT security to developers in multiple ways. "It allows individual designers or ISVs to make their own decisions regarding security," says Khanna. "In addition to the security functions we expose in the Win 32 API, we wrap standard cryptography tools in the CryptoAPI and the ability to extend the Windows NT security model using the Security Support Provider Interface [SSPI]." The CryptoAPI is the programming interface that enables users to use Microsoft’s cryptography routines in user-developed or prepackaged software.

The business advantage to using a single security model is significant. Users need only sign on once to the system, and their authentication information then serves as the basis for all future security interactions with the operating system or applications. Application programmers are freed from having to develop their own security applications and can concentrate on meeting the business needs of the application rather than administrative security needs. Perhaps overlooked among the advantages is the fact that using the underlying security means that, as security protocols and standards change, the applications developer doesn't have to struggle to keep up. Instead, by using the security API, the developer can take advantage of stronger authentication and better cryptography, without ever having to change the application.

The easiest way to find out if a packaged application is using Microsoft's built-in security facilities for Windows NT "is to see if the product has been certified to be BackOffice-compliant," claims Dominique Brezinski, network security specialist for Secure Computing Corp. (Minneapolis, www.securecomputing.com) BackOffice certification requires that the application use Microsoft's security APIs."

It's not quite as easy for applications not designed with Back Office in mind. "You can ask if the application is using the SSPI interface for client/server authentication," says Secure Computing's Brezinski, "and you can also ask if the application requires you to take advantage of Windows NT's access control lists." Brezinski points to another indirect technique for finding out if an application is using the Windows NT security model. If it communicates using Microsoft’s Remote Procedure Call (RPC) or DCOM techniques, "it's very likely that it also follows the NT security model."

Not every application can take advantage of Windows NT's built-in security model. Those applications running across multiple platforms have no way to convert the Windows NT specific SIDs into meaningful authentication information for other operating systems. Khanna of Microsoft says this is one of the most common reasons developers choose not to use Microsoft's built-in security model: "When developers are building multiplatform, enterprise applications, the primary problem is sharing the credentials and access control information in a meaningful way."

Commercial software that attempts to map corresponding identifier information between platforms is available, but perhaps a better solution is the migration toward standard multiplatform security protocols such as Kerberos. Microsoft, according to Khanna, is moving away from its proprietary NT LAN Manager credential process to Kerberos in version 5.0 of Windows NT.

"Security today touches everything: transaction and directory services, the Internet, as well as traditional applications," says Microsoft's Khanna. "There are lots of additional benefits to using a comprehensive security model, and the benefits are getting greater over time." Not only are the benefits of using the Windows NT model getting greater; the model is getting easier to use. Secure Computing's Brezinski says that "with Windows 3.5 it took a couple of days to get the security interface right. Now, with version 4.0 and its higher level APIs, it's become pretty simple."

A security model that's simple to use and comprehensive enough to depend on is important to every application designer. The evolution of the Windows NT security model has reached that goal: Now it's up to network designers and developers to take advantage of it. --Mark McFadden is a consultant and is communications director for the Commercial Internet eXchange (Washington). Contact him at [email protected].