Как пользоваться таблицей требований
Как применять требования Приказа ОАЦ № 66 на практике:
сначала определить класс типовой информационной системы, затем выбрать соответствующий столбец
в приложении 3, установить обязательность каждого требования, определить способ реализации
и заранее подготовить доказательства выполнения.
Эта страница объясняет порядок работы с подготовленной GuardCore таблицей. Она не заменяет
официальный текст Приказа ОАЦ № 66: при расхождении приоритет имеет действующая редакция
нормативного акта.
Что представляет собой таблица
Приложение 3 к Положению о порядке технической и криптографической защиты информации
содержит перечень требований к системе защиты информации, подлежащих включению
в техническое задание, и матрицу применимости по классам типовых информационных систем.
В GuardCore эта матрица дополнена ссылками на отдельный практический разбор каждого пункта.
класс ИС → применимый столбец → обязательность требования → способ реализации →
документирование → доказательства выполнения.
Сначала определите класс информационной системы
Нельзя корректно читать матрицу требований до определения класса типовой ИС. Класс зависит
от вида обрабатываемой информации и от наличия подключения к открытым каналам передачи данных.
Результат отнесения оформляется актом отнесения информационной системы к классу
(классам) типовых информационных систем.
Если система одновременно обрабатывает несколько видов защищаемой информации, следует
проверить применимость всех присвоенных ей классов и не ограничиваться одним столбцом
только потому, что он содержит меньше требований. До утверждения акта матрица может
использоваться только как предварительный ориентир.
Как читать обозначения «+» и «+/−»
Обязательное требование
Для выбранного класса требование должно быть учтено и реализовано.
Рекомендуемое требование
Нормативная таблица не относит его к обязательным для данного класса.
В примечаниях к приложению 3 прямо установлено: требования со знаком «+» являются
обязательными, а со знаком «+/−» – рекомендуемыми.
Практический подход GuardCore: рекомендуемое требование не следует автоматически удалять
из проекта. Сначала оценивают архитектуру ИС, угрозы, уже применяемые меры и ожидаемый эффект,
после чего принимают и документируют решение о применении либо неприменении меры.
Это методическая рекомендация, а не изменение статуса «+/−», установленного Приказом.
Когда рекомендуемая мера всё же полезна
Рекомендуемый статус означает именно отсутствие обязательности в конкретной ячейке приложения 3,
а не отсутствие риска. Например, архитектура может содержать удалённое администрирование,
общие сегменты виртуализации, внешние подключения или критичные прикладные сервисы,
для которых дополнительная мера снижает реальный риск эксплуатации.
Поэтому при проектировании полезно отдельно фиксировать: «требование рекомендуемое»,
«решение – применить» либо «решение – не применять», а рядом – краткое обоснование.
Такой подход позволяет позднее понять, почему конкретная мера появилась в ТЗ или,
наоборот, была исключена из проекта.
Не путайте требование и средство защиты
В таблице описывается требуемый результат. Конкретный продукт, служба Windows, функция
межсетевого экрана, организационный регламент или иной механизм – это уже способ достижения
результата. Один и тот же пункт может быть реализован организационной, технической
или комбинированной мерой.
Поэтому при чтении отдельной статьи сначала устанавливайте смысл требования,
а уже затем выбирайте инструмент. Иначе можно получить формально установленное средство,
которое не обеспечивает проверяемый результат.
Четыре уровня, которые должны совпасть
Как работать с отдельным требованием
- Найдите строку требования и выберите столбец класса вашей ИС.
- Зафиксируйте статус: обязательное «+» либо рекомендуемое «+/−».
- Откройте разбор GuardCore и определите, какой результат требуется получить.
- Сопоставьте требование с архитектурой: какие активы, сегменты, пользователи и каналы оно затрагивает.
- Выберите вариант реализации: организационный, технический или комбинированный.
- Закрепите решение документально там, где это необходимо.
- Сразу определите доказательство, которое можно будет воспроизвести при внутренней проверке или аттестации.
Что считать доказательством
Само наличие продукта или записи в ТЗ не доказывает выполнение требования. Доказательство
должно позволять установить фактическое состояние защиты и воспроизвести проверку.
- утверждённые ЛПА и организационно-распорядительные документы;
- фрагменты ТЗ, политики ИБ, регламентов и инструкций;
- скриншоты настроек с понятным источником и контекстом;
- выгрузки конфигураций, журналы и события безопасности;
- результаты проверочных действий и тестов;
- протоколы испытаний и иные материалы, позволяющие подтвердить результат.
Как проверить качество доказательства
Перед включением материала в протокол полезно задать три вопроса. Первое: понятно ли,
какое именно требование подтверждает доказательство. Второе: можно ли по нему определить
конкретный актив, систему или настройку. Третье: можно ли воспроизвести проверку повторно,
не опираясь на устное пояснение администратора.
Скриншот без названия узла, путь в интерфейсе без результата, журнал без временного интервала
или документ без связи с конкретной мерой создают слабую доказательную базу. Для каждой меры
лучше заранее определять проверочное действие и ожидаемый результат проверки.
Как использовать таблицу перед аттестацией
Положение об аттестации предусматривает использование акта отнесения ИС к классу,
политики информационной безопасности, структурной и логической схем, технического задания,
ЛПА и других организационно-распорядительных документов, а также документов на средства
защиты информации.
В ходе аттестации проверяется соответствие фактического состава активов структурной
и логической схемам, достаточность реализованных мер, документы и фактическое выполнение
установленных требований. Поэтому удобнее не собирать доказательства в последний момент,
а вести матрицу «требование → актив → реализация → документ → проверочное действие → результат».
Та же логика подходит для внутреннего предпроектного аудита: сначала фиксируется текущее
состояние, затем несоответствия, после чего формируется перечень обязательных доработок.
Как использовать таблицу для внутреннего аудита
Внутренний аудит удобно строить не от перечня установленного оборудования, а от строк приложения 3.
Для каждой обязательной строки задаётся один и тот же набор вопросов: применимо ли требование,
чем оно реализовано, где это закреплено, на каких активах проверяется и какое доказательство
подтверждает результат.
Если ответ отсутствует хотя бы на одном уровне, это не всегда означает одинаковую по критичности
проблему. Может отсутствовать документ при работающей технической мере, доказательство при
корректной настройке или сама реализация. Такие ситуации полезно разделять в реестре
несоответствий, потому что способы устранения и сроки для них различаются.
Как сформировать собственную рабочую матрицу
Полная таблица GuardCore отвечает на вопрос, какие пункты существуют и какова их нормативная
применимость. Для конкретной организации имеет смысл создать рабочую копию матрицы и добавить
к каждой строке поля: применимо ли требование к данной ИС, какие активы затрагиваются,
как реализовано требование, какой документ это закрепляет, каким действием проводится
проверка и где хранится доказательство.
Такая матрица становится связующим документом между проектированием, внедрением, аудитом
и аттестацией. По ней сразу видно, где отсутствует реализация, где есть настройка без
документа, а где документ описывает меру, которой фактически нет в инфраструктуре.
Типичные ошибки при работе с таблицей
- выбирать требования до официального отнесения ИС к классу;
- читать «+/−» как запрет или как требование, которое обязательно нужно исключить;
- подменять организационное требование названием технического продукта;
- считать наличие СЗИ достаточным доказательством без проверки конфигурации;
- не связывать требования с конкретными активами и сегментами;
- готовить скриншоты без указания, что именно ими подтверждается;
- иметь разные сведения в схемах, перечне активов, ТЗ и фактической инфраструктуре.
Рабочий маршрут
Для первого прохода не нужно читать все 51 статьи подряд. Определите класс ИС,
откройте таблицу, выберите применимые требования и переходите к разборам только тех пунктов,
которые относятся к вашей системе.
Нормативная основа
Основной источник – действующая консолидированная редакция Приказа Оперативно-аналитического
центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66. Для работы с матрицей
используется приложение 3 к Положению о порядке технической и криптографической защиты
информации; для подготовки к аттестации – Положение о порядке аттестации систем защиты информации.