I find myself spending more time on regex then using the platform

[RSAAdmin]

Seems I spend more time troubleshooting regexs instead of investigating events....for all the money spent on the tool its pretty primitive and time consuming to narrow the data down to what you want.

I figured simple things like ip.dst != 10.0.0.0/8 would simply work....or src.org !='org name" would work....

How about a better regex guide....I really dont have the time to figure out what works and what doesn't....

Scott,

[markd]

RegExLib.com Regular Expression Cheat Sheet (.NET Framework)

here is some regex.

However ip.src, ip.dst, etc are meta tags and not regex's.

The tool isn't difficult to use.

[RSAAdmin]

Scott,

Under ideal circumstances, where would you like such guidance presented within the interface? Regex can obviously be quite complex, so that has to be considered. I know right now you'd probably be happy with a cheat sheet, and I'll see what I can do to find such a beast. Ping me at  Michael.shreve@rsa.com

[RSAAdmin]

Welcome to the fundamental problem with "Big Data."  The problem isn't getting the data, the problem is making sense of it when you've got a lot of it - finding the needle in the haystack.  NW/SA is just a tool to help you make sense of it and hunt through the haystack, but it's not necessarily a "find evil" button.

As far as what isn't working, you'll have to be more specific.  ip.dst != 10.0.0.0/8 and src.org != 'org name' should both work fine as netwitness/SA queries -- but they just may take a long time to run given the configuration of your infrastructure (i.e. indexing) and the amount of data you're dealing with.  In fact there are timeouts built into the system for performance concerns so if those queries take long enough to run they may reach that timeout and be unceremoniously killed, leading to the impression that they "don't work."

Not-equals comparisons are very expensive, try to think about writing queries in a way that does equivalence comparisons to try to accomplish the same thing.  In other words, = is in general likely to be a lot faster than != when doing queries against the database (the same doesn't necessarily hold true if you're doing them in parsers or app rules).

[RSAAdmin]

Does this help?  

[RSAAdmin]

I have worked on SIEM and HADOOP for about 10 years. I have worked on envision, q1 and arcsight extensively. I didn't want to mention the dreaded "arcsight" word...but they have made it easy for filtering data quickly to get to the data you need. I don't want to play developer with a security platform, just have it do its job.

I do not want my analyst to go out and buy regex buddy to build the filter strings they want. The whole regex aspects just smacks of developer laziness. I want to drill and refine events in seconds without worrying about "will this regex work in this mode" or not.

The regexs work in some areas and not in others, perhaps its the web interface that's challenged, regardless. ip.src/ip.dst excluding rfc 1918 should work period overhead or not, or excluding orc.src/org.dst chained together should work. Why do I have spend a lot of hours figuring out which regex works in which instance. That's inconsistent behavior and doesn't belong in a SIEM platform. I have viewed comments across many of the blogs complaining about this behavior and RSA needs to address it.

[RSAAdmin]

I never use Regex.  I don't think you should either since it seems you havent mastered the standard query language and app rule interface/custom query just yet.

Excluding RFC 1918 addresses is easy.  For outbound traffic, it is org.dst exists.  For inbound traffic, its org.src exists.

To reiterate, I never use regex.  It's nice that it is available, but there has never been a use case that exists that cannot be addressed by using the standard query meta language.

[RSAAdmin]

Sorry, I do not mean regex, working on a problem while I am venting my frustration with the RSA interface, standard queries...or advanced as your interface calls them....

when you have 20 + orgs, and the query works "mostly" but not fully....I have a problem with that, please look at others in your forum struggling with standard queries NOT working. Suggesting work arounds to issues is skirting the problem, why are standard queries not working...

perhaps more importantly, you are totally missing my point, the interface is less than ideal. I have two major customers (not to mention a few dozen others) on RSA Envision. Do you really think I can recommend going to analytics with this interface? This is not 2002....I have had great hopes for so long and have been very patient. It seems we are taking steps backwards.

as for regex, try finding a dga...

[RSAAdmin]

Scott, I'm a product manager for Security Analytics. Specifically I'm the product manager for threat detection and intelligence. If you're feeling pain attempting to put together queries to assist you in looking for threats to your network, that absolutely concerns me. I'd like to be able to formally capture your specific pain points so we can make it less painful going forward. I get the general gist of functional inconsistency, but I'd much rather get as specific as I can in order to capture the necessary amount of information to formulate requirements against actual use cases.

[RSAAdmin]

I'd like to know why you think the standard queries do not work.  In other words, please give a specific example along with the results you are receiving that are incorrect.  Also, what version are you running?

For troubleshooting purposes, it would be even better if you could capture a NWD, pcap or log file that exhibits the problem with a specific session.

Thanks