Блог

Эвристики удобной информационной безопасности

• Цветков Максим
• 05.07.2024

Создавать потребность, менять поведение людей, их привычки и помогать людям формировать мотивации — одна из задач UX-специалиста. И как только мы сталкиваемся с задачей изменить поведение сотрудников в соответствии с требованиями безопасности компании, первое что приходит на ум — кинуть сотрудникам курсы, а следом тестовую фишинговую рассылку. Но не все так просто, давайте разбираться.

Мы хотим изменить поведение сотрудников, и для этого нужно понять, какое поведение считается ожидаемым. Другими словами, нужно определить цели. Цели должны быть как можно более конкретными, а не расплывчатыми, и описаны по SMART. Обычно нам интересны краткосрочные цели с позитивным результатом, которые оцениваются по факту, а не по формальным метрикам. И самое главное, цели строятся от оценки рисков. Оценка рисков происходит по трем уровням: severity, frequency, criticality.

Самая известная модель смены поведения, которой уже более 40 лет, это transtheoretical model. Она состоит из 6 шагов, в которых описаны состояния эволюции сотрудника от неосознанного нежелательного поведения к желаемому поведению:

• Precontemplation — не хочет менять свое поведение, не в курсе последствий своего поведения.
• Contemplation — хочет измениться в течении следующего полугода. Знают и плюсах и сложностях процесса.
• Preparation — готовится измениться за следующий месяц, сделал подготовительные шаги, такие как вошел в группы поддержки, нашел тренера, купил книжки, подписался на каналы.
• Action — за прошедщие полгода, сделал заметные изменения.
• Maintenance — поддерживает привычки,
• Termination — нет желания вернуться к прежним привычкам

Есть и другие модели, например information motivation behavioral skills model, или behavior change wheel, COM-B model.

Но все эти модели объединяют некие ключевые принципы, без понимания которых не удастся изменить поведение людей. Например, обычно люди легко готовы пожертвовать безопасностью ради вознаграждения или просто удобства. Например, мы требуем создавать надежный пароль, где не менее n-символов. Вроде как просто и понятно. Но у человека могут быть проблемы с памятью, зрением, и после 10 попыток придумать надежный пароль, человек может попросту взбеситься. И отдать придумывание пароля своему ребенку. На моем опыте, использование менеджеров паролей и легко запоминающихся паролей приводит к улучшению общей защиты. Поощрение использования кодовых фраз вместо сложных паролей позволяет найти баланс между безопасностью и удобством использования.

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

Моя личная модель смены поведения выглядит так:

1. Выяснить проблему. Какую проблему мы хотим решить, какого поведения мы хотим достичь. Для начала наблюдает за текущим поведением, анализируем его, и на основе текущего поведения формирует видение нового.
2. Контекст / окружение. Более детально смотрим на текущее поведение, изучаем эффект от нашего потенциального вмешательства, учитываем культурный контекст, нюансы юзабилити. Обязательно учитываем ограничения сотрудников по навыкам, мотивации, знаниям.
3. Делаем решение. Например, это может быть всего лишь общение с сотрудниками, и выявление секурити-чемпионов.
4. Применяем решение. С метриками.
5. Определяем влияние и эффект нашего вмешательства.

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

1. концептуальные (идеи, гипотезы)
2. процедурные (инструкции, методы)
3. регламенты
4. эмпирические данные (наблюдения из исследований)
5. директивные (как прийти к конкретному результату)
6. факты
7. стимулы

Любая модель управления безопасностью состоит из людей, процессов и политик. Диаграмма ниже иллюстрирует типичный флоу принятия решений по управлению безопасностью. В левой части диаграммы представлены 3 основных исходных данных для принятия решений по управлению безопасностью: i) нормативные данные, включающие законы, правила и ценности; ii) бизнес-риски, включающие риски кибербезопасности для стратегических целей компании, бренда и репутации компании; iii) операционные риски, включающие риски кибербезопасности, возникающие в результате использования, управления и внедрения технологий. Эти исходные данные оцениваются и определяются по приоритетности комиссией, состоящей из заинтересованных сторон организации. В результате расстановки приоритетов и оценки рисков формируются процессы и технологии управления безопасностью, представленные на правой стороне диаграммы.

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

