41% сотрудников российских компаний не распознают фишинговые письма

41% сотрудников российских компаний не распознают фишинговые письма

41% сотрудников российских компаний не распознают фишинговые письма

Компания RED Security проанализировала результаты проектов по обучению киберграмотности сотрудников в российских организациях. Согласно данным платформы RED Security Awareness, до прохождения обучения 41% работников не отличают фишинговые письма и переходят по вредоносным ссылкам или открывают вложения.

Каждый третий сотрудник вводит на поддельных сайтах логины и пароли от корпоративных учётных записей.

Исследование проводилось на основе симуляций фишинговых атак: с начала года семь тысяч сотрудников из крупных компаний получили тестовые рассылки, имитирующие реальные письма злоумышленников. Все действия пользователей фиксировались и анализировались, чтобы оценить уровень их киберграмотности.

Результаты оказались тревожными:

  • 41% сотрудников переходят по подозрительным ссылкам или открывают вложения;
  • 34% вводят корпоративные данные на поддельных страницах;
  • 13% делают это несколько раз подряд, если не получают ожидаемого результата.

По словам специалистов RED Security, в реальной атаке такие действия с высокой вероятностью привели бы к взлому корпоративной инфраструктуры. В отчётах центра мониторинга компании отмечается, что фишинг и использование реальных учётных записей сотрудников — самые распространённые методы первоначального проникновения в сеть.

Отдельно эксперты предупреждают, что фишинговые рассылки становятся всё более качественными и персонализированными. Этому способствует активное использование злоумышленниками технологий искусственного интеллекта: по данным RED Security SOC, количество писем с признаками применения ИИ выросло на 53% по сравнению с прошлым годом.

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

«В прошлом году 28% работников вводили свои логины и пароли на поддельных сайтах, сейчас — уже 34%. Компании должны выстраивать системное обучение персонала, иначе риск инцидентов будет только расти».

Тестовые письма для сотрудников напоминали обычные внутренние уведомления — о запуске нового портала ДМС, опросах по качеству кофе в офисе или корпоративных бонусных программах.

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

Не просто сканер, а разбор находок: SASTAV вынесли в формат ИБ-сервиса

ShiftLeft Security, разработчик платформы анализа защищённости исходного кода SASTAV, объявила о партнёрстве с провайдерами управляемых сервисов ИБ, включая системного интегратора УЦСБ. Теперь заказчики смогут передавать проверку кода и валидацию уязвимостей внешним экспертным командам.

Модель рассчитана на одну из частых проблем при работе с SAST-инструментами — большое количество ложноположительных срабатываний.

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

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

SASTAV может анализировать разные части приложения: бэкенд-сервисы, frontend, API-контуры и инфраструктурные манифесты. При оценке учитываются архитектура и бизнес-логика конкретного проекта, а критичность находок ранжируется с учётом вероятности эксплуатации.

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

Границы работ, технологический стек и объём проверяемого кода фиксируются в техническом задании. Такой формат позволяет компаниям получать внешнюю оценку защищённости разработки без необходимости полностью переносить эту нагрузку на собственные ИБ-ресурсы.

RSS: Новости на портале Anti-Malware.ru