Customer journey map и кибербезопасность

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

Удобство vs безопасность? Надо ли их противопоставлять?  

Да, мы часто считаем (и это даже уже как-то у нас засело в голове), что безопасность — это всегда неудобство и с этим надо просто мириться. Но это не так. В 1975-м году двумя исследователями, Джеромом Зельтцером и Майклом Шредером, были сформулированы принципы проектирования и построения защищенных систем, среди которых был так называемый принцип психологической приемлемости, звучавший следующим образом:

Очень важно, чтобы интерфейс взаимодействия с пользователем был удобным в использовании; чтобы пользователи запросто и на “автомате” использовали механизмы защиты правильным образом. Если образ защиты в уме пользователя будет соответствовать тем механизмам, которые он использует на практике, то ошибки будут минимизированы. Если же пользователь должен переводить представляемый ему образ на совершенной иной “язык”,  он обязательно будет делать ошибки.

Почему же мы до сих пор не следуем правилу, сформулированному почти 50 лет назад? На самом деле все просто (на мой взгляд). Мы оторваны от тех, кого мы защищаем!

Информационная безопасность пользователя или информационная безопасность для пользователя?

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

Хороший тест: попросите вендора ИБ-решений, особенно если он предлагает решения для оконечных устройств, в том числе и мобильных, прислать доказательства наличия у него команды по UI/UX-тестированию его продуктов. Даже если просто спросить сейла, который с вами общается, что он может сказать про UI/UX-тестирование продаваемых им продуктов, то это будет простым маркером. И да, это не про нагрузочное или функциональное тестирование, которым обычно занимается команда QA. И это не тестирование безопасности или совместимости.

Давайте еще раз вернемся в прошлое и посмотрим на мою заметку шестилетней давности. Там приводится статистика объемов продаж по результатам внедрения механизма защиты платежных транзакций 3D Secure. Так вот его включение приводит к 10-20-типроцентному падению!

Еще раз! Внедрение механизма ИБ делает только хуже для бизнеса, который этот механизм призван защищать. 

И вот тут мы вплотную подходим к тому, с чего я начал, а именно к словосочетанию “клиентский путь” (customer journey или customer journey map), который описывать весь маршрут движения клиента при достижении своей цели, включая и все точки контакта пользователя с неким продуктом, услугой или компанией. С точки зрения прикладной математики CJM можно представить как ориентированный граф, в котором его вершины представляют собой способы взаимодействия с пользователем, а ветви — каналы взаимодействия. При этом, в зависимости от того, речь идет о программном продукте, системе или целой услуге, способы и каналы взаимодействия могут быть совсем разные — приложения, оффлайновые точки продаж, клиентские офисы, всплывающие окна в браузере или на десктопе и т.п. Есть такие способы и каналы и в ИБ. Например, ввести логин и пароль, нажать кнопку подтверждения по cookie, согласиться с уведомлением об обработке ПДн в соответствие с ФЗ-152…

Если проводить аналогию, то CJM — это как модель угроз, которая показывает, КТО, КУДА и КАК будет атаковать. Такая карта позволяет увидеть всю картинку целиком, что очень важно для запуска удобного продукта или услуги, а также выявления узких мест, “бутылочных горлышек“ и т.п.

Пример с 3D Secure выше как раз показывает, что слабым звеном в цепочке взаимодействия с клиентом был как раз механизм защиты, который приводил к увеличению времени на закрытие сделки (пока прилетит одноразовый код по SMS, пока мы его введем…), что и приводило в свою очередь к оттоку клиентов, нелюбящих ждать. Если пойти дальше, то мы поймем, что ИБ очень часто и является таким “бутылочным горлышком” и камнем преткновения на клиентском пути — постоянно всплывающие окна с требованием повторно ввести логин/пароль после таймаута неактивности, требования согласиться с обработкой cookies, уведомления об обработке ПДн на весь экран, капчи, многофакторная аутентификация и т.п. Да, все эти механизмы важны и нужны (наверное), но именно от того, как они реализованы и зависит удобство пользователя и его желание и дальше пользоваться вашими продуктами и услугами и приносить нам деньги.

Где брать CJM? Если у вас активно развита собственная разработка, то CJM должна быть у менеджеров проектов, отвечающих за разрабатываемые сервисы и продукты. Причем путей на ней у вас будет несколько (под разные сценарии). Например, регистрация в ДБО, смена пароля в ДБО, перевод денежных средств в ДБО, контакт с банком через ДБО, оформление кредита в ДБО… — это все разные сценарии, каждый из которых имеет свой путь и свои защитные механизмы на нем.

Важно! Механизмы защиты являются частью CJM (независимо того, встроенные они или наложенные) и их надо учитывать при оценке клиентского пути.

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

Задача ИБ — помочь бизнесу зарабатывать деньги, снижая риски в своей зоне ответственности.

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

Для работы с CJM не обязательно иметь сложные и дорогостоящие программные продукты. Многие используют для этого либо доску, либо листы большого формата, на котором все вершины и ветви CJM отрисовываются вручную. Можно также использовать стикеры Post-It или даже Excel. Но если у вас такой продукт есть, то работать с ним гораздо удобнее. Это могут быть решения класса Application Performance Monitoring. Они заточены под ИТшные нужды, но могут показывать болевые точки приложений, в том числе и с точки зрения приложений. Их отличие в том, что они позволяют оценивать работу приложений с точки зрения различных срезов, ставить маркеры и триггеры, оценивать метрики и получать уведомления, если происходят отклонения от пороговых значений.

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

Это могут быть и специализированные решения для построения CJM, которые позволяют контролировать и оценивать деятельность каждого сотрудника компании, обслуживающего клиента (внешнего или внутреннего). Можно оценить сколько времени тратится на каждую операцию и подумать над улучшением как отдельных процедур, так и всего в процесса в целом. Кстати, эти решения можно применить и для деятельности ИБ, например, для SOCа, оценивая время, затрачиваемое аналитиками L1-L3 на обработку инцидентов и связанные с ними процессами (TI, TH и т.п.).

Упс… Мы пришли к тому, что ИБ может влиять на бизнес и показывать вклад в него?! Да, ровно об этом и заметка 🙂

ЗЫ. А завтра мы продолжим. Тема обширная, а у меня еще есть что сказать по ней 🙂