Поведенческий анализ все еще остается довольно новым с практической точки зрения инструментом. В своей практике мы иногда сталкиваемся с тем, что часть директоров по информационной безопасности (ИБ-директоров), слабо понимает суть и механизмы работы этой полезной технологии.
Лирическое вступление
В информационную безопасность эти решения перекочевали из электронной коммерции. Как только в сети «заколосилась» онлайн-торговля, предприниматели получили возможность собирать данные о своих покупателях и вытаскивать из них ценные сведения, чтобы продавать больше и лучше конвертировать посетителей интернет-магазина в покупателей. Какие товары смотрел потенциальный клиент? Как перемещался по сайту? Как фильтровал покупки? Все это важные вопросы, которые помогают сделать интернет-магазин удобнее, а его выручку – больше.
Со временем стало очевидно, что подобные технологии могут выявить то, что невозможно найти никакими другими способами – а именно аномальное поведение человека в сети. Для онлайн-торговли такие случаи не имеют значения: онлайн-ритейлу гораздо важнее понять типичное поведение, чтобы иметь возможность влиять сразу на решения множества пользователей. Зато для информационной безопасности это – настоящий клад.
Допустим, бухгалтер входит в систему и вместо того, чтобы открыть 1С, идет изучать папки коммерческого департамента (по какой причине они находятся в широком доступе – это отдельная проблема). Как об этом узнать? Следить за действиями каждого пользователя силами сотрудников ИБ — никаких ресурсов не хватит. А что это значит? Может быть, он ищет информацию по какой-то конкретной сделке; или знакомый менеджер по продажам попросил распечатать документ; или данные его учетной записи скомпрометированы и через его «учетку» к сети компании подключился кто-то другой, с вовсе не добрыми намерениями. Выяснить это помогут системы UBA (user behavior analytics, анализ поведения пользователей).
Добавляем еще одну букву и переходим к практике
Но в реальности все сложнее. Бизнесу важно знать не только что пользователь делал, но видеть более широкий контекст: с каких устройств заходил, откуда подключался к сети, и так далее. Все эти нюансы помогают еще точнее отфильтровать нормальные действия сотрудника от опасной активности – например, скомпрометированной учетной записи, которую использует кто-либо другой. Если в компании запрещено использовать другие устройства, то система подаст сигнал о том, что пользователь, хоть его машина продолжает работать, залогинился на чужом компьютере. Но чаще всего это именно скомпрометированная учетная запись, которая дальше пытается «путешествовать» по остальным устройствам, либо аутентифицироваться на них, чтобы получать доступ к данным, включая тикеты аутентификации других пользователей.
Так в англоязычной аббревиатуре появляется еще и буква E – entity, сущность. Теперь мы имеем дело с полноценным UEBA.
Теперь давайте разберемся с тем, чем отличаются одни UEBA-решения от других. Существуют различные подходы к использованию модели угроз.
Первый – обычная статика. Мы говорим о том, что система должна реагировать на определенные события – допустим, аутентификацию администратора на клиентской машине. Причем для этого мы можем либо заранее задать этот список администраторов (тогда модель полностью статическая), либо администраторов выделяет сама система без участия пользователя (полустатическая модель).
Модели угроз могут быть и автоматическими. Тогда решение UEBA определяет, каким образом обычно ведет себя пользователь, как ведут себя пользователи со схожими обязанностями, учитывает множество других факторов и создает модель. Исходя из созданного системой профиля мы понимаем, что он не должен был бы пойти на определенный ресурс с тем, чтобы его использовать или копировать какие-то данные.
Далее возникает вопрос: что же делать с пользователем, если система обнаружила аномальное поведение?
По широкой практике работы различных организаций хотел бы сразу предостеречь: ни в коем случае не стоит в произвольном случае автоматически отключать пользователю доступ к системам компании, блокировать доступ к ресурсу или его учетную запись, если он ведет себя нестандартно. Иначе есть серьезный риск блокировать важную легитимную рабочую активность. Например, сотрудник в ночи доделывает важнейший отчет, для которого потребовались данные из смежных департаментов или регионов. Если система «отключит» его, важная задача будет провалена: разумеется, его руководитель в это время спит, и сотрудники SOC по звонку от самого сотрудника, без реакции от владельца данных, восстановить доступ не смогут.
Автоматическое отключение целесообразно только в том случае, если речь о потенциально огромном ущербе для компании (работа вируса-шифровальщика), критических процессах (например, на промышленных предприятиях), жизни и здоровье людей. В остальных случаях к решению о блокировке доступа необходимо привлекать непосредственного руководителя того сотрудника, чья учетная запись может быть скомпрометирована. На практике можно отсылать его начальнику оповещение о подобной деятельности, и предлагать самостоятельно или вместе с аналитиком ИБ принять решение о том, легитимна она или нет.
Борьба с ложными срабатываниями
Хорошо работает система UEBA или плохо, можно понять по двум критериям:
- Пропускает ли она нелегитимные активности,
- Сколько ложных срабатываний она делает.
Ложные срабатывания – настоящая головная боль для ИБ-директора. Каждый аналитик, работающий в SOC или департаменте кибербезопасности, может качественно проверить лишь определенное количество оповещений. Если их значительно больше, чем ресурсов, то они выстраиваются в очередь. Очередь оповещений растет, а затем «обнуляется» – просто потому, что другого выхода нет.
От ложных срабатываний пока не удается уйти совсем, но их количество можно минимизировать. В первую очередь, для этого в части решений UEBA используются алгоритмы самообучения: система узнает от аналитика, что считать корректным срабатыванием, а что ложным, и таким образом повышает свою точность.
Другой способ – добавлять исключения вручную. Самый простой пример – массовое удаление записей DNS принтеров, что может происходить довольно часто и создавать регулярные ложные срабатывания. У аналитика в данном случае есть вариант: добавить в правило исключение, говорящее о том, что такое может происходить легитимно.
С самообучением систем есть одна проблема: одни и те же действия могут несколько раз быть распознаны как вполне легитимные, но в какой-то момент подобная активность окажется действием злоумышленника. Например, пользователь 10 раз выполняет поиск файлов в одной и той же папке, система «учится» считать это действие нормальным, а на 11-ый раз пользователь начинает массово копировать оттуда файлы (особенность работы в Windows состоит в том, что зачастую поиск и копирование файлов неотличимы). «Наученная» система считает, что всё в порядке, а зря.
Поэтому правильный, на наш взгляд, способ борьбы с ложными срабатываниями – сбалансированное сочетание ручной проверки с предварительным машинным обучением, и самообучением в процессе работы. Есть и другие инструменты, которые могут помочь сократить количество ложных срабатываний. Например, в случае с Windows, применение в компании специальных систем поиска файлов (чтобы аналитик и система могли отличить копирование данных от поиска).
Цели применения
В завершение, хочется сказать, что удаленная работа, конечно, усилила потребность компаний в решениях поведенческого анализа. Логика с точки зрения информационной безопасности проста: периметр компании размывается - уберечь учетные записи сотрудников от компрометации все сложнее, и хотелось бы видеть не только признаки взлома элементов службы каталогов, например, но и к чему этот взлом привёл – достигли ли атакующие цели или их действия были пресечены до этого. Вопрос же активности инсайдеров, в «свободное» от их основных обязанностей время, также покрывается при автоматическом анализе девиаций их поведения на ресурсах компании. С точки зрения корпоративных финансов в этом тоже есть смысл, ведь предотвратить результативное посягательство на активы компании всегда дешевле, чем «разгребать» последствия.
