For IT departments and MIS managers at many companies, securing Windows NT and Windows 2000 environments, particularly as they connect to the Internet, has become a major priority, and an enormous challenge.

As everyone breathed a collective sigh of relief over the quiet passing of the "Y2K" deadline, a wave of high profile denial of service attacks highlighted the inherent fragility of the ecommerce infrastructure. These attacks were followed by unprecedented levels of Internet-borne malicious code infection, large-scale e-mail outages, and costs to businesses and government agencies measured in billons of dollars.

Sadly, these losses to the ever-present dark side of information technology were entirely preventable. But that is not a message victims like to hear, which may explain the growing Windows NT/2K security myth, a misguided belief that Windows 2000 NT and Windows 2000 environments are inherently insecure, and thus doomed to become the playing field of malicious coders, criminal hackers, industrial spies, disgruntled employees and unethical business partners. Allow us to explain why this is simply not true.

You have the technology

Windows NT has always contained powerful security mechanisms. These have been significantly enhanced in Windows 2000. But many organizations have failed to take full advantage of these mechanisms. The reasons are many and varied and entirely understandable, beginning with the rapid pace at which internal networks have expanded. Add the staggering rate at which those internal networks have been connected to external networks, including the public Internet and remote users, and it is easy to understand why chinks have appeared in the infosec armor.

At the same time, an unprecedented level of "freelance system-testing" has been taking place outside of corporate and government circles, in "underground" chat rooms, Web sites and bulletin boards. Large numbers of attacks have been devised, scripted and published by a worldwide collective whose members are motivated by everything from curiosity to fame and unfair gain.

While this "system testing" has turned up some genuine coding errors and security holes within Windows NT, the vast majority of security weaknesses in NT environments are not weaknesses in the technology itself. Rather, they arise from the way in which the technology is implemented, and are thus a people factor, one of several we will address later. As to the relative security of NT, only one item on a recent list of top ten Internet security threats was specific to Windows NT, namely flaws in Microsoft Internet Information Server (the report is available from the Web site of SANS, a private company with a reputation for objective security analysis). Five of the remaining nine threats were Unix-related, while the other four applied to both Unix and NT systems.

There is not enough space here to enumerate the security features available in the Windows NT environment, or the many sources of information on how best to implement them, but a comprehensive list of references has been included for those whose job it is to know this stuff. What we can provide are two proven methodologies for making sure that your NT environment is as secure as you need it to be: the security cycle and the three-layer analysis.

The security cycle

You begin the security cycle by turning the phrase "secure as you need it to be" into a question. Optimal security time and effort levels can only be achieved if you ascertain management's risk tolerance, which can only be arrived at through a proper understanding of current threats. This is the risk assessment phase of the cycle, shown in the figure below. Your organization should develop and document a Standard of Due Care, comprised of a threat analysis, plus baseline best practices in information security, both general and industry segment specific. For example, a bank may have different risk tolerance from a video game company. Different standards of care may be indicated, although some underlying legal and regulatory issues, such as privacy protection, may apply to both.

Your organization needs to document what data and services are being protected, and from whom. Acceptable scope of compromise scenarios should also be established, for example, what is the maximum acceptable downtime for the corporate Web site? The security design phase flows from this, with an overall enterprise infrastructure architected to minimize the effect of the compromise of a single component (the three-layer analysis we describe in a moment will help with this). Intrusion detection systems should be designed in at the network, host and application levels. For example, place an IDS "sensor" between the outer router and firewall to detect failure of your first line of defense. A sensor beyond the outside router will give you information about attempted attacks while a sensor between firewall and inner router will detect failure of the firewall, and so on.

In the Windows NT environment, secure design requires an appropriate domain structure, plus proper grouping of users, and OS hardening. Based on these parameters, a secure NT build is developed, incorporating the appropriate patches and service packs, but eliminating all superfluous accounts, privileges, components and services. The build is then lab-tested, prior to deployment, which only occurs after comprehensive documentation. Subsequent tests, performed by internal staff as well as by reputable, objective external testers lead to improvements, which are tested iteratively.

