SIEM давно превратились в стандарт де-факто при анализе событий безопасности и выявлении инцидентов (хотя сейчас отмечается некоторое движение в сторону отказа от SIEM и замены их решениями по управлению журналами регистрации с надстройкой из технологий машинного обучения), но эффективность этого решения сильно зависит от того, с какими источниками данных оно работает. Все-таки обычно специалисты SIEM преимущественно работают с журналами регистрации, оставляя в стороне такой важный источник информации, как Netflow, который позволяет увидеть то, что часто не попадает в логи или попадает, но слишком поздно. При этом возникает ряд вопросов. Зачем современному SIEM-решению нужна поддержка Netflow? Что SIEM может получить от анализа Netflow? Какой вариант интеграции SIEM с Netflow предпочесть, если есть производители, которые встраивают поддержку Netflow в свои решения напрямую, а есть те, кто предпочитает работать с различными коллекторами Netflow. В чем особенности работы SIEM с Netflow? Об этом мы и поговорим.
В одной из прошлых статей я уже описывал возможности использования Netflow для целей кибербезопасности. Напомню, что в отличие от логов сетевого оборудования или сырого трафика, Netflow — это протокол, который позволяет анализировать трафик по метаданным, собираемым из сетевых сессий. Это не только адреса и порты назначения и источника, но и типы и коды сообщений для ICMP, типы сервиса IP, тип IP-протокола, сетевые интерфейсы, длительность сессии, время ее начала и окончания и т.п. Если обычно логи генерятся на оконечных устройствах (например, серверах, рабочих станциях и СУБД ) или средствах защиты, то что делать в ситуации, когда первые не генерят события безопасности или на них нельзя поставить средства защиты, а вторые установлены только на периметре и не видят происходящего внутри корпоративной или ведомственной сети? Другое дело сетевое оборудование — коммутаторы и маршрутизаторы (аппаратные или виртуальные), беспроводные точки доступа и контроллеры. Они установлены внутри и взаимодействие пользователей, устройств, приложений всегда проходит через них. Миновать их невозможно! Транслируя данные о таком взаимодействии в Netflow (а его генерит даже Cisco ASA или Firepower), мы получаем ценнейший источник информации для целей не только ИТ, но и кибербезопасности. Там где оборудование не понимает flow-протокол, мы можем воспользоваться специальными экспортерами, программными или аппаратными решениями, которые генерят записи о потоках для пропускаемого через них трафика (у Cisco такими экспортерами могут служат Netflow Generation Appliance или Stealthwatch Flow Sensor). Накладываемые на потоки Netflow алгоритмы обнаружения аномалий или сигнатур, а также методы машинного обучения, позволяют выявить отклонения от эталонного поведения сетевого трафика, что и будет характеризовать угрозы ИБ или проблемы с ИТ-инфраструктурой.
Стоит помнить, что Netflow не может сказать, что передается внутри сетевого трафика (хотя уже есть технологии, которые позволяют распознавать используемые приложения и вредоносный код по Netflow), он разрабатывался для других задач. Но он может подсказать, кто “говорил” и с кем, как и насколько долго. Несмотря на наличие разных версий flow-протоколов, большинство из них позволяет вам собирать следующие данные:
В ряде версий, например, в IPFIX или Netflow v9 вы можете извлекать часть информации из тела данных, что позволяет анализатору Netflow (самостоятельному или встроенному в SIEM) идентифицировать работающие приложения. Всей этой информации зачастую достаточно, чтобы выявить аномалии или даже угрозы в сетевом трафике.
Что делать, если целевая система не генерит логи или они отключены злоумышленниками? Что делать, когда на целевой системе просто нет средств защиты, потому что они нагружают процессор и тормозят систему? Что делать, когда сотрудник приносит свое личное устройство, которое не заведено на SIEM? У нас остается единственный источник информации — сетевой трафик, который в любом случае генерится целевым устройством. Что может помочь идентифицировать «чистый» Netflow, который можно анализировать без SIEM, с помощью решений класса NTA (Network Traffic Analysis)? Вот небольшой список таких угроз и аномалий:
А что дают вам логи, которые собирает ваш SIEM? Возможность мониторить пользовательскую активность на узлах, доступ к ресурсам, вход и выход в системы и из них, сигналы тревоги от сетевого оборудования и средств защиты, и многое другое. Комбинация логов и Netflow, поступающая на SIEM и анализируемая там, позволяет вам быстро идентифицировать новые сессии и новый трафик с только что атакованных устройств, в том числе и идущий в обход вашего периметра. Комбинируя эти типы данных, вы также можете идентифицировать некорректно настроенные средства сетевой безопасности. Netflow дополняет традиционные возможности SIEM способностью обнаружения новых типов трафика, его всплесков, взаимодействия с внешними и внутренними ресурсами, утечек данных, распространения вредоносного кода, взаимодействия с командными серверами, инкапсуляции вредоносной нагрузки в разрешенные протоколы и т.п.
Комбинация традиционно обрабатываемых SIEM данных с Netflow позволяет не только увидеть больше различных событий безопасности, но и увидеть их быстрее, снижая так называемый параметр TTD (Time-to-Detect) и, как следствие, время реагирования. Понятно, что SIEM и анализ Netflow могут работать независимо друг от друга и выполнять свою работу хорошо, но именно комбинация этих двух решений позволяет достичь синергетического эффекта.
Изменение шаблона поведения трафика может характеризовать подозрительное или аномальное поведение. Например, превышение порогового значения для загружаемых в Интернет данных может говорить об утечке. А изменение размера DNS-запросов и ответов по сравнению с предусмотренной RFC может характеризовать факт работы вредоносного кода (по статистике Cisco, DNS используется в 92% вредоносных программ для получения команд, выкачки данных или загрузки обновлений). Помните историю с Equifax? Тогда злоумышленники смогли получить доступ к Web-порталу, а потом к внутренним серверам баз данных, потихоньку выгружая большие объемы данных наружу. По отдельности, все эти события не представляли большого интереса и только собранные вместе и обогащенные данными Netflow, они позволили выявить инциденты ИБ. Это еще один кейс для систем анализа Netflow, которые могут выявлять нестандартное поведение и Web-портала, с которого учащаются запросу к БД, и БД, которые вдруг отдают много данных порталу. Я уже описывал этот сценарий на Хабре ранее. SIEM, получая данные Netflow, может получить дополнительный контекст для событий, создаваемых IPS, МСЭ, прокси, антивирусами, EDR и т.п., чтобы более эффективно реагировать на инцидент.
Другой пример. Обнаружение неизвестных атак для которых у систем обнаружения вторжений нет сигнатур — за счет корреляции сетевых аномалий и событий от хостов, а также срабатывании триггеров. Например, сканирование 100 узлов за 3 минуты может характеризовать работу вредоносного кода, расширяющего свой плацдарм. Увеличение времени отклика от сервера может характеризовать DDoS-атаку против него, а, например, несоответствие объема получаемой и отправляемой информации по протоколу DNS может говорить об утечке данных. Это кейс мы уже рассматривали ранее, когда я рассказывал об обнаружении кампании DNSpionage. При этом вы можете обратить внимание, что в одном случае мы анализировали только Netflow, а в другом — собирали данные еще и с оконечных устройств, песочницы, DNS-шлюза и т.п.
Еще одной областью, где интеграция Netflow в SIEM может помочь, — это ситуационная осведомленность. Корреляция потоков с логами, контекстом, геолокационной информацией, активностью пользователей, репутационными данными. Например, в прошлой заметке, я приводил кейс с обнаружением внутреннего трафика с узлами из Ирана или Северной Кореи. Если у вас нет контактов с этими странами, то возможно это признак работы вредоносного кода, крадущего информацию, или прогосударственных хакеров, нацелившихся на вашу компанию. Система анализа сетевых аномалий может сделать часть этой работы, выявив соответствующую аномалию. Но если вы хотите также понять, кто из пользователей участвовал в данном инциденте, вам понадобится дополнительный контекст в виде имен пользователей из Active Directory. Сам по себе Netflow этой информацией не оперирует — поэтому нам нужно обогатить его сведениями из AD. Если вы используете Cisco Stealthwatch, то вам для этого достаточно интегрировать его с Cisco ISE, который и будет увязывать IP- и MAC-адреса с конкретными пользователями и профилями устройств. А если в сети Cisco ISE не развернут? Задачу обогащения Netflow пользовательской информацией берет на себя SIEM.
Другой пример. У меня на компьютере запущен Web-сайт, используемый для ряда задач. Но многие ли рядовые пользователи могут похвастаться тем же? Вдруг вы фиксируете с пользовательского компьютера трафик, присущий работе Web-сервера? Или в сегменте, в котором находятся пользователи, работающие на ПК с Windows, вы вдруг видите трафик, присущий ОС Linux. Возможно, это “рукастый” пользователь решил поднять виртуалку с Linux, нарушив тем самым политику безопасности? А еще вы можете выявить таким образом утилиты для удаленного доступа (например, RAT), криптомайнеры, облачные или пиринговые приложения и т.п.
Если вы сторонник моновендорного подхода, то строительство системы защиты на базе решений Cisco, позволит вам снизить зависимость от SIEM, — все решения Cisco, включая межсетевые экраны, средства защиты e-mail, песочница, решение по защите ПК (Cisco AMP for Endpoints) и т.п. могут обмениваться данными, контекстом, событиями безопасности, командами между собой напрямую. Но если ваша инфраструктура унаследовала множество разных решений от разных производителей, то именно SIEM будет тем связующим звеном, который поможет построить из зоопарка разных продуктов целостное решение. В любом случае, анализ сетевого трафика, собираемый с существующей сетевой инфраструктуры, комбинированный с данными, которые обычно собирает SIEM, расширяетгоризонты способность службы ИБ видеть больше и реагировать быстрее.
Преимущества использования Netflow в SIEM:
Но не стоит думать, что Netflow — это серебряная пуля, которую все так давно ищут. У него есть и недостатки. Например, его обработка может нагружать процессор и память устаревшего или неверно выбранного сетевого оборудования и это может негативно сказаться на его производительности и пропускной способности сети. Чтобы эффективно работать с Netflow вам может понадобиться его аппаратная поддержка или использование так называемых экспортеров, которые пропуская трафик через себя будут транслировать его в Netflow (кто сталкивался с внедрением IDS/СОВ в коммутируемых сетях, использовал для схожей задача так называемые tap'ы или разветвители). Я уже выше приводил два примера таких внешних решений — Cisco Stealthwatch Flow Sensor и Cisco Netflow Generation Appliance. Хотя при условии недавней модернизации сети, можно предположить, что ваши коммутаторы и маршрутизаторы уже поддерживают те или иные варианты Netflow и никаких дополнительных экспортеров вам не понадобится.
К другим особенностям Netflow, о которых стоит знать, я бы отнес:
Какие из представленных сегодня на рынке SIEM работают с сетевым трафиком? Надо сказать, что почти все, но по-разному и часто это требует отдельной платной лицензии, которые, в свою очередь, тоже подразделяются на варианты. Я бы выделил три варианта анализа Netflow в SIEM:
Встроенная поддержка Netflow есть, например, у Microfocus ArcSight, достаточно популярном на постсоветском пространстве SIEM. Такая возможность позволяет SIEM на лету проводить корреляцию сетевых потоков с другими событиями безопасности или обогащать их данными из источников Threat Intelligence. Однако у данного варианта есть и свои недостатки, а именно:
Если вы только стоите перед выбором SIEM, то включите в список рассматриваемых параметров еще и тип Netflow, который генерится вашим оборудованием. Если у вас SIEM уже куплен, то у вас не так много выбора. В этом случае вам стоит рассмотреть следующие варианты:
Кстати, прежде чем мы перейдем к следующему варианту интеграции Netflow с SIEM пора коснуться вопроса, а сколько данных Netflow мы будем получать в нашу систему анализа событий безопасности? Для средств защиты или обычных логов существует немалое количество примеров и статистики по EPS (events per second). Данных по FPS (flow per second) не так много. Средний объем Netflow прямо пропорционален числу уникальных TCP/UDP-сокетов, создаваемых клиентскими устройствами и серверами в вашей сети, которые могут сильно разнится от случая к случаю. Да и включение семплирования (то есть выборочной передачи данных Netflow) тоже влияет на итоговый объем данных.
Так сколько же FPS у нас может генериться? Конечно, это сильно зависит от ситуации, но я бы назвал, что для обычной рабочей станции это число равно, в среднем, 1.5 FPS, и 6 FPS при пиковой нагрузке. Иными словами, если в вашей сети 10 тысяч узлов и среднее значение FPS для каждого из них составляет 4, то сеть генерит около 40 тысяч потоков в секунду. Почему так много? Как я написал выше, это зависит от того, насколько много уникальных соединений генерят ваши приложения или ваша сеть. А сегодня на компьютерах пользователей работает очень много “болтливых” программ, которые либо активно подгружают контент из Интернета, например, браузеры, либо постоянно проверяя обновления, например, антивирусы. Вот примерный список ПО и сервисов, которое активно повышает число FPS в сети:
Более точный ответ вам подскажет анализ Netflow в нужных вам сегментах сети, что делается всего одной командой на сетевом устройстве (зависит от производителя).
Длина одной записи Netflow v5 составляет 48 байт. Для 9-й версии Netflow такой точной цифры не существует, так как эта версия позволяет описывать то, что вы будете включать в запись и поэтому ее длина может сильно варьироваться. Но если, очень грубо, взять 100 байт за среднюю длину записи о потоке (а каждый сетевой пакет может генерить 20-30 потоков), то можно прикинуть, какой объем данных будет генериться и поступать на SIEM. При этом объем хранилища SIEM под эти данные может быть больше (это будет зависеть от формата хранения, индексации, сжатия, резервирования и т.п.). Кстати, рассчитывая количество FPS помните, что в рамках какой-нибудь DDoS-атаки понятие “среднее число FPS” не работает, так как каждое соединение, каждый TCP SYN-пакет, будут представлять собой отдельный поток и при мощной DDoS-атаке число FPS в пике у вас будет очень большим.
Выше я упомянул, что в случае с передачей Netflow на центральный SIEM, вам придется «гонять» его через Интернет. Не стоит думать, что генерация Netflow создаст огромную нагрузку на сеть и снизит ее пропускную способность. Согласно нашим исследованиям, так как в Netflow передается только информация по заголовку и дополнительная телеметрия, а не все тело данных, рост нагрузки составит около 1-2% на интерфейс, с которого экспортируется сетевая телеметрия (на самом деле при использовании семплирования и современных версий протокола Netflow это значение может быть меньше еще на порядок и варьироваться на уровне 0,1%).
Но, допустим, вы все-таки решили завести «сырой» Netflow на свой SIEM. У данного сценария есть и еще один нюанс. Очень важно понимать, что недостаточно наличия поддержки Netflow в SIEM; крайне важно уметь этот Netflow обрабатывать с точки зрения безопасности, то есть иметь встроенные и постоянно обновляемые под новые типы атак правила анализа и корреляции потоков Netflow. Допустим, Netflow нам выдает вот такую картину:
Мы видим всплеск по протоколу SSH. На самом деле такую же картину мы сейчас наблюдаем с атаками на протокол RDP. Это подбор пароля. Но выявить это можно только при условии, что у нас есть соответствующее правило, которое из множества потоков Netflow соберет одно событие “Подбор пароля”. Тогда можно говорить о том, что SIEM у нас имеет встроенную поддержку Netflow и может его анализировать с точки зрения безопасности. Поэтому выбирая этот путь, стоит поинтересоваться у продавца, что может анализировать SIEM в Netflow “из коробки” и, если ничего, то насколько трудоемок процесс описания собственных обработчиков Netflow и есть ли у вас в штате специалисты, которые будут это делать. Мы же прекрасно понимаем, что написать коннектор к Netflow не так уж и сложно, в отличие от правил его обработки и выявления в нем аномалий, требующих постоянной работы. Это примерно как скопипастить чужой движок для своей IDS (Snort, Zeek или Suricata), но не уметь на постоянной основе писать сигнатуры для вновь обнаруживаемых эксплойтов и атак. В примере выше, система должна сама распознать всплеск трафика по SSH и сама сказать, что это атак «подбор пароля» на SSH (или Telnet, или RDP, или FTP). Это может выглядеть так (на примере Cisco Stealthwatch Enterprise):
А уже потом можно проводить расследование данного инцидента на более глубоком уровне, используя возможности, предоставляемые или SIEM, или отдельным средством анализа Netflow. Без умения «понимать» Netflow с точки зрения ИБ, наличие встроенной поддержки Netflow является сомнительным преимуществом для SIEM.
Другой игрок SIEM-рынка, LogRhythm, в свою очередь, предлагает дополнительный экспортер потоков NetMon, что может быть полезно в распределенной инфраструктуре, а также в сети, оборудование которой не поддерживает Netflow и требуется отдельный генератор Netflow для пропускаемого через него сетевого трафика. По сути, в данном варианте производитель SIEM берет на себя функции сетевых вендоров, разрабатывая решение для генерации Netflow и снижения нагрузки на SIEM, который освобождается от необходимости обрабатывать и хранить сырой Netflow. Ситуация схожа с поддержкой функции SSL Offload на многих межсетевых экранах нового поколения. Да, она там существует, но при интенсивном обмене HTTPS-трафиком, дополнительная нагрузка на NGFW приводит к существенному снижению его пропускной способности. Поэтому в высоконагруженных архитектурах под эту задачу обычно выделяют отдельное устройство, которое и берет на себя задачу расшифрования SSL-трафика с последующей его отдачей на NGFW. Тоже самое происходит и с обработкой Netflow на SIEM в данном сценарии.
Понятно, что у такого сценария есть и недостаток — рост итоговой цены решения, так как помимо оплаты лицензий по количеству анализируемых FPS, понадобится платить и за дополнительные сенсоры, которые будут пропускать через себя трафик и генерить Netflow. Кроме того, понадобится вносить изменения в сетевую архитектуру, но это придется делать в любом случае, так что я бы назвал это не недостатком, а особенностью этого сценария. Если ваше сетевое оборудование не умеет генерить Netflow, а вы хотите анализировать сетевые аномалии, то единственный вариант сделать это — использовать отдельные сенсоры. Вопрос только в том, что будет дешевле — покупать сенсоры от производителя SIEM или задействовать сенсоры от сетевых производителей (например, Cisco Netflow Generation Appliance) или разработчиков средств анализа сетевых аномалий (например, Cisco Stealthwatch Enterprise Flow Sensor). В этом варианте тоже стоит узнать, умеет ли SIEM анализировать Netflow с точки зрения ИБ или у него есть просто коннекторы в виде вынесенных вовне экспортеров/сенсоров (обычно умеет)?
Третий вариант, интеграция с решениями класса NTA, является достаточно очевидным, так как, по сути, NTA является таким же генератором событий безопасности как и NGFW, антивирус, сканер безопасности, IPS и т.п. Этот сценарий, однако, интересен тем, что вы объединяете два имеющихся у вас инструмента аналитики ИБ, но можете работать с ними и отдельно. NTA позволяет вам проводить глубокий анализ сетевого трафика, выявлять вредоносный код, DDoS-атаки, утечки информации, контролиировать удаленных пользователей… При этом, хорошее средство анализа сетевого трафика также позволяет вам использовать отдельные сенсоры в тех сегментах, где сетевое оборудование не поддерживает Netflow или его включение приводит к росту нагрузки на сетевое оборудование. NTA в этом сценарии позволяет агрегировать, обрабатывать, анализировать Netflow (в разных его версиях), а на SIEM отдавать только сигналы тревоги по факту обнаружения той или иной вредоносной активности. Очевидно, что этот вариант также имеет смысл задействовать, когда у вас или у ваших ИТшников уже есть решение класса NTA для сетевого траблшутинга и его можно задействовать и под задачи сетевой безопасности. Или когда, наоборот, вы хотите поделить траты на решение NTA с вашими сетевиками, которые будут использовать его для своих задач, а вы для своих.
Недостатком этого варианта является дополнительная стоимость решения класса NTA, а также необходимость двойного обучения специалистов основам работы с двумя разными решениями. Но зато отдельное решение для анализа сетевого трафика позволит проводить более глубокие расследования инцидентов, чем при наличии одного лишь SIEM с встроенной поддержкой Netflow, и более гибкие варианты применения, чем с вариантом наличия отдельных сенсоров Netflow у производителя SIEM. Но стоит помнить, что когда мы говорим об отдельном решении класса NTA, я имею ввиду именно решение по безопасности, а не просто инструмент по анализу сетевого трафика или мониторинга производительности сети. Например, уже упомянутый ранее SolarWinds NTA неплохо анализирует сетевой трафик с целью поддержки ИТ-задач, но очень плохо это делает для целей ИБ. Тоже касается 5View от InfoVista или Visual TruView от Fluke. А тот же, например, Cisco Stealthwatch Enterprise может быть использован и тем и другим подразделением в компании.
Выбирая решение NTA для целей безопасности, а также анализируя экспортеры/сенсоры, предоставляемые вендорами SIEM или SIEM с поддержкой Netflow, я бы порекомендовал обратить внимание на следующие критерии:
Если бы речь шла о том, что выбирать независимо от SIEM, то я бы еще посоветовал посмотреть в сторону возможностей по threat hunting, которые предоставляет выбираемое решение. Но так как тема заметки выбрана немного другая, то этому аспекту мы внимание уделять сейчас не будем.
Если на эти три варианта посмотреть с точки зрения их стоимости, то наиболее дорогим с точки зрения капитальных затрат (при условии одинаковых возможностей по анализу Netflow во всех трех сценариях) окажется третий вариант. Оно и понятно. Помимо стоимости SIEM вам понадобится отдельное решение по анализу сетевого трафика, которое будет состоять, минимум, из системы управления и нужного количества коллекторов, собирающих Netflow с разных экспортеров/сенсоров. С другой стороны, как бы вы не расширяли потом покрытие своей сети новыми экспортерами/сенсорами, на стоимости SIEM и инфраструктуры для него это никак не скажется, так как он будет работать с уже обработанными сигналами тревоги, а не с “сырыми” потоками Netflow, которых (сигналов) будет на несколько порядков меньше.
Первый вариант выглядит самым привлекательным с точки зрения его цены, так как нам не надо дополнительно платить ни за обучение аналитиков и администраторов NTA, ни за дополнительные экспортеры/сенсоры; знай, передавай потоки Netflow в SIEM и все. Однако у вас сильно возрастет стоимость инфраструктуры для SIEM, так как придется хранить “сырые” потоки Netflow, что потребует расширения имеющегося хранилища. Второй вариант является промежуточным между двумя крайними — как с точки зрения возможностей по анализу Netflow, так и с точки зрения стоимости. В любом случае, в первых двух вариантах стоит уточнять у производителя SIEM совокупную стоимость владения решением исходя из стоящих задач, а также текущего и ожидаемого показателя FPS и, как следствие, изменения стоимости лицензий для SIEM и хранилища для него. Возьмем, к примеру, LogRhythm и его подсистему для анализа Netflow. Существует минимум три варианта его реализации и, как следствие, ценообразования. Самый младший вариант, Freemium может отдавать в SIEM только сигналы тревоги, пропускная способность не может превышать 1 ГБит/с, объем хранилища составляет всего 1 Гб (это около одного дня хранения Netflow без семплирования), срок хранения индекса не больше 3-х дней, а также отсутствует корреляция с дополнительными источниками данных, а поддержка работает только онлайн и через community. В следующей версии, NetMon, показатели лучше (пропускная способность до 10 ГБит/с на все экспортеры, хранилище не ограничено, индекс сохраняется до месяца, но корреляции с другими источниками тоже нет). И только в премиум-версии NetworkXDR у вас никаких ограничений нет, но стоит она как “километр московских дорог”, то есть недешево.
В одном из проектов мы столкнулись с тем, что при ежедневном объеме сетевой телеметрии в 1 ТБ и отправки его в SIEM с встроенной поддержкой Netflow итоговая стоимость решения составила около 600 тысяч американских долларов (еще до очередного скачка курса). При этом часть этих данных оставалась необработанной из-за отсутствия в SIEM соответствующих правил и дублирующей. Применение отдельного NTA-решения (в нашем случае это был Cisco Stealthwatch Enterprise) привело к снижению объема передаваемых в SIEM данных на 80%, а стоимость решения упала до 99 тысяч долларов США. Математика может отличаться от проекта к проекту, но мы заметили, что чем больше Netflow нам надо обрабатывать, тем дороже будет обходиться инфраструктура SIEM для его обработки. Почему так?
Давайте посмотрим на один из примеров. Когда пользователь подключается к серверу, с точки зрения классического анализа событий ИБ мы имеем дело, условно, всего с одним событием, которое мы “снимаем” с сервера, отправляя его, например, по syslog на SIEM (на самом деле событий будет два — попытка подключения и ее результат). Если это событие разложить на сетевые составляющие, то мы увидим, что потоков будет сгенерировано на порядок больше. Для примера, среднее число “хопов” (hop) от клиента к серверу составляет в среднестатистической сети 5-6. Каждый коммутатор или маршрутизатор, через который проходит запрос от клиента в сторону сервера, генерит свои записи Netflow, описывающие проходящий трафик. Причем делается это для каждого направления сессии (запрос и ответ) отдельно. Получается, что там, где на прикладном уровне было сгенерировано всего 1-2 события, потоков Netflow понадобилось минимум в 10 раз больше (на самом деле еще больше, так один сетевой пакет генерит порядка 20-30 потоков Netflow). И мало того, что мы должны будем заплатить за все эти десятки потоков (хотя событие по-прежнему одно) и выделить место для их хранения. Так еще и SIEM должен будет их обработать, убрать дубли, объединить разнонаправленные потоки в рамках одной сессии и только потом уже коррелировать эти данные с другими событиями. Поэтому совокупная стоимость казалось бы очевидного решения может оказаться выше, чем в случае с вынесенным отдельно экспортером Netflow или самостоятельным решением по анализу сетевых аномалий, интегрированными с SIEM.
А использоваться такие внешние Netflow-анализаторы могут в одном из двух сценариев. Первый — передача в SIEM оптимизированной телеметрии, очищенной от повторов (дедуплицированной), объединяющей разнонаправленные потоки. Опираясь на наш опыт (а Stealthwatch Enterprise может работать в таком режиме), могу сказать, что это дает шестикратное сокращение объема телеметрии, передаваемой на SIEM, который, в данном сценарии, должен все равно уметь анализировать Netflow с точки зрения безопасности.
Второй сценарий подразумевает, что вся обработка осуществляется на решении класса NTA, а в SIEM поступают только сигналы тревоги, полученные в результате обработки Netflow. Этот вариант позволяет сократить еще больше данных, отправляемых на SIEM, снижая затраты на его лицензии и инфраструктуру. Да и от SIEMа уже не требуется умение анализировать «сырой» Netflow, что расширяет возможности по выбору средств анализа событий ИБ.
Рассмотрев варианты использования Netflow в SIEM для обнаружения большего числа событий безопасности, чем без Netflow, давайте посмотрим на возможные альтернативы.
Вы можете попробовать использовать средства сетевой диагностики, применяемые для оценки пропускной способности сети, доступности внутренних узлов и сегментов, пиковых нагрузок и т.п. Например, SolarWinds NetFlow Traffic Analyzer. Эти решения не предназначены для обнаружения аномалий и угроз ИБ, но их можно задействовать для передачи flow-информации на SIEM, который может иметь возможность анализа Netflow. Это нагрузит SIEM, как я уже описывал выше, и вам придется решать, готовы ли вы к этому? Правда, предварительно стоит уточнить, может ли сетевой анализатор отдавать данные Netflow во внешние системы. Иногда они могут отдавать вовне только сводную статистику или генерить сигналы тревоги, чего явно недостаточно для задач ИБ.
Сетевые IPS и NGFW являются иной альтернативой. Они могут заглянуть внутрь сетевого трафика и могут обнаруживать многие угрозы за счет механизма глубокой инспекции сети… но на периметре. Все-таки обычно NGFW и IPS ставятся на границе корпоративной сети и Интернет и видят только то, что проходит через них. Наставить эти устройства, “железные” или виртуальные, в каждом интересующем вас месте будет слишком накладно, а в ряде случаев и невозможно технически. Говоря о границе или периметре, стоит помнить, что стык между корпоративным ЦОДом и пользовательскими сегментами — это тоже граница. И стык между корпоративной и промышленной сетью тоже. Но в любом случае, установка дополнительных сенсоров IPS или NGFW может больно ударить по кошельку, в то время как Netflow будет собираться с уже купленного и внедренного сетевого оборудования.
Решения класса NFT (Network Forensics Tool) позволяют хранить, обрабатывать и анализировать сетевой трафик в целях рассследования инцидентов. Но между этим типом решения и NTA есть существенное отличие — NFT работает с полной копией трафика, то есть обычно с PCAP-файлами, а NTA — с записями о нем. И если решения по анализу Netflow работают практически в реальном времени, то NFT — с существенной задержкой. Кроме того, любое решение, которое работает с PCAP (или с иным способом захватывать и сохранять копию всего сетевого трафика), столкнется с проблемой места для хранения всех собранных данных.
Представьте, что у вас есть порт на сетевом устройстве на 1 Гбит/сек. При длине пакета в 64 байта этот порт сможет пропустить через себя 1953125 пакетов в секунду, а при длине в 1500 байт — 83333 пакетов. То есть в зависимости от длины пакета (а это зависит от приложений в сети) у нас будет проходить от примерно 80 тысяч до 2 миллионов пакетов в секунду, которые нам надо будет сохранять. В день такой порт пропустит через себя 86400 Гбит/с или почти 11 ТБ. За год набежит почти 4 ПБ и это только для одного порта, которых у нас может быть в сети тысячи и десятки тысяч. Даже выборочное хранение трафика не сильно облегчит нашу жизнь. Поэтому решения класса NFT нужны, но заменить собой анализаторы Netflow они не в состоянии. Это инструменты, решающие разные задачи, — мониторинг и расследование инцидентов. Обычно эти решения работают в паре — Netflow позволяет выявлять нам инциденты, а NFT уже собирает детальные данные по ним в виде захвата всего сетевого трафика.
"А вот есть SIEM с функцией NFT, например, IBM QRadar Incident Forensics или RSA Security Analytics, которые позволяют работать с полной копией сетевого трафика и все мета-данные Netflow автоматически будут доступны в SIEM". Да, есть! Помимо этого, преимуществом такого решения является возможность реконструкции всех интересующих сетевых сессий и их визуализация, что может облегчить расследование инцидентов. Такой SIEM позволяет встать на место злоумышленника и увидеть все то, что видит он. Но за этим достоинством скрывается и серьезный недостаток, который я уже упоминал выше, — на хранение полной копии сетевого трафика требуется большое, нет, не так, огромное хранилище, которое может по цене встать как отдельный SIEM, а то и больше (больше, чем хранение даже просто сырого Netflow). Вам может понадобиться выбрать, какие конкретно сессии сохранять для экономии места, а это может привести к тому, что какой-то трафик будет потерян. Кроме того, в условиях выполнения законодательных требований по хранению данных, связанных с инцидентами, вам придется нарушить их или платить дополнительные деньги за хранилище. Еще одна особенность такого решения — необходимость сохранять в SIEM уже расшифрованный трафик, а значит вам понадобится пересмотреть архитектуру своей системы мониторинга, чтобы иметь возможность расшифровывать трафик и подавать его в SIEM. И не забывайте, что такие решения все-таки ориентированы на проведение расследований, что требует квалифицированного персонала, а не на обнаружении аномалий и угроз по готовым алгоритмам.
В данном сценарии я бы все таки смотрел на первичный анализ сетевого трафика с помощью Netflow, а уже потом, для интересующих меня событий и инцидентов, включал запись сетевого трафика. Это позволит сэкономить и не тратить ресурсы на хранение «всего».
Итак, подводя краткие итоги. Netflow является ценнейшим источником данных для мониторинга безопасности корпоративных и ведомственных сетей, зачастую единственным, который может быть собран и на базе которого можно принимать решения о наличии или отсутствии угроз в вашем окружении. В принципе Netflow можно анализировать и самостоятельно с помощью решений класса NTA, которые, обладая большой базой правил и алгоритмов выявления вредоносной и аномальной активности, способны оперативно обнаруживать инциденты и реагировать на них. Интеграция же Netflow с данными, собираемыми SIEM, дает нам гораздо больше. SIEM начинает видеть то, чего не видел до этого и видеть это гораздо раньше, чем нам может быть нанесен ущерб. При этом нам не надо вносить сильных изменений в существующую инфраструктуру мониторинга, так как сетевое оборудование у нас уже есть, — надо просто перенаправить Netflow на SIEM, напрямую или через промежуточные решения. Задействование Netflow также позволяет мне достигнуть маленькой, но быстрой победы, — почти все наши пилоты решения Cisco Stealthwatch Enterprise заканчиваются тем, что мы обнаруживаем те или иные нарушения политик ИБ, которые раньше не замечались службой ИБ. Netflow позволял их увидеть, а интеграция его с SIEM, получить синергетический эффект от применяемых средств мониторинга сетевой и системой активности.
Netflow для обнаружения угроз
В одной из прошлых статей я уже описывал возможности использования Netflow для целей кибербезопасности. Напомню, что в отличие от логов сетевого оборудования или сырого трафика, Netflow — это протокол, который позволяет анализировать трафик по метаданным, собираемым из сетевых сессий. Это не только адреса и порты назначения и источника, но и типы и коды сообщений для ICMP, типы сервиса IP, тип IP-протокола, сетевые интерфейсы, длительность сессии, время ее начала и окончания и т.п. Если обычно логи генерятся на оконечных устройствах (например, серверах, рабочих станциях и СУБД ) или средствах защиты, то что делать в ситуации, когда первые не генерят события безопасности или на них нельзя поставить средства защиты, а вторые установлены только на периметре и не видят происходящего внутри корпоративной или ведомственной сети? Другое дело сетевое оборудование — коммутаторы и маршрутизаторы (аппаратные или виртуальные), беспроводные точки доступа и контроллеры. Они установлены внутри и взаимодействие пользователей, устройств, приложений всегда проходит через них. Миновать их невозможно! Транслируя данные о таком взаимодействии в Netflow (а его генерит даже Cisco ASA или Firepower), мы получаем ценнейший источник информации для целей не только ИТ, но и кибербезопасности. Там где оборудование не понимает flow-протокол, мы можем воспользоваться специальными экспортерами, программными или аппаратными решениями, которые генерят записи о потоках для пропускаемого через них трафика (у Cisco такими экспортерами могут служат Netflow Generation Appliance или Stealthwatch Flow Sensor). Накладываемые на потоки Netflow алгоритмы обнаружения аномалий или сигнатур, а также методы машинного обучения, позволяют выявить отклонения от эталонного поведения сетевого трафика, что и будет характеризовать угрозы ИБ или проблемы с ИТ-инфраструктурой.
Стоит помнить, что Netflow не может сказать, что передается внутри сетевого трафика (хотя уже есть технологии, которые позволяют распознавать используемые приложения и вредоносный код по Netflow), он разрабатывался для других задач. Но он может подсказать, кто “говорил” и с кем, как и насколько долго. Несмотря на наличие разных версий flow-протоколов, большинство из них позволяет вам собирать следующие данные:
- IP-адрес источника и назначения
- порты источника и назначения
- протокол
- тип сервиса
- интерфейс источника
- временные метки начала и завершении сессии
- объем переданной информации.
В ряде версий, например, в IPFIX или Netflow v9 вы можете извлекать часть информации из тела данных, что позволяет анализатору Netflow (самостоятельному или встроенному в SIEM) идентифицировать работающие приложения. Всей этой информации зачастую достаточно, чтобы выявить аномалии или даже угрозы в сетевом трафике.
Netflow и SIEM: в чем сила, брат?
Что делать, если целевая система не генерит логи или они отключены злоумышленниками? Что делать, когда на целевой системе просто нет средств защиты, потому что они нагружают процессор и тормозят систему? Что делать, когда сотрудник приносит свое личное устройство, которое не заведено на SIEM? У нас остается единственный источник информации — сетевой трафик, который в любом случае генерится целевым устройством. Что может помочь идентифицировать «чистый» Netflow, который можно анализировать без SIEM, с помощью решений класса NTA (Network Traffic Analysis)? Вот небольшой список таких угроз и аномалий:
- вредоносный код, шифровальщики и криптомайнеры
- взаимодействие с командными серверами
- сканирование сети
- атаки “отказ в обслуживании”
- утечки данных
- взлом SSH или RDP
- работу торрентов и иных P2P-приложений
- аномалии в работе сервисов, характеризующие их компрометацию
- использование анонимайзеров
- и т.п.
А что дают вам логи, которые собирает ваш SIEM? Возможность мониторить пользовательскую активность на узлах, доступ к ресурсам, вход и выход в системы и из них, сигналы тревоги от сетевого оборудования и средств защиты, и многое другое. Комбинация логов и Netflow, поступающая на SIEM и анализируемая там, позволяет вам быстро идентифицировать новые сессии и новый трафик с только что атакованных устройств, в том числе и идущий в обход вашего периметра. Комбинируя эти типы данных, вы также можете идентифицировать некорректно настроенные средства сетевой безопасности. Netflow дополняет традиционные возможности SIEM способностью обнаружения новых типов трафика, его всплесков, взаимодействия с внешними и внутренними ресурсами, утечек данных, распространения вредоносного кода, взаимодействия с командными серверами, инкапсуляции вредоносной нагрузки в разрешенные протоколы и т.п.
Комбинация традиционно обрабатываемых SIEM данных с Netflow позволяет не только увидеть больше различных событий безопасности, но и увидеть их быстрее, снижая так называемый параметр TTD (Time-to-Detect) и, как следствие, время реагирования. Понятно, что SIEM и анализ Netflow могут работать независимо друг от друга и выполнять свою работу хорошо, но именно комбинация этих двух решений позволяет достичь синергетического эффекта.
Изменение шаблона поведения трафика может характеризовать подозрительное или аномальное поведение. Например, превышение порогового значения для загружаемых в Интернет данных может говорить об утечке. А изменение размера DNS-запросов и ответов по сравнению с предусмотренной RFC может характеризовать факт работы вредоносного кода (по статистике Cisco, DNS используется в 92% вредоносных программ для получения команд, выкачки данных или загрузки обновлений). Помните историю с Equifax? Тогда злоумышленники смогли получить доступ к Web-порталу, а потом к внутренним серверам баз данных, потихоньку выгружая большие объемы данных наружу. По отдельности, все эти события не представляли большого интереса и только собранные вместе и обогащенные данными Netflow, они позволили выявить инциденты ИБ. Это еще один кейс для систем анализа Netflow, которые могут выявлять нестандартное поведение и Web-портала, с которого учащаются запросу к БД, и БД, которые вдруг отдают много данных порталу. Я уже описывал этот сценарий на Хабре ранее. SIEM, получая данные Netflow, может получить дополнительный контекст для событий, создаваемых IPS, МСЭ, прокси, антивирусами, EDR и т.п., чтобы более эффективно реагировать на инцидент.
Другой пример. Обнаружение неизвестных атак для которых у систем обнаружения вторжений нет сигнатур — за счет корреляции сетевых аномалий и событий от хостов, а также срабатывании триггеров. Например, сканирование 100 узлов за 3 минуты может характеризовать работу вредоносного кода, расширяющего свой плацдарм. Увеличение времени отклика от сервера может характеризовать DDoS-атаку против него, а, например, несоответствие объема получаемой и отправляемой информации по протоколу DNS может говорить об утечке данных. Это кейс мы уже рассматривали ранее, когда я рассказывал об обнаружении кампании DNSpionage. При этом вы можете обратить внимание, что в одном случае мы анализировали только Netflow, а в другом — собирали данные еще и с оконечных устройств, песочницы, DNS-шлюза и т.п.
Еще одной областью, где интеграция Netflow в SIEM может помочь, — это ситуационная осведомленность. Корреляция потоков с логами, контекстом, геолокационной информацией, активностью пользователей, репутационными данными. Например, в прошлой заметке, я приводил кейс с обнаружением внутреннего трафика с узлами из Ирана или Северной Кореи. Если у вас нет контактов с этими странами, то возможно это признак работы вредоносного кода, крадущего информацию, или прогосударственных хакеров, нацелившихся на вашу компанию. Система анализа сетевых аномалий может сделать часть этой работы, выявив соответствующую аномалию. Но если вы хотите также понять, кто из пользователей участвовал в данном инциденте, вам понадобится дополнительный контекст в виде имен пользователей из Active Directory. Сам по себе Netflow этой информацией не оперирует — поэтому нам нужно обогатить его сведениями из AD. Если вы используете Cisco Stealthwatch, то вам для этого достаточно интегрировать его с Cisco ISE, который и будет увязывать IP- и MAC-адреса с конкретными пользователями и профилями устройств. А если в сети Cisco ISE не развернут? Задачу обогащения Netflow пользовательской информацией берет на себя SIEM.
Другой пример. У меня на компьютере запущен Web-сайт, используемый для ряда задач. Но многие ли рядовые пользователи могут похвастаться тем же? Вдруг вы фиксируете с пользовательского компьютера трафик, присущий работе Web-сервера? Или в сегменте, в котором находятся пользователи, работающие на ПК с Windows, вы вдруг видите трафик, присущий ОС Linux. Возможно, это “рукастый” пользователь решил поднять виртуалку с Linux, нарушив тем самым политику безопасности? А еще вы можете выявить таким образом утилиты для удаленного доступа (например, RAT), криптомайнеры, облачные или пиринговые приложения и т.п.
Если вы сторонник моновендорного подхода, то строительство системы защиты на базе решений Cisco, позволит вам снизить зависимость от SIEM, — все решения Cisco, включая межсетевые экраны, средства защиты e-mail, песочница, решение по защите ПК (Cisco AMP for Endpoints) и т.п. могут обмениваться данными, контекстом, событиями безопасности, командами между собой напрямую. Но если ваша инфраструктура унаследовала множество разных решений от разных производителей, то именно SIEM будет тем связующим звеном, который поможет построить из зоопарка разных продуктов целостное решение. В любом случае, анализ сетевого трафика, собираемый с существующей сетевой инфраструктуры, комбинированный с данными, которые обычно собирает SIEM, расширяет
Преимущества использования Netflow в SIEM:
- корреляция сетевой активности с другой информацией по ИБ, собираемой с уровня приложений и ПК/серверов
- возможность мониторинга там, где высоки риски нарушения законодательства о приватности (например, GDPR) и анализировать можно только заголовки или метаданные сетевого трафика, а не его содержимое
- обнаружение аномалий, характеризующих первые этапы развития инцидента или целевые атаки
- сбор и хранение различных данных, характеризующих инцидент, и предоставление их в рамках проведения расследований ИБ или взаимодействия с правоохранительными органами.
Серебряная пуля?
Но не стоит думать, что Netflow — это серебряная пуля, которую все так давно ищут. У него есть и недостатки. Например, его обработка может нагружать процессор и память устаревшего или неверно выбранного сетевого оборудования и это может негативно сказаться на его производительности и пропускной способности сети. Чтобы эффективно работать с Netflow вам может понадобиться его аппаратная поддержка или использование так называемых экспортеров, которые пропуская трафик через себя будут транслировать его в Netflow (кто сталкивался с внедрением IDS/СОВ в коммутируемых сетях, использовал для схожей задача так называемые tap'ы или разветвители). Я уже выше приводил два примера таких внешних решений — Cisco Stealthwatch Flow Sensor и Cisco Netflow Generation Appliance. Хотя при условии недавней модернизации сети, можно предположить, что ваши коммутаторы и маршрутизаторы уже поддерживают те или иные варианты Netflow и никаких дополнительных экспортеров вам не понадобится.
К другим особенностям Netflow, о которых стоит знать, я бы отнес:
- ложные срабатывания, которые могут быть связаны как с неправильным или недостаточным обучением системы анализа, так и с изменением ИТ-операций, о котором система анализа еще «не поставлена в известность»
- снижение производительности и влияние на хранилище SIEM (об этом мы поговорим еще дальше)
- метаданные, собираемые в рамках Netflow, не всегда позволяют проводить полноценное расследование, для которого может понадобиться сырой трафик в формате PCAP.
Варианты интеграции SIEM с Netflow
Какие из представленных сегодня на рынке SIEM работают с сетевым трафиком? Надо сказать, что почти все, но по-разному и часто это требует отдельной платной лицензии, которые, в свою очередь, тоже подразделяются на варианты. Я бы выделил три варианта анализа Netflow в SIEM:
- встроенная поддержка Netflow в SIEM
- наличие собственных экспортеров/сенсоров для генерации Netflow и передачи в SIEM
- интеграция SIEM с внешними решениями класса Network Traffic Analysis (NTA).
SIEM с встроенной поддержкой Netflow
Встроенная поддержка Netflow есть, например, у Microfocus ArcSight, достаточно популярном на постсоветском пространстве SIEM. Такая возможность позволяет SIEM на лету проводить корреляцию сетевых потоков с другими событиями безопасности или обогащать их данными из источников Threat Intelligence. Однако у данного варианта есть и свои недостатки, а именно:
- Во-первых, вам придется хранить не только события от средств защиты, но и всю сетевую телеметрию. Насколько вы готовы к росту объема хранимых данных (о том, «сколько данных надо хранить», мы поговорим далее)?
- Во-вторых, гонять Netflow в SIEM, который может находиться на значительном удалении от точки генерации Netflow может быть достаточно накладным. Насколько ваша архитектура готова к этому? Поддерживает ли ваш SIEM многоуровневую архитектуру, позволяющую расставить точки сбора событий и потоков как можно ближе к местам их генерации, например, в удаленных офисах? Или вам все-таки придется гонять «сырой» Netflow из удаленных площадок в центр?
- В-третьих, сетевой трафик может быть зашифрованным. Как вы планируете анализировать его? Вам придется его исключить из анализа или предварительно пропускать через соответствующий терминирующий VPN-шлюз (и то не для всех типов трафика).
- В-четвертых, как лицензируется анализ Netflow в вашем SIEM и сколько FPS он поддерживает?
- Наконец, еще одна сложность заключается в том, что flow-протоколов существует больше одного (см. выше таблицу). Если бы речь шла только о Netflow, то можно было бы просто интегрировать его поддержку в SIEM. Но даже Netflow у нас существует несколько версий — v5, которая является наиболее распространенной сегодня, и v9, которая расширена за счет поддержки IPv6, MPLS и др. А ведь есть еще Flexible Netflow (расширение Netflow v9), IPFIX, который часто называет Netflow v10, sFlow, поддерживаемый, например, некоторыми российскими производителями сетевого оборудования, NetStream, Jflow и т.д. Какие из этих вариантов поддерживает ваше сетевое оборудование и ваш SIEM?
Если вы только стоите перед выбором SIEM, то включите в список рассматриваемых параметров еще и тип Netflow, который генерится вашим оборудованием. Если у вас SIEM уже куплен, то у вас не так много выбора. В этом случае вам стоит рассмотреть следующие варианты:
- отдельный анализатор сетевых аномалий ИБ (например, Cisco Stealthwatch), который будет проводить весь анализ самостоятельно, а на SIEM отдавать уже его результаты
- отдельный коллектор Netflow, который сможет отдавать в SIEM сводную аналитику по сетевым потокам, а SIEM уже будет анализировать эти данные.
Сколько вешать в граммах, то есть хранить в байтах?
Кстати, прежде чем мы перейдем к следующему варианту интеграции Netflow с SIEM пора коснуться вопроса, а сколько данных Netflow мы будем получать в нашу систему анализа событий безопасности? Для средств защиты или обычных логов существует немалое количество примеров и статистики по EPS (events per second). Данных по FPS (flow per second) не так много. Средний объем Netflow прямо пропорционален числу уникальных TCP/UDP-сокетов, создаваемых клиентскими устройствами и серверами в вашей сети, которые могут сильно разнится от случая к случаю. Да и включение семплирования (то есть выборочной передачи данных Netflow) тоже влияет на итоговый объем данных.
Так сколько же FPS у нас может генериться? Конечно, это сильно зависит от ситуации, но я бы назвал, что для обычной рабочей станции это число равно, в среднем, 1.5 FPS, и 6 FPS при пиковой нагрузке. Иными словами, если в вашей сети 10 тысяч узлов и среднее значение FPS для каждого из них составляет 4, то сеть генерит около 40 тысяч потоков в секунду. Почему так много? Как я написал выше, это зависит от того, насколько много уникальных соединений генерят ваши приложения или ваша сеть. А сегодня на компьютерах пользователей работает очень много “болтливых” программ, которые либо активно подгружают контент из Интернета, например, браузеры, либо постоянно проверяя обновления, например, антивирусы. Вот примерный список ПО и сервисов, которое активно повышает число FPS в сети:
- Adobe, антивирусы, Java
- Skype
- почтовые клиенты
- NetBIOS
- браузеры
- приложения, ориентированные на фиды (Twitter, новости, Telegram и т.п.).
Более точный ответ вам подскажет анализ Netflow в нужных вам сегментах сети, что делается всего одной командой на сетевом устройстве (зависит от производителя).
Длина одной записи Netflow v5 составляет 48 байт. Для 9-й версии Netflow такой точной цифры не существует, так как эта версия позволяет описывать то, что вы будете включать в запись и поэтому ее длина может сильно варьироваться. Но если, очень грубо, взять 100 байт за среднюю длину записи о потоке (а каждый сетевой пакет может генерить 20-30 потоков), то можно прикинуть, какой объем данных будет генериться и поступать на SIEM. При этом объем хранилища SIEM под эти данные может быть больше (это будет зависеть от формата хранения, индексации, сжатия, резервирования и т.п.). Кстати, рассчитывая количество FPS помните, что в рамках какой-нибудь DDoS-атаки понятие “среднее число FPS” не работает, так как каждое соединение, каждый TCP SYN-пакет, будут представлять собой отдельный поток и при мощной DDoS-атаке число FPS в пике у вас будет очень большим.
Выше я упомянул, что в случае с передачей Netflow на центральный SIEM, вам придется «гонять» его через Интернет. Не стоит думать, что генерация Netflow создаст огромную нагрузку на сеть и снизит ее пропускную способность. Согласно нашим исследованиям, так как в Netflow передается только информация по заголовку и дополнительная телеметрия, а не все тело данных, рост нагрузки составит около 1-2% на интерфейс, с которого экспортируется сетевая телеметрия (на самом деле при использовании семплирования и современных версий протокола Netflow это значение может быть меньше еще на порядок и варьироваться на уровне 0,1%).
Собирать нельзя анализировать
Но, допустим, вы все-таки решили завести «сырой» Netflow на свой SIEM. У данного сценария есть и еще один нюанс. Очень важно понимать, что недостаточно наличия поддержки Netflow в SIEM; крайне важно уметь этот Netflow обрабатывать с точки зрения безопасности, то есть иметь встроенные и постоянно обновляемые под новые типы атак правила анализа и корреляции потоков Netflow. Допустим, Netflow нам выдает вот такую картину:
Мы видим всплеск по протоколу SSH. На самом деле такую же картину мы сейчас наблюдаем с атаками на протокол RDP. Это подбор пароля. Но выявить это можно только при условии, что у нас есть соответствующее правило, которое из множества потоков Netflow соберет одно событие “Подбор пароля”. Тогда можно говорить о том, что SIEM у нас имеет встроенную поддержку Netflow и может его анализировать с точки зрения безопасности. Поэтому выбирая этот путь, стоит поинтересоваться у продавца, что может анализировать SIEM в Netflow “из коробки” и, если ничего, то насколько трудоемок процесс описания собственных обработчиков Netflow и есть ли у вас в штате специалисты, которые будут это делать. Мы же прекрасно понимаем, что написать коннектор к Netflow не так уж и сложно, в отличие от правил его обработки и выявления в нем аномалий, требующих постоянной работы. Это примерно как скопипастить чужой движок для своей IDS (Snort, Zeek или Suricata), но не уметь на постоянной основе писать сигнатуры для вновь обнаруживаемых эксплойтов и атак. В примере выше, система должна сама распознать всплеск трафика по SSH и сама сказать, что это атак «подбор пароля» на SSH (или Telnet, или RDP, или FTP). Это может выглядеть так (на примере Cisco Stealthwatch Enterprise):
А уже потом можно проводить расследование данного инцидента на более глубоком уровне, используя возможности, предоставляемые или SIEM, или отдельным средством анализа Netflow. Без умения «понимать» Netflow с точки зрения ИБ, наличие встроенной поддержки Netflow является сомнительным преимуществом для SIEM.
SIEM с собственным экспортером Netflow
Другой игрок SIEM-рынка, LogRhythm, в свою очередь, предлагает дополнительный экспортер потоков NetMon, что может быть полезно в распределенной инфраструктуре, а также в сети, оборудование которой не поддерживает Netflow и требуется отдельный генератор Netflow для пропускаемого через него сетевого трафика. По сути, в данном варианте производитель SIEM берет на себя функции сетевых вендоров, разрабатывая решение для генерации Netflow и снижения нагрузки на SIEM, который освобождается от необходимости обрабатывать и хранить сырой Netflow. Ситуация схожа с поддержкой функции SSL Offload на многих межсетевых экранах нового поколения. Да, она там существует, но при интенсивном обмене HTTPS-трафиком, дополнительная нагрузка на NGFW приводит к существенному снижению его пропускной способности. Поэтому в высоконагруженных архитектурах под эту задачу обычно выделяют отдельное устройство, которое и берет на себя задачу расшифрования SSL-трафика с последующей его отдачей на NGFW. Тоже самое происходит и с обработкой Netflow на SIEM в данном сценарии.
Понятно, что у такого сценария есть и недостаток — рост итоговой цены решения, так как помимо оплаты лицензий по количеству анализируемых FPS, понадобится платить и за дополнительные сенсоры, которые будут пропускать через себя трафик и генерить Netflow. Кроме того, понадобится вносить изменения в сетевую архитектуру, но это придется делать в любом случае, так что я бы назвал это не недостатком, а особенностью этого сценария. Если ваше сетевое оборудование не умеет генерить Netflow, а вы хотите анализировать сетевые аномалии, то единственный вариант сделать это — использовать отдельные сенсоры. Вопрос только в том, что будет дешевле — покупать сенсоры от производителя SIEM или задействовать сенсоры от сетевых производителей (например, Cisco Netflow Generation Appliance) или разработчиков средств анализа сетевых аномалий (например, Cisco Stealthwatch Enterprise Flow Sensor). В этом варианте тоже стоит узнать, умеет ли SIEM анализировать Netflow с точки зрения ИБ или у него есть просто коннекторы в виде вынесенных вовне экспортеров/сенсоров (обычно умеет)?
SIEM, интегрированный с NTA
Третий вариант, интеграция с решениями класса NTA, является достаточно очевидным, так как, по сути, NTA является таким же генератором событий безопасности как и NGFW, антивирус, сканер безопасности, IPS и т.п. Этот сценарий, однако, интересен тем, что вы объединяете два имеющихся у вас инструмента аналитики ИБ, но можете работать с ними и отдельно. NTA позволяет вам проводить глубокий анализ сетевого трафика, выявлять вредоносный код, DDoS-атаки, утечки информации, контролиировать удаленных пользователей… При этом, хорошее средство анализа сетевого трафика также позволяет вам использовать отдельные сенсоры в тех сегментах, где сетевое оборудование не поддерживает Netflow или его включение приводит к росту нагрузки на сетевое оборудование. NTA в этом сценарии позволяет агрегировать, обрабатывать, анализировать Netflow (в разных его версиях), а на SIEM отдавать только сигналы тревоги по факту обнаружения той или иной вредоносной активности. Очевидно, что этот вариант также имеет смысл задействовать, когда у вас или у ваших ИТшников уже есть решение класса NTA для сетевого траблшутинга и его можно задействовать и под задачи сетевой безопасности. Или когда, наоборот, вы хотите поделить траты на решение NTA с вашими сетевиками, которые будут использовать его для своих задач, а вы для своих.
Недостатком этого варианта является дополнительная стоимость решения класса NTA, а также необходимость двойного обучения специалистов основам работы с двумя разными решениями. Но зато отдельное решение для анализа сетевого трафика позволит проводить более глубокие расследования инцидентов, чем при наличии одного лишь SIEM с встроенной поддержкой Netflow, и более гибкие варианты применения, чем с вариантом наличия отдельных сенсоров Netflow у производителя SIEM. Но стоит помнить, что когда мы говорим об отдельном решении класса NTA, я имею ввиду именно решение по безопасности, а не просто инструмент по анализу сетевого трафика или мониторинга производительности сети. Например, уже упомянутый ранее SolarWinds NTA неплохо анализирует сетевой трафик с целью поддержки ИТ-задач, но очень плохо это делает для целей ИБ. Тоже касается 5View от InfoVista или Visual TruView от Fluke. А тот же, например, Cisco Stealthwatch Enterprise может быть использован и тем и другим подразделением в компании.
На что обратить внимание при выборе?
Выбирая решение NTA для целей безопасности, а также анализируя экспортеры/сенсоры, предоставляемые вендорами SIEM или SIEM с поддержкой Netflow, я бы порекомендовал обратить внимание на следующие критерии:
- Типы обнаруживаемой вредоносной активности. Вы берете средство мониторинга ИБ; логично предположить, что оно должно уметь выявлять различные аномалии и угрозы, имеющие отношение к ИБ, «из коробки». Причем этот параметр разбивается на три части — встроенные алгоритмы обнаружения различных типов угроз ИБ, написание собственных обработчиков/правил и поддержка внешних источников Threat Intelligence для обогащения анализируемых потоков данными об угрозах.
- Поддерживаемые протоколы Netflow. Очевидно, что они должны совпадать с тем, что генерится вашим сетевым оборудованием сейчас и что может генериться в будущем.
- Производительность. Сколько потоков может быть получено, обработано и сохранено за 1 секунду (тот самый показатель FPS)? Если ваша сеть генерит 60 тысяч FPS, а NTA рассчитан на 40 тысяч, то вам придется докупать еще один коллектор, что по цене может обойтись дороже, чем один коллектор, например, на 80 тысяч FPS.
- Формат хранения. Проприретарный, flat, СУБД… От этого зависит не только объем хранимых данных, но и возможность доступа к ним со стороны сторонних приложений. Кстати, относительно СУБД. Они бывают тоже разные. Бывают классические, хранящие потоки в отдельных строках СУБД (так, например, работает Argus, Fluke, Plixer, Riverbed или SolarWinds), а есть те, которые хранят данные в столбцах СУБД. В последнем случае СУБД может более эффективно работать с запросами к хранящейся информации, которые будут более быстрыми и более гибкими. В таких СУБД вам не нужно сканировать каждую строку по отдельности, отбрасывая ненужные; вы сразу работаете со строками, у которых в столбце содержатся нужные данные. Так организовано хранение данных о потоках, например, у Cisco Stealthwatch.
- Дедупликация данных. Если вы собираете потоки с разных точек вашей сети, то у вас всегда будет ситуация, когда одна сессия будет описана потоками, полученными с разных сетевых устройств, через которые эта сессия проходит. Умение собрать все такие потоки воедино и отсечь повторяющуюся информацию — большой плюс в системах NTA. Это было одним из оснований, почему Cisco в свое время отказалась от решения nfdump и OSU FlowTools и перешла на продукцию компании Lancope, позже нами купленной и вошедшей в состав нашего портфолио по ИБ.
- Возможности работы с потоками. Тут важно понимать, что слабые или неполные возможности по экспорту сетевых данных могут привести к потере или необнаружению какой-либо важной для ИБ информации. Поэтому важно обратить внимание на следующие возможности:
- Пропускная способность экспортера/сенсора
- Размер flow cache (не путать с cash flow :-)
- Поддерживаемые атрибуты сетевого трафика. Многие поддерживают MAC-адреса, теги VLAN, метки MPLS, флаги TCP, но, например, не умеют экспортировать данные о приложениях или, поддерживая временные метки в секундах, не позволяют детализировать их до наносекунд (хотя стандарт IPFIX это поддерживает).
- Интеграция с другими системами. В данной статье мы рассматриваем возможность анализа Netflow в SIEM, поэтому интеграция с SIEM у NTA должна быть. А также, возможно, и с другими решениями (например, для проведения расследования) через REST API, syslog и т.п.
Если бы речь шла о том, что выбирать независимо от SIEM, то я бы еще посоветовал посмотреть в сторону возможностей по threat hunting, которые предоставляет выбираемое решение. Но так как тема заметки выбрана немного другая, то этому аспекту мы внимание уделять сейчас не будем.
Вопрос цены
Если на эти три варианта посмотреть с точки зрения их стоимости, то наиболее дорогим с точки зрения капитальных затрат (при условии одинаковых возможностей по анализу Netflow во всех трех сценариях) окажется третий вариант. Оно и понятно. Помимо стоимости SIEM вам понадобится отдельное решение по анализу сетевого трафика, которое будет состоять, минимум, из системы управления и нужного количества коллекторов, собирающих Netflow с разных экспортеров/сенсоров. С другой стороны, как бы вы не расширяли потом покрытие своей сети новыми экспортерами/сенсорами, на стоимости SIEM и инфраструктуры для него это никак не скажется, так как он будет работать с уже обработанными сигналами тревоги, а не с “сырыми” потоками Netflow, которых (сигналов) будет на несколько порядков меньше.
Первый вариант выглядит самым привлекательным с точки зрения его цены, так как нам не надо дополнительно платить ни за обучение аналитиков и администраторов NTA, ни за дополнительные экспортеры/сенсоры; знай, передавай потоки Netflow в SIEM и все. Однако у вас сильно возрастет стоимость инфраструктуры для SIEM, так как придется хранить “сырые” потоки Netflow, что потребует расширения имеющегося хранилища. Второй вариант является промежуточным между двумя крайними — как с точки зрения возможностей по анализу Netflow, так и с точки зрения стоимости. В любом случае, в первых двух вариантах стоит уточнять у производителя SIEM совокупную стоимость владения решением исходя из стоящих задач, а также текущего и ожидаемого показателя FPS и, как следствие, изменения стоимости лицензий для SIEM и хранилища для него. Возьмем, к примеру, LogRhythm и его подсистему для анализа Netflow. Существует минимум три варианта его реализации и, как следствие, ценообразования. Самый младший вариант, Freemium может отдавать в SIEM только сигналы тревоги, пропускная способность не может превышать 1 ГБит/с, объем хранилища составляет всего 1 Гб (это около одного дня хранения Netflow без семплирования), срок хранения индекса не больше 3-х дней, а также отсутствует корреляция с дополнительными источниками данных, а поддержка работает только онлайн и через community. В следующей версии, NetMon, показатели лучше (пропускная способность до 10 ГБит/с на все экспортеры, хранилище не ограничено, индекс сохраняется до месяца, но корреляции с другими источниками тоже нет). И только в премиум-версии NetworkXDR у вас никаких ограничений нет, но стоит она как “километр московских дорог”, то есть недешево.
В одном из проектов мы столкнулись с тем, что при ежедневном объеме сетевой телеметрии в 1 ТБ и отправки его в SIEM с встроенной поддержкой Netflow итоговая стоимость решения составила около 600 тысяч американских долларов (еще до очередного скачка курса). При этом часть этих данных оставалась необработанной из-за отсутствия в SIEM соответствующих правил и дублирующей. Применение отдельного NTA-решения (в нашем случае это был Cisco Stealthwatch Enterprise) привело к снижению объема передаваемых в SIEM данных на 80%, а стоимость решения упала до 99 тысяч долларов США. Математика может отличаться от проекта к проекту, но мы заметили, что чем больше Netflow нам надо обрабатывать, тем дороже будет обходиться инфраструктура SIEM для его обработки. Почему так?
Давайте посмотрим на один из примеров. Когда пользователь подключается к серверу, с точки зрения классического анализа событий ИБ мы имеем дело, условно, всего с одним событием, которое мы “снимаем” с сервера, отправляя его, например, по syslog на SIEM (на самом деле событий будет два — попытка подключения и ее результат). Если это событие разложить на сетевые составляющие, то мы увидим, что потоков будет сгенерировано на порядок больше. Для примера, среднее число “хопов” (hop) от клиента к серверу составляет в среднестатистической сети 5-6. Каждый коммутатор или маршрутизатор, через который проходит запрос от клиента в сторону сервера, генерит свои записи Netflow, описывающие проходящий трафик. Причем делается это для каждого направления сессии (запрос и ответ) отдельно. Получается, что там, где на прикладном уровне было сгенерировано всего 1-2 события, потоков Netflow понадобилось минимум в 10 раз больше (на самом деле еще больше, так один сетевой пакет генерит порядка 20-30 потоков Netflow). И мало того, что мы должны будем заплатить за все эти десятки потоков (хотя событие по-прежнему одно) и выделить место для их хранения. Так еще и SIEM должен будет их обработать, убрать дубли, объединить разнонаправленные потоки в рамках одной сессии и только потом уже коррелировать эти данные с другими событиями. Поэтому совокупная стоимость казалось бы очевидного решения может оказаться выше, чем в случае с вынесенным отдельно экспортером Netflow или самостоятельным решением по анализу сетевых аномалий, интегрированными с SIEM.
А использоваться такие внешние Netflow-анализаторы могут в одном из двух сценариев. Первый — передача в SIEM оптимизированной телеметрии, очищенной от повторов (дедуплицированной), объединяющей разнонаправленные потоки. Опираясь на наш опыт (а Stealthwatch Enterprise может работать в таком режиме), могу сказать, что это дает шестикратное сокращение объема телеметрии, передаваемой на SIEM, который, в данном сценарии, должен все равно уметь анализировать Netflow с точки зрения безопасности.
Второй сценарий подразумевает, что вся обработка осуществляется на решении класса NTA, а в SIEM поступают только сигналы тревоги, полученные в результате обработки Netflow. Этот вариант позволяет сократить еще больше данных, отправляемых на SIEM, снижая затраты на его лицензии и инфраструктуру. Да и от SIEMа уже не требуется умение анализировать «сырой» Netflow, что расширяет возможности по выбору средств анализа событий ИБ.
Есть ли альтернативы?
Рассмотрев варианты использования Netflow в SIEM для обнаружения большего числа событий безопасности, чем без Netflow, давайте посмотрим на возможные альтернативы.
Средства сетевой диагностики
Вы можете попробовать использовать средства сетевой диагностики, применяемые для оценки пропускной способности сети, доступности внутренних узлов и сегментов, пиковых нагрузок и т.п. Например, SolarWinds NetFlow Traffic Analyzer. Эти решения не предназначены для обнаружения аномалий и угроз ИБ, но их можно задействовать для передачи flow-информации на SIEM, который может иметь возможность анализа Netflow. Это нагрузит SIEM, как я уже описывал выше, и вам придется решать, готовы ли вы к этому? Правда, предварительно стоит уточнить, может ли сетевой анализатор отдавать данные Netflow во внешние системы. Иногда они могут отдавать вовне только сводную статистику или генерить сигналы тревоги, чего явно недостаточно для задач ИБ.
Системы обнаружения вторжений и NGFW
Сетевые IPS и NGFW являются иной альтернативой. Они могут заглянуть внутрь сетевого трафика и могут обнаруживать многие угрозы за счет механизма глубокой инспекции сети… но на периметре. Все-таки обычно NGFW и IPS ставятся на границе корпоративной сети и Интернет и видят только то, что проходит через них. Наставить эти устройства, “железные” или виртуальные, в каждом интересующем вас месте будет слишком накладно, а в ряде случаев и невозможно технически. Говоря о границе или периметре, стоит помнить, что стык между корпоративным ЦОДом и пользовательскими сегментами — это тоже граница. И стык между корпоративной и промышленной сетью тоже. Но в любом случае, установка дополнительных сенсоров IPS или NGFW может больно ударить по кошельку, в то время как Netflow будет собираться с уже купленного и внедренного сетевого оборудования.
Средства расследования сетевых инцидентов
Решения класса NFT (Network Forensics Tool) позволяют хранить, обрабатывать и анализировать сетевой трафик в целях рассследования инцидентов. Но между этим типом решения и NTA есть существенное отличие — NFT работает с полной копией трафика, то есть обычно с PCAP-файлами, а NTA — с записями о нем. И если решения по анализу Netflow работают практически в реальном времени, то NFT — с существенной задержкой. Кроме того, любое решение, которое работает с PCAP (или с иным способом захватывать и сохранять копию всего сетевого трафика), столкнется с проблемой места для хранения всех собранных данных.
Представьте, что у вас есть порт на сетевом устройстве на 1 Гбит/сек. При длине пакета в 64 байта этот порт сможет пропустить через себя 1953125 пакетов в секунду, а при длине в 1500 байт — 83333 пакетов. То есть в зависимости от длины пакета (а это зависит от приложений в сети) у нас будет проходить от примерно 80 тысяч до 2 миллионов пакетов в секунду, которые нам надо будет сохранять. В день такой порт пропустит через себя 86400 Гбит/с или почти 11 ТБ. За год набежит почти 4 ПБ и это только для одного порта, которых у нас может быть в сети тысячи и десятки тысяч. Даже выборочное хранение трафика не сильно облегчит нашу жизнь. Поэтому решения класса NFT нужны, но заменить собой анализаторы Netflow они не в состоянии. Это инструменты, решающие разные задачи, — мониторинг и расследование инцидентов. Обычно эти решения работают в паре — Netflow позволяет выявлять нам инциденты, а NFT уже собирает детальные данные по ним в виде захвата всего сетевого трафика.
"А вот есть SIEM с функцией NFT, например, IBM QRadar Incident Forensics или RSA Security Analytics, которые позволяют работать с полной копией сетевого трафика и все мета-данные Netflow автоматически будут доступны в SIEM". Да, есть! Помимо этого, преимуществом такого решения является возможность реконструкции всех интересующих сетевых сессий и их визуализация, что может облегчить расследование инцидентов. Такой SIEM позволяет встать на место злоумышленника и увидеть все то, что видит он. Но за этим достоинством скрывается и серьезный недостаток, который я уже упоминал выше, — на хранение полной копии сетевого трафика требуется большое, нет, не так, огромное хранилище, которое может по цене встать как отдельный SIEM, а то и больше (больше, чем хранение даже просто сырого Netflow). Вам может понадобиться выбрать, какие конкретно сессии сохранять для экономии места, а это может привести к тому, что какой-то трафик будет потерян. Кроме того, в условиях выполнения законодательных требований по хранению данных, связанных с инцидентами, вам придется нарушить их или платить дополнительные деньги за хранилище. Еще одна особенность такого решения — необходимость сохранять в SIEM уже расшифрованный трафик, а значит вам понадобится пересмотреть архитектуру своей системы мониторинга, чтобы иметь возможность расшифровывать трафик и подавать его в SIEM. И не забывайте, что такие решения все-таки ориентированы на проведение расследований, что требует квалифицированного персонала, а не на обнаружении аномалий и угроз по готовым алгоритмам.
В данном сценарии я бы все таки смотрел на первичный анализ сетевого трафика с помощью Netflow, а уже потом, для интересующих меня событий и инцидентов, включал запись сетевого трафика. Это позволит сэкономить и не тратить ресурсы на хранение «всего».
Заключение
Итак, подводя краткие итоги. Netflow является ценнейшим источником данных для мониторинга безопасности корпоративных и ведомственных сетей, зачастую единственным, который может быть собран и на базе которого можно принимать решения о наличии или отсутствии угроз в вашем окружении. В принципе Netflow можно анализировать и самостоятельно с помощью решений класса NTA, которые, обладая большой базой правил и алгоритмов выявления вредоносной и аномальной активности, способны оперативно обнаруживать инциденты и реагировать на них. Интеграция же Netflow с данными, собираемыми SIEM, дает нам гораздо больше. SIEM начинает видеть то, чего не видел до этого и видеть это гораздо раньше, чем нам может быть нанесен ущерб. При этом нам не надо вносить сильных изменений в существующую инфраструктуру мониторинга, так как сетевое оборудование у нас уже есть, — надо просто перенаправить Netflow на SIEM, напрямую или через промежуточные решения. Задействование Netflow также позволяет мне достигнуть маленькой, но быстрой победы, — почти все наши пилоты решения Cisco Stealthwatch Enterprise заканчиваются тем, что мы обнаруживаем те или иные нарушения политик ИБ, которые раньше не замечались службой ИБ. Netflow позволял их увидеть, а интеграция его с SIEM, получить синергетический эффект от применяемых средств мониторинга сетевой и системой активности.