Обзор BI.ZONE PAM 2.3, системы управления доступом по модели нулевого доверия - Выбор корпоративных средств защиты - Форумы Anti-Malware.ru Перейти к содержанию
AM_Bot

Обзор BI.ZONE PAM 2.3, системы управления доступом по модели нулевого доверия

Recommended Posts

AM_Bot
Обзор BI.ZONE PAM 2.3, системы управления доступом по модели нулевого доверия
BI.ZONE PAM 2.3 — система управления привилегированным доступом по модели «нулевого доверия» (Zero Trust). Защищает критические цифровые системы, при этом не создаёт помех для управления ИТ-инфраструктурой. Продукт BI.ZONE PAM включён в реестр отечественного ПО, сертифицирован ФСТЭК России.      ВведениеФункциональные возможности BI.ZONE PAM 2.32.1. Вход в веб-интерфейс2.2. Защищённое подключение2.3. Добавление объектов контроля2.3.1. Настройка политик доступа2.3.2. Подключение через RemoteApp2.4. Динамическое управление секретами2.5. Мониторинг сеансов2.6. Просмотр SSH- и RDP-сессий2.6.1. Работа с SCP- и SFTP-сессиями2.6.2. Фиксация дополнительных данных для SOC2.7. РеагированиеФункциональные особенности для удобства пользователей3.1. Самостоятельные изменения по согласованию3.2. Массовые действия на ресурсах3.3. Application-to-Application Password Manager3.4. Поддержка сценариев автоматизации через Ansible PlaybookАрхитектура BI.ZONE PAM 2.3 и интеграция в ИТ-среду4.1. Компоненты системы4.2. Непрерывность работы, отказоустойчивость и аварийный доступ4.3. Масштабирование4.4. Установка4.5. ИнтеграцииСистемные требования и лицензирование BI.ZONE PAM 2.3Кейсы применения BI.ZONE PAM6.1. Замещение иностранного решения в масштабной ИТ-инфраструктуре6.2. Защита от ошибок ИТ-специалистов и контроль подрядчиков6.3. Безопасность в производственной компании с соблюдением требований законодательстваВыводыВведениеПривилегированные пользователи (ПП) — это не только администраторы, но и все, кто имеет расширенные полномочия в операционных системах (ОС) и ключевых компонентах инфраструктуры: от специалистов по кибербезопасности и разработчиков до бизнес-пользователей и подрядчиков. Такие права позволяют обходить стандартные меры защиты, и при компрометации привилегированных пользователей последствия для компании могут быть критическими — вплоть до потери данных, разрушения инфраструктуры и доступа к финансам.Практика показывает, что компрометация учётных записей ПП продолжает оставаться одним из ключевых факторов успешных атак на российские организации. В процессе эксплуатации информационных систем организации сталкиваются с рядом типичных, но критически важных проблем.Многие компании продолжают использовать административные учётные записи, информация о которых давно забыта или потеряна. Их пароли часто оказываются слабыми, не меняются годами. Деятельность администраторов на целевых ресурсах остается непрозрачной, а объём предоставляемых прав существенно превышает реальные потребности и зачастую не отзывается, даже когда сотрудники уже не выполняют соответствующие функции.Перечисленные риски подтверждаются данными BI.ZONE Threat Intelligence: 42 % атакующих групп используют техники, связанные с учётными записями ПП, для проникновения в инфраструктуру, а 63 % — на этапе продвижения по сети компании. Показательно, что во всех случаях разрушения ИТ-инфраструктуры, которые расследовала команда BI.ZONE DFIR в 2025 году, для нанесения масштабного ущерба использовались возможности привилегированных учётных записей.  Рисунок 1. Популярность техник MITRE ATT&CK, связанных с учётными записями ПП Отдельное внимание организациям приходится уделять выполнению требований регуляторов: указа Президента России № 250, федеральных законов № 152-ФЗ и 187-ФЗ, стандартов PCI DSS, ГОСТ Р 57580 и других.С учётом выявленных проблем и роста числа атак мы в компании BI.ZONE приняли решение о создании собственной системы управления привилегированным доступом — BI.ZONE Privileged Access Management (BI.ZONE PAM).В продукте отсутствуют OEM-компоненты сторонних производителей, что исключает критическую зависимость от внешних поставщиков. Это позволяет контролировать жизненный цикл всех ключевых компонентов, оперативно устранять уязвимости и развивать функциональность без ограничений, связанных с обновлениями или поддержкой со стороны третьих лиц.Решение включено в реестр отечественного ПО (№ 16915 от 21.03.2023), сертифицировано ФСТЭК России (4-й уровень доверия, сертификат № 4844 от 19.09.2024).Функциональные возможности BI.ZONE PAM 2.3В рамках серии видео «Эволюция российских PAM» уже была распаковка платформы BI.ZONE PAM. Тогда были обозначены ключевые задачи, которые решает продукт:Управление привилегированным доступом. Доступ к ключевым системам получают исключительно нужные люди на конкретный срок.Управление секретами привилегированных учётных записей. Сотрудники и подрядчики не знают пароли от учётных записей с расширенными правами. Секреты регулярно меняются — по расписанию или после каждого подключения.Контроль активности привилегированных пользователей. Действия при работе с критическими системами фиксируются в формате видео и текстовых команд, а данные о событиях уходят в SIEM.Реагирование на атаки. Нелегитимную активность можно прекратить в ручном режиме или заблокировать автоматически по чёрному списку запрещенных команд.Рассмотрим BI.ZONE PAM 2.3 более детально.Продукт представляет собой централизованную платформу для управления привилегированным доступом, реализующую принципы «нулевого доверия». Ключевой механизм — разрыв цепочки аутентификации: сотрудники подключаются к компонентам PAM, а не напрямую к целевым системам. Таким образом, создаются два независимых плеча подключения:от пользователя к PAM — с использованием непривилегированной учётной записи;от PAM к целевому ресурсу — с применением выделенных данных для привилегированного доступа.Рисунок 2. Схема работы BI.ZONE PAM 2.3 BI.ZONE PAM 2.3 реализует принципы «нулевого доверия» на архитектурном и прикладном уровне. Пользователь не получает прямого доступа к целевым системам и не владеет учётными данными — все подключения происходят через управляемые каналы по строго заданным правилам. Доступ предоставляется только через заранее определённые аккаунты с ограниченными по контексту правами. Каждое обращение проходит проверку политик, а попытки обхода системы исключены технически. Таким образом, платформа не доверяет ни пользователю, ни его устройству, ни локальной сети и требует явной авторизации и контроля на каждом этапе.Платформа контролирует весь процесс: проверяет права, проводит аутентификацию, автоматически предоставляет доступ с необходимыми полномочиями только в рамках заранее заданных сценариев. Подключение к целевым системам осуществляется через контролируемую среду, что позволяет записывать действия пользователей, ограничивать команды, исключать несанкционированные операции.Модель «нулевого доверия» также подразумевает, что строгость контроля компенсируется удобством работы. Это требуется для того, чтобы меры безопасности не снижали эффективность и скорость выполнения бизнес-задач. Платформа BI.ZONE PAM учитывает этот аспект Zero Trust, поэтому предлагает упрощённый пользовательский путь, понятный интерфейс, поддержку сценариев автоматизации, быстрое развёртывание и интеграцию с инфраструктурой, а также механизмы для ускорения взаимодействия между командами ИТ и безопасности.Вход в веб-интерфейсНа странице аутентификации в веб-интерфейсе BI.ZONE PAM демонстрируются информационные сообщения и уведомления. Рисунок 3. Вход в интерфейс BI.ZONE PAM 2.3 Эта функциональность предназначена для оперативного информирования пользователей, как внутренних, так и внешних (например, подрядчиков), о событиях, влияющих на доступ к целевым системам. Администратор может разместить уведомление, поясняющее причины возможных сбоев в подключении. Например, проведение технических работ на стороне целевого ресурса, запуск обновлений или наложение ограничений другим оператором. Это снижает количество обращений, ошибочно направляемых в адрес PAM-системы, и позволяет пользователю самостоятельно интерпретировать причины отказа в подключении.Настройка уведомлений доступна во вкладке «Настройка» при выборе раздела «Уведомления». Рисунок 4. Настройка уведомлений в BI.ZONE PAM 2.3 После аутентификации через доменную учётную запись пользователь попадает в интерфейс решения. В зависимости от присвоенных ролей (преднастроенных или кастомных) отображаются соответствующие элементы управления. Рисунок 5. Интерфейс администратора Рисунок 6. Интерфейс пользователя Защищённое подключениеBI.ZONE PAM 2.3 поддерживает подключение к разным типам ресурсов, включая Secure Shell (SSH), Secure Copy Protocol (SCP), SSH File Transfer Protocol (SFTP), Remote Desktop Protocol (RDP), базы данных PostgreSQL, Oracle и другие. Кроме проксирования сессий SSH и RDP, есть возможность настройки подключений через публикацию приложений RemoteApp.Добавление объектов контроляСоздание нового ресурса возможно в разделе «Ресурсы». Рисунок 7. Заведение целевого ресурса в BI.ZONE PAM 2.3 Ресурс идентифицируется по типу подключения и по уникальному набору атрибутов: IP-адресу, порту, FQDN. Это исключает коллизии при доступе, особенно в случаях, когда на одном IP-адресе работают разные сервисы на различных портах.Посмотреть целевые системы, к которым пользователю настроен доступ, можно во вкладке «Мои подключения». Группировка подключений и возможность поиска по всему списку ускоряют работу с большим количеством систем. Рисунок 8. «Мои подключения» в BI.ZONE PAM 2.3 Подключение к ресурсу возможно только при наличии соответствующей учётной записи. Добавить учётные записи в PAM-систему администратор может вручную или за счет синхронизации пользователей и групп из LDAP-каталогов.Сущности «ресурс» и «учётная запись» объединяются в структуру под названием «аккаунт». Это базовая единица, с которой в дальнейшем производится управление доступом. Один аккаунт представляет собой связку между конкретной учётной записью и целевым ресурсом. Например, привилегированная учётная запись Administrator может быть связана с IP-адресом 10.8.198.216, который соответствует контроллеру домена. Рисунок 9. Учётная запись в аккаунте Рисунок 10. Ресурс, связанный с учётной записью Administrator Простой случай — это один аккаунт на один ресурс с одной учётной записью. Однако предусмотрен и другой подход: один аккаунт может включать одну учётную запись и несколько ресурсов. Рисунок 11. Добавление ресурсов для одной учётной записи Это позволяет централизованно управлять доступом, например, для административных задач в рамках проекта или службы.Настройка политик доступаПрава выдаются и отзываются через политики, настраиваемые во вкладке «Права и доступ». Рисунок 12. Вкладка «Права и доступ» в BI.ZONE PAM 2.3 В политике указывается, какие аккаунты доступны и кому — отдельным пользователям или группам. В случае использования групп права автоматически наследуются всеми участниками группы. Политики можно редактировать: отозвать доступ, удалив группу или конкретного пользователя из политики. Такой подход снижает вероятность ошибок со стороны администратора, поскольку отпадает необходимость вручную повторно связывать учётные записи с ресурсами при каждом изменении прав.Для каждой политики доступа можно задать используемый протокол подключения. Это выполняется во вкладке «Приложения». Здесь указывается, каким способом должен подключаться пользователь при доступе к определённому ресурсу. Например, RDP — для подключения к контроллерам домена Microsoft, SSH — для серверов под управлением Linux. Это позволяет системе однозначно интерпретировать, какой протокол и тип подключения применять к каждому аккаунту. Рисунок 13. Указание типа доступа в политике доступа Для снижения риска несанкционированного доступа мы рекомендуем настраивать политики доступа с многофакторной аутентификацией. Это может быть реализовано за счет встроенного механизма отправки временных кодов (TOTP) или интеграции с провайдерами многофакторной аутентификации. В качестве альтернативной или дополнительной меры система поддерживает подключение по номеру заявки (тикета). При интеграции с внешней ITSM-системой пользователь сначала создает тикет с запросом доступа к критическому ресурсу, получает согласование администратора и далее подключается к ресурсу с указанием номера тикета. Подключение через RemoteAppВ системе предусмотрена возможность использования различных типов приложений, реализованных в виде шаблонов (вкладка «Приложения»). Допустим, заказчик использует самописную систему, доступ к которой возможен только через специфичную версию браузера. В этом случае создается шаблон приложения, в котором явно указывается нужная версия Chrome и необходимые параметры запуска.Тип приложения указывается при создании шаблона — например, опубликованный браузер. В рамках шаблона могут быть описаны параметры запуска, включая конкретную версию приложения и файл конфигурации. В результате пользователь, подключаясь, открывает экземпляр браузера, настроенный по шаблону, и получает доступ к интерфейсу системы. Такой подход позволяет учитывать специфические требования заказчика. Рисунок 14. Создание приложения (типа доступа) До конца года мы планируем добавить поддержку публикации приложений через Linux‑терминальные фермы. Пользователи смогут обращаться к целевым ресурсам через эти опубликованные приложения, сохраняя централизованный контроль привилегий, аудит сеансов и безопасное управление доступом без необходимости подключаться к хостам напрямую.Динамическое управление секретамиПоддерживаются два метода аутентификации: по паролю или с использованием сертификата SSH. Все секреты, включая пароли и ключи, хранятся в хранилище секретов.Управление секретами организовано через специализированные движки, каждый из которых отвечает за хранение и выдачу определённого типа учётных данных. Например, движок по типу «ключ-значение» (key-value) — для локальных учётных записей, специализированный SSH-движок — для SSH-ключей, LDAP-движок для записей из соответствующего каталога и пр.Ротация и жизненный цикл секретов реализуются в рамках соответствующих движков: одни автоматически создают и отзывают временные учётные записи, другие позволяют версионировать и обновлять статичные значения. Логи и аудит записывают операции с секретами без раскрытия их содержимого, а API и инструменты автоматизации обеспечивают интеграцию с CI / CD и оркестраторами для централизованного управления и обновления секретов. Рисунок 15. Заведение привилегированной учётной записи в BI.ZONE PAM 2.3 Мониторинг сеансовВ интерфейсе BI.ZONE PAM 2.3 для всех сессий доступна информация о точке входа, маршруте, IP-адресе пользователя, времени начала, продолжительности сессии и другое. Рисунок 16. Вкладка «Сессии» в BI.ZONE PAM 2.3 Отображение сессий настраивается при помощи функции «Настройка отображения колонок» (в верхнем правом углу). Рисунок 17. Настройка отображения колонок в BI.ZONE PAM 2.3 Имеется возможность фильтрации информации — по дате, началу, окончании сессии, периоду активности пользователя. Рисунок 18. Фильтрация сессий по дате в BI.ZONE PAM 2.3 Также сохраняется видео- и текстовый журнал действий пользователей, который можно использовать для аудита и расследования.Просмотр SSH- и RDP-сессийПосле открытия интересующей сессии автоматически запускается модуль воспроизведения, где отображаются временная шкала и сгруппированные команды, вводимые пользователем. Команды группируются по факту выполнения.Например, при вводе команды touch она сохраняется в списке, и по клику система перемещает на соответствующий момент на таймлайне. При этом интерфейс не использует видеофиксацию — вся информация отображается в виде текста, который доступен для копирования и может использоваться для поиска, фильтрации и локализации инцидентов. Рисунок 19. Просмотр SSH-сессий в BI.ZONE PAM 2.3 Рисунок 20. Просмотр RDP-сессий в BI.ZONE PAM 2.3 Засечки на таймлайне указывают на активные действия пользователя. При наличии пауз в действиях предусмотрен режим пропуска неактивных участков — Skip idle, при включенной опции плеер автоматически перемещается между периодами активности, позволяя ускорить просмотр.В правой части экрана доступна панель метаданных, где отображаются:время начала и завершения сессии; логины пользователей;тип подключения (например, ssh-native);IP-адреса и внутренние идентификаторы;компонент подключения, использованный в конкретной сессии;привязанный тикет (если был указан при подключении).Эти данные предоставляют контекст, необходимый для анализа действий пользователя и взаимодействия с целевыми ресурсами.Работа с SCP- и SFTP-сессиямиПользователь может работать с файлами через SCP / SFTP в рамках отдельной сессии, параллельно SSH. В интерфейсе отображаются действия: загрузка, редактирование, удаление, переименование. Каждый файл фиксируется с указанием времени операции, направления передачи и изменения размера. Действия отображаются в специализированной вкладке интерфейса, где для каждого события формируется отдельная запись с подробными метаданными. Рисунок 21. Работа с файлами через SCP / SFTP в BI.ZONE PAM 2.3 Фиксация дополнительных данных для SOCЗафиксированные действия пользователей и администраторов могут быть направлены во внешние системы.По умолчанию поддерживается отправка данных через Kafka и другие каналы, включая форматы, согласуемые на этапе внедрения. Фиксируются не только успешные подключения, но и попытки доступа, включая ввод неверных учётных данных или обращения к портам подключения. Такая информация может быть использована для формирования инцидентов в SIEM-системах.РеагированиеЕсли возникает необходимость экстренного отключения пользователя (например, при выявлении компрометации), администратор может вручную отключить его через интерфейс PAM или заблокировать пользователя в стороннем каталоге. При этом политика доступа не изменяется, а пользователь просто утрачивает текущие сессии. Это позволяет оперативно реагировать на инциденты без риска нарушить общую конфигурацию доступа. Рисунок 22. Разрыв соединения через интерфейс BI.ZONE PAM 2.3 Во втором случае необходимо во вкладке «Пользователи» найти соответствующую учётную запись и воспользоваться функцией отключения. После этого пользователь теряет возможность устанавливать новые подключения к ресурсам, даже если права доступа по-прежнему присутствуют. Статус пользователя может быть синхронизирован со статусом его учётной записи из внешнего каталога пользователей. Рисунок 23. Отключение пользователя в BI.ZONE PAM 2.3 Помимо реагирования в ручном режиме, BI.ZONE PAM 2.3 предлагает также автоматическую блокировку нежелательной активности. Это реализовано через фильтрацию SSH-команд по чёрному списку. Рисунок 24. Фильтрация команд в BI.ZONE PAM 2.3 Список поддерживает регулярные выражения, доступен преднастроенный перечень. Когда пользователь вводит команду из списка, платформа может запретить действие, показать предупреждение или передать данные в SIEM. Мера повышает защиту от злоумышленников, в том числе внутренних. Ещё она позволяет ИТ‑отделам организовать плавное погружение для новых сотрудников. К примеру, можно запретить им ввод команд для перезагрузки критических систем.Функциональные особенности для удобства пользователейСреди возможностей BI.ZONE PAM 2.3 выделяются механизмы, которые способствуют балансу между безопасностью и удобством при контроле привилегированного доступа.Самостоятельные изменения по согласованию В версии 2.3 платформа BI.ZONE PAM стала поддерживать сценарий, при котором пользователи могут самостоятельно предлагать изменения, связанные с настройками системы. Администратор платформы одобряет или отклоняет такие изменения в разделе «Заявки». Механизм «второй руки» ускоряет работу, а двойной контроль исключает ошибки. Рисунок 25. Согласование заявок в BI.ZONE PAM 2.3 Массовые действия на ресурсах Во время операций над десятками серверов или баз данных ИТ-специалист может использовать варианты кеширования многофакторной аутентификации, чтобы подключаться к целевым ресурсам без повторного ввода пароля. Пользователь один раз проходит полную проверку, а затем получает возможность многократного доступа по SSH-сертификату или специальному ярлыку для RDP-подключений. Срок действия таких файлов определяет администратор платформы.Для получения SSH-сертификата необходимо во вкладке «Сертификаты» выбрать «Мои сертификаты» и нажать «Создать». Рисунок 26. Создание сертификата в BI.ZONE PAM 2.3 При этом понадобится указать название, используемый криптографический алгоритм, битовую длину ключа. Система задаст пароль для сертификата и отобразит его срок действия. Рисунок 27. Генерация сертификата Кнопка закрытия окна генерации станет доступной только после загрузки файла сертификата. Такой подход обеспечивает дополнительную гарантию, что секрет не будет утерян до его сохранения.Для RDP-сессий реализован дополнительный механизм в виде постоянных и одноразовых ярлыков подключения. Рисунок 28. Скачивание ярлыка подключения к ресурсам по протоколу RDP Постоянный ярлык можно сохранить на рабочем столе и использовать многократно, каждый раз вводя только пароль. Рисунок 29. Подключение по RDP к целевому ресурсу в BI.ZONE PAM 2.3 через ярлык Одноразовые ярлыки создаются в рамках активной сессии в веб-интерфейсе.Повторное использование одноразового ярлыка невозможно: при втором запуске система сообщает, что токен недействителен. Рисунок 30. Сообщение о том, что токен невалидный Передача ярлыка третьим лицам также исключена — токен привязан к конкретному пользователю и рассчитан на однократное использование. Это позволяет безопасно подключаться к ресурсам без повторного прохождения процедуры аутентификации, сохраняя при этом требования по контролю доступа.Application-to-Application Password ManagerСторонние приложения могут запрашивать секреты из модуля управления секретами BI.ZONE PAM по защищённому API и использовать их в работе. Это обеспечивает централизованное хранение секретов, ротацию паролей, контроль доступа по ролям и аудит вызовов API. При этом приложения получают только необходимые секреты на короткий срок, а в коде или конфигурации не хранятся данные, которые могут дать постороннему доступ к корпоративным сервисам.Поддержка сценариев автоматизации через Ansible PlaybookBI.ZONE PAM 2.3 поддерживает скрипты Ansible — популярный инструмент для выполнения типовых DevOps-операций (настройка, обновление, проверка конфигурации целевых систем и пр.).Это позволяет ускорять выполнение рутинных задач без выхода из PAM-сессии. Платформа сама обеспечивает аутентификацию скрипта в целевой системе, запуск скрипта осуществляется только в рамках прав доступа пользователя PAM, все действия контролируются политиками безопасности PAM, логируются и могут быть воспроизведены для аудита.Для запуска Ansible Playbook в рамках PAM-сессии пользователю достаточно указать в конфигурационном файле Ansible Inventory параметры подключения, предоставленные PAM (например, proxy, user, host, порт). Рисунок 31. Схема работы с Ansible Playbook Архитектура BI.ZONE PAM 2.3 и интеграция в ИТ-средуАрхитектура BI.ZONE PAM построена по микросервисному принципу с возможностью масштабирования и кластеризации компонентов, основанных на подходе container-native. Это обеспечивает отказоустойчивость и гибкость при развёртывании в инфраструктуре заказчика.Компоненты системыКомпоненты реализованы в виде контейнеров, поддерживается развёртывание в кластере OpenShift (или совместимом контейнерном окружении). Рисунок 32. Архитектура BI.ZONE PAM 2.3 Ключевые элементы архитектуры:Оркестратор предоставляет доступ к интерфейсу платформы, перечню целевых систем. Управляет конфигурацией решения, отслеживает состояние активных и завершённых сессий. Поддерживает REST-интерфейс (API) для интеграции со сторонними системами. Интерфейс един для пользователей и администраторов — доступная функциональность определяется ролевой моделью. Также в оркестратор встроен модуль аутентификации с поддержкой внешних каталогов (например, Microsoft Active Directory, FreeIPA) и внутренней реализацией многофакторной аутентификации по протоколу TOTP.Компонент управления отвечает за контроль и координацию активных сессий, получает секреты из модуля управления секретами, контролирует взаимодействие с компонентом подключений, обеспечивает запись и чтение данных сессий.Компонент подключений реализует проксирование пользовательских сессий по различным протоколам. В версии 2.3 это RDP (включая RemoteApp через терминальные приложения Microsoft) и SSH, SCP и SFTP. Все действия пользователей фиксируются как в текстовом виде, так и в формате видеозаписей, что позволяет обеспечить полный аудит активности.Кластер баз данных хранит конфигурационные данные платформы и настройки прав доступа и разрешений на подключение к целевым ресурсам.Модуль управления секретами отвечает за хранение и ротацию учётных данных привилегированных пользователей.Непрерывность работы, отказоустойчивость и аварийный доступЗа счёт микросервисной архитектуры BI.ZONE PAM сохраняет работоспособность при обслуживании и изменении настроек: отдельные компоненты можно обновлять, настраивать или перезапускать без остановки всей системы. Это же помогает сохранять работоспособность системы даже при сбое её отдельных компонентов.Для дополнительных гарантий непрерывности бизнес-процессов платформа поддерживает различные схемы высокой доступности, включая резервирование Active-Active, Active-Passive и N+1, в зависимости от требований конкретной организации. При выходе из строя одного из компонентов резервный узел активируется мгновенно.Для распределённых инсталляций с несколькими компонентами подключения в интерфейсе предусмотрена настройка балансировки. В таких сценариях балансировщик принимает входящие подключения от пользователей и распределяет их между доступными нодами, обеспечивая отказоустойчивость и равномерную загрузку системы. Добавление балансировщиков производится через «Права и доступ» при выборе одноименного раздела. Рисунок 33. Раздел «Балансировщик» во вкладке «Права и доступ» Аварийные сценарии включают механизм резервного доступа. Он реализован по аналогии с концепцией «золотого тикета» (Golden Ticket). В рамках политики доступа можно предусмотреть учётную запись, к которой предоставляется доступ даже в случае недоступности основной инфраструктуры PAM. Такая запись создаётся заранее, она может быть использована, например, в случае отказа контроллера домена или самого PAM-сервера. Рисунок 34. Вкладка «Резервный доступ» в BI.ZONE PAM 2.3 При попытке подключения система сначала проверяет наличие тикета в собственном списке резервного доступа. Если тикет найден, доступ предоставляется. Если нет — инициируется обращение во внешнюю тикетницу. Такой подход позволяет обеспечить непрерывность доступа даже при сбоях во внешних системах или в рамках плановых работ.МасштабированиеМикросервисная архитектура BI.ZONE PAM позволяет создать инсталляцию, охватывающую всю информационную инфраструктуру организации и готовую к высокой нагрузке. Например, одна из подтверждённых инсталляций BI.ZONE PAM охватывает сотни тысяч серверов и десятки тысяч одновременных сессий.Как следствие:Возможности горизонтального масштабирования зависят от доступных вычислительных ресурсов заказчика, а не от ограничений самого программного обеспечения.Горизонтальное масштабирование не требует приобретения дополнительных лицензий.Чтобы расширить вычислительные ресурсы для поддержки большего количества подключений и распределения нагрузки, достаточно добавить в систему дополнительный компонент подключений. Управление всеми компонентами, в том числе геораспределёнными, доступно в едином веб-интерфейсе.Установка Система BI.ZONE PAM может быть установлена в инфраструктуре заказчика на виртуальной машине, выделенном физическом сервере или в контейнерной среде. Готовые скрипты развёртывания позволяют подготовить платформу к добавлению систем и учётных записей за десятки минут. За счёт микросервисной архитектуры возможна доработка скриптов инсталляции под конкретную инфраструктуру, от схем all-in-one (инсталляция на одной виртуальной машине) до отказоустойчивых инсталляций с георезервированием.Интеграции«Из коробки» поддерживаются интеграции: с источниками учётных записей AD, FreeIPA, Avanpost DS, ALD Pro, РЕД АДМ, «Атом.ДОМЕН», «Альт Домен», Dynamic Directory, «Эллес» (также система располагает внутренним каталогом пользователей); провайдерами двухфакторной аутентификации в дополнение к встроенной 2FA — по протоколам OpenID Connect, OAuth 2.0, SAML; SIEM-системами; ITSM-системами (тикетницами).Дополнительные интеграции можно реализовать через REST API: в разработке команда BI.ZONE PAM придерживается подхода API-first.Системные требования и лицензирование BI.ZONE PAM 2.3Решение совместимо с корпоративной ИТ-инфраструктурой на базе операционных систем семейств Windows NT и Linux / Unix, в том числе основных российских Linux‑дистрибутивов.Для определения необходимого количества компонентов Worker рекомендуется учитывать, что один Worker SSH рассчитан на обслуживание до 250 одновременных сессий. Worker RDP чувствителен к количеству ЦП, стабильно держит 6 сессий на 1 ЦП. Таблица 1. Минимальные требования к аппаратному обеспечениюКомпонентBI.ZONE PAM docker composeRAM (ГБ)16CPU (ядер)8SYS SSD600ОСUbuntu 22.04ПримечаниеВиртуальная машина Лицензирование производится по количеству одновременных активных сессий привилегированных пользователей, подключающихся к целевым системам, и числу привилегированных пользователей.Кейсы применения BI.ZONE PAMВнедрение BI.ZONE PAM выполняется поэтапно и начинается с определения целей проекта. На этом этапе устанавливаются объём и границы предстоящих работ, а также фиксируются критерии, по которым будет оцениваться успешность внедрения. После согласования целевых параметров и ожиданий заказчика осуществляется развёртывание и настройка системы: устанавливаются необходимые компоненты, добавляются и конфигурируются привилегированные учётные записи, настраиваются политики и параметры доступа в соответствии с архитектурой инфраструктуры.Следующий этап — функциональное тестирование. Команда BI.ZONE проверяет соответствие реализованной конфигурации поставленным задачам, корректность работы механизмов аутентификации, мониторинга и управления доступом.После подтверждения работоспособности и завершения основных настроек осуществляется закрытие проекта. На этом этапе готовится отчётная документация, итоговый протокол.Рассмотрим кейсы внедрения BI.ZONE PAM в организациях различного масштаба и отраслевой принадлежности.Замещение иностранного решения в масштабной ИТ-инфраструктуреВ «Сбере» внедрение BI.ZONE PAM преследовало цель заменить зарубежное решение для управления привилегированным доступом на отечественное, сохранив привычные возможности продукта и высокий уровень безопасности. Проект потребовал учесть три ключевых фактора:масштаб инфраструктуры; невозможность остановки работы даже на непродолжительное время;сроки, т. к. миграция инфраструктуры такого масштаба занимает несколько лет, а на проект отводилось только 1,5 года.Переход осуществлялся поэтапно. Каждая новая функция проходила предварительную валидацию в тестовом контуре, после чего внедрялась в промышленную среду для ограниченной фокус-группы из 3–5 человек. На следующем этапе происходило масштабирование на группу около 100 пользователей, а затем — на всю целевую аудиторию, охваченную BI.ZONE PAM. Такой подход позволил избежать простоев и исключить сценарии, при которых привилегированный доступ временно оставался бы вне контроля PAM-системы.Внедрение BI.ZONE PAM не только сохранило привычную функциональность, но и улучшило пользовательский опыт сотрудников «Сбера». Один из примеров — оптимизация массовых подключений: DevOps-, SRE-инженерам и администраторам стало требоваться меньше действий для одновременного подключения к большому числу систем. С деталями кейса можно ознакомиться по ссылке.Защита от ошибок ИТ-специалистов и контроль подрядчиковДля организации среднего бизнеса из сферы ИТ и телекоммуникаций основной задачей внедрения PAM-системы было обезопасить инфраструктуру от нежелательных изменений в критически важных сервисах. Подразумевался не только умышленный вред, но и случайные действия: в силу специфики компании почти половина её сотрудников работает с ключевыми для бизнеса системами, и это повышает вероятность ошибки. Из-за этой же специфики требовалось, чтобы меры контроля не ломали привычный пользовательский опыт для разработчиков и DevOps-инженеров, обеспечив им бесшовный доступ к серверам и другим защищаемым системам.Команда BI.ZONE PAM помогла скорректировать процессы управления доступом в соответствии с моделью Zero Trust, оптимизируя контроль внешних подключений со стороны подрядчиков. Благодаря поддержке беспарольной аутентификации, изменений по согласованию (механизм «второй руки») и Ansible-скриптов удалось минимизировать воздействие защитных мер на удобство выполнения рутинных задач ИТ-команды.Безопасность в производственной компании с соблюдением требований законодательстваПромышленная организация искала PAM-решение для защиты геораспределённых площадок. Требования по контролю привилегированного доступа учитывали внимание регуляторов (152-ФЗ, приказы ФСТЭК России № 21, № 31, № 239 и т. д.).BI.ZONE PAM отвечает этим запросам. За счёт микросервисной архитектуры можно развернуть систему в нескольких филиалах по финансово выгодной схеме — в рамках единой лицензии. Решение сертифицировано ФСТЭК России по 4-му уровню доверия и помогает выполнять требования законодательства, усиливая необходимые меры защиты.ВыводыBI.ZONE PAM решает ключевые задачи в области управления привилегированным доступом и защиты критических ресурсов. Для повышения безопасности реализовано динамическое управление секретами: пароли и сертификаты автоматически обновляются при каждом подключении. Действия администраторов и подрядчиков фиксируются в процессе работы с критической информацией, что позволяет контролировать выполнение операций и повышать прозрачность.События кибербезопасности передаются в системы централизованного мониторинга, обеспечивая оперативное реагирование со стороны центра мониторинга и реагирования на инциденты.Достоинства:Поддержка разных протоколов подключения — SSH, SCP / SFTP, RDP, PostgreSQL, Oracle и другие.Предоставление доступа к критическим данным только определённым сотрудникам на нужный срок.Совместимость с корпоративной ИТ-инфраструктурой на базе операционных систем семейств Windows NT и Linux / Unix, в т. ч. основных российских Linux‑дистрибутивов.Встроенная поддержка двухфакторной аутентификации по протоколу TOTP.Внутренний каталог для внесения в PAM-систему локальных учётных записей пользователей.Удобный просмотр записанных текстовых и графических сессий и быстрое перемещение по событиям внутри записанной сессии.Сервисы самостоятельных изменений по согласованию.Поддержка сценариев автоматизации и DevOps (container-native, скрипты Ansible, подход API-first и пр.).Горизонтальное масштабирование без необходимости приобретения дополнительных лицензий.Отказоустойчивость и готовность к высокой нагрузке за счёт микросервисной архитектуры.Простая установка с готовыми скриптами развёртывания и помощью опытной команды техподдержки.Поддержка непрерывной работы системы при проведении технического обслуживания и изменении конфигурации.Отсутствие зависимости от OEM-компонентов сторонних производителей при развитии продукта.Присутствие в реестре отечественного ПО, наличие сертификата ФСТЭК России.Недостатки:Для использования режима RemoteApp требуется наличие терминальной инфраструктуры Microsoft.Не реализована функция формирования отчётов по действиям пользователей и сессиям.Отсутствие функциональности управления привилегированным доступом к Kubernetes через PAM.Реклама, 18+. ООО «БИЗон» ИНН 9701036178ERID: 2VfnxwHjuzx

