Как мы моделируем угрозы. Часть 3: техники и тактики

Как мы моделируем угрозы. Часть 3: техники и тактики

Зачем вообще понадобилось разрабатывать новую методику моделирования угроз?

По смыслу нормативных документов ФСТЭК модель угроз должна показать, достаточно ли базовых мер защиты для успешного противодействия нарушителю. И если их недостаточно, модель угроз должны показать, чем именно эти меры защиты нужно дополнить или усилить. Но что мы видим в тех "моделях угроз", которые разрабатываются сейчас?

Аннотация угрозы: осуществление несанкционированного ознакомления, модификации и блокировки целевой информации, хранимой и обрабатываемой в ИС.

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

Способы реализации угрозы:

1) осуществление несанкционированного доступа, используя штатные средства ИС;

2) использование бесконтрольно оставленных технических средств;

3) хищение нарушителями и утрата уполномоченными лицами технических средств ИС (в том числе носителей информации);

4) несанкционированный просмотр средств отображения информации и распечатанных документов.

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

Что мы узнали из этого текста? Что произойдет, если нарушитель "несанкционированно ознакомится с информацией"? Неизвестно. Как именно человек, не имеющий легитимного доступа к этой информации, может этот доступ получить? Неизвестно, Что мы можем сделать, чтобы ему помешать? Неизвестно. То есть в этом тексте нет ничего, что позволило бы понять, защищены мы от этой угрозы, или нет.

Чтобы решить эту проблему, ФСТЭК обязала операторов информационных систем руководствоваться формулировками угроз из БДУ:

Угроза заключается в возможности повышения нарушителем своих привилегий в дискредитированной системе (получения привилегии дискредитированных программ) путём использования ошибок в программах и выполнения произвольного кода с их привилегиями.

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

Реализация данной угрозы возможна при условиях:

- обладания дискредитируемой программой повышенными привилегиями в системе;

- осуществления дискредитируемой программой приёма входных данных от других программ или от пользователя;

- нарушитель имеет возможность осуществлять передачу данных к дискредитируемой программе

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

Как мы это делаем

Комментаторы совершенно справедливо отмечают, что в проекте новой методики моделирования угроз многое заимствованно из MITRE Att&CK. Если нас интересует практическая защита от квалифицированного хакера, то Att&CK - пока единственная методика, позволяющая достаточно точно указывать на слабые места в обеспечении безопасности информационной системы и точечно выбирать меры защиты против определенных действий нарушителя.

