Я с этим полностью согласен. Но решение контролировать именно core bisiness - это не моя идея (более того, я был её последовательным противником). Но то решение было принято более из политических соображений. Основы техники в расчет не брались.

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

потоки информации в системе можно свести к основным точкам - места доступа, хранения и выхода за периметр предприятия. файловые хранилища можно сканировать, базы данных тем более, все это нормальные DLP отлично умеют. доступ тоже контролируется обычно на уровне агента на десктопе который смотрит и ведет учет открытым файлам и страницам, буферу обмена и т.д.
иходящие потоки контролировать тоже не сложно - те же smtp, http или даже json/xmlrpc/rest/soap и переслание на принтер легко разобрать и прогнать через фильтры - форматы ведь вполне стандартные.
внутри компании тоже передача данных не может вестись какими либо нестандартными методами* (а если ведется, то это легко заблокировать даже на свиче, если свичи покупать правильные). Да и как бы она ни шла - пока информация не уходит наружу - ничего страшного. Если разные отделы должны иметь защиту от утечки, то настраиваем отделы разными сетями и организуем связь между ними так же как с интернетом - только после фильтрации на известных проходных точках.

Если документ изначально защищен, то DLP уже сделает стойку на его открытие. Часть документа попадает в буфер обмена - агент на десктопе это ловит и тоже пишет в лог. Пересылка по внутренней почте тоже попадает в логи, и если почта идет от департамента на одном уровне защиты в другой, с другим уровнем, это уже утечка, которую можно или просто записать, или заблокировать на мейлере, причем в лог уже попадает и from и rcpt.

на самом деле, обычно агент на десктопе не даст вообще копировать что либо из защищенного дока.

*а за нестандартные бинарные потоки надо отрывать разработчикам руки и втыкать в то место которым они до такой идеи додумались.

конечно, но ты ведь сам сказал - "для выполнения своих основных функций". Если сделать все с умом, то именно core business остается внутри, в полной безопасности, а внешние каналы работают по стандартным методам - мейл, фтп, хттп и т.д. А для стандартных методов есть стандарты (пардон за тавтологию), и под эти стандарты пишутся "полочные" DLP которые не ломаются от изменения в протоколе smtp, бо этот протокол фиг поменяешь

Я с этим полностью согласен. Но решение контролировать именно core bisiness - это не моя идея (более того, я был её последовательным противником). Но то решение было принято более из политических соображений. Основы техники в расчет не брались.

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

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

Разработчиков выбирал не я. Я был тогда вообще очень далёк от этой проблемы. А въехали эти разработчики в контору, где я тогда работал (в Банк России) на волне фальшивых "чеченских" авизовок. Нарисовали эскизный проект системы наблюдения и контроля в которой, якобы, можно было проанализоровав поведенческую модель работы пользователя (вызовы тех или иных функций приклада, вплоть до анализа текстов, названий, пунктов менюшек ) выявить факт "вброса" фальшивого платежного документа юзером в потоке обычного легального ввода.

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

...что является болезнью любой самописаной системы.

конечно, но ты ведь сам сказал - "для выполнения своих основных функций". Если сделать все с умом, то именно core business остается внутри, в полной безопасности, а внешние каналы работают по стандартным методам - мейл, фтп, хттп и т.д. А для стандартных методов есть стандарты (пардон за тавтологию), и под эти стандарты пишутся "полочные" DLP которые не ломаются от изменения в протоколе smtp, бо этот протокол фиг поменяешь

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

а не нужно контролировать, нужно просто держать лог, кто что взял, и куда дел. data path breadcrumbing то есть. превентивные меры только на точках выхода наружу - внешние каналы и переносимые хранители.

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

а заказано оно было у специалистов по DLP или у просто разработчиков без специфичного опыта?

Разработчиков выбирал не я. Я был тогда вообще очень далёк от этой проблемы. А въехали эти разработчики в контору, где я тогда работал (в Банк России) на волне фальшивых "чеченских" авизовок. Нарисовали эскизный проект системы наблюдения и контроля в которой, якобы, можно было проанализоровав поведенческую модель работы пользователя (вызовы тех или иных функций приклада, вплоть до анализа текстов, названий, пунктов менюшек ) выявить факт "вброса" фальшивого платежного документа юзером в потоке обычного легального ввода.
Для меня это изначально прозвучало, что сие - лженаука. И я, получив задание оформить проект ТЗ этому разработчику абсолютно сознательно переписал, скопипастил, из эскизного проекта это самое выявление факта вброса как требование к системе.  Эту "шутку" более высокие чины просекли (или им подсказал кто, не знаю) и в окончательном варианте из ТЗ данный пункт был убран.  Но на этапе приемки данного поделия потоптались на этом тезисе изрядно. Разработчик выглядел достаточно бледно, но работу таки сдал, сошлись на мнении, что их система есть система _доверенного_ аудита. Ну а потом - несколько лет доработок...

