А1 ИнтегриумА1 ИнтегриумПлатформа техдокументации
ПродуктРолиПроцессКачествоВнедрениеЭффектЦеныВопросыМатериалыЗапросить демонстрацию
Безопасность и ИБ

Модель угроз: зачем нужна и как оформляется

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

Начните с объекта защиты

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

Определите основания и метод работы

Для оценки рассмотрите методику оценки угроз безопасности информации от 5 февраля 2021 года. Для регулируемого объекта профильный специалист проверяет её применимость и работает с полным документом. Эта статья предлагает порядок подготовки исходных данных, а не заменяет нормативную методику. Для систем с персональными данными статья 19 Закона № 152-ФЗ включает определение угроз в меры безопасности. Не выводите из этого одинаковую обязательную форму для любого проекта. В начале работы зафиксируйте используемые основания, границу исследования и ответственного за оценку, чтобы участники не смешивали разные подходы без пояснения.

Разбирайте сценарий и последствия

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

Сопоставьте меры и оставшиеся ограничения

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

Пример: подрядчик с доступом к хранилищу

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

Пересматривайте после значимых изменений

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

Проверка перед завершением

  • ✓Отражайте реальные границы системы.
  • ✓Объясняйте выбор и исключение сценариев.
  • ✓Связывайте меры с реализацией.

Частые вопросы

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

Читайте также

Обсудить задачу

Обсудим подготовку, проверки, согласование и выпуск документации для вашей команды.

Написать нам