- Introduction
- Determining What Constitutes Normal System Behavior
- Why Characterization Is Important
- 1: Document and Verify Characterization Trust Assumptions
- 2: Characterize Typical Network Traffic and Performance
- 3: Characterize the Expected System Configuration and Performance
- 4: Characterize Expected Process and User Behavior
- 5: Characterize Expected File and Directory Information
- 6: Generate an Inventory of System Hardware
- 7: Recognize the Iterative Nature of Data Collection and Characterization
- 8: Protect Characterization Information, Authoritative Reference Data, and Hardware Inventory to Ensure Their Integrity
- 9: Policy Considerations
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
3: Characterize the Expected System Configuration and Performance
Document the procedure to verify that systems are performing as expected. The type of information captured by the characterization helps answer these questions:
What is the range of acceptable performance levels provided by the organization's systems?
What constitutes an acceptable operating system configuration?
It also includes system performance data and other system data described in Table 1.
The operating system's foundation as loaded into the system's memory—called the kernel—may change, usually through the addition of device drivers. Knowing the specifics of any changes and whether they're acceptable is the key. For example, if a different type of Ethernet controller driver is loaded into a system kernel, is that considered routine?
There are no products—commercial or otherwise—that provide a complete solution. However, some strategies can be used to reduce the likelihood that the kernel will change unexpectedly. For example, Windows 2000 (and later versions) uses a technique called driver signing. This gives an administrator more confidence that the driver being loaded into the kernel came from a known and hopefully reputable source. The chances are that the driver will work as advertised and not perturb the kernel in unexpected ways.
Similarly, on some Linux systems adding drivers and other modules to the kernel can be prohibited; so can changes to special files that reference kernel memory. This means that the kernel can be made unchangeable beyond a specified point in the system boot process.
In both of these cases, the kernel's integrity is not checked, but controls are used to limit what can be done. This gives an administrator more confidence that the system is running as expected and that an intruder has not altered it.
Comparing the previous system kernel configuration and performance information with current information allows an administrator to determine whether any system characteristic is beyond tolerable or acceptable limits.