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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эффективная защита КИИ, часть 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. Вторая (заключительная) часть

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ. Частенько сталкиваюсь с позицией людей неИБшников, что обход требований и средств ИБ в организации это, в целом, нормальная практика и ничего зазорного в этом нет. Если есть права администратора на десктопе, то чего бы, допустим, не грохнуть агент DLP или EDR? А то ж работать мешает. 😏 Раз ИБшники активно не воспрепятствовали такому, значит они сами и виноваты.

В связи с этим в новостях пролетело интересное уголовное дело. Инженеру предприятия ВПК дали реальные 3 года общего режима по 274.1 УК РФ "Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации".

Цитата того, что он сделал:

"Установлено, что инженер, находясь по месту работы, имея умысел на копирование с целью дальнейшей модификации информации о ходе технологического процесса изготовления изделий на предприятии, нейтрализовал средство защиты компьютерной информации программно-технического комплекса, являющегося значимым объектом критической информационной инфраструктуры РФ"

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

Нафантазировать себе можно, например, следующее. В некоторой организации с некоторыми файлами можно работать только на некоторых десктопах. Копирование файлов с этих десктопов на флешку блокируются СЗИ. А некоторому инженеру очень нужно было скопировать и отредактировать какой-то файл на другом десктопе. Возможно, что никакой зловредной цели у него при этом не было. Возможно, что он наоборот всей душой радел за общее дело и хотел как лучше. Где-то что-то почитал про то, как и чем блокируется копирование на флешку, как это обходить. Поэкспериментировал - получилось, скопировал! Возможно даже сам похвастался кому-то на радостях. И заверте… 😱

Мораль? Не нарушайте требований ИБ в организации. Даже если глубоко презирайте ИБшников и считаете, что всё что они делают - мешают вам выполнять настоящую важную работу. Даже если вам неудобно. Неудобно? Жалуйтесь начальству! В крайнем случае увольняйтесь. Но никогда и ни в коем случае не делайте что-то втихаря. Это может очень плохо закончиться лично для вас. Особенно, если имеете дело с КИИ и ЗОКИИ.

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

11 июня в 11:00 пройдёт вебинар К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ»

11 июня в 11:00 пройдёт вебинар К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ»

11 июня в 11:00 пройдёт вебинар К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ».

О чем будут рассказывать:

👾 Актуальные угрозы для субъектов КИИ
🗿 Какие подводные камни могут возникнуть в ходе работ
🏃‍♂️ Грамотный выбор продуктов ускоряет реализацию проекта
🕵️‍♀️ На что стоит обратить внимание при выборе подрядчика.

Там будет не столько про «бумажную безопасность» (хотя куда ж мы без регуляторики и ответственности за невыполнение требований 😏), сколько про реальную защиту промышленных и бизнес-процессов.

Учитывая, что на иллюстрации еще и «уязвимости» есть, надеюсь, что особенностей Vulnerability Management-а для КИИ также коснутся. 😉

Выступать будет Егор Куликов, руководитель направления безопасности КИИ и АСУ ТП компании К2 Кибербезопасность.

➡️ Подробности и регистрации здесь.

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

На сайте ФСТЭК выложили финальную версию "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации"

На сайте ФСТЭК выложили финальную версию Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации

На сайте ФСТЭК выложили финальную версию "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что изменилось по сравнению с драфтом в части Управления Уязвимостями?

🔻 Поправили опечатку "их сети Интернет".
🔻 В обоих пунктах появилась приписка "или в отношении таких уязвимостей реализованы компенсирующие меры".

Понятно почему появилась приписка про компенсирующие меры - не всегда уязвимости можно исправить обновлением. Но есть опасность, что этим будут злоупотреблять, т.к. не указано какие меры можно считать компенсирующими. Возможно толкование, что компенсирующие меры могут выбираться произвольно. В духе "на десктопе есть EDR, значит все уязвимости на нём скомпенсированы". 🤪 Но даже если меры будут браться строго от вендора или из БДУ непонятно как контролировать, то что они были корректно применены, а главное, что эти меры действительно препятствуют эксплуатации уязвимости. На практике это будет выглядеть так: сканер детектирует уязвимости, а IT/ИБ с покерфейсом говорят "а у нас всё скомпенсировано". 😐 Так что моё мнение - без приписки было лучше, не нужно было создавать такую лазейку.

