Специалист Infosecurity по NTA-решениям Егор Микитюк рассказал Ciso Club об отношении российского рынка к NTA и его развитию
Автор воспользовался услугами нашумевшего ChatGPT и задал несколько вопросов в рамках материала.Определение NTA от искусственного интеллекта — Network Traffic Analysis (NTA) — это процесс мониторинга и анализа сетевого трафика, который происходит в организации. NTA может включать в себя исследование пакетов, анализ протоколов и другие методы, направленные на выявление неожиданных или нежелательных трендов в сетевых данных. На самом деле еще до введения определения NTA международным ИБ-сообществом эти системы уже существовали в виде сетевых сенсоров почти у всех ведущих производителей решений по защите от APT. В дальнейшем его вид формализовали и стандартизировали. В итоге, развиваясь в форматоре этих стандартов, NTA дошли до наших лет.
Рынок не хочет разбираться с NTA
Прародителей NTA уже давно используют в информационной безопасности и, честь по чести, некоторые вендоры так и не превратили свои сенсоры в полноценный анализатор сетевого трафика по современным стандартам. Стандарты стандартами, но у каждого разработчика есть свое видение развития продукта в рамках собственных экосистем. В том числе это касается отечественного рынка, где сильные не только вендоры, но и аналитики в сфере информационной безопасности, поэтому ожидания от игроков рынка NTA относительно высокие.
Прежде чем рассуждать о разнообразии баз решающих правил NTA, стоит разобраться, что же составляет ядро NTA, а именно на основе чего решение выявляет атаки. Окунувшись в дебри презентаций и брошюр, а также в практику использования, можно сделать вывод, что всё, что производители заявляют в своих материалах о базах знаний NTA, в конечном итоге является одним и тем же. По сути, всё это аналоги, не слишком отличающиеся друг от друга по результатам применения. «Вот это да!» — скажете вы. — «Маркетинг работает!». Автор считает, что он действительно работает, но не только в части позиционирования или продажи продукта. Неожиданно и сами пользователи решения по каким-то причинам начинают думать в том же ключе, что заложил вендор в своей технической брошюре. Это приводит к удивительным вещам, смысл которых можно уложить во фразе классика: «Чем больше сдадим, тем лучше».
Прежде чем рассуждать о разнообразии баз решающих правил NTA, стоит разобраться, что же составляет ядро NTA, а именно на основе чего решение выявляет атаки. Окунувшись в дебри презентаций и брошюр, а также в практику использования, можно сделать вывод, что всё, что производители заявляют в своих материалах о базах знаний NTA, в конечном итоге является одним и тем же. По сути, всё это аналоги, не слишком отличающиеся друг от друга по результатам применения. «Вот это да!» — скажете вы. — «Маркетинг работает!». Автор считает, что он действительно работает, но не только в части позиционирования или продажи продукта. Неожиданно и сами пользователи решения по каким-то причинам начинают думать в том же ключе, что заложил вендор в своей технической брошюре. Это приводит к удивительным вещам, смысл которых можно уложить во фразе классика: «Чем больше сдадим, тем лучше».
Вот вам общие тематики наполнения брошюр вендоров:
Перечень характеристик любого NTA обнаруживает огромное количество функционала. Ведь бытует мнение, что чем длиннее список фич, тем лучше и эффективнее решение. Но на самом деле единственная вещь, которая должна интересовать пользователя в первую очередь – как NTA выявляет или отражает воздействия APT-атаки в сети. Причем нужно обратить внимание, что мы работаем с решением по защите от APT, а не с решением по выявлению URL по базам, файлов в сети или фишинговых ссылок в сетевом трафике. Автор считает, что эпоха решений, которые включают в себя большое количество мелких и не всегда нужных фич, закончилась лет 10 назад, и наступила эпоха консолидации функциональных возможностей. Это в свою очередь ведет к упрощению предъявляемых требований к NTA, но при этом все еще требует держать в голове у специалиста по ИБ все дополнительные примочки (к сожалению), ибо консолидация пока не всеобъемлющая.
- Репутационные списки
- Базы URL – вредоносных / используемых в целевых атаках / фишинг URL
- Базы хэшей – вредоносов / ВПО / опасных файлов и т.п.
- Базы фишинг ресурсов
- Сигнатуры («О Боже мой»: воскликнет кто-то в 2023 году и будет не прав)
- ML классификаторы – тут вендоры проявляют массу изобретательности в названии
- Экспертные списки
- Прочее
Перечень характеристик любого NTA обнаруживает огромное количество функционала. Ведь бытует мнение, что чем длиннее список фич, тем лучше и эффективнее решение. Но на самом деле единственная вещь, которая должна интересовать пользователя в первую очередь – как NTA выявляет или отражает воздействия APT-атаки в сети. Причем нужно обратить внимание, что мы работаем с решением по защите от APT, а не с решением по выявлению URL по базам, файлов в сети или фишинговых ссылок в сетевом трафике. Автор считает, что эпоха решений, которые включают в себя большое количество мелких и не всегда нужных фич, закончилась лет 10 назад, и наступила эпоха консолидации функциональных возможностей. Это в свою очередь ведет к упрощению предъявляемых требований к NTA, но при этом все еще требует держать в голове у специалиста по ИБ все дополнительные примочки (к сожалению), ибо консолидация пока не всеобъемлющая.
Рынок не оценил по достоинству все возможности NTA
Наблюдая последние 4 года за работой специалистов с NTA, автор не может не подметить, что с момента, когда сетевые сенсоры начали называться этим славным выражением NTA, существенно ничего не изменилось. NTA не столько эволюционировали из сетевых сенсоров, сколько их вырастили специалисты в больших исследовательских корпорациях по ИБ в ожидании, что заявленные функции, например дампы сетевого трафика, хранимые на решении для сетевой форензики, будут востребованы в индустрии. Автор считает, что глобально этого не произошло. К сожалению для аналитиков, вендоры NTA усложнили свои решения, что привело либо к полному игнорированию новых функций NTA, либо к увеличению требований к аналитикам или привлечению дополнительных профильных специалистов к работе с NTA.
Отсюда вывод — у аналитика появились дополнительные функции (читайте — обязанности) при работе с NTA, в том числе дополнительный ручной труд. Конечно, сами вендоры вряд ли замышляли подобное, но в итоге мы имеем NTA, требующие выполнения постоянного монотонного ручного труда. И на рубеже первой четверти 21го века такие тенденции не могут не угнетать. Попробуем, попутно разбираясь в основных хитростях NTA, представить себе решение идеальное и даже гениальное.
Отсюда вывод — у аналитика появились дополнительные функции (читайте — обязанности) при работе с NTA, в том числе дополнительный ручной труд. Конечно, сами вендоры вряд ли замышляли подобное, но в итоге мы имеем NTA, требующие выполнения постоянного монотонного ручного труда. И на рубеже первой четверти 21го века такие тенденции не могут не угнетать. Попробуем, попутно разбираясь в основных хитростях NTA, представить себе решение идеальное и даже гениальное.
Сырой трафик и метаданные — насколько это оправданно?
Сбор данных из анализируемого трафика существовал и до введения термина NTA. В своё время специалисты пришли к выводу, что для более эффективной работы следует изучать и другие сессии от участников инцидента, а лучше вообще все. Это в свою очередь привело к созданию функций хранения как метаданных о сессиях, так и трафика в сыром виде. Причем каждый производитель оставил за собой право решать, что лучше всего подходит пользователю в рамках их NTA. В итоге каждый разработчик NTA может похвастаться либо возможностью хранить метаданные, либо сырой трафик, либо все вместе. Каждый делает это по-своему, исходя из специфики продукта.
Но, как показала практика использования, подобные функции крайне избыточны по СХД. Можете сами прикинуть, сколько занимает сырой трафик на потоке, скажем, в 200Мбит/c (достаточно стандартные объемы), за неделю при работе 24/7 (~14,8 TB). И тут возникает самый главный вопрос — каков период ротации таких СХД? На который ответа, по сути, нет. И переход к метаданным не спасает, потому что коэффициент «сжатия» сырого трафика колеблется от 0,3 до 0,6, что приводит ровно к тем же самым проблемам. В итоге для бизнеса это оборачивается удорожанием продукта за счет редко используемых функций, а для аналитика — более скрупулезным наблюдением за сработками, а значит, и к большему объему рутинной работы.
Кстати, автор имел счастье изучать тендерную документацию на anti-APT решение, в рамках которой предлагалось хранить сырой трафик за последние 30 дней и !заново! анализировать его после каждого обновления Баз решающих правил. А компания работала в масштабе всей страны. Стоимости СХД улетали в космос при таких условиях, поэтому в итоге из тендера эти требования удалили.
Решить проблему ограниченности ресурсов в принципе тяжело, и тем более это тяжело сейчас, в период санкционного давления. Но давайте подумаем, зачем вообще хранить трафик? Очевидно, из-за нехватки контекста при формировании сработок в NTA. Можно ли получать контекст автоматически, а не искать его вручную? Ответ – частично можно. В целом, весь объем контекста для анализа и не нужен, а значит и хранить всё подряд не имеет смысла (кстати, к этому сейчас идут некоторые производители NTA в РФ – отсекают лишние протоколы при хранении сессий). А значит NTA, опираясь на собственные базы решающих правил, может понимать, когда нужен контекст, а когда — нет.
Итак, у нас складывается образ хорошего NTA:
1. «Понимает», когда необходимо вычленять дополнительный контекст из сырого трафика, а когда — нет.
2. Автоматически вычленяет и хранит сырой трафик в случае, когда контекст необходим.
А если зайти еще дальше, то лишний контекст может не потребоваться в принципе, если NTA сможет определять весь набор достаточных показателей атаки в рамках Баз решающих правил. Это, безусловно, приводит к вопросу о качестве Баз. Сама по себе эта задача извечная, но у некоторых вендоров есть мнение по ее решению, поэтому ожидаем новостей.
Но, как показала практика использования, подобные функции крайне избыточны по СХД. Можете сами прикинуть, сколько занимает сырой трафик на потоке, скажем, в 200Мбит/c (достаточно стандартные объемы), за неделю при работе 24/7 (~14,8 TB). И тут возникает самый главный вопрос — каков период ротации таких СХД? На который ответа, по сути, нет. И переход к метаданным не спасает, потому что коэффициент «сжатия» сырого трафика колеблется от 0,3 до 0,6, что приводит ровно к тем же самым проблемам. В итоге для бизнеса это оборачивается удорожанием продукта за счет редко используемых функций, а для аналитика — более скрупулезным наблюдением за сработками, а значит, и к большему объему рутинной работы.
Кстати, автор имел счастье изучать тендерную документацию на anti-APT решение, в рамках которой предлагалось хранить сырой трафик за последние 30 дней и !заново! анализировать его после каждого обновления Баз решающих правил. А компания работала в масштабе всей страны. Стоимости СХД улетали в космос при таких условиях, поэтому в итоге из тендера эти требования удалили.
Решить проблему ограниченности ресурсов в принципе тяжело, и тем более это тяжело сейчас, в период санкционного давления. Но давайте подумаем, зачем вообще хранить трафик? Очевидно, из-за нехватки контекста при формировании сработок в NTA. Можно ли получать контекст автоматически, а не искать его вручную? Ответ – частично можно. В целом, весь объем контекста для анализа и не нужен, а значит и хранить всё подряд не имеет смысла (кстати, к этому сейчас идут некоторые производители NTA в РФ – отсекают лишние протоколы при хранении сессий). А значит NTA, опираясь на собственные базы решающих правил, может понимать, когда нужен контекст, а когда — нет.
Итак, у нас складывается образ хорошего NTA:
1. «Понимает», когда необходимо вычленять дополнительный контекст из сырого трафика, а когда — нет.
2. Автоматически вычленяет и хранит сырой трафик в случае, когда контекст необходим.
А если зайти еще дальше, то лишний контекст может не потребоваться в принципе, если NTA сможет определять весь набор достаточных показателей атаки в рамках Баз решающих правил. Это, безусловно, приводит к вопросу о качестве Баз. Сама по себе эта задача извечная, но у некоторых вендоров есть мнение по ее решению, поэтому ожидаем новостей.
Ответ искусственного интеллекта (ИИ) на вопрос «Считаешь ли ты, что сбор сырого трафика и метаданных являются избыточными функциями NTA?
Сбор сырого трафика и метаданных является одной из ключевых функций NTA, так как это позволяет анализировать трафик в режиме реального времени и выявлять потенциально вредоносные события. Без этой функции NTA не сможет корректно работать и предоставлять полезную информацию об угрозах. Однако, сбор больших объемов сырого трафика и метаданных может привести к избыточности данных, которые потребуется обрабатывать. Это может привести к увеличению нагрузки на систему и замедлению работы NTA. Поэтому, важно настроить NTA правильно, чтобы избежать сбора избыточных данных и обеспечить оптимальную производительность системы. Таким образом, сбор сырого трафика и метаданных не является избыточной функцией NTA, а наоборот, является необходимым компонентом системы для эффективного обнаружения угроз и защиты сетевой инфраструктуры.
Оно не блокирует?! Зачем оно мне?! Про kill-chain и специалистов по ИБ
Все еще можно услышать от некоторых Заказчиков вопрос «Зачем нам NTA, если он ничего не блокирует?» Удивительно, но похоже, что исследователи kill-chain и APT и производители anti-APT решений так и не донесли до бизнеса идею эффективного для ИБ выявления целевого воздействия именно на первых стадиях kill-chain.
Несмотря на то, что NTA не обеспечивает моментальную блокировку сложных атак, он весьма полезен для предотвращения серьезных инцидентов безопасности. Анализ трафика позволяет выявить подозрительное поведение и связи, которые могут указывать на наличие угрозы. Это может помочь организациям быстро определить, какие системы и данные могут быть подвержены риску, и предпринять необходимые меры для защиты своей инфраструктуры и ресурсов.
Сложные атаки по времени могут развиваться достаточно долго, и тот самый желанный момент блокировки возможен лишь в середине этого отрезка. NTA же способен обнаружить начало целевого воздействия на ранних стадиях, но не может на этом этапе его блокировать. Отсюда вытекает проблема в виде необходимости ручного труда в момент сработки NTA. С одной стороны, невозможность блокировки атаки в самом начале можно назвать недоработкой производителей, а с другой — последствием того, что бизнес не транслирует вендорам своих внятных пожеланий по части функционала NTA и не пытается модифицировать свои процессы ИБ так, чтобы быть максимально автоматизированными. К сожалению, консенсуса с бизнесом и ИТ по этому вопросу все еще нет. Да и автор за последние пару лет, если быть честным, так и не услышал мало-мальски вменяемого ТЗ на подобный функционал со стороны страждущих.
Несмотря на неопределенность постановки задачи некоторые вендоры последние пару лет ведут работу в направлении возможностей блокировки на ранних этапах. Что ж, ждём от производителей в РФ решения данного вопроса.
Сложные атаки по времени могут развиваться достаточно долго, и тот самый желанный момент блокировки возможен лишь в середине этого отрезка. NTA же способен обнаружить начало целевого воздействия на ранних стадиях, но не может на этом этапе его блокировать. Отсюда вытекает проблема в виде необходимости ручного труда в момент сработки NTA. С одной стороны, невозможность блокировки атаки в самом начале можно назвать недоработкой производителей, а с другой — последствием того, что бизнес не транслирует вендорам своих внятных пожеланий по части функционала NTA и не пытается модифицировать свои процессы ИБ так, чтобы быть максимально автоматизированными. К сожалению, консенсуса с бизнесом и ИТ по этому вопросу все еще нет. Да и автор за последние пару лет, если быть честным, так и не услышал мало-мальски вменяемого ТЗ на подобный функционал со стороны страждущих.
Несмотря на неопределенность постановки задачи некоторые вендоры последние пару лет ведут работу в направлении возможностей блокировки на ранних этапах. Что ж, ждём от производителей в РФ решения данного вопроса.
Минимум нагрузки на ИБ-специалистов и максимум полезных функций — образ идеального NTA для рынка
Стандарт NTA достаточно строго прописан в международных исследовательских организациях типа Gartner. Этот стандарт включает в себя не только функции, описанные выше, но и статистический анализ сетевого потока, и поведенческие движки и многое другое. Но и сверх фич, описанных стандартом, в NTA полно иных сопряженных функций. Тут вендоры проявляют массу изобретательности, оснащая свои NTA уникальными фичами, призванными выделяться среди конкурентов. Только вот, вспоминая о проблемах отсутствия автоматизации, можно сделать вывод, что на эти фичи банально не хватит аналитического ресурса. Как правило, наличие таких функций добавляет решению веса в глазах пользователей, и все эти дополнительные фичи теоретически могут быть действительно полезными, но только если решить проблемы автоматизации и внутренней аналитической наполненности NTA. В текущей же практике специалистов ИБ, содержащей и без того избыточный ручной труд, они нередко оказываются ненужными.
Ответ ИИ на вопрос «Каким, на твой взгляд, должен быть идеальный NTA с учетом возможных будущих разработок?»
- Идеальный NTA должен обладать несколькими важными характеристиками:
- Высокая точность обнаружения: NTA должен быть в состоянии точно идентифицировать потенциально вредоносный трафик и отличать его от нормального трафика.
- Широкий охват угроз: NTA должен обнаруживать различные типы угроз, включая известные и неизвестные угрозы, а также сложные атаки.
- Мгновенная реакция: NTA должен быть в состоянии быстро реагировать на угрозы и принимать меры для минимизации ущерба.
- Понятный интерфейс: NTA должен иметь интуитивно понятный интерфейс для удобного использования и анализа результатов.
- Поддержка современных протоколов: NTA должен поддерживать все современные сетевые протоколы и быть гибким для адаптации к изменяющимся требованиям сетевой инфраструктуры.
- Автоматизированная обработка данных: NTA должен иметь возможность автоматической обработки больших объемов данных и использования искусственного интеллекта и машинного обучения для повышения эффективности и точности обнаружения угроз.
- Соответствие стандартам безопасности: NTA должен соответствовать стандартам безопасности и защиты данных, чтобы обеспечивать высокий уровень защиты приватности и конфиденциальности.
- Гибкая интеграция с другими инструментами: NTA должен быть гибко настраиваемым и интегрируемым с другими инструментами безопасности для достижения максимального уровня защиты сетевой инфраструктуры.
Вместо заключения — каким должен быть идеальный NTA
- Автоматизация в рамках выявления событий. Автоматическое выборочное изъятие контекста из метаданных и сырого трафика в зависимости от инцидента и необходимости анализа данных.
- Отсутствие необходимости в хранении избыточного объема данных из трафика.
- Наличие дополнительных фич при условии автоматизации основных функций NTA.
- Сокращение рутинной работы.
- Возможность блокировки сетевых сессий сигналом от NTA.
Хочется видеть на рынке автоматизированные в рамках выявления событий NTA, но, к сожалению, это будет сложно реализовать без глубокого понимания целевых атак и экспертизы разработчиков, активного участия ИБ-специалистов и здоровой конкуренции среди вендоров. Безусловно, на отечественном рынке присутствуют сильные игроки с серьезной исследовательской командой и технологиями киберразведки, но хотелось бы видеть и развитие малых вендоров. Пока что конкуренция на отечественном рынке NTA как будто ощущается исключительно в маркетинговых материалах. В любом случае сегмент NTA-решений продолжает развиваться и уже предлагает достаточно высокотехнологичные и конкурентоспособные продукты.
В статье не было затронуто еще много важных тем, но автор надеется в будущих статьях раскрыть смежные незатронутые темы в рамках ANTI-APT модулей. Всем спасибо за прочтение!
Егор Микитюк, ведущий технический эксперт Infosecurity
