quasar

Yeah, I can see a default rule requiring you to clone it before saving changes, but I've never experienced it changing to random values before. I hope they get that resolved for you.

That should reduce how frequently the rule triggers. The required behavior should now be that a source talks to a destination on unique destination ports at least 30 times in 10 seconds. Which is the kind of behavior you would expect from something scanning for open ports on a box. I would test it to make sure you like the…

No problem; glad it helped!

Right. So if you click the tiny square icon to the right of where it says "30 Events within 10 seconds" in the Correlation Time container, you'll see the definition for which events apply. In 5.5, they are as specified above: "10 TCPTrafficAudit events occurring within 10 seconds where the Source Machine is the same and…

Hi. If I understand correctly, you want the $User variable to give you the name of the user who created the group. Is this correct? If so, set the $User variable to the NewGroup.SourceAccount field. This will give you that information. You can also include NewGroup.SourceDomain in a different variable if you need to know…

Are you running this query within the LEM Console? If so, there is a DestinationPort field under the TCPTrafficAudit event that you can use. Locate the TCPTrafficAudit event and drag and drop the DestinationPort field into your conditions, either in the search builder window or on the search builder bar at the top of the…

Is this 5.5? It flags because, out of the box, the correllation on the rules that do PortScan inference isn't set up the way you would expect. If you find one of these rules (example: TCPTrafficAudit with possible TCP PortScan Inference) and click the gear on the Correlation box, you'll see that the only criteria is that…

If ServerA & ServerB are machines with agents, define them as the InsertionIP. Use an OR statement to grab data from both. For the latter part, I'm uncertain whether your text is going to end up as the EventInfo, ExtraneousInfo, etc. Force the event to occur, note the timestamp, then see how the manager parses it by using…

The "unusual" alerts (Unusual Traffic, UnusualIPTraffic, UnusualProtocol, UnusualICMPTraffic, UnusualTCPTraffic, UnusualUDPTraffic), in my environment, are almost always inferred alerts. Inferred alerts are generated by rules in response to some condition configured in that rule. For example, if you look at the Default…