Эвристики

Эвристика это ментальные шорткаты, можно сказать что это чек-лист из готовых правил оценки интерфейса, идеи, кода. Многое уже придумано за нас. Например, перед тем как бежать проводить очередное исследование, генерировать гипотезы и нанимать агентство за весь годовой бюджет, можно почитать критерии юзабилити по ISO 9241-11.

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

1. Пользователь всегда может получить доступ к информации, имеющей отношение к безопасности
2. Система уведомляет пользователя о соответствующих изменениях в мерах безопасности
3. Система напрямую информирует пользователя об обязательных действиях по обеспечению безопасности, которые он должен выполнить
4. Система обеспечивает несколько уровней детализации безопасности, если система используется как начинающими, так и опытными пользователями
5. Система показывает только информацию о безопасности, необходимую для текущей деятельности
6. Информация, имеющая отношение к безопасности, является краткой, простой для понимания и описательна
7. Четко указано, для каких целей используется личная информация пользователей
8. Четко указано, для каких целей используется личная информация пользователей
9. Система информирует пользователя, если она находится в небезопасном состоянии
10. Терминология, связанная с безопасностью, является выразительной и последовательной
11. Терминология, связанная с безопасностью, соответствует стандартам
12. Система информирует пользователя о ходе работы, если в системе возникают задержки, связанное с функционалом безопасности

Аутентификация:

1. Аутентификация является обязательным условием для доступа к защищенным или конфиденциальным разделам
2. Пользователь может выбирать между различными вариантами аутентификации
3. Варианты аутентификации разработаны таким образом, чтобы не было чрезвычайной когнитивной нагрузки на пользователей
4. Система использует строгую политику паролей, которая но при этом проста в понимании
5. Пользователь может изменить свой пароль
6. Система информирует пользователя о политике паролей когда он задает пароль
7. По умолчанию система никогда не показывает пароль
8. Система информирует пользователя о том, была ли успешной аутентификация
9. Система блокирует повторные неудачные попытки аутентификации спустя n-количество попыток

Контроль и свобода пользователя.

1. Пользователь должен принять условия использования и политику конфиденциальности
2. Пользователь должен подтвердить передачу данных третьим лицам
3. Пользователь может выбрать между иконкой и текстовым отображением информации о статусе безопасности
4. Система предоставляет быстрые клавиши для выполнения частых задач
5. Пользователь может настраивать предпочтения в области безопасности
6. Пользователь может отменить свои операции, связанные с безопасностью
7. Пользователь может отменить операции, связанные с безопасностью, которые он инициировал
8. Пользователь должен подтвердить действия с радикальными, негативным или необратимыми последствиями
9. Пользователь может обновлять или удалять личную информацию
10. В системе реализованы принципы «Безопасность по по умолчанию» и «Конфиденциальность по умолчанию»
11. Все настройки конфиденциальности применяются ко всей система

Распознавание, диагностика и устранение ошибок.

1. Сообщения об ошибках всегда указывают на причину проблемы
2. Сообщения об ошибках информируют пользователя о серьезности проблемы
3. Сообщения об ошибках содержат информацию о действиях, которые пользователь должен предпринять
4. Сообщения об ошибках написаны на человеческом языке

Поддержка пользователей и документация.

1. Для получения доступа к документация не требуется приостанавливать выполнение задачи
2. Справка и документация следуют за последовательностью действий пользователя
3. Пользователи информируются об обновлениях в справке и документации
4. Справка и документация доступны с каждого экрана

Доступность.

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

Мы не можем обойти стороной эвристики Нильсона. Да, они устарели и могут казаться очевидными, но это база:

Видимость состояния системы:

• Есть ли четкие индикаторы потенциальных угроз или нарушений?
• Соответствие между системой и реальным миром:
• Использует ли система кибербезопасности знакомый язык и понятия? Понятны ли предупреждения и подсказки по безопасности для неспециалистов?

