Привет, Хабр!
Мы часто просим наших заказчиков рассказать, как они на практике закрывали задачи по ИБ в своих компаниях. Недавно мы и сами делились опытом, как наводили порядок в файловых системах. Сегодняшний пост будет по мотивам воспоминаний об одной задачке, которую решал Николай Казанцев, будучи начальником отдела информационной безопасности в компании «ПОЛИСАН». В компании ему довелось застать момент введения режима коммерческой тайны, после чего остро встала необходимость разобраться, где хранятся документы под грифом ДСП и насколько хорошо они защищены. Далее с его слов.
В ходе долгих обсуждений как внутри отдела, так и с руководством тогда приняли решение, что нужно внедрять какой-то инструмент аудита всего файлового хозяйства. Хочу поделиться опытом: какие варианты пробовали, почему в итоге сделали выбор в пользу DCAP и почему некоторым компания эта система не нужна.
При внедрении режима комтайны приходится начинать с долгого и кропотливого процесса – восстановления картины, кто является внутренним «владельцем» того или иного документа, в рамках каких процессов информация создается и обрабатывается, в каких видах файлов содержится. Нужно построить информационную модель для каждого пункта из перечня сведений, составляющих коммерческую тайну.
Одним из важных информационных активов в компании был набор файлов с техническими показателями по производству. Все сотрудники подразделения, которые работали с ними, уверяли, что хранят документы в одной папке и следовали регламентированному процессу. Но время от времени появлялась информация, что где-то хранятся неучтенные или устаревшие копии, что сотрудники сохраняли себе эти документы из банального удобства. Было понятно, что надо проводить аудит папок и файловых серверов.
Столкнулись с вопросом: как аудит провести?
Ситуация с аудитом файловых хранилищ нетипичная. В случае с другими задачами инфобеза всегда есть выбор готовых инструментов – антивирусы, межсетевые экраны, песочницы, DLP-системы. Для построения же data-centric security (то есть аудита файлов, которые находятся не в движении, а в покое) нужно приложить фантазию.
Есть несколько вариантов, как организовать аудит. Мы испробовали следующие:
Самое очевидное – это вести аудит обращения к файлам средствами операционной системы в связке с системами анализа логов. Но в этом случае нагрузка на файловые серверы неприемлемо высока, да и об удобстве работы говорить не приходится.
RMS-системы (Rights Management Systems). Продукты прошлого поколения сразу не годились, т.к. имели очень узкое применение. Из современных тестировали Azure RMS. Концептуально он хорош, но не универсальный, слишком трудоёмкий в плане организации процессов. И нероссийской «прописки», что с прошлого года стало почти непреодолимым препятствием к использованию.
Тестировали Netwrix Auditor, но он использовал «под капотом» функционал журналирования ОС, что давало высокую нагрузку на серверы и рабочие станции.
-
DLP + другие инструменты – это было наиболее очевидным вариантом, т.к. DLP-система у нас уже использовалась. В «СёрчИнформ КИБ» был модуль «индексация рабочих станций» (это, по сути, e-Discovery), который находит файлы по заданным правилам во всем массиве рабочих станций и серверов. Анализ логов через модуль FileController давал представление, кто к ним обращается. Аудит прав доступа выполняли с помощью самописного скрипта и все это сгружали в систему аналитики данных (Power BI). Это позволяло нам составлять базовые профили информационных объектов: кто использует информацию, где она хранится, куда передаётся.
По базовому профилю вместе с владельцами информации определяли границы: где должен храниться файл, а где нет; кто может иметь доступ, как можно передавать информацию. Все отклонения прописывались в политики безопасности для DLP, сработки считались инцидентами.
По такому алгоритму мы и шли. Брали список того, что в нашей компании составляет коммерческую тайну, и прорабатывали каждый пункт.
Какое-то время такой подход позволял решать задачу. Но потом трудозатратность стала настолько критична, что подход оказался непригодным. Используя DLP и анализ логов с целью контроля файловых хранилищ, требуется постоянно объединять данные из разных источников. Условно, в компании со 100 рабочими станциями и одним файловым сервером – это несложно, а что делать, если их намного больше?!
Итого: все описанные решения не защищают от неправомерного доступа и ничего не знают о текущих правах доступа; не отслеживают жизненный цикл информации – откуда файл взялся, как редактировался, сколько его копий есть в организации и у кого хранятся; не работают проактивно; могут создавать неприемлемо большую нагрузку и требовать непомерно много СХД.
Но главное, чего не позволяют добиться все перечисленные способы – они позволяют разграничить доступ к документам только по контекстным признакам, таким как формат или принадлежность к какой-то папке. Контентное разграничение доступа они не делают. Это значит, что компании не защищены от ситуаций, когда один файл просто будет переложен в другое хранилище.
После этого поняли, что под задачу нужна именно DCAP-система, потому что с ней фокус с перекладыванием не пройдёт: система выявит, что этот документ по-прежнему является ПДн или коммерческой тайной – и применит к нему все ограничения политик безопасности.
И все же DCAP
Второе решение, которое ставили на тест из профессиональных DCAP-инструментов, – это «СёрчИнформ FileAuditor» (во-первых, на рынке кроме двух вышеупомянутых никого и не было, во-вторых, как я упоминал, у нас уже стояла DLP «СёрчИнформ КИБ». Строить общую «экосистему» казалось правильнее (и в итоге оправдало себя).
Плюс FileAuditor в том, что все сведено в одно место для решения конкретных задач аналитика. Работать стало быстрее, как следствие – больше устранённых инцидентов. Удобно, что функционал обращения к файлам вынесен в ту же панель, что и дерево каталогов, все в одном месте.
Конечно, контроль передачи информационных активов (через базовые модули DLP) и «данных в покое» (через FileAuditor) – это отдельные процессы информационной безопасности. Но вместе они позволяют построить наиболее полную информационную модель вокруг конкретных данных. Мы понимаем, где они хранятся, кто их кому передаёт, даже в какой последовательности. Как следствие, обладая полным пониманием «нормального» процесса, легче обнаружить отклонения, которые могут оказаться инцидентами безопасности.
Всегда ли нужен DCAP?
Нет. Покупка специализированного софта может не оправдать себя, если работа с ним не поставлена профессионально. Поэтому обращаю внимания на такие моменты:
Заниматься наведением порядка на файловых серверах и рабочих станциях пользователей задача важная. Но без контроля каналов передачи информации (с помощью DLP) – это может быть неконструктивно. FileAuditor должен быть продолжением уже встроенной, в том числе на базе DLP, инфраструктуры безопасности компании.
Так же не стоит бросаться в защиту файловых ресурсов пока не определились с тем, что, собственно, следует защищать. В компании должно быть сформировано понимание, какие информационные активы для неё наиболее критичны.
Нужно понимать, что если для информационных активов (на уровне информации, а не железа и ПО) не определены владельцы из числа бизнес-подразделений, то работы по наведению порядка с файлами тоже будут затруднительны. Но кстати, тут появление FileAuditor как раз может помочь найти потенциальных владельцев. Программа быстро и наглядно покажет, какие сотрудники и подразделения интенсивнее всего работают с информацией. С большой вероятностью они либо являются владельцем данных, либо знают больше всего об этом бизнес-процессе.
Надеемся, что обзор оказался полезен. Задавайте вопросы - передадим их автору.