Best Practices for System Health

[RenatoGoncalves]

I was reading Best Practices for System Health and i found this:

"Configure the alerts database to maintain a healthy level of alerts. ESA uses MongoDB to store alerts. If the MongoDB becomes flooded with alerts, it can slow or stop the database. To ensure your database maintains a healthy level of alerts, configure settings to clear out alerts regularly. To do this, see "Configure ESA Storage" in the Event Stream Analysis (ESA) Configuration Guide."

After that o start reading the Configuration Guide for ESA and i saw this:

ESA Config: Configure ESA Storage 

But in the link the way to configure MongoDB is:

• Log on to Security Analytics as admin.
• In the Security Analytics menu, select Administration > Services.
• Select the ESA service, then  View > Explore.
• On the left, select Alert > Storage > maintenance.

And when i go to Administration > Services > View > Explore > Alert in the left panel there is no Storage option.

Where can i find it in this version?

[JohnKisner]

Renato,

That document is for 10.6 according to the breadcrumbs at the top of the page. What version of Netwitness are you currently running? 

[RenatoGoncalves]

We are currently running 11.1

And i cant found anything that leads me there. I downloaded a PDF for this version and i can't found where to go 

[JohnKisner]

Renato,

I'm seeing the same thing in our lab as well as in 11.2. I've sent an email to one of our Continued Engineering team to see if these options are no longer needed in 11.x or if they have been moved to another location. I'm unsure how fast I will get a response but I will update this post as soon as I get one. Please allow until at least Tuesday of next week.

[JohnKisner]

Renato,

I received a reply back from Continued Engineering. In 11.x alerts are no longer stored in ESA, thus the reason there is no storage maintenance. Instead the alerts are sent to the Respond service. Technically they are still on the ESA appliance as that is where the mongo database is for the Respond service however the Respond service is responsible for the maintenance. You can go into the Respond's service explore view to see what the data retention is.

Go to Administation -> Services -> Respond Server -> Explore -> respond/dataretention

Inside the above node you will see 4 nodes:

- enabled

- execution-hour

- frequency

- retention-period

By default I believe the data retention is turned off. So you will need to change enabled from false to true. The execution hour is the 24 hour clock so the default of 0 is midnight. Frequency is set to every 24 hours  and the retention-period is 30 Days. So once you enable the retention it would run once a day at midnight and remove any alerts older than 30 days.

Remember when dealing with retention and keeping things healthy, this retention does not take into account alert bursts. So if you have a rule that produces a very large amount of alerts over a very short period of time the retention process won't catch it and keep your database healthy until it hits the retention parameters outlined above. This is why it is very important that any new rules that are created are set as trial rules with limitations set until you are certain of how it is going to perform.

I hope this helps.

[RenatoGoncalves]

Hello John,

Thanks for the help. 

Im trying to undertstand why our NW sometimes retains incidents and alerts. We are testing it with some port scans and it doesn't appear. After we restart ESA and Server we start recevieng a lot of them...Maybe the retention type will help

[JohnKisner]

Renato,

I see you have opened up a support case around the ESA alerts/incidents. Please work with your support engineer on the ESA alerts/incidents not appearing. Once the resolution has been determined it may be good to come back here and put what you found to help out anyone else who may experience the issue in the future.

Were you able to set the retention per my instructions above?

[RenatoGoncalves]

We had John.

I will