Также остался вопрос с "датой публикации обновления (компенсирующих мер по устранению)". Такой даты нет в БДУ (равно как и в других базах уязвимостей). Непонятно откуда её массово забирать, чтобы автоматически отслеживать, что организация укладывается в сроки. Вряд ли источник с датами появится, так что видимо на практике в VM-решениях будут использовать какую-то другую дату (например дату заведения уязвимости). А в случае инцидента это будет повод для лишних разбирательств. Имхо, зря это сразу не прояснили.

На эту же тему может быть интересная ситуация: допустим выходит обновление в котором вендор втихую исправляет уязвимость критического уровня опасности. А о существовании этой уязвимости становится известно, допустим, через полгода. В момент публикации данных об этой уязвимости у организации сразу получается просрочка. 🤷‍♂️ Просто потому, что используется дата, привязанная к обновлению, а не к уязвимости. Надумана ли такая ситуация? Да нет, "silent patches" проблема достаточно распространенная.

В этом, правда, есть и позитивный момент. Чтобы не попасть в такую ситуацию организации придётся выстраивать Patch Management процесс независящий от уязвимостей. И с неплохими требованиями регулярности обновлений: 30 дней для хостов на периметре, 90 дней для десктопов и серверов. 😏

PS: Также pdf-документ выпустили как-то странно, так что по нему не работает поиск. По odt-документу поиск работает нормально.

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации"

Вышел драфт Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что там с Управлением Уязвимостями?

Есть 2 показателя безопасности, зависящие от оперативности устранения уязвимостей:

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

🔸 3.3 "На пользовательских устройствах и серверах отсутствуют уязвимости критического уровня с датой публикации обновления (компенсирующих мер по устранению) более 90 дней (не менее 90% устройств и серверов)"

❓Во втором случае не указано откуда дату публикации обновления брать. Наверное нужно сделать единообразно.
❓"доступных их сети Интернет" - опечаточка, "из".

Из пунктов следует, что нужно:

🔻 покрывать все активы детектами уязвимостей
🔻 понимать какие именно активы опубликованы в Интернет
🔻 уметь оценивать критичность уязвимостей по методике ФСТЭК
🔻 отслеживать дату публикации обновления (а не дату публикации самой уязвимости!) в разных источниках 😲

Последнее выглядит как нетривиальная задача, т.к. общего реестра данных по обновлениям не наблюдается, получается ведение такого реестра и наполнение его ляжет на организацию. На практике, скорее всего, придется ориентироваться именно на дату публикации уязвимости, т.к. её гораздо проще определять (непосредственно в NVD/BDU) и, по идее, она должна быть всегда более ранней или равной дате публикации обновления. 🤔 Поэтому, возможно, имеет смысл подкрутить формулировочку, например на "дата публикации уязвимости или обновления (компенсирующих мер по устранению)". И сделать пометочку, что допустимо взять наибольшую из имеющихся дат.

И, в идеале, хотелось бы ещё видеть аналог CISA KEV с непосредственно указанными датами, когда конкретные уязвимости должны быть исправлены.

Ещё про импортозамещение, на этот раз для ЗОКИИ финансовых организаций

Ещё про импортозамещение, на этот раз для ЗОКИИ финансовых организаций

Ещё про импортозамещение, на этот раз для ЗОКИИ финансовых организаций. Федеральный закон от 13.06.2023 № 243-ФЗ "О внесении изменений в Федеральный закон "О Центральном банке Российской Федерации (Банке России)". Насколько я понял из текста, вводятся:

- согласование планов мероприятий по переходу на преимущественное использование российского ПО, аппаратных средств и услуг на значимых объектах КИИ и обязательство этот переход совершить
- согласование заявок на закупки иностранного ПО, аппаратных средств и услуг для значимых объектов КИИ

Пока выглядит относительно лайтово.