Архив метки: КИИ

У Елены Борисовны Торбенко, начальника управления ФСТЭК, был сегодня интересный доклад на Инфофоруме

Добавить комментарий

У Елены Борисовны Торбенко, начальника управления ФСТЭК, был сегодня интересный доклад на Инфофоруме

У Елены Борисовны Торбенко, начальника управления ФСТЭК, был сегодня интересный доклад на Инфофоруме. В 2025 году было проверено более 700 значимых объектов КИИ, выявлено 1200 нарушений и недостатков обеспечения безопасности, из которых 80% являются типовыми. Заведено >600 дел по 13.12.1 и 19.7.15 КоАП.

Среди типовых недостатков указали "непроведение мероприятий по выявлению и анализу уязвимостей на значимых объектах КИИ, наличие уязвимого ПО на значимых объектах КИИ".

Имхо, формулировать это в терминах VM-процесса (нарушение сроков по детектированию, SLA на устранение и т.п.) было бы лучше, но внимание к теме в любом случае радует. 👍😇

Отдельно подчеркнули VM-ные проблемы:

🔻 Отсутствие процесса инвентаризации сведений о ЗОКИИ → лишнее ПО, создающее угрозы ИБ.
🔻 Использование зарубежного ПО без поддержки вендором.
🔻 Недооценка уязвимостей в соответствии с руководством ФСТЭК по организации VM-процесса.
🔻 Низкая периодичность выявления уязвимостей ("1 раз в год").

В самом конце прошлого года, 30 декабря, был опубликован приказ ФСБ № 554 от 26 декабря, устанавливающий требования к средствам противодействия компьютерным атакам (КА) на КИИ, среди которых есть средства предупреждения КА - фактически средства Непрерывного Управления Экспозициями с Учётом Угроз (CTEM)

Добавить комментарий

В самом конце прошлого года, 30 декабря, был опубликован приказ ФСБ № 554 от 26 декабря, устанавливающий требования к средствам противодействия компьютерным атакам (КА) на КИИ, среди которых есть средства предупреждения КА - фактически средства Непрерывного Управления Экспозициями с Учётом Угроз (CTEM)

В самом конце прошлого года, 30 декабря, был опубликован приказ ФСБ № 554 от 26 декабря, устанавливающий требования к средствам противодействия компьютерным атакам (КА) на КИИ, среди которых есть средства предупреждения КА - фактически средства Непрерывного Управления Экспозициями с Учётом Угроз (CTEM). По сравнению с приказом № 196 (06.05.2019), требования стали яснее и лаконичнее. 👍

Решение должно реализовывать (п.13) "сбор и обработку сведений об уязвимостях и недостатках в настройке ПО, а также справочной информации", обработку этой информации и формирование рекомендаций по минимизации угроз.

Помимо уязвимостей и мисконфигов необходимо собирать (п.14) инфу об инструментах атак, тактиках и техниках, малварях, IOC-и, репутацию IP/доменов/адресов email, C&C и ботнетах и т.д. Все сведения должны (п.15) агрегироваться, коррелироваться и визуализироваться в форме графов.

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

Раньше в положении о НКЦКИ не было ничего про уязвимости - а теперь будет!

Добавить комментарий

Раньше в положении о НКЦКИ не было ничего про уязвимости - а теперь будет!

Раньше в положении о НКЦКИ не было ничего про уязвимости - а теперь будет! Был опубликован приказ ФСБ России от 24.12.2025 № 540 «О внесении изменений в Положение о Национальном координационном центре по компьютерным инцидентам, утвержденное приказом ФСБ России от 24 июля 2018 г. № 366».

Среди прочего, он добавляет такой пункт:

"5. В целях выполнения предусмотренных настоящим Положением задачи и функций НКЦКИ в пределах своей компетенции имеет право:
…
5.9. Запрашивать для выполнения задачи и осуществления функций НКЦКИ у субъектов критической информационной инфраструктуры, центров ГосСОПКА и органов (организаций) результаты проведенных мероприятий, направленных на защиту от компьютерных атак в отношении принадлежащих им информационных ресурсов Российской Федерации, а также информацию об устранении уязвимостей информационных ресурсов Российской Федерации."

Похоже, планируют стимулировать устранение уязвимостей, и это не может не радовать. 🙂👍

Не пора ли создать систему государственного мониторинга инфраструктуры (активов и уязвимостей) аналогичную CISA BOD 23-01? Продолжу размышления о необходимости российского Реестра Известных Эксплуатабельных Уязвимостей с конкретными дедлайнами по их устранению, аналога CISA KEV

