Дмитрий Карасовский: «Каждое существенное изменение требует оценки его влияния на безопасность»

2 часа назад

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

С 1 сентября 2026 года действует приказ ФСТЭК России № 137, который изменил требования приказа № 117 к защите государственных и ряда других информационных систем. Документ уточняет: выполнение плана защиты должно обеспечивать нормативное значение показателя защищенности. Самого факта проведения запланированных мероприятий для этого недостаточно.

О том, как выстроить постоянный контроль безопасности и подтвердить его результат, рассказал Дмитрий Карасовский, руководитель отдела по информационной безопасности Axiom JDK.

— Какие изменения внес приказ ФСТЭК России № 137 и на что организациям нужно обратить внимание в первую очередь?

Дмитрий Карасовский: Главное содержательное уточнение касается результата выполнения плана защиты. Он должен обеспечивать достижение нормативного значения показателя защищенности. То есть недостаточно отчитаться о выполнении запланированных мероприятий: необходимо подтвердить, что они дали требуемый результат.

Часть изменений начнет действовать с 1 марта 2027 года. Новая редакция пункта 32 предусматривает оценку защищенности не реже одного раза в полгода и направление результатов во ФСТЭК не позднее пяти рабочих дней после расчёта. Если показатель не соответствует нормативному значению, руководителя необходимо проинформировать в течение трех календарных дней после завершения оценки.

Для подрядчиков устанавливается оценка зрелости: до предоставления доступа к системам или информации либо передачи им информации, а затем не реже одного раза в два года.

При этом важно различать процедуры и учитывать сферу действия требований. Полугодовая оценка показателя защищенности и пентест — разные виды работ. Поэтому считать обязательным проведение пентеста каждые шесть месяцев было бы неверно. Отдельно нужно проверять применимость поправок к значимым объектам критической информационной инфраструктуры (КИИ).

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

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

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

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

Остановка переводов для банка означает недоступность финансовых услуг. Сбой касс или складской системы для ритейлера способен остановить продажи и поставки. Последствия для бизнеса должны определять очередность защитных мер.

— Почему аттестации недостаточно для поддержания безопасности системы?

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

Замена оборудования на аналогичное без изменения настроек и предоставление удаленного доступа подрядчику несут разные риски. Необходимость дополнительных испытаний или повторной аттестации определяется применимыми правилами и тем, как изменение влияет на условия защиты. Приказ № 137 не устанавливает обязанность переаттестовывать систему после любого обновления.

Проверить работу контроля изменений можно на конкретном недавнем примере. Кто оценивал безопасность обновления? Были ли проверены права доступа и новые подключения? Есть ли порядок восстановления при сбое? Ответы покажут, насколько последовательно выполняются предусмотренные процедуры и где требуется доработка.

— Какую роль в постоянном контроле играют анализ уязвимостей и пентесты?

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

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

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

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

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

— На что обратить внимание при работе с интеграторами, поставщиками ПО и другими подрядчиками?

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

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

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

— Как руководителю понять, что контроль безопасности действительно работает?

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

Устранение уязвимости следует подтверждать повторной проверкой и фиксировать её результаты. Дополнительно стоит отслеживать соблюдение сроков, число просроченных исправлений и причины задержек. Эти данные помогают руководителю понять, где не хватает ресурсов или требуется изменить порядок работ.

Если риски часто связаны с изменениями и доступами подрядчиков, имеет смысл измерять, какая доля изменений в критичных системах прошла проверку до запуска, насколько своевременно пересматриваются внешние доступы и отключаются ненужные учетные записи.

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

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

Ранее RUБЕЖ разбирал изменения в требованиях ФСТЭК к защите государственных информационных систем. Эксперты отмечали, что формальная аттестация не гарантирует устойчивость цифрового контура без регулярного контроля изменений, доступов и фактического уровня защищенности. Подробнее — в материале: «ФСТЭК обновила требования к защите ГИС: почему формальная аттестация не спасает от сбоев и киберрисков».