11436 SSO

Dealing with malicious attacks

Feb 24, 2012

In my last post I looked at some of the ways malicious users can attack your apps and APIs and ways to mitigate the risk of attack. This time we'll look at some more ways to push back against attackers.

When a malicious user or app is detected, the user or the app can be blocked, throttled or denied service. The confidence in the "maliciousness" of an app or a user can be used to take service denial actions or even to reduce the QoS available for such users and apps. Similarly, end users should be notified about actions taken against apps that have been authorized by the user to act on their behalf using their credentials. 

Let’s take a look at some of the push-back mechanisms in detail.

Quotas: Quotas can be applied at various levels i.e. at any one of user, app, IP address, or API level. In addition, quotas can be defined over multiple durations of time - that is quotas over windows of seconds, minutes, daily, monthly, and so on. A sensible quota strategy should use the traffic patterns generated by an app or seen by an API to deduce “good”, “bad” and “suspicious” behaviors over different sources and time durations and then enforce the resulting quotas judiciously. Denying legitimate traffic service because of misconfigured or stale quotas can cost usage and annoy legitimate users who can then in turn decide to leave the app or service. Automatic quota management is a good approach for scenarios where quota management is a necessity - that is for apps or APIs that have a high abuse potential.

Throttling: Like quotas, throttling can be applied to users, apps, IP addresses or APIs. Since throttling impacts the rate at which clients can make requests, a good throttling strategy requires integration with an intelligent traffic monitoring solution. Such a solution can employ and disengage various throttling measures based on changes in traffic while ensuring that higher volume traffic sources do not cause the lower volume traffic to starve for service.

Tiered Traffic: It is crucial for any developer or API provider to reserve and deliver the highest quality of service to the set of users who are “desirable”. In other words, to support users who promote the API or app, which in turn increases usage and profitability. Since profitability is a function of cost and revenue, a set of users that offers relatively high value but can be served at a lower cost (through caches etc.) are also good contenders for the higher tier. Users who are suspicious, unknown, or new or exhibiting mixed behaviors can be limited to lower tier traffic.

Blocking: Outright blocking is another option that can be implemented by “black lists” that are built and managed by the provider. Blocking when done extensively requires black list management, remediation, and expiration policies to ensure that entities on the black list are able to escalate and prove their legitimacy and so be removed from the black list.

Proofs: Users, devices, and apps can be asked to prove their legitimacy through “proofs” that force them to verify that they are human (e.g. CAPTCHA) or verify their identity (e.g. SMS or voice mail based code). There are numerous services that offer APIs that enable such functionality.

Regressive Actions: Often historical analysis is required to correctly classify the activity or behavior of an app or user. Offline historical analysis can be used to perform such classifications and “regressive actions” can be taken based on the results. In other words, the abuser is punished after they have carried out an attack. This ensures that no other users or providers can be targeted. In addition, regressive actions can be used to protect end users who have yet to be targeted by such attacks. For example, phishing email can be removed from a user's inbox if they have not yet read the email.

It is important to note that no single technique is a silver bullet and high-value services and users need to be protected through a mixture of these techniques. In addition, if there is enough money to be made by attacking users and providers, one should expect the abusers to push back against these techniques and attempt to game the system to be able to thwart or circumvent these defenses.

Next time, we'll look at designing online safety systems as they require the ability to dial the aggressiveness of the protection, detection, and remediation mechanisms up and down.

Scaling Microservices