Агент — друг или враг? Обзор агентного и безагентного подходов в ИБ

Как выбрать стратегию защиты конечных точек?

В индустрии существует два подхода: с использованием агентов – специального программного обеспечения (далее – ПО), которое устанавливается на конечных точках (далее будем называть его «агентным подходом») и без использования такового (далее – «безагентный подход»). Оба метода помогают анализировать состояние системы путем получения данных с конечных машин и обеспечивать их защищенность, но делают это по-разному.

Агентный подход – эффективное реагирование, но с издержками

Агентные решения предоставляют возможность детального анализа на конечных устройствах. В качестве установленного на сервере или рабочей станции программного обеспечения агент выполняет несколько ключевых функций:

• Мониторинг процессов и активностей – отслеживает запущенные приложения, события информационной безопасности, действия пользователей и различные изменения на целевом устройстве, что позволяет быстро выявлять подозрительную активность и различные изменения в функционировании конечных точек;
• Контроль целостности – обнаруживает несанкционированные изменения в критически важных файлах и настройках на уровнях операционной системы или программного обеспечения, указывающие на возможные атаки и внутренние угрозы ИБ.
• Обнаруживает вредоносное ПО (при наличии такой функциональности) – путем использования базы данных угроз и других косвенных признаков, обнаруживает вирусы, трояны, шифровальщики и другие угрозы ИБ.
• Автоматизированное реагирование на инциденты ИБ – при выявлении угроз, агент предоставляет возможность выполнять различные действия, например, блокировать вредоносные процессы, ограничивать сетевую активность или восстанавливать систему до безопасного состояния, осуществлять взаимодействие с другими системами и приложениями через управляющий сервер и других агентов. В большинстве случаев, действия по реагированию на инциденты ИБ полностью или частично автоматизируются.

Борьба за ресурсы

Применение агентных решений требует значительных вычислительных мощностей. Например, типовой агент может потреблять следующие вычислительные ресурсы:

• Процессор: до 5–10% CPU при активном мониторинге процессов и сканировании на угрозы ИБ. Назовем эти цифры среднестатической, потому что они не учитывает возможных скачков нагрузки.
• Оперативная память: от 512 МБ до 8 ГБ, в зависимости от типа агента и выполняемых им функций;
• Дисковое пространство: от 1 ГБ до нескольких десятков ГБ, включая СУБД для хранения данных и конфигурации самого агента, а также журналы активности. В качестве СУБД «внутри» агентов обычно используется SQLite, MS SQL Express, а также облегчённые редакции PostgreSQL, например, Embedded или Portable.

Зачастую потребление ресурсов ограничено пороговым значением, выставленным компанией-разработчиком агента, но техническая реализация ограничений может иметь негативные нюансы для тех или иных окружений. Например, это касается сферы АСУ ТП, где нередки случаи использования устаревшего оборудования с отсутствием заложенного запаса вычислительных ресурсов.

Конфликты с другими средствами защиты

Некоторые агентные решения включают встроенные механизмы антивирусной защиты. Однако в случаях, когда агент и СрЗИ, например, антивирус, разработаны разными производителями, возможны конфликты. Антивирусные решения работают по сигнатурным принципам, определяя угрозы на основе антивирусных подписей или сигнатур (от англ. signatures), созданных на основе известных образцов вредоносного кода, которые были обнаружены исследователями ИБ. Агенты, взаимодействующие с системой на низком уровне, могут и сами вызывать срабатывания антивирусных проверок и требовать ручной настройки исключений на стороне антивирусного решения для снижения количества ложных срабатываний проверок и обеспечения работоспособности агента.

Сложность развертывания

Как и любое другое ПО, агентские решения требуют развертывания на конечных точках, что привносит весомые издержки в случаях, когда ландшафт организации состоит из большого количествах машин.

Другой путь – это использовать внешние средства автоматизации развертывания, например, такие как UDV SOAR, в котором один из модулей позволяет сократить время и расходы на развертывание в организациях, где количество целевых машин иногда может достигать десятков, а то и сотен тысяч устройств.

Необходимость перезагрузки машин и дополнительные угрозы ИБ

Установка агента, как и его обновление до новых версий может требовать перезагрузки целевых машин. В промышленности возможность остановки производства допустима нечасто, что накладывает дополнительные сложности: организациям приходится либо вынужденно выполнять перезагрузку, либо адаптироваться под длинные интервалы технического обслуживания целевых систем. Как следствие, низкая скорость развертывания и использование устаревших версий агентов, в том числе – с потенциальными угрозами ИБ.

