Планы ФСТЭК на 2025-й год

Все материалы конференции выложены на сайте мероприятия. Там же есть материалы и других конференций, прошедших в рамках ТБ-Форума, — по ИБ АСУ ТП, по безопасной разработке и т.п.

Итак, что мне запомнилось из презентаций представителей ФСТЭК (Виталия Сергеевича Лютикова , Ирины Сергеевны Гефнер, Дмитрия Николаевича Шевцова и Елены Борисовны Торбенко) и какие рекомендации можно дать:

Усиление требований к защите информации – подготовка к новым стандартам

• С 1 марта 2026 года вступают (в случае принятия) в силу новые требования по защите информации в государственных информационных системах и иных ИС госорганов (на замену 17-му приказу), про которые была выступление Ирины Сергеевны Гефнер. Я этот проект у себя в Telegram-канале разбирал.
• Владельцам ИС необходимо заранее оценить соответствие своих систем новым требованиям, провести аудит существующих мер защиты и спланировать доработки, так как там много нововведений по сравнению с действующей редакцией 17-го приказа.

Новый приказ будет распространяться не только на государственные ИС, но и на иные системы госорганов, ГУПов и госучреждений, то есть число субъектов, попадающих под действие требований ФСТЭК сильно возрастет.

• Особое внимание следует уделить соответствию требованиям безопасности при передаче данных между системами, так как по требованию законодательства, если из ГИС передается информация ограниченного доступа в другие системы, принимающая система должна соответствовать новым требованиям.

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

Сертификация и использование только проверенных средств защиты

• Ужесточается (в случае принятия) административная ответственность за использование несертифицированных информационных систем и средств защиты информации, там где эта сертификация обязательна. Увеличен также срок давности по статье 13.12 КоАП. Я про этот законопроект писал у себя в Telegram-канале.
• Штрафы за использование несертифицированных средств защиты информации и несоблюдение требований безопасности многократно увеличены (например, штрафы для юридических лиц возросли до 100 тыс. рублей).
• Как минимум государственным организациям, а также тем, на кого госы распространяют свои требования, необходимо убедиться, что все используемые СЗИ имеют актуальные сертификаты, список которых можно посмотреть в реестре ФСТЭК.
• Владельцы систем должны провести инвентаризацию используемых средств защиты и заменить несертифицированные решения. Важно провести анализ рисков и заложить в бюджет затраты на соответствие новым требованиям, чтобы избежать финансовых потерь от возможных санкций. Или принять на себя риски несоответствия.

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

• Будут введены обновленные требования к средствам защиты информации, включая антивирусы, межсетевые экраны (обычные, не NGFW), а также новые требования к системам EDR и решениям по контролю привилегированных учетных записей (PAM). Об этом подробнее рассказывал в своей презентации Дмитрий Николаевич Шевцов.
• Владельцы ИС стоит пересмотреть список используемых средств защиты и при необходимости заменить устаревшие на решения, соответствующие новым стандартам. Ну а что касается EDR и PAM, то их просто надо будет предусмотреть при бюджетировании на 2026-й год.

Кстати, обратите внимание на систему добровольной сертификации КИИ-СЕРТ, которую создает Гринатом.

• Теперь сертификация охватывает весь процесс разработки ПО, включая анализ исходного кода, моделирование угроз, проверку уязвимостей и даже сертификацию сертификаторов. Например, ФСТЭК установила требования к аттестации работников органов по сертификации и испытательных лабораторий в форме тестирования и решения практических задач (10% специалистов аттестацию не прошло).

• В январе ФСТЭК выпустила информационные сообщения относительно усиления требований к средствам защиты, которые включают в себя контейнеры, интерпретаторы, веб-сервера и сервера приложений. Также с января ФСТЭК стала требовать от разработчиков средств защиты реализации мер по повышению защищенности инфраструктуры разработки СЗИ (MFA, сегментация, сканирование на уязвимости, локальные репозитории).

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

