Showing posts with label DLP and DRM/IRM. Show all posts
Showing posts with label DLP and DRM/IRM. Show all posts
Friday, September 25, 2015
Wednesday, April 16, 2014
Все запретить!
Не далече как вчера я пытался рассказать о том, что запреты неэффективны для борьбы с утечкой информации. И тут надо же:
В нас снова вдалбливают стереотипы о том, что безопасность == запрещение/ограничение/блокировка.
Коллеги, времена изменились! Сейчас значительно эффективнее предоставлять сервис и мониторить коммуникации, возможно, даже скрывая сам факт мониторинга. Это позволит вам не просто найти того, кто что-то слил и посадить его на кол, а, вполне возможно, провести полноценное расследование, выявить более серьезные преступления, установить не очевидные связи, поймать "более крупную" рыбу. Не даром говорят, что кто владеет информацией - владеет миром. Так владейте информацией - собирайте ее, обрабатывайте ее. Блокируя информационные потоки, вы блокируете свою возможность собирать информацию, а информация - основа любого расследования.
Не надо, чтобы пользователи бежали с корпоративных устройств во всякие BYOD-ы, спасаясь от ограничений, пытаясь быть максимально эффективными - сделайте так, чтобы корпоративными сервисами было удобно пользоваться, чтобы пользователи выбирали корпоративную среду всегда, когда им надо поработать - это и будет лучшей защитой от утечки, а, вместе с тем, вы получите полный контроль над информацией и работой пользователя.
Я уверен, что коллеги из Infowatch это все прекрасно понимают, да и любое DLP правильнее в современных условиях рассматривать как решение именно контроля и мониторинга, а уже потом - блокировки... скорее всего они пытаются попасть в стереотипы, которые когда-то вбили нам в голову - "минимум полномочий", "минимум функционала", "минимум сервиса" и т.п. - но используя стереотипы как инструмент продвижения продукта, они, к сожалению, продолжают их культивировать.
В нас снова вдалбливают стереотипы о том, что безопасность == запрещение/ограничение/блокировка.
Коллеги, времена изменились! Сейчас значительно эффективнее предоставлять сервис и мониторить коммуникации, возможно, даже скрывая сам факт мониторинга. Это позволит вам не просто найти того, кто что-то слил и посадить его на кол, а, вполне возможно, провести полноценное расследование, выявить более серьезные преступления, установить не очевидные связи, поймать "более крупную" рыбу. Не даром говорят, что кто владеет информацией - владеет миром. Так владейте информацией - собирайте ее, обрабатывайте ее. Блокируя информационные потоки, вы блокируете свою возможность собирать информацию, а информация - основа любого расследования.
Не надо, чтобы пользователи бежали с корпоративных устройств во всякие BYOD-ы, спасаясь от ограничений, пытаясь быть максимально эффективными - сделайте так, чтобы корпоративными сервисами было удобно пользоваться, чтобы пользователи выбирали корпоративную среду всегда, когда им надо поработать - это и будет лучшей защитой от утечки, а, вместе с тем, вы получите полный контроль над информацией и работой пользователя.
Я уверен, что коллеги из Infowatch это все прекрасно понимают, да и любое DLP правильнее в современных условиях рассматривать как решение именно контроля и мониторинга, а уже потом - блокировки... скорее всего они пытаются попасть в стереотипы, которые когда-то вбили нам в голову - "минимум полномочий", "минимум функционала", "минимум сервиса" и т.п. - но используя стереотипы как инструмент продвижения продукта, они, к сожалению, продолжают их культивировать.
Posted by
Sergey Soldatov
0
comments
Labels: DLP and DRM/IRM, Enterprise Security
Wednesday, September 1, 2010
Классификация информации и DLP
Я решил повнедрять DLP. На данном этапе (весьма и весьма начальном) выяснил, что несмотря на то, что тема "модная" и внедрятели рассказывают о том, что это успешно делается, все далеко не так просто. Не буду тратить время на рассказ как работают системы DLP, перейду сразу к проблемам "стандартного" подхода к внедрению.
- У меня есть классификация информации, допустим: Коммерческая тайна (КТ), Для служебного использования (ДСП) и Открытая (О). Крайне сложно понять какие типы информации попадают в какие классы, так как: а) это невозможно сделать без заинтересованности бизнес-подразделений, чего добиться крайне сложно, б) сами бизнес-подрездения не имеют представления какие типы информации у них в обращении.
- Даже если я, с горем пополам, определил какие типы информации попали в какие категории, крайне сложно научить DLP распознавать эти типы информации с нужной степенью достоверности, а низкая достоверность крайне неблагоприятно влияет на стоимость владения.
- Такой подход к категоризации опять же решит задачу, так как один и тот же тип информации (например, договор) в разных случаях может иметь различную категорию. Как эти исключения "запрограммировать", я не знаю.
Сразу оговорюсь, что подобый "стандартный" подход с большой степенью вероятности применим в сильно заформализованных предприятиях, например государственных, где четко определены категории документов и даны требования к их оформлению (например, на них обязательно проставление грифов). Тут все будет просто и красиво.
Подискутировав данную тематику с коллегами родился следующий подход, который я и предлагаю на ваш суд, уважаемые читатели, любые мысли относительно изъянов данного подхода крайне интересны. Для предметности и понятности я буду давать пояснения на примере файлов в сетевых папках.
Задача DLP - предотвратить компрометацию данных, т.е. чтобы неавторизованные пользоватли не получили доступ к информации. Пока, на данном, начальном, этапе предлагаю единицей информации банально считать файл (в дальнейшем можно поиграться с цифровыми отпечатками, ключевыми словами с весами и прочими инструментами, которые предоставляет DLP для классификации данных "на лету", но давайте есть слона по частям) Аналогична и задача контроля доступа.
Процедура получения доступа к информационному ресурсу формализована, не важно используется MAC, DAC или RBAC. В любом случае есть роль, которая выполняет согласование уровня доступа к реусурсу желающим. Идея заключается в распростаранении такого же подхода на отдельные файлы. Идентифицировать конкретные файлы можно, например по хешу или как-то по принадлежности к сетевому ресурсу (по тому, в какой сетевой папке лежит), если такая возможность у DLP имеется. Соответственно, будет две политики использования: только чтение или чтение и изменение, аналогично тому, как это настраивается для сетевого ресурса: доступ в папку только по чтению или по чтению и записи. Можно подумать о введение дополнительных прав, например, запрет удаления. При этом, основная цель недопущения компрометации документа будет достигнута - пользователь не получит доступ к файлу, если у него нет членства в группах доступа к сетевому ресурсу, где этот файл хранится, независимо от того, как пользователь этот файл получил: по почте от коллеги, через съемный носитель или еще как. Доступ к файлу он получает на основании членства в группе доступа к сетевому ресурсу, которое появляется после отработки процедуры предоставления доступа в сетевой ресурс, через согласующего.
Отвязывание политики доступа к файлу "как к его сетевому ресурсу" должно согласовываться аналогичным предосталвленю доступа образом через назначенного согласующего.
Проблемы, что я тут вижу:
- Политик использования файлов у меня будет столько сколько сетевых ресурсов и типов доступа к ним у меня есть, т.е. тьма.
- Вместо "похожих" по цифровым отпечаткам у меня одинаковой политикой использования будут обладать непохожие документы, имеющие фиксированый хеш и принадлежность к одной папке (вот единственный критерий "похожести").
Posted by
Sergey Soldatov
11
comments
Labels: DLP and DRM/IRM, Enterprise Security
Subscribe to:
Posts (Atom)