Учётные записи бухгалтеров: почему они в фокусе злоумышленников и как выявить аномалии

Бухгалтерия — один из тех отделов компании, где в одной точке сходится большое количество чувствительной информации. В распоряжении бухгалтеров и финансовых специалистов находятся данные о платежах и проводках, контрагентах и заказчиках, заработных платах, персонале, финансовой отчетности.

Эти данные делают учетные записи сотрудников финансовых подразделений привлекательной целью для злоумышленников. Причем компрометация такой учетной записи создает риски не только для конфиденциальности данных, но и для их целостности и доступности.

При этом взлом не обязательно выглядит как что-то явно подозрительное. Злоумышленник может получить легитимные учетные данные сотрудника, использовать разрешенные приложения и штатные способы доступа. Для части средств защиты такая активность может выглядеть легитимной: пользователь успешно авторизовался и работает разрешенными инструментами.

Чтобы понять, где искать отклонения, сначала определим, какими системами пользуются сотрудники финансовых подразделений.

Состав приложений, которыми пользуется бухгалтер, можно рассматривать как один из первичных индикаторов. Типовой набор таких систем включает:

• 1С, в том числе ERP-конфигурации;
• системы «Клиент-Банк»;
• системы налоговой отчетности и взаимодействия с государственными органами;
• системы электронной подписи;
• файловые хранилища;
• офисные приложения — Excel, Word и другие;
• VPN-клиенты для подключения к банкам и целевым информационным системам.

Если набор программ неожиданно меняется, это повод для проверки.

Однако значительно сложнее ситуация, когда состав остается прежним. Злоумышленник запускает ту же 1С, работает с почтой, использует Excel, подключается удаленно привычным способом. Явного вредоносного ПО и очевидно нелегитимных действий может не быть.

В таком сценарии традиционных индикаторов компрометации и средств защиты может оказаться недостаточно. SIEM способен собрать и коррелировать события из разных источников, DLP — контролировать передачу защищаемой информации по доступным ему каналам, но при использовании валидных учетных данных сама по себе успешная авторизация или запуск разрешенного приложения еще не говорит об атаке. И вот в этой ситуации особое значение приобретает анализ поведения.

Для таких сценариев применяют поведенческий анализ — UBA, User Behavior Analytics, а при анализе не только пользователей, но и других сущностей инфраструктуры — UEBA, User and Entity Behavior Analytics.

Логика UEBA заключается не только в фиксации отдельного события, но и в оценке того, насколько текущее поведение пользователя, хоста или другой сущности соответствует сложившемуся профилю. Объектом контроля может быть не только учетная запись. Анализировать можно хост, с которого работает пользователь, обращения к базам данных, файлам и другим объектам информационных систем.

Однако прежде, чем приступать к анализу, необходимо определить, что именно считать нормой. Для бухгалтерии это особенно важно из-за цикличности работы. Месячная, квартальная, полугодовая и годовая отчетность создают естественные всплески активности. В конце отчетного периода бухгалтер может работать дольше, выполнять больше операций и обращаться к большему объему информации, чем обычно. И если система ориентируется только на «бейзлайн», сформированный на коротком первоначальном интервале — например, нескольких неделях, — такой легитимный пик легко принять за аномалию. Результатом станет поток ложноположительных срабатываний, или false positive.

Поэтому для оценки поведения важна достаточно длинная ретроспектива, учитывающая сезонность бизнес-процессов. Кроме того, модель нормального поведения не должна оставаться неизменной: она должна адаптироваться по мере изменения активности пользователя.

Есть еще один важный уровень — сравнение поведения сотрудника с поведением группы пользователей со схожими ролями и функциями. Пять бухгалтеров могут отвечать за разные участки, но использовать похожие приложения, типы доступа и категории файлов. Отклонение дает дополнительный контекст для оценки события.

Наконец, действия учетной записи стоит сопоставлять с поведением хоста и другой доступной телеметрией. Например, злоумышленник использует привычный RDP-доступ. Сам протокол не изменился. Но через соединение внезапно начинает передаваться больше файлов, растет объем копирования данных или меняется продолжительность сессий. Параллельно учетная запись обращается к необычной информации.

По отдельности эти события могут не выглядеть критичными. Вместе они формируют совсем другую картину.

1. Меняются параметры работы учетной записи с хостами

Первое, на что стоит смотреть, — связь между учетной записью, устройством и временем активности.

Если за бухгалтером закреплен определенный хост, а его учетная запись внезапно начинает использоваться с нескольких устройств, это требует проверки. Обратный сценарий — с одного пользовательского компьютера последовательно или одновременно работают несколько учетных записей.

Для терминальной инфраструктуры сама по себе множественность пользователей на сервере нормальна. Тогда больший вес получают другие параметры:

• время авторизации и выхода;
• длительность сессии;
• нетипичное время работы конкретной учетной записи;
• используемые протоколы и способы подключения;
• изменение объема передаваемой в рамках сессии информации.

Ни один из этих параметров в отдельности не доказывает компрометацию. Но изменение сразу нескольких характеристик относительно паттерна повышает значимость события.

2. Меняются объекты доступа

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

Примеры:

