Web Application Firewall (WAF)

Monitor, detect, and prevent application layer attacks through our Web Application Firewall (WAF). Our WAF inspects inbound HTTP/HTTPS traffic against reactive and proactive security policies and blocks malicious activity in-band and on a real-time basis.

Key information:

WAF requires an Edgio organization. It cannot be applied to a private space.
Set up WAF at the organization level. This allows you to apply general security policies across all of your organization’s properties. You may also define granular security policies that only apply to specific requests.
Our service includes a basic offering called Security Insights. However, we also offer more comprehensive security soutions. Contact your account manager or our sales department at 1 (866) 200 - 5463 to upgrade your account.

Use our WAF to:

Enable a comprehensive set of threat detection measures for the purpose of identifying malicious traffic. These measures define the types of application layer attacks that will be detected, such as:
- Protocol validation
- Malicious client identification
- Generic attack signatures
- Known vulnerabilities signatures
- Trojan/backdoor access
- Denial of Service
Restrict the flow of site traffic with the intention of:
- Diverting malicious or inadvertent DDoS traffic.
- Preventing a customer origin server from being overloaded.
Filter out unwanted traffic by screening for a custom delivery profile.

Traffic that doesn’t meet the requirements defined in this delivery profile may be blocked before it even reaches our core network.
Establish traffic restrictions to block malicious traffic.

Use a whitelist, blacklist, or accesslist to restrict traffic by ASN, country, IP address, referrer, URL, user agent, HTTP method, media type, and file extension.
Filter out traffic generated by basic bots to prevent them from scraping your site, carding, spamming your forms, launching DDoS attacks, and committing ad fraud.
Validate payloads for API requests.

Basic Setup

Secure your web applications by defining security rules and then creating a Security App configuration that enforces them. After which, perform near-real-time threat monitoring through the dashboard.

Additional information on each of the above steps is provided below.

Step 1 - Create Security Rules: Create modular rules (i.e., Access Rules, API Security Rules, Rate Rules, Bot Rules, Custom Rules, and Managed Rules) through which you may define security policies for inbound HTTP/HTTPS traffic. These rules identify legitimate traffic or threats through:
- Access controls (e.g., IP address, country, URL, etc.).
- API schemas.
- Rate limits.
- Bot detection
- Custom threat detection rules.
- Threat detection policies.
Step 2 - Create a Security App Configuration: Create a Security App Configuration that identifies the type of traffic for which:
- New security rules will be tested. This is known as Audit mode.
- Security rules will be enforced. This is known as Production mode.
Step 3 - Monitor Threats: Use the dashboard to:
- Visualize threat frequency and timing.
- Analyze threats and ensure that legitimate traffic is not impacted.

Different applications and types of requests may require varying levels of protection. Create security rules and Security App configurations for each use case that requires a unique level of protection.

Audit Security Rules

Apply a security rule within a Security App configuration in one of the following modes:

Audit: Test new security configurations by screening traffic in Audit mode.
Production: Use this mode to enforce your security policy.

Screening traffic in Audit mode generates an alert when a request violates a security rule. If an alert is triggered, Edgio will immediately stop checking your Audit configuration and start screening your Production configuration. For example, if a request triggers an access rule, then Edgio will skip Audit configurations for API Security, Custom Rules, or Managed Rules and proceed to screen that request against your Production configuration.

Threat Detection

A Security App configuration contains security rules that define the criteria that determine whether traffic is legitimate or a threat. Security leverages this security configuration and performs a sequential check for each criterion. An overview of this security check is illustrated below.

Each request undergoes the following security workflow:

Edgio will first screen the request against your Audit configuration. Proceed to the next step once either of the following conditions are met:
- An alert is triggered. Edgio will skip all remaining Audit configurations.
- Edgio has finished screened the request against your Audit configurations.
Does the request meet a whitelist criterion defined within an access rule? If so, it is considered legitimate and no further checks will be performed.

A whitelist identifies traffic that should always be considered safe. Traffic may be whitelisted by ASN, country, IP address, referrer, URL, user agent, HTTP method, media type, and file extension.
Proceed to the next step if the access rule does not contain at least one acceslist.

Does the request satisfy at least one criterion in each defined accesslist? If not, then the request is identified as a threat and no further checks will be performed.

An accesslist identifies traffic that may access your content upon passing a threat assessment. Traffic may be accesslisted by ASN, country, IP address, referrer, URL, user agent, HTTP method, media type, and file extension.
Does the request meet a blacklist criterion defined within an access rule? If so, it is identified as a threat and no further checks will be performed.

A blacklist identifies traffic that should always be considered malicious. Traffic may be blacklisted by ASN, country, IP address, referrer, URL, user agent, HTTP method, media type, and file extension.
The payload for POST, PUT, and PATCH requests will undergo additional threat detection analysis if the Security App configuration has been assigned an API Security ruleset. Does the request’s payload violate an API schema? If so, then the request is identified as a threat and no further checks will be performed.
Has the rate limit been exceeded? If so, then the request is identified as a threat and no further checks will be performed.
Was the client identified as a bot? If so, then the request is identified as a threat and no further checks will be performed.
The request will undergo threat detection analysis if the Security App configuration has been assigned a custom rule set. Was a rule in the custom rule set satisfied? If so, then the request is identified as a threat and no further checks will be performed.
Will the request be served from cache instead of being forwarded to an origin server? If so, it is considered legitimate and no further checks will be performed.
The request will undergo additional threat detection analysis if the Security App configuration has been assigned a managed rule set. A request will be classified as a threat when the severity and frequency of rule violations exceeds the configured threshold.

