В погоне за «неправильными» инцидентами, или Как мы строим Threat Hunting
Инциденты с SLA-таймингами должны детектироваться с минимальным числом False Positive, а также иметь четкий workflow обработки. При таком устройстве SOC гарантирует, что инцидент будет обработан за определённое время – для дальнейшего своевременного реагирования… Такой подход многие годы был справедлив для любого SOC (и нашего в том числе). Но в какой-то момент пришло осознание, что мы частично теряем полноту картины происходящего. Причина – в тех самых объективных ограничениях, накладываемых на сценарии. Ведь во множестве малорелевантных сработок (которые не могут быть обработаны на линиях мониторинга разумными ресурсами и в рамках SLA) порой таится самая соль происходящего инцидента.
Читать дальше →
Читать дальше →
Источник: Хабрахабр
Похожие новости
- Кастомные вордлисты для самых маленьких
- Думаем графами с IPAHound
- Rookee: Как писать FAQ, который будет процитирован ИИ
- Веб-интегратор “Компот”: Письмо от бывшего 💌 Почему реактивация клиентов не работает
- Broken Authentication (Skills Assessment) — HTB Academy
- Защищаем личные номера телефонов на маркетплейсах: соединяем клиента и исполнителя
- Spark_news: Минцифры выделило 40 млрд рублей на развитие видеоплатформы VK
- Теряет ли GitHub доверие индустрии?
- Почему ваша LLM-платформа — следующая цель: аудит безопасности AI-сервиса изнутри
- [Перевод] Пять документов ломают ваш RAG: где реальная уязвимость и что с ней делать