Категорирование в рамках приказа ФСТЭК 239 - это этап, который задает дальнейший объем мер. Если категория определена неверно, все последующие решения будут либо избыточными, либо недостаточными. На практике ошибка чаще связана не с расчетом, а с неправильным описанием объекта, границ и сценариев, которые реально поддерживаются системой.
Почему категорирование вызывает трудности
Категорирование часто пытаются выполнить по шаблону: взять похожий объект и перенести значения. Это плохо работает, потому что у разных организаций разные процессы, разные цепочки зависимости и разные последствия отказа. Еще одна причина - попытка описать объект слишком широко. Чем шире граница, тем сложнее собрать корректные данные, и тем выше риск неучтенных каналов доступа и интеграций.
Сначала границы, потом оценка
Перед оценкой фиксируются границы объекта: какие подсистемы входят, какие данные обрабатываются, где хранятся журналы, какие интерфейсы доступны извне, как устроены резервирование и администрирование. Важно описать не только основную систему, но и элементы, без которых она не работает: каталог учетных записей, сетевые шлюзы, сервисы мониторинга, системы резервного копирования. Если их не учесть, категория будет рассчитана для "идеальной схемы", а не для реальной.
Ошибки, которые чаще всего искажают результат
Первая ошибка - оценивать последствия только по ИТ-параметрам, например по времени простоя, и не учитывать цепочки зависимостей. Вторая ошибка - не различать аварийный отказ и нарушение целостности данных. Простои обычно заметны сразу, а повреждение данных может проявиться позже и дать более тяжелые последствия. Третья ошибка - считать, что внешние интеграции не влияют на объект, хотя через них проходят критичные операции.
Как собрать данные для оценки
Нужны источники, которые отражают реальную эксплуатацию: схемы сети и сегментации, перечни интеграций, журналы изменений, данные о резервных копиях, перечни ролей и прав, описание бизнес-процессов. Хорошо, если это подтверждается не только словами, но и артефактами: выгрузками, конфигурациями, журналами. Тогда категорирование становится повторяемым: его можно обновлять при изменении системы, не начиная заново.
Один практичный порядок работ для категорирования:
-
описать объект и границы, включая зависимости и точки администрирования
-
перечислить сценарии функционирования и критичные операции, которые поддерживаются
-
определить виды негативных последствий для каждого сценария: отказ, искажение, утечка, недоступность
-
зафиксировать допущения и источники данных, чтобы оценку можно было воспроизвести
-
сверить результат с владельцами процессов и с тем, как система реально используется
Проверка категорирования через тестовые вопросы
После получения категории полезно пройтись по контрольным вопросам. Что будет, если отключить каталог учетных записей? Что будет, если нарушится целостность справочника или очереди сообщений? Можно ли выполнить критичную операцию через внешнюю интеграцию без дополнительных проверок? Есть ли сервисные аккаунты, через которые администрирование возможно в обход основной схемы? Такие вопросы быстро показывают, где границы описаны неполно.
Что делать, если система постоянно меняется
Если объект развивается, категорирование лучше держать как рабочую процедуру. При каждом значимом изменении проверяется, не изменились ли границы, критичные сценарии и зависимости. Для этого помогает журнал изменений и список триггеров пересмотра: новая интеграция, смена схемы доступа, перенос в другой сегмент, изменение модели резервирования, появление внешних подрядчиков с доступом.
Оформление результатов и связь с последующими документами
Результаты категорирования должны быть оформлены так, чтобы их можно было использовать дальше: при разработке модели угроз, при выборе мер и при подготовке планов контроля. Полезно фиксировать не только итоговую категорию, но и основания: какие сценарии рассматривались, какие допущения приняты, какие источники данных использованы. Если основания не описаны, при смене ответственных или при проверке становится непонятно, почему выбрано именно такое значение, и оценка превращается в спор мнений.
Типовые расхождения, которые всплывают на проверках
Нередко категория формально определена, но меры на практике соответствуют другой картине. Например, в оценке заявлено, что доступ ограничен сегментацией, а фактически есть общий VPN-профиль для подрядчиков. Или указано, что администрирование централизовано, но существует локальная учетная запись на сервере, о которой не знают владельцы процесса. Поэтому после категорирования полезно провести короткую сверку: описанная схема доступа и управления должна совпадать с конфигурациями и журналами изменений
В процессе создания статьи частично задействованы материалы с сайта blog.infra-tech.ru - категорирование по ФСТЭК 239
Дата публикации: 27 июня 2022 года