Use custom hardware.
For select high surety systems, such as weapons systems and high consequence special purpose control systems, custom hardware is appropriate. These are generally classes of analog control systems and/or finite state automata used in conditions where very particular environmental challenges arise and control complexity is limited. Another area where such controls are used is very low cost low surety systems, such as trivial on-off controls in custom pools and similar sorts of devices where common floats or similar mechanisms may have to be adapted to the specifics of the situation. Such systems are rarely used for medium surety except in high volume (e.g., automobiles) where they are no longer custom, because off-the-shelf systems are less expensive than the likely lifecycle maintenance cost of custom hardware in these situations. Such systems are not remotely alterable and generally have fixed or only slightly adjustable function over their lifecycle.
Use customizable hardware / state machines.
Customizable hardware, such as hardware-based programmable logic controllers (PLCs), distributed computing systems (DCSs), and hardware/software combination systems using field programmable gate arrays (FPGA), electrically erasable programmable read only memory (EEPROM), and similar reprogrammable technologies are used in environments where high volume manufacturing is called for, but high performance or hardware-controlled changes are required. These are used across a wide range of systems, including firewall technologies used to support application-specific detection mechanisms.
Use trusted systems of the proper type (CC, TCSEC,
TCG) in certified configurations.
For systems with general purpose software (e.g., many SCADA and HMI systems and select newer PLCs, DCSs, Routers, and security devices) interacting with high consequence environments, trusted system approaches are sometimes justified. Depending on the integrity (TCG), confidentiality (TCSEC), or other requirements of these systems, specific certified approaches are appropriate. The proper certification (Common Criteria is the most likely certification of interest except for TCG systems related to integrity only controls) at the proper level should be chosen based on the specific requirements, and with detailed analysis by specialists who understand both the protection profiles and the surety levels and how they relate to the specific issues at hand.
Use bootable CD-ROMs or equivalent to assure
configuration control at each use.
Hardware-based protection that assures a standard initial condition with configuration determined by a modifiable read-only device (such as a hardware write-locked floppy disk or USB memory device) and operated forward from that point, combined with a reasonably limited set of functions, provides a substantially trustworthy environment for most situations without going to the higher expense of trusted systems. While there may be weaknesses, they are generally dealt with through patching and upgrades to the CD-ROM and the configuration media. And the advantages of getting to a known initial state are substantial in being able to rapidly reconstitute an operational state, making these systems particularly useful for high availability. This also includes virtualized computers in which the virtual machine can be reconstituted at every login for the specifics of the user configuration.
Use heavily controlled configurations with
minimal required functions.
Heavily controlled configurations are typically limited as to what is permitted within the systems, what can be placed on the user's desktop, limit downloads and the ability to execute code not provided with the environment, include a range of detection and control mechanisms, and minimize the loaded software and data based on the need. No "root" access is allowed on these systems except for maintenance purposes and maintenance is usually done by a separate process than use. These typically include controlled update mechanisms that are not fully automated, specific cryptographic coverage, antivirus, antimalware, white listing, integrity shells, and other similar mechanisms based on the operating environment, include forced audit mechanisms, and may operate with limited identity management access mechanisms, with augmented local controls.
Use common operating environments with
established controls and managed updates.
Most enterprises use common operating environments to reduce the workload associated with management of large numbers of similar machines. These provide common configurations with some user settings, data, and programs and reasonably flexibility for the user, but typically limit root access, provide for remote update mechanisms, allow management control over cryptography, have managed antivirus, antimalware, and other similar mechanisms, include audit mechanisms, and operate under identity management access mechanisms.
Use standard operating environments with
anti-malware and up-to-date patching.
These are commercial off-the-shelf systems, such as Windows, OS-X, Linux, or other similar operating environments augmented by the enterprise to include patch management and software defenses against computer viruses, malware, and so forth. They are relatively easy to generate by buying standard computers and adding limited software after procurement.
Use off-the-shelf operating environments in
These are commercial computers with whatever operating environments they come with.
Use a digital diode to limit flow only TO the
Audit zone FROM the environment.
Generally, the audit environment should be separated from all other environments with a digital diode.
Use virtual machines for risky operations to limit effects on the remainder of the endpoint. Virtual machines may be used as part of a microzoning strategy to limit effects of content, applications, or access to subsets of the endpoint environment.