Я всегда прекрасно понимал, что ребята научились встраиваться в адресное пространство прикладной офтопичной задачи и наблюдать все её вызовы, но вот что именно делать с потоком этого наблюдения... В результате система показывала только очень явные отклонения от штатного  поведения (администратор зашел на комп по своей надобности). Но такой административный заход легко фиксировался иными, более штатными, средствами.

Большие конторы очень часто, если не повсеместно, используют для выполнения своих основных функций именно кастомный софт. Который разрабатывают или самостоятельно, в профильном подразделении, или разработку ведет специализирующаяся на этой разработке контора. Так что кастомный софт неизбежен. Как и постоянная "жизнь" его ABI/API.
Ну и плюс казённые амбиции моего руководства. Все мои слова, что сопровождать разработку этой "DLP" должен разработчик типового программного комплекса, под который эта DLP и точилась - игнорировались. Как же, мы - опорный регион по сопровождению "DLP", можно человечка-другого, дополнительно, в отдел нанять. Ну и "мы, опорный регион" звучит гордо. Правда, штатов под опорный регион нам так и не добавили. Обходитесь своими силами. Хотя - когда возникала очередная волна оптимизаций - опорность помогала сохранить людей в отделе.

Но это было всё лет 5 и более назад. Как там сейчас - не знаю.

Еще раз уточню - всё это было предназначено для контроля одной кастомной системы. Большой замкнутой системы.
Был еще форк этой DLP под офисные нужды, но там всё было вообще грустно. Контроль потоков защищаемой информации обеспечить было практически нереально. Как связать открытие документа, содержащего кроме всего прочего, защищаемую информацию, копировние её в клипборд, далее вставка буфера в почтовое сообщение, отправка на соседний комп, далее обработка сообщения соседом (от которого можно получить его же и обратно) и отсылка куда-нибудь еще... В принципе, это легальная схема подготовки документа несколькими сотрудниками. И документ выходящий, при этом может быть как "секретным", так и не содержать никаких секретов. Как вычленить в этой каше утечку конфиденциального абзаца из оригинального документа - не представляю. Так что и в офисной своей части этот форк контролировал запуски ворда с екселями и отлуками. Но контроля потоков информации по Беллу-Лападулу там не было...

Это была заказное программное обеспечение нацеленное на анализ действий юзера в одной крупном программном комплексе для очень крупной конторы.

а заказано оно было у специалистов по DLP или у просто разработчиков без специфичного опыта?

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

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

интересно что именно это было, на самом деле интересно.

Название широкой публике ничего не скажет. Это была заказное программное обеспечение нацеленное на анализ действий юзера в одной крупном программном комплексе для очень крупной конторы. Веселуха начиналась тогда, когда разработчик этого комплекса планово или нет вносил изменения в свой комплекс. Все это наше DLP мгновенно раскорячивалось от этих изменений. Соответственно поток событий НСД прямо пёр... Пока не скажешь, что это всё легально и надо пропускать. И в этом потоке можно было запросто и реальное НСД проглядеть, и объявить его легальным действием, разрешить его...
Именно этот опыт работы и настроил меня очень скептически по отношению ко всему семейству DLP.

Бизнес - он разный. У меня внешних данных немного, а каналы на фирму - тонкие. Забивать эти каналы трафиком от нашего WWW и FTP - нецелесообразно.

это конечно, и разговор не о том А о том разговор, что не стоит пользоваться одной единственной мерой для обеспечения бесопасности совершенно разных сервисов.

вы, мсье, будете удивлены

вот мне интересно, это из личного опыта разработки и работы с серьезными системами DLP или так, бабушка надвое вилами по воде? Потому что я немного знаком с  вебсенсом изнутри, чуть даже не остался там работать, и там сидят далеко не дураки, да и систем обнаружения там немного больше чем в по детски наивном mydlp

интересно что именно это было, на самом деле интересно.

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

ftp таких размеров будет стоить изрядных денег, да и незачем он, мы хостерам не доверяем, у фирмы особенная степень паранойи

Бизнес - он разный. У меня внешних данных немного, а каналы на фирму - тонкие. Забивать эти каналы трафиком от нашего WWW и FTP - нецелесообразно.

