Практика внедрения систем защиты от утечек конфиденциальной информации

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

Есть все основания считать, что внутренние угрозы представляют собой более важную проблему для безопасности предприятий, чем внешние. Так, по данным InfoWatch за 2007 г., на долю внешних угроз ИБ приходилось 43,5%, а внутренних — 56,5%. Но при этом, как ни парадоксально, в открытых источниках до сих пор практически нет данных о том, каким образом компании решают задачи защиты информации от утечек через собственных сотрудников*. Доступная информация строго делится на две части: теоретическую (организационно-правовую) и продуктовую, оценивающую свойства конкретных продуктов в отрыве от практического использования. Практически все крупные компании так или иначе решили для себя вопрос с первичной защитой от внутренних угроз, но подробностей внедрения в открытых источниках до обидного мало.

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

По данным компании InfoWatch (www.infowatch.ru), за последние несколько лет в России реализовано около сотни проектов, которые можно с разной степенью точности отнести к построению комплексной системы защиты от утечки информации. Данная статья представляет собой попытку обобщить опыт внедрения таких систем. Автор приносит извинения читателям за невозможность раскрыть некоторые подробности внедрений и инцидентов при использовании систем защиты, поскольку данная информация относится к категории конфиденциальной.

Специфика проектов внутренней информационной безопасности

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

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

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

Подробное описание организационной части проектов выходит за рамки этой статьи, поэтому просто перечислим ее компоненты. Во-первых, нужно провести аудит всей конфиденциальной информации на предмет того, как и где она рождается; кем, как и где изменяется; кем, как и где архивируется в информационной системе компании. Во-вторых, следует защитить эту информацию организационно, приняв соответствующие внутренние документы: «Положение об обращении с конфиденциальной информацией», «Положение о коммерческой тайне» и т. п. В-третьих — легитимизировать комплексную систему защиты информации, т. е. проинформировать сотрудников о том, что такая система есть, объяснить, что именно она делает, а также указать, что сотрудник может делать с информацией, а на что не имеет права. И последнее — нужно уметь организационно и технически правильно привязывать личность нарушителя к его «электронной копии» (IP-адресу, учетной записи, адресу электронной почты). Все четыре компонента важны для легитимного использования результатов: первые два — для фиксации объекта кражи, вторые два — для возможности использования доказательств в суде. Автору известны случаи, когда похититель, даже схваченный с поличным, уходил от ответственности, так как информация не была проведена приказом как конфиденциальная, а следовательно, формально не представляла ценности. В другом случае работодатель смог представить в суд только электронные копии журналов Интернет-сессии, которые не были приняты судом в качестве доказательств.

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

И последняя особенность таких проектов — отсутствие опыта внедрения и использования аналогичных систем. Большинство решений, относящихся к этому типу, внедряются впервые, на рынке недостаточно специалистов и консультантов в данной области. Большинство компаний последовательно наступают на одни и те же грабли. Следует отметить, что спрос на специалистов по реализации таких проектов сегодня особенно велик в банках: иметь такие системы требуют сразу несколько регуляторов (Стандарт информационной безопасности Банка России, PCI DSS, ФЗ «О персональных данных» и т. д.).

Предыстория рынка DLP

Большинство проектов защиты от внутренних угроз начинались как «продуктовые», т. е. в них ставилась задача покупки некоторого ПО, имеющего в качестве одной из функций возможность противостоять утечкам информации изнутри информационной системы. Подавляющее большинство этих продуктов — средства мониторинга и защиты электронной почты. Такие системы приобретались в 2000–2003 гг., и есть компании, где они до сих пор честно несут свою службу. Стоит отметить, что эти решения изначально проектировались как «канальные» (иногда используют термин «шлюзовые»), т. е. имеющие целью защитить конкретный канал, чаще всего — электронную почту. Соответственно такое решение реализовало еще несколько функций информационной безопасности для конкретного канала — почтовый антивирус, защиту от спама, фильтры на картинки и видео непристойного содержания, почтовый архив и т. д. Никто из производителей таких систем — и тем более пользователей — до 2004 г. не рассматривал эти системы как элемент защиты от утечек.