• Контроль и свобода пользователей: Насколько пользователи контролируют параметры и конфигурации безопасности?
• Последовательность и стандарты: Стандартизированы ли протоколы безопасности для различных платформ или устройств?
• Предотвращение ошибок: Как системы помогают пользователям предотвратить ошибки, которые могут поставить под угрозу безопасность?
• Распознавание, а не запоминание: Как кибербезопасность может минимизировать когнитивную нагрузку на пользователей при сохранении безопасности?
• Гибкость и эффективность использования: Адаптирован ли продукт для пользователей с разным уровнем знаний?
• Эстетичный и минималистичный дизайн: Как дизайн интерфейса системы кибербезопасности влияет на вовлеченность и восприятие пользователя?
• Помощь пользователям в распознавании, диагностике и восстановлении после ошибок: Имеются ли четкие инструкции или механизмы поддержки для пользователей, сталкивающихся с проблемами безопасности?
• Помощь и документация: Имеется ли удобная документация и каналы поддержки, доступные для нетехнических пользователей?

Метрики

Нам нужны метрики. Самое главное, мы считаем метрики только относительно конкретного окружения. Хорошая метрика имеет количественное выражение (не высокий/низкий). Например, количество заблокированных соединений/атак, количество устройств с необновленными базами антивируса, число запросов по вопросам ИБ. А вот, скажем, % снижения рисков ИБ это плохая метрика, даже если такую метрику выдает некая SIEM. Хорошей метрикой можно считать нечто более детальное, как устойчивость системы к XSS до и после внедрения taint checking. Список метрик есть на сайте www.securitymetrics, я обычно стараюсь добавить такие метрики в требования SLA.

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

Так как пользователи почти наверняка взаимодействуют с некой системой, то можно автоматизировать сбор неких данных. Например, процент кликов на фишинговые письма, а если открыли — то ввели ли важные данные, запустили ли вложенный в письмо файл. Как много времени прошло между фактом открытия письма и фактом запуска файла из вложения? Другая метрика это сколько раз система блокировалась из-за неактивности пользователя. Попробуем разобрать одну метрику чуть детальнее, например событие в SIEM:

Структура исходных данных

• Что в основе дампа
• Сколько синтетики
• Как синтезировалось
• Медианный (1Q) размер сообщения
• Какой поток был сгенерирован и как был подан в SIEM (вброшен в шину, собран агентами)

Структура платформы

• Сколько серверов
• Какие тех. характеристики
• Чем и как связаны (сеть)

Контент

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

Хранение:

• Хранились ли сырые события, или только нормализованные.
• Было ли настроено хранение в БД, или просто в /dev/null
• Была ли БД пустая на старте

Если настолько сложные и детальные метрики пока не соответствуют уровню зрелости организации, то всегда есть универсальная тройка: effectiveness, efficiency, and satisfaction. Effectiveness — это то, могут ли люди успешно достичь своих целей, например, может ли сотрудник быстро и легко сообщить сотрудникам службы кибербезопасности о фишинговом письме. Также играет роль психологический аспект. Я замечал, что если пользовать знает о мониторинге его компьютера, то это сказывается на эффективности выполнения задач. Помним, что для сотрудника подумать о безопасности это лишь второстепенная задача.

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

Satisfaction — пересечение физических, когнитивных и эмоциональных реакций пользователя при использовании системы, продукта или услуги, а также то, насколько хорошо удовлетворены его потребности и ожидания. Например, в контексте кибербезопасности на удовлетворенность может повлиять раздражение, которое испытывает пользователь, сталкиваясь с повторяющимися предупреждениями о безопасности. И хорошие примеры usable security: двухфакторная автентификация. Если пароль приходит быстро и нету проблем с токеном, безопасность улучшилось. Разрешить менеджеры паролей — хорошо. Наличие двухфакторной аутентификации (2-FA) с Face ID помогает снизить когнитивные усилия.

Так мы покроем все три аспекта: продукт, процесс и контекст. 

На что обратить внимание

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

