Геймификация при обучении и повышении осведомлённости по ИБ (Gamification on information security awareness, education and training)

“Ready Player One” (c) Ernest Cline

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


Предисловие
В Австралии в 2016 году было проведено исследование о влиянии личных качеств или личных черт личности сотрудников на результаты программы повышения осведомлённости ИБ (далее ППОИБ).
(DOI: 10.1016/j.chb.2016.11.065 "Individual differences and Information Security Awareness")

За анализируемые критерии исследователи взяли наличие самой ППОИБ, пол, возраст, 5 «больших» факторов личности (Big Five), склонность к риску.

В исследовании приняли участие 286 женщин и 219 мужчин, с возрастом от 18 до 60++, из 13 различных отраслей, имеющие различные должностные положения в организациях. Самое важное условие, это обязательное наличие программы ИБ в их организации (политики, инструкции и т.д.).

Результаты исследования:
Согласно исследованию существенное влияние на успешность ППОИБ оказывают следующие черты личности:
• Добросовестность (Big 5 - Conscientiousness) – способна повлиять положительно.
• Приятность в общении (Big 5 - Agreeableness) – способна повлиять положительно.
• Эмоциональная стабильность (Big 5 - Neuroticism) – способна повлиять отрицательно.
• Склонность к риску – способна повлиять отрицательно.

Не существенное влияние оказывают:
• Возраст
• Пол
• Открытость к новому опыту (Big 5 - Openness to experience)

Не оказывает влияния:
• Экстраверсия (Big 5 – Extraversion) – экстраверт или интраверт испытуемый.

Старшие поколения – менее склонны к риску, чем младшие.
В отношении к полу выяснилось, что женщины набирают чуть больше баллов в результатах тестирования ППОИБ, чем мужчины. Но в то же время в отношении фишинговых сообщений, – женщины оказались более восприимчивы.

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

Там же я узнал о существовании модели обучения KAB: Знания (Knowledge), Отношение (Attitudes), Поведение (Behaviour). Согласно которой, успешная ППОИБ основывается на этих 3 китах.

Например:
Если мы хотим скорректировать поведение сотрудников (к примеру меньше переходить по ссылкам в фишинговых письмах), то мы должны предоставить им соответствующие знания об угрозах\атаках\уязвимостях\ИБ политиках\инструкциях, выработать у них соответствующее отношение к этим знаниям (почему они должны им следовать) давая им корректирующие установки "как избежать проблем" или рассказывая о правилах безопасности, таким образом, выработав у них соответствующее поведение (что они должны делать).

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

В том же исследовании, упоминался другой аналитический материал - "The Human Aspects of Information Security Questionnaire" (HAIS-Q). Это некая модель, разработанная в 2014 году, для оценки угроз ИБ, направленных именно на сотрудников в рамках одной организации. Эта модель выделяет 7 ключевых доменов по которым необходимо проводить ППОИБ (о них я уже ранее писал):
- Безопасность паролей
- Безопасность электронной почты
- Безопасность информации
- Безопасность мобильных устройств
- Безопасность в Интернет
- Безопасность в социальных сетях
- Информирование об инцидентах


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

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

Платформа обучения на которой базируются курсы и игра - СДО WebTutor. Рекомендую её как очень функциональный, удобный и гибкий продукт для дистанционного обучения и управления знаниями.

Теперь немного о получившихся продуктах:
1) Курс обучения "Безопасность паролей"
Команда: администратор WebTutor (1 чел., РП), outsource-разработчик SCORM-пакета (дизайн+копирайтинг, 1 чел.), безопасник (контент+копирайтинг+требования к дизайну, 1 чел.).

Ценности: Повышение осведомлённости, лучшие практики по безопасности паролей.

2) Игра по ИБ
Команда: Внешний сервис-провайдер (команда разработчиков -> дизайн\код\сюжет\контент\ SCORM-пакет), безопасник (контент, требования к дизайну, сториттелинг, тестирование), копирайтер (сюжет + тестирование), администратор WebTutor (РП), outstaff-разработчик WebTutor (создание рейтинга игроков).

