NAV
shell

Exein Overview

Exein is a host-based, run-time anomaly detection agent for Linux-based embedded systems.

Exein's goal is to protect the target system from undesirable behavior, introducing the self-protecting and remote-monitoring set of tools into the embedded systems arena. In order to achieve this, the solution needs to extract and analyze the system’s behavior by enumerating its events. This is carried out in three steps (or main functions):

Derived from this functional division, Exein has three main components: a Linux Security Module (LSM Exein), a Linux Kernel Module (Exein interface) and a Machine Learning Engine (MLE Player).

As can be seen in Figure 1, each executable that’s meant to be tracked by Exein is labeled with a unique tag. These tags are added to the executables during the firmware build by inserting a new section within the ELF header containing the unique value.

Each tag will then be used by the Exein kernel modules to keep record of which ML Model is responsible for tracking each group of processes (parent and child processes spawned or forked by the first tagged binary).

image

One machine-learning model is created and subsequently used to track each individual tag. As the tagged processes issue system calls to the Linux Kernel, Exein extracts rich features from kernel hooks and sends them to the machine learning models in order to identify anomalous behavior and — if a certain threshold is passed — block the process actions.

The Exein Machine Learning Engine (MLE)

The MLE is a user-space process responsible for deciding whether the behavior of a device is to be considered normal or, instead, if the device appears to be under attack.

image

In order to accomplish this task, the Exein MLE employs a deep Convolutional Neural Network that studies the behavior of the device processes at kernel level during the training phase, which consists in learning the expected behavior of a variable using a “clean”, normal dataset in a semi supervised fashion.

Once the training phase is completed, the model trained on the clean dataset can be used as a tool for detecting anomalies in new data that has not been labeled a-priori (i.e. it might or might not contain anomalies) by predicting the future evolution of the device behavior and comparing the model predictions with the actual observations. If these match, then the device is operating under the learned normal behavior; if, otherwise, the new observations diverge significantly from the model’s predictions, then a change of behavior has occurred and the new behavior can be identified as anomalous with respect to the learned one, i.e. the one that is considered to be normal.

We refer to the discrepancy between the machine learning models’ predictions for a process and its actual observations as the process “anomaly score”. During real time execution, the Exein MLE Player keeps track of the anomaly score of each monitored process.

As shown in Figure 2, when the anomaly score for a given process exceeds a certain threshold, the process is considered to be malicious, and the LSM is informed about it so that it can respond accordingly.

The Exein Linux Security Module (LSM)

This module of the Exein Core interacts in a direct way with the Linux Kernel. It receives hook calls from the processes being tracked as they issue system calls to the kernel and extracts relevant data given the context of every received hook.

The contextual data available on each case depends on the type of hook being executed but it can range from file descriptors, names and paths, inode attributes, details of memory regions, capabilities and processes attributes to users, groups and effective permissions being used when accessing a resource.

After being extracted, the data is delivered to the MLE through an interface with the third main component: The Exein Linux Kernel Module (or LKM). There are hundreds of different security hooks that are provided by the Linux Kernel and could be tracked by the Exein LSM implementation.

As the amount, type, and signature of the hooks vary between kernel versions we developed tools to keep track of these changes and automate the configuration of the LSM build for several kernel versions.

In case the MLE detects a process trying to do something unexpected, the LSM will receive a message with this information and will enforce a policy over the process, thus eliminating the threat.

The Exein Linux Kernel Module (LKM)

This module plays the role of interfacing between the LSM and the MLE, which are running at different execution levels (kernel and user space respectively). It provides a communication channel carried over netlink protocol and provides some debug functionalities as well.

Live Mode Snapshot Mode
image image

It supports two modes of operation, the first, named “live” is meant to be used on high-end devices and to collect data for training a new ML model. Its main feature is to export in a “live” way all the data produced by a target process. The second mode of operation is named “snapshot”, and it is the default mode of operation, meant to run on the low-end devices. It minimizes Kernel - user-space communications by exporting only the data that can be actually analyzed, keeping the current image of each monitored process within the kernel address space.