• Первое, любой продукт должен легко устанавливаться: удобство использования и доступность облегчают принятие и соблюдение мер безопасности. Когда средства безопасности удобны и доступны, люди с большей вероятностью начнут их использовать.
• Второе это удобство использования: усли меры безопасности, такие как двухфакторная аутентификация (2-FA), спроектированы так что пользователю не нужно регулярно прерывать свою работу, пользователи с большей вероятностью не будут сопротивляться. Например, использование кодовых фраз вместо сложных паролей.
• Третье это не перегибать с настройкой политик доступа: юзабилити в приоритете, когда мы пытается обеспечить баланс между безопасностью и простотой использования.
• Доступность материалов: все регламенты, документы, должны быть написаны человеческим языком и быть легко доступными для всех сотрудников, только так мы имеем право требовать от сотрудников понимания протоколов безопасности и следования им.
• Учет существующего поведения: любые изменения должны учиывать существующее поведение в организации.
• Копирайтинг: представление информации о безопасности на языке организации, а не с использованием технической терминологии безопасности, делает ее более удобной и доступной для сотрудников.
• Устранение барьеров: перед тем как внедрить изменение, нужно подумать об устранении «барьеров возможностей» т.е. факторов, которые против изменений, направленных на улучшение поведения в сфере безопасности.
• Разнообразие методов доступа: предоставление различных методов доступа обеспечивает эффективное взаимодействие с системами безопасности для всех пользователей, включая тех, у кого есть особые потребности. А это в том числе и старые люди.
• Сокращение усилий: упрощение моделей поведения в сфере безопасности за счет снижения сложности и количества необходимых шагов.

Как специалист по UX, я никогда не виню пользователей. Но я стремлюсь их обучать. В данном случае пользователи это сотрудники компании. И регулярно коммуницировать с сотрудниками это обязательная часть работы специалистов по информационной безопасности. Также, ваши ИБшники не должны страдать «проклятием знаний», и общаться без терминологии и сложных технических нюансов. Не надо просить сотрудников заучить NIST, он слишком технический. Хороший пример это англоязычный plainlanguage. Также имейте ввиду, что плохое юзабилити создает угрозы, например, после внедрения требований на блокировку экрана после минуты бездействия, пользователи начнут создавать искуственные движения мышкой. И даже если ИБ компании идеально юзабельно, сотрудники все равно будут ошибаться. Просто реже.

Я прекрасно понимаю, что преступники сначала атакуют людей, и лишь потом технологии. И ребята из ИБ ненавидят терять контроль, давая сотрудникам свободу. Это всегда про поиск баланса. Просто кинуть сотрудникам курс по ИБ и ожидать от них идеального следования регламентам — бред. Сам факт наличия знаний после курсов никак не меняет поведение. Если вы хотите, чтобы пользователи отправляли сообщения о фишинговых письмах, хотя бы добавьте кнопку «сообщить и фишинге» в ваш почтовый клиент.

И немного про поведение. Если все упростить, то речь о нажатии правильных кнопочек и ненажатии неправильных. Чтобы нажатие на нужную кнопку состоялась, у пользователя должна быть мотивация (желание) и возможность (наличие прав), тогда заветная кнопочка будет кликнута. Есть еще одна составляющая — триггер. Изначально тремин «триггер» применяли к людям с ПТСР, которые не могли контролировать свои эмоции и поведение. В их случае триггером мог стать любой раздражитель: звук, запах, набор слов. Поэтому триггер это некий внешний раздражиель. К общепринятым «триггерам» при работе с интерфейсами стоит относиться как к гипотезам (и проверять их).

Триггер должен быть своевременным, т.е. не висеть на каждом экране в виде уведомления. Триггером может выступать любой сигнал, инструкция, некое внутреннее озарение пользователя. На этом сказываются индивидуальные характеристики человека. Так, Бергер писал, что на наше восприятие влияет возраст, пол, сексуальная ориентация, раса, вера, лингвистические традиции, гражданский статус, идеология. Опять же, есть методология. Она называете SCENE, в ней главная цель это привлечение заинтересованных сторон к созданию и оценке поведенческих стимулов. Для того, чтобы понять какие подталкивающие механизмы использовать, для SCENE используется MINDSPACE framework.