Follow

Deep HTTP Inspection for Cloud Defender | Feature Education

In This Article

Overview

Alert Logic® Cloud Defender™ includes deep HTTP inspection, an out-of-band HTTP inspection capability that provides advanced detection without the risk of affecting business applications or causing latency.

With this detection capability, Alert Logic provides real-time detection accuracy for attacks on unique flaws in off-the-shelf and custom web applications such as those outlined in the OWASP Top 10. To provide confidence in detected threats, both HTTP requests and responses are inspected, with support for HTTP response signatures and HTTP response anomaly detection. By layering deep HTTP inspection as part of the Cloud Defender service, this capability provides minimal noise and actionable context in detecting layer-7 attacks.

In this article, you can learn more about how deep HTTP inspection works and what it provides.

Back to top

When HTTP Responses Are Inspected

With deep HTTP inspection, HTTP requests are inspected to identify when attackers are attempting to compromise a web application. "Violations" are created if:

  • Any characteristics of a request violate historically normal ranges for that appliance (anomaly detection)
  • A request matches any known patterns of malicious activity (signatures)
  • A request parameter does not contain a valid value (positive rules)

If suspicious activity is detected in an HTTP request and a violation is created, the HTTP response capability is triggered to help determine whether the attempt was successful. By analyzing the request and response violations together, we can better distinguish which events indicate a high probability of a compromise, allowing for efficient analysis and response.

Back to top

How Anomaly Detection Works

Anomaly detection is used within Cloud Defender to analyze certain characteristics of HTTP responses to see if any fall far outside (typically 3 standard deviations or the 99.99% percentile) the normal range of transactions that Cloud Defender has learned for that application.

The following table lists examples of potentially anomalous activity for the HTTP response characteristics that are analyzed.

HTTP Response Characteristic What We're Watching Possible Anomalies
Headers size Average size of the headers Changes could indicate that a different web application sent the response. 
Body size Average size of the server response Changes could indicate something entirely different was served or included in the response.
Response time Two variables: Backend server response time and total response time Changes could indicate that unusual application logic was invoked, or that the application was deliberately instructed to hold back the response as in the case of a time-based SQLi attack.
Text ratio The ratio of text to code in server responses - reflects usage of standards, templates, and guidelines in the web application pages Changes could indicate that non-formatted content that was not intended to be displayed in the web application was served.
Max text The longest chunk of text uninterrupted by HTML tags or other code in the server response Changes could indicate that SQL data is being exfiltrated as text.

Layering anomaly detection with the deep HTTP inspection techniques for Cloud Defender avoids the pitfalls of using anomaly detection as a standalone technique, which can yield unexpected results when behavior is unusual but not malicious. Cloud Defender creates a detection use case that combines a specific behavior that is considered suspicious with validation that there is also anomalous behavior.

Back to top

When Malicious Behavior Is Detected

When Cloud Defender detects malicious activity that is confirmed by inspecting HTTP responses, violations (i.e. “events”) are created and sent to Alert Logic. These events contain fields that identify details about the activity, such as the level of exposure or the degree of how abnormal the response was.

Alert Logic ActiveIntelligence™ then uses these fields to create incidents. Incidents are created with one of the sources as the primary source of an incident, while findings from another source are combined into the incident if they are coming from the same attacker source.

For more information about how Alert Logic classifies events and incidents, as well as where to view them in the Alert Logic user interface, refer to our Incidents documentation.

Back to top

Additional Resources

For information about installing the out-of-band web application firewall and related user guides, refer to Alert Logic Docs

Back to top

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.