You are here

Software behavior models for the detection of anomalies

The work that has been done so far in the Thread Adaptive fault identification of the project has produced a new specification language (herein called SpecLang) allowing the signature-based detection of software behaviors (herein called scenarios; which can be both atomic or abstracted) within execution traces. SpecLang provides all the facilities for defining highly complex signatures on the basis of trace events.
A number of modifications could be made to SpecLang to allow the identification of anomalies within executions traces. An anomaly is defined as the non-finding and/or the addition of (in execution traces) pre-defined scenarios or sub-scenarios or atomic elements in an expected/observed scenario. Examples are:

  1. one scenario was not detected in an execution trace;
  2. one sub-scenario (not defined in the expected scenario) was detected, and other pre-defined sub-scenarios were correctly detected as expected;
  3. one atomic element of a scenario was not detected but other elements were detected.

The work that is being proposed in this thread consists in adapting SpecLang for the detection of
anomalies (for all levels of granularity as shown in the three examples above).
Tasks:

  1. Develop a new technique allowing the generation of behavior models on the basis of the source codes. Static analysis of the source code will be utilized to produce behavior models of the studied software. This task addresses all kinds of software that is running in the user space of the Linux kernel (application software, libraries, daemons, etc.) The work that will be done in this task should be easily adaptable for the Linux kernel (to be done in another project). Generated models should be well aligned with the results of a preliminary study Knowledge base model for the Linux Kernel State of the art and feasibility study that was conducted by Mathieu Desnoyers, PhD in 2011 for DRDC Valcartier.
  2. Adapt and enrich the syntax of SpecLang. It should be possible to express software behaviors models (as well as unknown parts/scenarios) with SpecLang. SpecLang should also be able to express the software behavior patterns that were defined in the Thread Adaptive fault identification of the project (all defined behavioral patterns will be made available).
  3. If necessary, adapt the detection engine. The detection engine should be able to detect and identify, based on expected behavior models, anomalies in execution traces.
  4. Redaction of a report describing lessons learned and obtained results (including recommendations).