Иногда бывает полезно взглянуть на ситуацию под другим углом. Для информационной безопасности это правило работает так: надо посмотреть на свою инфраструктуру с точки зрения потенциального злоумышленника. Как тебя будут ломать? И что будет, когда сломают? Такой подход к оценке уровня защищенности компании называется Offensive – наступательная безопасность. В этом посте мы поделимся нашим опытом подобных проектов и расскажем, как перейти от тестирования на проникновение к моделированию действий потенциального злоумышленника.

Offensive как часть Defensive

Начнем с того, что Offensive и Defensive — это единое целое, и обеспечение информационной безопасности организации должно идти по обоим этим направлениям.

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

Тут в игру вступает Offensive, то есть наступательная безопасность, которая является проактивной защитой. Такие проекты позволяют посмотреть на инфраструктуру глазами злоумышленника и понять, насколько она защищена от реальной угрозы.  

В итоге Offensive помогает Defensive-стороне обучаться, проверять и оценивать себя без ущерба для организации. Defensive же подталкивает Offensive к дальнейшему развитию и обучению.  Существует несколько разных типов работ по оценке и повышению уровня защищенности, и каждый из них решает свою задачу. В декабре прошлого года в рамках SOC-форума отдел пентеста «Ростелеком-Солар» уже рассказывал об этом. Для тех, кто пропустил выступление, но интересуется вопросом, – раскрываем тему ниже.

Тестирование на проникновение

Если организации необходимо провести оценку уровня защищенности (это может быть ежегодное запланированное мероприятие или требование регуляторов), то для этого прекрасно подходит тестирование на проникновение – пентест. Его задача – обнаружить критические уязвимости за отведенное время и проэксплуатировать их, чтобы доказать возможность получения доступа. Обычно ИБ-служба компании, которая заказывает пентест, в курсе происходящего и не противодействует «нападающим». Пентестерам же нужно обойти только автоматизированные средства защиты.

Например, в рамках внешнего тестирования на проникновение было обнаружено веб-приложение. В нем имелся недостаток: некорректная обработка входных данных, что позволяет провести атаку «Внедрение SQL-кода» (так называемая «SQL-инъекция»). Эксплуатация этой уязвимости дает возможность выполнять команды на уровне операционной системы. В итоге доступ во внутреннюю сеть не занял много времени. Кстати, если у пентестеров остается время, выделенное на проект, они могут поискать и другие уязвимости.

Red Teaming

Этот вариант подходит для компаний с высоким уровнем зрелости в части ИБ: у них реализуется система управления информационной безопасностью и даже есть Security Operations Center (SOC). А это значит, что, помимо оценки уровня защищенности, нужно периодически проводить обучение сотрудников этого SOC и проверять, насколько эффективно работают процессы обнаружения и реагирования на инцидент, а также устранения последствий. Эти задачи решает Red Teaming.

Обычно такие работы выполняются в условиях секретности – без предупреждения ИБ-службы. А независимой внешней команде специалистов известно только название компании, которую надо проверить. Все как в реальности. Более того, перед командой атакующих может быть поставлена задача имитации действий какой-нибудь известной APT-группы. Тогда имеет смысл использовать матрицу MITRE ATT&CK, в которой приведены пути атак и используемые TTP (тактики, техники и процедуры) большинства APT-групп.

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

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

Кстати, в прошлом году мы подробно писали о мифах и заблуждениях, которые существуют вокруг Red Teaming.

Purple Team

Злоумышленники становятся хитрее и опытнее, и популярные средства обнаружения уже не могут «ловить» абсолютно все подозрительные события. Одна и та же цепочка атак (killchain) может быть реализована с помощью различных техник и средств. А Red Teaming — это, хоть и полезно, но долго и дорого. К тому же такие работы не показывают все возможные векторы атак, доступные для использования киберпреступниками. Таким образом, появляется задача рассмотреть не одну единственную цепочку атаки, как в случае с Red Teaming, а все возможные техники и средства, применяемые внутри одной цепочки.

