“Декомпозиция приложения — это не просто создание диаграмм, а способ понять его как цель для атаки. Мы разбираем систему на ключевые элементы, чтобы увидеть её глазами злоумышленника: откуда можно проникнуть, что украсть и какую уязвимость использовать.”
Шаг 1: Декомпозиция приложения
Первая стадия моделирования угроз — детально разобраться в том, как устроено приложение и как оно взаимодействует с внешним миром. Работа ведётся в нескольких направлениях:
- Определение сценариев использования (use cases): как приложением пользуются легальные пользователи.
- Выявление точек входа: где потенциальный злоумышленник может взаимодействовать с системой.
- Выявление активов: что представляет ценность и может стать целью атаки.
- Определение уровней доверия: какие права доступа предоставляются различным субъектам (пользователям, системам, процессам).
Вся собранная информация фиксируется в документе модели угроз и используется для построения диаграмм потоков данных (DFD). DFD наглядно показывают, как данные перемещаются между компонентами системы, и, что критически важно, где проходят границы привилегий.
Шаг 2: Определение и ранжирование угроз
Для систематического поиска угроз используют методологии их классификации. Один из самых распространённых подходов — STRIDE, который фокусируется на целях атакующего:
- Spoofing (спуфинг личности)
- Tampering (несанкционированное изменение данных)
- Repudiation (отказ от авторства действий)
- Information Disclosure (раскрытие информации)
- Denial of Service (отказ в обслуживании)
- Elevation of Privilege (повышение привилегий)
Альтернативой может служить подход с позиции защиты, например, Application Security Frame (ASF), который группирует угрозы по категориям контролей безопасности: аутентификация, авторизация, защита данных, журналирование и другие.
DFD, построенные на первом шаге, помогают определить, на какие элементы системы (процессы, хранилища, потоки данных) может быть направлена атака. Для каждой выявленной угрозы полезно строить деревья угроз, где корнем является цель атаки, а ветвями — пути её достижения через эксплуатацию уязвимостей.
Следующий этап — оценка риска. Можно использовать субъективные модели вроде DREAD, которая присваивает баллы по параметрам: Damage (ущерб), Reproducibility (воспроизводимость), Exploitability (возможность эксплуатации), Affected users (пострадавшие пользователи), Discoverability (обнаружаемость). Для более объективной оценки применяют качественные модели, где риск определяется как произведение вероятности реализации угрозы на потенциальный ущерб для бизнеса.
Шаг 3: Определение контрмер и смягчение рисков
Уязвимость может быть устранена или смягчена с помощью контрмеры. Для их поиска удобно использовать таблицы сопоставления типа угрозы и возможных защитных мер. После ранжирования угроз по уровню риска можно выстроить приоритеты для устранения.
Для каждой угрозы с высоким риском рассматривается стратегия реагирования:
- Принять: осознанно оставить риск, если его воздействие на бизнес приемлемо.
- Устранить: убрать компонент, делающий уязвимость возможной.
- Смягчить: внедрить проверки или механизмы контроля, снижающие вероятность реализации угрозы или размер ущерба.
Далее каждый из этих шагов рассматривается более подробно с примерами.
Декомпозиция приложения
Цель — добиться всестороннего понимания логики работы приложения и его связей с внешними системами. Этот процесс структурирован и подразумевает последовательный сбор информации.
Метаданные модели угроз
Документ начинается с базовой информации, идентифицирующей объект анализа:
- Название приложения
- Версия приложения
- Описание: высокоуровневое описание функциональности.
- Владелец документа
- Участники: команда, участвовавшая в моделировании.
- Рецензент
Пример:
Метаданные модели угроз
Версия приложения: 1.0
Описание: Веб-сайт библиотеки колледжа — первая реализация онлайн-сервиса для библиотекарей и читателей (студентов и сотрудников). Функциональность начальная. Определены три роли пользователей: Студент, Сотрудник, Библиотекарь. Студенты и сотрудники могут входить в систему и искать книги, сотрудники — запрашивать книги. Библиотекари могут добавлять книги и пользователей, а также осуществлять поиск.
Владелец документа: Петров И.С.
Участники: Сидоров А.В., Козлова Е.П.
Рецензент: Иванов Д.К.
Внешние зависимости
Это элементы, внешние по отношению к коду приложения, но влияющие на его безопасность. Часто они находятся под контролем инфраструктурного подразделения, а не команды разработки. Сюда относятся требования к среде выполнения: операционные системы, СУБД, межсетевые экраны, политики харденинга.
Внешние зависимости документируются в виде таблицы:
- ID: уникальный идентификатор.
- Описание: детальное описание зависимости.
Пример:
Внешние зависимости
ID Описание 1 Веб-сервер работает на Linux с Apache, харденинг выполнен в соответствии с внутренним стандартом компании, включая установку актуальных обновлений безопасности. 2 СУБД — MySQL на отдельном Linux-сервере, также харденизированном по стандарту. 3 Соединение между веб-сервером и СУБД осуществляется по выделенному сегменту сети. 4 Веб-сервер расположен за межсетевым экраном, доступ извне возможен только по TLS.
Точки входа
Интерфейсы, через которые атакующий может передать в приложение данные или команды. Точки входа могут быть многоуровневыми: например, весь веб-сайт — точка входа, каждая его страница — вложенная точка входа, каждое поле формы на странице — ещё более глубокая точка входа. Точки входа и выхода определяют границы доверия в системе.
Документирование:
- ID: уникальный идентификатор, для вложенных точек используется нотация major.minor (например, 1.2.1).
- Название: понятное имя точки входа.
- Описание: что происходит в этой точке.
- Уровни доверия: какие роли имеют доступ к этой точке. Ссылается на список уровней доверия.
Пример:
Точки входа
ID Название Описание Уровни доверия 1 HTTPS порт Единственный внешний доступ к сайту по TLS. Все страницы сайта являются вложенными точками входа. (1) Анонимный пользователь
(2) Авторизованный пользователь
(3) Пользователь с неверными данными
(4) Библиотекарь1.1 Главная страница Стартовая страница сайта. (1) Анонимный пользователь
(2) Авторизованный пользователь
(3) Пользователь с неверными данными
(4) Библиотекарь1.2 Страница входа Страница аутентификации пользователей. (1) Анонимный пользователь
(2) Авторизованный пользователь
(3) Пользователь с неверными данными
(4) Библиотекарь1.2.1 Функция логина Обработчик формы входа, сравнивающий введённые данные с записями в БД. (2) Авторизованный пользователь
(3) Пользователь с неверными данными
(4) Библиотекарь
Точки выхода
Часто упускаемый из виду, но критически важный элемент. Точки выхода — это места, где приложение отдаёт данные внешнему потребителю (пользователю, другой системе). Именно через них реализуются такие атаки, как межсайтовый скриптинг (XSS) или раскрытие чувствительной информации в ошибках. Угрозы точек выхода тесно связаны с угрозами соответствующих точек входа: некорректное сообщение об ошибке при логине (выход) может раскрыть факт существования пользователя, помогая в подборе учётных данных.
Активы
То, что представляет ценность и является целью атаки. Активы делятся на материальные (данные пользователей, конфигурационные файлы, сессионные токены) и абстрактные (репутация компании, доступность сервиса).
Документирование активов:
- ID: уникальный идентификатор.
- Название.
- Описание и обоснование необходимости защиты.
- Уровни доверия: какие роли имеют право доступа к активу.
Пример:
Активы
ID Название Описание Уровни доверия 1 Учётные данные Данные для входа пользователей и администраторов 1.1 Хэши паролей пользователей Зашифрованные пароли учётных записей студентов и сотрудников в БД. (4) Библиотекарь
(5) Администратор БД
(7) Процесс веб-сервера2 Персональные данные Конфиденциальная информация о пользователях 2.1 База персональных данных ФИО, контакты, читательские билеты пользователей. (4) Библиотекарь
(5) Администратор БД
(6) Администратор сайта3 Функциональность системы Критичные возможности, которые могут быть скомпрометированы 3.1 Возможность выполнения SQL-запросов Привилегия на чтение/запись в базу данных от имени приложения. (7) Процесс веб-сервера
(8) Пользователь БД (чтение)
(9) Пользователь БД (чтение/запись)
Уровни доверия
Формализация прав доступа, которые приложение предоставляет внешним субъектам. Каждому уровню доверия ставятся в соответствие точки входа и активы, что позволяет наглядно видеть, кто и к чему имеет доступ.
Документирование:
- ID: уникальный номер.
- Название: имя роли или субъекта.
- Описание: детализация прав и контекста.
Пример:
Уровни доверия
ID Название Описание 1 Анонимный пользователь Подключился к сайту, но не представил учётных данных. Имеет доступ только к публичным страницам. 2 Авторизованный пользователь Вошёл в систему под учётной записью студента или сотрудника. Может искать и запрашивать книги. 4 Библиотекарь Сотрудник библиотеки. Может добавлять книги, регистрировать новых пользователей, просматривать персональные данные читателей. 7 Процесс веб-сервера Системный пользователь, от имени которого выполняется код backend приложения. Имеет права на подключение к БД от имени специальной учётной записи.
Диаграммы потоков данных
Вся собранная информация визуализируется в виде DFD. Это ключевой артефакт, который позволяет увидеть систему целиком: откуда данные приходят, как обрабатываются, где хранятся и куда уходят. DFD иерархичны: начинаются с контекстной диаграммы высокого уровня, которая затем детализируется для каждого процесса.
Стандартные обозначения в DFD для моделирования угроз:
| Символ | Название | Описание |
|---|---|---|
 |