The above threat detection workflow is illustrated below.

Managed Rule Violations

If other security rules cannot identify whether a request is legitimate or a threat, then it is up to the Security App configuration’s managed rule to make that determination. The request will be evaluated according to a managed rule’s enabled rules and its definition of a valid HTTP request. A request will not be considered a threat until a threshold of violations is met. The score assigned to a request is determined according to the severity and frequency of the violations.

Severity: Each rule is assigned a severity. Each severity is assigned an anomaly score from 2 to 5.

Severity	Anomaly Score	Description
Critical	5	This severity level is triggered by web attack violations.
Error	4	This severity level is reserved for future use.
Warning	3	This severity level is triggered by malicious client violations.
Notice	2	This severity level is generally used to indicate protocol policy violations.

Frequency: A threat is identified when the aggregate score for all violations meets or exceeds the configured threshold value. This allows Security to account for minor violations without forcing it to take action for a single offense.

A managed rule may be assigned a threshold value from 2 to 20. However, the recommended value is 5. A threshold value of 5 triggers threat identification after a single severe violation or multiple minor violations. This balanced approach identifies questionable requests without impacting legitimate traffic.

Best Practices

Best practices for setting up security vary by organization due to a variety of factors, such as those listed below.

Web Applications: The type of web applications running on the origin server may affect the level of protection that may be applied through Security.
Traffic Delivery Profile: The level of security that should be applied to site traffic may vary for a variety of reasons, such as:
- Public vs. private content that requires authentication
- Type of application (e.g., CMS vs. non-CMS traffic)
Additionally, there may be multiple traffic delivery profiles that are specific to an application, role, or the action being performed.

Sample scenario:

Both country and referrer access controls may potentially be applied to a site that requires authentication and only caters to customers in the United States. However, this configuration would be too restrictive for a site that has worldwide users from various traffic sources.
Acceptable Risk: Security allows the flexibility to determine the degree to which a site will be protected. A balance must be found between security and allowing the flow of legitimate traffic. A major factor in this balancing act is the degree to which an organization is able to cope with risk.

As a result of the above factors, it may make sense to tailor security by request type. This may require a Security App configuration and security rules for each custom set of security requirements.

Recommended Setup

The recommended approach for setting up security is described below.

Create an access rule with a minimal set of whitelisted access controls.
Create a managed rule according to these recommendations.
Create a Security App configuration that only screens traffic for your application. Add the above managed rule and access rule. Set their production action to Alert only.
Repeat steps 1 - 3 as needed.
After an acceptable period of time has passed (e.g., 24 to 48 hours), review the alerts logged in the dashboard. Assess whether your security policy is too permissive, generates too many false positives, or strikes a balance between the two.

Use the following tips to adjust your configuration:
- Too Permissive: Close any security loopholes by defining additional restrictions within your access rule(s) and managed rule(s). If your security policy is still too permisive, define custom threat detection critieria through a custom rule set.
- False Positives: If you detect that legitimate traffic is being flagged within the dashboard, then you should filter for the alert in question, expand a log entry, and then take a look at the Rule Tags field to determine whether a rule, access control, or a setting was violated. Take the following action:
  - Managed Rule: The recommended approach is to avoid disabling relevant policies and rules whenever possible. Assess the rule that was violated and consider whether the web application should be updated to conform to that rule. If careful analysis indicates that the security profile must be changed, then you should either create a rule exception (recommended) or disable the rule in question.
    
    Identify a rule through the Rule Tags and Rule ID fields. The Rule Tags field identifies a policy, while the Rule ID field provides the identification number for the rule that triggered the alert.
    
    Each policy contains a search feature that finds all rules within that policy whose name contains the specified term or that are an exact match for the specified ID.
  - Delivery Profile: Consider modifying the delivery profile defined within your access rule or managed rule to account for the set of traffic being blocked.
- Balanced: If the current security policy balances security with risk tolerance without causing too many false positives, then you should update the Security App configuration’s production action for the access rule and managed rule to Block request. This will cause Security to deny requests that are identified as threats.

Threat Detection through Managed Rules

The recommended approach to setting up a profile’s rule set is to:

Set the detection threshold to a level that balances security with risk tolerance. The appropriate value for this threshold will vary according to the set of enabled policies/rules and your traffic profile.

The detection threshold fine tunes threat detection to balance security requirements with risk tolerance. For example, this detection threshold may need to be increased if a significant number of false positives are detected upon activating an instance associated with this profile.
Enable as many relevant policies and rules as possible.
Disable all policies and rules that are inapplicable. This step is crucial for performance.

One way to deal with false positive alerts is to check to see whether the corresponding web application or the site’s source code may be modified to bring it into compliance with the offending rule.

Access Controls

Use an access rule to define access controls for URLs, countries, IP addresses, etc.

Whitelist: Use a whitelist sparingly to always allow traffic from a trusted source.

Whitelisting traffic should only be performed after careful consideration and with extreme caution. Whitelisted traffic will not be screened and therefore creates a launching point for a potential attack on your applications and web servers.
Accesslist: The recommended approach for traffic from trusted sources is to identify it through an accesslist. This approach allows that trafic after it passes a threat assessment.
Blacklist: The recommended approach for unwanted traffic is to identify it through a blacklist. Traffic identified through a blacklist can be blocked through your Security App configuration.