Несмотря на тренд по импортозамещению, на практике многие организации до сих порт используют системы, функционирующие на платформе Microsoft Windows. В дополнение к тому, что получение обновлений для платформы от Microsoft может быть затруднено в текущих реалиях, любое ПО, разрабатываемое под данную ОС, вынуждено использовать библиотеки и фреймворки, предоставляемые Microsoft. Например, ".Net", "ASP.Net Core" и многие другие.

Восстановление после катастроф – не так просто

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

Это связано это с тем, что в зависимости от особенностей восстановления и среды, в которой восстановлена конечная точка, ее параметры, например, такие как Hardware ID, могут измениться, что может приводить к плачевным последствиям: например, к «потере» агентом лицензии и, как следствие, остановке его работоспособности, и к потере связи с управляющим центром. Устранение таких сложностей, безусловно, может занимать значительное время, поэтому крайне важно проводить тренировочные мероприятия по восстановлению данных после катастроф.

Почему безагентные решения востребованы?

Несмотря на то, что агентные решения продолжают использоваться там, где необходим детальный контроль с возможностью реагирования, а внутренние политики ИБ не запрещают их установку на конечные точки, их недостатки заставляют компании искать альтернативы. Безагентный метод предлагает скорость развертывания, масштабируемость и гибкость, позволяя анализировать инфраструктуру без необходимости установки дополнительного ПО на конечные устройства.

Использование универсальных интерфейсов и отсутствие воздействия на целевые системы

В основе безагентного подхода лежит принцип универсальности. Различные устройства, машины, оборудование, ПО и операционные системы, встречающееся в сегментах АСУ ТП и IT предоставляют универсальные стандартизированные интерфейсы для взаимодействия с ними. Чаще всего, данные интерфейсы создаются разработчиками для нужд интеграции, собственных нужд или с целью закрытия потребностей пользователей и описаны в рабочих предложениях (от англ. RFC, Request for Comments) – технических спецификациях, стандартах или сопроводительной технической документации к решениям. Знание этих стандартов и технических спецификаций, а также факт создания данных интерфейсов международными сообществами и самими вендорами, позволяют сторонним разработчикам, включая экспертов UDV Group, использовать их наиболее безопасным образом. Данные интерфейсы зачастую используют специфичные либо достаточно распространенные протоколы передачи данных, которые служат транспортным каналом, а иногда даже полноценным механизмом для передачи и получения данных «на» и «с» конечных точек. Приведем примеры таких интерфейсов и протоколов:

• Windows Management Instrumentation, WMI – сбор данных с конечных точек под управлением Microsoft Windows;
• Windows Event Log (MS-EVEN) – сбор событий ИБ с конечных точек под управлением Microsoft Windows;
• SSH – сбор данных и управление Linux и Unix-системами;
• Syslog – сбор логов и событий ИБ с систем под управлением Linux и Unix;
• SMB и CIFS – сбор данных с сетевых хранилищ;
• REST API – сбор данных от приложений, систем и управления ими;
• SOAP – сбор данных от приложений, систем;
• SNMP – сбора данных с сетевого оборудования;
• S7, Modbus, OPC UA и прочие – сбор данных с ПЛК и других компонентов АСУ ТП
• И многие, многие другие...

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

Безагентный подход имеет ряд ограничений:

• Слабые возможности для проактивного реагирования – поскольку эффективные сценарии реагирования на инциденты ИБ требуют решительных действий (например, изоляции машины), а выполнение таких действий посредством удаленного доступа по сети требует повышенных привилегий у учетной записи, под которой выполняется данное действие на конечной машине, реализация таких функциональных возможностей в безагентном подходе либо достаточно трудоемка, либо может нести дополнительные риски ИБ, т.к. данные учетные записи могут быть потенциально скомпрометированы. В некоторых случаях механизм получения данных может не предусматривать возможностей управления даже под привилегированной учетной записью.
• Отсутствие встроенного антивируса – сужает возможности для выявления инцидентов ИБ, что диктует необходимость приобретения дополнительного решения для выявления угроз на конечных точках в режиме реального времени;
• Сложность управления учетными записями – в организациях, где внутренние политики ИБ диктуют необходимость частой и регулярной смены паролей, и в случае если разработчик безагентного решения не предоставляет централизованного инструмента для управления УЗ, обеспечение возможности аутентификации может быть затруднено, что приведет к дополнительным накладным расходам, особенно в крупных окружениях;
• Зависимость от сетевого доступа и необходимость удаленной аутентификации – если устройство отключено от сети, получение и отправка данных невозможны.

