This was an idea originally spawned by Sean Ennis so I have to give kudos to him for coming up with the original data set and link to the source data ...
NetWitness with the TLS parser (or any other parser that might write values into the crypto metakey) writes the crypto/cipher suites that are detected into this metakey, which makes it really easy to match up against a list of known good or bad suites to provide alerting or reporting on what is seen in the events.
So where to find a good, trusted source for weak cipher suites?
This site is a great reference to check your own browser cipher suites and provide a report card on what is presented and if legacy or weak suites are presented (potential downgrade attacks).
If you hop over to the GitHub page for this site you can locate this file which lists the weak cipher suites that can be used in a feed to match against what is see on the wire and provide additional alerting or reporting on what is detected.
With a little work in Notepad++ you can get a file as included in this post and create a matching xml file for feed deployment. Then deploy to your decoders (packet and log) and now you have the ability to create matching meta (in this case the xml points to
analysis.service = 'insecure_cipher_suites'
and more detailed reason of why in threat.desc
threat.desc='sweet32ciphersuites:uses 3des which is vulnerable to the swe...'
in this case matching this suite
The additional meta as well as direction or specific applications or workstation subnets can form the basis of additional alerts/meta or rules that can end up in IM/Respond for Triaging. Can also be an Ops report to provide locations where weak suites are being used (maybe a legacy internal app is requesting them or legacy browsers on unmanaged devices)
which can also be used in addition to the other serivce analysis keys to look for addities in the properties of TLS traffic that might give you further reason to look at the source or destination of the traffic.