Authentication and authorization can and should be based on many factors. Relying solely on a username or group leaves a lot to be desired, especially when thinking about how to continuously layer on checks and balances to increase security. User and Entity Behavior Analytics (UEBA) not only looks at what users are doing but also at how the device, aka entity, is behaving.

So, what other factors should be considered?

Before we get into the factors, let’s look at the CAPTCHA challenge-response test and how it has improved over the years. We’re all familiar with CAPTCHA. You’re presented with a 4×4 grid of pictures and have to find the traffic lights, bicycles, stairs, and so on. This was great when bots were not able to quickly analyze pictures, but now most systems can quickly capture the pictures and find the ones with the traffic lights, bicycles, and so on. As a result, CAPTCHA started updating how they process the inputs. They look at things like time taken, scrolling, the methods and means to click on the pictures. These additions help detect human versus bot interactions, which was the initial reason to have CAPTCHA in the first place.

With that in mind, let’s look at additional factors that give input into behavior to determine if it’s the correct person trying to access your system.

• Time of day – there are business hours, but these business hours may not be the same for sales or engineering for example. Folks in DevOps may be logged in at 2 a.m. Sunday morning to push out a maintenance release.
• Day of week – similar to time of day, there may be typical business days of work, but these may not be the same for all employees.
• Location – where is the remote user logging in from? With integrations into HR systems, checks can also be done to see if the location matches with the city, state, and/or country that the user has given. There are also known “bad actors” which direct traffic from certain locations and those may raise red flags quickly. This factor should also include adjusting time of day/day of week if the end user has permanently moved or is traveling.
• Applications access – which applications does this group or type of user typically use?
• Direction of traffic – is the end user mostly consuming an internal website? Do they typically just upload or edit a document? Are they now downloading documents a few days before their last day of employment? Again, an integration with the HR system may help catch some of these anomalies.
• Volume of traffic – most job functions have a “standard” range of traffic volume. If you’re doing video editing, you’ll mostly like have more traffic than the person working on an Excel spreadsheet. Baselining the volume traffic and then tracking and looking for anomalies will help detect employees trying to take intellectual property before they leave or even worse, hackers that have gained access to systems.

For all of the above, it is necessary to establish a baseline. Not all employees work at the same time or on the same days. It is important to start learning about individual user behavior and start creating a baseline as soon as the user starts their interactions. This baseline should also employ continuous learning. Behavior in the summer (when kids may be home from school), or at the beginning of employment, may change significantly.

Now let’s look at what can be done and how:

• Learning versus enforcement modes – during the initial learning time as you baseline behavior, you don’t want to flag everything as an anomaly. However, as an admin setting policies you’ll also want to know what happens once you enable enforcement.
• Logging anomalies – all anomalies should be logged and shown in log files. Logs needs to be captured in UTC and normalized so that they are easier to read across regions. Anomalies should also be adjusted for severity and effect on access.
• Automatically reacting to anomalies – Once an anomaly is detected, the system should automatically react without needing analysis and action from a human. Multi-factor authentication (MFA) and sending out email/SMS challenges may be step one. Stepping down access may also be another form of immediate action. Allowing an admin to “acknowledge” an anomaly later may also be considered so that admins are aware of each anomaly, again, to help adjust policies.
• Advantages of a client to learn “offline” behavior – some systems only capture behavior when you’re connected to it. To get the best overall baseline of user and entity behavior, the system should always be looking at behavior. A client will also be able to detect software like keystroke loggers and other software that may be capturing credentials or trying to intercept system or network calls.

To schedule a demo and see how easily you can layer on security with Banyan, visit https://www.banyansecurity.io/demo-request/.