Examining Threat Aware Authentication in v11.3

[JoshRandall]

One of the features included in the RSA NetWitness 11.3 release is something called Threat Aware Authentication (Respond Config: Configure Threat Aware Authentication).  This feature is a direct integration between RSA NetWitness and RSA SecurID Access that enables NetWitness to populate and manage a list of potentially high-risk users that SecurID Access can then refer to when determining whether (and how) to require those users to authenticate.

The configuration guide above details the steps required to implement this feature in the RSA NetWitness Platform, and the relevant SecurID documentation for the corresponding capability is here: Determining Access Requirements for High-Risk Users in the Cloud Authentication Service.

On the NetWitness side, to enable this feature you must be at version 11.3 and have the Respond Module enabled (which requires an ESA), and on the SecurID Access side, you need to have Premium Edition (RSA SecurID Access Editions - check the Access Policy Attributes table at the bottom of that page).

At a high level, the flow goes like this:

1. NetWitness creates an Incident
2. If that Incident has an email address (one or more), the Respond module sends the email address(es) via HTTP PUT method to the SecurID Access API
3. SecurID Access checks the domains of those email addresses against its Identity Sources (AD and/or LDAP servers)
4. SecurID Access adds those email addresses with matching domains to its list of High Risk Users
5. SecurID Access can apply authentication policies to users in that list
6. When the NetWitness Incident is set to Closed or Closed-False Positive, the Respond module sends another HTTP PUT to the SecurID Access API removing the email addresses from the list

In trying out these capabilities, I ended up making a couple tools to help report on some of the relevant information contained in NetWitness and SecurID Access.