Традиционно считается, что импульс к выделению таких систем в отдельный класс дало принятие в 2002 г. американского закона SOX (Sarbanes-Oxley Act, закон Сарбэйнса — Оксли). Однако, по мнению автора, таким толчком послужило принятие в то же самое время целого ряда американских отраслевых стандартов, обязывающих компании публично раскрывать масштаб утечек информации и ее причину. Именно анализируя открывшуюся информацию, специалисты InfoWatch пришли к выводу, что основные потери информации идут не извне, а изнутри. Западные и российские исследования последних лет показали, что большинство компаний готовы приобретать продукты, защищающие их от внутренних угроз.

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

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

От теории к практике

С чего же начинаются проекты защиты информации от утечек изнутри? Почти в половине случаев — со срочной покупки какого-нибудь решения. Затем в большинстве случаев следует разочарование. Разочарование бывает двух типов: клиническое «это не то, что нам нужно» или «как, оно само работать не будет?!» Причины разочарования просты — неправильно поставленная задача плюс недооценка административного ресурса, который компания использует для внедрения.

Пример из реальной жизни — представители одной компании выбирают решение для контроля оператора биллинговой системы. Приходя с референс-визитом в компанию, которая около года использует подобное решение, прежде всего они спрашивают: «А как вы боретесь с тем, что человек с правами администратора со своим ноутбуком по кросс-линку подсоединяется к операторской рабочей станции?» Натыкаются на непонимание: «У нас это просто невозможно, у нас пять человек имеют права администратора одновременно в сети и в приложении, и от них такая система не защищает». Визитеры радостно потирают руки — нашли уязвимость. Насколько известно автору, они до сих пор ищут систему, не имеющую такой уязвимости. Поскольку мы собираемся рассматривать «лучшие практики», останавливаться на неудачных внедрениях в этой статье не будем.

Итак, первое, что нужно сделать, — понять, для чего внедряется система. Причинами для внедрения могут быть требования регулятора, случившийся инцидент или построение комплексной системы информационной безопасности. Очень важно в каждом случае выявить внутреннего заказчика проекта (его еще называют «спонсором» проекта или даже его «покровителем»). Именно внутренний заказчик позволяет оценить организационные ресурсы, которые будут выделены на проект.

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

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

Затем нужно определиться с нарушителем — кто он, какие имеет права в информационной системе, какой у него уровень доступа к информации, к каким каналам он имеет доступ и т. д.

И последнее (по хронологии, но не по важности) — это определение критерия успешности проекта. Иными словами, перед началом проекта необходимо четко сформулировать, в каком случае пользователь будет считать себя удовлетворенным. Это не такая простая задача, как кажется на первый взгляд. Четко понимая, что стопроцентно эффективного решения для защиты информации от утечки не существует (всегда остается зрительная память пользователя, фотографирование экрана, переписывание данных на бумагу и т. д.), нужно изначально настраиваться на приемлемый уровень защиты.

Определившись с описанными параметрами, можно начинать решать технологические задачи.

Типовые проекты

Приведем основные типы реализованных проектов, информация о которых предоставлена компанией InfoWatch. На примере этих проектов видно, как для поставленной задачи с учетом выделенных ресурсов можно выбрать одно или несколько технических решений.

Пример А

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

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

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

Решение было выбрано не техническое, а организационное — сегмент сети, в котором обрабатывалась защищаемая информация, был гальванически отделен от сети, в которой обрабатывалась текущая информация. У всех конструкторов отобраны права локальных администраторов, на всех компьютерах разрешено к запуску единственное приложение — CAD/CAM-система. Естественно, никаких коммуникаций, кроме встроенных в систему проектирования, на компьютерах не осталось, как не осталось портов ввода-вывода, кроме сетевого. Вся связь с остальной информационной системой организована через один шлюз, у которого постоянно дежурит офицер информационной безопасности, по заявкам конструкторов выполняющий «опасные» операции с секретными документами (печать, копирование на сменные носители, отправку по электронной почте). Заявка подписывается непосредственным начальником заявителя и начальником первого отдела.

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

