Коллеги, доброго времени суток. столкнулись с проблемой, с которой бьемся не одну неделю.
в сегменте корпоративной wi-fi сети при появлении нового сетевого устройства (в данном случае ноутбук) в KSC генерируется большое количество событий "Mac Spoofing Attack: conflicted ARP response" и "Mac Spoofing Attack: unexpected ARP response". 
Как появляется данная проблема:

1) На ноутбук устанавливается корпоративный образ ОС, тот же что используется и на стационарных ПК. в моменте подключения агента к KSC серверу начинается бурный поток критических событий, якобы данное устройство начинает атаковать другие ПК в wi-fi сегменте арп запросами. При этом в теле события указан ip и мак нового сетевого устройства (которые соответствуют данному ноутбуку), вот тело события:
 

Пользователь: user\user (Активный пользователь)    ------ пользователь wi-fi сети на которого производится атака. 
Компонент: Защита от сетевых угроз
Описание результата: Разрешено
Название: Mac Spoofing Attack: unexpected ARP response
Объект: ARP от неожиданного источника
Тип объекта: Сетевой пакет
Название объекта: ARP от неожиданного источника
Дополнительно:  
Подозрительный: 15.08.2023 9:14:45: b0-3c-dc-8c-90-bf -> 10.54.3.10      -------     адрес нового ноутбука в сети. 
Дата выпуска баз: 14.08.2023 4:09:00

2) Что предпринимали:

--- Пробовали прописать в меню базовая защита- сетевой экран доверенный диапазон wi-fi сети (события продолжают сыпаться).

--- Пробовали отключать чекбокс в политике агента касперского "сжимать сетевой трафик" (не помогло)
--- Пробовали отключать ноутбук. через некоторое время начинают сыпаться события, но уже якобы атакует другой ноут. 

Помог лишь перевод ноута из вайфай сети в локальную корпоративную сеть, подключив его через патчкорд. 
 

Рекомендации лаборатории касперского. Вдруг кому-то понадобиться. 
 

Зачастую, регистрация атак такого типа, это следствие особенностей сетевой инфраструктуры, топологии сети, протоколов, которые используются в тех или иных VLAN-ах (например, протокола повышения доступности маршрутизаторов (VRPP), когда вполне легитимно осуществляется подмена физического адреса шлюза виртуальным) и т.д.
 
В случае с событиями ‘Mac Spoofing Attack: unexpected ARP response’ всё несколько иначе и причина детектов очевидно уже другая. Чаще условно атакующими устройствами являются не компьютеры и не сетевые маршрутизаторы, а некоторое сетевое оборудование вроде принтеров (МФУ), NAS-ов, камер и т.д. Для таких устройств веерная рассылка по своему сегменту сети ARP-ответов может являться вполне штатным сценарием функционирования, на что и реагирует продукт. В практике неоднократно были случаи, когда такие устройства рассылали ARP-ответы на компьютеры в своей подсети, несмотря на отсутствие со стороны компьютеров ARP-запросов (и это соответствовало логике работы оборудования). Для целевых компьютеров получение ARP-ответов неожидаемо (mac_spoofing_reply_without_request), тогда продукт реагирует на это детектом с упоминанием ‘unexpected ARP response’ – т.е. запрос не отправлялся, а ответ пришел.
 
Также хочу отметить, что по умолчанию опция отслеживания MAC-спуфинга отключена в политике KES, так как целесообразно ее использование только в сетях, где могут быть подключаться сторонние клиенты, например сети торговых центров и.т.д. Или если сам хост выносят из изолированной сети в публичную, например, ноутбук выносят из офиса и подключают к публичному Wi-Fi.
 
Если ситуация не соответствуют вышеуказанными, то можно опцию просто отключить.

Такая же беда.

Массово регистрируются сообщения о MAC-спуффинге с двух разных ноутбуков с Windows.

Функция "Использовать случайные аппаратные адреса" в настройках WiFi на обоих устройствах отключена.

Сообщения фиксируются примерно раз в 5 минут. 
Чтобы ещё такое предпринять не отключая функцию слежения в политике?