Actions required when upgrading

This section describes changes in Airlock Gateway 8.2 that may require manual actions. Read this section carefully to see whether your configuration is affected.

After installing Airlock Gateway 8.2, you cannot uninstall it to revert to Airlock Gateway 8.1. This is due to limitations of the underlying operating system. For more information about upgrade/update limitations, see Release notes.

• Suggestions:
• Create Snapshots, if Airlock Gateway is operated as a virtual machine.
• Use system backup and restore.
• Export the current configuration.
• Ensure the installation media of the old release is available.

In Airlock Gateway 8.2, the new client behavior model (CBA) has been added. This anomaly detection model can determine if the end-user is human or not.

• Automatic upgrade actions:
• Updating from Airlock Gateway 8.1 will add new columns to the database schema for the CBA model.
• Existing trained models will be removed because the new version of Anomaly Shield provides improvements on model calculation and is incompatible with the old models.

0. After the upgrade, the following approach for migration from 8.1 to 8.2 is suggested:
1. Re-train the models as described in the article Training and model enforcement.
2. After training, the prepared model will have an incomplete status, which is expected since ColdDB lacks training data for the new CBA model. Nevertheless, you can use all other models for anomaly detection while collecting new training data that include CBA values.
3. Enforce the incomplete model to secure your Anomaly Shield application as before the upgrade.
4. Enable training data collection for your Anomaly Shield application to collect traffic, including CBA values. It is recommended to keep training data collection enabled at all times so that automatic retraining can be used.
5. Wait for at least 35 days and until you have collected sufficient realistic production data in the ColdDB (see suggestions in article Enable training data collection).
6. Re-train your models and proceed with the follow-up configuration tasks.

• Suggested follow-up configuration tasks:
• Rules offer new IP Aggregation action features that should be enabled to identify and block suspicious IP addresses.
• Existing trigger patterns should be reconfigured using the new Query Parameters feature or replaced with the new default triggers and rules.
• Enable automatic retraining and enforcement of models. This will retrain all models every 3 months without manual intervention. See Part 2 – Training and model enforcement for more information about model training.

The best practice configuration for rules and trigger configuration can be found here.