Security Experience (SX)

Выход на тонкий лёд

Я не встречал пока (лето 2021) ни в российском, ни в зарубежном сообществах КБ каких-либо исследований по вопросам, которые я сейчас буду рассказывать. Более того, если с термином Security UX еще можно случайно повстречаться где-то на дне интернета, то термин Security Experience (SX) я не встречал ещё нигде. Так что имейте в виду, что мы на протяжении этого поста будем находится на весьма тонком льду, аккуратнее.

Security User Experience (Security UX)

Есть такая деятельность, как User Experience (UX) или Опыт взаимодействия, если по-русски. Он теперь у нас везде, где пользователь сталкивается с каким-либо продуктом или сервисом: не важно, покупает ли он что-то на Озоне или сдаёт документы в МФЦ. Если следовать официальным определениям (ISO 9241-210), то это:

Восприятие и ответные действия пользователя, возникающие в результате использования и/или предстоящего использования продукции, системы или услуги

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

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

Первая точка имеет достаточно очевидные механизмы улучшения этого UX (вот, например, рассуждают, как за счёт UX можно даже безопасность повысить). К сожалению того же самого не скажешь о второй точке. Особенно учитывая, что как раз вокруг неё у нас и развивается токсичная культура кибербезопасности. О токсичной культуре можно почитать тут и тут, а также помедитировать над прогнозом Forrester на 2021 год:

A CISO from a Global 500 firm will be fired for instilling a toxic security culture: Toxic security team culture harms employee retention and hinders recruiting. 2021 will be a year of reckoning for leaders who create, tolerate, or ignore hostile cultures.

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

Developer Experience (DX)

Есть такие роли/команды в компаниях-разработчиках, как DX (Developer eXperience). Боб Расселман и Мэттью Броберг из RedHat так описали, что же это такое:

Developer experience describes the interactions and feelings that a developer has when working with a body of code in order to meet a specific objective. You can think of developer experience as the user experience specifically for programmers.

Они отметили, что это штука важная, так как в каких-то компаниях процессы разработки легки и непринужденны, а где-то — путь через минное поле. То есть хороший DX позволяет разработчику встать и сделать свою работу с минимальными проблемами, а плохой — отправляет на вечную битву добра и нейтралитета ("neverending battle trying to figure out what the code is supposed to do and then actually getting it to work"). Ясно, что второй вариант выливается в лишние издержки, время и, в принципе, программист вообще может однажды сказать «до свидания, я ухожу.

Как человек, считающий, что мир разработки сейчас флагман в инновациях организации эффективных процессов, я побежал в интернет за Security eXperience. Но его там не оказалось, ни в поиске, ни в англоязычном твиттер-сообществе КБ. Так что, попытаюсь самостоятельно немного приземлить этот термин.

Security Experience (SX)

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

Черты хорошего SX:

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

Черты плохого SX:

• захлёбываемся в бизнес-изменениях (business change),
• захлёбываемся в выполнении того, чем сами себя вместе со ФСТЭК нагрузили (run),
• захлёбываемся своими задачами по изменению архитектуры/процессов КБ (change),
• возникают вопросы: "а зачем мы вообще это делаем?", "как наши риски связаны с нашими действиями?",
• не можем ничего найти в своих же документах,
• на почти любой аудиторский запрос уходит большое количество времени,
• постоянная загрузка однотипными задачами и т.д.

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

Как сделать хороший SX?

К сожалению, пока никакие умные дяди (ISO, NIST, SANS и т.д.) руководства нам именно по кибербезопасности не выдали (помните, я говорил вначале про тонкий лёд?).

Так что придётся действовать согласно здравому смыслу и методом аналогий. Открываем Jesse James Garrett "The Elements of User Experience: User-Centered Design for the Web". Там весь процесс проектирования хорошего UX разделен на пять уровней (5 S's of UX).

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

Объект приложения силы

Я видел варианты от нескольких десятков гигабайт (и плакал) до "ну мы выбрали путь, чтобы у нас её не было" (привет, компаниям-разработчикам софта). Эти граничные варианты ужасны с какой стороны на них не посмотри. А еще можно вспомнить отваливающийся РС БР ИББС-2.0-2007 «Методические рекомендации по документации в области обеспечения информационной безопасности в соответствии с требованиями СТО БР ИББС-1.0» с его 4 уровнями иерархиями и вот таким ужасом:

Крайние случаи мы рассматривать, конечно, не будем, так как не особо интересно. Итак, у нас есть что-то среднее:

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

Все эти документы присутствуют в их самом типовом виде: набор пунктов с отдельными требованиями или описаниями действий.

Идентификация точек SX

Пользователи наших документов:

• в первую очередь, мы сами (в основном чтобы кого-то из бизнеса ткнуть, что он дёрнулся в какую-то не ту сторону)
• во вторую очередь, работники нашей компании (когда открывают их при устройстве на работу, закрывают и забывают)
• в третью очередь, аудиторы
• и в последнюю очередь, надзорные органы.

Остальные чайки, которые прилетают раз в тысячелетие, нас особо не волнуют.

1. Определяем стратегию SX

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

Будем использовать тут стандартную нотацию пользовательских историй (User story):

Как <роль>, я могу <возможность>, чтобы <выгода>

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

2. Переходим на уровень возможностей

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

• должен быть поиск по всей документации
• должна легко извлекаться конкретная мера кибербезопасности со всем её окружением (требования, процедуры и т.д.)
• должны быть выжимки из документа (аннотации, либретто, обзоры) для различных типов пользователей документов

• должен быть унифицированный подход к составу и содержанию документации
• и т.д.

3. Определяем структуру

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

Будем использовать в качестве Golden Source электронный справочник (например, Confluence или что-то другое wiki-подобное с хорошим поиском). Все требования и процедуры оформим отдельными сущностями и составим из них базы данных. Проведем соответствие каждого комплайенс требования с соответствующими записями в БД требований и процедур. Таким образом сможем сами отследить, что и как у нас с комплайенсом, а также со скоростью света отвечать на запросы. Ну и оформим "либретто" для каждого набора типовых пользовательских задач (для этого, кстати, неплохо бы провести предварительное исследование, чтобы выявить "боли" работников).

4. Компонуем

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

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

5. Формируем поверхность взаимодействия

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

Тут уже слишком личное.

Итого

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