• Программные компоненты с открытым кодом теперь должны проходить сертификационные испытания, а владельцам ИС стоит требовать у поставщиков ПО и СЗИ Software Bill of Materials (SBOM) с корректным перечнем всех используемых компонентов как это делает сама ФСТЭК в соответствие с порядком испытаний и поддержки безопасности средств защиты информации, в состав которых входят заимствованные программные компоненты с открытым исходным кодом, утвержденным ФСТЭК в сентябре 2024 года.

Обязательная многофакторная аутентификация и защита привилегированных пользователей

• В ходе проверок ФСТЭК выявлено, что многие организации не используют MFA для привилегированных учетных записей.
• Владельцам ИС необходимо внедрить многофакторную аутентификацию и повысить уровень контроля за привилегированными пользователями. Для решений класса PAM ФСТЭК как раз готовит руководящий документ для сертификации.

Многие эксперты в Telegram пишут, что странно указывать на отсутствие MFA как недостаток, если в том же 17-м приказе нет такого требования. Как по мне, так это не странно. 17-й приказ все-таки был принят давно, а стоит смотреть не только на букву, но и дух приказа. А при моделировании угроз стоило бы обратить внимание, что многие инциденты реализуются именно по причине отсутствия многофакторной аутентификации. Ну и не забываем про методичку к 17-му приказу и меры усиления, которые намекают на MFA.

Предположу, что и в другие приказы регулятора войдет требование обязательной MFA хотя бы для привилегированных пользователей. Хотя я бы и на всех остальных его распространил, но дифференцировал по типу и критичности защищаемых систем. Правда, последнее сложно реализовать в концепции любого из приказов ФСТЭК — там системы не дифференцированы.

Централизованный мониторинг и реагирование на инциденты

ФСТЭК отмечает отсутствие планов реагирования на инциденты и отсутствие централизованного мониторинга событий безопасности, что и приводит к тому, что в течение длительного времени компании не замечают в своей инфраструктуре злоумышленников, а когда обнаруживают, то не знают, что делать.

В новом приказе, который придет на смену 17-му приказу, требованию наличия централизованного мониторинга ИБ найдется достойное место. Так что если у вас нет SIEM, стоит начать присматриваться к этому классу решений.

Стоит отметить, что до сих у нас отсутствуют требования к этому классу решений, что связано с отсутствием четкой позиции между ФСТЭК и ФСБ по поводу того, кто отвечает за этот класс ИБ-решений.

Усиление требований к оценке защищенности объектов информатизации

• В ходе аттестации объектов информатизации ФСТЭК выявила типовые недостатки:
  • Не проводится анализ уязвимостей, даже критических, несмотря на наличие соответствующей методики регулятора. В ходе проверок 100 государственных ИС согласно ПП-860 выявлено более 1250 уязвимостей, включая критические; как правило на уровне прикладного ПО.
  • Отсутствует функциональное тестирование средств защиты (продукты покупаются по рекламным листовкам, а не реальной проверке возможностей ИБ-решений).
  • Не тестируются методы обхода систем защиты с помощью пентестов, решений класса BAS, кибериспытаний и иных методов оценки защищенности.
  • Используются несертифицированные средства защиты.

Минцифры подготовило проект нового Постановления Правительства «О проведении эксперимента по повышению уровня защищенности государственных информационных систем федеральных органов исполнительной власти и подведомственных им учреждений», которое, по сути, является реинкарнацией ПП-860.

• Владельцам ИС необходимо провести ревизию своих систем ИБ и устранить выявленные типовые ошибки, чтобы при прохождении аттестации не наступать на эти грабли.

Не имеет отношения к конференции ФСТЭК, но нельзя не упомянуть, что Советом Федерации был разработан законопроект, вводящий в российское законодательство отношения в сфере деятельности по поиску уязвимостей и оценке уровня защищенности объектов (bug bounty) информационной инфраструктуры Российской Федерации, устанавливает права и обязанности участников этих отношений и определяет основы государственного регулирования указанной деятельности. И это тоже может стать частью системы оценки защищенности отечественных организаций.

