InfoWatch Data Access Tracker — самостоятельный продукт и новый модуль в едином интерфейсе Центра расследований. Сегодня разберем риски ИБ, связанные с событиями службы каталогов Microsoft Active Directory (AD), на примере 5 кейсов: от изменения состава привилегированных групп доступа и сброса пароля администраторами до попыток подбора паролей, наличия «фантомных учетных записей» и других событий AD.

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

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

Здесь мы воспользовались результатами опроса наших коллег из AM.Live, опроса слушателей мероприятия, посвященного защите не структурированных данных. В первую очередь мы сегодня будем говорить про те данные, которые находятся внутри периметра организации. Это может быть все что угодно. Это данные, которые находятся на файловых серверах, на порталах, в базах данных, в CRM, ERP и так далее. То есть данные, которые находятся внутри. Особенно важны те данные, которые представляют особую важность для компании, которые являются частью бизнес-процессов. Утечка которых или же их компрометация может привести к довольно печальным последствиям. Причем мы здесь говорим не просто про документы вордовые, pdf, но и также про файлы настроек. Файлы настроек почтовой системы, application серверов, web-серверов, баз данных, настроек конфигурации, почтовые архивы, backup и так далее. То есть вся ценная информация, которая нужна для жизнедеятельности компании и находится внутри нее. Но с небольшой оговоркой. Сейчас очень многие компании используют обычные ресурсы - это Яндекс 360, Clouds, Verge Cloud и так далее. Сейчас очень много на рынке предложений таких вот корпоративных систем на замену ушедшему офису Microsoft 365. Утечки и контроль ухода данных и контроль прав доступа данных в таких облачных ресурсах тоже важный процесс, мы в этом направлении также общаемся активно с вендорами на предмет обеспечения дополнительного слоя безопасности и контроля прав доступа. Таким образом, когда мы говорим про защиту не структурированных данных внутри организации, что первое пришло на ум респондентам и слушателям мероприятия по DCAP. Ну, во-первых, все сказали про шифрование данных и про антивирусную защиту. Это совершенно верно. Но обратите внимание, здесь мы четко видим два так называемых домена. Один домен — это связан с защитой непосредственно данных, путем их шифрования, чтобы нельзя было расшифровать, но любые данные можно взять и удалить. Шифрованные данные тоже здесь не исключение. Защита от вредоносных программ. Тут имеется в виду не просто антивирусная защита, но и система класса EDR, которая позволяет защитить данные от угроз, связанных с различными вирусами, троянами, шифровальщиками и так далее. Совершенно отдельно и с большими процентами у нас стоит аутентификации пользователей – 21%. Соответственно, все мы понимаем, что очень важно контролировать право доступа пользователей к определенной конфиденциальной информации. И на самом деле, это основная задача DCAP или DAC System. DAC – это немножко устаревшее название, Data Access Governance сейчас используется. Data Control Access and Protection. Более того, я скажу, это аббревиатура, введенная несколько лет назад Gartner, она тоже компанией Gartner, уже считается устаревшей. Потому что DCAP-система, она на самом деле включает в себя довольно много компонентов. И аутентификация пользователей, контроль прав доступа, является необходимым модулем этих систем. И сейчас, вот видите, рядом с DCAP находится DLP. они не просто так находятся рядом. Несмотря на то, что DLP традиционно использовалась для того, чтобы контролировать утечки, но сейчас мы понимаем, что и контроль доступа внутри организации, он также важен.

Сейчас в организациях используются сотни различных систем. Если мы говорим про крупную компанию, то это зачастую в ней очень много информационных систем. Это системы, которые используются для организации бизнес-процессов, это различные порталы, базы данных, «1С», все что угодно. Плюс информационные системы для поддержки и плюс системы для защиты. Я разговаривал с руководителем службы безопасности довольно крупной нашей компании, он сказал, что количество консолей, за которыми ежедневно приходится проводить время ИБ-сотрудника, где-то больше 20. И появление еще одного решения, такого, как DCAP, со своими консолями, со своими отчетами, еще больше будет нагружать сотрудника отдела безопасности.