Next Steps

If you want to find out more about Exein's technology, a great follow up is reading our public white paper or checking out or official blog on Medium.

Get started using Exein by signing up for free and downloading our CLI.

Get Started

The Exein CLI is a simple tool that helps you to secure your IoT device using Exein cutting-edge technology. Exein CLI has been designed to ease secure firmware development. This tutorial guides you step-by-step to perform the operations required to build and install a secured firmware using Exein CLI. In order to secure your device the following steps are necessary:

  1. Prerequisites
  2. Create an Exein Project
  3. Create an Audit Build
  4. Collect data
  5. Train the MLE
  6. Create a Release Build
  7. Secure your process

Prerequisites

./exein-installer-current.run

Make sure you have downloaded and installed the Exein CLI. If you haven’t done so already, please download the CLI at https://beta.exein.io/static/exein-installer-current.run and install it by running in your terminal:

Make sure you have also registered an account with Exein. If you haven’t done so already, please visit https://hub.exein.io/signup to register your account.

Make sure you have cmake 3.16 or later installed in your working environment.

Before proceeding with the installation of Exein inside your firmware, please note the latest version of Exein only supports the Linux Kernel Versions:

and the following architectures:

Support for more kernel versions and architectures is coming soon.

Please also note that the latest version of Exein only supports the following build systems:

Only glibc is supported.

Step 1: Create an Exein Project

exein init --name "my-first-project" --type "buildroot"

In order to initialize an Exein project, navigate to the main directory where your firmware build resides and run:

The exein init command will first ask you to authenticate to Exein using your registered credentials. You have to specify the name of your ptoject and the type of buid system choosing between buildroot, openwrt and yocto.

If authentication is successful, a file named “.exein” will be created in the firmware project directory. This file stores your Exein CLI project configurations.

Step 2: Install Exein in Audit mode

After having successfully initialized an Exein project in your firmware main directory, the next step is to install Exein in audit mode in your firmware source by running the exein install CLI command.

Exein secures the device through the Exein Machine Learning Engine (MLE). In order to detect suspicious activities, the MLE needs to first learn the regular firmware behaviour: the audit mode consists of the original firmware build with the addition of the Exein components that are responsible for collecting the data needed to train the MLE.

Exein monitored processes need to be tagged with a section in the ELF executable file. The TAG is a user-defined 16-bits integer.

exein install --tags mypackage=13107

In this example mypackage will be tagged using TAG number 13107.

If the command terminate successfully, you now have Exein installed in your firmware source and ready to build.

Step 3: Collect data

The next step is to build your firmware, flash it on your target device -or on a virtual machine, depending on your need - and collect the behavioral data required to train the MLE security model for your firmware.

Exein needs to collect data about the regular firmware behaviour to train the MLE. During this phase, you should test all the functionalities you expect to be used in your target application so that the MLE will be able to recognize them in the future and not flag them as anomalies.

The main goal of this step is to have Exein automatically produce a dataset file containing all the process regular behavior that has been observed and recorded during the firmware test operations. This file will be used to train the Machine Learning Engine security model for your firmware and to create the final release build.

To start data collection of a tagged running process:

exein receive --port PORT --tag TAG
echo 1 > /proc/exein/mode_ctl
training-forwarder IP PORT TAG SECURE_SEED PKT_SIZE

During this phase, it is extremely important to test all the functionalities you expect to be used in your target application when deployed. This will allow Exein to create a strong model of your target expected behavior and effectively detect anomalous deviations from it. Once you have completed the firmware tests, stop the receiver using CTRL-C.

Example

echo 1 > /proc/exein/mode_ctl
training-forwarder 192.168.1.10 13107 13107 35465436 1350

To forward the training data of the process with TAG: 13107 to the server listening at UDP:192.168.1.10:13107 with the kernel SECURE_SEED 35465436, do the following (use 1350 as default packet size):

