Опишите систему до выбора угроз
Модель угроз должна опираться на назначение системы, состав данных, способы доступа и взаимодействия. Начните с процессов: кто вводит информацию, где она хранится, кто использует результат и какие внешние сервисы участвуют. Затем сопоставьте процессы с компонентами и границами доверия.
Одинаковый продукт может работать в изолированной сети или быть доступным из интернета. Это разные условия рассмотрения. Отметьте административные интерфейсы, удалённые подключения и доступ подрядчиков. Обработка информации на бумаге и передача файлов между подразделениями тоже могут быть важны для общей картины.
Формулируйте сценарии, а не общий список
Перечень названий угроз сам по себе мало помогает при проектировании. Для рабочего сценария нужно объяснить источник воздействия, уязвимое условие, затронутый компонент и возможное последствие. Например, избыточная роль пользователя связана с конкретной операцией в системе и с тем, какие данные доступны ему после входа.
Обсудите предположения с администраторами и владельцами процессов. Если защита предполагает отсутствие удалённого доступа, проверьте это по фактическим настройкам. Укажите основания для включения и исключения сценариев. Не используйте готовую модель другого заказчика как доказательство актуальности угроз вашей системы.
Свяжите угрозы с мерами и проверками
Результат становится полезным, когда для актуального сценария видно, какие меры его ограничивают и как проверить их выполнение. Часть мер относится к техническим настройкам, часть — к порядку работы персонала и подрядчиков. Связь должна сохраняться в документах и в заданиях на внедрение.
Не сводите выбор к покупке одного средства защиты. Для сценария могут понадобиться разделение прав, журналирование, сегментация и порядок реагирования. Требования к продуктам, лицензиям и применимости мер рассматриваются для конкретного объекта. Цена и состав внедрения рассчитываются после согласования границ.
Поддерживайте документ после изменений
Подключение нового интеграционного сервиса, перенос системы или изменение состава данных — повод проверить принятые предположения. Назначьте владельца модели и порядок её пересмотра. В реестре версии полезно хранить причину изменения и связь с архитектурным решением или обследованием.
При приёмке оценивайте не объём текста, а воспроизводимость рассуждения: понятные исходные данные, описанные условия, согласованные сценарии и связь с мерами. Состав документа и применяемые методические основания фиксируются в задании. Материал этой страницы помогает подготовить обсуждение, но не заменяет модель конкретной системы.
Что подготовить к первому обсуждению
- Назначение системы и категории данных
- Компоненты, площадки и границы доверия
- Роли пользователей, администраторов и подрядчиков
- Сетевые и внешние взаимодействия
- Предположения, сценарии и последствия
- Связь мер, проверок и порядка пересмотра
Отправьте краткое описание без чувствительных вложений. Если какой-то пункт неизвестен, отметьте это: обследование и восстановление исходных данных можно согласовать отдельным этапом.
Границы предложения
Материал опирается на направления работ НПК Оборон-Экран: обследование, подготовку защиты, аттестационные задачи, персональные данные, КИИ и мониторинг ИБ. Он помогает сформулировать запрос и не определяет правовой статус объекта заочно. Применимые требования, права исполнителя и роли сторон проверяются для конкретного задания; специальные допуски одной организации не переходят другой автоматически.
Объём, результаты, порядок приёмки и возможные исключения фиксируются в предложении и договоре. Итоговое соответствие, наличие необходимого допуска и завершение обязательной процедуры подтверждаются своими документами. Цена, универсальный срок и положительный результат заранее не обещаются.
Направления работ