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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учёт эксплоитов в Vulristics: ошибка и переименование компонента

Учёт эксплоитов в Vulristics: ошибка и переименование компонентаУчёт эксплоитов в Vulristics: ошибка и переименование компонента

Учёт эксплоитов в Vulristics: ошибка и переименование компонента.

🔹 Обнаружил, что у меня где-то с апреля месяца была ошибка в Vulristics: уязвимости без эксплоитов получали значение не 0, а 0.5.🤦‍♂️ Как-то не обращал на это внимание и никто мне это не зарепортил. Сегодняшним коммитом поправил. Отчёты по Microsoft Patch Tuesday и Linux Patch Wednesday за апрель и май перегенерю. Это, конечно, не супер-критичная бага, но итоговый скор уязвимости искажала. Если используете Vulristics, то обратите внимание и обновитесь.

🔹 Заодно переименовал компонент "Public Exploit Exists" в более логичное "Exploit Exists". Он принимает значения:
1, если есть публичный эксплоит (ссылка или флаг в БДУ)
0, если вообще нет данных об эксплоите
от 0 до 1, если есть данные о приватном эксплоите/PoC-е

🔹Завёл Changelog, запустил версионирование (с версии 1.0.5) и добавил ключ "-v" или "--version". А то с 2020 года обходился без версий. Сапожник без сапог, VM-щик без версий. 😅🤷‍♂️

Уязвимость Remote Code Execution - PHP на Windows хостах (CVE-2024-4577) используется в атаках шифровальщиков

Уязвимость Remote Code Execution - PHP на Windows хостах (CVE-2024-4577) используется в атаках шифровальщиков

Уязвимость Remote Code Execution - PHP на Windows хостах (CVE-2024-4577) используется в атаках шифровальщиков. О самой уязвимости у меня уже был пост в субботу. Теперь же исследователи Imperva Threat Research сообщают, что эта уязвимость используется злоумышленниками для доставки зловреда, идентифицированого как компонент шифровальщике TellYouThePass.

⏳ Атаки были замечены 8 июня, менее чем через 48 часов после выпуска патча от разработчиков PHP. В атаках использовался эксплоит, который к тому времени уже был публично доступен.

Атаки с использованием TellYouThePass отмечаются с 2019 года. Они нацелены на организации и частных лиц. Злоумышленники шифруют и Windows, и Linux инфраструктуру.

Какие можно сделать выводы? Если видите уязвимость с публичным эксплоитом и более-менее понятным вектором эксплуатации - не поленитесь запатчить её как можно быстрее. Потому что злоумышленники точно не поленятся добавить этот эксплоит в свою малварь. 😉

Трендовые уязвимости мая по версии Positive Technologies

Трендовые уязвимости мая по версии Positive Technologies. Как обычно, в 3 форматах:

📹 Рубрика "В тренде VM" в новостном ролике SecLab-а (начинается с 17:06)
🗞 Пост на Хабре, фактически это несколько расширенный сценарий рубрики "В тренде VM"
🗒 Компактный дайджест с техническими деталями на официальном сайте PT

Список уязвимостей:

🔻 RCE в Fluent Bit (CVE-2024-4323)
🔻 RCE в Confluence (CVE-2024-21683)
🔻 RCE в Windows MSHTML Platform / OLE (CVE-2024-30040)
🔻 EoP в Windows DWM Core Library (CVE-2024-30051)

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

Как СберКорус с помощью TS Solution с нуля выстраивали у себя VM-процесс на MaxPatrol VM (часть 3)

Как СберКорус с помощью TS Solution с нуля выстраивали у себя VM-процесс на MaxPatrol VM (часть 3)

Как СберКорус с помощью TS Solution с нуля выстраивали у себя VM-процесс на MaxPatrol VM (часть 3). Завершаю серию постов про выступление Романа Журавлева из TS Solution и Никиты Аристова из СберКоруса на конференции СФЕРА Cybersecurity. В прошлый раз было про кастомные виджеты и прокачку MaxPatrol VM, а сейчас будет про планы СберКоруса на будущее.

Технические планы

🔸 В идеальной картине мира хотят получать в VM уязвимости из контейнеров. Тестируют PT Container Security.
🔸 Уязвимости из VM планируют передавать в Threat Intelligence. Там создастся репутационный список индикаторов компрометации, связанных с эксплуатацией уязвимостей. Этот список будет блокироваться на межсетевых экранах. Этот же список уйдёт в SOC для упрощения расследований. Уязвимости также планируют передавать в SOC (наличие некоторых уязвимостей это инцидент сам по себе и они должны мониториться 24/7 и оперативно исправляться).
🔸 Автоматизировать создание задач на ответственных в ITSM системах Jira и Naumen.
🔸 В SGRC передавать список активов и список уязвимостей на этих активах. В процессе пилотирования. Сейчас в MPVM нет функциональности по постановке задач, поэтому нужно решать это интеграциями.
🔸Хотят получать список активов из CMDB. Если актив есть в CMDB, помечаем в VM-е как легитимный. Если нет - разбираемся с Shadow IT. Также хотят обогащать активы CMDB техническими данными из VM-а.