В компании InfoWatch развита сильная экспертиза по DLP-системам. Traffic Monitor - система для анализа данных, в которой находятся классификаторы информации, движки, которые отвечают за анализ информации. Мы подумали, почему бы эти две системы не объединить.

Чем собственно DCAP-системы важны для организации, почему сейчас на них обращают внимание, какие задачи они решают, причем сразу скажу, они решают задачи, которые никакая другая система не решает, поэтому они уникальны в своем плане. Опять же, мы воспользовались результатами опросов наших коллег - AM.LIFE. Как видим, первое на что обращают внимание — это поиск данных — 36%. Важно, чтобы система могла понимать, где находятся важные конфиденциальные данные. То есть, DCAP-система должна понимать, где что находится. Хорошо, мы засветили какой-то ресурс, допустим файловый сервер или портал, на котором находятся важные документы, которые выгружаются и дальше используются для работы всей компании. Мы эти документы обнаружили, дальше что с ними делать? А дальше система должна понять, что это за данные, что это за документы. То есть эти данные нужно каким-то образом классифицировать или понять, насколько важная информация в них находится. И тут как раз прослеживается очевидная связь DLP-системы, она использует мощные движки контентного анализа для того, чтобы понять степень важности данных, которые необходимо контролировать. И на втором месте как раз классификация данных. Итак, поиск данных, классификация. И на третьем месте - управление правами доступа. Потому что мы видим, где находятся различные важные документы, но кто к ним имеет доступ? Обычно, согласно бизнес-процессам, в IDM-системах строится так называемая управляемая матрица доступа, задача которой свести реальные права доступа к тем, которые должны быть у сотрудника согласно бизнес-процессам. Но важное отличие IDM от DCAP, в том что IDM смотрит сверху на права. Она не проваливается внутрь, она не смотрит на права доступа к конкретным объектам. А это довольно важно. И вот как раз в этом принципиальном отличие от DCAP, то что DCAP смотрит, что за объект, что за документ ему нужно защищать. И какие у него в настоящий момент права доступа, как они меняются со временем, и насколько эти изменения легитимны.

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

Причем контентный анализ должен быть привязан к бизнес-процессам компании. То есть, когда мы внедряем DLP-систему, проходят месяцы, перед тем, как мы сможем настроить объекты защиты на конкретные организации, на их бизнес-процессы. Конечно, существуют системы автоматического создания объектов защиты, как автоDLP, система категоризации данных, которая была представлена в последних версиях Traffic Monitor. Это все значительно ускоряет процесс создания объектов защиты, то есть тех данных, которые мы должны защищать. В крупных организациях, особенно если это финансовый сектор, порядка 80% документов, очень хорошо категоризируются по определенным шаблонам и согласно этим шаблонам необходимо проводить их в защиту. И здесь видно очевидное преимущество совместного использования DCAP с контентным анализом существующей DLP-системы, потому что результат настройки DLP-системы можно использовать в том же DCAP. И таким образом у нас получается закрытая, законченная экосистема. Один продукт этой экосистемы, как модуль, в данном случае это, возможно, Data Discovery, анализирует документы, которые находятся внутри компании, анализирует права доступа, передает эту информацию в DCAP, то есть DCAP становится такой некоей «думалкой», объединяющей в себе функциональность нескольких решений.

Если мы говорим про анализ доступа, возьмем в качестве примера файловый сервер, на котором настроено разграничение доступа. Каким образом можно право доступа поменять? Ну, несколькими способами, скажу про два. Во-первых, можно напрямую доступ дать пользователю на файлы, которые находятся на ДФС-шаре или же поменять право доступа в группах в активной директории. Причем зачастую сам факт изменения состава групп DLP-система не отсечет. Для этого нужны другие средства, которые входят в отдельный модуль, который в свою очередь входит в активную директорию или в любую другую службу каталогов. Посмотрит на изменение прав доступа, посмотрит на изменение состава групп, сможет это сопоставить с теми права доступа, которые были получены от модуля Discovery перед этим. Таким образом безопасник поймет, что права доступа поменялись. Иногда этот режим можно организовать искусственно в продуктах. Он называется режим песочницы, когда пользователь вносится в определенные группы и тут же безопасник видит, как это приведет к изменению его прав доступа по информационным системам внутри его организации.

Таким образом, DCAP должна проводить аудит данных. Где они находятся? Должен проводиться аудит служб каталогов, потому что службы каталогов несут в себе полную информацию о пользователях, которые мы в дальнейшем используем для назначения прав доступа аксесс-листов в любую систему. DCAP должна проводить классификацию данных, чтобы понять, а что за данные появились на открытой шаре. И почему? ДСП находится в папке паблик или находилась буквально в течение 5 минут, а потом кто-то убрал, но за это время человек 100 уже раскачали. DCAP должна регулярно проводить мониторинг, проводить аудит, контролировать изменения, которые происходят как в правах доступа, как в распределении документов внутри компании, то есть должна постоянно перестраиваться карта или инфополе. Если мы говорим про наше новое решение, Data Access Tracker – это что-то связанное с DCAP. Поэтому мы название решили не менять, для того чтобы никого не путать.

Соответственно, когда мы говорили про контроль прав доступа, мы упомянули про изменение в службе каталогов. Ну, так как большинство из вас наверняка уже знакомы с линейкой продуктов InfoWatch, и вы знаете, что вот этого модуля как раз у нас и не хватало. Что происходит в службе каталогов и как это приводит к изменению прав доступа по документам, мы, к сожалению, понять не могли. И как раз этот модуль DAT, он закрывает потребность в контроле и аудите служб каталогов.

Сейчас это Microsoft OD, и в настоящий момент мы работаем напрямую с разработчиками ALD, и буквально в ближайшие месяцы будет добавлен ALD Pro. На самом деле мы, честно, работаем с разработкой «Астрой», наш отдел тестирования даже умудряется в ALD Pro находить различные баги. И совместными усилиями всё это отправляется, тут же проверяется. Так что я думаю, в ближайшие пару месяцев поддержка ALD Pro у нас появится.

Итак, DAT. Сейчас мы этим DAT начинаем закрывать те информационные домены, которых у нас нет для того, чтобы закрыть полностью потребность организации в DCAP сценарии. Зачастую DCAP начинает страдать от некачественного анализа контента. Так как Traffic Monitor, который вписывается в бизнес-процессы компании, плюс он настраивается под компания и те объекты защиты, те политики, которые реализованы в Traffic Monitor, их также можно использовать в DCAP-системе и можно будет использовать в DAT. Это очень важно. Если DCAP внутри использует какую-то Open Source систему для контентного анализа, но она должна быть удобно настраиваемая. И многие компании сейчас представляют преднастроенные системы категоризации по так называемым комплайнсам или законам, но если вы захотите что-то добавить свое, это возможно потребует значительных усилий.

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

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

Как мы проводили пилотное тестирование. Мы пилотирование начали в марте этого года. В пилотах участвовало порядка двадцати крупных компаний. И мы заметили такую тенденцию. Что, во-первых, задача аудита и контроля службы каталогов действительно важна. Важна почему? Потому что за годы существования компании служба каталогов, то есть служба основная, где находится информация о всех пользователях, о организационных юнитах, группах, групповых политиках и так далее, она приходит в состояние некого хаоса. И DAT, как система фактически анализа логов, контроллеров домена, позволяет довольно быстро это все разобрать. Уже бывали случаи, когда буквально на следующие сутки после внедрения DAT в довольно крупные, многодоменные компании, уже можно было понять, что у нас не так. Вот. И вторая задача, которую DAT в итоге решал, после того, как мы навели более-менее порядок в службe каталогов, мы теперь следим уже точечно, что, собственно, там меняется со временем. Особенно это помогало компаниям с филиальной разветвлённой системой, с локальными администраторами и безопасник, который теперь видел в центре расследования все продукты, относящиеся к анализу прав доступа и к анализу данных, он мог легко и быстро понять, что происходит и к чему это может привести, что конечно очень важно с точки зрения расследования.

Давайте рассмотрим несколько примеров, вот таких вот очень актуальных сейчас в наше время, которые могут закрыть изменение состава привилегированной группы активной директории. Есть два класса групп. Первая – это преднастроенные админы, такие как Domain, Admin Schema, Admin Enterprise, Admin Exchange, Admin Etc. Это те группы пользователей и реальных администраторов, которые отвечают за функционирование инфраструктуры. Естественные изменения в таких группах, включение даже временное людей, которые не являются уполномоченными сотрудниками, может привести к довольно печальным последствиям. Как бы это ни звучало, но все-таки безопасники с IT должны дружить, но и друг другу немного помогать с точки зрения обеспечения безопасности.

Вторая группа привилегированных пользователей – это, естественно, люди, которые отвечают за бизнес компании. Это топ-менеджеры, финансовые сотрудники, это ейчары, то есть люди, от которых зависит бизнес. И люди, которые имеют доступ к информации, публичность которой может представлять угрозу для репутации компании. Соответственно, вот эти две группы пользователей, во-первых, их нужно выделить, во-вторых, изменения их нужно контролировать. И на данном слайде мы как раз показываем, как система позволяет проконтролировать изменения групп, допустим, группы, связанные с финансами, с бухгалтерией и так далее. То есть временное включение сотрудников такой группы, представление им доступа и прав от лица этой группы может привести к доступу к закрытой финансовой информации, к денежным потокам, обязательствам и так далее. Если человек попробует это использовать в своих корыстных целях, для компании ничем хорошим может это  не закончиться.

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

Неудачные попытки входа и попытки входа в нерабочее время тоже представляют довольно большой интерес, более того, я скажу, что есть система так называемого класса UBA – User Behavior Analysis. И вот такие вот случаи, они там подсвечены с максимальным приоритетом, потому что это нестандартное поведение сотрудника, это отклонение, а любое отклонение – это аномалия. Если вы видите, что сотрудник обычно работает условно с 9 до 18, И вдруг он начал заходить в систему в субботу вечером, еще и не с первого раза. Это повод для безопасника начать беспокоиться и разобраться, что, собственно, такому сотруднику понадобилось в не рабочее время, и повод выяснить, откуда происходят заходы по имени устройства, по его айпишнику. В системах так называемого класса CAS-B есть карты обычной GEO IP, которые показывают, откуда сотрудники в кавычках входили, потому что обычно это попытки взлома. Да, такие многократные неудачные попытки входа должны блокироваться, неактивные учетные записи, особенно админские.

То есть сотрудники IT-отделов, особенно в крупных компаниях, часто меняются, причем не только IT, но и support, и devops, и так далее. И сотрудники, находящиеся под увольнением, но всё еще обладающими высокими правами, они могут создавать так называемые фантомные учетные записи. Мы называем их фантомными, потому что они вроде есть, но не активны, они админские, из-под них можно натворить много бед.

Сервисные учётные записи обычно используются для запуска критически важных сервисов. Application Server – это база данных. Там используются так называемые сервисные учётки, у которых выключен Interactive Logon. Что это значит? Под этими учётками нельзя войти в ноутбук. Если совсем просто. Я думаю вы прекрасно осведомлены об опасности, которые таят такие сервисные учётные записи, если от них будет украден, допустим, пароль. Во-первых, такие учётки нужны для функционирования корпоративных критических систем, поэтому нужно очень серьёзно соблюдать гигиену паролей, не записывать их на бумажке, потому что всё это каким-то кейлогерами легко снимается. То есть учетные записи, которые когда-то использовались, но сейчас они нигде не используются, но они активны, они обычно с очень легкими или вообще с пустыми паролями, на сервисную учетку, иногда не распространяются политики ГПО компании. Их можно использовать для запуска левых сервисов, причем сервисов на серверах. То есть сервисные учетные записи нужно обязательно контролировать, а у нас в системе это уже возможно. Конечно, продукт сейчас может уже работать с большим количеством проблем, которые могут привести к существенным потерям информации внутри компании. Тут система построена как система отчетов, где безопасник фокусируется на какой-то одной определенной проблеме. То есть, с одной стороны, мы фокусируемся на том, чтобы показать события, которые происходят в службе каталогов и фокусируем внимание на тех событиях, которые важны с точки зрения безопасности и те, которые важны с точки зрения прав доступа, потому что DAT – это все-таки ядро DCAP-системы.