Не смотря на ограничения, у данного подхода есть и сильные преимущества:

• Не оказывает влияния на конечные системы – отсутствует дополнительное ПО, которое могло бы потреблять ресурсы конечных точек, на которых оно установлено, а использование созданных вендорами целевых систем интерфейсов и протоколов и заложенные ими ограничения позволяет гарантировать стабильность работы;
• Быстрое развертывание – установка ПО на целевых машинах не требуется;
• Отсутствие конфликтов с антивирусами и другими СрЗИ – безагентный метод использует универсальные стандартизированные интерфейсы и протоколы.

Таким образом, безагентные решения идеальны для быстрого анализа соответствия требованиям информационной безопасности, аудита и других задач, но могут уступать агентам в части выявления и реагирования на инциденты ИБ ввиду особенностей технологии.

Какой подход используется в UDV DATAPK Industrial Kit?

На момент написания данной статьи, UDV DATAPK Industrial Kit использует безагентный подход, установка дополнительного ПО на конечные системы не требуется. Решение позволяет осуществлять неинвазивный мониторинг с сохранением замкнутой программной среды целевых систем и позволяет гибко адаптироваться под реальные потребности промышленного сегмента. Это подтверждено протоколами совместимости с производителями различных систем, включая ПЛК, а также успешными кейсами внедрения и использования.

Как это работает?

В основе решения используются специальные коннекторы, которые взаимодействуют с конечными точками с компонента Sensor используя универсальные и стандартизированные интерфейсы и протоколы. Новые коннекторы добавляются в рамках плановых выпусков UDV DATAPK Industrial Kit, в том числе по запросам от заказчиков.

Для аутентификации на конечных точках используются механизмы, являющиеся частью используемого интерфейса или протокола. Учетные данные для аутентификации централизовано хранятся в безопасном хранилище на сервере уровня Management, что упрощает управление ими и снижает риски компрометации.

Для сбора данных и выполнения команд используются сканеры, которые после подключения по сети к конечной точке содержат логику для выполнения операций на конечной точке посредством универсальных механизмов на самой конечной точке. Сканеры могут быть объединены в группы для упрощения настройки, одновременного выполнения различных действий и сложных операций. Мы создаем сканеры в соответствии с потребностями рынка и по индивидуальным запросам от заказчиков. Если необходимый коннектор уже есть, добавление новых сканеров в решение не требует изменения программного кода.

Задачи сбора данных позволяют создавать и планировать выполнение сканеров или групп сканеров на заданных активах или группах активов, в том числе по необходимому расписанию. После запуска задачи, она выполняется и формируется результат, которые мы называем статусом выполнения задачи или статусом сбора данных. Данный статус позволяет отслеживать успешность выполнения, а также перейти непосредственно к важным деталям.

В зависимости от потребностей заказчика, могут быть созданы уникальные и специфичные правила корреляции, которые позволят получать инциденты ИБ по факту получения результатов задач сбора для дальнейшего расследования. Данные инциденты могут быть также переданы в сторонние системы, включая решения класса SIEM посредством протокола Syslog или через REST API. При этом сформированные правила могут применяться не только к новым событиям ИБ, но и использоваться для ретроспективного анализа уже накопленных данных. Это позволяет проводить расследования с учетом новых обстоятельств, а также гибко настраивать набор корреляционных правил, оперативно проверяя гипотезы на основе исторических событий ИБ.

Данный подход позволяет обеспечить полный жизненный цикл контроля за состоянием защищенности конечных точек, проводить аудит ИБ, выявлять угрозы и проверять активы на соответствие требованиям ИБ, отслеживать неизменность конфигураций, критичных для ИБ параметров, а также контролировать неизменность программ на ПЛК.

Какой подход выбрать?

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

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

Безагентные решения, напротив, устраняют эти риски, но взамен лишают системы глубины реагирования на угрозы ИБ. Они становятся скорее наблюдателями, чем защитниками.

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