Проблема БДУ заключается в том, что все содержащиеся в ней угрозы - это единичные действия. В реальности так не бывает: чтобы сделать с информационной системой что-то плохое, требуется сперва провести большую подготовительную раюоту: получить доступ в нужный сегмент инфраструктуры (или хоть в какой-нибудь, если доступа к инфраструктуре нет совсем), загрузить инструментарий, собрать информацию о системе, найти уязвимые узлы, получить контроль над ними и т.п. поэтому любая более или менее сложная атака превращается в тактичесакую игру, где в каждый ход нарушитель решает определенную тактичекую задачу и намечает следующий ход исходя из того, что у него получилось в результате текущего хода. Парни из MITRE выделили двенадцать тактических задач (тактик), которые приходится решать нарушеителю и из которых складывается сценарий его "игры"

  1. Initial Access: "первичное проникновение", возможность хоть как-то дотянуться до элементов атакуемой инфраструктуры. Способы ("техники" в терминах Att&CK) могут быть разными, от использования общедоступного уязвимого внешнего интерфейса до социальной инженерии и подключения к инфраструктуре собственных устройств.
  2. Execution: возможность хоть каким-нибудь способом заставить атакуемый элемент инфраструктуры выполнить хоть какие-то из нужных нарушителю действий. Техники, опять же, могут быть очень разными, от использования готового интерфейса командной строки до инфицировани узла вредоносным ПО.
  3. Persistence: возможность сохранить присутствие в атакованной инфраструктуре даже после того, как будет перезагружен атакованный узел, будут найдены и уничтожены некоторые внедренные инструменты и т.п. Техники... - ну, вы поняли.
  4. Privilege Escalation: если Execution - выполнение хоть каких-то действия, то здесь нарушитель старается "добрать" недостающие ему возможности.
  5. Defense Evasion: противодействие противодействию. Жертва может использовать различные приемы обнаружения и блокирования действий нарушителя, и тот старается их обойти.
  6. Credential Access, в реальности - одна из ключевых тактик, включает в себя различные способы перехвата, восстановления, подбора или повторного использования паролей, ключей, аутентификационных токенов и т.п. Если нарушителю удается получить контроль хоть над каким-то узлом инфраструктуры, эта тактика всегда заканчивается получением учетки enterprise admin'а - таковы суровые реалии совеременной ИБ.
  7. Discovery: сбор любой возможной информации, которая может быть полезна для успешного начала или развития атаки. Сюда входят и анализ общедоступной информации инструментами OSINT, и вдумчивое изучение "внутренностей" успешно атакованных элементов инфраструктуры.
  8. Lateral Movement: "расползание" по атакованной инфраструктуре, расширение своего присутствия. "Захватывай все, до чего можешь дотянуться - потом посмотрим, как это использовать". По применяемым техникам - то же самое, что и Initial Access, но только после усепшного преодоления периметра, когда возможностей для "захвата" внутренних элементов инфраструктуры гораздо больше.
  9. Command and Control, задача, смежная с Persistence: обеспечить удаленное управление контролируемыми узлами инфраструктуры, а в некоторых случаях - возможность "поработать руками" на узле, к которому у нарушителя не должно было бы быть удаленного доступа.
  10. Collection, Exfiltration, Impact, финальные штрихи успешной атаки: сбор интересующей нарушителя информации (и ее выгрузка наружу, что, с учетом ее объемов, может оказаться совсем нетривиальной задачей), а также всевохможные деструктивные действия.

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

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

  1. в приложении в какой-то момент может присутствовать уязвимость, которая позволит нарушителю внедрить в CMS собственный модуль;
  2. в приложении в какой-то момент может присутствовать уязвимость, которая позволит нарушителю выполнить команду ОС, SQL-запрос или собственный скрипт;
  3. в приложении в какой-то момент может присутствовать уязвимость, которая позволит нарушителю выполнить собственный скрипт в браузере пользователя;
  4. в приложении в какой-то момент может присутствовать уязвимость, которая позволит нарушителю выгрузить чувствительную информацию, например - хеши паролей пользователей или, не дай Бог, сами пароли открытым текстом;
  5. в приложении в какой-то момент может присутствовать учетная запись пользователя со словарным парлем (или с паролем, который бул успешно получен в резуьтате атаки на другой элемент инфраструктуры) и т.п.

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

  1. Определенный, пригодный для этой техинки класс уязвимостей, которые могут присутствовать в информационной системе "от рождения" или могут появиться в ходе эксплуатации. Причем формулировка "могут появиться" - скорее дань политкорректности: вероятность появления таких уязвимостей напрямую зависит от уровня пофигизма, присущего IT-индустрии на всех стадиях жизненного цикла информационных систем, и сейчас честнее было бы говорить "неизбежно появятся, рано или поздно".
  2. Определенные приемы, приеняемые нарушителем. Т.е., когда мы говорим "протокол STP позволяет перенаправлять и перехватывать трафик", речь идет не о теоретической возможности, а о вполне определенной последовательности действий, которую можно продемонстрировать.
  3. Определенные последствия, в том числе - получение нарушителем определенных возможностей. Опять же, когда мы говорим "доступность протокола STP АРМам пользователей - это плохо", это означает вполне конкретные последствия: нарушитель может перехватывать трафик (и это дает ему вохможность применять "пассивные" техники, основанные на анализе трафика) или, при неосторожном применении техники, капитально "уронить" ядро сети.
  4. Определенные следы, которые оставляет применение этой техники и по которым ее применение можно обнаружить - в момент атаки или в ретроспективе. Именно поэтому в нормативных документах ФСБ обнаружением атак называется не применение IDS, а комплекс действий по анализу разнародных событий с привязкой их к определенным техникам.
  5. Определенные "точечные" меры противодействия. Не абстрактные "поставьте SIEM", "анализируйте программный код", "управляйте конфигурацией", а "настройте вот такие корреляции", "следите, чтобы в коде не появлялись вот такие конструкции" и "бейте админа по рукам при попытке изменить вот эти параметры".

При моделировании угроз на уровне техник появляется возможность оценивать достаточность применяемых мер защиты уже на стадии разработки ТЗ. Вы написали, что должна обеспечиваться аутентификация пользователей по паролям с вот такими требованиями к минимальной политикой сложности? Этого недостаточно: извольте дописать в ТЗ требования к защите парольной информации в процесе хранения, к защите аутентификационной информации в процессе ее передачи и использования, к мерам обнаружения попыток активного подбора паролей, к защите от задания слабых/словарных паролей пользователями и администраторами и так далее. Иногда коллеги возражают: мол, все эти технические подробности исполнитель должен придумать и сформулировать сам. Такое возражение вызыает только недоумение: если такие техические подробности исполнитель должен определять сам по своему усмотрению, то зачем вы вообще тратили свое и его время на написание и согласоваие банальностей про необходимость аутентификации или управления доступом? Основное назначение ТЗ - не дать разработчику "сэкономить", отказавшись от реализации действительно нужных вам фич, и чем абстрактнее требования - тем лучше для него и тем хуже для вас.

