Определяем текущее состояние ИБ и даем рекомендации по улучшению уровня защиты
Помогаем обеспечить выполнение требований 152-ФЗ по защите персональных данных
Отчет с рекомендациями и дорожная карта для выполнения требований Указа №250
Проведем категорирование объектов, подготовим ОРД и поможем обеспечить безопасность КИИ
Курсы информационной безопасности для вас и ваших сотрудников
Услуги:
Статьи:
Аттестация объектов информатизации и подключение к ГИС
Поиск путей проникновения внешнего нарушителя во внутреннюю сеть
Экспертный анализ и оценка уровня защищенности инфраструктуры
Анализ защищенности от атак с доступом к локальной сети организации
Услуги:
Статьи:
Анализ защищенности от атак с эксплуатацией уязвимостей веб-ресурсов
Симуляция атак с использованием методов социальной инженерии
Анализ защищенности от атак с эксплуатацией уязвимостей мобильных приложений
Реализация требований ГОСТ Р 57580.1 , начиная с аудита и заканчивая построением системы защиты
Проводим оценку рисков ИБ для организации, вероятность их реализации и степень допустимости
Проводим аудит по требованиям Положения 716-П, готовим отчёт и комплект ОРД
Проводим аудит по требованиям Положений 787-П и 779-П, готовим отчёт и комплект ОРД
Проводим аудит по требованиям Положения SWIFT CSCF, готовим отчёт и комплект ОРД
Статьи:
Услуги:
Полный комплекс работ по обеспечению информационной безопасности КИИ
Защита автоматизированных систем управления технологическими процессами
Готовим документы для выполнения требований по защите ПДн (152-ФЗ)
Обеспечение соответствия Приказам ФСТЭК № 235 и № 239
Поможем выполнить требования Указа № 250 Президента Российской Федерации
Оценка и подтверждение соответствия объектов информатизации требованиям безопасности
Услуги:
Статьи:
Внедрение и сопровождение IDM, аудит прав доступа, построение ролевой модели
Внедрение и поддержка средств мультифакторной аутентификации
Внедрение и поддержка систем контроля привилегированных пользователей
Услуги:
Услуги:
Статьи:
Проектирование, внедрение, поддержка систем защиты конечных точек
Проектирование, внедрение, поддержка систем защиты конечных точек от комплексных угроз
Проектирование, внедрение, поддержка систем Extended Detection and Response
Услуги:
Статьи:
Сервис обучения сотрудников навыкам кибербезопасности на базе Phishman
15 базовых курсов по информационной безопасности для ваших сотрудников
Автоматизированная система обучения сотрудников основам ИБ
Услуги:
Разработка системы управления информационной безопасностью в соответствии с ISO/IEC 27001
Экспертный аудит и разработка стратегии непрерывности бизнеса в соответствии с ISO 22301
Новости

Как рынок относится к российским NTA-решениям

Специалист Infosecurity по NTA-решениям Егор Микитюк рассказал Ciso Club об отношении российского рынка к NTA и его развитию
Автор воспользовался услугами нашумевшего ChatGPT и задал несколько вопросов в рамках материала.Определение NTA от искусственного интеллекта — Network Traffic Analysis (NTA) — это процесс мониторинга и анализа сетевого трафика, который происходит в организации. NTA может включать в себя исследование пакетов, анализ протоколов и другие методы, направленные на выявление неожиданных или нежелательных трендов в сетевых данных. На самом деле еще до введения определения NTA международным ИБ-сообществом эти системы уже существовали в виде сетевых сенсоров почти у всех ведущих производителей решений по защите от APT. В дальнейшем его вид формализовали и стандартизировали. В итоге, развиваясь в форматоре этих стандартов, NTA дошли до наших лет.

Рынок не хочет разбираться с NTA

Прародителей NTA уже давно используют в информационной безопасности и, честь по чести, некоторые вендоры так и не превратили свои сенсоры в полноценный анализатор сетевого трафика по современным стандартам. Стандарты стандартами, но у каждого разработчика есть свое видение развития продукта в рамках собственных экосистем. В том числе это касается отечественного рынка, где сильные не только вендоры, но и аналитики в сфере информационной безопасности, поэтому ожидания от игроков рынка NTA относительно высокие.

