Performing intrusion analysis

Once you know someone has gotten inside your security perimeter, you have to be able to understand how that person did it, and what happened after that. This calls for analysis of intrusion, and this tip, excerpted from the InformIT Web site, discusses how you would go about analyzing intrusion-detector reports.

The second of the three phases in the [intrusion] analyzer is the operational analysis of a live event stream. In this phase, the analyzer is applied to live data to spot intrusions and other activity of interest.

• Input new event record: The first step of performing analysis is taking an event record as generated by one of the information sources. Such information sources might be network packet traces, operating system audit trails, or application log files, and it is assumed that they have not been compromised.
• Preprocessing: As in the construction of the analyzer, some preprocessing of the event data may be performed. The exact nature of this preprocessing depends on the nature of the analysis. Examples include threading together various TCP messages into a higher-level abstraction (a "session") and structuring process identifiers from operating system audit trails into high-integrity process trees.
  • Misuse detection: For misuse detectors, the event data is usually converted to some canonical form. This form corresponds to the structure of the attack signatures. In some approaches, the event data is aggregated (collected to make up some minimum interval of interest, such as a user session, a network connection, or other high-level event). In other approaches, the data is reduced by combining some attributes, eliminating others entirely, and performing calculations on others to create new, more compact data records.
  • Anomaly detection: In anomaly detection, the event data is usually reduced to a profile vector with behavior attributes expressed as scores and flags.
• Compare the event record to the knowledge base: The formatted event record is compared to the contents of the knowledge base. The next step of the process depends on the results of this comparison and on the analysis scheme in question. If the record indicates an intrusion, it may be logged. If the record does not indicate an intrusion, the analyzer simply accepts the next event record and repeats the formatting and comparison.
  • Misuse detection: In the misuse detector, the preprocessed event record is submitted to a pattern-matching engine. If the pattern matcher finds a match between an attack signature and the event data, it returns an alert. In some misuse detectors, if a partial match is found (if a pattern indicating a possible preamble to attack is matched), that fact may be recorded or the record cached in memory, awaiting further event information that can be appended to it to make a more definitive decision. Detection engines that can "remember" sequences of events are called stateful detectors.
  • Anomaly detection: In anomaly detection, the contents of the user behavior profile for the session are compared to the historical profile for that user. Depending on the analysis scheme, a judgment is made as to whether the user behavior is close enough to the historical profile to be considered "normal" and therefore not indicative of attack. If the user behavior is determined to be abnormal, an alert is returned. Many anomaly detection-based intrusion detection engines also perform misuse-detection in parallel with this process, so some cross-pollination may occur between these different analysis schemes.
• Generate a response: If the event record corresponds to an intrusion or other behavior of interest, a response is returned. Again, the nature of the response depends on the specific nature of the analysis approach. The response can be an alarm, a log entry, an automated response, or some other action specified by the operator of the intrusion detection system.

To read more of this excerpt, click over to the InformIT Web site. Registration is required, but it's free.