dmesg |grep "ExeinLSM - lsm is active"
[0.001962] ExeinLSM - lsm is active: seed [1841749789]

Root users can retrieve the kernel SECURE_SEED using the following command:

On the CLI, run exein receive and check the number of received hooks. Test all the functionalities of the tagged executable (e.g. web-page serving) and stop the receiver when all the tests are completed. For robust results, the number of received hooks should be at least 15K.

Step 4: Train the MLE

After having collected the training data for the MLE, the next step is to actually train the MLE using this data.

exein train --file "path/to/training-data"

To train the MLE model run:

In the background, Exein servers will start a training job with your data to produce a custom MLE model for your firmware.

The CLI returns a positive output and ends the program as soon as the training request has been taken over by Exein servers.

exein status

At this point, you can check the model training status using the command:

This command shows inside a table the status for all the MLE models associated to the Exein project you are working on. Each model is identified by a unique model ID. Last trained models in order of time are shown at the end of the table. An estimated time of completion is calculated. Also the status and the model score are reported as soon as they are available.

Step 5: Install the MLE for Release mode

exein install_model --id "unique_model_id"

After having ensured that your model has been correctly trained - with its status is marked as COMPLETED and a positive score - launch the exein install_model command and specify which MLE model to use to create the final release build.

This command downloads the model and place it in your firmware source in a new package specific to your build system.

Now you have to enable the model in your configuration:

You can now build your firmware.

Step 6: Secure your process

mle-player SECURE_SEED MODEL_CONFIG_PATH TF-LITE_MODEL_PATH

Finally, to secure your process using the MLE-Player, flash the release build on your target device and run the mle-player command providing the .ini configuration file and the trained .tflite MLE model. By default, the config file and the MLE model are stored in /etc/exein/.

Example

mle-player 1841749789 ARMEL-F-414162-config-13107.ini ARMEL-F-414162-model-13107.tflite &>/dev/null &
dmesg |grep "ExeinLSM - lsm is active"
[0.001962] ExeinLSM - lsm is active: seed [1841749789]

where the first argument is the kernel SECURE_SEED, the second argument is the path of the model config file, and the third argument is the .tflite model. Root users can retrieve the kernel SECURE_SEED using the following command:

At this point, Exein is active and monitoring the behavior of your target process: as soon as anomalies are detected, the MLE-Player reacts and takes action against the anomalous processes, securing your device from potential threats.

CLI Reference

exein [command] [arguments]

Commands on Exein CLI are issued in the following way:

exein init

Description

Initialize a new Exein project.

Usage

exein init --name NAME --type TYPE [--description DESCRIPTION]

Arguments

Argument Description
type build system used for the project (only Buildroot is supported as of the 0.01 release, with Yocto and OpenWRT in the pipeline for the 0.02 release)
name project name specified by the user
description (optional) a short description of the project

Extended Description

exein init is the first command used when a new Exein project is initialized. A login prompt shows up if the user is not logged in with username and password. A file named “.exein” is then created in the firmware project directory. This file stores the Exein CLI project configurations.

Example

$ exein init --name exein-ip-cam --type buildroot 



                       .__
    ____ ___  ___ ____ |__| ____
  _/ __ \\  \/  // __ \|  |/    \
  \  ___/ >    <\  ___/|  |   |  \
   \___  >__/\_ \\___  >__|___|  /
       \/      \/    \/        \/  Installer v0.4



Email: johndoe@exein.io
Password:
[2021-01-13T09:34:45Z INFO ] Logged in as: Jonh Doe
[2021-01-13T09:34:47Z INFO ] Exein repository initialized

This example initializes a new Exein project named “exein-ip-cam” with buildroot as target build system inside the current working directory.

exein install

Description

Install Exein components in the firmware source.

Usage

exein install --tags TAGS

Arguments

Argument Description
tags list of space separated PACKAGE=TAG directives, where PACKAGE is the name of the package to tag and TAG is a user-defined 16-bits

Extended Description

When exein install is launched by the user, the Exein CLI first checks that the current directory contains an “.exein” project. Then it adds Exein (kernel patch and MLE software) to the project.

