An Attack Vs. An Anomaly: What’s The Difference?

No business wants to allow a bad actor to launch a successful account takeover attack on its users. As such, there are many tools available that can help block malicious traffic. There is an interesting challenge however, that is becoming more and more apparent as attacks become increasingly sophisticated. How do you tease out the ‘definitely bad traffic’ from the ‘maybe bad traffic’? What is an attack and what is an anomaly?

As attacks become more sophisticated, the line begins to blur between what is a clear attack pattern versus what is normal, healthy traffic. Having an aggressive solution that will block 100% of account takeovers sounds great in theory. However, that level of protection comes at the risk of false-positives, where good users get routinely locked out or blocked from completing transactions due to a misclassification. On the flip side, other solutions might prioritize zero false-positives. This too sounds good, until considering that the gains in user experience can come at the cost of letting less obvious attacks slip through the cracks.

A comprehensive solution should have the right balance of aggression and elegance. You want to recognize the absolute worst traffic and respond accordingly, blocking it outright with a staunch workflow. At the same time, you also want the ability to acknowledge traffic that falls into a grey area, and that can be managed with a more effective, user-centric workflow.

In short, a complete solution involves a pairing of playbooks that can address both attacks and anomalies. One flow dedicated to detecting and responding to aggressive attacks, and another dedicated to detecting and handling the anomalies gracefully. By bringing these two components together, you can be assured that your security solution is of the highest quality, while also ensuring that your users’ experience, core business metrics, and reputation remain intact.

What is an attack?

An attack is when someone deliberately tries to gain access to your user accounts. This may be to initiate an account takeover so they can make purchases, withdraw funds, or complete another type of detrimental activity.

This sort of attack usually begins with ‘credential stuffing’. These are automated scripts that rotate through thousands or millions of leaked credentials, trying each one to see if they are valid for a given application. In this case, the one attack can be spread across many IPs, User Agents, and devices, but there are often certain sets of common identifiers that can link the malicious traffic together.

When there’s a focused attack running against an application, you can often identify where that attack is coming from, provided you’re using the right tools and techniques. Once you’ve picked out a common set of attack identifiers, you can subsequently block out these types of malicious requests. Companies typically use bot detection, web application firewalls, and rate limiting rules to combat these types of attack, where they are able to take very aggressive stances, denying access to the malicious traffic outright.

What is an anomaly?

An anomaly is similar to an attack, in the sense that there is unusual activity taking place, though generally on a smaller scale. Unlike attacks, where the offending activity tends to flood through in distinct waves, anomalies are typically more ‘one-off’ by nature, and will be distributed consistently amongst the healthy traffic.

An example of an anomaly is when someone logs into a user account from a location or device that is different from the user’s historical activity. This activity is unusual for the user, so it raises a flag. The user may have been caught up in a phishing scam where somebody stole their password and is now logging in manually for the first time. On the other hand, the user might just be traveling on vacation or working remotely. This is a bit of a gray area, where there is nothing inherently malicious about the location and device itself, it just happens to be outside of the norms for this particular user.

What if the above case isn’t a scammer, and the user is in fact working from a remote office? Treating an anomaly case as an attack, and therefore taking an overly aggressive stance, you run the risk of blocking out a fairly high percentage of good users. So on one hand, you want to be secure and have a way to address these anomalies, but you need to be extra careful to not lock out legitimate users. Delivering a poor user experience can drive existing users away from your platform, and can also result in reduced conversion rates across the board.

Having a plan for each scenario

Attacks and anomalies have a lot in common, but you need to have a plan in place for how to react to each individually. Both occurrences should be handled delicately to ensure that you’re not only protecting your user, but providing them with a good experience; ultimately minimizing your false-positives and false-negatives.

Addressing an attack

If you identify an attack, you need to be ready to take aggressive action. For example, you should immediately block malicious devices, deny access to your users’ accounts, and prevent bad actors from making any updates or transactions. You should also trigger alerts to the account owner, informing them of the attack you’ve protected them from. As an added safety precaution, you will also want to freeze the user’s account and send them an email asking them to reset their password before they can regain access. The reason being – even though you prevented the bad actor from gaining access to their account, if you are aware that their credentials are in the hands of an attacker, it’s best practice to have the user rotate their credentials to prevent future attempts, should the attacker return with more sophisticate techniques down the line.

You want to be extremely confident that the user’s account was truly compromised if you are labeling something as an attack. Because you need to take such aggressive actions to remediate an attack, the user experience cost of a false-positive is severe. Therefore, for any tool being used to label attacks, the false-positive rate should be near-zero.

Addressing an anomaly

By their nature, “anomalies” fall into a gray area where false-positives are bound to occur at a higher rate. Because of this, we’ve found that many teams tend to stay away from this gray area entirely. However, these anomalies can actually be used as a way to increase the customer’s trust in your platform.

Opting to focus only on conservative countermeasures for attacks can leave companies and their users open to a range of more slippery threat tactics. Phishing attacks and manual-powered account takeovers are two examples of popular account takeover techniques that are generally discovered as one-off anomalies.

Having a plan in place to effectively secure anomalies without ruining user experience is a delicate balance – but it is possible! Anomalies are a perfect opportunity to prompt a step-up authentication challenge, for example. This provides the ability to thwart an attacker, without locking a good user out of the application.

A more passive approach would be to send the user an email or push notification informing them of suspicious activity on their account, providing them with the opportunity to submit feedback around the event, based on their assessment.

Depending on your application and business case, there are ranges of user experiences that can be rolled out, both in-app and out-of-band, to ensure that you are responding effectively to anomalies and gathering user feedback – without risking a poor user experience or a drop in your core business conversion metrics. When well executed, these cases can be turned into valuable opportunities to increase user trust in your platform, showing users that you are looking out for them and actively safeguarding their accounts.

Protecting users from attacks and anomalies

Ultimately, no company wants to see malicious activity of any kind from bad actors. Having a solid understanding of the differences between attacks and anomalies can allow you to create workflows that put the user first. In particular, being prepared to act aggressively against attacks, while still gracefully handling the gray area of anomalies, will put you in a better position to create a security experience that is seamless for users and covers all of your bases.