Распределенная аналитика безопасности
Искусственный интеллект радикально меняет отрасль кибербезопасности. Для успешного использования ИИ для обеспечения безопасности качество данных имеет первостепенное значение. Данные, связанные с безопасностью, должны собираться из множества различных источников, среди которых сетевые данные из пакетов, данные сервера из команд и процессов, данные приложений, такие как журналы, и данные анализа угроз, полученные от исследователей безопасности. Эти разрозненные потоки информации поступают в централизованный процессор, где машинное обучение выполняется для обнаружения угроз безопасности.
Проблемы с данными
Некоторые проблемы возникают в процессе сбора данных.
- Недостаточно данных
В некоторых случаях объем данных недостаточен для машинного обучения для получения точного результата. Когда это происходит, может быть слишком много ложных срабатываний или ложноотрицательных результатов. Как правило, чем больше объем данных, тем точнее результат.
- Слишком много данных
Обратной стороной большого объема данных, однако, является возрастающая стоимость требуемых вычислительных мощностей. Данных может быть так много, что машинное обучение потребляет слишком много ресурсов и его невозможно поддерживать. В таких случаях развертывание моделей машинного обучения в оперативном режиме становится непрактичным или дорогостоящим.
- Потерянная информация
Данные могут отсутствовать или быть неполными. Если кусочки головоломки отсутствуют, определенные события безопасности не могут быть обнаружены. Мы подробно рассмотрим, что это означает, в следующем разделе.
- Неверные данные
Если данные неверны, даже теоретически совершенная модель машинного обучения даст неверные результаты. Мусор на входе, мусор на выходе.
Поскольку вторая и третья задачи менее интуитивны, мы сосредоточимся на решении этих двух проблем.
Мы обсудим, почему архитектура аналитики безопасности имеет большое значение при определении ее масштабируемости и надежности при развертывании.
Централизованная и распределенная аналитика безопасности
Чтобы разработать машинное обучение для кибербезопасности, можно рассмотреть две архитектуры. Централизованная архитектура довольно распространена. В централизованном машинном обучении потоки данных поступают из многих источников, в то время как машинное обучение выполняется централизованно. Потоки данных, которые представляют собой журналы или сетевой трафик, такие как Netflow или IPFIx, сами по себе содержат мало информации - они просто являются транспортными средствами к центральной платформе больших данных. Затем машинное обучение выполняется центральной платформой на совокупных данных.
Благодаря архитектуре распределенной аналитики безопасности (DSI) аналитика безопасности умело применяется в критических точках всей системы, начиная с источников данных в самом начале процесса. Хотя архитектура DSI аналогичным образом передает эти разрозненные источники данных в централизованную платформу больших данных для анализа, применение интеллекта в дополнительных точках сокращает объем данных, принимаемых платформой больших данных. Подобно вычислениям FOG, это различие обеспечивает масштабируемость и доступность, которые очень востребованы средними и крупными предприятиями и MSSP с множеством клиентов SME.
Случаи использования
DSI демонстрирует свое превосходство в качестве архитектуры для аналитики безопасности в следующих случаях:
Проблемный случай 1: сырые пакетные данные не масштабируются
Как ранее было продемонстрировано IDS / IPS, использование сырых пакетов для обнаружения имеет серьезные ограничения на масштабируемость. Чтобы смягчить эту проблему, большинство IDS / IPS развертываются в непосредственной близости от межсетевого экрана периметра, если не являются его частью. Представьте себе попытку сделать это на некоторых централизованных серверах в центре обработки данных или облаке - пакеты дублируются и передаются по сети в кластер серверов. Хотя попытка может быть возможна, это приведет к большой нагрузке на ЦП исходного сервера, пропускную способность сети, а также вычислительные ресурсы централизованных серверов. Запускать машинное обучение на сырых пакетах просто непрактично. Кроме того, плотность информации, имеющей отношение к безопасности, для каждого из них очень низкая, а пакеты форматируются для эффективной передачи, а не для анализа, такого как машинное обучение.
Проблемный случай 2: Netflow / IPFIX пропускает важные данные
Из-за отсутствия масштабируемости необработанных пакетов может показаться разумным сжимать данные и извлекать только полезную информацию. Netflow и IPFIX - это протоколы, которые отслеживают информацию о потоке сетевого трафика, а не отдельные пакеты. Они резко сокращают объем данных, делая возможным машинное обучение. Однако, несмотря на то, что Netflow / IPFIX полезны для анализа производительности сети, мало что можно сделать для понимания содержимого приложения. Для обнаружения угроз безопасности требуется такая информация, как имена доменов DNS, URL-адреса HTTP, запросы к базе данных и многое другое.
Были предприняты попытки расширить функциональные возможности IPFIX для поддержки такого содержимого, как имя приложения, но результаты не дали результатов из-за обилия различных приложений, а также сложности каждого приложения.
Решение: превосходные данные с содержанием приложения
Распределенный интеллект представляет собой лучший способ. Информацию, связанную с безопасностью, следует извлекать из популярных приложений, таких как доменные имена DNS и запросы MySQL, путем правильной идентификации приложений из необработанных пакетов. Извлеченные данные могут быть обогащены во время сбора информацией о потоках, такой как начало сеанса, продолжительность сеанса, общее количество байтов в каждом направлении сеанса и шаблон передачи пакетов, и это лишь некоторые из них. Эта распределенная модель может похвастаться сокращением объема данных по сравнению с использованием только сырых пакетов, а также преодолением ограничений стандартных протоколов, таких как Netflow / IPFIX. Плотность полезной информации для помощи в обнаружении угроз увеличивается, а объем данных уменьшается.
Учитывая потенциальное разнообразие и сложность приложений, а также потенциальную сложность каждого приложения, идентификация приложения может занять очень много времени. Инструменты с открытым исходным кодом, такие как BRO, могут извлекать содержимое приложения, но производительность по-прежнему остается проблемой. Для достижения определенной пропускной способности может показаться необходимым иметь дорогостоящее выделенное оборудование. Фильтр данных Stellar Cyber - это мощное, легкое решение со встроенным интеллектом, которое может идентифицировать тысячи приложений с помощью только первого пакета потока. Его интеллект снижает требуемую вычислительную мощность и предоставляет дополнительную информацию, которая окажется критически важной при обнаружении событий безопасности.
Проблемный случай 3: один только сетевой трафик пропускает важные данные
Выполнение машинного обучения с данными о сетевом трафике, безусловно, может обнаружить некоторые события безопасности, но результаты могут быть неэффективными. Например, можно идентифицировать взломанный сервер или контейнер по его IP-адресу. Однако можно было бы улучшить информацию об IP-адресе сервера его именем хоста, поскольку IP-адреса могут изменяться со временем. Дальнейшее улучшение может заключаться в точном определении команды, процесса или пользователя на сервере, сгенерировавшего событие, чтобы можно было остановить вредоносные процессы и очистить скомпрометированных пользователей. Для достижения этих целей необходимо осуществлять интеллектуальный сбор и объединение данных из других источников данных, таких как журналы приложений, выполняемые команды и серверные процессы.
Решение: превосходные данные из других источников
Данные из нескольких источников можно и нужно получать. Фильтры данных Stellar Cyber используют распределенный интеллект для поддержки разнообразного диапазона источников данных, от сетевого трафика с содержимым приложений до команд или процессов, выполняемых на серверах, до журналов приложений и т. Д. Наш централизованный процессор может принимать данные из дополнительных источников, таких как брандмауэр и журналы IDS / IPS, каналы аналитики угроз и пользовательская информация из AD. Затем эти обширные наборы данных объединяются и сопоставляются для подготовки к расширенному анализу.
Проблемный случай 4: слишком много данных для централизованной обработки
Общие угрозы, такие как сканирование портов, SYN-потоки и кража данных через туннелирование DNS, могут быть обнаружены интеллектуальным центральным процессором. Однако более эффективная и экономичная стратегия заключается в их обнаружении на начальном этапе сбора данных. Применение интеллекта в локальных ветвях системы сокращает объем данных, которые должны приниматься, обрабатываться и храниться центральным процессором. Если весь набор данных сетевого трафика, который содержит соответствующие угрозы, подается на процессор, модуль машинного обучения без необходимости запускает анализ десятков тысяч или миллионов дополнительных записей. Чтобы сохранить ресурсы, агент сбора данных должен разделить данные на важные элементы, прежде чем продолжить. Помимо повышения производительности, центральный процессор также выиграет от снижения риска получения DOS-атак.
Интеллектуальная и быстрая безопасность с распределенным интеллектом
Преимущества распределенного интеллекта в масштабировании машинного обучения и повышении безопасности обнаружения выходят за рамки этих случаев. Интеллектуальный сборщик данных, например, может захватывать пакеты события туннеля DNS в момент обнаружения, так что туннелированная информация может быть восстановлена.
Распределение аналитики безопасности по всей цепочке обработки данных повышает масштабируемость всей системы обнаружения угроз. Интеллект в точках сбора данных улучшает качество данных при одновременном уменьшении объема. Архитектура централизованного процессора данных на основе микросервисов позволяет использовать как контролируемое, так и неконтролируемое машинное обучение в конвейере для своевременного и надежного обнаружения угроз.
Changming Liu
CEO
Звездный кибер