Example

$ exein install --tags uhttpd=3333

            .__
    ____ ___  ___ ____ |__| ____
  _/ __ \\  \/  // __ \|  |/    \
  \  ___/ >    <\  ___/|  |   |  \
   \___  >__/\_ \\___  >__|___|  /
       \/      \/    \/        \/  Installer v0.4



[2021-01-13T09:35:02Z INFO ] Logged in as: Jonh Doe
[2021-01-13T09:35:02Z INFO ] Installation started
[2021-01-13T09:35:02Z INFO ] Cloning exein buildtools...
[2021-01-13T09:35:22Z INFO ] Installation completed

This example installs exein components in the firmware sources in auditing mode and adds the tag for uhttpd package.

exein receive

Description

Receives data from tagged executable processes. Data are sent by running training-forwarder on the device. This command creates the dataset file required to train the MLE.

Usage

exein receive --port PORT --tag TAG

Arguments

Argument Description
port port used by training-forwarder to send data
tag tag number used to tag the target executable

Extended Description

The command exein receive starts a UDP server listening on the specified port to receive data from a tagged executable process . Data are sent by running training-forwarder on the device using the same port. This command creates the dataset file required to train the MLE. Use the same tag number that have been assigned to the target process during the tagging operation and the same port used by the command training-forwarder. During this phase, it is recommended to test all the functionalities you expect to be used in your target application. Once you have completed the tests, stop the receiver using CTRL-C.

Example

$ exein receive --port 13107 --tag 13107

                       .__
    ____ ___  ___ ____ |__| ____
  _/ __ \\  \/  // __ \|  |/    \
  \  ___/ >    <\  ___/|  |   |  \
   \___  >__/\_ \\___  >__|___|  /
       \/      \/    \/        \/  Installer v0.4



[2021-01-13T09:55:21Z INFO ] Logged in as: Jonh Doe
[2021-01-13T09:55:21Z INFO ] Receiving...

This example shows how to receive data on port 13107 for the tagged process 13017.

$ echo 1 > /proc/exein/mode_ctl
$ ./training-forwarder 192.168.1.10 13107 13107 35465436 1350

On the device, to forward the training data of the target process tagged with 13107 to the server listening to UDP:192.168.1.10:13107 using kernel seed 35465436 run the following command (use 1350 as default packet size):

$ dmesg |grep "ExeinLSM - lsm is active"
[0.001962] ExeinLSM - lsm is active: seed [1841749789]

Root users can retrieve the kernel seed using the following command:

exein download_model

Description

Download previously trained model.

Usage

exein download_model --id ID

Arguments

Argument Description
id unique ID of an Exein MLE model

Extended Description

When exein download_model is launched by the user, the Exein CLI checks that there is an active “.exein” project in the current directory. It then checks that the MLE model specified in “id” is in the COMPLETED state, then downloads it in the current folder.

Example

exein download_model --id 8b8bd444-6da1-4406-9781-4f4d58347d13



                       .__
    ____ ___  ___ ____ |__| ____
  _/ __ \\  \/  // __ \|  |/    \
  \  ___/ >    <\  ___/|  |   |  \
   \___  >__/\_ \\___  >__|___|  /
       \/      \/    \/        \/  Installer v0.4



[2021-01-13T09:52:33Z INFO ] Logged in as: Jonh Doe
[2021-01-13T09:52:33Z INFO ] Model successfully downloaded. File saved to /home/jdoe/bestfirmware/8b8bd444-6da1-4406-9781-4f4d58347d13.zip

This example downloads the model with unique ID: "8b8bd444-6da1-4406-9781-4f4d58347d13".

exein install_model

Description

Install previously trained model in the firmware source.

Usage

exein install_model --id ID

Arguments

Argument Description
id unique ID of an Exein MLE model

Extended Description

When exein install_model is launched by the user, the Exein CLI checks that there is an active “.exein” project in the current directory. It then checks that the MLE model specified in “id” is in the COMPLETED state, then downloads it and place it in a new package named mle-player-model.