Ценности: Геймификация программы обучения, повышение вовлечённости сотрудников и эффективное усвоение знаний и навыков по ИБ.

Игра получилась с 5 глобальными доменами повышения осведомленности (2 осталось не проработано из-за некоторых ограничений в ресурсах), 15 проблемными темами в том числе фишинг, вред. ПО, вишинг, смс-мошенничество и другие (которые приводятся у меня в блоге), рейтингом игроков (делался отдельно на WebTutor со статистикой в режиме реального времени) и поощрительными призами для первых финалистов игры (кто быстрее пройдёт, того и тапки). В игре 15 блоков на 5 доменов. Каждый блок содержит правильные и неправильные ответы\решения игрока. Так вот один блок это 6,66% к прохождению игры. Если в блоке 6 вопросов - то каждый вопрос это примерно 1% к прохождению. Попыток прохождения не ограничено (но при желании можно ограничить). Таким образом пройдя успешно все 15 блоков - игрок набирает 100%. Мы опасались, что игрок попросту не будет играть до 100% (тоесть проходя все блоки на отлично и без ошибок), поэтому в какой-то момент игра давала закончить себя на 78% (это примерно 7 блоков пройденных на отлично) и предоставляла игроку финал, поздравления, эмоции. Но так как была поощрительная часть и дух сопернечества, то ограничение сняли и игра проходилась при получении 100% баллов за правильные ответы.

Я участвовал в разработке контента, сторителлинга, требований к дизайну, роботам, игровым задачкам, тестировании, сопровождении и Бог знает чего ещё. По сюжету игрока вызывают на помощь в подразделение безопасности, дают ему очки для погружения в корпоративное киберпространство и он должен "спасти компанию" от растущего кол-ва кибератак ;)

Адаптивная многофакторная аутентификация (Adapting multifactor authentication)

(c) Ram Dass (Kali Linux)

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


Небольшая предыстория
В начале было слово и слово это было не просто слово, а набор слов, – целое требование в ТЗ  нового разрабатываемого клиентского веб-сервиса в целях цифровизации "офлайнового" бизнес-процесса. Требование звучало так: "Реализовать механизм двухфакторной аутентификации".

На определённом этапе разработки клиентского сервиса в целях формирования и реализации потребностей клиентов  – была сформирована фокус-группа пользователей от крупных клиентов организации. Для них в определённый момент был опубликован предварительный тестовый инстанс веб-сервиса с минимально реализованным к тому времени функционалом. Доступ предоставлялся по клиентскому IP-адресу (да, не очень удобно, зато секьюрно). Также почти сразу, мы закрыли веб-приложение WAF-ом в режиме Prevent, причём без каких-либо костылей, и это было лучшим решением в плане безопасности. В таком режиме разработки и тестирования сервиса прошло примерно 10 месяцев и мы, наконец, дошли до фазы проекта – реализация требований безопасности.

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

1. Поиск и исправление всех обнаруженных уязвимостей приложения всеми доступными нам средствами (проверяли приложение на соответствие требованиям стандарта OWASP ASVS, запускали различные сканеры уязвимостей SAST\DAST и т.д.)
2. Разработка процессов системы безопасности приложения (регистрация пользователей, первый вход, 2-FA, сброс пароля, управление сессиями и т.д.)
3. Пентест приложения и исправление обнаруженных уязвимостей.

Когда поднялся вопрос о реализации 2FA я начал изучать вопрос и наткнулся вот на такую простую схему:

Это оказалась схема адаптивной мультифакторной аутентификации. В конце заметки будет ссылка на коммерческое решение, где можно почерпнуть много интересного в целом по данному классу решений (adaptive multifactor authentication), а также ознакомиться с более продвинутыми возможностями коммерческого продукта.

Что разъясняет эта схема?
Что веб-приложение проверяет не только 2 (или более) фактора аутентификации, но и осуществляется проверка так называемого контекста пользователя, – сверяются некие известные данные о пользователе. Например, что пользователем осуществляется вход с известного устройства, сети, браузера, определённого времени на устройстве или осуществляется проверка известного поведения пользователя, например доступ к приложению из известной геолокации, аналитика движений мыши, скорости набора текста, вход в рабочее время и т.д. Если всё ОК – второй фактор не запрашивается. Это если кратко.

