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.
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:
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
Policy
Rule set
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.
When Brett navigates to an app, he is presented with a logon screen with his password:
Since he is low risk, after a successful authentication with User ID and password, he is now logged in to the demo app.
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.
We simulated a few failed logins to create an incident:
Back in the SecurID Cloud Authentication Service, you can see that Brett has been added to the high risk users
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.
5 Comments
