«Требования по ИБ часто пишут как формальность, чтобы «закрыть» чек-лист аудитора. Но это живой инструмент, который связывает абстрактные риски с конкретными настройками в системе и действиями людей. Когда требования написаны правильно, проверки перестают быть стрессом, а каждый новый проект сразу ясно, как защищать».
Почему требования — это фундамент безопасности
Крупные компании иногда тратят миллионы на современные средства защиты — межсетевые экраны, системы обнаружения вторжений, криптографию — но инциденты всё равно происходят. Часто причина не в технике, а в том, что система защиты не была увязана с реальными бизнес-процессами. Средства внедряются точечно, а требования к их работе сформулированы размыто.
Без чётких требований даже лучшие инструменты превращаются в набор разрозненных функций. Требования — это не список пожеланий, а конструкторская документация. Они переводят цели бизнеса и диктуемые законом обязательства в конкретные технические спецификации и организационные регламенты.
Ключевые понятия
Чтобы избежать разночтений, важно договориться о терминах.
Требование ИБ
Конкретное, измеримое условие, которому должна соответствовать система, процесс или поведение персонала для выполнения целей безопасности. Хорошее требование всегда можно проверить.
Модель угроз
Структурированное описание потенциальных нарушителей, их целей, методов атаки и уязвимых активов. Это основа для формирования требований: нельзя защищаться от всего, нужно защищаться от конкретных угроз, актуальных для организации.
Уровень защищённости
Интегральная характеристика, показывающая, насколько текущее состояние ИБ соответствует целям. Может определяться по результатам аудита или по шкале, заданной в отраслевых стандартах (например, в требованиях ФСТЭК к системам защиты информации).
Три уровня требований информационной безопасности
Эффективная система защиты не ограничивается техникой. Она работает на трёх взаимосвязанных уровнях, и требования должны быть сформированы для каждого.
Организационный уровень
Здесь определяются правила игры. Требования этого уровня создают среду, в которой технические меры будут работать системно, а не сами по себе.
- Политика ИБ: Документ верхнего уровня, который задаёт принципы, распределяет роли и ответственность.
- Руководитель (подразделение) ИБ: Требование о назначении ответственного с реальными полномочиями и ресурсами.
- Регламенты: Чёткие инструкции по реагированию на инциденты, классификации данных, проведению аудитов.
- Планы мероприятий: Дорожные карты внедрения, графики проверок, сроки устранения уязвимостей.
Технический уровень
Конкретные параметры, настройки и архитектурные решения. Ключевая задача — избежать избыточности, которая удорожает систему, и недостаточности, создающей бреши.
- Выбор средств защиты (СЗИ): Требования к типам систем (DLP, SIEM, WAF) на основе оценки рисков, а не маркетинга вендоров.
- Каналы связи: Минимальные версии протоколов шифрования (TLS 1.2+), использование VPN, защита от MITM-атак.
- Аудит и мониторинг: Параметры логирования, сроки хранения логов, правила корреляции событий в SIEM.
- Контроль доступа: Внедрение ролевой модели (RBAC), обязательная многофакторная аутентификация (MFA) для критичных систем, принцип наименьших привилегий.
Кадровый уровень
Человеческий фактор — источник большинства инцидентов. Требования этого уровня формируют культуру безопасного поведения.
- Обучение: Обязательные регулярные тренинги по ИБ для разных категорий сотрудников (не только для технических специалистов).
- Инструктажи: Вводный при приёме на работу и периодические — при изменении регламентов или после инцидентов.
- Тестирование: Проведение фишинговых атак (с согласованием с руководством) для проверки бдительности, симуляции инцидентов для отработки действий.
Нормативно-правовая база
Требования к системе защиты информации не создаются в вакууме. Они выводятся из законодательных и отраслевых нормативов, которые задают обязательный минимум.
| Норматив | Область применения | Что переходит в требования к системе |
|---|---|---|
| 152-ФЗ «О персональных данных» | Все операторы, обрабатывающие ПДн | Обязательность системы управления ИБ (СУИБ), классификация информационных систем, конкретные меры защиты в зависимости от актуальности угроз, необходимость оценки эффективности. |
| 187-ФЗ «О безопасности КИИ» | Субъекты критической информационной инфраструктуры | Категорирование объектов КИИ, выполнение конкретных приказов ФСТЭК, сегментация сетей, подключение к системе ГосСОПКА для обмена данными об угрозах. |
| Требования ФСТЭК России (серия приказов) | Госорганы, КИИ, защищаемые информационные системы | Детальные технические спецификации: классы защищённости, требования к СВТ, ЗИ, противодействию НСД. Фактически, это готовый каталог требований для соответствующих систем. |
| Отраслевые стандарты (ПБ, ГОСТ Р 57580) | Банки, телеком, энергетика и др. | Специфические для отрасли меры: защита транзакций, резервирование каналов связи, особые режимы мониторинга. |
Статический подход vs Жизненный цикл
Главная дилемма: считать требования фиксированными на этапе внедрения или заложить механизм их постоянной актуализации.
| Статический подход («настроил и забыл») | Подход на основе жизненного цикла (continuous compliance) |
|---|---|
|
|
Важно: Подход на основе жизненного цикла не отменяет тщательного проектирования. Напротив, он требует, чтобы изначальная архитектура системы допускала возможность лёгкого аудита, обновления и масштабирования мер защиты.
Практический пример: от бизнес-цели к требованию ИБ
Рассмотрим, как абстрактная бизнес-цель превращается в конкретные, проверяемые требования. Пример для компании, обрабатывающей ПДн.
| Бизнес-цель / Регуляторное требование | Конкретное, измеримое требование к ИБ | Как проверить выполнение |
|---|---|---|
| Обеспечить конфиденциальность ПДн клиентов (требование 152-ФЗ). | Все базы данных, содержащие ПДн, должны шифроваться на уровне хранилища с использованием алгоритма AES-256. Ключи шифрования хранятся отдельно от данных, доступ к ним имеют только уполномоченные администраторы. | Аудит конфигурации СУБД, проверка журналов доступа к менеджеру ключей. |
| Минимизировать ущерб от действий инсайдера. | Во всех информационных системах с доступом к коммерческой тайне внедрена система контроля действий привилегированных пользователей (PAM). Все сессии записываются, а аномальные действия (массовое копирование, доступ в нерабочее время) блокируются и генерируют инцидент в SIEM. | Тестовый запуск сценария аномальных действий, проверка наличия алертов и записей сессий. |
| Обеспечить соответствие приказу ФСТЭК №239 для системы 1-го класса защищённости. | Межсетевой экран настроен с политикой «запрещено всё, что не разрешено явно». Ежеквартально проводится анализ правил и удаление устаревших. Все изменения в правилах проходят утверждение по регламенту Change Management. | Аудит конфигурации МСЭ, проверка журналов согласования изменений за квартал. |
Типичные ошибки при формулировании требований
Эти ошибки делают требования бесполезными для практического применения и аудита.
Неправильно (абстрактно, неизмеримо)
- «Обеспечить высокий уровень безопасности» — неясно, что это значит.
- «Защититься от хакеров» — неконкретно.
- Список технологий («внедрить DLP») без описания, что именно должна контролировать эта система и как.
- Требования скопированы из чужой политики без адаптации к своим процессам.
- Нет критерия успешности: как понять, что требование выполнено?
Правильно (конкретно, измеримо, привязано к активу)
- «Внешний доступ к панели администрирования веб-приложения возможен только через VPN с обязательной MFA».
- «Еженедельно выполняется проверка на отсутствие учётных записей бывших сотрудников во всех доменных службах. Срок деактивации — не позднее рабочего дня после увольнения».
- «Все рабочие станции в бухгалтерии оснащены СЗИ от НСД 1-го класса по руководящему документу ФСТЭК. Пропускная способность USB-портов ограничена до скорости, недостаточной для быстрого копирования больших объёмов данных».
- Требования согласованы с владельцами бизнес-процессов и не противоречат друг другу.
Чек-лист: проверка качества требований
Прежде чем утверждать документ с требованиями, проверьте его по этому списку.
- ☐ Каждое требование привязано к конкретному бизнес-процессу или информационному активу.
- ☐ Учтены все применимые нормативные акты (152-ФЗ, отраслевые стандарты, приказы ФСТЭК).
- ☐ Для критичных активов проведён анализ угроз, и требования являются ответом на выявленные риски.
- ☐ Требования измеримы и верифицируемы (есть чёткий способ проверки).
- ☐ Покрыты организационные, технические и кадровые аспекты.
- ☐ Для каждого требования определены ответственный за выполнение и сроки.
- ☐ Учтена необходимость поддержки требований на протяжении всего жизненного цикла системы (планы обновлений, аудита).
- ☐ Отсутствуют внутренние противоречия (например, требование о шифровании трафика противоречит требованию о его глубоком анализе без расшифровки).
- ☐ Требования согласованы со всеми ключевыми стейкхолдерами: бизнес-владельцами, разработкой, эксплуатацией, юристами.
Ключевые выводы
Формирование требований — это основной процесс, определяющий, будет ли система безопасности эффективной или останется дорогой формальностью.
- Требования — это переводчик. Они переводят язык законов и бизнес-рисков на язык технических спецификаций и должностных инструкций.
- Конкретность — главное свойство. Требование, которое нельзя проверить, бесполезно. Вместо «шифровать данные» должно быть «шифровать поле “паспортные данные” в БД “Клиенты” алгоритмом GOST 28147-89 в режиме гаммирования».
- Без организационной основы техника не работает. Самый совершенный DLP обойдёт сотрудник, если нет регламента, запрещающего это, и ответственности за его нарушение.
- Нормативы — обязательный минимум, а не потолок. Требования 152-ФЗ — это база. Реальные требования должны быть строже, если этого требует оценка рисков для конкретного бизнеса.
- Требования живут и меняются. Подход, основанный на жизненном цикле, когда требования регулярно пересматриваются, — единственный способ поддерживать актуальную защиту в меняющейся среде угроз и инфраструктуры.