© 1995-2021 Компания «Инфосистемы Джет»
DLP как сервис – маленькие радости реализации
Информационная безопасность

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

Информационная безопасность Тренд

DLP как сервис – маленькие радости реализации

Автор
Владимир Дрюков Руководитель департамента JSOC компании Solar Security. В прошлом - эксперт Центра информационной безопасности компании "Инфосистемы Джет"

19.08.2013

Посетителей: 56

Просмотров: 45

Время просмотра: 1 мин.

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

 

 

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

 

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

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

 

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

 

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

 

  • агенты рабочих станций и серверов, собирающих с этих источников информацию об активности с конфиденциальными данными;
  • сенсоры сбора данных, как выступающие в роли точки централизованного сбора информации с агентов, так и собирающие и обрабатывающие ее на сетевом уровне (SPAN-порт, почтовый и веб-трафик);
  • узел сбора инцидентов и исторический архив хранения, редактор политики.

 

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

 

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

 

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

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

 

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

 

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

 

Есть ли место интегратору?

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

 

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

Читайте нас в Telegram

Уведомления об обновлении тем – в вашей почте

Интегрировать нельзя игнорировать

Разумеется, мы хотим интеграцию с максимально возможным количеством систем, хотим выжать всю возможную информацию из всех мыслимых источников…

История одного DLP-расследования

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

DLP - не роскошь, а средство комфортного предупреждения утечек

Как нам кажется, DLP-систему в части ее назначения и функционирования вполне можно сравнить с автомобилем.

Волков бояться? Или все-таки в лес?

Если в компании встает вопрос о расследовании утечек информации, то, как правило, существуют те или иные признаки того, что подобная утечка вообще произошла

«Если ваш безопасник не умеет программировать, увольте его и наймите нормального»

Кирилл Ермаков, СТО компании QIWI, — личность известная. Кто-то знает Кирилла как жесткого спикера, способного озвучивать «неудобную» правду о рынке ИБ, кто-то — как создателя Vulners, яркого приверженца Bug Bounty и топового багхантера.

DLP как пазл, который должен сложиться

О практике использования DLP-решения беседуем с Алексеем Фроловым, руководителем Департамента по безопасности и режиму ПАО «Корпорация Иркут»

Интернет – взгляд на психологию пользователей и безопасность в организации

21-й век. Локальные конфликты, пробки и повышение цен на бензин. Люди вольно или невольно получают и обрабатывают огромные информационные потоки.

Заглянуть в цифровую черную дыру

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

Комплекс защиты от утечек информации «Дозор-Джет»: общая архитектура и функциональные возможности

Комплекс защиты от утечек информации «Дозор-Джет» представляет собой DLP-систему, ядром которой является «Система архивирования и анализа «Дозор-Джет», вот уже более 10 лет развиваемая компанией «Инфосистемы Джет».

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня