Evidian

Risk-based
Authentication
Evaluating contextual factors to estimate and mitigate
risks related to access requests
DirX Access is a comprehensive accessmanagement and identity federation
solution. Starting with version 8.5, thecapabilities of DirX Access have beenenhanced by adding risk-based
authentication (RBA), also called adaptive
authentication.
RBA has recently become a new must-havefor IAM products like DirX Access thatprovide authentication and accessmanagement. DirX Access incorporates RBA
into its main decision-making mechanism,making it readily available for use whenevaluating any request.
From a technical standpoint, RBA evaluates
the potential risks connected with every
interaction between the user (also called anagent) and the system. These risks must be
offset by a sufficient level of confidence –assurances – regarding the user's identity. If
these assurances cannot be made, additional
actions must be taken, such as advanced
authentication, auditing or request denial.
Any resource can be assigned one or morerisk conditions as well as a sensitivity level.
The risk conditions evaluate the request data
either generally or at a user-specific level. The
general approach allows administrators todefine risk factors like lists of malicious IP
addresses and other static policies. The userspecific approach takes the user’s behavior
patterns into account and raises the risk level
when it detects a behavioral inconsistency,

Trusted partner for your Digital Journeysuch as a request from a different
geolocation or at an unusual time of day. The
resource sensitivity approach allows
administrators to increase the assurances
needed to access a particular resource.

Motivation
When speaking about securing any
enterprise solution, identity verification is oneof the main problems to solve. The processof identity verification must be secure,reliable and user-friendly.
Confidence Provided by Authentication
Methods
The methods of authenticating a user to asystem generally fall into three categories, or
factors, depending on the type of
information in use: knowledge (a password, a
PIN or the answer to a challenge ),possession (a smart card or a mobile phone),and inherence (a fingerprint or face).
Any authentication method achieves a levelof confidence connected with its use; theparticular levels are highly dependent on themethod’s factor. Security officers should be
responsible for designing appropriate
policies for evaluation of available
authentication methods. The policies thendetermine the appropriate authentication
methods for the intended use. This process
results in assigning a number to eachauthentication method to represent theconfidence for the purposes ofprocessing with RBA. By combining
multiple authentication methods, usuallyof different factors, the confidence in the
combined solution can surpass its
respective components. This approach iscalled multi-factor authentication.
Measuring Risks from User Data
Earlier, we mentioned each user’s
interaction is connected to risks
evaluated according to the risk
conditions. We can also look at this fromthe opposite point of view – the unfulfilledrisks being the fulfilled assurances. We fix
the amount and nature of the data thatthe user sends to the authentication
system and then try to retrieve as much
useful information from this data as
possible. This process provides very
good results thanks to the use of big data
and machine-learning techniques. This
represents the idea that authentication isin fact a machine-learning process. Thisidea emerged several years ago and isgaining popularity in the industry. The
major market players have deployed themachine-learning approach toauthentication into their IAM products,
usually under the name of risk-based or
adaptive authentication.

RBA: Benefits and Trade-offs
DirX Access RBA addresses the typical issues
connected to the process of authenticationof information system users: Achieving sufficient confidence in theclaimed user’s identity.
 Reducing the use of laborious methodsof authentication.
 Preventing the necessity of costly
solutions.
This is achieved by the built-in evaluation
mechanism, when RBA collects all possible
risks connected with a user request on theprotected system and then compares themto the assurances given by theauthentication methods. These risks haveseveral different forms: risks known inadvance (for example, a request from amalicious IP address), risks connected with
unexpected data (user behavior), and risks
connected with requesting a resource thatdemands a higher level of protection(resource sensitivity). This last form implies
that the DirX Access solution is resourcesensitive.
Not only does the behavioral approach
identify the risks; it also provides additional
assurances regarding the claimed identity. In
this way, RBA represents a supporting
continuous behavioral authentication
method. Some of the evaluations that RBA
performs are truly based on a user’s past
behavior.
The behavioral data cannot be used tounambiguously identify a user; however, they
increase the confidence in the claimed
identity. By contrast, if the user deviates fromthe expected behavior, the confidence in theclaimed identity decreases, and the system
can challenge them with additional
authentication directives. In this way, RBA
enables an optimal trade-off between
security and user friendliness.
RBA is able to utilize the information about
the device used for interaction with thesystem for authentication purposes. If such a
device is in the exclusive possession of theuser, RBA might serve as the possession
authentication method.
The basic part of the RBA mechanism isformed by general risk conditions that areuser independent. These conditions can beused for known threats prevention.