• бухгалтер, не работающий с зарплатами, начинает запрашивать зарплатные данные;
• сотрудник обращается к папкам главного бухгалтера, хотя раньше их не открывал;
• пользователь начинает работать с документами или таблицами, не относящимися к его обычному участку.

Для оценки таких событий особенно полезно сравнение с похожей группой сотрудников. Если подобный доступ характерен для всей группы специалистов с аналогичной ролью, его значимость ниже. Если сотрудник резко выбивается из поведения группы — выше.

3. Меняются типы выполняемых операций

Следующая группа аномалий относится уже к действиям внутри систем. Количество операций может оставаться примерно тем же, но их характер меняется.

Например, бухгалтер обычно работает с проводками, счетами, счетами-фактурами и документами своего участка. Затем он начинает активно запрашивать годовую или полугодовую финансовую отчетность, сведения о движении денежных средств, взаимодействии с заказчиками, поставщиками или контрагентами и не просто просматривать эту информацию, а копировать её в большом количестве или нетипичным образом конвертировать.

4. Меняется способ доступа

Даже при работе с теми же данными может измениться путь, по которому пользователь к ним обращается.

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

5. Резко меняются объемы данных

Для легитимного пользователя объем запрашиваемой и передаваемой информации обычно относительно стабилен, и изменения всегда постепенны. Например, компания растет, и соответственно увеличивается клиентская база, становится больше операций и документов. Но в нормальном сценарии это, как правило, относительно плавная динамика. Резкий всплеск объема запрашиваемых, копируемых или выгружаемых данных может быть признаком подготовки информации к эксфильтрации.

Интересно и обратное отклонение — резкое падение обычной активности. Если пользователь перестал выполнять свой стандартный набор операций и практически полностью переключился на чтение и сбор информации, это также стоит проверить.

Ручной поиск аномалий – теоретически простая задача, однако на практике она быстро становится трудоемкой.

Самый простой пример — ошибки авторизации. Если количество неуспешных попыток резко выросло, аналитик получает понятный повод для проверки. Но ведь причина не обязательно может связана с атакой. Пользователь мог забыть пароль. Учетные данные могли недавно изменить. Наконец, другой сотрудник мог попытаться войти под учетной записью коллеги, потому что его собственная заблокирована, а бизнес-процесс нельзя остановить.

С точки зрения политики ИБ последний сценарий тоже является проблемой: учетные данные фактически переданы другому человеку. Но реакция на событие должна учитывать бизнес-контекст. Если просто автоматически заблокировать все связанные учетные записи, можно остановить работу бухгалтерии.

С более сложными аномалиями ручной анализ становится еще тяжелее. Допустим, организация собирает аудит 1С. Чтобы определить отклонение, недостаточно просто открыть журнал событий. Нужно понимать, какие события генерирует конкретная операция и как интерпретировать их последовательность.

Дополнительную сложность создают автоматизированные задания и скрипты: пользователь нажимает одну кнопку для формирования выгрузки, а за ней запускается цепочка действий: обращение к нескольким базам, объединение информации, очистка, предварительная обработка и формирование итогового отчета.

Для пользователя это одна операция. В логах — множество событий. И если в одном из звеньев произошла ошибка, сотрудник может увидеть одно сообщение о невозможности выполнить действие, а аналитик — целую последовательность ошибок. Чтобы понять, является ли она признаком атаки, ошибкой приложения или обычным сбоем автоматизации, события придется восстановить в контексте.

Формально ничто не мешает собирать такую статистику вручную, агрегировать ее в Excel и рассчитывать условные нормы: количество операций на пользователя, число ошибок авторизации, объемы выгрузок, время сессий. Но тогда это уже становится отдельным процессом, который требует ресурсов.

Кроме того, аналитику необходимо заранее понимать, что именно искать. Сравнить количество логинов относительно просто. Значительно сложнее вручную определить, что конкретный пользователь стал обращаться к нетипичным данным, причем только в определенные периоды и необычным способом.

Добавим сюда необходимость сравнивать пользователя с его собственной историей, группой пользователей и одновременно анализировать телеметрию хоста — и объем ручной корреляции быстро растет. Поэтому вопрос не столько в том, можно ли найти аномалию без специализированного инструмента, сколько в том, насколько масштабируемым будет такой процесс.

UEBA полезен тем, что позволяет искать признаки атаки еще до финальной стадии. Если DLP может обнаружить попытку передачи защищаемой информации по контролируемому каналу, то поведенческий анализ позволяет увидеть то, что происходило раньше: пользователь начал обращаться к новым данным, изменил тип операций или резко увеличил объем выгрузок.

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

В перспективе поведенческий анализ может смещаться от детектирования отдельных аномалий к оценке состояния и риска конкретных объектов инфраструктуры. Но базовый принцип останется тем же: недостаточно увидеть одно необычное событие. Важно понимать, кто, откуда, когда, каким способом, с какими данными и в каком объеме работает, и насколько вся эта комбинация отличается от нормального поведения пользователя и группы пользователей с похожими ролями. Именно этот контекст помогает заметить атаку в тот момент, когда злоумышленник для инфраструктуры все еще выглядит легитимным пользователем.