Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2019 > October

19DEC2019 Update:

Modified the original ESA rule (ja3context.txt) with additional/better logic to match destination port numbers between the Endpoint and Network sessions. Additionally, I recommend disabling the "Alert" option in the rule, as this can be a noisy alert and might unnecessarily clutter your incident and alert queues; please note that disabling this will NOT prevent the script notification output, it will only stop an alert from being sent to Respond.


Also added a different ESA rule (ja3window.txt) that does the same thing, but instead of relying on a script to produce a finalized list, the results with the linked JA3 fingerprint and application information are held in a Named Window - ja3curated; this approach might be better if a Feed is not a desired outcome, but you still want to be able to use the JA3/Application context for other ESA alerting.




A couple years ago, a few smart folks over at salesforce came up with the idea of fingerprinting certain characteristics of the "Client Hello" of the SSL/TLS handshake, with the goal to more accurately identify the client application initiating TLS-encrypted sessions.


This concept certainly has potential to provide invaluable insight during incident response, though there are some significant operational limitations that (my opinion) have so far prevented JA3 fingerprinting from gaining more widespread adoption and use.  Perhaps the biggest of these limitations is the need for some kind of known JA3 fingerprint library or repository, where the thousands (?potentially millions?) of client applications that might initiate a TLS handshake can be reliably matched with their JA3 fingerprint. There are a couple sites building out these repositories


...but their content is limited (after all, fingerprinting a client requires installing it, running it, capturing the PCAP, running a JA3 parser or script against the PCAP, and then adding that fingerprint to the library; that process simply does not scale) and the fidelity/accuracy/timeliness of these libraries is a pretty large question mark.


However, with NetWitness 11.3.1, which has a native option to enable JA3 and JA3S fingerprinting, and NetWitness Endpoint 11.3 we can bridge this gap and create our own JA3 libraries.


The concept is fairly simple

  • use NetWitness Endpoint to identify applications making outbound network connections
  • use NetWitness Network to identify outbound HTTPS traffic
  • link these events and sessions by their common characteristics
  • once we have that link
    • extract the filename and sha256 hash of the application from the NetWitness Endpoint event
    • along with the JA3 fingerprint from the network session
    • and then create a feed of that information that the NetWitness Platform can use for additional context


In order to ensure this process scales, we can make use of the ESA's rule engine to identify the sessions we want and it's script output functionality to create the feed for us. The ESA rule and python script output are attached to this blog.


Prior to enabling these, you'll want to make sure the "netwitness" user has either read/write access to the "/var/netwitness/common/repo" directory on the Admin Server, a.k.a Node0, or at least read/write access to the "ja3Context.csv" file in that directory that the script will update.


A good guide for setting ACLs in CentOS is here:  and the result:


Once the appropriate permissions are set and you've enabled the ESA rule and its script output, your last step will be to turn that CSV output into a feed (A list two ways - Feeds and Context Hub - many thanks again to the SE formerly known as Eric Partington for this blog):


...and choose your meta keys:


And voila!  We have an automatically generated and constantly updating library of applications for our JA3 fingerprints:

Today RSA Link implemented a new way of presenting documentation to help RSA NetWitness® Platform customers find the information they need quickly and easily. RSA NetWitness Platform 11.3 presents the documentation in a unified map of product documentation and videos, including software, hardware, and RSA content.


The new RSA NetWitness® Platform 11.3 Documentation page


The blocks represent a high-level workflow, each block a task for different RSA NetWitness® Platform activities. For example, an Incident Responder would click the “Investigate and Respond” block. Clicking a block opens a list of tasks for the selected category with quick links to product information.


Instead of searching through a list of document titles that may have the information you need, you can select one of the high-level tasks—Get Started, Install & Upgrade, Configure & Manage, Investigate & Respond, or Integrate & Develop—and see a list of the relevant information.


The widgets on the right provide direct links to:

  • The Master Table of Contents with quick links to every Version 11 document.
  • The Known Issues page with a sortable list of known issues.
  • The Troubleshooting page with information to help resolve issues from diverse RSA Link resources.
  • The Documentation Feedback email sends feedback and suggestions to the Information Design and Development team responsible for RSA NetWitness® Platform technical content.


Please click the Documentation Feedback under Other Resources on the right to provide your comments. We hope you find this new page useful and appreciate your comments.

One of the biggest commitments we at RSA make to our customers is to provide best-in-class security products that help manage digital risk.  Our goal is to do so with maximum reliability while also requiring minimum effort on your part.  However, we know, that even best-in-class products occasionally need help to install, use, and maintain them.  While we are continuously focused on improving our support services to ensure that every interaction you, our customers, have with us is positive and quick, we realize that even the best support interaction still requires time and effort on your part.  And what’s more valuable than time?


With that in mind, today I am happy to officially launch our Engineering Request dashboard within the RSA Case Management portal, which will allow you to monitor progress of Engineering Requests (ER) opened on your behalf*.  Not only will you be able to see progress of your ER’s, but you will be able to do so on your own, without the need to call support for an update. 


To access this information, navigate to the RSA Case Management portal by clicking on My Cases in the main menu on RSA Link.    Clicking on the Engineering Requests tab will display Engineering requests that have been opened on your behalf (linked to your support cases) since January 1, 2018.  For each of these, you will be able to see its Status to know when the issue has been addressed, and if a fix is included in a release, you’ll see the release number as well.


Click to enlarge


This is just another small improvement to your support experience.  Stay tuned for the more exciting upcoming changes.


In the meantime, if you have any feedback on this enhancement or other ideas to continue to improve your experience, please share! 


* This functionality is currently only available for the RSA Archer Suite and the RSA NetWitness Platform. Additionally, you will only be able to monitor Engineering Requests that were opened directly on your behalf and are not security issues that could have sensitive information.  We will encourage you to utilize the RSA Ideas portal to manage and monitor Enhancement requests.

Filter Blog

By date: By tag: