Привет, Хабр! Меня зовут Александр Щербаков. Расскажу, как системы Privileged Access Management помогают контролировать действия привилегированных пользователей (таких как системные администраторы, управленцы, девопсы и проч.) с помощью сигнатурного анализа. Привилегированные пользователи — в силу своих обязанностей — обладают расширенным доступом к инфраструктуре. Любые их ошибки, небрежность или недобросовестные действия могут нанести организации большой вред.
The Devil You Know
Злоупотребление полномочиями, человеческий фактор, нарушение внутренних регламентов — все это причины, по которым компания рискует столкнуться с утечкой критичных данных и вмешательством в работу инфраструктуры. Например, в 2022 году сотрудник Yahoo, имея привилегированный доступ к данным компании, выкрал интеллектуальную собственность, чтобы передать конкурентам — более 500 тыс. файлов, в том числе с исходным кодом. Похожие инциденты в прошлом происходили и с российскими компаниями — в том числе с банками.
Виновниками таких инцидентов могут быть и злоумышленники, получившие доступ к привилегированным учеткам. Кража логинов и паролей становится одним из распространённых методов атак. Мониторить активность привилегированных пользователей помогают решения класса PAM. С их помощью можно отслеживать, кто, когда и откуда заходил на учетную запись, вести логи и проводить аудит. В компаниях с PAM ИБ-инциденты происходят на 48% реже. Сокращать число инцидентов помогает анализ действий привилегированных пользователей на основе сигнатур.
Сигнатурный анализ
Инфраструктура PAM анализирует процессы в привилегированных сессиях и представляет их в виде событий. Каждое событие описывается следующими свойствами:
Субъект действия — привилегированный пользователь, который произвел операцию;
Привилегированная учетная запись, от имени которой выполняется операция;
Ресурс — защищаемая система, на которой произошло событие;
Выполняемое либо выполненное действие;
Объект действия;
Привилегированная сессия, в ходе которой возникло событие;
Время события.
Как правило, более простые модели с меньшим количеством свойств (например, оперирующие исключительно командами, которые запускает пользователь) не позволяют нарисовать полную картину происходящего в рамках сессии. Следовательно, на них нельзя построить по-настоящему эффективный механизм контроля.
Сигнатура — это правило, по которому PAM-система идентифицирует события как опасные и автоматически реагирует на них. Входные условия формируют первые пять параметров параметра из списка выше, при этом допускается группировка соответствующих объектов (например, сигнатура может указывать на определенные группы пользователей, узлов или на некоторую совокупность файлов). Также сигнатура содержит тип реакции PAM на зафиксированное событие. Например:
Если пользователь из группы подрядчиков, работающих с Windows, пытается выполнить действия на ресурсе Linux, система может заблокировать его и разорвать сессию.
Если любой пользователь попытается выполнить на Linux-ресурсе команду rm -rf / или отредактировать файл /etc/shadow, система заблокирует операцию.
Если на ресурсе Windows запускается процесс mimikatz.exe, система уведомит ИБ-специалистов, разорвет сессию и заблокирует пользователя.
Может быть и так, что в инфраструктуре возникает некоторый набор или цепочка событий, которые сами по себе опасности не несут и не являются подозрительными, но в совокупности могут указывать на потенциальную угрозу. Чтобы обработать такую ситуацию, PAM-система способна выполнить корреляцию — сгенерировать обобщенное событие на основе исходных. Примерами таких «составных» угроз могут быть:
Открытие одним пользователем множества сессий к разным ресурсам и изменений системных файлов на них. Это — признаки возможного развития атаки island hopping: вероятный злоумышленник, «прыгая» от одного «островка»-узла к другому, увеличивает поверхность атаки, заражая все новые компоненты инфраструктуры.
Если пользователь за короткое время изменяет на узле большое количество системных конфигурационных файлов, это может указывать на попытку «подселения» какого-либо нежелательного ПО.
Если пользователь выполняет команды, позволяющие отлаживать работу процессов (например, в среде Windows применен procdump, на Linux — gcore и/или gdb). Вообще, единичные запуски программного обеспечения такого рода, вероятно, проблемой не являются, и не должны вызывать срабатывания механизмов реагирования (иначе получится большое количество ложноположительных срабатываний). Но если за пару часов наблюдается множество подобных операций, в том числе на разных узлах, то весьма вероятно, что пользователь не ищет причины неработоспособности ПО, а пытается извлечь идентификационные данные (credentials) из памяти ОС и процессов.
Если пользователь открывает несколько сессий к серверам с СУБД, а затем на сетевых интерфейсах возникает большой исходящий трафик, есть вероятность, что он «сливает» базы данных.
PAM-система обрабатывает подобные события с помощью правил корреляции. Они описывают, каким образом следует объединить события.
В частности, в правиле указывается, какое новое событие должно быть порождено, какая цепочка/либо совокупность исходных событий для этого должны произойти, за какой промежуток времени это должно случиться, какие признаки (например, субъект действия, узел, сессия) должны совпасть у исходных событий. Если все условия выполнены — значит, происходит нечто потенциально опасное, PAM-система порождает новое событие, на которое сработает сигнатура.
Компоненты PAM-системы
Архитектура таких инструментов зависит от конкретного вендора. Я расскажу, какие компоненты могут входить в PAM-систему на примере нашего решения.
Первый компонент — это прокси (Proxy), который управляет привилегированными сессиями. Он также проверяет данные пользователей на соответствие базе известных угроз и блокирует потенциально вредоносные действия. Второй компонент архитектуры PAM — это хранилище секретов (Vault). В нем лежат зашифрованные пароли, ключи и другие данные, необходимые для доступа к привилегированным учетным записям.
Третий компонент — регистратор сессий (Session Recorder). Он пишет видео привилегированных сессий, запоминает текстовые команды и регистрирует метаданные. Эта информация хранится или локально, или в сетевом хранилище.
Наконец, анализатор событий (Event Processor) оценивает действия пользователей на основе сигнатур и транслирует команды прокси для остановки сессии при обнаружении угрозы. Все зафиксированные инциденты также отражаются в журнале. Так, специалист по ИБ может быстро оценить ситуацию — есть ли опасность, нужно ли реагировать.
Если у вас есть вопросы, можете задавать их в комментариях — давайте обсудим.