In our business now, we cannot escape the buzz word of all buzz words (Zero Trust). It truly is the “One Ring” to rule them all. Today, we’re here to introduce the gatekeeper of Zero Trust at the Edge known as “Login Risk Score.”

I’ve written about my view of Zero Trust just like everyone else has. If that wasn’t enough, I did it a second time just for fun last year. My highlight of VMware Explore last year (outside of speaking) was a session hosted by the “father of Zero Trust” John Kindervag. A sentiment he brought up is how no one is really doing zero trust as it was intended and talked about how it’s become a particular vendor’s interpretation of Zero Trust. I won’t waste anytime covering Zero Trust, but I will talk today about “Login Risk Score” which evolves your authentication at the edge being the gatekeeper of Zero Trust. Today, we will cover what it is, how to setup Login Risk Score, discuss a sample policy, a reporting script (since it’s not in Intelligence yet), and a demo.

What is Login Risk Score?

Risk Scoring in general is a new focus within Workspace ONE Intelligence, which you can read more about here. As VMware shows you, a nice graphic on the concept of risk scoring can be seen below:

Essentially, from a Login perspective you have two main points of data:

• The Device
• The Location

Login Risk Scores behave differently than the rest of the risk scoring fleet with VMware. The system leverages WS1 Access data and extends it to capabilities within Access Policies.

Information is ingested from a user’s login location and reports potential anomalous behavior. The machine learning model learns user login behavior to re-baseline their expected behavior. The ML model takes the history of a user to determine if something is out of the ordinary and adjusts and builds baselines during the first 14 days of that user’s logins. Users will be assigned a Low, Medium, or High Risk Level. During the learning period, the user is ranked as a medium-level risk (a big improvement from where it was, thanks to the PM Giresh).

It’s hard to understand what Low, Medium, and High mean as those terms are highly subjective. Per the VMware Docs:

• High – High Potential that this user/location is risky and could be a threat along with the worst score you could have.
• Medium – Moderate potential to be a risk to your organization. As mentioned earlier, the expected baseline early on.
• Low – This score is the desired outcome. The user is known and is considered to be very low risk.

Now, we will discuss some potential scenarios and how they’re scored today.

Some Risk Scoring Scenarios for Login Risk Score

We’ll use a basic table to examine a few scenarios and how they should be scored.

The User Behavior	How the Risk Should be Scored	Notes
New User’s Initial Login	Medium	This should be our default if no login history exists.
New User w/ subsequent logins from a known browser and location	Low	This is during the grace period of 24h.
New User w/ subsequent logins from a new browser and known location	Medium	Any new data points will have risk assessed and graded as a medium risk.
New User w/ subsequent logins from a known browser and unknown location	Medium	Any new data points will have risk assessed and graded as a medium risk.
New User, new login 24+ hours later during learning period	Medium	Grace Period is (24h) during the learning period of 14 days
Existing User, w/ known browser and location	Low	Once established, the baseline grades the actual risk.
Existing User, w/ new browser or location	Medium	Any new data points will have risk assessed and graded as a medium risk.
Existing User w/ subsequent logins from that new browser or location	Low	Once established, the baseline grades the actual risk.

A note around the scoring system is that there might be some challenges on risk score high. I would not recommend using “High” at this juncture as I am working with Product Management at VMware to identify the issue there.

Essentially the way Login Risk Score works is:

1. You start at a Low Score
2. If a device or location is not known, you are now a MEDIUM Score
3. Don’t forget the 14-day grace period and that will impact and force medium scores.

Now, let’s cover the super easy setup.

Setting up Login Risk Score and Policy

The setup of the Login Risk Score is easy. First, you go into the auth methods and click “Configure” on Login Risk Score:

I strongly recommend setting it like this below:

Setting up the policy is pretty easy too. This is what an example policy would look like with step-up authentication:

Basically, what you want to actually add is the “Login Risk Score” into your existing auth methods, and then add a new auth method without Login Risk Score (as the step-up authentication method). It’s not too hard and just take a bit of work to get right:

A little demo on what a “Block” looks like and the policy setup can be seen below:

User Experience Demo for Login Risk Score

The only real issue I have with the user experience is that you cannot customize the language, but overall it’s relatively nice and clean. Even blocks are well-written (except the spacing and formatting needs work) as you saw the previous two demos.

Login Risk Score Auditing Script

So, a nice piece that I have put together is a script that will dump the users and their Login Risk Scores so you can audit this. Soon, it will hit Intelligence, but you can’t really use stuff like this if you aren’t doing the due diligence. You can access my script here, which is an offshoot of the scripts from my WS1 Access blog article last week. Let’s check out the code a little bit: (we will only cover the code that is different from my base auditing script)

$Response = Invoke-RestMethod -Uri https://$AccessURL/analytics/reports/audit?objectType=LOGIN&fromMillis=$fromMillis&toMillis=$toMillis -Method GET -headers $Headers
$list = New-Object System.Collections.ArrayList @()
for ($i=0; $i -lt $response.data.length; $i++)
{$list.Add(($response.data[$i][4] | ConvertFrom-Json)) |Out-Null}
$RiskLevel = $list | Where-Object -FilterScript {$_.values -like '*LoginRiskLevel*'}
$RiskLevel | Select-Object actorUserName, actorDomain, sourceIp, deviceId, @{Name="LoginRiskLevel";Expression= {$_.values.LoginRiskLevel}} | Export-CSV C:\temp\RiskAuditLog-$((Get-Date).ToString('dd-MM-yyyy')).csv

So, this is what our code does:

1. It says give me the last 7 days of Login Events from the Audit Log
2. Creates a new Array List
3. Adds the stuff from the Audit Logs to that Array
4. Filters the array for any events that have the words “LoginRiskLevel” which are what we care about
5. Formats the data for the CSV with username, domain, source IP, device ID, and Login Risk Level.

Overall, it was a bit of a pain to get it exactly how I wanted it, but it was a great result and helps you dig deep into Login Risk Score.

Final Thoughts

Well, a few weeks later I have finally finished beating my head against the wall and I hope you enjoy the fruits of that labor. The main issue right now with Login Risk Score are the “High” events which aren’t even the fun sort of high! I will be working with product management on that like I did with the 30-day grace period. Luckily, Giresh is a good partner and I hope this can really deliver some huge value. This is especially crucial for your VMware Horizon strategy since Access will almost certainly be your IDP for Horizon even if you have Ping or Okta around. Trust Mobile Jon.. and IMPLEMENT this because it will give you some nice credability and if you’re lucky maybe you did something your IAM team hasn’t even done yet.