Question on ESA metakey types

[JoshuaCole1]

Hello, I was curious about an issue I ran into while writing a custom rule for a Netwitness packets deployment. Rather than including destination ports and protocols, I was trying to filter on the metakey "service". However, I realized that while the Esper engine requires a long type value (like 80), the JSON output returns "service" as a string (like 'HTTP').

Is there a way around this? This isn't a huge deal for the rule I'm writing, but I thought it was an interesting problem and I couldn't find anything about it in the KBs or blogs. Thanks for any suggestions!

[JoshRandall]

What method are you using to view/output the raw alert details?

In my lab (v 11.5.3.1), I am not seeing the service alias names in the alert details (left is the raw alert within Respond, right is the raw alert written to disk):

[JoshuaCole1]

We're running 11.5.0, and I'm just exporting meta from the Event Viewer, and pasting it into the ESA test window. That's where I get the error about the type mismatch.  (you can see it does the same thing to "ip.proto")

[JoshRandall · Accepted solution]

Hmm...interesting...

Those aliases are set and controlled by the service index XMLs, and are intended to allow for easier understanding of various content (e.g.: some folks might not immediately understand what service=80 means, but they'll understand what service=HTTP means).

That said, I don't believe those content exports should be maintaining the alias'd names in their outputs, especially since we intend some outputs to be used in the other NW features, like the ESA testing window.

[JoshuaCole1]

So would my rules work if I just specify the service as an integer, even though the alias is a string?

[JoshRandall · Accepted solution]

Yup, thats correct.

[JoshuaCole1]

Okay, sweet! I'll just remember to modify the exported meta when I'm testing. Thank you!