Examples include denying access frommalicious IP addresses or at unexpected
times.
Contrary to the static policies, such as
minimal password length or official working
hours, user-specific part of RBA represents a
more dynamic way of evaluation. The
enterprise security policies are applied herewith respect to the assessment of statisticaloutcome. With this in mind, RBA informs thesystem administrator about, for example, thepercentage of user requests that cause
additional interaction (step-up authentication)
between the user and system. Based on thisassessment, the administrator can change
the RBA policies to meet the enterprise goals.
One of the major advantages of RBA is that
there are no additional costs or actions on
the user side. For almost all authentication
methods, some deployment action must be
taken for any new user: the password must
be memorized or the smartcard must be
issued. And during the authentication
process, some explicit action from the user isneeded, resulting in a delay, a help desk call,and so on. With RBA, the only requirement isenough space and computational power.
The mechanism is immediately applied to
any user without any explicit interaction
required.

Risk Evaluation

System Overview

As mentioned earlier, RBA evaluation
does not demand any explicit userinteraction. If RBA determines that theauthentication is insufficient, an action istaken depending on the system policy.
By default, the request is denied.
Optionally, DirX Access can employ the
Authentication Application component toallow legitimate users to provide stronger
evidence of their identity. Instead of asimple denial, the user is redirected to the
Authentication Application and provided
with all the authentication methods thathave an assurance level that is highenough to balance the risks, a process
called the challenge approach. All of the
RBA mechanism’s actions are also
logged.
As we can clearly see here, an importantpart of the RBA-enabled system is a wide
range of authentication methods thatallow for the establishment of different
levels of trust. DirX Access addresses thisThe traditional authentication process isperceived as an initial action that provides us
with the user’s identity. The identity
subsequently remains unquestioned until theend of the session.
Risk-based authentication is a newcomponent of an authentication process that
introduces two substantial improvements.
The first is decision set extension: instead ofproviding only the authenticated/denied
state, RBA outputs a relative measure of therisks connected with the trust in the resolved
identity (which can also be seen as aconfidence in the identity claim). The second
improvement lies in the extension of its
applicability to any user request: with RBA,
authentication becomes a continuous
process of recalibrating the risk level torespond to new important information about
the user’s behavior that may be contained inany new request.

The compound estimation of the risks isuser-, request-, and resourcedependent. For every resource, a set of
conditions is defined and subsequently
applied during the evaluation process.
Each condition assesses relevant requestand user-related data and outputs asingle number that represents theestimated risk. In DirX Access, the intervalfrom which this number is drawn isconfigurable to reflect both theenvironment specifics and the enterprisesecurity policy. The conditions aremutually independent, so they areevaluated separately and the outputs are
summed into the final risk level.
Another RBA system variable is theassurance level. Every authentication
method has its assurance level
configured. The user’s authenticatedstate contains the assurance level
granted by the most secureauthentication method used.
On each request, the assurance and risk
level are compared. If the risk level ishigher, additional authentication actions
are invoked.

User Perspective

Figure 1: Risk-based authentication system in the context of request processing
2

DirX Access ---- Risk-based Authentication ---- White Paperissue by offering a large number of directlyimplemented methods, including passwordbased (customizable form, basic), possessionbased (X.509), one-time passwords(RFC2289, RFC4226, RFC6238) and more.
The number of methods is even extended by
the support of identity federation standards(SAML, OAuth) and the ability to wire any
custom solution into the system using a
dedicated customization interface.

General Risk Conditions
The general type of risk condition represents
the evaluation that is request-dependent
only. When targeted on one of the definedresources, the request data (being from anarbitrary user) are evaluated using therelevant condition. The condition is either
satisfied or violated, with violation leading to
the increase of the risk level by a definedvalue.
In addition to the built-in conditions, DirX
Access allows including a custom condition
solution, thanks to a customization interface.

Known Threats Prevention
Because general risk conditions are userindependent, they can be seen as prevention
against known threats. DirX Access RBA cantrack three different features: IP addresses,
time ranges, and HTTP protocol headers.
Tracking malicious IP addresses is acommon approach to attack prevention.
There are a number of publicly-accessible
lists that can be easily included into the risk
condition configuration. The administration
tool DirX Access Manager allows theadministrator to enter the addresses either
directly or by ranges. When using ranges,
RBA can also be used to privilege the wellknown addresses (for example, from thecorporate network).

Figure 2: RBA evaluation of user context-aware conditions

Login Failures and Login
Interval

User context-aware Risk
Conditions

