Существует много готовых фреймворков, в которых описываются правила реагирования. Наиболее известные из них, – например, STIX, Sigma. Но есть и другие, поэтому «птичий язык» не нужен.
Кроме того, существуют открытые базы, в которых содержатся уже наборы готовых правил. Стоит также отметить, что обычно системы безопасности имеют возможность импортировать правила в этих форматах. Ну и сама система имеет обычно конструктор, который позволяет пользователю создавать собственные правила. Я везде пишу «обычно», так как в конкретных реализациях системы ИБ этот процесс может отличаться, однако базовый функционал есть в любой системе уровня enterprise. Я говорю об уровне enterprise, поскольку рассматриваемая в статье тема не относится к потребностям обычного пользователя (вряд ли кто-то решит завести себе в квартиру 400 Gbps).
Да, согласен, что на пределе. Но это уже включенными политиками. Если просто соединить вход с выходом, быстродействие будет заметно выше. Я сознательно не уточнял, на каком алгоритме получены эти цифры, поскольку в целом ориентировался на некий усредненный алгоритм, а цель была показать именно возможность оптимизации. Условно скажем, что этот алгоритм – полноценный DPI. А касательно TLS-терминации, она выполняется аппаратно карточкой Mellanox. В тексте упоминается, что всего TLS/SSL Offload до 1 млн сессий.
Биллинг – это, по сути, тот же DPI, разбор трафика по сессиям от конечных пользователей, далее подсчет суммы переданных байтов по типам трафика (потоковое аудио-видео, скачивание файлов, веб-серфинг и т.д.). Далее информация передается в платежную систему оператора (упрощено, там на самом деле больше модулей), и оттуда возвращается вердикт о продолжении сессии, прерывании сессии или шейпинге. В общем, стандартно для DPI.
«Захардкожено» – все-таки это не совсем точное определение. Происходит исследование трафика, и оно в большинстве случаев более-менее универсально. А далее есть политики, которые указывают на конкретное реагирование по тому или иному событию. Вот политики и их исполнение – это, конечно, более специфическая тема, привязанная к конкретной роли. Поэтому если употреблять слово «захардкожено», то, наверное, соотношение такое: 80% универсальные алгоритмы, а 20% – специфические, зависящие от типа устройства. И да, из тех типов устройств, что я упоминал, CDN стоит немного сбоку, конечно.
Здесь все зависит от класса решаемых задач. Аппаратное ускорение действительно применяется – в том числе интеллектуальная балансировка RSS и аппаратное ускорение TLS-декодирования. Однако это вовсе не означает, что система способна обрабатывать только базовые функции вроде Anti-DDoS с фильтрацией по черно-белым спискам.
На практике, например, IPS может работать не в разрыве трафика, а на его копии, инициируя блокировку сессии уже на 3-4 пакете.
Однако справедливо и другое: чем больше функций одновременно задействовано, тем ниже возможная пропускная способность при обеспечении защиты (Protection Throughput).
Частично ответил на этот вопрос выше. В целом да – подходы к DPI у всех примерно одинаковы: будь то сотовые операторы или «глобальный китайский файрвол». Сначала осуществляется перехват всего трафика, затем его анализ, после чего принимаются решения о блокировке или иных действиях.
Что именно использует РКН, комментировать не буду. Отмечу лишь, что у них есть собственное решение.
Добрый день! Статья в первую очередь посвящена тому, как повысить скорость обработки трафика. Конкретные методы дальнейшей обработки он я ней не рассматривал – лишь упомянул, что такое есть.
Если говорить о практическом применении, то основная область использования – информационная безопасность. Конкретная реализация решений определяется их целевым назначением. В общих чертах такие решения обычно представляют собой L4/L7-файрволы, задача которых – анализировать сетевой трафик и выделять из него протоколы, приложения и конкретный контент. Далее есть правила, которые разрабатывает организация, применяющая данное устройство. Это могут быть фильтры на блокировку служебной информации, проверка на вирусы, проверка на сетевую атаку и так далее. Для каждой из этой функции существуют свои общепринятые способы написания правил. Например, основой для написания правил по обнаружению хакерской атаки является MITRE ATT&CK. Если нужно подробнее, как производится анализ, то необходимо рассматривать конкретные сценарии применения. Скажем, Anti-DDoS.
Да, ScanOVAL в принципе тоже можно использовать, но у него есть один недостаток: его придется устанавливать на каждый хост отдельно. А мы рассматривали варианты сканеров для массового и удаленного сканирования.
Изначально у компании не стояла задача «ловить» сотрудников, использующих автокликеры или иные средства автоматизации. DLP просто зафиксировала у сотрудника аномальную активность. В ходе дальнейшего разбирательства стало понятно, что человек лишь имитировал работу с помощью автокликера.
А так, в целом, абсолютно согласны с Вами, что автоматизировать рутину – нормально и даже здорово, если это приносит пользу бизнесу. В описанном в статье случае проблема возникла не из-за автоматизации как таковой, а из-за того, что за высокой активностью не было реальных результатов работы.
Добрый день! К сожалению, такого вопроса не было в нашей анкете, поэтому статистикой поделиться не можем. Но спасибо за идею))) Мы добавим этот вопрос в опросник, когда будем проводить исследование в следующем году.
Если говорить о мониторинге операций, когда "Гарда DBF" работает с копией трафика, то мы не оказываем влияния на производительность Kafka.
При необходимости блокировки и использования агентов производительность действительно немного снижается. По результатам наших тестов, это порядка 1-2%.
Добрый день!
Существует много готовых фреймворков, в которых описываются правила реагирования. Наиболее известные из них, – например, STIX, Sigma. Но есть и другие, поэтому «птичий язык» не нужен.
Кроме того, существуют открытые базы, в которых содержатся уже наборы готовых правил. Стоит также отметить, что обычно системы безопасности имеют возможность импортировать правила в этих форматах. Ну и сама система имеет обычно конструктор, который позволяет пользователю создавать собственные правила. Я везде пишу «обычно», так как в конкретных реализациях системы ИБ этот процесс может отличаться, однако базовый функционал есть в любой системе уровня enterprise. Я говорю об уровне enterprise, поскольку рассматриваемая в статье тема не относится к потребностям обычного пользователя (вряд ли кто-то решит завести себе в квартиру 400 Gbps).
Да, согласен, что на пределе. Но это уже включенными политиками. Если просто соединить вход с выходом, быстродействие будет заметно выше. Я сознательно не уточнял, на каком алгоритме получены эти цифры, поскольку в целом ориентировался на некий усредненный алгоритм, а цель была показать именно возможность оптимизации. Условно скажем, что этот алгоритм – полноценный DPI. А касательно TLS-терминации, она выполняется аппаратно карточкой Mellanox. В тексте упоминается, что всего TLS/SSL Offload до 1 млн сессий.
В вопросе два момента – отвечу по порядку
Биллинг – это, по сути, тот же DPI, разбор трафика по сессиям от конечных пользователей, далее подсчет суммы переданных байтов по типам трафика (потоковое аудио-видео, скачивание файлов, веб-серфинг и т.д.). Далее информация передается в платежную систему оператора (упрощено, там на самом деле больше модулей), и оттуда возвращается вердикт о продолжении сессии, прерывании сессии или шейпинге. В общем, стандартно для DPI.
«Захардкожено» – все-таки это не совсем точное определение. Происходит исследование трафика, и оно в большинстве случаев более-менее универсально. А далее есть политики, которые указывают на конкретное реагирование по тому или иному событию. Вот политики и их исполнение – это, конечно, более специфическая тема, привязанная к конкретной роли. Поэтому если употреблять слово «захардкожено», то, наверное, соотношение такое: 80% универсальные алгоритмы, а 20% – специфические, зависящие от типа устройства. И да, из тех типов устройств, что я упоминал, CDN стоит немного сбоку, конечно.
Добрый день!
Здесь все зависит от класса решаемых задач. Аппаратное ускорение действительно применяется – в том числе интеллектуальная балансировка RSS и аппаратное ускорение TLS-декодирования. Однако это вовсе не означает, что система способна обрабатывать только базовые функции вроде Anti-DDoS с фильтрацией по черно-белым спискам.
На практике, например, IPS может работать не в разрыве трафика, а на его копии, инициируя блокировку сессии уже на 3-4 пакете.
Однако справедливо и другое: чем больше функций одновременно задействовано, тем ниже возможная пропускная способность при обеспечении защиты (Protection Throughput).
Добрый день!
Частично ответил на этот вопрос выше. В целом да – подходы к DPI у всех примерно одинаковы: будь то сотовые операторы или «глобальный китайский файрвол». Сначала осуществляется перехват всего трафика, затем его анализ, после чего принимаются решения о блокировке или иных действиях.
Что именно использует РКН, комментировать не буду. Отмечу лишь, что у них есть собственное решение.
Добрый день! Статья в первую очередь посвящена тому, как повысить скорость обработки трафика. Конкретные методы дальнейшей обработки он я ней не рассматривал – лишь упомянул, что такое есть.
Если говорить о практическом применении, то основная область использования – информационная безопасность. Конкретная реализация решений определяется их целевым назначением. В общих чертах такие решения обычно представляют собой L4/L7-файрволы, задача которых – анализировать сетевой трафик и выделять из него протоколы, приложения и конкретный контент. Далее есть правила, которые разрабатывает организация, применяющая данное устройство. Это могут быть фильтры на блокировку служебной информации, проверка на вирусы, проверка на сетевую атаку и так далее. Для каждой из этой функции существуют свои общепринятые способы написания правил. Например, основой для написания правил по обнаружению хакерской атаки является MITRE ATT&CK. Если нужно подробнее, как производится анализ, то необходимо рассматривать конкретные сценарии применения. Скажем, Anti-DDoS.
Да, ScanOVAL в принципе тоже можно использовать, но у него есть один недостаток: его придется устанавливать на каждый хост отдельно. А мы рассматривали варианты сканеров для массового и удаленного сканирования.
Trivy не упомянули, поскольку он в первую очередь предназначен для сканирования контейнерных сред
Здравствуйте!
Благодарим за вопрос.
Изначально у компании не стояла задача «ловить» сотрудников, использующих автокликеры или иные средства автоматизации. DLP просто зафиксировала у сотрудника аномальную активность. В ходе дальнейшего разбирательства стало понятно, что человек лишь имитировал работу с помощью автокликера.
А так, в целом, абсолютно согласны с Вами, что автоматизировать рутину – нормально и даже здорово, если это приносит пользу бизнесу. В описанном в статье случае проблема возникла не из-за автоматизации как таковой, а из-за того, что за высокой активностью не было реальных результатов работы.
Добрый день! Да, спасибо, поправили ошибку. Благодарим, что обратили внимание
Добрый день! К сожалению, такого вопроса не было в нашей анкете, поэтому статистикой поделиться не можем. Но спасибо за идею))) Мы добавим этот вопрос в опросник, когда будем проводить исследование в следующем году.
это про Москву))))))
Приходите 16 октября в конгресс-центр Soluxe (ул Вильгельма Пика, 16 ). Будем очень рады видеть Вас в числе участников нашей конференции!
Здравствуйте, Евгений.
Если говорить о мониторинге операций, когда "Гарда DBF" работает с копией трафика, то мы не оказываем влияния на производительность Kafka.
При необходимости блокировки и использования агентов производительность действительно немного снижается. По результатам наших тестов, это порядка 1-2%.