Регламент анализа защищённости ИСПДн

Когда систему только настраивали, скорее всего, проверили основные параметры безопасности: закрыли лишние порты, обновили программное обеспечение, ограничили права доступа. Проблема в том, что система не остаётся статичной — появляются новые версии программ с уязвимостями в старых, добавляются пользователи и интеграции, меняются настройки под текущие задачи.

Анализ защищённости — это не разовое мероприятие, а повторяющийся процесс, который отвечает на вопрос: соответствует ли фактическое состояние системы тому уровню защиты, который был выбран изначально. Мера входит в состав технических мер, обязанность применять которые вытекает из статьи 19 закона 152-ФЗ, и её конкретный объём зависит от уровня защищённости ИСПДн.

На практике анализ защищённости обычно охватывает несколько направлений:

• проверку наличия обновлений операционной системы и прикладного программного обеспечения, устраняющих известные уязвимости;
• проверку настроек сетевого оборудования и средств защиты на предмет отклонения от установленного порядка;
• инвентаризацию учётных записей на предмет неиспользуемых, тестовых или избыточных прав доступа;
• сканирование системы специализированными средствами для выявления известных уязвимостей — там, где это оправдано уровнем защищённости;
• проверку соответствия фактической конфигурации системы той, что зафиксирована в документации.

Для небольшой системы часть этих пунктов можно объединить в один короткий чек-лист, который заполняет ответственный сотрудник, а не проводить как отдельный сложный проект.

Единого календарного срока закон не устанавливает — периодичность определяет сам оператор, соотнося её с уровнем защищённости и динамикой изменений в системе. Система, которая меняется часто — регулярно добавляются пользователи, интеграции, обновления, — требует более частого анализа, чем стабильная система с редкими изменениями.

Регламент должен явно называть оба основания: плановую периодичность и события, которые запускают внеплановую проверку. Стоит заранее решить, кто именно фиксирует факт проведения проверки и куда попадает результат — не оставлять это на усмотрение того, кто вспомнит об этом первым. Без такой фиксации трудно доказать регулятору, что проверки проводятся регулярно, а не только тогда, когда об этом вспомнили.

Проверка без порядка устранения находок теряет смысл — уязвимость, зафиксированную в отчёте и оставленную без действий, легче найти при разборе инцидента, чем оправдать перед регулятором. Регламент должен задавать сроки устранения в зависимости от критичности найденного: критичные уязвимости, дающие прямой доступ к персональным данным, закрываются в первую очередь и в короткий срок, менее значимые — по плану.

Полезно вести простой реестр находок: что обнаружено, когда, кто устраняет, в какой срок, статус закрытия. Такой реестр, даже в виде обычной таблицы, наглядно показывает и самой компании, и проверяющему, что анализ защищённости — это реальный процесс, а не разовая формальность.

Привлекать стороннюю организацию для регулярного анализа защищённости обязательно не для всех систем — это оправдано для высокого уровня защищённости и сложной инфраструктуры. Для небольшой компании с одной облачной системой анализ защищённости может проводить тот же сотрудник, что администрирует систему, если он способен выполнить базовые проверки: обновления, права доступа, настройки.

Важно избегать ситуации, когда анализ защищённости проверяет сам себя — если один и тот же человек и настраивает систему, и оценивает её защищённость, полезно хотя бы раз в год привлекать независимый взгляд, будь то коллега из другого подразделения или внешний специалист, чтобы не пропустить системные слепые зоны.

Ещё один практичный шаг — включить в регламент минимальный список бесплатных или встроенных инструментов, которыми ответственный сотрудник может воспользоваться самостоятельно: штатные средства проверки обновлений операционной системы, стандартные отчёты облачного провайдера о состоянии безопасности аккаунта, простые сканеры для проверки открытых портов. Это снижает зависимость от дорогих специализированных решений там, где уровень защищённости системы этого прямо не требует.