- PVSM.RU - https://www.pvsm.ru -
Скриншот собираемых данных:
Современные системы безопасности ОЧЕНЬ прожорливы до ресурсов. Почему? Потому что они считают больше, чем многие продакшн-сервера и системы бизнес-аналитики.
Что они считают? Сейчас объясню. Начнём с простого: условно первое поколение защитных устройств было очень простым — на уровне «пускать» и «не пускать». Например, файерволл пускал трафик по определённым правилам и не пускал трафик по другим. Естественно, для этого особая вычислительная мощность не нужна.
Следующее поколение обзавелось более сложными правилами. Так, появились репутационные системы, которые в зависимости от странных действий пользователей и изменений в бизнес-процессах присваивали им рейтинг надёжности по заранее заданным шаблонам и выставленным вручную порогам срабатывания.
Сейчас системы UBA (User Behavior Analytics) анализируют поведение пользователей, сравнивая их с другими сотрудниками компании, и оценивают логичность и правильность каждого действия сотрудника. Делается это за счёт Data Lake-методов и довольно ресурсоемкой, но автоматизированной обработки алгоритмами машинного обучения — в первую очередь потому, что прописывать все возможные сценарии руками занимает несколько тысяч человеко-дней.
Примерно до 2016 года прогрессивным считался подход, когда все события со всех сетевых узлов собираются в какое-то одно место, где стоит сервер аналитики. Сервер аналитики умеет собирать, фильтровать события и мапить их на корреляционные правила. Например, если вдруг начинается массовая запись файлов на какой-то рабочей станции, то это может быть признак вируса-шифровальщика, а может и не быть. Но уведомление админу система на всякий случай отправит. Если станций несколько, вероятность развёртывания зловреда повышается. Надо поднять тревогу.
Если пользователь постучался в какой-то странный домен, зареганный пару недель назад, а через пару минут пошла вся эта цветомузыка, то это почти точно вирус-шифровальщик. Надо тушить АРМ и изолировать сегмент сети, параллельно оповещая админов.
SIEM сопоставлял данные от DLP, файерволла, антиспама и так далее, и это позволяло очень хорошо реагировать на разные угрозы. Слабым местом были вот эти шаблоны и триггеры — что считать опасной ситуацией, а что нет. Дальше — как в случае с вирусами и разными хитрыми DDoS — специалисты SOC-центров стали формировать свои базы признаков атак. Для каждого типа атаки рассматривался сценарий, выделялись симптомы, к ним назначались дополнительные действия. Всё это требовало непрерывной доработки и донастройки системы в режиме 24 на7.
То есть почему нельзя обойтись без UBA? Первая проблема в том, что прописать руками всё невозможно. Потому что разные сервисы ведут себя по-разному — и разные пользователи тоже. Если прописать события для среднестатистического пользователя внутри компании, поддержка, бухгалтерия, тендерный отдел и админы будут очень выделяться. Админ с точки зрения такой системы — явно злонамеренный пользователь, потому что творит много и активно лезет в неё. Поддержка злонамеренна, потому что подключается ко всем подряд. Бухгалтерия передаёт данные по шифрованным тоннелям. А тендерный отдел постоянно сливает наружу данные компании при публикации документации.
Вывод — надо прописывать сценарии использования ресурсов для каждого. Потом глубже. Потом ещё глубже. Потом что-то меняется в процессах (а такое случается каждый день) и прописывать надо заново.
Было бы логично использовать что-то вроде «скользящего среднего», когда норма для пользователя определяется автоматически. К этому мы ещё вернёмся.
Второй проблемой стало то, что злоумышленники стали в разы аккуратнее. Раньше слив данных, даже если вы пропустили сам момент взлома, было довольно легко поймать — например, хакеры могли закинуть интересующий файл себе на почту или на файлообменник и в лучшем случае шифровали в архив, чтобы избежать обнаружения DLP-системой.
Сейчас всё интереснее. Вот что мы встречали в своих SOC-центрах за последний год.
Для проникновения обычно используют строго кастомную вирусню, сделанную прямо под юзеров компании-цели. Причём атаки часто идут через промежуточное звено. Например, сначала компрометируется подрядчик, а потом уже через него зловред заносится в основную компанию.
Вирусы последних лет почти всегда сидят строго в оперативке и удаляются при первом же шухере — акцент на отсутствие следов. Форензика в таких условиях очень затруднена.
Общий результат — SIEM плохо справляется. Много что уходит из поля зрения. Примерно так на рынке возникло пустое место: чтобы систему не надо было настраивать на тип атаки, а она сама понимала, что не так.
Первыми репутационными системами безопасности были модули антифрода для защиты от отмывания денег в банках. Для банка главное — выявить все мошеннические транзакции. То есть и немного перебдеть не жалко, главное, чтобы оператор-человек понимал, к чему нужно присмотреться в первую очередь. И не был перегружен совсем мелкими тревогами.
Работают системы так:
Про последнее поговорим подробнее.
Пример 1. Вы всю жизнь покупали себе пирожок и колу в Макдональдсе по пятницам, а потом внезапно купили на 500 рублей во вторник утром. Минус 2 балла за нестандартное время, минус 3 балла за нестандартную покупку. Порог срабатывания тревоги для вас установлен на –20. Ничего не происходит.
Примерно за 5-6 таких покупок вы эти баллы выведете в ноль, потому что система запомнит, что для вас зайти в Макдональдс во вторник утром — это нормально. Разумеется, я очень сильно упрощаю, но логика работы примерно такая.
Пример 2. Вы всю жизнь покупали себе разные мелкие штуки как обычный пользователь. То в продуктовом расплатитесь (система уже «знает», на какую сумму вы обычно едите и где чаще всего покупаете, — точнее, не знает, а просто пишет в профиль), то билет в метро купите на месяц, то закажете что-то небольшое через интернет-магазин. И вот вы покупаете рояль в Гонконге за 8 тысяч долларов. Могли? Могли. Давайте посмотрим на баллы: –15 за то, что это похоже на стандартный фрод, –10 за нестандартную сумму, –5 за нестандартное место и время, –5 за другую страну без покупки авиабилета, –7 за то, что вы раньше ничего не брали за рубежом, +5 за своё стандартное устройство, +5 за то, что другие пользователи банка там покупали.
Порог срабатывания тревоги для вас установлен на –20. Транзакция «подвешивается», в ситуации начинает разбираться сотрудник ИБ банка. Это очень простой случай. Скорее всего, минут через 5 он вам позвонит и скажет: «Вы правда решили купить в 4 утра что-то в музыкальном магазине в Гонконге за 8 тысяч долларов?» Если вы ответите утвердительно, вам пропустят транзакцию. Данные лягут в профиль как однажды совершённое действие, дальше за похожие действия будет даваться меньше отрицательных баллов, пока они вообще не станут нормой.
Как я уже говорил, я очень-очень упрощаю. Банки вкладывались в репутационные системы годами и годами же их оттачивали. Иначе куча мулов выводила бы деньги реально быстро.
На базе алгоритмов антифрода и защиты от отмывания денег появляются системы поведенческого анализа. Собирается полный профиль пользователя: как быстро печатает, к каким ресурсам обращается, с кем взаимодействует, какой софт запускает — в общем, всё то, чем пользователь занимается каждый день.
Пример. Пользователь часто взаимодействует с 1С и часто вносит туда данные, а потом вдруг начинает выгружать всю базу в десятках мелких отчётов. Его поведение выбивается за рамки стандартного поведения для такого пользователя, но его можно сравнить с поведением похожих профилей по типу (скорее всего, это будут другие бухгалтеры) — там видно, что у них в определённые числа наступает неделя отчётов и они все так делают. Числа совпадают, никаких других отличий нет, тревога не поднимается.
Ещё пример. Пользователь всю жизнь работал с файловой шарой, записывая пару десятков документов в день, а потом вдруг начал забирать с неё сотни и тысячи файлов. И ещё DLP говорит, что он отправляет что-то важное наружу. Может, тендерный отдел начал подготовку к конкурсу, может, «крыса» сливает данные конкурентам. Система этого, естественно, не знает, но просто описывает его поведение и подаёт тревогу безопасникам. Принципиально поведение нового сотрудника, техподдержки или гендиректора, может мало отличаться от поведения «засланного казачка», и задача безопасников сказать системе, что это нормальное поведение. Профиль всё равно приложится, и, если учётку гендиректора скомпрометируют и репутация попрыгает по баллам вниз, тревога поднимется.
Профили пользователей порождают правила для UBA-системы. Точнее, тысячи эвристик, которые регулярно меняются. Для каждой группы пользователей есть свои принципы. Например, пользователи этого типа отправляют 100 Мб в день, пользователи другого — 1 Гб в день, если это не выходные. И так далее. Если первый отправит 5 Гб, это подозрительно. А если второй — то будут отрицательные баллы, но порог тревоги они не пробьют. А вот если рядом он обращался по DNS к подозрительным новым доменам, то будет ещё пара отрицательных баллов и тревога уже случится.
Подход в том, что это не правило «если были странные DNS-запросы и потом подскочил трафик, то…», а правило «если репутация дошла до –20, то…» — каждый отдельный источник баллов для репутации пользователя или процесса независим и определяется исключительно нормой его поведения. Автоматически.
При этом на первых порах отдел ИБ помогает обучить систему и определить, что есть норма, а что нет, а потом система адаптируется, дообучается сама на реальном трафике и логах пользовательской активности.
Как системный интегратор мы предоставляем нашим заказчикам услугу по оперативному управлению информационной безопасностью (управляемый сервис SOC КРОК [1]). Ключевым компонентом наряду с такими системами, как Asset Management, Vulnerability Management, Security Testing и Threat Intelligence, доступными из нашей облачной инфраструктуры, является связка между классическим SIEM и проактивным UBA. При этом, в зависимости от пожеланий заказчика, для UBA мы можем использовать как промышленные решения крупных вендоров, так и нашу собственную аналитическую систему, основанную на связке Hadoop + Hive + Redis + Splunk Analytics for Hadoop (Hunk).
Для поведенческого анализа из нашего облачного SOC КРОК или по модели on premise доступны такие решения:
А для критичных сегментов, будь то АСУ ТП или ключевой бизнес-приклад, мы расставляем дополнительные сенсоры для сбора расширенной форензики и ханитопы для отвлечения внимания хакера от продуктивных систем.
Потому что пишутся все события. Это как Гугл Аналитика, только на локальном АРМ. В локальной сети события отправляются в Data Lake все, через интернет — метаданными о статистике и ключевыми событиями, но если оператор SOC хочет расследовать инцидент, записанный полный лог тоже есть. Собирается всё: временные файлы, ключи реестра, все запущенные процессы и их контрольные суммы, что прописано в автозагрузке, действия, скринкаст — что угодно. Ниже пример собираемых данных.
Список параметров с рабочей станции:
Системы по объёму хранилища и оперативке становятся на порядок сложнее. Классическая SIEM начинается с 64 ГБ оперативы, пары процессоров и хранилища на полтерабайта. UBA — это от терабайта оперативки и выше. Например, наше последнее внедрение было на 33 физических сервера (28 вычислительных нод для обработки данных + 5 управляющих нод для распределения нагрузки), озера на 150 ТБ (600 ТБ в железе, включая быстрый кэш на инстансах) и по 384 ГБ оперативной памяти.
В первую очередь тем, кто находится в «зоне риска» и постоянно подвергается атакам, — это банки, финансовые организации, нефтегазовый сектор, крупный ретейл и многие другие.
Для таких компаний стоимость утечки или потери данных может исчисляться десятками, а то и сотнями миллионов долларов. А вот установить у себя UBA-систему обойдётся куда дешевле. И конечно же, государственные компании и телеком, ведь никто не хочет, чтобы в какой-то момент данные миллионов пациентов или переписка десятков миллионов человек уплыла в открытый доступ.
Автор: D_Berezin
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/289395
Ссылки в тексте:
[1] SOC КРОК: http://service.croc.ru/soc/
[2] SOC-центры: https://habr.com/company/croc/blog/353324/
[3] Большая компания, которая 5 лет не занималась ИБ и выжила: https://habr.com/company/croc/blog/352044/
[4] Сайт проприетарных UBA-систем: https://www.anti-malware.ru/analytics/Market_Analysis/user-and-entity-behavioral-analytics-ubaueba
[5] Источник: https://habr.com/post/420293/?utm_campaign=420293
Нажмите здесь для печати.