Example

exein install_model --id 8b8bd444-6da1-4406-9781-4f4d58347d13



                       .__
    ____ ___  ___ ____ |__| ____
  _/ __ \\  \/  // __ \|  |/    \
  \  ___/ >    <\  ___/|  |   |  \
   \___  >__/\_ \\___  >__|___|  /
       \/      \/    \/        \/  Installer v0.4



[2021-01-13T09:52:33Z INFO ] Logged in as: Jonh Doe
[2021-01-13T09:52:33Z INFO ] Model installation started
[2021-01-13T09:52:33Z INFO ] Model installation completed

This example installs the model with unique ID: "8b8bd444-6da1-4406-9781-4f4d58347d13".

exein train

Description

Train an Exein MLE model.

Usage

exein train --file FILE

Arguments

Argument Description
file path to the training data file

Extended Description

When exein train is launched by the user, the Exein CLI checks that there is an active “.exein” project in the current directory. It then sends the training data file to Exein’s server along with a reference to the firmware.

Example

$ exein train --file training-dataset.csv.zip



                       .__
    ____ ___  ___ ____ |__| ____
  _/ __ \\  \/  // __ \|  |/    \
  \  ___/ >    <\  ___/|  |   |  \
   \___  >__/\_ \\___  >__|___|  /
       \/      \/    \/        \/  Installer v0.4



[2021-01-13T09:37:17Z INFO ] Logged in as: Jonh Doe
[2021-01-13T09:37:22Z INFO ] Training data uploaded successfull. Model id: 8b8bd444-6da1-4406-9781-4f4d58347d13

This example trains a security model using the training dataset found at "training-dataset.csv.zip".

exein status

Description

Check the status of the current Exein project model training.

Usage

exein status

Arguments

This command takes no argument.

Extended Description

When exein status is launched by the user, the Exein CLI checks that there is an active “.exein” project in the current directory. It then makes a request to the backend to know the current status of the Exein MLE models associated to that project.

Example

$ exein status



                       .__
    ____ ___  ___ ____ |__| ____
  _/ __ \\  \/  // __ \|  |/    \
  \  ___/ >    <\  ___/|  |   |  \
   \___  >__/\_ \\___  >__|___|  /
       \/      \/    \/        \/  Installer v0.4



[2021-01-13T09:38:55Z INFO ] Logged in as: Jonh Doe
+--------------------------------------+----------+--------------------------------+
| MODEL ID                             | STATUS   | CREATION DATE                  |
+--------------------------------------+----------+--------------------------------+
| 8b8bd444-6da1-4406-9781-4f4d58347d13 | TRAINING | 2021-01-13 09:38:15.505573 UTC |

This example retrieves all the active security models inside the current Exein project. An estimated time of completion is calculated. Also the status and the model score are reported as soon as they are available.

Note: model score is a statistical indicator of the trained model performances. Model score is calculated by evaluating the model against synthetic ad-hoc attacks that are spuriously injected into benign data. The score takes values in [0,1). A high-score (e.g. > 0.7) means that the model detects as anomaly even the slightest deviation from the device's normal behaviour. Model scores below 0.4 suggest to re-train the model using more robust data.

exein logout

Description

Logout of the Exein CLI during an active session.

Usage

exein logout

Arguments

This command takes no argument.

Extended Description

The command exein logout terminates the current active session, if any, logging the user out of the Exein API. When the user issues any new command after having logged out, they will be asked to login using their credentials.

Example

$ exein logout



                       .__
    ____ ___  ___ ____ |__| ____
  _/ __ \\  \/  // __ \|  |/    \
  \  ___/ >    <\  ___/|  |   |  \
   \___  >__/\_ \\___  >__|___|  /
       \/      \/    \/        \/  Installer v0.4



[2021-01-13T09:55:21Z INFO ] Logout successfully

This example simply logs you out of Exein CLI. The next time you run any Exein command, you will be asked to log in again.