Добавить комментарий

Не пора ли создать систему государственного мониторинга инфраструктуры (активов и уязвимостей) аналогичную CISA BOD 23-01? Продолжу размышления о необходимости российского Реестра Известных Эксплуатабельных Уязвимостей с конкретными дедлайнами по их устранению, аналога CISA KEV

Не пора ли создать систему государственного мониторинга инфраструктуры (активов и уязвимостей) аналогичную CISA BOD 23-01? Продолжу размышления о необходимости российского Реестра Известных Эксплуатабельных Уязвимостей с конкретными дедлайнами по их устранению, аналога CISA KEV. На это можно возразить: ну допустим, сроки устранения будут определены, как сделать так, чтобы в эти сроки укладывались? 🤔

Американцы решили эту проблему для инфраструктуры федеральных агентств с помощью системы, описанной в директиве CISA BOD 23-01. Я разбирал её года 1,5 назад. Она предусматривает

🔹 еженедельное обнаружение активов в инфраструктуре;

🔹 циклические двухнедельные сканы активов на уязвимости;

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

Это позволяет регулятору отслеживать актуальное состояние инфраструктуры органа/организации и оперативно проводить необходимые стимуляции. 🥕

Имхо, перенимать можно практически 1 в 1. 😉

Не пора ли создать российский аналог CISA KEV?

Добавить комментарий

Не пора ли создать российский аналог CISA KEV?

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

Можно, конечно, говорить, что пострадавшие организации сами виноваты. Им дали базу уязвимостей, методику оценки критичности уязвимостей, руководство по построению VM-процесса. Могли бы делать, как написано, и эксплуатабельные уязвимости устранялись бы. Или, как минимум, могли бы обращать внимание на трендовые уязвимости от PT. Но, похоже, организации не тянут это без директивной стимуляции. 🤷‍♂️

Как CISA ставит федеральным агентствам США чёткие дедлайны по устранению конкретных особо критичных уязвимостей, эксплуатация которых была подтверждена, так и наши регуляторы могли бы ставить аналогичные дедлайны. Хотя бы для организаций, на которые распространяется 117-й приказ и для КИИ.

Эффективная защита КИИ, часть 2

1 комментарий

Эффективная защита КИИ, часть 2Эффективная защита КИИ, часть 2

Эффективная защита КИИ, часть 2. Продолжение поста по итогам вебинара компании К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ».

Сложности с настройкой

🔹 Установка средств защиты и настройка ОС всегда несут риски отказа АСУ ТП. Рекомендуют делать резервное копирование критических данных перед началом пусконаладочных работ (обязательно!), создавать актуальные полные копии образов жестких дисков АРМ и серверов АСУ ТП вместе с загрузочными областями, заранее подумать о наборе ЗИП (особенно для АРМ-ов и серверов).

🔹 Трафик блокируется при передаче между КСПД (корпоративная сеть передачи данных) и ТСПД (технологическая сеть передачи данных) при установке МСЭ в разрыв. Рекомендуют взять паузу на выявление ранее неизвестных потоков трафика, проводить установку строго в рамках технологических окон, использовать правила Allow All для выявления всех ранее не указанных сетевых взаимодействий (поработать в режиме мониторинга).

🔹 После установки САВЗ (средства антивирусной защиты) нужно применить большое количество одинаковых настроек защитных компонентов на АРМ и серверах. Рекомендуют при настройке использовать конфигурационный файл.

🔹 После установки СЗИ не работает прикладное ПО АСУ ТП (существенное падение производительности ПО АСУ ТП, после обновления компонентов защиты на сервере занят весь объем оперативной памяти, после установки компонентов защиты не запускается ПО АСУ ТП). Рекомендуют создать стенды, полностью эмулирующие работу АСУ ТП, выполнить полнофункциональное тестирование совместимости, проводить обновление ПО АСУ ТП и средств защиты в разное время с фиксацией корректного функционирования.

Сложности с персоналом

🔹 На производственных площадках не знают о внедрении средств защиты в инфраструктуре. Рекомендуют сообщать в официальных письмах от центрального управления ИБ о необходимости назначить конкретных ответственных лиц за внедрение.

🔹 Персонал АСУ ТП опасается за его работоспособность после установки СЗИ и пытается всячески отдалить момент сдачи работ. Рекомендуют продемонстрировать работу средств защиты на некритичных АРМ и серверах АСУ ТП (хорошо работает метод). На практике покажите специалистам АСУ ТП, что установка средств защиты не несет в себе угрозы работоспособности.

