IBM Security QRadar

EPS Shuffling - In large QRadar distributed deployments, there are multiple event or flow processors where certain EPS is configured. However, during a spike or cyber incidents, if there is an increase, we need to manually adjust the EPS by redistributing it from other hosts. So, my point is, there should be some automation or logic to shuffle the EPS based on the spike and revert back to normal afterward.

Event or Flow Processor IO Error - In distributed environments, whenever there is an issue with the network connectivity between the console and event processor, or if the Event Processor is down due to some issue, the queries initiated by SOC users go into an error state, indicating an IO error. For this, IBM should build a simple option to temporarily disable the event processor without removing it from the deployment. This way, whenever the issue with the EP or network connectivity is fixed, it can be easily re-enabled. This is important because in large deployments, it's difficult to exclude all event processors one by one in searches.

Event Processor Removal - Referring to the above second point, since there is no option to mark the event processor or exclude it in the search, we need to remove it from the deployment. After removing it, the event processor stops processing events, which is not good for cyber investigations because we are losing logs.

EPS Shuffling - In large QRadar distributed deployments, there are multiple event or flow processors where certain EPS is configured. However, during a spike or cyber incidents, if there is an increase, we need to manually adjust the EPS by redistributing it from other hosts. So, my point is, there should be some automation or logic to shuffle the EPS based on the spike and revert back to normal afterward.

Event or Flow Processor IO Error - In distributed environments, whenever there is an issue with the network connectivity between the console and event processor, or if the Event Processor is down due to some issue, the queries initiated by SOC users go into an error state, indicating an IO error. For this, IBM should build a simple option to temporarily disable the event processor without removing it from the deployment. This way, whenever the issue with the EP or network connectivity is fixed, it can be easily re-enabled. This is important because in large deployments, it's difficult to exclude all event processors one by one in searches.

Event Processor Removal - Referring to the above second point, since there is no option to mark the event processor or exclude it in the search, we need to remove it from the deployment. After removing it, the event processor stops processing events, which is not good for cyber investigations because we are losing logs.