Недавно я принял участие в эфире AM Live по теме DCAP вместе с гендиректором Makves Романом Подкопаевым и ведущим системным инженером Varonis Иваном Дудоровым. Ждал, что будет жесткий баттл, но встреча получилась джентельменской и даже немного просветительской.
На старте разговора у зрителей спросили, кто вообще в курсе, что DCAP за зверь такой и с чем его едят. Судя по опросу только 12% зрителей либо пилотировали, либо уже используют DCAP-систему, остальные этот класс решений пока не применяют. И это при том, что Gartner говорит, что скоро вообще ничего не будет, будет одно сплошное телевидение DCAP будет распространен буквально как антивирусы. Откуда такая уверенность?
Собрал некоторые соображения по итогам беседы.
Как-то жили без DCAP, откуда необходимость?
Необходимость в том, что компаниям приходится иметь дело с гигантскими объемами данных. Разобраться, что есть просто «файловая помойка», а что нет, становится все сложнее. Просто в силу того, как выросли объемы документов в любой среднестатистической компании.
Для начала обозначим, что DCAP – это:
1) подход, который ставит в центр защиты данные, а не процессы вокруг них;
2) решение, которое дает понимание: какие данные в организации есть, где они хранятся, кто имеет к ним доступ.
Можно решать эти задачи без закупки специального ПО? Можно. И раньше, действительно, как-то справлялись. По опыту общения с клиентами, примерно так:
- Разграничить доступ можно в операционке или NAS. Хоть и на примитивном уровне, но такой функционал существует в СХД. На рынке есть неплохие RMS-системы.
- E-discovery – еще один «классово близкий» продукт, позволит выявить факт проблемного хранения.
- Можно использовать возможности DLP. В большинстве нормальных систем сейчас тоже есть функционал e-discovery.
Сразу оговоримся, все эти решения имеют технические недостатки:
- не защищают от неправомерного доступа и ничего не знают о текущих правах доступа;
- не отслеживают жизненный цикл информации – откуда файл взялся, как редактировался, сколько его копий есть в организации и у кого хранятся;
- не работают проактивно;
- могут создавать неприемлемо большую нагрузку и требовать непомерно много СХД.
Но главный недостаток подобного комбинированного решения задачи в том, что «сооружено» оно на зоопарке средств и держится на честном слове айтишника/ибэшника – «кулибина», которого в вашей компании может и не быть.
(А если этот «кулибин» – вы и есть, вам, наверное, не очень интересно тратить время и нервы, переключаясь из консоли в консоль и выискивать подозрительные логи).
В итоге напрашивается вывод: нормально делай – нормально будет. То есть, держи файлы в порядке.
Правда, на четверых присутствовавших в студии AntiMalware нашелся только 1 из нас, кто вспомнил реальную компанию, где существует образцовый порядок файлов. Так себе статистика.
Так что же, DCAP – это просто удобный конструктор из других систем?
С одной стороны, DCAP, действительно, объединяет в себе функции смежных продуктов. В конце встречи мы договорились до того, что DCAP – это класс решений, который вбирает в себя функции немного UEBA, немного SIEM, немного альтернативной AD, немного DLP, немножко бэкапа.
Из-за такого широкого «ролевого диапазона» DCAP-систем заказчики часто применяют его в том числе и для нетипичных задач. Для меня, например, сюрпризом стало, что клиент использовал наш FileAuditor для экономии СХД. Он решил бэкапировать не все файловые хранилища, включая и «помойки», а только реально ценные для компании файлы.
А как вам использование DCAP в борьбе с вирусами-шифровальщиками? Система позволяет уменьшить общую площадь атакуемого периметра, чтобы в случае чего зловреды получили доступ только к тому участку инфраструктуры, куда имеет доступ пользователь.
Но в первую очередь DCAP – это единственное ПО, которое дает возможность контентного разграничения доступа, а не по контекстным признакам, таким как формат или принадлежность к какой-то папке. Это значит, что компании защищены от ситуаций, когда один файл просто будет переложен в другое хранилище. Такой фокус не пройдет: DCAP выявит, что этот документ по-прежнему является ПДн или коммерческой тайной и применит к нему все ограничения политик безопасности.
Хорошие сапоги, надо брать. Может, написать опенсорсную DCAP-систему?
Логичный вопрос, вытекающий из первого. Короткий ответ: да, это возможно. Просто ли это? Нет. Настолько непросто, что за создание для себя не берутся даже крупнейшие корпорации, у которых явно есть и технические, и финансовые ресурсы для реализации такого проекта.
«Вместо тысячи слов» приведу пример из нашей практики. Huawei предпочла интегрировать свои СХД OceanStor c нашим FileAuditor, а не писать систему самостоятельно.
Так что совет такой: не плодите долгострой, принесите в компанию DCAP на тест – и ваше руководство удивится, какие документы и в каком виде не хранят сотрудники.
Интересно наблюдать за реакцией заказчика. Первое, что его удивляет, это объем залежей данных. Второе – что среди них есть множество критичной информации, хранящейся как попало: персональных и платежных данных, внутренних инструкций, 100500 версий какого-нибудь маркетингового плана и т.д. и т.п.
Половина из них подпадает под ФЗ-152, GDPR, HIPAA и т.д. Так что «великий и ужасный» compliance не стоит сбрасывать со счетов.
И кстати о «комплаенс». А требует ли какой-нибудь закон применения DCAP?
Малоизвестный факт – да, требует! Как бы мы ни ругали законодательство за то, что использует витиеватые формулировки, по поводу DCAP в нем есть однозначный ответ. ФЗ-152 («О персональных данных») в статье 19 говорит (осторожно, казенный язык закона):
«оператор при обработке персональных данных обязан принимать необходимые правовые, организационные и технические меры или обеспечивать их принятие для защиты персональных данных от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения персональных данных, а также: «от иных неправомерных действий в отношении персональных данных, а так же установлением правил доступа к персональным данным, обрабатываемым в информационной системе персональных данных, а также обеспечением регистрации и учета всех действий, совершаемых с персональными данными в информационной системе персональных данных».
Мало кто об этом знает, но полезно быть в курсе.
Кроме того, DCAP может рассматриваться как техническая мера по защите КИИ, то есть удовлетворение требований ФЗ-187. Статья 11 этого закона указывает на необходимость «принятия организационных и технических мер для обеспечения безопасности значимых объектов критической информационной инфраструктуры».
Другое дело, коллеги справедливо отметили, что жесткость российских законов смягчается отсутствием штрафных санкций за несоблюдение. Это предмет другого разговора, но что-то мне подсказывает, что закон и его применение не всегда будет таким беззубым.
Частный случай – финансовые организации, которые подчиняются требованиям PCI DSS. Финансовые регуляторы к операторам персданных гораздо строже, чем российские законы, и накажут за небрежное хранение, не сомневайтесь.
Ок, DCAP нужен. Но какой?
Об этом мы вели долгий разговор, приведу здесь только несколько принципиальных моментов.
Должна ли DCAP быть проактивной (менять права доступа в случае инцидента, включать блокировку, бить сотрудника по рукам, если он тащит конфиденциальный файл на флешку или личный ПК)?
Здесь мы с коллегами-разработчиками разошлись во мнениях. Я лично убежден, что DCAP без проактивных операций (читайте, блокировками действий с файлами) – это вообще не DCAP. Это в лучшем случае eDiscovery с журналированием операций.
Поскольку цель DCAP – защищать, а не уведомлять, то без проактивности сегодня никуда не деться. Да, всегда есть риск случайных срабатываний, но это вопрос настройки системы. Если заказчику их сложно сделать, то это вопрос к разработчикам алгоритмов и интерфейса.
Заказчики интересуются проактивными действиями, хотя и с осторожностью, потому что осознают, что главный принцип применения блокировок – не навреди. Но бездействие – тот же вред. Поэтому работа преимущественно в режиме уведомлений, о чем говорят в Varonis, это, с моей точки зрения, не лучший выход.
Логично следует вопрос, а должна ли DCAP быть открыта не только для ИБ, но и для «простых смертных», чтобы они могли самостоятельно размечать документы и получать уведомления, если доступ к ним получает кто-то «левый»?
Здесь мы снова разошлись во мнениях с коллегами-вендорами. Я лично уверен, что никто не понимает ценность документа лучше его создателя. Поэтому полезно, чтобы он мог из своего интерфейса поставить метку одной из базовых категорий конфиденциальности документа (совершенно секретно, для служебного пользования и т.п.). Применение инструмента не потребует от пользователя знания всех тонкостей создания политик безопасности, но позволит, грубо говоря, поставить на документе красный, желтый или зеленый «флажок». Мы такой функционал добавили.
В Makves полагают, что незачем отвлекать сотрудников от их основной работы. Тем более, что они могут и ошибиться. И будет нехорошо, если сотрудник бездумно или по каким-то своим соображениям присвоит конфиденциальному документу статус «для общего пользования». Но мы постарались и этот момент учесть. DCAP перепроверит выбранную создателем или редактором документа категорию и, в случае необходимости, усилит ее. То есть приоритет остается за «компетентными» алгоритмами DCAP-системы, которые перепроверяют контент на соответствие политикам безопасности.
Насколько я знаю, Varonis также вовлекает пользователей в процесс ИБ, но реализует это несколько иначе, через так называемый «пользовательский портал».
Какие хранилища должна поддерживать DCAP
Короткий ответ – любые, которыми пользуются в компании. Практика показывает, что это в первую очередь локальные хранилища – российские компании все-таки чаще всего размещают файлы на собственных серверах. Да того от них требует закон, когда мы ведем речь про ПДн.
Но реалии таковы, что миграция в облака для многих компаний – дело решеное, особенно за рубежом. Если DCAP не умеют классифицировать данные в Office 365 или Dropbox, это неполноценное решение. Я сам уверен, что DCAP должен иметь интеграцию хотя бы с основными облачными сервисами.
Когда DCAP станут большими
DCAP для России еще молодой класс решений. Как он будет развиваться, какими задачами обрастет – все «обкатается» в практике применения. А пока даже терминология только формируется. Например, в кулуарах мы подискутировали о том, в чем разница между DCAP и DAG. Пришли к согласию, что термины эти можно использовать как синонимы.
Логичное развитие класса DCAP – это интеграция с практически неограниченным кругом систем безопасности – как на функциональном уровне, так и на уровне обмена данными.
Например, понятно, что системы DCAP и DLP должны понимать друг друга «без переводчика»: первая размечает документы, вторая считывает метки, принимая решение, пропускать документ по каналам пересылки или нет. Эти же метки по-хорошему должны быть поняты и любыми другими системами безопасности.
В свою очередь и DCAP должна уметь считывать метаданные из других систем. Например, из MS Office, где есть множество важных для понимания полей в виде автора, владельца, редактора. Чем больше источников информации, тем лучше.
Логичны и здравы «тандемы» DCAP с SIEM, для оптимизации процессов может пригодиться интеграция с системами электронного документооборота, бизнес-приложениями и так далее. Вариантов здесь огромное количество.
Я вижу, что DCAP со временем может стать центральным элементом системы защиты данных, потому что логично начинать именно с категоризации и разметки. Сделали уборку – дальше все остальное.
Более того, готов биться об заклад, что идеология data-centric станет общепризнанной и массовой. Функционал DCAP войдет хоть в каком-то облегченном виде в операционные системы, как это произошло с антивирусами и файерволами. Не вижу для этого препятствий: сфера применения DCAP ничем не ограничена, а функционал разграничения доступа и категоризации пригодится даже в бытовом использовании. Представьте, как удобно открыть «проводник» и увидеть, где лежат файлы той или иной категории.
P.S. Приглашаю посмотреть запись, там раскрыто еще много вопросов, в том числе частных. Например, как быть с запароленными архивами, как DCAP детектит ситуацию, когда сервисная учетка получает доступ к несвойственным для нее данным, можно ли контролировать облачные хранилища, как работают блокировки и многое другое.
P.P.S. так как пост – размышление, буду рад пообщаться в комментах, в т.ч. по альтернативным позициям.