Иллюзия. Эспортируем таблицу с номерами в pdf или в jpg и накрываются медным тазом все эти паттерны. Ну а если юзеру разрешено обмениваться с внешним миром этими форматами - ищи ветра в поле. Никогда не найдешь передачу инсайдерской информации в общем таком потоке. DLP - красиво в теории, но на практике реализуемо так же, как и модель мандатного доступа Белла-Лападула. Для того, чтобы DLP хоть как-то заработало необходимо реализовать именно метод ножниц, полностью изолировать свою систему от внешнего мира и оставить общение с ним только через очень определенные контролируемые каналы. Плюс - жесткая политика в части исполняемых функций в прикладе на всех компах системы. Как правило - это не реализуемо. А если этого не реализовать, то будет очередная профанация. Я проходил через это, как раз через нечто подобное DLP.

1. А в чем особый смысл держать такой файлер на собственных ресурсах. У меня корпоративный WWW и FTP у хостера. И нет проблем.

ftp таких размеров будет стоить изрядных денег, да и незачем он, мы хостерам не доверяем, у фирмы особенная степень паранойи

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

плюс у меня есть еще и требования к внешним контракторам, которые должны закачивать файлы на наш файлер - давать им доступ в vlan где все юзеры vpn сидят? нет уж - только одноразовые пароли и SFTP.

что касается DLP, то тут нужен правильный подход. Эта система вряд ли способна полностью предотвратить уечку, да и не в этом ее задача. А задача ее в том, чтоб узнать как утечка произошла, если она все таки случится.

1. А в чем особый смысл держать такой файлер на собственных ресурсах. У меня корпоративный WWW и FTP у хостера. И нет проблем.
2. По DLP - баловство это. Здесь я стою на позиции "заставь дурака Богу молиться, он и лоб расшибет". До тех пор, пока юзеры не станут сдавать свои головы в секретную часть - в своей голове они унесут всё что угодно. Самую большую ценность представляет не сам документ, а идея как сделать, концепция, подход. Человек может просто за рюмкой чая сболтануть (по доброте душевной) лишнее, а специалисту достаточно и этого "лишнего", чтобы понять суть секрета и раскрутить его на своих подходах. DLP - это дорогостоящаа имитация безопасности.

Есть причина, есть следствие. У меня не только почта в VPN завернута. Но и иные сервисы. Например, Asterisk. Оплачивать звонки в Нигерию? Потому и закрываю всё единым механизмом.

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

плюс у меня есть еще и требования к внешним контракторам, которые должны закачивать файлы на наш файлер - давать им доступ в vlan где все юзеры vpn сидят? нет уж - только одноразовые пароли и SFTP.

a некоторые сервисы заперты настолько наглухо что никакой VPN не поможет - только source IP == bastion-server который сам по себе за двумя файрволлами.

что касается DLP, то тут нужен правильный подход. Эта система вряд ли способна полностью предотвратить уечку, да и не в этом ее задача. А задача ее в том, чтоб узнать как утечка произошла, если она все таки случится.

какое это отношение имеет в тотальному использованию VPN?

Есть причина, есть следствие. У меня не только почта в VPN завернута. Но и иные сервисы. Например, Asterisk. Оплачивать звонки в Нигерию? Потому и закрываю всё единым механизмом. А чтобы исключить несанкционированный доступ к ключам VPN - шифруем диск, где они могут лежать. Я предпочитаю метод изоляции. Надежнее ножниц еще ничего не придумали. VPN как раз и обеспечивает нужную мне изоляцию.
А к DLP (если мы понимаем оно и тоже) у меня отношение, пока еще, осторожное. Это как порося стричь - визгу много, а шерсти мало. Настраивать DLP замучаешься, а толку  чуть выше плинтуса. Ожидаемый эффект не адекватен трудозатратам.

Зато дешево и практично. Какие есть угрозы (то есть строим модель нарушителя) от ремутного компьютера.
1. Ремутный (разъездной) ноут можно пролюбить в каком либо кабаке. Нарушитель получает доступ к телу ноута. Следовательно - надо сделать так, чтобы к данным, к ключам доступа, которые есть  на этом ноуте он доступа не получил. Как? Криптография. Диск тотально зашифрован.

какое это отношение имеет в тотальному использованию VPN?

и опять же - при чем тут доступ к почте?

у меня например зимбра, для доступа рекомендуется пользоваться не клиентами а веб панелькой - доступ к ней только по https. телефоны и клиенты на IMAPS

к терминалам доступ через цисковый VPN, плюс завинчены все гайки, вытащить документ из сервера можно только распечатав его (что видно в аудите) или сфотографировав экран

для телефонов кстати, разворачиваем MDM, и вебсенсовский DLP для всей фирмы.

Этот самый dualboot может быть слабым местом. Пусть и теоретически, но ведь может.

Нет. Его стойкость определяется решением задачи криптоанализа. Сумеешь расшифровать рабочий диск, то есть подобрать ключ - молодец, возьми с полки пирожок. А не сумеешь...
Так что есть дуалбут или нет его - всё едино.