Although we consider them to be generalrisk conditions, the login failures and login
interval risk conditions are somewhat special
in that they depend on several user-specificparameters: login failures on the number ofsubsequent login failures (incorrect
credentials use) and login interval on theinterval since the last successful login.
The login failures condition enables a morefine-grained approach to account locking bysoftening the hard limit of unsuccessfulattempts allowed. The hard limit can beincreased while the condition may enforce
the use of stronger authentication methods
after a lower number of attempts.

The user context-aware (UCA) risk
conditions represent a very powerfulmechanism. They fully leverage userdependency to model user behavior andthen perform a risk-level assessment on
the model. The underlying algorithms
employ several machine-learningtechniques and principles according to
the structure of the data used for theevaluation.
Each UCA risk condition by itself gives
the relative confidence (risks) connectedwith the evaluated data. The evaluation
output needs to be able to express thisfact. Hence, the output of the UCA risk
condition evaluation can be drawn fromthe values in the continuous interval tothe defined risk level.

Resource Sensitivity
As mentioned earlier, RBA demands a certain
level of confidence (assurances) regarding
the user's identity to balance the risks. The
resource sensitivity type of risk condition
can be used to explicitly increase the level ofconfidence needed to access particular
resources.
Having in mind the purist approach toconfiguration of risk conditions, this is a very
important risk condition type. Ideally, we
would like to have all defined conditions
applied when requesting any resource andthe only resource-dependent setting would
be achieved by this condition type. In
practice, however, it’s not important toevaluate all conditions in all cases, so someconditions can usually be omitted to
improve performance.

DirX Access ---- Risk-based Authentication ---- White Paper

Figure 3:
The distribution of the risks (x-axis; minimal 0; maximal 9) for the access time data.
Y-axis shows the number of requests evaluated for the corresponding risk level.
3

Learning Process

Figure 4:
The potential risk levels:
the darker the color, thesmaller the risk,
X-axis = authenticationtime,
Y-axis = number ofinteractions of thelegitimate user with thesystem.

DirX Access employs the received userspecific data that can be used in UCA RBA in
the learning phase. These data update theuser model that is subsequently used during
the evaluation. The entire process is highly
configurable due to performance reasonsand the need to address the specific data
dependencies. Examples of configuration
options include the learning frequency
during the user session and the data
expiration time.
The data learned during one session arepropagated into the user model at the end of
the session and are then employed within
the evaluation of the subsequent session.

Figure 5:
After the first interaction:
RBA is tolerant.

Risk Evaluation Process
For each UCA risk condition, the evaluation
phase takes the relevant data from the usermodel and operates on them according to its
internal algorithm.
The system allows for configuring arbitrary
UCA risk conditions. On the other hand,determining the relevance of a particularcondition type with a particular configuration
can be a complex task that can be eased
somewhat by understanding therequirements and constraints on UCA RBA.
The main intuitive requirement is this: Assign
the minimal risk level to any legitimate
interaction between a legitimate user and theprotected system. The simple solution to thisrequirement is to assign the minimal risk
level to any interaction. As a result, thesecond requirement is this: Assign the
maximal risk level to any interaction between
the illicit user and the system. The problem isthat we do not know the true distribution of
the legitimate and illicit requests. To
determine it, we use the very machinelearning mechanism at the core of theevaluation process. This process, however,transforms the initial requirements into this:Assign the risk level in proportion to how
close the evaluated data are to the data
expected for the legitimate user. UCA RBA
handles the security aspect – the resilienceagainst illicit requests – internally. Conversely,
administrators can monitor the correct
resolution of legitimate user requests andshould leverage this information todetermine the condition configuration.
Figure 3 shows the risks determined for
legitimate user requests by evaluating accesstimes (in a real deployment). We can see thatthe evaluation gets closer to granting theminimal risk level most of the time. The tail ofthe graph shows the peak for the maximal
risk level, which is due to learning a new andpreviously unobserved user behavior.
Considering usability, the distribution seen in
Figure 3 is approximately the one to look forwhen designing an efficient condition.

4

Figure 6:
Several followinginteractions occur at
almost the same place:
RBA assumes that theposition does not change
and is very precise.

Figure 7:
An access from anotherplace is recorded: RBA
starts to be more tolerant
but preserves the
expected areas and their
proportions.

Figure 8:
An access from yet
another place is recorded:
RBA becomes even moretolerant to cover larger
areas around the pastoccurrences.

DirX Access provides an RBA test mode forrealizing this methodology. If a UCA risk
condition is switched to test mode, the entire
learning and evaluation process proceeds
normally except that the result has no effecton the compound evaluation result. Instead,the results are monitored and can be further

analyzed to achieve the optimal UCA
RBA configuration.

