Kelly Ahlers

Operationalizing Threat Aware Authentication

Blog Post created by Kelly Ahlers Employee on Apr 29, 2020

Shout out to @Casey Switzer, @Josh Randall & @Larry Hammond.  Without their help, the lab, configuration and operational considerations would not be possible.

 

Last year in RSA NetWitness 11.3, a new integration was introduced to allow NetWitness to integrate with RSA SecurID to populate high risk users from incidents in Respond.

 

@Josh Randall covered this in his blog post here: Examining Threat Aware Authentication in v11.3

 

At the time, SecurID could only add a user to the list based on an email address.  While this is good for email based alerts, the majority of Linux and Windows logs do not contain that value.

 

An easy workaround for this is to configure a recurring feed (See Decoder: Create a Custom Feed) including sAMAccountName & email address.  A simple powershell script to export sAMAccountName & email address should suffice. When you create an incident based on sAMAccountName the email address is present in the session's meta data allowing the ThreatAware authentication integration to work.   I used several callback keys to ensure I covered the various conditions to capture the username.

 

 AdUserEmailAddress Feed

 

Once this feed is live, you will see email.src & email.all metadata upon an event containing any of the meta keys above.  In this case it was a failed logon:

Email Meta

 

As of April 2020, RSA SecurID will now accept email address or username for Threat Aware Authentication and to support this, version 11.4.1 of NetWitness, introduced configuration for Respond for which field send to SecurID.  See Respond Config: Configure Threat Aware Authentication for more information.  

 

This represents a great option to using ad_username, however when you choose that value, you will lose the email_address integration.  A way around this is to do the inverse of the feed earlier to ensure you have the email address field in your sessions.  For this blog, we will continue to use the existing feed and send email_address to SecurID.  I set my synchronization to 1 minute but the default setting is 15 minutes.

 

Threat Aware Authentication Settings

Within the RSA SecurID Cloud Access Service, you will need to configure your Assurance Levels and  Risk-Based Authentication policies.  I set my Assurance Levels to require Device Biometrics for High Assurance, Approve for Medium and allow at a Low level.  I set a simple policy which will be used for the SAML test.

Assurance Levels

Assurance Levels

 

Policy

 Threat Aware Policy

 

Rule set

Threat Aware Rules

We have a test user which will be used to demonstrate Threat Aware Authentication.  Currently as you can see, Brett Cline is synchronized from lab.internal and is currently a low risk user.

Low Risk User

 

When Brett navigates to an app, he is presented with a logon screen with his password:

Test App 

Since he is low risk, after a successful authentication with User ID and password, he is now logged in to the demo app.

App Success

 

We created a simple ESA rule to catch 3x failed logins  to create an alert (ec_activity = 'Logon' and ec_outcome = 'Failure' 3x within 3 minutes) and a corresponding Incident Rule to group these alerts and create a meaningful title. 

Threat Aware Incident Rule

 

We simulated a few failed logins to create an incident:

Threat Aware Incident

 

Back in the SecurID Cloud Authentication Service, you can see that Brett has been added to the high risk users

Test User High Risk

 

 

Now when he logs into the app, he will be prompted for his userid/password

But due to being on the high risk users list, he will be required to approve via biometrics on his phone as per the policy set above:

 

Which will then lead to the successful authentication.

*** Note: The user will remain on the high risk users list until the incident is closed. ***

 

Additional Information:

 

If you are collecting logs from the Cloud Authentication Service, you will see the following meta keys:

And here is the corresponding event: 

Operational Thoughts:

@Larry Hammond for some insight into operational considerations.  He and I spoke about how NetWitness has traditionally been a passive device and cannot/should not interfere with your network or operations.  With the addition of Threat Aware Authentication, a poorly crafted rule could add many users to require step up authentication which could result in a disruption to business.  Good rule building practices should be followed and ensuring you test them before creating alerts.

 

This was the reasoning behind creating meaningful alerts in ESA to ensure the NetWitness admins have a view of the incidents which resulted in adding someone to the high risk users.

Outcomes