🔹 Персонал АСУ ТП опасается, что в инфраструктуре будут найдены активные вирусные заражения. Рекомендуют сделать временную "ИБ-амнистию", т.е. анонсировать персоналу АСУ ТП отсутствие административных наказаний в случае обнаружения в АСУ ТП вредоносного ПО или активных вирусных заражений.

🔹 Внедрение антивирусной защиты — дополнительная нагрузка на персонал АСУ ТП в условиях дефицита технологических окон. Рекомендуют внедрять СЗИ вне технологических окон при их дефиците. Но при таком подходе важно, чтобы средства защиты не требовали перезагрузки после установки, СЗИ имели неинвазивный режим работы, не было риска остановки технического процесса при false-positive сработках.

Сложности с выбором подрядчика

🔹 Рекомендуют обращать внимание на готовность подрядчика оптимизировать подход к этапам проекта, квалификацию его команды, лицензии, состав услуг, коммуникации (например, готовы ли создать рабочую группу в мессенджере и решать вопросы оперативно). Крупным заказчикам рекомендую делить проекты по системам и площадкам.

Эффективная защита КИИ, часть 1

1 комментарий

Эффективная защита КИИ, часть 1Эффективная защита КИИ, часть 1

Эффективная защита КИИ, часть 1. Посмотрел вебинар компании К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ». В основном там было в контексте АСУ ТП, но проблемы вполне характерны и для более привычных сфер КИИ, таких как, банки или связь (все сферы приведены в 187 ФЗ пункт 2.8)

Что вообще нужно сделать по безопасности КИИ:

🔻 Идентифицировать субъекты КИИ и обеспечить безопасность объектов КИИ (187-ФЗ, уголовная ответственность, срок до 10 лет для должностных лиц).
🔻 Создать специальные отделы по защите информации и перестать использовать западные СЗИ до 1 января 2025 (Указ Президента № 250, штраф до 100 000 руб.)
🔻 Перейти на отечественное ПО для КИИ до 1 января 2025 (Указ Президента № 166)
🔻 Перейти на доверенные ПАК до 1 января 2030 согласно правилам перехода (Постановление Правительства РФ № 1912)

Как прогресс по работам? По исследованию К2 Кибербезопасность 90% компаний приступили к выполнению требований 187-ФЗ, но завершили проекты по защите КИИ только 8%. Каждая 5-ая компания не успеет реализовать проекты к 2025 году. 🤷‍♂️

Что по инцидентам? 65000 кибератак нa КИИ в 2023 году. Рост за год на 7%. Больше всего атак (28%) связаны с эксплуатацией уязвимостей инфраструктуры.

Дальше на вебинаре рассматривали разные сложности.

Сложности с интеграцией различных решений

🔹 Общий срок проектирования систем защиты очень сильно сокращается, если решения от одного вендора (из одной экосистемы), включая интеграцию с общими системами ИБ, например, SIEM.

Сложности при обследовании объектов КИИ

🔹 Данные об объектах устарели или были не полностью собраны при обследовании. Рекомендуют собрать информацию об объектах АСУ ТП, о смежных системах, о готовности инженерной инфраструктуры, уточнить отраслевую специфику, организовать встречи с представителями технического блока.

Сложности с инженерной инфраструктурой

🔹 Инфраструктура не готова к внедрению средств защиты: нужно проложить СКС (структурированная кабельная система), в шкафах нет места для оборудования средств защиты, не хватает питания и охлаждения для оборудования средств защиты. Рекомендуют обследовать инженерную инфраструктуру для размещения оборудования средств защиты и заложить в сметы необходимое оборудование на этапе техно-рабочего проектирования.

🔹 В АСУ ТП используются устаревшие АРМ и серверы. Хосты работают на пределе возможностей. Дополнительная нагрузка в виде средств защиты может снизить производительность и время отклика. Рекомендуют сделать гибкую настройку средств защиты: настроить только базовые функции защиты, а дополнительные — отключить. Устаревшее оборудование лучше, по возможности, заменить.

🔹 Трудно сегментировать сеть (корпоративная и технологическая сети физически находятся в одной плоской сети, нет межсетевых экранов и маршрутизаторов ИЛИ ЗОКИИ находятся в единой сети с другими системами АСУ ТП). Рекомендуют выполнить физическое разделение корпоративной и технологической сетей, провести сегментацию технологической сети с учетом категорирования АСУ ТП (инвентаризировать оборудования АСУ ТП и перепроектировать сети).

В следующей части будет про сложности с настройкой, с персоналом и выбором подрядчика.

Upd. Вторая (заключительная) часть