Как происходит внедрение DLP-систем (защита от утечек информации)? В материале рассматриваются этапы внедрения, порядок их следования, взаимосвязь друг с другом. Процесс показан с точки зрения и заказчика, и исполнителя. В статье также даны практические рекомендации: на что обратить внимание обеим сторонам, чтобы внедрение и применение DLP-системы в организации было комфортным и эффективным.
2. Этап 1. Подготовка к внедрению
2.2. Юридическое сопровождение
4. Этап 3. Проектирование и установка
Введение
«Помощь должна совершаться не против воли того, кому помогают» (Георг Вильгельм Фридрих Гегель)
В отличие от начальных этапов развития рынка DLP-систем, сегодня уже можно говорить об активном формировании пользовательского спроса на продукты класса DLP. Немало компаний успели познакомиться с системами предотвращения утечек информации, понимают механизм их работы и сформулировали требования к таким системам. Рустэм Хайретдинов, заместитель генерального директора компании InfoWatch, сравнивает модернизацию DLP-системы с покупкой автомобиля — если к первой машине требования невысоки («лишь бы ездила»), то ко второй будущий собственник предъявляет точные требования, основанные на опыте использования предыдущего автомобиля. Впрочем, компания, принявшая решение о внедрении, не обязательно должна иметь опыт эксплуатации продукта того же класса. Для определения требований этой компании может помочь опыт партнера или конкурента.
Можно ли говорить о всеобщей готовности компаний, решивших внедрять DLP-систему, к этому процессу? И что понимать под готовностью? Как показывает практика, в большинстве случаев заказчик представляет себе технические возможности продуктов данного класса, но не до конца понимает необходимый объем работ, благодаря которому в консоли управления DLP-системой начнет появляться действительно важная информация. А появляться она начнет, если подходить к процессу внедрения DLP-решения как к одному из методов реализации наиболее актуального в наши дни подхода к обеспечению информационной безопасности — Data-centric security, или комплексного подхода, ориентированного на защиту информационных активов. В рамках подхода Data-centric security данные, представляющие информационные активы, разделяются на три категории:
- Data at Rest — данные в режиме хранения; статично хранятся на отчуждаемых носителях, компьютерах, мобильных устройствах пользователей и т. д.;
- Data in Motion — данные в режиме движения: финансовые транзакции, передача аутентификационных данных и т. д.;
- Data in Use — данные, непосредственно используемые пользователями в рамках бизнес-процессов.
Решения класса DLP позволяют контролировать и защищать данные всех перечисленных категорий. Однако следует помнить, что успех такой серьезной операции как внедрение DLP напрямую зависит от понимания ценности защищаемых данных. Здесь мы вплотную подходим к описанию важнейшего этапа внедрения DLP-системы — подготовке.
Этап 1. Подготовка к внедрению
Обследование
Компания NSS Labs в своей статье «За 12 шагов — к успешному внедрению DLP» делится парой тезисов, с которыми сложно не согласиться:
- успешное внедрение DLP-системы — комплексное мероприятие, в рамках которого развертывание продукта — этап необходимый, но не достаточный;
- классификация документов и определение матрицы доступа — основа для политик безопасности DLP-систем.
Кто должен выполнять работы по обследованию? Как правило, за это отвечает компания, которая внедряет DLP-систему (исполнитель). Однако не все так просто. Если компания-заказчик не готова на запрос исполнителя предоставить, к примеру, описание процессов взаимодействия с защищаемой информацией, то необходимо понять, в чьей зоне ответственности будет находиться разработка этого документа.
У идеального заказчика, принявшего решение о внедрении DLP-системы, введен режим коммерческой тайны, подготовлен перечень информации ограниченного доступа, имеется описание бизнес-процессов, в рамках которых происходит обработка, хранение и передача такой информации. Другими словами, заказчик ясно понимает правила, по которым событие считается утечкой конфиденциальной информации, а также исключения их этих правил. В таком случае исполнителю остается лишь перенести правила в политики безопасности.
У реального заказчика может быть не определено ничего. В таком случае он должен осознавать важность своего участия в обследовании, ведь чем ответственнее заказчик подходит к этому процессу, тем реальнее описание бизнес-процессов компании, критерии отнесения сведений к категории защищаемых и т. д. В случае слабой вовлеченности заказчик полагается на видение безопасности своих бизнес-процессов глазами исполнителя, а это не всегда соответствует требованиям к защите данных.
Обычно работы в рамках обследования включают в себя следующие мероприятия:
- изучение организационно-распорядительных документов, относящихся к обеспечению безопасности и классификации информации;
- изучение перечня информационных ресурсов, схем сети, схем потоков данных и т. п., относящихся к формализации информационного взаимодействия;
- согласование признаков отнесения информации к информации ограниченного доступа;
- формализация перечня информации ограниченного доступа;
- обследование и описание процессов передачи, обработки и хранения информации ограниченного доступа в рамках бизнес-процессов.
По итогам перечисленных мероприятий разрабатываются документы, на основе которых впоследствии будут создаваться политики безопасности DLP-системы. К таким документам могут относиться:
- «Перечень информации ограниченного доступа»;
- «Схема потоков данных информации ограниченного доступа»;
- «Описание технологических процессов взаимодействия с информацией ограниченного доступа»;
- «Основные сценарии утечки конфиденциальной информации».
Имея понимание того, в рамках каких бизнес-процессов происходит работа с критичными данными, из каких действий с этими данными состоят вышеупомянутые процессы, не составляет труда определить необходимые механизмы работы DLP-системы и, соответственно, требования к ней. Опционально в рамках данного этапа могут быть разработаны эскизы политик безопасности в терминах конкретного продукта. Подробнее о выборе продукта будем говорить далее.
Юридическое сопровождение
Одними из важных вопросов, с которыми столкнется руководство компании, принявшее решение об использовании продукта класса DLP, — это вопросы юридического характера. К примеру:
- «Будет ли использование этой системы трактоваться как слежка за сотрудниками?»
- «Как будем защищаться от конфликтов, вызванных работой этой системы?»
Добавьте сюда не совсем очевидные вопросы, вроде «Как контролировать администратора DLP-системы, имеющего доступ ко всему архиву перехваченной информации?».
Становится понятно, что без должной юридической и организационной подготовки внедрение такого продукта для компании — затея не из лучших. Юридическое сопровождение DLP-системы — тема отдельной статьи, которых, к слову, уже написано не так мало. Предлагается, не вдаваясь в детали, поделиться основным выводом от аналитиков по данному вопросу и опыта правоприменительной практики — компания, грамотно подготовившая внедрение DLP-системы, будет права в потенциальном споре с сотрудником, причиной которому стала работа этой системы. Главные тезисы в поддержку этого утверждения:
- компания имеет право защищать свою коммерческую тайну, вводя для этой цели режим коммерческой тайны, определяющий перечень информации ограниченного доступа, правила работы с ней и т. д.;
- средства обработки информации, переданные сотруднику для выполнения своих должностных обязанностей, а также созданные с их помощью информационные ресурсы, являются собственностью компании;
- компания не является оператором связи и не обеспечивает тайну связи при передаче по своим корпоративным каналам.
Создание грамотной стратегии использования DLP-системы в правовом контексте — вновь совместная задача для заказчика и исполнителя. Результатом этой работы должны стать шаги по организации режима коммерческой тайны или соответствующие дополнения к нему. В рамках данных работ исполнитель изучает организационно-распорядительные документы клиента, трудовые договоры, дополнительные соглашения и прочие кадровые документы, относящиеся к определению условий труда и обязательств работников, а также внутренние процедуры контроля заказчика. И по результатам анализа формирует рекомендации по внесению изменений в нормативную базу заказчика. В число документов, разрабатываемых исполнителем на данном этапе, могут войти:
- дополнительные соглашения к трудовым договорам;
- дополнения к правилам трудового распорядка;
- политика допустимого использования средств обработки информации;
- иные документы, регламентирующие работу с информацией ограниченного доступа.
Отдельно хочется напомнить про актуальность контроля эксплуатирующего персонала DLP-системы, имеющего неограниченный доступ к архиву перехваченной информации. Видится разумной попытка пресечь возможное использование этой информации в личных целях путем подписания соответствующих соглашений. И, немного забегая вперед, отметим: заказчику рекомендуется уже на данном этапе подумать над методом формирования архива перехваченной информации — сохранять все события или только события, нарушившие политику безопасности. В отличие от западных игроков отечественные DLP-системы пошли по пути сохранения всего трафика.
Здесь мы вплотную подходим к следующему этапу — выбору конкретного продукта.
Этап 2. Выбор продукта
Этот этап довольно условно расположен вторым номером, так как в ряде случаев продукт уже определен явно до начала внедрения, или этапу подготовки предшествует пилотный проект одного или нескольких решений. Таким образом, выбор конкретного продукта — этап, в зависимости от обстоятельств идущий либо первым, либо вторым, либо параллельно подготовке.
По завершению (или в процессе) этапа подготовки как у заказчика, так и у исполнителя уже имеется представление о том, как абстрактная DLP-система будет использоваться для контроля над утечками информации. Остается определить, какой именно продукт будет соответствовать требованиям оптимально. Говоря о требованиях, не стоит забывать о тех из них, которые напрямую не определяют процесс перехвата и анализа информации. К таковым относятся:
- Сложность развертывания и поддержки. Если в решении используется, к примеру, система управления базами данных Oracle, обладает ли заказчик специалистом, способным провести резервное копирование базы данных? Не стоит ли посмотреть в сторону решения, где эта процедура выполняется за три клика мыши, скажем, в планировщике заданий ОС Windows, где при установке создается соответствующее задание?
- Воздействие на инфраструктуру. Как сильно установленный агент будет влиять на работу компьютера пользователя или канал передачи данных? Возможна ли установка компонентов системы в среде виртуализации?
- Организация процессов работы эксплуатирующего персонала. Заказчик на данном этапе должен понять, что из себя будет представлять работа аналитика, ответственного за безопасность, или системного администратора, отвечающего за поддержку работоспособности решения.
Очевидным является требование к системе обладать механизмами сбора и анализа информации, удовлетворяющими потребностям заказчика в контроле бизнес-процессов, определенных на этапе обследования.
Нельзя забывать и о бюджете заказчика, который в том числе является весомым требованием. Помимо продуктов класса Enterprise, DLP-системы также представлены т. н. «легкими DLP» и Channel DLP, подразумевающими как ряд функциональных ограничений по сравнению со «старшим братом», так и вовсе направленные на контроль одного конкретного канала передачи данных. К примеру, в условиях ограниченного бюджета для заказчика может быть оптимально докупить DLP-функционал к существующему прокси-серверу и использовать только агентское решение стороннего продукта.
Данный этап характеризуется большой ответственностью исполнителя, задачей которого является предложить заказчику максимально подходящее решение. При этом возможная пассивность последнего сыграет с ним злую шутку на этапе эксплуатации и поддержки системы.
Выбор конкретного продукта сложно представить без понимания архитектуры решения, реализованного средствами этого продукта, поэтому можно утверждать, что на данном этапе уже берут свое начало работы по проектированию.
Этап 3. Проектирование и установка
Проектирование
Как правило, ключевые моменты в архитектуре решения к этому этапу уже определены. Работы по проектированию определяются как процесс детализации и расширения этих ключевых моментов до такой степени, при которой получившееся проектное решение полностью готово к реализации. Ключ к хорошему проектному решению — это детальное обследование инфраструктуры заказчика и макетирование решения «у себя дома». Эти мероприятия минимизируют риск технических сложностей на этапе установки. Очень желательно, чтобы заказчик это понимал и активно содействовал процессу.
Вид, в котором проектное решение будет представлено, обсуждается сторонами. В большинстве случаев это согласованный набор технических документов, описывающих окончательное проектное решение. На данном этапе также устанавливаются требования к эксплуатационной документации. В случае если официальных руководств производителя выбранной DLP-системы недостаточно, исполнитель готовит недостающий комплект. Примерами таких документов могут выступать как перевод официального руководства с иностранного языка, так и более экзотические документы вроде «Описания жизненного цикла программного обеспечения».
На этапе проектирования важно реализовать возможности для изменения системы в будущем, например, при потенциальном масштабировании или переходе с режима мониторинга на режим блокировки. Требования к оборудованию, программному обеспечению или даже к построению технологических процессов работы продукта должны быть заложены исполнителем исходя из такой необходимости.
Итак, исполнитель подготовил проектное решение, заказчик его согласовал, следующий этап — установка и первоначальная настройка DLP-системы.
Установка
Работы по установке DLP-системы тоже требуют тесного взаимодействия заказчика и исполнителя. Поскольку продукты такого класса решений связаны с рядом смежных систем (почтовыми, прокси-серверами, сетевым оборудованием), то сложно представить процесс установки без вовлечения специалистов заказчика.
Обычно установка продукта начинается с инсталляции серверных компонентов и настройки связи между ними и смежными системами. Однако бывают и исключения. Скажем, при сжатых сроках внедрения и значительном количестве устанавливаемых агентов процесс установки последних может быть инициирован еще до завершения работ по проектированию. Такой пример нестандартного решения еще раз напоминает про необходимость ведения диалога между сторонами на всех этапах внедрения.
Важный вопрос в рамках работ по установке, одновременно приближающий нас к работам по настройке — это вопрос сохранения в тайне от сотрудников заказчика факта внедрения продукта. Если степень вовлеченности пользователей в работу DLP-системы еще не определена, то самое время об этом подумать.
Этап 4. Настройка
К сожалению, в рамках этого этапа не будет описан универсальный алгоритм, следуя которому любой желающий получает грамотно настроенную DLP-систему. Хотя почему нет? Ведь если подумать, этот алгоритм состоит всего из одного легко формулируемого пункта — «Непрерывно настраивать систему и изменять политики безопасности на протяжении всего периода эксплуатации».
Как мы видим, речь идет не о длительной настройке, а о непрерывной — это ключевой момент, который необходимо понять заказчику. Выполненный «на отлично» этап подготовки будет являться незаменимым подспорьем на этапе настройки, и исполнитель непременно поможет в начале пути (а может и не только в начале, все определяется договоренностями). Но основная работа в рамках текущего этапа ложится на плечи заказчика (здесь не берем во внимание сервисную модель услуг, в рамках которой исполнитель может взять на себя значительную часть от этих работ).
Изменение бизнес-процессов, инфраструктуры, прием на работу сотрудников, делегирование обязанностей внутри существующих отделов, выпуск новых документов вроде приказов руководства, должностных инструкций — все эти события влекут за собой необходимость изменения политик безопасности. Вооружившись цифровыми отпечатками, словарями, а иной раз и технологиями машинного обучения, ответственный персонал должен успевать за всеми значимыми для DLP-системы изменениями в компании и нивелировать их возможные отрицательные последствия, чтобы избежать утечку информации. Причем под отрицательными последствиями здесь понимаются не только новые каналы для утечки, но и возможный рост ложноположительных срабатываний.
Если говорить об обязанностях сторон в рамках внедрения, то, заключая договор, они пытаются согласовать количественные и качественные характеристики работ по настройке DLP-системы, которые исполнитель обязуется выполнить. Как правило, речь идет о наполнении базы специальных терминов, написании регулярных выражений и создании на основе данных технологий политик защиты данных. Работы по настройке обычно сопровождаются консультациями персонала. В интересах обеих сторон сделать этот процесс максимально продуктивным, устраняя неспособность сотрудников самостоятельно работать с системой.
В ходе настройки необходимо держать в голове вопрос: «Хочет ли заказчик использовать DLP-систему как инструмент обучения пользователей работе с конфиденциальной информацией или как инструмент слежки?». Западные компании широко используют первый вариант. Его идея заключается не только в осведомленности пользователей о наличии DLP-системы, но и в вовлечении в организацию безопасности данных рядовых сотрудников. Как следствие — изменение их поведения в сторону большей ответственности. Чем больше организация, тем объективно более востребован для нее такой подход: численность собственного отдела ИБ ограничена, а DLP-системы могут требовать значительных трудозатрат на первых порах эксплуатации. Внутренний краудсорсинг может оказать ощутимую поддержку в таком трудоемком деле. Принцип геймификации добрался и до такой области применения, как эксплуатация DLP-систем. В рамках игровой парадигмы компания отказывается от так называемого «шлепка по рукам» — стандартного всплывающего окна с угрозами, оформленного в красных тонах, призванного вызвать максимальный стресс у пользователя. В случае непреднамеренного нарушения политики безопасности пользователь увидит описание причины блокирования его действия и сноску о том, как избежать нарушения в будущем. Другая важная часть геймификации — явная положительная мотивация. Присвоение пользователям значков отличия за соблюдение норм обеспечения безопасности данных, публикация красивых графических отчетов DLP-систем о тех, чье взаимодействие с данными является наиболее правильным, и т. п.
При кажущейся простоте подхода такой механизм помогает ввести и закрепить в рабочем обиходе сотрудников само понятие «защита от утечки данных», сделать защиту данных не чуждым пользователю понятием, а неотъемлемой и естественной (при этом не скучной) частью рабочего процесса. Второй вариант подразумевает максимальную скрытость присутствия продукта в информационной среде. Формулировку ответа на этот вопрос рекомендуется оформить как этап № 0.
Выводы
Внедрение DLP часто осложняется объективными факторами: различие в функционале, отсутствие единственно верного варианта внедрения и единого сценария использования. Даже само принятие решения о внедрении защиты от утечки данных может откладываться заказчиком из-за мифов, связанных с DLP-системами («на поддержание DLP уйдет весь ресурс ИБ», «внедрять DLP нужно не менее полутора лет или не внедрять вообще» и т. п.), а также из-за того, что для эффективного внедрения необходима вовлеченность представителей бизнеса и пр.
В таком случае, опираясь на опыт, исполнитель должен предложить сценарии, которые покажут ценность решения как представителям технического блока заказчика, так и представителям бизнеса. DLP способны показать быстрый и объективный результат, который поможет клиенту определиться с выбором.
Для организаций, которые ответственно подходят к безопасности собственных данных и данных своих клиентов, DLP — однозначно необходимое решение.