The first of these is a script (sidHighRiskUsers.py; attached at the bottom of this blog) to query the SecurID Access API in the same way that NetWitness does.  This script is based on the admin_api_cli.py example in the SecurID Access REST API tool (https://community.rsa.com/docs/DOC-94122).  That download contains all the python dependencies and modules necessary to interact with the SecurID API, plus some helpful README files, so if you do intend to test out this capability I recommend giving that a look.

Some usage examples of this script (can be run with either python2 or python3 or both, depending on whether you've installed all the dependencies and modules in the REST API tool):

Show Users Currently on the High Risk List

# python highRiskUsers.py -f /path/to/SIDAccess/API.key -o getHighRiskUsers -u "https://<URL_of_your_SID_Access_Cloud_Console_API>"

Add  Users to the High Risk List

# python highRiskUsers.py -f /path/to/SIDAccess/API.key -o addHighRiskUsers -u "https://<URL_of_your_SID_Access_Cloud_Console_API>" -e <single_or_multiple_email_address>

**Note: my python-fu is not strong enough to capture/print the 404 response from the API if you send a partially successful PUT.  If your python-fu is strong, I'd love to know how to do that correctly.

Example - if you try to add multiple user emails and one or more of those emails are not in your Identity Sources, you should see this error for the invalid email(s):

Remove Users from the High Risk List

# python highRiskUsers.py -f /path/to/SIDAccess/API.key -o removeHighRiskUsers -u "https://<URL_of_your_SID_Access_Cloud_Console_API>" -e <single_or_multiple_email_address>

*Note: same as above about a partially successful PUT to the API

The second tool is another script (nwHighRiskUsersReport.sh; also attached at the bottom of this blog) to help report on the NetWitness-specific information about the users added to the High Risk list, the Incident(s) that resulted in them being added, and when they were added.  This script should be run on a recurring basis in order to capture any new additions to the list - the frequency of that recurrence will depend on your environment and how often new incidents are created or updated.

The script will create a CEF log for every non-Closed incident that has added an email to the High Risk list, and will send that log to the syslog receiver of your choice.  Some notes on the script's requirements:

1. must be run as a superuser from the Admin Server
2. the Admin Server must have the rsa-nw-logplayer RPM installed (# yum install rsa-nw-logplayer)
3. add the IP address/hostname and port of your syslog receiver on lines 4 & 5 in the script
4. If you are sending these logs back into NetWitness:
   1. add the attached cef-custom.xml to your log decoder or existing cef-custom.xml (details and instructions here: Custom CEF Parser)
   2. add the attached table-map-custom.xml entries to the table-map-custom.xml on all your Log Decoders
   3. add the attached index-concentrator-custom.xml entries to the index-concentrator-custom.xml on all your Concentrators (both Log and Packet)
   4. restart your Log Decoder and Concentrator services
   5. **Note: I am intentionally not using any existing email-related metakeys in these custom.xml files in order to avoid a potential feedback loop where these events might end up in other Incidents and the same email addresses get re-added to the High Risk list
5. Or if you are sending them to a different SIEM, perform the equivalent measures in that platform to add custom CEF keys

Once everything is ready, running the script:

And the results:

------

sidHighRiskUsers.py.zip

CustomMetaFiles.zip

[ChadCaldwell]

What log sources feed the threat aware authentication use case? 

[JoshRandall]

This capability is not limited to a particular log or data source; any data (log event, network traffic, endpoint activity) regardless of source that has a valid email address will feed the threat aware authentication use case.

[CalvinNg]

Hi Josh,

This is a great demo to present the idea of Threat Aware Authentication. Does Threat Aware Authentication still work in OpenID Connect or SAML 2.0 integration with AzureAD or ADFS? For example, the user is going through AzureAD or ADFS portal to sign-in the application then redirects to SecurID Access to trigger multi-factor authentication. Do we need to create the correlation rule (ESA) with the AzureAD portal or ADFS?

[JoshRandall]

Hi Calvin,

  As long as authentication and access to the application are being managed by SecurID policies, the application itself shouldn't make any difference in this use case.

[MohamedShawara]

Hi Josh,

Do we have any demonstration video to show it to the clients for this feature?

[JoshRandall]

Check out Kelly Ahlers‌ blog to see what this can look like: https://community.rsa.com/community/products/netwitness/blog/2020/04/29/operationalizing-threat-aware-authentication 

[EnsignCalvinNg]

Hi RSA team,

Strongly recommend putting the RSA official integration into the marketplace of Cortex XSOAR. This use case is great for existing RSA SecurID users and it would enhance and benefit the existing RSA users of SOAR technology.

Calvin

[LeeMccotter]

To run sidHighRiskUsers.pym using python 3, you will likely need to install: pyjwt & python-dateutil

# pip3 install pyjwt[crypto]
# pip3 install python-dateutil

If you obtain the following error when using python 3

# python3 sidHighRiskUsers.py
Traceback (most recent call last):
  File "sidHighRiskUsers.py", line 261, in <module>
    main()
  File "sidHighRiskUsers.py", line 245, in main
    token = generate_token(args)
  File "sidHighRiskUsers.py", line 91, in generate_token
    return jwt.encode(jwt_claims, key["accessKey"], algorithm="RS256").decode("utf-8")
AttributeError: 'str' object has no attribute 'decode'

 You will need to change line 91 in sidHighRiskUsers.py to remove the last decode function call (as output is already in UTF-8).

FROM: 

    return jwt.encode(jwt_claims, key["accessKey"], algorithm="RS256").decode("utf-8")

TO:

    return jwt.encode(jwt_claims, key["accessKey"], algorithm="RS256")

Tested on RSA NetWitnesss Platform v11.6.0

Python v3.6.8

# pip3 list --format columns
Package Version
------------------- ---------
asn1crypto          1.4.0
certifi             2021.10.8
cffi                1.15.0     <-- cffi>=1.12 requirement for cryptography
chardet             4.0.0
charset-normalizer  2.0.11
cheroot             8.6.0
CherryPy            18.6.1
contextvars         2.4
cryptography        36.0.1     <--
distro              1.6.0
idna                3.3        <-- idna<4,>=2.5 for requests
immutables          0.16
importlib-resources 5.4.0
jaraco.classes      3.2.1
jaraco.collections  3.4.0
jaraco.context      4.1.1
jaraco.functools    3.4.0
jaraco.text         3.7.0
Jinja2              3.0.3
M2Crypto            0.35.2
MarkupSafe          2.0.1
more-itertools      8.12.0
msgpack             1.0.3
pip                 21.3.1
ply                 3.11
portend             3.0.0
psutil              5.9.0
pycparser           2.21       <-- pycparser>=2.06 for cffi
pycryptodomex       3.14.1
pycurl              7.43.0
PyJWT               2.3.0      <-- directly referenced in script (import jwt)
pyOpenSSL           22.0.0     <--
PySocks             1.7.1
python-dateutil     2.8.2      <-- directly referenced in script (import dateutil.parser)
pytz                2021.3
PyYAML              3.13       <--
pyzmq               17.0.0     <--
requests            2.27.1     <-- directly referenced in script (import requests)
rpm                 4.11.3
salt                3004
setuptools          59.6.0
six                 1.16.0     <-- six>=1.5 for python-dateutil
tempora             4.1.2
typing_extensions   4.0.1
urllib3             1.26.8     <-- urllib3<1.27,>=1.21.1 for requests
wheel               0.37.1     <--
zc.lockfile         2.0
zipp                3.6.0