Внешняя сущность | Пользователь или внешняя система, взаимодействующая с приложением. |
 |
Процесс | Компонент, обрабатывающий данные (например, серверный скрипт). |
 |
Хранилище данных | Место, где данные сохраняются (БД, файл, кэш). |
 |
Поток данных | Направленное движение данных между элементами. |
 |
Граница доверия | Пунктирная линия, обозначающая переход, где меняется уровень привилегий (например, переход из сети интернет в внутреннюю сеть приложения). |
Определение и ранжирование угроз
Категоризация угроз
STRIDE остаётся наиболее практичным и наглядным инструментом для поиска угроз, так как напрямую отвечает на вопрос «Что может сделать злоумышленник?».
| Тип угрозы (STRIDE) | Описание | Контроль безопасности |
|---|---|---|
| Spoofing | Воровство и использование чужих учётных данных. | Аутентификация |
| Tampering | Несанкционированное изменение данных (в БД или при передаче). | Целостность |
| Repudiation | Возможность для пользователя отрицать совершённые действия. | Неотказуемость |
| Information Disclosure | Несанкционированное чтение данных. | Конфиденциальность |
| Denial of Service | Нарушение доступности сервиса для легитимных пользователей. | Доступность |
| Elevation of Privilege | Получение прав, превышающих исходные (например, прав администратора). | Авторизация |
Анализ угроз и деревья угроз
После категоризации для каждой значимой угрозы строится дерево угроз. Это аналитический инструмент, который раскладывает общую цель атаки («украсть данные пользователей») на конкретные шаги и условия. В узлах дерева находятся уязвимости, а листья — это конечные техники атаки. Такой подход позволяет понять не только «что», но и «как» может быть скомпрометирована система.
Дополнительную глубину даёт анализ сценариев злоупотребления (abuse cases). В то время как use case описывает легальное действие пользователя, abuse case моделирует, как это же действие может быть искажено для атаки. Например, use case — «Пользователь вводит логин и пароль для входа». Соответствующий abuse case — «Злоумышленник вводит в поле логина специально сформированную строку для осуществления SQL-инъекции».
Ранжирование угроз
Для приоритизации работ по устранению угрозы оцениваются с точки зрения риска. Простая качественная модель часто эффективнее сложных численных расчётов.
Вероятность (Likelihood) оценивается по вопросам:
- Можно ли эксплуатировать угрозу удалённо?
- Требуется ли предварительная аутентификация злоумышленника?
- Можно ли автоматизировать атаку?
Воздействие (Impact) оценивается по вопросам:
- Позволяет ли успешная атака получить полный контроль над системой?
- Приведёт ли атака к раскрытию конфиденциальных данных (ПДн, коммерческая тайна)?
- Сколько пользователей или систем будет затронуто?
Присвоив каждому параметру значения High, Medium или Low, можно получить матрицу риска и классифицировать угрозы как критические, высокие, средние или низкие.
Определение контрмер и смягчение рисков
Контрмера — это защитный механизм, который предотвращает реализацию угрозы или снижает её воздействие. Для каждой категории угроз существуют типовые контрмеры.
Примеры контрмер для категорий ASF
| Категория угроз | Примеры контрмер |
|---|---|
| Аутентификация | Хранение хэшей паролей с солью; защита от перебора и подбора; многофакторная аутентификация для административного доступа. |
| Авторизация | Проверка прав на каждом уровне (UI, бизнес-логика, данные); принцип минимальных привилегий для сервисных учётных записей. |
| Защита данных | Шифрование чувствительных данных при передаче (TLS) и хранении; использование надёжных алгоритмов и управление ключами. |
| Валидация данных | Строгая валидация на стороне сервера по белому списку; экранирование выходных данных (output encoding). |
| Обработка ошибок | Унифицированное обработка исключений без передачи деталей системы пользователю; журналирование инцидентов для расследования. |
Профиль угроз и статус митигации
По итогам анализа формируется профиль угроз, где каждая угроза помечается одним из статусов:
- Не устранённая угроза: контрмеры отсутствуют, уязвимость может быть полностью эксплуатирована. Высший приоритет для исправления.
- Частично устранённая угроза: есть базовые защиты, но остаются векторы атаки, требующие дополнительных мер.
- Полностью устранённая угроза: реализованы адекватные контрмеры, риск снижен до приемлемого уровня.
Взаимосвязь с анализом кода
Моделирование угроз не заменяет статический или динамический анализ кода, но существенно его усиливает. Проводя анализ кода после декомпозиции, специалист фокусируется не на всём коде подряд, а на тех компонентах, которые были определены как критические: точки входа с высоким уровнем доверия, процессы, обрабатывающие ключевые активы, модули, пересекающие границы доверия. Это превращает рутинную проверку в целенаправленную охоту за уязвимостями, эффективность которой многократно выше.