Читать далее

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • Ego Dekker
      ESET Online Scanner был обновлён до версии 4.0.1. Приложение теперь работает только в 64-разрядной ОС.
    • Ego Dekker
      ESET Cyber Security был обновлён до версии 9.0.6700.
    • AM_Bot
      Теория звучит убедительно, но работает ли она на практике? Мы внимательно изучили Phishman 2.35 и решили не останавливаться на описании её возможностей. Вместо этого протестировали платформу на собственных сотрудниках и удивились, к каким результатам это привело.      1. Введение2. Методология тестирования Phishman 2.353. Первичное тестирование3.1. Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылки3.2. Тестирование доставки и отражения результатов в статистике3.3. Результаты атак4. Обучение4.1. Формирование учебной группы4.2. Составление образовательной программы по повышению киберкультуры4.3. Процесс обучения и его результаты5. Повторное тестирование5.1. Результаты атак6. Подведение итогов6.1. Сложности, с которыми мы столкнулись7. Впечатления от проекта команды «АМ Медиа»7.1. Реакция сотрудников7.2. Реакция организаторов7.3. Сотрудничество с вендором8. ВыводыВведениеPhishman 2.35 — это система повышения осведомлённости пользователей в сфере ИБ. Она помогает развивать киберкультуру и формировать у сотрудников устойчивые навыки безопасной работы с информацией, цифровыми сервисами и корпоративными ресурсами. В процессе обучения сотрудники учатся распознавать актуальные сценарии атак, закрепляют правильные модели поведения и в результате реже становятся причиной инцидентов, связанных с человеческим фактором.В первой части обзора Phishman 2.35 мы рассмотрели платформу с точки зрения её возможностей. Теперь пришло время проверить, как всё это работает на практике. За время проекта мы не только оценили эффективность различных сценариев, но и столкнулись с рядом особенностей, которые невозможно увидеть в документации. Одни из них влияли на ход тестирования, другие оказались скорее организационными нюансами, о которых стоит знать заранее.Методология тестирования Phishman 2.35В процессе работы с киберкультурой «АМ Медиа» мы будем использовать следующие метрики:Обученность. Отражает уровень знаний сотрудников в области ИБ. Показатель растёт, когда сотрудники осваивают темы: реагирование на инциденты, защита от социальной инженерии и другие критически важные компетенции.Иммунность. Показывает, как сотрудники применяют знания на практике. Она повышается, когда демонстрируется способность распознавать угрозы и правильно на них реагировать в реальных сценариях.Киберосознанность — итоговая метрика. Объединяет знания и практические навыки, показывая, насколько сотрудники в целом устойчивы к киберугрозам и действуют корректно при их возникновении.Прежде чем оценивать эффективность работы системы, необходимо определить отправную точку. Первичное тестирование определит, на какие сценарии реагирует каждый сотрудник, где чаще всего допускаются ошибки и какие темы требуют дополнительного развития. На основе этих данных формируется индивидуальная программа обучения: сотрудники проходят персонализированные курсы, выполняют практические задания и тесты, которые помогают устранить выявленные пробелы и закрепить необходимые навыки. В процессе обучения повышается уровень обученности, а закрепление знаний через практику влияет на показатель иммунности. После завершения обучения мы проведём повторное тестирование, которое покажет, какие изменения произошли по всем ключевым метрикам.Заключительный этап — сравнение результатов первичного и повторного тестирования. Здесь станет понятно, насколько вырос уровень киберкультуры сотрудников: изменилось ли их отношение к вопросам ИБ, стали ли они увереннее распознавать угрозы и чаще принимать безопасные решения в ситуациях, где раньше могли допустить ошибку.В качестве основного канала для рассылки фишинга выбрали электронную почту. Причина очевидна: именно она остаётся основным способом первичного контакта злоумышленников с сотрудниками и доставки фишинговых сценариев. По имеющимся оценкам, более 90 % успешных кибератак начинаются с электронного письма, поэтому исключать этот канал из подобных проверок было бы некорректно.Первичное тестированиеРеальные фишинговые атаки почти никогда не строятся по универсальному шаблону: злоумышленники адаптируют содержание писем под роль человека в компании, его рабочие процессы и типовые задачи. Поэтому при выборе целевой аудитории мы разделили сотрудников по функциям и уровню доступа к корпоративным данным, а сам проект разбили на 3 последовательные волны с разным уровнем сложности.Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылкиПосле определения целевой аудитории был проведён анализ структуры подразделений и рабочих процессов сотрудников. На этом этапе изучались:должностные обязанности;распределение зон ответственности;характер внутреннего взаимодействия между отделами;используемые адреса электронной почты;формат повседневной служебной переписки.Это позволило понять, какие сценарии коммуникации являются для сотрудников привычными и не вызывают подозрений.На основе собранных данных были подготовлены сценарии фишинговых сообщений. При разработке содержимого учитывались тематика рабочих задач, стиль корпоративного общения, оформление внутренних уведомлений и типовые причины отправки писем внутри организации. Основная задача заключалась в том, чтобы письмо воспринималось как стандартное рабочее сообщение, соответствующее реальным бизнес-процессам заказчика.Волна 1. Первая волна была построена как массовый фишинг. Сценарий — сверка графика отпусков. Для атаки создавали и настраивали пользовательский шаблон. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки.На этом этапе проверялась базовая реакция сотрудников на привычные рабочие триггеры и способность распознавать типовые признаки фишинга без привязки к конкретному подразделению. Рисунок 1. Шаблон для первой волны Рисунок 2. Вид фишингового письма из первой волны в почте Волна 2. Для каждого отдела были подготовлены письма, основанные на реальных рабочих процессах, характерных запросах и ситуациях, с которыми сотрудники регулярно сталкиваются в своей деятельности. Для атаки создали и настроили пользовательский шаблон, где-то добавили немного визуального оформления. Время начала рассылки — по запланированному времени. Рисунок 3. Пример шаблона из второй волны для отдела «Продажи» Рисунок 4. Вид фишингового письма из второй волны для отдела «Продажи» Волна 3. Здесь моделировались уже более сложные сценарии целевого фишинга (spear phishing). В письмах использовались специальные формулировки, элементы корпоративного брендирования. На этом этапе проверялась не только внимательность сотрудников, но и способность замечать менее очевидные признаки атаки в условиях, максимально приближённых к реальной целевой компрометации.За основу брали системный брендированный шаблон «Яндекс ID», добавили фишинговую форму и скорректировали немного её содержание. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 5. Пример шаблона из третьей волны Рисунок 6. Вид фишингового письма из третьей волны При переходе по ссылке открывалась фишинговая страница. Рисунок 7. Фишинговая страница Тестирование доставки и отражения результатов в статистикеДалее была подготовлена инфраструктура рассылки. После её настройки проводилось тестирование доставки сообщений. Проверялась доставка писем во входящие сообщения почтовых клиентов, анализировалась реакция антиспам-механизмов в почте, а также контролировалась корректность работы механизмов отслеживания действий пользователей. Рисунок 8. Результаты тестирования доставки и отображения сообщений в почте Тестирование прошло успешно.После завершения проверки была сформирована последовательность отправки сообщений по заранее определённым волнам. Такой подход позволил распределить нагрузку, контролировать ход тестирования и отслеживать реакцию сотрудников на различных этапах проведения проверки. Рисунок 9. Активные мероприятия Результаты атакБыли получены следующие результаты:Иммунность — 81 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 71 %.Уровень риска — 8, средний. Устойчивость формируется, но есть ещё риски. Рисунок 10. Общая информация после проведения первичного тестирования Самый низкий уровень иммунности — около 50 %, после первых двух волн атак. Рисунок 11. График иммунности во время первичного тестирования Далее — сформировали в системе отчёт по скомпрометированности сотрудников, на основании которого выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Рисунок 12. Отчёт по скомпрометированности всех сотрудников в Phishman 2.35 Таблица 1. Результаты первичного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот04,76 %4,76 %Продажи04,76 %9,52 %Продюсеры 0023,8 %Редакция0019,04 %Руководитель000 ОбучениеПервичное тестирование завершено, поэтому следующим этапом стало определение группы риска и формирование программы обучения.Формирование учебной группыНа этапе отбора рассматривались два варианта формирования учебной группы. Первый предполагал использование показателя иммунности сотрудников. Второй вариант заключался в создании правила, автоматически формирующего список сотрудников, которые были скомпрометированы в ходе проведённых проверок. Этот подход позволял сразу получить выборку пользователей, продемонстрировавших наибольшую подверженность атакам, без ожидания обновления показателей.Был выбран второй вариант. На основании созданного правила была сформирована группа для обучения: в неё вошли люди, которые были скомпрометированы в ходе первичного тестирования. Рисунок 13. Создание правила для выявления группы риска Рисунок 14. Отчёт по отработанному правилу для выявления группы риска Отдельно была сформирована группа сотрудников, успешно распознавших фишинговую атаку, для участия в обучении, направленном на поддержание киберкультуры.Составление образовательной программы по повышению киберкультурыПопавшиеся сотрудники были включены в отдельную учебную группу, для которой сформировали персональную образовательную траекторию. В неё вошли 3 микрокурса по фишингу и 1 курс по информационной безопасности. Содержание траектории было направлено на повышение устойчивости к методам социальной инженерии и снижение вероятности компрометации учётных данных. Рисунок 15. Заполнение параметров обучения сотрудников Рисунок 16. Составление учебной программы Отдельно была запущена программа обучения для сотрудников, которые не попали в выборку по результатам правила.Процесс обучения и его результатыПервый отчёт мы сформировали через 2 дня после запуска обучения, что позволило получить предварительную оценку вовлечённости сотрудников. Анализ данных показал, что наибольшую активность на начальном этапе продемонстрировали сотрудники, которые попались на фишинг. Рисунок 17. Промежуточный анализ обучения Через неделю после запуска обучения провели повторный анализ прогресса, включая оценку прохождения курсов и выявление участников, не приступивших к обучению. Рисунок 18. Отчёт по динамике обучения в Phishman 2.35 Анализ показал, что часть сотрудников не завершила обучение в установленный срок. Для обеспечения максимального охвата было принято решение о продлении сроков прохождения курсов. Рисунок 19. Продление и корректировка процесса обучения В результате фактическая продолжительность обучения составила 2 недели, что превысило первоначально установленный срок в одну неделю. Но и этого времени не хватило нашим сотрудникам. Чтобы узнать, кто оказался более ответственным, воспользовались возможностями правил. Рисунок 20. Пример настройки правила по выявлению сотрудников, прошедших обучение В результате была получена информация о сотрудниках, полностью и частично прошедших обучение. Рисунок 21. Отчёт по сработанному правилу по выявлению сотрудников, прошедших обучение Рисунок 22. Отчёт по сработанному правилу по выявлению сотрудников, частично прошедших обучение Результаты обучения:полностью прошли обучение — 52 %;частично — 22 %;не прошли обучение — 26 %.Мы проанализировали список сотрудников, не приступивших к обучению, и выяснили, что это те, кто не попался на фишинг во время первичного тестирования.Среди сотрудников, которые попались на фишинг, 80 % прошли обучение, остальные — прошли его частично. Рисунок 23. Результаты обучения сотрудников «АМ Медиа» Вместе с тем за этот период были зафиксированы положительные изменения в ключевых показателях: уровень обученности достиг 9 319 баллов, а показатель киберосознанности — 7 561 баллов. Несмотря на положительную динамику, полученные значения оставались гораздо ниже целевых ориентиров, что свидетельствует о необходимости дальнейшей работы по повышению вовлечённости сотрудников и развитию киберкультуры.Повторное тестированиеПовторное тестирование проводилось по тем же этапам, что и первичное: подготовка шаблонов, тестирование и проведение атак. Как и на первом этапе, основной задачей было сделать письмо максимально похожим на стандартную рабочую переписку, соответствующую реальным бизнес-процессам нашей компании.Подготовительный этап повторного тестирования потребовал дополнительных временных затрат, связанных с регистрацией новых доменов и расширением сценариев атак с учётом результатов первичного тестирования.Волна 1. Сценарии формировались не только для отдельных подразделений, но и адресно для конкретных сотрудников, что позволило повысить реалистичность и точность имитации фишинговых атак. Запустили несколько атак, для каждой из них были разработаны индивидуальные шаблоны электронных писем и соответствующие фишинговые формы. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 24. Пример фишингового письма для первой волны Рисунок 25. Пример фишинговой формы для письма из первой волны Волна 2. Вторая волна представляла собой массовую фишинговую кампанию. Для неё был создан и настроен пользовательский шаблон, основанный на триггерах срочности и страхе финансовых потерь. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки. Рисунок 26. Пример фишингового письма для второй волны Тестирование доставки писем и корректности отражения результатов в статистике прошло успешно.Результаты атакВ повторном тестировании приняли участие уже 23 человека. Увеличение числа участников на 2 человека связано с подключением новых сотрудников к нашему эксперименту. Резких скачков иммунности здесь не наблюдалось. Рисунок 27. График иммунности во время повторного тестирования Для дополнительной оценки мы и здесь также выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Таблица 2. Результаты повторного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот000Продажи008,7 %Продюсеры 008,7 %Редакция8,7 %08,7 %Руководитель000 Мы также посмотрели, как себя показали сотрудники, которые не прошли обучение, в повторном фишинговом тесте. По данным отчёта, в первой волне повторного тестирования на фишинг попались 40% из всех, кто не обучался. Рисунок 28. Поиск информации о сотруднике в отчёте по атакам Подведение итогов После завершения всех этапов эксперимента мы получили следующие показатели:Иммунность — 76 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 91,3 %.Уровень риска — 7, средний. Рисунок 29. Информационная панель Phishman 2.35 после завершения эксперимента После обучения и повторного тестирования добавились другие показатели:Обученность — 11 / 100. Знания отсутствуют, обучение следует начать с базового уровня.Киберосознанность — 10 / 100. Низкий уровень, сотрудники не знают, как действовать в случае угроз.Часть результатов сравнили и представили их в таблице ниже. Таблица 3. Сравнение показателей киберкультуры до и после обученияПоказательДо обученияПосле обученияОбученность09319Иммунность81 %76 %Киберосознанность 07561Охват аудитории (повторно попались на фишинг)71 %91,3 %Уровень риска87 Также проанализировали действия сотрудников после обучения и сравнили их с результатами первичного тестирования. Таблица 4. Сравнение действий сотрудников до обучения и послеОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДо обученияПосле обученияДо обученияПосле обученияДо обученияПосле обученияДокументооборот004,76 %04,76 %0Продажи004,76 %09,52 %8,7 %Продюсеры 000023,8 %8,7 %Редакция08,7 %0019,04 %8,7 %Руководитель000000 Рисунок 30. Процент попавшихся на фишинг до обучения и после по отделам Если во время первичного тестирования попалось 22 % участников, то после обучения этот показатель уменьшился и стал 12 %. Рисунок 31. Общий процент попавшихся на фишинг до обучения и после Результаты повторного тестирования показали, что, несмотря на заметное снижение количества взаимодействий с фишинговыми письмами, часть сотрудников по-прежнему выполняет действия, свидетельствующие о подверженности атакам. Это ожидаемый результат, поскольку киберкультуру невозможно сформировать за столь короткое время. Речь идёт о длительном процессе, который требует регулярной работы как со стороны специалистов по информационной безопасности, так и со стороны самих сотрудников.Наш эксперимент позволил проверить знания сотрудников, провести обучение и затем оценить, насколько полученные знания закрепились на практике. Однако с точки зрения развития киберкультуры — это лишь один из этапов работы, а не её завершение.Сложности, с которыми мы столкнулисьОсобенность нашего эксперимента — организация предварительного тестирования. Перед запуском каждой атаки мы проверяли её работу на собственном аккаунте, чтобы убедиться в корректной отработке сценария на стороне пользователя. Такие проверки попадали в общую статистику системы и оказывали влияние на итоговые показатели. Возможность исключить подобные события из расчётов отсутствует. Согласно комментариям вендора, для этих целей следует использовать отдельный тестовый стенд. Поэтому мы вели дополнительно самостоятельный анализ результатов эксперимента.Отдельные сложности возникли на этапе обучения сотрудников. Завершить обучение в установленные сроки не удалось из-за человеческого фактора. Не все участники смогли своевременно пройти назначенные материалы, что потребовало увеличения периода обучения и дополнительного контроля за его прохождением.Впечатления от проекта команды «АМ Медиа»Проведение тестирования не вызвало негативной реакции со стороны сотрудников. Хотя фишинговые сообщения активно обсуждались внутри коллектива, жалоб руководству или недовольства вида «зачем вообще было устраивать такую проверку» не возникло. Основной интерес был сосредоточен вокруг самих писем и попыток понять, что именно происходит.Реакция сотрудниковОдним из самых любопытных наблюдений стала реакция сотрудников после первой волны первичного тестирования. Полученные фишинговые сообщения быстро стали предметом обсуждения: сотрудники пересылали их друг другу, задавали вопросы коллегам и пытались разобраться, что происходит.Некоторые пошли ещё дальше и вступали в переписку с отправителем, воспринимая фишинговые письма как реальные рабочие сообщения. Это наглядно показало не только убедительность используемых сценариев, но и то, что практическое столкновение с угрозой вовлекает сотрудников в тему ИБ гораздо сильнее, чем абстрактные примеры из учебных материалов. Во время повторного тестирования такой реакции уже не возникло.Реакция организаторовЕсли для большинства сотрудников тестирование выглядело как неожиданно появившиеся письма в почте, то для команды, которой было поручено тестирование Phishman 2.35 этот проект сопровождался совсем другими эмоциями. Подготовка сценариев, запуск атак и ожидание результатов вызывали ощутимое волнение. Оказалось, что смотреть на ситуацию глазами злоумышленника не так просто, как может показаться со стороны. Приходилось постоянно задавать себе вопросы: какой сценарий покажется правдоподобным, что привлечёт внимание сотрудника, а что, наоборот, вызовет подозрения.Самыми напряжёнными были дни первой волны тестирования. На этом этапе ещё не было понимания, как сотрудники отреагируют на рассылки, насколько убедительными окажутся сценарии и не вызовет ли проверка негативной реакции внутри коллектива. С каждой новой зафиксированной активностью интерес смешивался с тревогой, а результаты ожидались едва ли не с большим нетерпением, чем сам запуск кампании.После завершения эксперимента стало легче: всё задуманное удалось реализовать, результаты были получены и проанализированы. Тем не менее полностью избавиться от мыслей о проделанной работе не получилось. Время от времени возвращаешься к отдельным этапам и задаёшься вопросом: а стоило ли сделать именно так? Может быть, какой-то сценарий можно было построить иначе, а какие-то решения принять по-другому?Наверное, это естественная часть любого практического проекта. Когда работа заканчивается, появляется возможность посмотреть на неё со стороны и критически оценить собственные решения. Именно в такие моменты часто приходят идеи, которые помогают сделать следующие проекты лучше.Сотрудничество с вендоромВ ходе подготовки и проведения эксперимента иногда возникали вопросы, связанные с настройкой платформы, особенностями реализации отдельных сценариев и интерпретацией результатов. Для их решения использовались как переписка, так и рабочие созвоны. Запросы обрабатывались оперативно, что позволяло своевременно получать необходимую информацию и не допускать задержек в выполнении работ. Поддержка была доступна не только в рабочее время, но и в выходные дни.ВыводыПовторное тестирование показало, что тщательно подготовленные и персонализированные фишинговые атаки значительно эффективнее. При наличии качественной разведки злоумышленники способны подобрать убедительный сценарий практически для любого сотрудника. А если специалист может ошибиться, то сотруднику, который не занимается вопросами ИБ каждый день, сделать это ещё проще.Работа в сфере информационной безопасности или информационных технологий сама по себе не защищает человека от фишинга, социальной инженерии и других современных атак. Мы убедились в этом на собственном опыте: даже профильные знания не гарантируют, что человек не попадется на хорошо продуманную атаку. Злоумышленники постоянно меняют сценарии, поэтому знания, полученные однажды, быстро устаревают.При помощи эксперимента мы не только проверили, насколько сотрудники готовы распознавать атаки, но и поняли, как с помощью Phishman 2.35 можно сделать работу по развитию киберкультуры системной. Вместо отдельных курсов появился понятный цикл: смоделировать атаку, оценить реакцию, провести обучение и проверить, изменилось ли поведение участников. При необходимости — повторить или скорректировать процесс при помощи рекомендаций платформы. Результаты фиксируются автоматически, поэтому можно видеть, какие темы требуют больше внимания, и развивать киберкультуру на основе реальных данных, а не предположений.Читать далее
    • PR55.RP55
    • santy
      RP55, есть у тебя ТГ?
×