Опрос: Сколько трафика входящего и исходящего у вашего почтовика в мес

"Cruiser78" написал:

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

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

"Cruiser78" написал:

2. По DLP - баловство это. Здесь я стою на позиции "заставь дурака Богу молиться, он и лоб расшибет".

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

dyasny написал:

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

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

dyasny написал:

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

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

"Cruiser78" написал:

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

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

"Cruiser78" написал:

Иллюзия. Эспортируем таблицу с номерами в pdf или в jpg и накрываются медным тазом все эти паттерны.

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

"Cruiser78" написал:

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

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

"Cruiser78" написал:

Я проходил через это, как раз через нечто подобное DLP.

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

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

dyasny написал:

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

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

"Cruiser78" написал:

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

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

"Cruiser78" написал:

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

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

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

dyasny написал:

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

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

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

dyasny написал:

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

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

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

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

"Cruiser78" написал:

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

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

"Cruiser78" написал:

Ну а потом - несколько лет доработок...

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

"Cruiser78" написал:

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

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

"Cruiser78" написал:

Еще раз уточню - всё это было предназначено для контроля одной кастомной системы. Большой замкнутой системы.

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

"Cruiser78" написал:

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

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

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

dyasny написал:

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

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

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

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

"Cruiser78" написал:

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

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

"Cruiser78" написал:

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

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

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

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

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


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