Как именно мы разрабатываем модели угроз на уровне техник, расскажу в следующий раз, но основные принципы нетрудно понять и без этого. К моменту написания ТЗ на создание системы разработчик, а часто - и заказчик тоже, уже в общих чертах представляют, из каких компонентов система будет состоять, как будут реализованы основные ее функции, какой софт будет использоваться на каждом из компонентов, в какой инфраструктуре все это будет обитать т.п. Уже в этот момент для каждого из будущих компонентов информационной системы и для каждого существующего элемента инфрастуктуры можно определить, какие техники потенциально к ним применимы и что нарушитель может получить, атаковав этот объект. Для информационной системы это можно сделать для каждого компонента отдельно, для инфраструктуры - сгруппировав элементы по типам ("виндовые АРМ", "линуксовые АРМ", "коммутаторы Cisco/Huawei", "узлы с веб-интерфейсами" и т.п.). Это, в свою очепредь, позволяет определить "до вот таких узлов я могу дотянуться снаружи или со своего рабочего места" (т.е. определить возможные стартовые точки сценария) и "контролируя узел А, я могу дотянуться до узлов Б, В и Г" (т.е. возможные пути продвижения по инфраструктуре, включая компоненты информацинной системы, для которой моделируются угрозы). Результатом становится граф атак, который определяет все возможные пути реализации угрозы и, что гораздо важнее, "точечные" меры защиты, которые помешают нарушителю двигаться по любому из этих путей. Основная хитрость - как сделать описание этого графа максимально компактынм и максимально полезным, но об этом, опять же, вследующий раз.

Что по этому поводу говорит методика

Да, раздел 6 написан на основе MITRE Att&CK. В нем определены те же тактики, что и в матрице Enterprise ("Credential Access" не выделена в отдельную тактику, а "Collection" и "Exfiltrarion" объединены). Подробное описание техник в документ включать не стали - участники сошлись во мнении, что "прибивать гвоздями" описание техник к нормативному документу, который потом не так-то просто изменить - плохая идея. Гораздо правильнее вместо этого переделать БДУ, включив в нее подробное описание техник и исправив недостатки, свойственные Att&CK. Но так как доработка БДУ - вопрос времени, в документ включили обобщенное перечисление техник, которое уже при моделировании угроз каждый впаве самостоятельно детализировать. При этом можно использовать любые общедоступные ресурсы и собственные знfния предметной области - например, мы в своей работе используем довольно много техник, которые в Att&CK даже не упоминаются.

В методике говорится о том, что при модлировании угроз нужно рассмаотреть максимально возможное количество сценариев. Почему? Для того, чтобы продемонатрировать актуальность угрозы, достаточно ограничиться очевидными сценариями ее реализации (социалка на пользователей системы, вербовка администратора системы и т.п.). Но дальше-то что? Если мы предлагаем меры защиты, то нужно показать, что этих мер защиты достаточно. "Мы рассмотрели все известные нам возможности реализации угрозы и ни одну из них использовать не получится" - вполне себе демонстрация достаточности, а уровень доверия к этой демонстрации определяется квалификацией исполителя. Доработка БДУ позволит исключить суббъективизм в выборе применимых техник, а пока стоит руководствоваться простым принципом: выбирайте исполнителя, который умеет примерно то же, что умеет ваш потенциальный проитвник. Не нужно переплачивать, если все, чего вы боитесь - это тупой DDoS LOIC'ом, и стоит трижды задуматься, прежде чем звать неопытного интегратора в моделирование APT-атак.

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

Обсуждая с коллегами понятие "граф атак", порой приходится сталкиваться с тем, что люди не понимают, что такое граф. Нет, это не рисунок со стрелками и надписями :) Есть разные способы представления графов, например - табличный. Граф атак, описывающий все возможные сценарии реализации угрозы, можно представиь в виде таблицы узлов (или категорий узлов) и применимых к этим узлам техник - о том, как это делается, мы поговорим как-нибудь в следующий раз.

Почему не MITRE

Да, моделирование угроз в методике ФСТЭК во многом основано не тактиках и техниках MITRE Att&CK. И нет, моделировать угрозы только на основе базы знаний MITRE Att&CK не получится. Да, это лучший из имеющихся на сеголдняшний день инструментов для моделрования возможных действий нарушителя - но только потому, что остальные инструменты еще хуже.

База знаний MITRE Att&CK в каком-то смысле иллюстрирует "систематическую ошибку выжившего" - она отражает прежде всего те техники, которые используются в реальных ставших известными инцидентах. Подавляющшее большинство широко известных инцидентов получают ту самую широкую известность благодаря усилиям антивирусных вендоров, и создается ощущение, что ключевым элментом успешных действий преступных группировок является использование вредоносного ПО. Но так ли это? Мы не можем ответить на этот вопрос, так как инцидентов, не связанных с использованием ВПО, известно крайне мало. Но если наши парни в ходе пентестов умудряются получать полный контроль над инфраструктурой заказчика без единого выстрела применения экмплойтов, то логично предположить, что то же самое умеют делать и криминальные группировки.

В матрице техник Att&CK перекос в сторону ВПО виден невооруженным взглядом - под внедрение кода целиком заточены четыре из двенадцати тактик (Execution, Persistence, Defense Evasion и Command and Control). А, например, техники проникновения в инфраструктуру крупных энтерпрайзов через косяки в настройках беспроводной сети в матрице Enterprise отсутствуют вовсе (приходится объединять матрицы Enterprise и Mobile), а все многообразие техник получения доступа к информационным системам через уязвимости веб-приложений представлено абстракцией "Exploit Public-Facing Application" (куда включены вообще все способы удаленной эксплуатации уязвимостей).

Поэтому приходится использовать полезную информацию и удачне идеи из всех доступпных источников, и Att&CK - только один из них.

Alt text