Пример Б

В компании Б была зафиксирована утечка информации через Интернет — сотрудник маркетингового отдела, пытающийся в полемике на профессиональном сайте доказать свою значимость, выложил в свой блог маркетинговую программу компании на ближайший год. Проблема дошла до генерального директора, который поручил разрешить ее ИТ-службе, уже имевшей негативный опыт попыток ограничить доступ сотрудников к ресурсам. Эти попытки натыкались на жалобы сотрудников, содержащие слова «ГУЛАГ», «параноики, подозревающие всех и вся» и «мешают работать». Генеральный директор — сам человек продвинутый, ведущий свой блог, — идею тотального отключения всех от всего, как в случае с проектом А, однозначно отверг.

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

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

Пример В

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

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

Рассматривалось несколько вариантов решений — от расстановки меток на документы в сочетании с мониторами активности пользователя, DLP-решение на основе хеш-отпечатков и DRM-решение. В результате было выбрано решение, сочетающее в себе ограничение доступа к хранилищу и внедрение системы управления правами (DRM), поскольку количество документов было практически статичным, количество обращений к ним велико, формат документов не выходил за рамки стандартных офисных форматов, а выделение решения в отдельный сегмент посчитали слишком затратным. В отличие от примера А пользователи этой информации должны были работать и с другими приложениями, а ставить два компьютера на стол сотне пользователей владельцы информации сочли невозможным по финансовым соображениям.

Как видно из данного примера, если секретная информация не меняется быстро и при этом нет задачи защитить ее любой ценой, то можно всю ее поместить в отдельное хранилище, каждый объект внести в DRM-систему и дальше специальному администратору («библиотекарю») управлять этими правами при выдаче документов из хранилища.

Типы проектов

Заметим, что во всех приведенных примерах потенциальные нарушители — это менеджеры среднего звена, рядовые сотрудники и специалисты. Модель нарушителя в этом случае сильно упрощается — потенциальных нарушителей довольно просто лишить прав локального администрирования своих рабочих станций, запретить им запускать «опасные» приложения, т. е. те приложения, с помощью которых можно обойти системы защиты.

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

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

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

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

Особо хочется отметить, что во всех трех случаях речь шла именно о защите информации, т. е. о блокировании выноса информации за пределы информационной системы. Многочисленные решения для мониторинга движения контента в описанных решениях даже не рассматривались. Мониторинг и архивирование любого трафика (на сленге офицеров информационной безопасности «корпоративный СОРМ») — совершенно другая задача. Ее постановку обычно связывают с расследованием инцидентов кражи информации, поэтому мониторинг движения контента в корпоративной сети иногда относят к решению задач внутренней информационной безопасности, однако к защите информации такое решение имеет весьма опосредованное, «психологическое» отношение. Возможно, зная, что все его действия записываются, злоумышленник и откажется от похищения, но если ему безразлично, узнает владелец информации о похищении или нет (например, он работает на конкурента или на спецслужбу), это его не остановит.

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

Заключение

По мнению аналитиков компании InfoWatch, пока российский и мировой опыт реализации проектов защиты от внутренних нарушителей невелик, если не считать таким проектом внедрение систем доступа к ресурсам, действующих по принципу: «нет доступа — нет утечки». По мере получения опыта компании отказываются от попыток найти решения для защиты «всего от всех» и более четко ставят задачу, сегментируя как защищаемую информацию, так и внутренних нарушителей.

В будущем российский рынок ждет новая волна DLP-проектов, обусловленная требованиями ФЗ «О персональных данных», Стандарта ИБ Банка России, PCI DSS и других регуляторов. Автор уверен, что в стране уже есть опыт удачных проектов защиты конфиденциальной информации от внутренних угроз, нужно лишь, чтобы его пропагандировали не заинтересованные производители ПО, а сами пользователи.

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

* Решения, предназначенные для защиты от внутренних угроз, сегодня принято обозначать термином DLP — Data Loss Prevention или Data Leak Prevention (защита от утечек данных).