Как известно, в общей массе утечек информации велика доля тех, которые происходят непосредственно с рабочих компьютеров. Рассказываем, как правильная настройка агентской политики помогает эффективнее бороться с такими утечками в компании.
Введение
Из недавних исследований «РТК-Солара» видно, что более половины всех выявленных в российских компаниях утечек информации происходит с рабочих станций пользователей. Нарушители либо отправляют конфиденциальную информацию за периметр организации через личную электронную почту, либо выкладывают её в облако, скажем на «Яндекс.Диск», либо выносят физически, записав на флешку или распечатав документ на принтере.
Основным «лекарством» для сокращения таких утечек является, безусловно, ограничение этих каналов. Что, конечно же, нереализуемо в полной мере, да и введённые ограничения имеют пределы: не всегда можно полностью запретить запись на флешку или печать — это прямое вмешательство в бизнес-процессы, а бизнес очень не любит, когда ему мешают. Получается, что угроза утечки есть, полностью убрать её нельзя. Зато можно снизить риск её возникновения. Для этого следует внедрять ИБ-решения, которые будут эффективно обрабатывать информационные потоки непосредственно на рабочих станциях сотрудников.
Немного агентской теории…
Именно для этих целей производители DLP-систем активно развивают функциональность агентов для конечных точек. Да, агент, установленный на автоматизированном рабочем месте (АРМ) пользователя, уязвим для действий злоумышленника: при наличии у того определённых знаний в ИТ, а тем более — при имеющихся изъянах в обеспечении безопасности АРМ, оставленных нерадивыми системными администраторами, агент можно удалить или повредить. Тем не менее попытки его удаления хоть и могут привести к кратковременному снятию защиты, но не останутся незамеченными офицерами ИБ, при этом сам агент обладает рядом уникальных свойств, позволяя перехватывать практически любую информацию с контролируемой рабочей станции, что делает его незаменимой частью любой уважающей себя DLP-системы.
Но написать и предоставить заказчику агент, перехватывающий трафик, — только полдела. Ещё надо создать механизм управления агентскими политиками — правилами, с помощью которых агент будет выявлять и эффективно блокировать действия пользователя, несущие прямую либо потенциальную угрозу организации. Такие политики должны быть: а) гибкими и точными, б) удобными в настройке.
Точность и гибкость политики необходимы для гарантированного выявления попыток утечки информации, но не только. Ещё она нужна для снижения (а в идеале — исключения) ложноположительных срабатываний (ЛПС) агента. Ведь каждая агентская блокировка — это прерывание бизнес-процесса, а если это прерывание произошло из-за ЛПС, то есть ошибочно, то каждая такая ситуация, конечно, выставляет DLP-систему (да и ИБ в целом) не в лучшем свете.
Удобство, простота настройки политики нужны для того, чтобы работа с ней не превратилась для офицера ИБ в отдельный трудоёмкий процесс, требующий специальных академических знаний, длительной переписки с вендором и большого количества времени.
Известно, что во «взрослых» DLP-системах агент для конечных точек — это программа устанавливаемая на подконтрольное АРМ единым пакетом. При этом, если заглянуть агенту «под капот», мы увидим, что за различные перехваты в системе отвечают отдельные модули — перехватчики, к которым применимы разные условия политики, иногда совершенно несовместимые между собой. Так, например, при блокировке запуска нежелательного приложения политике надо сообщить его имя, а при блокировке записи информации на внешний носитель — текст, содержащийся в копируемом файле. Иначе говоря, каждый перехватчик в агенте нужно настраивать отдельно.
Но в декабре 2022 года «РТК-Солар» выпустил новую версию своего флагманского продукта Solar Dozor 7.8, в которой представлена переработанная агентская политика: настройка всех перехватчиков происходит в одной точке по единым стандартам. Делается это в обновлённом интерфейсе, а сам процесс настройки политики стал ещё более простым и удобным (рис. 1).
Рисунок 1. Настройка правил контроля информации
Агентские политики в Solar Dozor 7.8 описываются в специальных правилах контроля и настраиваются применительно к пользователям и их группам. Это могут быть как группы Active Directory (AD) — OU (Organizational Unit) или безопасности, — так и группы созданные непосредственно в DLP-системе. В каждом правиле контроля описывается набор правил для всех доступных каналов агентского перехвата: условия блокировки печати на принтер, записи на съёмный носитель, публикации информации в сети и т. д. При этом в политике разрешено использование только тех правил и условий, которые применимы для конкретного канала перехвата. Если же контроль какого-то канала для группы пользователей не требуется, его можно легко отключить.
Для удобства настройки эти правила можно копировать. Это полезно в том случае, если есть необходимость использования похожих правил контроля для разных пользователей / групп. Но если одно и то же правило контроля планируется без изменений применять для множества групп, тогда, чтобы не дублировать одинаковые правила, не тратить время на их копирование и постоянную поддержку, можно назначить нужное правило контроля как шаблон и определить его для контроля действий других пользователей / групп либо использовать в других группах станций. Тогда разовое изменение правил в шаблоне приведёт к соответствующему изменению всех связанных с ним правил контроля.
Важно отметить, что один пользователь может присутствовать в различных группах AD, а в процессе эксплуатации DLP-системы правил агентской политики может быть настроено много, в том числе для разных групп, куда могут входить одни и те же пользователи (например, если на контроль поставлены группы OU разной вложенности). В Solar Dozor предусмотрен специальный механизм, исключающий конфликт применения политик из разных групп: для каждого пользователя применяется конкретная политика, скомпилированная по понятной логике.
…и много агентской практики
Теперь о практике. Как уже было сказано, агентская политика в Solar Dozor применяется к пользователям / группам, то есть пользователь, к какому бы АРМ он ни подключился, получит агентскую политику, которая предназначена именно ему. Рассмотрим подсказанные жизнью примеры.
Можно настроить такую политику, когда сотрудник отдела кадров, подключившись к любому АРМ своего подразделения, будет иметь одинаковые правила и ограничения. При этом, если такой сотрудник подключится к АРМ, скажем, бухгалтерии (то есть чужому для него), то он получит крайне ограниченные права, не разрешающие ему какую-либо активность. В случае же если сотрудник отдела кадров посетит филиал своей организации в другом регионе, он, подключившись там к АРМ филиального отдела кадров, получит точно такие же разрешения, как если бы он работал в своём офисе — ведь это такой же отдел кадров с теми же разрешениями (рис. 2). Либо наоборот: для него в филиале можно настроить ограниченные права как для гостя.
Рисунок 2. Настройка шаблона правил контроля для отдела кадров
Другой пример. Для системного администратора, который в силу своих обязанностей может заходить на АРМ любых пользователей, можно разрешить запуск на них любых процессов, при этом запретить для него запись информации на съёмные носители.
Ещё один сценарий. Сотрудник переводится из одного подразделения в другое — скажем, из отдела кадров в отдел льгот и компенсаций — со своим ноутбуком. Набор информации (в том числе и конфиденциальной), с которой будет работать сотрудник, несколько отличается от того, с чем он работал раньше. Следовательно, и ограничения в агентской политике для другого подразделения должны быть иными. Тем не менее при переводе сотрудника с одной должности на другую (и, соответственно, смене OU в AD) на ноутбуке пользователя автоматически заработает агентская политика, определённая уже для отдела льгот и компенсаций, а не для отдела кадров. При этом офицеру ИБ в DLP-системе никаких специальных действий производить не потребуется (рис. 3).
Рисунок 3. Настройка правил контроля при переводе между подразделениями
Таким образом, в Solar Dozor агентская политика по группам / пользователям работает схоже с групповыми политиками AD, но настраивается непосредственно в DLP-системе. При этом агентская политика даже частично дублирует системные функции. Так, с её помощью, например, можно ограничивать использование съёмных носителей информации: наличие сотрудника в той либо иной группе может означать для него разрешение (либо наоборот — запрет) на использование флешки.
Это особенно полезно в ситуациях, когда подразделению ИБ по каким-то причинам затруднительно взаимодействовать с отделом системного администрирования либо такое взаимодействие недостаточно оперативно. В этом случае подразделение ИБ может самостоятельно управлять некоторыми правами, назначая пользователям либо группам какие-либо правила и ограничения только за счёт ресурсов своей DLP-системы.
Здесь уместно рассмотреть ещё один кейс. Сотрудник пытается совершить некое нарушение, настолько серьёзное, что требуется не только пресечь это действие, но и незамедлительно принять меры по ограничению активности этого пользователя для недопущения рецидивов. Для этого в политике Solar Dozor есть специальное правило, по заданному условию помещающее нарушителя в группу особого контроля, для которой в агентской политике прописаны свои особые правила, полностью блокирующие взаимодействие подконтрольной рабочей станции со внешним миром. Что важно, всё это происходит в автоматическом режиме. В итоге нарушитель не сможет повторить нарушение, что даёт офицеру ИБ время отреагировать на инцидент.
Мы видим, что настройка агентской политики в зависимости от конкретных пользователей или групп значительно повышает эффективность работы агентов. Но что делать офицеру ИБ, если он хочет использовать одну политику для всех агентов? В таких случаях можно использовать политику «Любой пользователь», которая будет применяться для всех агентов Solar Dozor по умолчанию.
Передача и хранение данных
Теперь немного о передаче и хранении агентских данных. Вся информация об активных действиях агентов (например, о том, что агент заблокировал попытку записи на носители файла с информацией составляющей коммерческую тайну) в любом случае должна передаваться в DLP-систему для дальнейшего разбора. В Solar Dozor так и есть. Но для обеспечения оптимального использования объёмов файлового хранилища DLP-системы Solar Dozor можно управлять объёмом поступающего от агентов трафика. На больших инсталляциях такой трафик достигает значительного объёма и нагружает не только систему хранения данных, но и сеть. В Solar Dozor с помощью специальной настройки можно ограничивать поток событий отдельно по каждому каналу агентского перехвата.
Так, агент может отправлять в DLP-систему все события обработанные перехватчиком — например, по любым файлам, записанным на съёмный носитель; тогда оператор системы будет иметь полное представление обо всех операциях записи на флешку, совершённых пользователем. Если же такой необходимости нет, то агент следует настроить на передачу в Solar Dozor только ограниченного числа событий, например связанных с записью на флешки технической документации. Данную настройку можно менять для различных пользователей / групп, в зависимости от критической значимости данных, ими обрабатываемых.
Выводы
Размеры статьи, к сожалению, не позволяют рассказать обо всех возможностях новой агентской политики: представленные сценарии раскрывают только некоторые из них. Но из написанного видно, что в Solar Dozor политику можно настроить весьма гибко.
Вообще, чем качественнее в DLP настроена политика, тем меньше рисков утечки конфиденциальной информации из компании. И это касается не только лишь агентской части, но и всей системы в целом.
А для настройки такой качественной политики от DLP требуется наличие развитых аналитических возможностей — правил и условий. Solar Dozor этими возможностями обладает. Как, собственно говоря, и положено одной из передовых российских DLP-систем.