Прежде чем рассуждать о разнообразии баз решающих правил NTA, стоит разобраться, что же составляет ядро NTA, а именно на основе чего решение выявляет атаки. Окунувшись в дебри презентаций и брошюр, а также в практику использования, можно сделать вывод, что всё, что производители заявляют в своих материалах о базах знаний 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. В итоге каждый разработчик 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 достаточно строго прописан в международных исследовательских организациях типа Gartner. Этот стандарт включает в себя не только функции, описанные выше, но и статистический анализ сетевого потока, и поведенческие движки и многое другое. Но и сверх фич, описанных стандартом, в NTA полно иных сопряженных функций. Тут вендоры проявляют массу изобретательности, оснащая свои NTA уникальными фичами, призванными выделяться среди конкурентов. Только вот, вспоминая о проблемах отсутствия автоматизации, можно сделать вывод, что на эти фичи банально не хватит аналитического ресурса. Как правило, наличие таких функций добавляет решению веса в глазах пользователей, и все эти дополнительные фичи теоретически могут быть действительно полезными, но только если решить проблемы автоматизации и внутренней аналитической наполненности NTA. В текущей же практике специалистов ИБ, содержащей и без того избыточный ручной труд, они нередко оказываются ненужными.
Ответ ИИ на вопрос «Каким, на твой взгляд, должен быть идеальный NTA с учетом возможных будущих разработок?»

  • Идеальный NTA должен обладать несколькими важными характеристиками:
  • Высокая точность обнаружения: NTA должен быть в состоянии точно идентифицировать потенциально вредоносный трафик и отличать его от нормального трафика.
  • Широкий охват угроз: NTA должен обнаруживать различные типы угроз, включая известные и неизвестные угрозы, а также сложные атаки.
  • Мгновенная реакция: NTA должен быть в состоянии быстро реагировать на угрозы и принимать меры для минимизации ущерба.
  • Понятный интерфейс: NTA должен иметь интуитивно понятный интерфейс для удобного использования и анализа результатов.
  • Поддержка современных протоколов: NTA должен поддерживать все современные сетевые протоколы и быть гибким для адаптации к изменяющимся требованиям сетевой инфраструктуры.
  • Автоматизированная обработка данных: NTA должен иметь возможность автоматической обработки больших объемов данных и использования искусственного интеллекта и машинного обучения для повышения эффективности и точности обнаружения угроз.
  • Соответствие стандартам безопасности: NTA должен соответствовать стандартам безопасности и защиты данных, чтобы обеспечивать высокий уровень защиты приватности и конфиденциальности.
  • Гибкая интеграция с другими инструментами: NTA должен быть гибко настраиваемым и интегрируемым с другими инструментами безопасности для достижения максимального уровня защиты сетевой инфраструктуры.

Вместо заключения — каким должен быть идеальный NTA

  • Автоматизация в рамках выявления событий. Автоматическое выборочное изъятие контекста из метаданных и сырого трафика в зависимости от инцидента и необходимости анализа данных.
  • Отсутствие необходимости в хранении избыточного объема данных из трафика.
  • Наличие дополнительных фич при условии автоматизации основных функций NTA.
  • Сокращение рутинной работы.
  • Возможность блокировки сетевых сессий сигналом от NTA.

Хочется видеть на рынке автоматизированные в рамках выявления событий NTA, но, к сожалению, это будет сложно реализовать без глубокого понимания целевых атак и экспертизы разработчиков, активного участия ИБ-специалистов и здоровой конкуренции среди вендоров. Безусловно, на отечественном рынке присутствуют сильные игроки с серьезной исследовательской командой и технологиями киберразведки, но хотелось бы видеть и развитие малых вендоров. Пока что конкуренция на отечественном рынке NTA как будто ощущается исключительно в маркетинговых материалах. В любом случае сегмент NTA-решений продолжает развиваться и уже предлагает достаточно высокотехнологичные и конкурентоспособные продукты.

В статье не было затронуто еще много важных тем, но автор надеется в будущих статьях раскрыть смежные незатронутые темы в рамках ANTI-APT модулей. Всем спасибо за прочтение!
Егор Микитюк, ведущий технический эксперт Infosecurity
Блог