Вообще-то, ping-флуд может вообще не относиться к какому-то определенному приложению, а быть направленным на различные порты с целью отказа сетевого оборудования.
Поэтому не надо переживать сильно: файервол есть, он работает, блокирует атаки, так что паранойя здесь, как мне кажется, лишняя)

Такая ситуация может быть, когда есть, например, домашняя локальная сеть.
А если ее нет, значит, кто-то проводит сканирование ваших портов, что в этом удивительного, когда были данные, что на планете под 500 млн. инфицированных компьютеров?!
Атаки отражаются - это главное.

Ну, режим на основе политики блокирует все соединения, не удовлетворяющие ни одному из ранее определенных разрешающих правил. Т.е. если правило не создано, а соединение необходимо, то оно будет блокироваться.
Вообще, "Временно запретить" должно было бы, по идее, работать.
Тут интересен и протокол соединения: GRE & ESP.

Желательно вставить сюда скриншот уведомления с расширенными параметрами.

На входящее соединение от System?!
Не советовал бы.
Ясное дело, что не видели, а входящие соединения для System теперь разрешены, что совсем небезопасно.

А почему нельзя "Временно запретить"?!

Вообще, конечно, нельзя с этим не согласиться.
Но... есть у меня подозрения, что в ESET проблема не столько с идеями и их реализацией, сколько идет борьба с имеющимся кодом. Не знаю, сколько кода осталось с 3-ки/4-ки, но есть подозрения, что:
1) или слишком много кода изменено, и тогда понятно, что нужно было снова отловить пачки старых багов и что придется еще столько же исправлять новые,
2) или слишком мало кода изменено, и тогда, если реализация не достаточно объектно-ориентированная, то в будущем придется столкнуться с массой проблем при реализации той или иной функциональности.
Может быть, я неправ, и код полностью объектно-ориентированный, и интерфейс максимально отделен от бизнес-логики, но тогда функциональность "Завершить процесс; Передать файл на анализ в ESET; Проверить файл на VirusTotal по sha1; Открыть папку с файлом" у более-менее профессиональных программистов реализуется максимум за пару часов.

И не говори)
Сколько мы тогда понаписывали в предложениях, а сколько было реализовано. Хотя такими темпами есть шанс в 6-ке наконец увидеть песочницу)
Хотя, конечно, нужно признать, что HIPS таки сделали очень приличным. Другое дело, что появились баги с WebMoney, роутерами и т.п., но все-таки есть надежда, что эти баги будут постепенно исправляться.

Если в версии 4.2 все работает, то, действительно, похоже на недоработки в пятерке.
Можно написать о данной проблеме в официальную службу поддержки.

Тут, насколько я помню, была отдельная ветка про настройку HIPS.
Но все-таки пару слов скажу здесь)
На самом деле, сценариев работы с HIPS может быть сколько угодно: все здесь упирается в собственную фантазию и понимание работы ПК.
На мой взгляд, для обеспечения максимальной безопасности можно воспользоваться следующим методом.
При этом подразумевается, что под систему выделяется отдельный раздел, а на всех остальных разделах хранятся пользовательские данные.
В HIPS же создается правило в разделе "Конечные файлы" для всего системного раздела (или, по крайней мере, для всей директории Windows) для всех операций с действием "Запросить", и далее в течение нескольких дней стоит усиленно поиспользовать программы, чтобы настроить разрешающие правила для тех или иных приложений, чтобы постоянно не отвлекаться на простые запросы.
Ну, и лучше создать правила с тем же действием "Запросить" для основных веток реестра, таких как:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion­\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion­\Policies\System
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\­Policies\System
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\­Policies\Explorer
Можно и другие ветки сюда добавить: справочников по реестру Windows хватает.
При таких настроенных правилах при всяких подозрительных действиях будет выдаваться запрос, и пользователь сможет сам определять необходимость того или иного действия.