Web Application and API Protection

• Edgio Security is designed to protect your organization’s properties. As a result, it is configured at the organization level and cannot be applied to a private space.
  This design encourages you to apply a consistent security policy across all of your organization’s properties. However, you can also tailor your security policy to specific types of requests. For example, you can apply a security policy to a specific domain (e.g., www.example.com) or URL path (e.g., /scripts/*).
• Edgio allows all organizations to set up basic security through Security Insights. However, we also offer more comprehensive solutions. Contact your account manager or our sales department at 1 (866) 200 - 5463 to upgrade your account.

• 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.
• Detect and mitigate attacks, such as cross-site scripting (XSS) and code injection, by applying a Content Security Policy to your traffic.
• Validate payloads for API requests.
• Validate JSON Web Tokens provided within API requests.
• Detects violations of your Content Security Policy.

Basic Setup #

• 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.
  • Content Security Policies.
• Step 2 - Create a Security Application Configuration: Create a Security Application 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.

Dual Threat Detection #

• Enforce a proven security policy on your production traffic.
• Audit a new security policy without impacting your production traffic. Auditing a new security policy before enforcing it provides the means through which you can safely identify and reduce false positives introduced by changes to your security policy.

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

Threat Detection #

1. 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.
2. 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.
3. 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.
4. 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.
5. The payload for POST, PUT, and PATCH requests will undergo additional threat detection analysis if the Security Application 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.
6. Has the rate limit been exceeded? If so, then the request is identified as a threat and no further checks will be performed.
   Although most enforcement actions will cause Edgio to stop evaluating a request, this is not the case for alerts generated as a result of a rate rule. Requests that generate alerts are still eligible for enforcement by other security rules defined within a Security Application configuration.

   
   

   Rate rules is an exception with regards to request evaluation after an alert has been triggered. For all other security rules, Edgio Security does not perform further evaluation of a request once enforcement is triggered.
7. Was the client identified as a bot? If so, then the request is identified as a threat and no further checks will be performed.
8. The request will undergo threat detection analysis if the Security Application 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.
9. 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.
10. The request will undergo additional threat detection analysis if the Security Application 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.
11. For requests served to a client, does the response’s payload attempt to load a resource that violates your production Content Security Policy? If so, then the client will block that request from being submitted.

Managed Rule Violations #

• The request violates a rule associated with the EC Custom Rule policy or a policy whose name starts with Adv.
• The request violates sufficient rules to reach the threshold score defined within the managed rule. 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 #

• 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.

Recommended Setup #

1. Create an access rule with a minimal set of whitelisted access controls.
2. Create a managed rule according to these recommendations.
3. Create a Security Application configuration that only screens traffic for your application. Add the above managed rule and access rule. Set their production action to Alert only.
4. Repeat steps 1 - 3 as needed.
5. 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 Application 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 #

• 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 #

• 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 Application configuration.