Я решил повнедрять DLP. На данном этапе (весьма и весьма начальном) выяснил, что несмотря на то, что тема "модная" и внедрятели рассказывают о том, что это успешно делается, все далеко не так просто. Не буду тратить время на рассказ как работают системы DLP, перейду сразу к проблемам "стандартного" подхода к внедрению.
- У меня есть классификация информации, допустим: Коммерческая тайна (КТ), Для служебного использования (ДСП) и Открытая (О). Крайне сложно понять какие типы информации попадают в какие классы, так как: а) это невозможно сделать без заинтересованности бизнес-подразделений, чего добиться крайне сложно, б) сами бизнес-подрездения не имеют представления какие типы информации у них в обращении.
- Даже если я, с горем пополам, определил какие типы информации попали в какие категории, крайне сложно научить DLP распознавать эти типы информации с нужной степенью достоверности, а низкая достоверность крайне неблагоприятно влияет на стоимость владения.
- Такой подход к категоризации опять же решит задачу, так как один и тот же тип информации (например, договор) в разных случаях может иметь различную категорию. Как эти исключения "запрограммировать", я не знаю.
Сразу оговорюсь, что подобый "стандартный" подход с большой степенью вероятности применим в сильно заформализованных предприятиях, например государственных, где четко определены категории документов и даны требования к их оформлению (например, на них обязательно проставление грифов). Тут все будет просто и красиво.
Подискутировав данную тематику с коллегами родился следующий подход, который я и предлагаю на ваш суд, уважаемые читатели, любые мысли относительно изъянов данного подхода крайне интересны. Для предметности и понятности я буду давать пояснения на примере файлов в сетевых папках.
Задача DLP - предотвратить компрометацию данных, т.е. чтобы неавторизованные пользоватли не получили доступ к информации. Пока, на данном, начальном, этапе предлагаю единицей информации банально считать файл (в дальнейшем можно поиграться с цифровыми отпечатками, ключевыми словами с весами и прочими инструментами, которые предоставляет DLP для классификации данных "на лету", но давайте есть слона по частям) Аналогична и задача контроля доступа.
Процедура получения доступа к информационному ресурсу формализована, не важно используется MAC, DAC или RBAC. В любом случае есть роль, которая выполняет согласование уровня доступа к реусурсу желающим. Идея заключается в распростаранении такого же подхода на отдельные файлы. Идентифицировать конкретные файлы можно, например по хешу или как-то по принадлежности к сетевому ресурсу (по тому, в какой сетевой папке лежит), если такая возможность у DLP имеется. Соответственно, будет две политики использования: только чтение или чтение и изменение, аналогично тому, как это настраивается для сетевого ресурса: доступ в папку только по чтению или по чтению и записи. Можно подумать о введение дополнительных прав, например, запрет удаления. При этом, основная цель недопущения компрометации документа будет достигнута - пользователь не получит доступ к файлу, если у него нет членства в группах доступа к сетевому ресурсу, где этот файл хранится, независимо от того, как пользователь этот файл получил: по почте от коллеги, через съемный носитель или еще как. Доступ к файлу он получает на основании членства в группе доступа к сетевому ресурсу, которое появляется после отработки процедуры предоставления доступа в сетевой ресурс, через согласующего.
Отвязывание политики доступа к файлу "как к его сетевому ресурсу" должно согласовываться аналогичным предосталвленю доступа образом через назначенного согласующего.
Проблемы, что я тут вижу:
- Политик использования файлов у меня будет столько сколько сетевых ресурсов и типов доступа к ним у меня есть, т.е. тьма.
- Вместо "похожих" по цифровым отпечаткам у меня одинаковой политикой использования будут обладать непохожие документы, имеющие фиксированый хеш и принадлежность к одной папке (вот единственный критерий "похожести").
11 comments:
Решение отличное, но мне кажется применимо только для документов типа "ДСП". Поскольку решение о блокировке доступа принимается на основе "текущих" прав, как только становится необходимым поделиться файлом с внешним миром (подрядчики и т.п.), то возникает проблема поскольку такой доступ будет блокирован.
Как отвлеченная тема, мне очень нравится концепция привязки прав доступа не к хранилищу, а к информации. Я имею в виду технологии типа Microsoft RMS (или Adobe rights management) по сравнению с правами на сетевую папку. То что ты описал как раз попадает в категорию "привязка прав к документу". Но я уверен, что внедрение любой системы такого типа не будет успешным, если она не учитывает требований по обмену информацией, в частности с внешним миром.
Амиран, мне тоже нравятся решения типа WRMS, Adobe и прочие решения DRM/IRM (Digital Rights Management/Information rights management). Их общая проблема, что по умолчанию сами собой они не инфорсятся, т.е. либо пользователю надо самому предприянять некий экшен, чтобы этот DRM/IRM к документу приделался, либо тупо приходится настраивать, что все документы этого человека будут с привязанной такой-то политикой. Никакой гибкости, скажем, от конткнта здесь нет. Заинфорсить IRM/DRM можно двумя способами: доработать приложение, например, Word, чтобы пользователю при сохранении документа выскакивался промптер: "двай решать, какую политику привязывать, а то не сохраню", либо через DLP. Через DLP представляется более привлекательным, так как тут есть модные штуки анализа контента, да и доработать все приложения, чьи документы хочется окучить задача тяжелая и не поддерживаемая. Если выбираем DLP, то туда надо заходить с классификацией: надо ей точно сказать как на основании контента документа понять, что данный документ - "Коммерческая тайна", а вот этот - "ДСП". "Сходи в бизнес-подрезделения и спроси", - скажешь ты. Ходили, даже есть какой-то результат, но не настолько детальный, чтобы его можно было зарпограммировать в DLP. Поэтому и появилась очевидная идея - окучиться как есть, а потом, когда появятся запросы от бизнеса, уже быть готовыми дать им решение. Один из вариантов "как есть" я здесь и описываю. Мне очень интересен фидбэк, так как если взять любую книжку про DLP, там рассказано про то, как надо классифицироваться по контенту. Лично я не верю в надежную работу этих средств без пердварительно подготовки этого контента.
Я хотел предложить немного иной вариант.
Проблемы подхода Сергея (его сейчас считаю основным) дополняю:
1. Необходимость синхронизации политик со структурой каталогов.
2. Разработка алгоритма решения конфликта при рассинхронизации структуры каталогов и политики.
3. По прежнему в процессе определения категории документа задействована служба безопасности.
4. Дополнительная нагрузка на компьютеры сотрудников\серверы\ИС в части работы системы.
5. Потеря функциональности либо блокирование работы компании при сбоях в работе системы (вспомните антивирусы).
Предлагаю несколько иной подход, который по сути является вариантом. Исхожу из принципов:
1. Минимизация затрат
2. Снятие нагрузки со службы безопасности, перемещение точки принятия решения поближе к владельцу документа.
3. Решение проблемы внешнего обмена.
Итак, документы по прежнему лежат на файловой системе. Права на файловой системе выданы исходя из уровня доступа сотрудников. До настоящего момента все более или менее обычно.
А теперь, запрещаем обмен внутри компании документами. То есть сотрудники не могут пересылать документы коллегам и передавать на сменных носителях, они могут отправлять лишь ссылки на них.
При пересылке наружу сотрудник должен принять решение о возможности данного действия самостоятельно.
В результате:
1. Нет необходимости внедрения дополнительных систем - снизили стоимость владения.
2. Уменьшение нагрузки на СБ в части контроля за обменом информации внутри компании.
3. Нет необходимости проводить дополнительные классификации, тк считаем, что они уже выполнены.
4. Снижаем нагрузку на ИС в целом, когда один и тот же документ дублируется в разных версиях в почтовых ящиков десятков сотрудников.
Системы типа MRMS хороши, но нагрузка по поддержанию их работоспособности слишком велика. Возможно ее стоит задействовать при обмене с внешними контрагентами.
Коллеги, прямо затрудняюсь, что и сказать...
Есть классическая модель: IAM<->(IRM+DLP)<->SIEM и под нее ориентированы имеющиеся решения.
Не умничаю, но попал в тупик с изначальной посылкой Сергея: что обсуждаем то?, тк: посылка идет от IRM с сетованием на плохую реализацию IAM + упоминание DLP с конечной привязкой к IRM и которое в контесте оказывается вообще не при чем, кроме как снятие отпечатков. В итоге
приходим к правам доступа ro/rw на файл - это и есть проблема?
Может с понятиями у меня плохо?:) ->
IRM -> безопасность документооборота;
DLP -> контроль за перемещением информации;
SIEM -> контроль событий;
IAM -> управление доступом и правами;
Далее:
- В контексте MRMS+DLP к-во решений более чем ограничено, а в плане IAM (== удобство управления) - MS
далеко не лучший.
- обмен ссылками - обычный метод работы с док-тами;
и тд.
Какая формулировка задачи?
Игорь, хороший вариант, но я не знаю как запретить передачу документов. Есть концептуальный момент: если человек может почитать документ и у него свой end point, он может туда скопировать доумент.
Более или менее живой варинат тут - пересадить всех на что-то типа Citrix, чтобы все общение людей проходило внути одной информационной системы, а он бы уже обладала достаточным интеллектом, чтобы вместо пересылки документов пересылать ссылки.
Саш,
тут проблема в том, что хочется DLP, но не хочется делать классификацию. Причем второе не хочется не потомучто мы лентяи, а потому что задача эта не подъемная и, даже если она подъемная, поддерживать классификацию в актуальном состоянии я не представляю как, в любом случае, - это очень дорого.
Поэтому, предложена идея, делить информацию не на категории, типа КТ, ДСП, Прочее, а на "кучки", доступные разным людям. Как начальный вариант предлагаю одну кучку "все что нашлось в корп хранилищах" и пользователи - "все члены корпоративного домена". Потом, уже в диалоге с бизнесом, можно повыделить другие кучки с пользователями.
Просто в изначально постоянно звучали вопросы доступа к файлу. Задача DLP - управлением перемещением информации/данных на носители/по сети, но в отдельных реализациях (RSA DLP например) стыкуется с IRM (AD RMS в этом случае) для присвоения ейных предварительно заданных шаблонов прав доступа файлам,отвечающих результатам заданного для DLP поиска на сетевых шарах и тп.
Если сумели поделить на кучки - уже считай как-то классифицировали.
С позиции DLP - далее надо снять с кучек отпечатки от необходимых/всех типов файлов и привязать к ним требуемые политики.
А затем уже возможны разные вар-ты развития событий, например:
- связать с IRM и сосредоточиться на правах доступа;
- развертывать сетевую и end-point части DLP;
- их комбинации (напр., IRM + DLP Network для шифрования на почтовом шлюзе дешифрованных c IRM документов для сторонних лиц)
и тд и тп
А дальше - наведение порядка...
Но вообще, по-мне, старт решения задач такого рода дб на уровне CISO, те с соотв.общей проработкой и пониманием
наверху, после чего заработают другие рычаги: и конфиденциальная информация сразу формализуется, и
шаблоны для соотв. документов с заданными каталогами хранения образуются ;) Постепенно, но здесь путь постепенного расширения как-то естественней.
Саш, мне очень нравится идея реализации DLP на уровне сетевого оборудования. Это будет действительно правильно. Интересно, у Cisco есть планы по интеграции с каким-нибудь DLP-вендором. Надо поспрашивать....
Контроль документов при перемещении - одна из задач DLP. Лично мне кажется, что она не самая главная, так как если у тебя документ за-WRMS-ен, в целом не важно куда и как он уходит, ибо WRMS гарантирует, что:
1. его прочитают только авторизованные люди, то же про модификацию,
2. он будет уничтожен, в соответствии с заданной политикой.
2Сергей: ограничить пересылку документов можно технически, ограничив размер сообщений на почтовом сервере. У MS Exchange наверное не все просто, но наверняка есть доп.ПО. Плюс к этому организационные меры: приказ, контроль, наказание.
С печатью - проблема. Но на сегодня любое средство DLP умеет собирать данные об отправленных на печать документах. Как показывает практика, несколько проверок и проблема решится.
Я к чему клоню - невозможно решить проблему только технически, нужны организационные мероприятия.
2Alexander: Увы обмен ссылками не обычный метод работы внутрикорпоративной. Это мой опыт :).
2ALL: Как Сергей уже сказал - без классификации непрерывной (почти ежедневной) система станет неактуальной в течение квартала, максимум года. Посему либо это должно быть опущено на плечи пользователей, через навязчивые диалоги при сохранении, либо на их же плечи, через процедуру размещения документов в ИС. У меня есть мечта: создать отдел из нескольких любопытных старушек, которые будут заниматься перлюстрацией почты и, как оказалось, задача классификации информации тоже прекрасно ложится на этот отдел :)
Игорь, я до необходимости анализа данных тоже дорос. Причем у меня есть, как мне кажется, сбыточные планы посадить человека на анализ файловых помоек. А почему ты хочешь только почту? Бери все, что может хранить данные:
- почта
- endpoint-ы
- файловые помойки
- Web
На рынке есть решения, которые смогут все эти источники сливать в единую базу, над которой уже можно творить аналитику.
Ещеинтересный момент, которых хочется проанализировать (вот не доходят руки написать на эту задачу ТЗ) - анализ доступов пользователей в файловые помойки и корреляция этого доступа:
- с местом работы пользователя, позицией, в общем с HR
- с тем как фактически этот доступ используется.
Первое поможет причесать наше Least Privilege, второе - наше Need to Know.
Я видел только одно решение, которое это делает - Varonis - но оно мне показалось дороговатым для этой небольшой задачи.
В общем, будущее за анализом данных и бизнес-процессов, надо вылазить из своих железок :-)
Post a Comment