Architecture mapping tools, such as nmap and firewalk, are useful in this process, together with automated vulnerability scanning tools such as ISS. Allowed path testing should not be overlooked (an allowed path is a path permitted through the infrastructure in order to facilitate the proper operation of the applications — routers and firewalls cannot inspect the message payload for validity and are unable to guard against attacks initiated through allowed paths).

Next you enter the monitoring and maintenance phase, using IDS and logging tools to monitor the system, plus a watchful eye on vendor and community security bulletins. Mechanisms should be in place to learn of new vulnerabilities and patches as soon as possible, since attackers are constantly probing for systems that have not fixed known holes. After a meaningful period of operation in this mode, the cycle should be restarted, with a fresh assessment of risks and security standards.

Security layers

Three-layer analysis, developed by my colleague, David Brussin, is a repeatable methodology for creating verifiably secure systems. The three layers are architecture, protocols and applications. By asking the following questions and performing this type of analysis you can develop more secure systems.

The architecture layer looks at system components from clients to the back-end, including operating system, servers, databases, firewalls and routers, asking how they are configured. What physical infrastructure connects components? What is the high level data flow through the environment and how does it move between the components to implement application functionality? What are the security requirements associated with each step in the data flow and what allowed paths does it require? What services have to be available on each component to implement the application functionality? How do network security mechanisms restrict the allowed paths, for example, where do firewalls and routers exist, and how are they configured?

An effort is then made to resolve the architecture into trust domains and map trust boundaries. A trust domain is a logical grouping of systems based on the required level of confidence in each system's operation and integrity. A trust boundary is a connection between systems in different trust domains. Obviously, there are serious security requirements for crossing a trust boundary. The protocols used must be mature and well-defined and the end point within the domain of higher trust must be controlled and well-defined.

The architecture is also assessed for resistance to successive compromise. For example, when connecting a Windows NT environment to the Internet, a screened subnet architecture and DMZ are desirable. A screened subnet is created when ACL's on the router are set to match the restrictions on the firewall behind it. This is resistant to single component failure and newly developed attack techniques. A DMZ is protected from the untrusted systems, such as the Internet, and the trusted systems are protected from the DMZ, because it is not one hundred percent trustworthy. The DMZ acts as a buffer between untrusted and trusted systems by providing an endpoint for immature, complex protocols. For example, HTTP requests are terminated within the DMZ and passed to the back-end system via a more robust protocol.

In the Protocol layer of the analysis you check the protocols used to implement the high level data flow. Do they provide adequate security capabilities? It is important to know when protocols cross trust boundaries and if so, are the protocols appropriate? When reviewing the maturity and complexity of protocols a trade off is often made between versatility and utility. For example, HTTP and SQL are very versatile, but they also may provide additional functionality that can be maliciously exploited. As a rule, protocols should be mated to the architecture, for example, HTTP only on port 80, and only to the Web server.

The Application layer analysis looks at the how application components used to implement the high level data flow provide the necessary security requirements. Is the business logic appropriate? Are appropriate secure coding techniques in use? How are critical protocol endpoints implemented? Are endpoints resistant to hostile traffic and allowed path attacks? Is data sanitized prior to handling. Do third party application components meet security requirements? Review of code and in-house development practices is required at this stage.

People, authentication, and Windows 2000

Implementing security in any enterprise system, through careful analysis, design and testing, requires an adequate staff of highly-trained technicians, familiar with the technology. But security itself is not about technology. It is a people problem, and reliably identifying who is using your system is the single biggest security improvement you can make. As the accompanying diagram indicates, authentication of users is the hub of all security processes. Sadly, too many networks still rely on password authentication, which is inherently weak, given the limitations of human users.

Fortunately, Windows NT supports two and three factor authentication, including tokens, smart cards and biometrics. These should be used as widely as possible. It can be argued that the not inconsiderable investment in NT licenses is not money well spent unless security is based on something stronger than user passwords.

Support for token-based authentication is even more seamless in Windows 2000. But evolving to Windows 2000 is a complex process, with security implications of its own. NT trust domains may not map easily to the active directory structure of Windows 2000, and the real world security testing of Windows 2000 has only just begun, suggesting that organizations with a conservative security posture should delay upgrading until at least the first service pack.

However, the planning phase required for Windows 2000 migration is an excellent time to implement the security cycle and three layer analysis described here, and move your Windows environment to a new level of reliability and resistance in the face of adversity.