I have mentioned Risk Based Authentication (RBA) in the past in my MFA blog, but the technology is getting traction and more and more vendors deliver the feature, with the most recent from Forgerock – Autonomous Access. It seems to me, that with the scale of cyber attacks in the open, we may arrive at conclusion that RBA may just have to become standard. MFA isn’t mandatory everywhere (yet), but there are regulations in place (like PSD2 and its SCA – Strong Customer Authentication), that require enterprises to step up from their classic username/password combination to a lot stronger flows.
Risk Based Authentication
I call it the fourth authentication factor – ‘something you do’.
Long story short it’s a technology that allows us to categorise seemingly ‘as usual’ operations in the context of risk. It’s usually delivered in three flavours (outcomes): LOW, MEDIUM and HIGH. A classic approach (risk treatment) would be – do nothing for LOW (within risk appetite), do something for MEDIUM (apply controls to reduce risk which is slightly above risk appetite) and avoid HIGH, which in the context of authentication means – access denied.
Let’s look at an example. I have logged in to my laptop at 8am, which is what I do Mon-Fri, while working from home (the context here is – same time, same location, same days). It’s a low risk event and I am successfully granted access to the resources.
The following week I have travelled to my office in Bristol and I’m trying to log in at 11am. This is somewhat unusual, as I have never been there before (I am a newbie!) and despite providing the right set of credentials, the system triggers MFA, I need to click approve in my authenticator app on my mobile phone. That’s a medium risk event, because although unusual – plausible.
That week my authentication cookie is stolen from the browser and a hacker in the kingdom of far far away tries to get access to my email. While she or he is in possession of the cookie, the authentication server flags this because for some reason the operating system is now Windows (I normally use a Mac), it’s 2500 miles away and it wouldn’t be possible for me to travel that far in the amount of time between the requests. At this point (for the sake of the argument), this is beyond obvious that it cannot be me, so the access is going to be denied and perhaps the authentication session invalidated altogether. That’s a classic example of high risk, something way beyond risk appetite, that we simply avoid. Access denied.
Two main pillars of RBA
Many think of risk score (L/M/H) as a direct derivative of signals in some proportionate mathematical model. Let me explain why we have to split the signals and the formula to deliver the score. It’s not just about the ‘what’ but also about the ‘how’.
The signals
There’s not so many at the moment, but the list is growing as the technology grows. The most popular (consolidated) are:
Impossible travel and geolocation
You cannot login from London at 9am and from New York at 10:30am. At least in 2022.
UEBA (User and Entity Behaviour Analytics)
This is usually linked with some form of machine learning and/or artificial intelligence. We may observe the context of the user or the behavioural patterns. A classical example is tracking what types of devices our user uses. Mac or Windows, if so, what version of OS, what browser, resolution, font size, etc. If the attacker takes over our credentials but uses a different device, we may have a chance to flag it. Another example would be tracking what user accesses. A chemistry student requesting a lot of materials from a higher maths course may be suspicious. Banks have been doing this for a while, at least for a few years, if you had an unusual transaction on your card, it may be denied. I experienced this buying a car. It was unusual for me to spend so much money in one go, so I had to call the bank to approve the transaction.
IP address reputation
Where are you connecting from? How long was the IP in use? Is it used to send a lot of emails? Are you part of the TOR network? Have you been naughty and launched some Denial of Service (DoS) attacks or just been hacked and used as a node of a botnet. You can read a bit more about the IP reputation services in mu other blog here.
Anonymising attempts
If you’re trying to hide where you’re coming from, it may be considered suspicious. After all why would someone who has nothing to hide do that? Now, before I am swamped with complaints from privacy enthusiasts, you gotta grant me that the majority usually establishes the ‘norm’. And the overwhelming most of us don’t use TOR browser to log into the bank.
Known credential attacks
Credential stuffing, password spraying, you can read about them here. If I try to login from my home using too many different accounts it may be flagged. To make things worse I may try to use the pwned database (known stolen credentials), that would be flagged, too.
The score calculation
Once we have all the signals we need to deliver the score. The formula should be based on business and its operation model, together with a use case. Sometimes we might want to summarise, sometimes take the strongest signal or even multiply by a factor or simply average out. How the risk score is calculated is important to make sure that we have a low amount of false positives and that the RBA is effective from security perspective.
RBA – a function of…
In no particular order – security and customer experience (one may argue, the latter being a business function). Security – kind of self explanatory. But let’s talk about the customer experience a bit more and consider the good, the bad and the ugly. Whenever we talk about MFA (or even passwords!), we tend to call it ‘friction’. Friction is an enemy of customer experience (CX), meaning the more seamless the experience is (in our case the authentication journey), the better the overall feeling. The RBA evangelists will say, hey, if it’s low risk, we don’t need MFA, we can provide low friction. We will ONLY ask for stronger authentication if something is off. Ok, you convinced me. The next thing is you try to convince business in financial markets to use it and… they won’t settle for anything below MFA, mostly because of regulatory requirements. We don’t ever encounter the equivalent of LOW, which provides less friction. You may say, I don’t need RBA, because it adds no value. And you could not be mistaken more…
RBA on steroids aka intelligent authentication
Those who know me or work with me, will be fed up, as I talk about it every time I discuss RBA, but, I think it’s really important to understand. Not just for identity architects designing our stacks, but also for the architects of the actual solutions. Because we can act differently on the levels provided by risk engines, even if the organisation requires MFA everywhere (e.g. SailPoint), we can still lower the friction by reducing the amount of times user is challenged with the additional factor. For example, the first time user logs in, we are going to challenge that request with a push notification to an authenticator app. However for the next week, we’re not going to do that again… for as long as the risk level remains LOW. If it’s MEDIUM, we’re going to challenge the user every single time. There you go, MFA everywhere (but not every time) and we still have LOW/MED/HIGH levels of risk. We can push the boundary of HIGH risk, too. If our false positives and denied accesses are expensive (resulting in losing customers to competition for instance), we can choose to select much stronger authentication factors (like NIST level 2 assurance devices) or even carry out identity proofing.
Because intelligent authentication allows us to act on signals throughout the lifecycle of the access and identity management, we can deploy different risk policies depending on the resource or action taken. For example, when we register an account, we could check if the password has leaked against Pwned password database or we could deny bank account creation if the user comes from anonymised network.
The binary character of RBA signals
We can break down the signals into two main categories. Something we know and something we need to learn first. Credential stuffing or IP reputation are somewhat obvious signals. We know the blueprint of the credential attacks, it’s easy to detect them and then counteract. UEBA (User and Entity Based Analytics) on the other hand is based on AI/ML and requires learning time to distinguish standard patterns in user behaviour. This usually is defined per amount of transactions and/or in a function on time. Individual user’s behaviour is always learned quicker, than group’s behaviour. When we deploy RBA into production, the machine learning portion is used, but the signals don’t participate in the overall risk score. Once we have enough data, the analysis kicks in and the scores appear in the journey.
The bottom line – when
As we can see, RBA can be used from day 1 and it can be very useful. Depending on the requirement it will reduce friction in our authentication journeys, greatly enhancing customer experience and improve security posture, reducing credential based attacks. I am personally of opinion it will become a standard in not so distant future and may be a differentiating factor when we choose a specific vendor or solution.