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