3.3.Предыстория рынка dlp

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

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

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

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

3.4.Практические мероприятия по защите информации

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

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

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

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

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

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

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

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