cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
456
Views
0
Helpful
2
Replies

Alerts are LOST somewhere in Action Override Stage...

ovt
Level 4
Level 4

I have very, very strange statistics on my sensor. I cleared it few minutes ago and now it is as follows:

SigEvent Preliminary Stage Statistics

Number of Alerts received = 60

Number of Alerts Consumed by AlertInterval = 0

Number of Alerts Consumed by Event Count = 0

Number of FireOnce First Alerts = 0

Number of FireOnce Intermediate Alerts = 0

Number of Summary First Alerts = 8

Number of Summary Intermediate Alerts = 43

Number of Regular Summary Final Alerts = 8

Number of Global Summary Final Alerts = 0

Number of Active SigEventDataNodes = 10

Number of Alerts Output for further processing = 60

SigEvent Action Override Stage Statistics

Number of Alerts received to Action Override Processor = 60

Number of Alerts where an override was applied = 0

Actions Added

deny-attacker-inline = 0

deny-attacker-victim-pair-inline = 0

deny-attacker-service-pair-inline = 0

deny-connection-inline = 0

deny-packet-inline = 0

modify-packet-inline = 0

log-attacker-packets = 0

log-pair-packets = 0

log-victim-packets = 0

produce-alert = 0

produce-verbose-alert = 0

request-block-connection = 0

request-block-host = 0

request-snmp-trap = 0

reset-tcp-connection = 0

request-rate-limit = 0

SigEvent Action Filter Stage Statistics

Number of Alerts received to Action Filter Processor = 0

Number of Alerts where an action was filtered = 0

Number of Filter Line matches = 0

Number of Filter Line matches causing decreased DenyPercentage = 0

Actions Filtered

deny-attacker-inline = 0

deny-attacker-victim-pair-inline = 0

deny-attacker-service-pair-inline = 0

deny-connection-inline = 0

deny-packet-inline = 0

modify-packet-inline = 0

log-attacker-packets = 0

log-pair-packets = 0

log-victim-packets = 0

produce-alert = 0

produce-verbose-alert = 0

request-block-connection = 0

request-block-host = 0

request-snmp-trap = 0

reset-tcp-connection = 0

request-rate-limit = 0

SigEvent Action Handling Stage Statistics.

Number of Alerts received to Action Handling Processor = 1

Number of Alerts where produceAlert was forced = 0

Number of Alerts where produceAlert was off = 0

Actions Performed

deny-attacker-inline = 0

deny-attacker-victim-pair-inline = 0

deny-attacker-service-pair-inline = 0

deny-connection-inline = 0

deny-packet-inline = 0

modify-packet-inline = 0

log-attacker-packets = 0

log-pair-packets = 0

log-victim-packets = 0

produce-alert = 1

produce-verbose-alert = 0

request-block-connection = 0

request-block-host = 0

request-snmp-trap = 0

reset-tcp-connection = 0

request-rate-limit = 0

Per-Signature SigEvent count since reset

Sig 60000.0 = 1

Yes, single signature fired, but the number of "Preliminary Stage Alerts" was 60 !? What happened with other 59 alerts ???

1 Accepted Solution

Accepted Solutions

marcabal
Cisco Employee
Cisco Employee

Only when the alert has at least one action will it be passed to the event action handler.

So the other 59 alerts did not have any event action. Either no action was added directly from the signature definition, or the alerting type actions were removed because of summarization, or the actions were removed by filters.

There are several signatures that are intentionally created without actions. These signatures are what we call meta component signatures. On their own they don't mean much and so we remove all actions and they do not generate alerts into the eventstore. They trigger internally in sensorApp but do not get written to the eventstore. These alerts are internally monitored by Meta signatures. When multiple component signatures are triggered, then a Meta signature may trigger and it is the Meta signature that would have a produce-alert event action and be written to the eventStore.

With summarization the signature has a produce-alert action, but the summarizer routines see that the signature is being triggered multiple times with same addresses. The summarizer will allow through an alert on the first triggering. Later triggerings with the same address set will cause the summarizer to automatically remove the produce-alert action (and other alert causing actions). So the summarized alerts will not get written to the eventStore.

NOTE: In your output this happened for at least 43 of these alerts.

Filters may also be matching the alerts, and the filters may be removing the event actions.

So if the event actions have all be removed (or none were ever added), then the alert will not be passed to the event action handler.

In your output only 1 of the 60 alerts wound up with any actions needing to be executed.

View solution in original post

2 Replies 2

marcabal
Cisco Employee
Cisco Employee

Only when the alert has at least one action will it be passed to the event action handler.

So the other 59 alerts did not have any event action. Either no action was added directly from the signature definition, or the alerting type actions were removed because of summarization, or the actions were removed by filters.

There are several signatures that are intentionally created without actions. These signatures are what we call meta component signatures. On their own they don't mean much and so we remove all actions and they do not generate alerts into the eventstore. They trigger internally in sensorApp but do not get written to the eventstore. These alerts are internally monitored by Meta signatures. When multiple component signatures are triggered, then a Meta signature may trigger and it is the Meta signature that would have a produce-alert event action and be written to the eventStore.

With summarization the signature has a produce-alert action, but the summarizer routines see that the signature is being triggered multiple times with same addresses. The summarizer will allow through an alert on the first triggering. Later triggerings with the same address set will cause the summarizer to automatically remove the produce-alert action (and other alert causing actions). So the summarized alerts will not get written to the eventStore.

NOTE: In your output this happened for at least 43 of these alerts.

Filters may also be matching the alerts, and the filters may be removing the event actions.

So if the event actions have all be removed (or none were ever added), then the alert will not be passed to the event action handler.

In your output only 1 of the 60 alerts wound up with any actions needing to be executed.

I've got it. It was 1315.0 which has no actions by default. Thank you.

Review Cisco Networking products for a $25 gift card