This section presents the requirements related to the physical design of servers.
171 Icons are provided for all external connectors
This requirement helps ensure that the end user can correctly make the physical connections required for adding a device to a system. This requirement includes the following:
Wherever possible, keyed or shrouded connectors or other configurations should be used to prevent misconnection. The physical design of the connector must ensure that the user cannot mistakenly insert the connector into the wrong port.
Icons are provided for all external connectors. The icons can be molded, printed, or affixed as permanent stickers (which can include text). Icons can be based on existing vendor designs or on the examples shown on http://www.microsoft.com/hwdev/desguid/icons.htm.
Specific requirements are not defined for color coding of connectors and other cable markings, but the system designer is free to implement color coding in order to enhance user accessibility.
Note: It is recognized that the design for legacy ports, such as the PS/2-compatible mouse and keyboard ports, analog audio and video jacks, and the microphone and speaker jacks, will not change and therefore cannot fully meet this requirement. However, icons and labels must be provided wherever possible to help the user make the correct connections.
172 All expansion slots in the system are accessible for users to insert cards
The space for expansion cards that will reside in associated expansion slots cannot be physically blocked by components or devices provided with the system. However, this requirement does not exclude configurations that allow space only for half-height cards for some slots, passive back planes for connectors, and so on. It is understood that in order to install expansion cards in some expansion slot implementations, users might have to temporarily move other system components to gain access to the slot. In general, designers should minimize this juggling as much as possible.
173 System and device design include protected switches
Switches can be covered with a hood or other protection to prevent inadvertent switching. Locks can also be provided to prevent unauthorized access.
174 System design includes locking case
The computer case can be protected with key locks to prevent unauthorized access.
Other recommended features include: Key lock removes the computer case without additional tools (if this can be done and maintain compliance with other safety standards), and software management of physical components as documented in Windows Hardware Instrumentation Implementation Guidelines, Version 1.0 (WHIIG), which also defines the Windows-specific requirements of the Wired for Management Baseline Specification, Version 2.0, for hardware instrumentation.
175 System and device design include snap-on connectors
Snap-on connectors should be implemented to ensure connections. It is recognized that certain legacy connector implementations such as PS/2 pointing devices and keyboards will not generally allow this. However, locking cable connections provide a valuable reliability feature for end users.
Hardware Security Requirements
This section summarizes the system hardware security requirements and recommendations.
A baseline measurement of a secure operating system is the U.S. National Security Agency’s criteria for a C2‑level secure system. The requirements for a C2 secure system are articulated by the U.S. Department of Defense’s National Computer Security Center (NCSC) in the publication Trusted Computer System Evaluation Criteria, also known as the “Orange Book.” All systems, whether they are network operating systems or stand-alone operating systems, are evaluated under the criteria set forth in the Orange Book.
Windows NT Server was designed to comply with the NCSC’s Orange Book requirements. Every process and feature was designed with C2‑level security in mind. Because the Windows NT Server C2 implementation is entirely software-based, users will not have to install additional hardware on either their servers or clients to meet C2‑level security requirements. However, the hardware must meet minimum requirements for C2 evaluation with Windows NT. The C2 evaluation report is available in the following publication:
FINAL EVALUATION REPORT Microsoft Windows NT Workstation and Server Version 3.5 with U.S. Service Pack 3. National Computer Security Center, 23 June 1995.
In addition to its C2 evaluation, both the base and the network components of Windows NT have received the F‑C2, E3 ITSEC rating in the United Kingdom. This rating can be leveraged in Germany and soon in France and the Netherlands. Therefore, customers in both the U.S. and Europe can operate certifiably secure systems.
176 C2 evaluation for hardware
C2‑evaluated hardware meets requirements defined in the Orange Book.
For hardware designed for customers outside the U.S., equivalent evaluation might be defined in local standards, such as F‑C2/E3 ratings in Europe.
177 Peripherals meet hardware security recommendations
OEM-specific solutions can be implemented to meet these recommendations. The recommended hardware security features include:
External drive devices should have locking capabilities. Each removable media device on a server system should be capable of being locked to prevent unauthorized access to data. This means that the device is rendered useless, either electronically or mechanically.
Computer case and switches should have locking capabilities to prevent unauthorized internal access. An OEM-specific method can be implemented, either electronically or mechanically.
Remote software management should be supported for physical components.
Controls and remote alerts should be provided for chassis-open intrusion.
Smart card readers and cards should be provided. If provided with a server system, smart card devices must be compatible with Interoperability Specification for ICCs and Personal Computer Systems, published by Bull Personal Transaction Systems, Hewlett-Packard, Microsoft, Schlumberger, and Siemens Nixdorf at http://www.smartcardsys.com.
In addition, smart card readers and device drivers must be Plug and Play–compliant and must adhere to the Win32 smart card specifications published in the Windows NT DDK. Smart card applications and service provider DLLs must adhere to the Win32 smart card specifications published in the Win32 SDK.
Chapter 7
Basic Reliability, Availability, and Serviceability Requirements
These requirements and recommendations relate to ease of use and ease of maintenance issues. Design guidelines that make configuration and server setup easier for end users and administrators are defined to help reduce the total cost of ownership for servers.
Reducing the total cost of ownership is an important goal for servers; a key priority in this effort for servers is minimizing down time. This goal is achieved through mechanisms for backup and reliability, remote management, and emergency and preboot management.
|
