Dynamic Kernel Tracing for Intrusion Detection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Host-based intrusion detection systems are limited in practice due to the lack of facilities to instrument production code in ways that are both descriptive of detailed program behavior and of sufficiently low overhead to support real-time intrusion detection in interactive systems, limiting possible intrusion signatures and program behavior baselines.

Innovation Solution

Dynamic kernel/user-level tracing is employed to efficiently characterize runtime behavior of production code, allowing instrumentation of user space or kernel instruction sequences without access to source code, using dynamic tracing techniques like DTRACE to facilitate signature-oriented and anomaly-oriented intrusion detection strategies.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If host-based intrusion detection systems use detailed program behavior observation, then detection precision is improved, but system overhead increases making real-time detection infeasible

Engineering Contradiction:
Improvedetection precisionVSAvoidsystem overhead
Core Design Contradiction:
Measurement precisionVSUse of energy by moving object

Solution Approach 1:

The system segments program behavior observation into two distinct layers: a baseline recording phase that captures detailed program execution traces without intervention, and a detection phase that compares suspicious activity against the pre-recorded baseline. This segmentation allows detailed observation to occur offline, eliminating the overhead burden during real-time detection operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary action by recording and storing baseline program behavior characteristics before intrusion detection is needed. These baselines capture detailed execution patterns, system calls, and program flow information that would be expensive to gather in real-time. During actual detection, the system only needs to compare current activity against these pre-computed baselines, achieving high precision with minimal overhead.

Inventive Principle:
Principle #10Preliminary action

2Measurement precision

If signature-oriented detection strategies are used, then known threats are precisely detected, but new emerging threats cannot be detected

Engineering Contradiction:
Improvethreat detection accuracyVSAvoiddetection coverage
Core Design Contradiction:
Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The system implements feedback by continuously comparing actual program behavior against recorded baselines and using statistical analysis to identify deviations. This feedback mechanism enables the system to adapt to new threats by recognizing anomalous patterns that differ from established baseline behavior, even when no specific signature exists for the new threat. The feedback loop allows the system to learn and adjust to emerging attack vectors.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system changes parameters by transitioning from static signature matching to dynamic baseline comparison. Instead of relying on fixed threat signatures, the system records baseline behavior parameters under normal conditions and then monitors for parameter deviations that indicate potential intrusions. This parameter-based approach enables detection of both known threats (through pattern recognition) and new threats (through anomaly detection).

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If anomaly-oriented detection strategies are used, then emerging threats can be detected, but false positives increase when legitimate activity changes

Engineering Contradiction:
Improvethreat detection coverageVSAvoidfalse positive rate
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system performs preliminary action by recording baseline program behavior under known legitimate conditions before deployment. These baselines serve as reference models that capture the normal execution patterns, system call sequences, and program flow characteristics of legitimate applications. By having these pre-established baselines, the system can reliably distinguish between legitimate activity variations and actual anomalies, reducing false positives while maintaining detection of emerging threats.

Inventive Principle:
Principle #10Preliminary action

4Productivity

If rudimentary tracing mechanisms are used, then overhead is reduced for real-time detection, but characterization of system behavior is limited

Engineering Contradiction:
Improvereal-time detection capabilityVSAvoidbehavior characterization detail
Core Design Contradiction:
ProductivityVSLoss of information

Solution Approach 1:

The system segments information gathering into two phases: comprehensive baseline recording that captures detailed program behavior information without real-time performance constraints, and streamlined real-time detection that uses pre-processed baseline data. This segmentation allows the system to maintain detailed behavior characterization in the baseline while using lightweight comparison operations during actual detection, achieving both detailed characterization and real-time performance.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS8028336B2Intrusion detection using dynamic tracing
Publication Date: 2011.09.27 ORACLE AMERICAN INC
  • US8028336B2 patent drawing
  • US8028336B2 patent drawing
  • US8028336B2 patent drawing

AI summary

Techniques have been developed whereby dynamic kernel/user-level tracing may be employed to efficiently characterize runtime behavior of production code. Using dynamic tracing techniques, user space or kernel instruction sequences between system calls may be instrumented without access to source code. In some realizations, instrumentation may be interactively specified on a host system. In some realizations, instrumentation specifications may be supplied as functional definitions (e.g., as scripts and/or probe definitions) for installation on a host system. Using the developed techniques, data states, parameters passed and/or timing information may be sampled to provide more detailed insight into actual program behavior. In signature-oriented exploitations, more powerful intrusion signatures are possible. In anomaly-oriented exploitations, a more detailed “sense of self” may be developed to discriminate between normal and anomalous program behavior.