Airlock Anomaly Shield

Starting with release 7.6, Airlock Gateway includes Airlock Anomaly Shield, an unsupervised machine learning-based anomaly detection mechanism. Airlock Anomaly Shield can be licensed to detect anomalies in the web traffic of the applications protected by Airlock Gateway.

To detect anomalies, the Airlock Anomaly Shield must be configured and initially baseline-trained for each application separately. After training, the Anomaly Shield analyzes request traffic patterns of web sessions and generates anomaly information continuously as new requests arrive. The Anomaly Shield enforcement logic uses configured patterns against the anomaly information to determine the appropriate actions for each session.

Airlock Anomaly Shield operates on the behavior of a web session and complements conventional security features of the Security Gate core service that acts directly on the properties of every single request.

Airlock Anomaly Shield is based on unsupervised machine learning (ML) models. This has the advantage that no data labeling is required.

• However, initial ML training is required:
• To train the ML models for a new application, Airlock Gateway can be configured to collect traffic as training data during its normal operation. This cold data collection is used to establish the baseline training for the ML models.
• After training Airlock Anomaly Shield may be used to evaluate and detect anomalous traffic and take action upon it.

Airlock Anomaly Shield requires analyzing multiple requests of a web session, not just the properties of a single request. The evaluation of multiple requests is used to obtain anomaly indicator values. Anomaly detection can be further improved if back-end application responses are also processed.

During detection, there is a short delay between the start of the web session and the availability of anomaly indicator values by design. The reason for the delay is that anomalous behavior can only be detected once a sufficient number of requests have been processed. Keep in mind that the focus of anomaly evaluation is on the web session as a whole, so the detection time shift has little impact in practice.

Running anomaly evaluation and request processing asynchronously ensures that the security gate process does not have to wait for anomaly evaluation values. The security gate process will perform at peak efficiency even under very high loads.

Anomaly detection may require a lot of system resources and force the Airlock Anomaly Shield to continue processing the evaluation results while new requests arrive. The request data from such requests are automatically included in the next evaluation run.

The Airlock Anomaly Shield feature needs to be trained and configured for each application. An application definition can be used for multiple mappings, but a mapping can only be linked to a single application definition.

• Submenu – Anomaly Shield
• Airlock Anomaly Shield configuration