Соблюдение правил безопасности в компании напоминает здоровый образ жизни: все знают, что нужно делать, но в реальной жизни часто поступают по-другому.
При этом человеческий фактор — ошибки и небезопасные действия людей — причина 82% инцидентов информационной безопасности, произошедших с компаниями во всем мире в 2022 году.
Чаще всего хакеры атакуют или самих людей — сотрудников, например, по электронной почте, — или приложения — например, корпоративные системы или сайты компаний. Результат таких атак будет зависеть не от количества купленного железа и софта для защиты, а от уровня киберграмотности сотрудников, а также от того, насколько безопасный код пишут разработчики корпоративных систем. Вовлеченность людей, их активное участие в вопросах обеспечения безопасности — главный фактор, который определяет защищенность компании в условиях таких атак. В этой статье мы разберём пять типовых проблем, которые снижают вовлеченность сотрудников, и дадим пошаговый алгоритм их решения.
Кто мы:
Антифишинг — российская исследовательская компания и разработчик ПО. С 2016 года помогаем компаниям решать проблемы человеческого фактора в информационной безопасности. Продукты Антифишинга позволяют:
- научить сотрудников распознавать и предотвращать цифровые атаки, а разработчиков писать защищенный код без уязвимостей;
- сформировать требования по безопасности к ПО компании и наладить контакт с продуктовыми командами.
Проблема № 1: «Мне некогда»
Изучать информационную безопасность для многих сотрудников кажется сложным. Нужно отложить в сторону основную работу, на время забыть о домашних делах и сосредоточиться на непонятной информации. Для выполнения работы ИБ-знания кажутся лишними, поэтому сотрудники пытаются уклониться от обучения.
Они жалуются руководству на перегруженность работой и в некоторых случаях добиваются своего, получая отсрочку в прохождении назначенных курсов или даже списки с правильными ответами для прохождения тестов. Вряд ли стоит ожидать, что их поведение после такого «обучения» станет более безопасным.
Решение
Шаг 1. Покажите людям, что безопасность — приоритет компании и часть их ежедневной работы. Покажите, как лично они в своих рабочих процессах могут помочь защитить данные клиентов, корпоративные системы и результаты своей работы.
Используйте руководство по коммуникации, чтобы сотрудники узнали свою роль и поняли важность обучения.
Шаг 2. Покажите сотрудникам, что курсы по безопасности могут быть интересными и понятными. Если в других компаниях у них был негативный опыт обучения — пусть убедятся, что здесь вы подумали о них.
Заранее проверьте, что те курсы, которые им назначены, на самом деле полезно и интересно изучать.
Шаг 3. Помогите сотрудникам на практике понять, какие навыки безопасной работы могут быть нужны лично им. Отправьте имитированную фишинговую атаку с подкрепляющей обратной связью. Все, кто совершат опасные действия, получат мощную мотивацию к обучению. Все, кто сообщат об атаке, получат позитивное подкрепление от команды безопасности.
Проблема № 2: «Я всё это знаю, и мне неинтересно»
Часто такая проблема возникает с технически грамотными, продвинутыми ИТ-пользователями. Но профессиональные знания не означают, что сотрудников ИТ-подразделения не нужно обучать безопасному поведению.
Наши исследования показывают, что ситуация как раз противоположная: сотрудники ИТ-подразделений становятся жертвами атак чаще, чем, например, сотрудники отдела продаж.
Статистика опасных и безопасных действий в имитированных атаках по подразделениям компаний.
Источник: отчёт Антифишинга о защищенности сотрудников за 2021 год.
Чтобы грамотные и подготовленные люди не скучали, изучая хорошо известные им вещи, нужен дифференцированный подход. Пусть продвинутые коллеги изучают более сложные курсы и получают более сложные имитированные атаки.
Решение
Рассылка имитированных атак позволяет на практике выявить разницу в уровнях знаний и навыков. Эту разницу можно использовать для формирования групп риска. Создать группы риска можно вручную, выгрузив список сотрудников из Active Directory в Excel или Google Sheets.
К примеру, самых уязвимых сотрудников можно собрать в группу «Слабое звено» и назначить им дополнительное обучение по базовым вопросам ИБ, а затем провести серию элементарных имитированных атак для выработки навыков и проверки усвоения знаний. Для группы «ИБ-профи» подобрать более сложные модули и назначить серьёзные имитированные атаки, которые станут вызовом даже для подготовленных людей.
Другой вариант — воспользоваться инструментарием для управления группами риска в составе платформы для обучения и тренировки навыков сотрудников, если такая система имеется в организации.
Проблема № 3: «Безопасность — для безопасников…»
«…а я просто зарплату считаю / делаю свою работу».
Это ещё одно заблуждение, распространённое среди сотрудников. Преодолеть его не помогает даже указание на конкретные небезопасные действия человека, которые привели к инциденту. В ответ может прозвучать что-то в стиле «Вы безопасники, вы получаете зарплату за то, чтобы у нас всё было защищено. Это не я ошиблась, это вы меня не защитили.» Если не изменить такое отношение, в дальнейшем это приведёт к массовому саботажу обучения, жалобам руководству и развитию конфликтной ситуации.
Решение
Вовлекайте пользователей в процесс выявления инцидентов и налаживайте контакт с ними. Активное участие в защите своей компании изменит отношение сотрудников ко всему процессу безопасности. Они увидят, что от их правильных действий зависит защищенность всей компании. Объяснить роль сотрудников и вовлечь их в процессы безопасности поможет наше руководство по коммуникации.
С технической точки зрения хорошим решением для вовлечения сотрудников является специальный плагин, интегрированный в почтовый клиент или браузер.
Как только сотрудник получил подозрительное письмо, он может в один клик сообщить об этом команде безопасности, которая, в свою очередь, примет меры для защиты всей компании.
Проблема № 4: «Я и так всё знаю. Мне это не нужно»
Во многих компаниях кроме рядовых сотрудников имеются технические команды, например, разработчики и DevOps-инженеры, которые разрабатывают, поддерживают и эксплуатируют собственные ИТ-системы.
Пренебрежение безопасностью или недостаточный уровень вовлеченности со стороны этих людей может привести к более серьёзным последствиям, чем невнимательность офисного клерка.
Например, из-за уязвимости в API «Росреестра» для мобильных приложений любой желающий без какой-либо аутентификации мог получить персональные данные владельца недвижимости по его кадастровому номеру. Среди этих данных были не только ФИО, адрес и дата рождения, но и СНИЛС, данные паспорта, кадастровая стоимость.
Вовлеченность технических команд, а также специфические знания и навыки, такие как написание безопасного кода и настройка инфраструктуры — то, что критически важно для защищенности компании.
Решение
Объясните разработчикам, зачем учиться. Они тоже чрезвычайно занятые люди и не слишком охотно переключаются с написания кода на учёбу. Поэтому, как и с обычными сотрудниками, нужно наглядно продемонстрировать наличие проблемы.
Чтобы начать коммуникацию, можно предложить разработчику пройти тест Security Champion, который состоит из интересных техническому специалисту примеров и поможет оценить уровень его навыков в части написания безопасного кода.
После прохождения теста разработчик сам поймет, какие темы ему требуется подтянуть. А руководитель после проведения тестирования команды увидит, кто оказался киберчемпионом, и на кого можно рассчитывать при решении задач обеспечения безопасности.
Проблема № 5: «Не знаю, чему учиться, чтобы писать безопасно»
Во многих компаниях осознают, что безопасность кода требует дополнительных усилий, и вводят в штат должности специалистов по защищённости приложений — Application Security инженеров. Основная задача этих людей — контролировать безопасность приложений, а также проводить обучение технических команд приёмам безопасной разработки.
К сожалению, такие специалисты на рынке труда сейчас в большом дефиците. И даже если они есть в штате, невозможно приставить к каждой команде по AppSec-специалисту.
Например, у одного из наших клиентов на 6 000 разработчиков имеется лишь 14 AppSec-инженеров. С учётом занятости получается, что на каждую команду у специалиста по безопасности приложений всего 2 минуты в месяц. Это катастрофически мало.
Выход мы видим в развитии цифрового менторства — когда разработчики сами, автоматизировано получают необходимые им знания и навыки в контексте своих проектов, используемых языков и фреймворков.
Решение
Объясните, что изучать. Дайте разработчику конкретные рекомендации в контексте его проекта на языке, который он использует. Если разработчик пишет на Java, вряд ли примеры на Go помогут ему сделать код безопаснее.
Разработчики должны иметь возможность выбрать для обучения безопасной разработке один из востребованных сегодня языков — Python, Java, Go, PHP, JavaScript.
Уровень квалификации, который определён после тестирования, даёт возможность составить индивидуальный план развития навыков каждого разработчика с учётом выявленных слабых мест.
Если у вас пока нет возможности организовать полноценный процесс обучения, но уже нужно быстро повысить защищенность собственных продуктов, используйте наши рекомендации из руководства по безопасной разработке.
Гайд с рекомендациями и лучшими практиками по безопасной разработке
Заключение
Самые опасные угрозы для компаний сегодня — это угрозы человеческого фактора. Чтобы защитить компанию, нужно научить сотрудников вести себя безопасно, а разработчиков — писать безопасный код.
Решение этих задач начинается с оценки ситуации — проверки уровня подготовки пользователей и разработчиков.
Сделать это можно вручную, но в таком случае придётся потратить много времени на разработку тестов и имитированных атак, методику оценки и организацию процесса.
Более эффективный способ — использовать специализированные платформы, которые поднимут вовлеченность и помогут автоматизировано формировать нужные знания и навыки.
Например, в экосистеме Антифишинга — это продукты:
- Start AWR (ранее Антифишинг для сотрудников), который позволяет разрабатывать и проводить имитированные атаки.
- Start EDU — платформа для обучения продуктовых команд навыкам написания безопасного кода.
- Start REQ — инструмент для управления требованиями к безопасности приложений на понятном для разработчиков языке.