DirX Access ---- Risk-based Authentication ---- White Paper

Risk Evaluation Algorithm

Complexity

Future Outlook

The risk evaluation algorithm depends on
the type of supplied data.

RBA was designed with a major emphasis on
its usability in the enterprise environment.
This focus naturally resulted in complexity
optimization. We did not identify any
substantial increase in time or spatial
requirements for the general risk conditions.
Depending on the actual configuration, theUCA risk conditions may cause an increasein time consumption during the request
processing. However, this increase is forreasonably-configured conditions in thesame order as the time of the condition-lessrequest processing. Taking into account thatthe decisions are sent over a network, which
is much more time-costly, the UCA-related
time consumption can be consideredinsignificant for the decision consumer. The
UCA risk conditions also impose spacedemands to store the user-related data.
These demands are highly configurable,
enabling the customer to set, for example,
the upper limits of the space consumption.

Continuous research and developmentof the risk-based authentication
mechanism provides a long-term cuttingedge solution. The evolution ofcontemporary technologies makes thearea of risk-based authentication lookvery promising. In particular, mobile
devices are enabling the use of a growing
number of sensors that produce
interesting user data. Together with theever-more-frequent employment ofmobile devices in the enterpriseenvironment, this trend offers a unique
opportunity to improve the security of
the information systems.
The development of machine-learning
mechanisms is opening up other great
possibilities. Even the currently
transmitted data contained within every
request contain much more information
than is currently usually used. The focus
is on evolving from a risk evaluation
mechanism to a mechanism thatprovides an independent authentication
method.

Ordinal Evaluation
Ordinal evaluation is based on the proximityof evaluated values to the ones recorded in
the user model. In this way, DirX Access canprocess the access time, IP address, andgeolocation data.
The geolocation data are transported to thesystem using the HTTP Geolocation header
defined in a standard draft1. The
Authentication Application enables using
devices that can provide the geolocation
data through the JavaScript Geolocation API.
Figure 4 shows the potential risk levelassigned to the authentication request at aparticular time of day. The changes arecaused by the interaction of a legitimate user
with the system over time – their behavior is
re-evaluated on each new authentication
request.
Figures 5 to 8 show the changes to themodelled geolocation over the time of theinteraction with RBA. The vertical axis
represents the normalized risk level while thehorizontal axes represent the geolocation. In
this case, the visible square depicts the areaof a town, where the data have beencollected for a single user. The resulting
graph shows the potential risk level assigned
to a request from the particular position (forall possible positions).
Device ID
When the device ID risk condition is
configured, DirX Access attempts to deploy along-term cookie on the client side. This
cookie is subsequently used to identify thedevice (more precisely, the client application)and this information is used in a specificevaluation process.
String Evaluation
String evaluation is the simplest process. It isbased on the strict match of current request
values and user model values. However, toextend its expressiveness, regularexpressions can be used in the evaluation
process. This way, DirX Access evaluates the
HTTP request headers and custom string
data supplied to the system via acustomization interface.

Geographic extensions for HTTP
transactions. https://tools.ietf.org/html/draftdaviel-http-geo-header-05
1

DirX Access ---- Risk-based Authentication ---- White Paper

5White Paper

About Atos
Atos is a global leader in digital transformation
with over 110,000 employees in 73 countries
and annual revenue of over € 11 billion.
European number one in Cloud, Cybersecurity
and High-Performance Computing, the Group
provides end-to-end Orchestrated Hybrid
Cloud, Big Data, Business Applications andDigital Workplace solutions. The group is theWorldwide Information Technology Partner
for the Olympic & Paralympic Games andoperates under the brands Atos, Atos Syntel,
and Unify. Atos is a SE (Societas Europaea),
listed on the CAC40 Paris stock index.
The purpose of Atos is to help design the
future of the information technology space.
Its expertise and services support thedevelopment of knowledge, education
as well as multicultural and pluralistic
approaches to research that contributeto scientific and technological excellence.
Across the world, the group enables its
customers, employees and collaborators,
and members of societies at large to live,
work and develop sustainably and confidently
in the information technology space.
Find out more about us
atos.net
atos.net/careers

DirX_Access_RBA-White-Paper-en2

Let’s start a discussion together

For more information: www.evidian.com/dirx
Atos, the Atos logo, Atos Syntel and Unify are registered trademarks of the Atos group. July 2019
© Copyright 2019, Atos S.E. Confidential information owned by Atos, to be used by the recipient
only. This document, or any part of it, may not be reproduced, copied, circulated and/or
distributed nor quoted without prior written approval from Atos.