• Чтобы улучшить процесс аттестации, который критикуется многими специалистами, считающими этот способ оценки защищенности бессмысленной тратой ресурсов, ФСТЭК в этом году планирует выпустить 3 новых методических документа:
  • Методику испытаний систем защиты информации информационных систем путем осуществления тестирования ее функций безопасности (функционального тестирования)
  • Методику анализа уязвимостей в информационных системах
  • Методику испытаний систем защиты информации информационных систем путем тестирования на проникновение.
• В новых требованиях ФСТЭК, которые придут на смену 17-му приказу, будут установлены правила устранения уязвимостей из ранее принятой методики:

  • Критические уязвимости должны устраняться в течение 24 часов.

  • Уязвимости высокой степени опасности – в течение 7 дней.

Без выстроенного процесса управления уязвимостями эту задачу не решить!

Также ФСТЭК планирует к середине следующего года существенно обновить функционал Банка данных угроз (БДУ):

• Предоставление авторизованного доступа разработчикам СЗИ и ПО, а также исследователям УБИ.
• Получение информации об уязвимостях ПО посредством API-взаимодействия.
• Возможность публикации сведений об уязвимостях ПО экспертным сообществом.
• Непрерывная публикация сведений об уязвимостях ПО.
• Возможность обмена информацией в реальном времени посредством чата.

Требования по ИБ при взаимодействии с подрядчиками

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

Мне кажется, это первый документ в России, где устанавливают требования по безопасности подрядчиков, хотя именно через них российские организации чаще всего и ломают последние почти 3 года. Но лучше поздно, чем никогда.

Усиление требований к безопасной разработке ПО

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

Организациям, разрабатывающим ПО для госструктур, рекомендуется пересмотреть процессы разработки, внедрить методологии безопасной разработки и провести сертификацию своих процессов согласно порядка сертификации процессов разработки безопасного программного обеспечения средств защиты информации, утвержденного приказом ФСТЭК России от 1 декабря 2023 г. №240 (его, кстати, будут в этом году снова менять).

Минцифры также подготовило в конце прошлого года проект изменений в правила ведения реестра отечественного ПО, в которых предусмотрено, что с 1-го января 2026 для СЗИ, стремящихся в реестр, необходимо подтверждать наличие процедуры устранения ошибок и уязвимостей.

Готовность к проверкам со стороны регуляторов

• Вводится новая методика оценки показателя состояния защиты информации и обеспечения безопасности объектов критической инфраструктуры, которая уже апробирована на 170 организациях, из которых только 13% достигли минимального базового уровня. Уровень остальных 87% находится ниже плинтуса.
• Владельцам ИС следует провести внутреннюю проверку на соответствие этой методике, чтобы понимать, на что обращает внимание регулятор и чтобы избежать санкций со стороны регулятора.

Согласно новой редакции «17-го приказа» все подопечные ФСТЭК должны будут регулярно оповещать регулятора о своем состоянии защиты по этой методике.

Заключение

Владельцы информационных систем должны уже сейчас начать подготовку к новым требованиям, так как:

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

В целом хочется отметить, что ФСТЭК прям сфокусировалась на вопросах оценки защищенности информационных систем и программного обеспечения, подмяв под себя тему проактивной ИБ и «отдав» тему реактивную (реагирование на инциденты) второму главному регулятору.

ЗЫ. Также, согласно выписке из Плана разработки Федеральной службой по техническому и экспортному контролю нормативных правовых актов на 2025 год регулятор планирует в этом году не только принять новый приказ на замену 17-му, но и обновить 239-й и 236-й приказы по КИИ (думаю, по аналогии с новым 17-м все будет), а также 240-й по порядку проведения сертификации процессов безопасной разработки программного обеспечения средств защиты информации.