Социальная инженерия серьезная угроза безопасности при работе служб поддержки

Социальная инженерия серьезная угроза безопасности в работе служб поддержки

Компания RSA, подразделение безопасности корпорации EMC, обнародовала результаты нового опроса SANS Institute, посвященного угрозам нарушения конфиденциальности данных, к которым может привести работа служб  поддержки.

Опрос SANS «Безопасность и конфиденциальность при работе служб поддержки» за 2013 год, в котором приняло участие более 900 ИТ-специалистов со всего мира, выявляет наиболее распространенные уязвимости в работе служб поддержки и предлагает рекомендации, которые помогут организациям устранить эти критически важные проблемы. Результаты опроса касаются регламентации рабочих процессов служб поддержки в организациях, а также процедур и действий персонала служб поддержки, которые потенциально могут повлиять на безопасность предприятия.

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

Большинство респондентов (69%) назвали социальную инженерию самой серьезной угрозой безопасности при работе служб поддержки.  Однако в большинстве организаций для идентификации пользователей, обращающихся в службу поддержки, по-прежнему используются базовые личные данные (имя/подразделение и идентификационный номер сотрудника) — информация, которую злоумышленник может найти без особенных сложностей.  Кроме того, многие сотрудники служб поддержки обходят проверки безопасности в стремлении  оказать помощь пользователям быстро и эффективно.

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

Другие интересные  результаты исследования:

  • 44% респондентов считают, что верификация пользователей при обращении в службу поддержки представляет существенно большую угрозу, чем верификация пользователей, находящихся на самообслуживании (11% респондентов).
  • Только 10% респондентов оценили процедуры безопасности в своей организации как надежные.
  • Почти 43% респондентов не учитывают стоимость инцидентов, подвергающих угрозе безопасность данных, при утверждении бюджета, выделяемого на службы поддержки, который чаще определяется в зависимости от количества пользователей.

Обращение в службу поддержки для сотрудников остается предпочтительным способом разрешения базовых проблем, связанных с ИТГлавным в работе службы поддержки является наилучшее обслуживание пользователей, и поэтому специалисты службы поддержки могут обладать расширенными правами, что делает их привлекательной мишенью для социальных инженеров и технических хакеров, пытающихся получить доступ к корпоративным сетям.  Чтобы устранить уязвимости в организации работы служб поддержки, организациям необходимо пересмотреть свой подход к обеспечению удобства пользователей и большее внимание уделять защите от угроз. Рекомендуемые передовые практики:

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

Мнение руководителя RSA

Сэм Карри (Sam Curry), главный технолог компании RSA, подразделения безопасности корпорации EMC

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

Торвальдс охладил хайп: Rust и ИИ не спасут Linux от плохого кода

Линус Торвальдс снова разложил всё по полкам и без лишнего поклонения модным технологиям. На Open Source Summit India 2026 создатель Linux рассказал, что ядро развивается без блокбастерных релизов: не резкие скачки, а спокойное постоянное улучшение. Такой подход он предпочитает с тех пор, как появился Git.

По словам Торвальдса, ИИ начал находить интересные баги, и это заметно напрягает сообщество.

Проблема не только в реальных уязвимостях, но и в мусоре: LLM могут генерировать отчёты, которые выглядят правдоподобно, но оказываются галлюцинациями. Людям потом приходится тратить время, чтобы доказать, что ошибки на самом деле не существует.

Торвальдс признал, что сам почти не пишет код и теперь скорее руководит разработкой, чем программирует. Его работа — понимать общий смысл изменений, разбирать пулл-реквесты и следить, чтобы в ядро не прилетало что попало в последний момент. Технические баги, говорит он, чинить проще, чем человеческие конфликты.

Отдельно досталось Rust. Торвальдс считает язык интересным, но не верит, что он захватит мир. По его словам, Rust помогает избежать части простых ошибок, характерных для C, но не спасает от плохой логики. Если программист написал неправильный код, язык за него думать не начнёт. А в смешанных C/Rust-проектах гарантии Rust работают только там, где код действительно остаётся внутри Rust-модулей.

ИИ Торвальдс тоже не списывает со счетов. Он использует LLM для собственных небольших проектов и прототипов, но для исправлений уровня ядра Linux, по его мнению, такие инструменты пока недостаточно надёжны. Если ИИ нашёл баг, мало просто закинуть отчёт разработчикам, нужен человек, который проверит проблему, предложит патч и доведёт обсуждение до результата.

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