На портале правовой информации опубликован приказ ФСБ от 11.05.2023 № 213 «Об утверждении порядка осуществления мониторинга защищенности информационных ресурсов, принадлежащих федеральным органам исполнительной власти, высшим исполнительным органам государственной власти субъектов Российской Федерации, государственным фондам, государственным корпорациям (компаниям), иным организациям, созданным на основании федеральных законов, стратегическим предприятиям, стратегическим акционерным обществам и системообразующим организациям российской экономики, юридическим лицам, являющимся субъектами критической информационной инфраструктуры Российской Федерации либо используемых ими», разработанный во исполнение подпункта в) пункта 5 Указа 250 .
Что требует приказ?
Согласно данному приказу:
- Мониторингом защищенности занимается 8-м Центром ФСБ.
Именно 8-й Центр. Не НКЦКИ, не ГосСОПКА. Разговоры о том, что 8ка может привлечь для этих целей кого-то из внешних компаний не состоятельны — приказ не допускает такой возможности. В приказе еще говорится о территориальных органах безопасности, но имеют ли они такие компетенции?
- Мониторинг осуществляется только в отношении периметра организаций, попадающих под действие Указа 250.
Не думаю, что оценивать будут все 500+ тысяч организаций. И даже 100 тысяч врядли. Скорее всего сфокусируются на самых критичных, владеющими значимыми объектами КИИ.
- Все попавшие под действие приказа организации должны отправить в ФСБ информацию о свою доменах, внешних IP, а также об их изменении (по мере изменения и добавления).
На каком основании 500+ тысяч организаций, попавших под 250-й Указ должны отправлять данные в ФСБ и откуда они об этом узнают, не совсем понятно. Не могу сказать, что это какое-то сложное для попавших под Указ требование (хотя не все знают о своем периметре все, что требуется), но вот процедурно это выглядит пока не очень понятно. Я бы форму какую-нибудь замутил для этого, чтобы автоматизировать было проще задачу. А так все направят кто во что гораздо эти данные, а потом иди, разгребай. И если с субъектами КИИ все более или менее понятно (хотя они взаимодействуют не с 8-м Центром, а с НКЦКИ), то что делать остальным?
- Мониторинг осуществляется непрерывно и заключается в выявлении публично доступных сервисов, уязвимостей и оценки защищенности организаций.
К слову «непрерывно» все-таки надо относиться скептически. Скорее всего проверки будут проходить через некоторые интервалы времени. Все-таки речь не о мониторинге ИБ, а о мониторинге защищенности.
- Блокировать сканирование запрещено.
Это, конечно, интересно. А если у меня PT WAF и NGFW на периметре автоматически блокируют такие попытки? Это будет рассматриваться как воспрепятствование работе ФСБ? А я же не знаю, что меня именно ФСБ сканирует (об этом ниже). А если я отключу средства защиты на время сканирования, то я тем самым снижу свою защищенности ради ее оценки со стороны регулятора. Или все-таки регулятор будет указывать адреса, с которых он будет проводить сканирование? А если я отключаю блокирование сканирования, то я тем самым демонстрирую неспособность противостоять угрозам, а это приводит к указанию от ФСБ (см.ниже).
- Оценка защищенности осуществляется без предупреждения со стороны ФСБ.
Интересно, что для сканируемой организации такая оценка защищенности будет выглядеть как инцидент. Мы же помним, что согласно требованиям ФСБ сканирование информационного ресурса, а также попытки эксплуатации уязвимостей относятся к инцидентам, о которых надо сообщать в ГосСОПКУ. Может быть ФСБ таким образом хочет проверить, насколько выстроен процесс мониторинга инцидентов в компаниях, сравнивая тех, кого сканировали, с теми, кто об этом сообщил? Главное, чтобы в процессе сканирования не были выведены из строя информационные ресурсы, а то это уже статья 274.1 и субъект КИИ имеет полное право обратиться в суд. Неудобно получится, если в рамках расследования выяснится, что вред объекту КИИ был нанесен теми, кто призван защищать КИИ.
- Оценка защищенности осуществляется на основании плана, утверждаемого начальником 8-го Центра ФСБ. Выписки из них направляются тем, кого будут оценивать. Уведомление за 2 недели до начала оценки защищенности. В нем указывается дата начала и дата окончания сканирования (а IP-адреса, с которых оно будет)?
План, как обычно непубличный. И составляться будет, похоже, один раз в год (раз в приказе он назван ежегодным). Если меня предупреждают за 2 недели до начала оценки защищенности (п.12), то зачем тогда писать, что сканирование без предупреждения (п.10)?
- Если в результате оценки защищенности ресурсы организации выходят из строя, об этом надо сообщить в порядке, определенном приказом.
Сообщить о выходе сканируемого ресурса из строя в ФСБ надо письменно в течение двух часов. Только как поймешь — это тебя DDoSили и сайт упал или это тебя 8ка проверяла и сайт упал из-за корявого конфига, невынесшего проверки (тебя же не предупреждают о проверке)?
- Если по результатам оценки защищенности выявляется неспособность ресурсов организации противостоять угрозам ИБ, ФСБ выдает указание по обеспечению защищенности информационных ресурсов.
Интересно каков статус этих указаний (даже не рекомендаций)? Как оно соотносится с требованиями ФСТЭК по защите ГИС/ИСПДн/ЗОКИИ/АСУ ТП/ИСОПК? И какова ответственность за игнор или нарушение как этого указания, так и вообще приказа?
- С одной стороны выявление уязвимостей осуществляется удаленно (п.10 приказа), а с другой (п.13) — возможно применение программно-аппаратных комплексов ФСБ, подключаемых к анализируемым информационным ресурсам. Причем подключение может быть удаленным или на объекте анализируемой организации.
Что это за ПАКи? Что они делают? Что собирают? Пока никакой информации об этих «черных ящиках» и порядке их применения. Возможно, это решения класса NTA или СОВ/СОА?
А почему мониторинг защищенности?
Тут, конечно, вновь всплывает история взаимоотношений между нашими регуляторами в области ИБ. Исторически, вопросами контроля (анализа) защищенности у нас занималась и занимается ФСТЭК. Это требование прописано, начиная с 17-го приказа по защите ГИС, и дальше оно попало во все нормативные акты регулятора. ФСТЭК вообще в последнее очень активно занимается именно оценкой защищенности. На днях, вон, они утвердили «Руководство по организации процесса управления уязвимостями в органе (организации)». То есть я бы рассматривал именно ФСТЭК как основного регулятора в сфере установления требований по оценке защищенности. Но…
Одно дело устанавливать требования и совсем другое — контролировать, чтобы эти требования реализовывались и чтобы у заказчиков реально снижалось число уязвимостей в системах, что приводило бы к росту уровня защищенности. И вот эту тему недавно подхватило Минцифры, которое в 250-м Указе сначала потребовало оценить реальную защищенность 72 крупных компаний, потом внесла аналогичное требование в 860-е Постановление Правительство. И даже разработало и выложило на сайт типовое техническое задание на выполнение работ по оценке уровня защищенности информационной инфраструктуры. Потом Минцифры показало всем пример, разместив портал госуслуг и ЕСИА на платформах багбаунти. Правда, пока на этом и остановилось, — включать требование о багбаунти в ПП-676 Минцифры пока не планирует .
Но то, что пока делает Минцифры в публичной плоскости, — это история разовая или дискретная, но с большим периодом между оценками уровня защищенности. Нужно все-таки регулярно/непрерывно мониторить уровень защищенности организаций, выявлять у них хотя бы на периметре непатченные уязвимости и незакрытые и плохо настроенные сервисы. Делать это самостоятельно организации не особо и хотят; или не умеют, или говорят, что проблемы нет. Поэтому, чтобы не полагаться на сами компании, эту тему хотело оседлать Минцифры — на недавнем CISO Forum директор Департамента кибербезопасности Минцифры Владимир Бенгин как раз упоминал о «русском Шодане», который будет сканировать российское адресное пространство в поисках уязвимых ресурсов. И такой «русский Шодан» появился — о нем говорили на PHDays. Компания CyberOK разработала сканер Rooster, который и должен был выполнять эту задачу — искать уязвимости на периметре, выявлять некорректно настроенные сервисы и т.п.
Но так как на ГосСОПКУ у нас возложена по законодательству задача мониторинга защищенности, то логично, что и ФСБ подключалась к данной задаче и вот мы видим результат — новый приказ, которые говорит как раз не об установлении требований по анализу защищенности, не по разовой проверке, а по непрерывному мониторингу. При этом ФСБ не будет ждать данных от самих организаций, а будет по своей инициативе и без предупреждения их «зондировать».
Получается, что три регулятора в данном случае не противоречат и не конфликтуют друг с другом, а дополняют. Если вы не хотите указаний от ФСБ за низкую защищенность, следуйте рекомендациям ФСТЭК. Хотите получать бюджетные средства от Минцифры — будьте добры следовать практикам регулятора по цифровизации. Все вроде логично. Хотя сами регуляторы могут так и не считать; каждый из них хотел бы быть самым главным по анализу защищенности. Но пока у нас трехглавый дракон. Главное, чтобы он умел парить, а не по земле ползать, и руки у него были достаточно длинные 🙂
Что делать?
Закономерный вопрос. Коль скоро регуляторы серьезно взялись за анализ защищенности, то стоит сделать две вещи:
- Оценить ваш текущий процесс управления уязвимостями. Для сравнения можете посмотреть на результаты исследования этого вопроса в российских компаниях в 2020-м и 2022-м годах (см.ниже).
- Провести анализ защищенности до того, как вас проверят ФСБ, ФСТЭК и Минцифры. Можно использовать, как минимум, сканеры безопасности или решения класса BAS, а можно заказать пентест.
- Сделать так, чтобы анализ защищенности не показывал плачевное состояние вашего периметра (как минимум). То есть обновление и безопасная настройка web-сайта и периметрового сетевого оборудования, установка WAF и NGFW на периметре и вот это вот все.
- Выстроить процесс управления уязвимостями в организации.
Думаю, многие из поднятых в заметке вопросов к приказу ФСБ, будут сняты в процессе правоприменения.
Резюмируя
Год назад я написал заметку про уроки кибервойны и то, что несмотря на начало спецоперации в том числе и в киберпространстве, регуляторы у нас живут как в прошлом веке. Пора признать, что ситуация сдвинулась с мертвой точки и безопасность у нас все больше становится практической, а не бумажной. Да, не все регуляторы могут этим похвастаться. Да, от бумажных обязательных требований пока не отказываются. Но движение в сторону практического кибербеза налицо. Речь все чаще идет не о мерах защиты, а о процессах их реализации. Осталось представителям регуляторов на местах это осознать и самим заказчикам начать проактивно думать о своей безопасности. Пока за них не подумали ФСБ, ФСТЭК и Минцифры.
Полезные ссылки
- Как выстроен процесс управления уязвимостями в российских компаниях (2020 год)
- Как изменилась работа с уязвимостями в 2022 году
- Менеджмент уязвимостей: инструкция по применению
- CRR Supplemental Resource Guide. Volume 4. Vulnerability Management
- OWASP Vulnerability Management Guide
- NIST SP 800-40 Rev. 4. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology
- NIST SP 1800-31. Improving Enterprise Patching for General IT Systems: Utilizing Existing Tools and Performing Processes in Better Ways
- NIST SP 800-216. Recommendations for Federal Vulnerability Disclosure Guidelines
- SANS Vulnerability Management Maturity Model
- Трендовые уязвимости по версии CISA и по версии Positive Technologies, а также опасные уязвимости по версии ФСТЭК
