Сегодня мы сделаем для вас обзор ежедневных обязанностей аналитика информационной безопасности. Его работа – это, по сути, постоянный анализ необработанных данных из
разнородных источников событий (информационной и сетевой) безопасности для поддержания (и желательно) повышения уровня безопасности организации. Это не всегда конкретные практические действия, но, как правило, они включают в себя агрегацию данных из многих возможных источников: журналы событий операционных систем, брандмауэров, маршрутизаторов, антивирусных сканеров и многое другое. Затем ему требуется объединить
или сопоставить их для получения набора данных, который может быть обработан с помощью соответствующих алгоритмов.
Содержание
- Аналитика безопасности в деталях
- SIEM против ИБ-аналитика
- Практические примеры
- Преимущества ИБ-аналитика
- UBA или аналитика поведения пользователей
- Как визуализировать аналитику безопасности: панели мониторинга и модели угроз
Аналитика безопасности в деталях
Трудная часть профессии ИБ-аналитика заключается в том, чтобы найти в пресловутом стоге сена текущие активные угрозы. И более того, выйти за рамки текущей угрозы, чтобы увидеть и проанализировать картину целиком. А в результате заблокировать все подобные ей угрозы или же придумать разовый, но действенный ответ.
Для того, чтобы сделать это правильно, важно сразу определиться с типом требуемого анализа, а также выделить конкретные события, на которых вы будете сосредоточены в данном расследовании.
Такова аналитика информационной безопасности с высоты птичьего полета.
Теперь давайте поговорим о системах Управления Событиями Информационной Безопасности (Security Information and Event Management), или SIEM. Это, по сути, то же самое, что я описал выше – обработка журналов событий, в основном из логов операционных систем, сетевых устройств и других инструментов безопасности и их последующий совмещенный анализ. По завершении анализа используется классическая матстатистика для того, чтобы исходные данные могли быть достоверно интерпретированы людьми.
Чтобы получить представление о том, как выглядит работа с журналами событий, вы можете взглянуть на события операционной системы Windows, открыв Event Viewer на своих ноутбуках:
Вот она рутина низкоуровневых событий Windows – все не так уж и волшебно!
Здесь есть возможность прокручивать тысячи и даже десятки тысяч системных событий и событий безопасности: запуск и завершение процессов, блокировки учетных записей, выполнение команд PowerShell и т.д. А теперь представьте, что должна сделать SIEM: объединить, а затем найти корреляции между этими событиями операционной системы и событиями, захваченными с сетевых устройств и других систем безопасности, и, наконец, показать нам на основании этого какой-то смысл!
В качестве небольшого примера давайте предположим, что вы хотите отследить удаление важного файла. Возможно также, что это удаление, когда оно коррелирует с другими событиями, будет указывать на реальную атаку. Для ИТ-специалиста, который не знаком с SIEM, это могло бы показаться совсем простой задачей: просто найти
в журнале событий Windows событие удаления, связанное с этим файлом:
О, нет! Событие удаления Windows (номер события 4660) не содержит имени файла!
К сожалению, если вы посмотрите на событие удаления файла Windows, в нем отсутствует одна важная информация: имя и путь до файла.Как же нам тогда определить имя файла, связанного с событием удаления в логе Windows?
SIEM против ИБ-аналитика
Это нелегко, потому что эта информация размазана по нескольким записям журнала. Вам придется сопоставить событие 4660 удаления с другим, событием 4663 доступа к объекту. На практике вы скорее всего зададите поиск по этим двум событиям 4660 и 4663, а затем объедините информацию из них, чтобы получить внятную картину. И, кстати, на случай если вы не в курсе, включение аудита действий с файлами в Windows (чтобы получать события по файлам, подобные тем, что были показаны выше) довольно ресурсоемкая задача – и, по разным оценкам, будет стоить вам до 30% потерянной мощности файлового сервера. Именно поэтому для этого есть специализированные решения.
Даже в этом очень простом примере вы можете видеть, что работа SIEM — это интенсивный и сложный процесс с мощным потреблением ресурсов. Кстати именно поэтому, как отмечают аналитики безопасности, на SIEM накладываются некоторые фундаментальные ограничения, по крайней мере, для первых поколений этих продуктов.
Спойлер
работает это все не так шустро и точно, как всем нам хочется
Практические примеры
Среди наиболее распространенных вариантов использования ИБ-аналитики можно отметить:
- Аналитика поведения пользователей UBA (см. ниже)
- Детектирование и классификация угроз
- Обеспечение ИТ-безопасности за счет предоставления полной и точной информации бизнесу для снижения общего риска
Преимущества ИБ-аналитика
Попытка найти инциденты безопасности в необработанных журналах событий по своей сути сложна, а SIEM имеет тенденцию к слишком большому количеству неточных результатов и ложных срабатываний.
Именно здесь ИБ-аналитик имеет основные преимущества перед SIEM: он намного опытнее и прозорливее в том, как стоит смотреть на необработанные данные событий, а также в том, как потом отобразить полученную аналитику для принятия лучших решений в управлении ИТ.
UBA, или аналитика поведения пользователей
Аналитику поведения пользователей, или UBA, можно рассматривать как более информированную версию SIEM. Да, как и SIEM, он также опирается на журналы событий. Однако UBA фокусируется на том, что делает пользователь: запущенные приложения, сетевая активность и наиболее критичные открытые им файлы (когда файл или письмо были открыты, кто их открывал, что с ними делал и как часто).
Хранение и сбор событий на основе действий пользователей имеет свои существенные преимущества перед стандартными логами в SIEM. Пользователи имеют свои собственные уникальные шаблоны поведения: например, регулярный доступ к определенным файлам и каталогам. Чтобы найти потенциальные инциденты безопасности, UBA просматривает текущие журналы событий, связанные с каждым пользователем, а затем сравнивает их с типичной для него картиной того, что обычно делает этот пользователь.
Таким образом, UBA – это по своей сути SIEM, но плюс с историей и контекстом. Поэтому она может выявить потенциальные атаки, определить, исходят ли подозрительные действия от хакера, инсайдера, вредоносного ПО или же от других процессов и служб.
Если вы только что задумались о том, что тут наверняка используются методы машинного обучения и анализа/прогнозирования из теории больших данных, то вы совершенно правы! Эти методы анализа помогают установить некую базовую линию, на основе которой можно затем предсказывать, что нормально, а что нет.
Подводя итог, безусловно, SIEM является разумным подходом для обнаружения атак. Но без дополнительного контекста, выводы и действия, основанные только лишь на SIEM-статистике, становятся менее надежными. Это будут, по сути, «ложные срабатывания», когда SIEM-система, указывает нам на угрозу в тот момент, когда ее нет. В какой-то момент вы вдруг обнаруживаете, что почти 100% времени анализируете одни лишь фальшивые угрозы. А в итоге вообще начинаете их игнорировать, да еще и вместе с теми, которые, безусловно, стоят вашего внимания.
UBA привносит контекст, благодаря чему сокращаются ложные срабатывания. Системы UBA обрабатывают тот же самый поток событий, но смотрят на него под углом ежедневной активности людей в компьютерных системах, а затем сравнивают ее с наработанной нормализованной базой. И за счет этого, используя собственные алгоритмы и правила, более точно выявляют нестандартную активность.
Как визуализировать аналитику безопасности: панели мониторинга и модели угроз
Системы UBA, как мы видели, дают нам более чистые данные, на основе которых сотрудники ИТ-безопасности должны иметь возможность принимать более взвешенные решения. Чтобы сделать любые данные пригодными для использования людьми, необходима визуализация, которая позволит с первого взгляда отличить, какие из пользователей были замечены в аномальном поведении.
Единая панель мониторинга безопасности. Здесь можно все детализировать, чтобы получить более подробную информацию о затронутых пользователях и угрозах, нависших над ними
Панели мониторинга ИБ-аналитики (Security analytics) — это многоуровневые интерфейсы GUI, которые позволяют нам детализировать и увидеть больше информации, например, просмотреть детали затронутого пользователя, нажимая на карту контекста пользователя. Так например, в нашей панели мониторинга Varonis (см. картинку выше) вы легко сможете увидеть, какие пользователи подвергаются атаке, связанные с ними устройства, модели угроз, в которых они участвуют.
Ну и, в конечном итоге, это все должно привести нас к обсуждению моделей угроз, которые на самом деле являются формальным способом выявления и оценки потенциальных угроз и уязвимостей. Например, Mitre, знаменитая научно-исследовательская лаборатория MIT, имеет прекрасную базу знаний о текущих моделях угроз, которые заслуживают вашего внимания.
Панель мониторинга состояния безопасности организации находится в верхней части пищевой цепочки событий. Это визуальный результат цепочки обработки, которая начинается с методов UBA, применяемых к сырым необработанным событиям, и заканчивается специальными алгоритмами, часто основанными на машинном обучении, для поиска и классификации данных в различные модели угроз. К примеру, необычный доступ к конфиденциальным данным, обнаруженная криптоактивность, необычные изменения привилегий пользователя или группы, массовое удаление и многое другое.
Надеюсь, для вас теперь тоже вполне очевидно, что панель мониторинга текущих угроз на основе UBA намного эффективнее, чем работа с сырыми журналами событий? Например, наше решение DatAlert покрывает очень широкий диапазон моделей угроз. А если вы захотите узнать больше о том, как наши возможности по анализу данных могут помочь вам избежать просмотра необработанных журналов, то запишитесь на демо или пилотное тестирование.
