Security In a Software Development Environment

Windows NT provides a number of different "environment subsystems," such as the Windows subsystem, the POSIX subsystem, and the OS/2 subsystem. Each of these subsystems presents a set of application programming interfaces (APIs). These subsystems are built using an underlying set of programming interfaces and mechanisms that are primarily used only in the development of the operating system and operating system components (such as device drivers and environment subsystems). These underlying mechanisms are not designed to be used in the development of applications, such as word processors or database server packages, and so generally are of little interest to a security administrator. However, this is not always the case, and in some circumstances these mechanisms are of vital interest to security administrators.

A typical shrink-wrapped product from a reputable manufacturer uses only the programming features explicitly provided for application development. However, what do you really know about a shareware program downloaded from a public network server? It might try to take advantage of some of the mechanisms in Windows NT that are not intended to be used by application programmers — either for beneficial uses, or maybe to introduce a Trojan Horse or virus program into your system. This might also be true if you purchase software from a company more interested in exploiting every bell and whistle, rather than producing quality products using published interfaces and mechanisms. Even your own developers, if your company does its own in-house software development, could use these mechanisms in their programs. As you can see, there are situations where understanding some of these underlying mechanisms and being able to monitor their use is vitally important.

This document helps you to understand some of Windows NT's underlying and internal APIs and mechanisms. It also provides information that can be used by a security administrator to monitor these mechanisms and to interpret the log files generated as a result of this monitoring. This information is, necessarily, quite technical in nature, being roughly equivalent to programmer documentation. In fact, the information in this document might also prove to be useful background for anyone wishing to write some automated security monitoring tools.