После прикручивания интеграций к MaxPatrol VM в СберКорус могут смело сказать, что "Инвестиция нашего руководства в безопасность окупается. Продукт реально работает, на него завязано много процессов, которые делают много полезного и все счастливы, все улыбаются, даже наш коммерческий директор". 🙂

Q/A: Можно ли контролировать виртуализацию облачного провайдера (компания спрашивающего пострадала от эксплуатации такой уязвимости)? Конечно нет. По договору никто туда не пустит. [ На эту тему в КиберДуршлаге с Алексеем Лукацким было хорошо ].

Очень классное выступление, побольше бы таких! 👍 🙂

Хакатон MaxPatrol VM, часть 2: Ansible playbook для установки ПО из TAR-архива

Хакатон MaxPatrol VM, часть 2: Ansible playbook для установки ПО из TAR-архива

Хакатон MaxPatrol VM, часть 2: Ansible playbook для установки ПО из TAR-архива. Прошлая часть была про то, как я подготавливал виртуалку на Linux, чтобы работать с ней с помощью Ansible. По первому заданию мне нужно было поставить с помощью Ansible некоторые программное обеспечение из TAR-архива (обозначим здесь как Libre Data Analytics). Чтобы его установить необходимо просто скачать архив с сайта и распаковать в любую директорию. Я решил делать это прямо в домашнюю директорию пользователя vmuser. 🙂

Сам playbook аналогичен тестовому, который я запускал в прошлый раз. Такая же последовательность task-ов Ansible. Только в этот раз кроме тасков типа , который позволяет выполнять bash-скрипты, я использовал более специализированные.

1. - создание временной директории
2. - скачивание файла архива
3. - разархивирование архива
4. - удаление файла архива
5. - копирование из временно директории в постоянную
6. - удаление временной директории
7. - получение фактической версии ПО и запуск ПО с дефолтными параметрами (требуется по условию задания)
8. - вывод фактической версии ПО

Необходимую версию ПО и путь до директории, куда будет установлено ПО, оформил в виде переменных и .

Код плейбука:

- name: Install Libre Data Analytics from tar.gz file
hosts: all
vars:
libre_data_analytics_version: 2.13.0
libre_data_analytics_path: "/home/{{ ansible_user }}/"
tasks:
- name: Create temporary download directory
ansible.builtin.tempfile:
state: directory
prefix: libre-data-analytics-
register: download_dir

- name: Download Libre Data Analytics archive
ansible.builtin.get_url:
url: "https://artifacts.libre-data-analytics.org/releases/bundle/libre-data-analytics/{{ libre_data_analytics_version }}/libre-data-analytics-{{ libre_data_analytics_version }}-linux-x64.tar.gz"
dest: "{{ download_dir.path }}/libre-data-analytics.tar.gz"
mode: '0640'

- name: Extract Libre Data Analytics files
ansible.builtin.unarchive:
src: "{{ download_dir.path }}/libre-data-analytics.tar.gz"
dest: "{{ download_dir.path }}"
remote_src: true

- name: Remove libre_data_analytics_path
ansible.builtin.file:
path: "{{ libre_data_analytics_path }}/libre-data-analytics-{{ libre_data_analytics_version }}"
state: absent

- name: Copy files to the libre_data_analytics_path
ansible.builtin.copy:
src: "{{ download_dir.path }}/libre-data-analytics-{{ libre_data_analytics_version }}"
dest: "{{ libre_data_analytics_path }}"
remote_src: true

- name: Remove temporary download directory
ansible.builtin.file:
path: "{{ download_dir.path }}"
state: absent

- name: Get Libre Data Analytics version
ansible.builtin.shell: cd "{{ libre_data_analytics_path }}/libre-data-analytics-{{ libre_data_analytics_version }}"; ./bin/libre-data-analytics -V
register: installed_version

- name: Libre Data Analytics
ansible.builtin.shell: cd "{{ libre_data_analytics_path }}/libre-data-analytics-{{ libre_data_analytics_version }}"; nohup ./bin/libre-data-analytics /dev/null 2>&1 &

- name: Display Outputs
debug:
msg: "Path: {{ libre_data_analytics_path }}/libre-data-analytics-{{ libre_data_analytics_version }}, installed version from binary {{ installed_version.stdout }}"

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

nginx_from_repo_on_ubuntu
├── playbook.yaml
└── roles
└── nginx_from_repo_on_ubuntu
├── defaults
│ └── main.yaml
└── tasks
└── main.yaml

В итоге задание у меня успешно приняли. 👍 Можно двигаться дальше. 🙂