- 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
7: Recognize the Iterative Nature of Data Collection and Characterization
Initially, collect as much data as possible; you may not know which data will be the most meaningful. Over time, begin to identify filtering approaches that successively refine what data to examine. In addition, such refinement supports identifying trends in behavior and specific activities and events that constitute normal behavior. This behavior can then be captured as part of the current characterization baseline. However, it's important to note that systems and the operations that users perform on them are always changing (for example, the addition of new software, or changes in user privileges due to new assignments), so periodically examine characterization information to determine whether it needs to be updated.
Having a trusted characterization baseline is crucial for identifying departures from normal and expected behavior that warrant further investigation. In addition, data that reveals normal and expected behavior can be eliminated from further consideration, allowing an administrator to focus attention on a smaller set of data demonstrating unexpected behavior, including potential intrusions.
Characterizing software, hardware, and information assets and keeping characterization information up to date are time-consuming, complex, and ongoing tasks. An administrator needs to determine, in advance, the level of resources that can be committed to this activity—and then stick to it. It's difficult to estimate both the time required to develop an initial characterization baseline and the additional time required to keep it updated. One good guideline is to periodically observe a system's behavior for three to six months and then derive the initial characterization baseline from that observation, using some of the data-collection mechanisms described in this practice. Another good guideline is to allow 15 days of observation for characterizing the first system, 12 days for the second system, 9 days for the third system, and 7 days for the fourth and all subsequent systems. (These numbers are the "rule of thumb" judgment of administrators in CERT who have done this type of work.)
It may take one year or more for an administrator to observe the network traffic traversing a large network and to develop a characterization baseline representing normal traffic behavior. Once an administrator understands how to develop a characterization baseline, however, developing subsequent baselines should proceed more quickly.