Each Security Configuration contains a policy that defines how your application handles incoming requests, and contains protections that enforce those controls.

When you create a Security Configuration in App & API Protector Hybrid, a default policy is created automatically. You can modify this policy to adjust how protections are applied to your application traffic.

Protections are individual controls within a policy. They apply specific rules and response actions, such as web application firewall behavior or custom protection rules. When you open your Security Configuration, you can access these protections from the menu on the left side of your screen. Read on to learn how to configure, apply, and adjust them:

Protect against web application attacks

Web Application Firewall protections perform rule-based evaluation of requests to either deny a request or trigger an alert. These rules focus on request behavior and traits. They defend against multiple known attack vectors and flag suspicious behavior, like protocol violations, HTTP policy violations, cross-site scripting attacks, injection attacks, and more.

Akamai's Web Application Firewall protection engine delivers advances that help you protect your websites with less effort and greater accuracy. Features include:

Flexibility for different management styles. Depending upon your product and experience, you can switch easily between two modes of web application firewall management:
- Automatic (recommended) updates itself so you always have the latest protections to face emerging threats. This is the easiest way to keep robust protections in place with the least administrative effort.
  👍
  Akamai conducts thorough advance and continuous testing of new rules. Rely on our monitoring and automation instead of scattershot manual efforts.
- Manual requires you to manually install new rule versions to stay up-to-date.

When you apply web application firewall protections as part of your security policy, the policy uses rules to examine specific requests and determine what, if any, action to take. Because our network handles about one third of the world's web traffic, it has unique insight into traffic patterns and request behavior. Our Security Research team leverages insights and data to improve rules and create new ones based on the latest threats.

Rules fall into attack groups which focus on individual attack vectors, like SQL injection, cross-site scripting, trojans, and more. You can specify defensive action by an attack group, and take advantage of our web application firewall engine's dynamic risk assessment.

How risk scoring works

When you scroll through the rules on your Web Application Firewall list, you see that their action is preset to Risk scoring. That's a misleadingly simple label for all the hard work the protection engine does. When evaluating a request, each rule runs and contributes a score up to its group. The whole group's tabulated score determines whether or not to apply the response action.

👍
In addition to the risk score by group, threat intelligence rules also evaluate a request. These rules detect suspicious request traits that fall outside regular web application firewall rules. These detections also contribute to scoring and taken together with web application firewall rule scores can help trigger a response action.

The risk-scoring system works well because it gathers lots of data. Armed with intelligence from multiple points along an entire attack vector, the group-level evaluation can make a broadly informed assessment of whether or not a request poses a threat.

How you can handle risk score intelligence, depends on how you're managing your Web Application Firewall:

Rule violations within an attack group combine to calculate an automatically-generated risk score for the group, which the engine uses to decide when to apply the assigned action. You also can set action by individual rules if you want. Say there's a rule you always want to enforce with a Deny action. When you do so, any request that violates that rule will be blocked, and evaluation of the request by additional rules halts.

👍
The proverb "Two heads are better than one." applies to Web Application Firewall rules as well. In some cases you may wish to have individual rules trigger actions, but when all the rules for an attack vector work together, their intelligence and effectiveness is enhanced. For this reason, try to apply action by group, leaving individual rules in risk-scoring. Or better yet, consider using automatic mode to not only set protections by group, but have them update themselves as needed.

Custom Rules

Use Custom Rules to handle scenarios not covered by standard rules or to quickly patch new website vulnerabilities.

The Custom Rule builder lets you alert on or deny requests based on parameters like:

hostname
request method
path
extension
filename
protocol version
request header
request header order
cookie
query string
request body parameter
request body parameter name

Custom Rules are a handy way to cover unusual situations. For example, say that your website creation software provider notifies you of a newly discovered vulnerability they plan to patch in an upcoming release. In the meantime, you could create a Custom Rule that protects your site from the problem.

👍
Custom Rules are version-level resources. It means that each Security Configuration version has its own set of Custom Rules.

You can't customize a rule that exists in the Web Application Firewall rule set. You can only create a new Custom Rule, and customize it to be similar and do what you wish.

Protect against denial-of-service attacks (DoS)

Distributed Denial of Service (DDoS) attacks attempt to bring down web content by overwhelming a website's origin server with bogus requests, often from multiple locations and networks. This attack traffic can result in slow page loads and even complete blockage of legitimate site traffic. App & API Protector Hybrid lets you configure your security policy to mitigate application-layer DoS attacks using rate limiting controls.

Rate limiting

Identify clients that send requests at an excessive rate.

To discover a security or application vulnerability, attackers often must send lots of HTTP requests. Rate Limiting Policies let you protect against excessive request rates like this and also against Denial of Service attacks by monitoring and controlling the rate of requests.

You create a Rate Limiting Policy and set rate controls in your Security Configuration. In the Rate Limiting Policy, you specify what to check, and in the rate controls you set the response action you want to take.

In your Rate Limiting Policy, you set the following two rate thresholds:

Burst threshold. The number of hits per second occurring within a one to five-second window.

👍
You can configure this timespan according to preference — however, for existing Rate Limiting Policies, proceed with caution and be careful not to reduce the measure window from 5 seconds without analyzing your traffic in Alert mode first.

Average threshold. The number of hits per second occurring within a two-minute window.

You can also set criteria for requests. For example, you could apply rate settings only to submission requests on your site's login page. The match criteria you set in your Rate Limiting Policy define the scope for initial request rate checks, which happen right away. It specifies which requests to tally and compare to your threshold settings. Violators are put in the penalty box for 10 minutes (if the action in your Rate Limiting Policy is set to Deny), where rate controls check for them.

You set rate controls within your Rate Limiting Policy. Controls let you specify the action to take on rate-violating clients.

👍
For rate controls, IPv4 addresses are identified using a /32 prefix, while IPv6 addresses use a default /64 prefix.

When a request comes in from a client currently in the penalty box, and it meets the match criteria for a Rate Limiting Policy, then the Deny action you specify in your rate control applies. The Deny action continues to apply to requests from that client for the next 10 minutes. After 10 minutes, the action deactivates until another request exceeds the threshold and reactivates it.

You can associate up to 10 Rate Limiting Policies with a Security Configuration. Consider using only 9 active Rate Limiting Policies to keep a free slot available in case of emergency.

Rate Limiting Policies are version-level resources, which means that if you roll back to an earlier Security Configuration version, these policies roll back too.