Такой вариант подходит для организаций с высоким уровнем зрелости, где есть собственная команда специалистов по тестированию на проникновение (Red Team). Помимо внутренних работ по поиску уязвимостей и оценки уровня защищенности она может объединяться с командой защиты (Blue Team) для повышения эффективности плейбуков реагирования на инциденты, настройки средств обнаружения атак, правил SIEM и средств защиты информации. А вместе это Purple Team – смешение красного и синего.

Основной принцип таких работ: взять известную TTP и провести цикл проверки, как показано на схеме:

Можно менять реализации или придумать новые TTP, чтобы максимально наполнить плейбуки и отследить все возможные подозрительные события в сети. Стоит отметить, что все вышеописанные типы работ по оценке защищенности не предусматривают демонстрацию реализации угрозы активам. Другими словами, не видно последствий (чаще финансовых), которые могут наступить в случае реальной атаки. И это подводит нас к иному варианту оценки уровня защищенности организации.

Новый взгляд на оценку уровня защищенности 

Для повышения киберзащиты компаниям стоит «предполагать нарушение». То есть задавать вопрос: а что произойдет, когда (а не если) инфраструктура будет скомпрометирована злоумышленником? Хороший способ проверить безопасность предприятия и свои СЗИ — это смоделировать действия злоумышленника, используя те же тактики, техники и процедуры, что и при реальной атаке.

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

Сейчас вы спросите: если есть Red Teaming, зачем нужно придумывать что-то еще?

Отвечаем: Red Teaming направлен на обучение сотрудников SOC, и в какой-то момент (обычно на последнем этапе выполнения проекта) команда атакующих начинает привлекать к себе внимание защитников. И несмотря на то, что подходы к выполнению работ могут быть одинаковыми, в случае проектов Red Teaming задача демонстрации угрозы не является самоцелью.

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

 Наш опыт показывает, что основные группы угроз это:

• хищение;

• шантаж;

• шпионаж;

• саботаж;

• плацдарм для дальнейших атак.

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

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

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

Пример из практики

Чтобы лучше понять, как работает метод моделирования атаки, разберем один из наших реальных проектов. Его цель заключалась в том, чтобы продемонстрировать реализацию угрозы незаметной выгрузки информации из базы данных. На схеме ниже приведен оптимальный маршрут проведения работ, но путей к решению задачи было много. Мы же старались избегать очень шумных и заметных техник, как, например, сброс пароля пользователя или выполнение атаки Kerberoasting:

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

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

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

На сервере имелась активная сессия администратора Exchange. Также был установлен антивирус Kaspersky, который не позволил сделать дамп процесса lsass и извлечь из него полезные данные (такие как пароль), но позволил нам собрать билеты Kerberos. Атака Pass-The-Ticket предоставила нам сессию от имени администратора Exchange.

Привилегии администратора Exchange позволили нам создать архив почтового ящика администратора СУБД для его изучения на наличие полезной информации. В результате был получен доступ к базе паролей, а из нее – пароль для подключения к целевой базе данных, с последующей выгрузкой информации.

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

Разница при различных типах работ

А как бы этот кейс был реализован при других типах работ по оценке уровня защищенности?

С внешним тестированием на проникновение все понятно: оно завершится на стадии получения доступа во внутреннюю сеть.

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

В Red Teaming смоделированный командой нападения «злоумышленник», если не будет обнаружен на любом из этапов, начнет привлекать внимание на этапе получения доступа к целевой базе данных.

Как можно увидеть, моделирование действий злоумышленника можно использовать и во внутреннем тестировании на проникновение, и в виде отдельных работ по симуляции действий нарушителя. Разница будет заключаться в производимом исполнителем «шуме».

Вывод

Исходя из вышесказанного, можно сделать вывод, что для каждой из существующих задач по оценке уровня защищенности и улучшению защиты найдется свое решение. Задачу поиска и эксплуатации уязвимостей решает тестирование на проникновение; обучения людей и проверки процессов реагирования – Red Teaming; повышения эффективности playbook и защиты – Purple Team; проверки реализации угроз активам – моделирование действий злоумышленника.

Автор: Дмитрий Неверов, руководитель группы анализа защищенности внутренней инфраструктуры  "Ростелеком-Солар"