Данное решение предоставляет следующие ценности:
1) Удобство (не нужно каждый раз проходить второй фактор, система "помнит" контекст клиента)
2) Повышенный риск-ориентированный уровень безопасности (система может быть настроена на проверку определённых рисков)
3) Экономический эффект (например, не нужно каждый раз отправлять платные СМС, снижается время на безопасный вход в приложение)

Никто не мешает внедрять подобное в SSO-решениях и кастомизировать под свои риски и потребности. Механизм доказывает, что можно делать безопасные решения не в ущерб функциональности и удобству:

Security Functionality Usability Triangle (c) EC-Council CEH

Рассмотрим подробнее пример реализации:
При успешном прохождении первого фактора (логин и пароль) и второго фактора (ввод кода из SMS, из Email, приложения и т.д.), веб-сервер должен запоминать контекст клиента, например связку: IP-адрес (к примеру первые 2 октета, на случай если IP-адрес клиента динамически меняется), user-agent (идентификатор браузера клиента) и далее генерировать токен аутентификации для клиентского браузера, сохраняя его в Cookies с определённым сроком жизни (зависит от контекста организации и приложения, срок жизни токена например 1 месяц). Веб-сервер под каждого успешно аутентифицированного пользователя ведёт в БД отдельную таблицу запоминаемого контекста клиента: IP-адрес, User-Agent, Token (этим не ограничено).

При следующем входе клиента – если контекст пользователя не поменялся (срок действия токена не истёк и валидный токен присутствует в Cookies браузера, IP-адрес не изменился, User-Agent тот же)  – второй фактор система не запрашивает. Если поменялось хоть что-нибудь из контекста пользователя, – инициируется запрос и проверка второго фактора (у нас это был OTP: код по SMS, email и т.д.) и выдача нового токена при успешной аутентификации. При этом ещё нужно задать ограничение на кол-во запоминаемых контекстов пользователя и при его превышении - удаление наиболее старого или сброс остальных с уведомлением. Также, например, осуществлять сброс токенов - когда при переборе паролей (атакующие сумели обойти CAPTCHA) осуществляется сброс всех токенов для данного пользователя (скажем после 100-ой попытки подбора пароля). Это для подстраховки, если атакующий изменит вектор атаки. При прохождении второго фактора и входа на сервис – отправлять пользователю email-уведомление.

Результаты
Совместно с командной разработки мы реализовали подобный механизм. Но вместо дорогого и не всегда доступного SMS-сервиса (на западе крупный бизнес давно уже от него уходит) в нашем приложении была реализована отправка кода по EMAIL. Да, не самый безопасный способ, зато самый простой и доступный в реализации (не во всех организациях разрешено на рабочем месте использовать смартфон). По сути мы перекладываем риски безопасности для второго фактора на плечи сервиса электронной почты клиента. Это не самое секьюрное решение, но в контексте нашего приложения и других механизмов безопасности – этого достаточно (по моей субъективной оценке).

Cо стороны КЛИЕНТОВ и БИЗНЕСА – к реализованному решению никаких претензий не последовало, оно показалось вполне удобным, а главное – безопасным.

Также, механизм прошёл успешный аудит безопасности командой пентестеров (топовый сервис-провайдер в РФ). По методике OWASP Testing Guide (раздел OTG-AUTHN-XXX) – уязвимостей не обнаружено.

"Я считаю это успех! Машина времени работает!" (с)

p.s. Помните, мало просто внедрить 2FA, надо убедиться, что нет других уязвимостей, например, перехвата сессии или отсутствия ограничения на кол-во одновременных сессий и т.д., чтобы всё не оказалось напрасным. Также, надо всё самому проверять, особенно логику процессов безопасности. Разработчики и тестировщики могут пропустить.


Коммерческие решения
Как обещал, хорошая презентация по этой теме и, на мой взгляд, интересный коммерческий продукт и его возможности:

• https://www.slideshare.net/SecureAuth2FASSO/why-twofactor-isnt-enough
• https://www.secureauth.com/products/access-management/adaptive-authentication