Интерфейс как угроза

Меня зовут Мария Летта, я ведущий дизайнер интерфейсов в компании «Гарда».

23:14. Ночная смена в SOC — центре мониторинга, где аналитики круглосуточно разбирают сигналы о возможных атаках. Аналитик смотрит в экран шестой час. За смену пришло больше 400 алертов, первые полсотни оказались ложными. Он это понял быстро, а система — нет: система продолжает присылать предупреждения с той же частотой и с той же пометкой «высокая важность». К 340 алерту рука тянется к кнопке «Закрыть» раньше, чем глаза дочитывают текст. На 388 аналитик пропускает реальную атаку. Разбор инцидента займет неделю, а то и больше. Вывод будет стандартный: человеческий фактор. Аналитик не среагировал, значит, нужно усилить контроль, дописать регламенты, провести обучение ^[1]. Никто не посмотрит на экран, перед которым аналитик просидел шесть часов.

Это собирательная сцена, но ничего необычного в ней нет. Я часто провожу исследования, говорила с десятками аналитиков SOC, и, как правило, все они повторяют ^[2] одни и те же две мысли:

«Еще ничего не успел сделать, а уже чувствую, что отстаю». «Боюсь увидеть что-то — и не понять, что с этим делать».

Как видите, это не жалобы на неудобные кнопки — так люди описывают среду, в которой каждый день принимают решения с высокой ценой ошибки ^[3].

Мы ищем угрозу не там

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

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

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

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

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

Первый механизм: интерфейс приучает не слышать

28 марта 1979 года на атомной станции Три-Майл-Айленд в Пенсильвании частично расплавилась активная зона реактора — крупнейшая ядерная авария ^[4] в истории США.

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

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

А индикатор главного клапана показывал не его положение, а только то, что на него ушла команда. Клапан заклинило открытым, лампочка погасла, и операторы решили, что всё в порядке. Устройство пульта комиссия назвала одной из причин аварии.

С тех пор этот механизм подробно изучили. Мозг ^[5] перестает реагировать ^[6] на то, что повторяется без последствий. Поэтому мы не всегда слышим холодильник и не чувствуем запах ^[7] собственной квартиры. Это называется привыканием и в обычной жизни спасает от перегрузки. В SOC — выключает внимание ^[8] аналитика.

Феномен привыкания хорошо виден по работе больниц, где мониторы пищат постоянно. Например, в детской больнице Филадельфии исследователи ^[9] записали на видео больше 500 часов работы медсестер. Из 11 745 сигналов мониторов действий требовали только 50. Чем больше пустых сигналов медсестра слышала перед этим, тем медленнее шла к пациенту. А с каждым часом смены время реакции росло примерно на 15%. 

В SOC картина похожая. В опросах разных лет аналитики оценивают долю ложных алертов от 45% до 80% с лишним, а 73% команд называют ложные срабатывания главной проблемой обнаружения атак. 

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

Второй механизм: автоматизация отучает думать

1 июня 2009 года самолет Air France 447 летел из Рио-де-Жанейро в Париж и упал в Атлантический океан. Погибли все…

Бортовые самописцы нашли на дне океана только через два года, окончательный отчет вышел в 2012 году. Оказалось, что трубки, с помощью которых самолет измеряет скорость, забило кристаллами льда. Данные о скорости стали противоречивыми, автопилот отключился и передал управление людям. Пилоты не поняли, что самолет теряет скорость и падает. Через четыре с половиной минуты самолет ударился о воду.

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

В продуктах для информационной безопасности аналогичный механизм запускается тихо. Система сама расставляет приоритеты инцидентов. Аналитик видит готовый список и работает по нему. Через полгода он перестает сам думать о приоритетах. И это не его решение: мозг не тратит силы на задачу, которую решает машина.

Психологи называют это automation bias — склонностью доверять автоматике больше, чем себе. Проблема проявляется, когда система ошибается. Нестандартная атака, новый паттерн, что-то, чего не было в обучающих данных: система ставит «низкий приоритет» или молчит, а аналитик соглашается и не чувствует подвоха.

Здесь живет второй страх ^[10]: «Боюсь увидеть что-то и не понять, что с этим делать». Это страх не некомпетентности, а беспомощности. Если человек долго работает там, где его решения ничего не меняют, он перестает верить, что может что-то изменить. В психологии это называют выученной беспомощностью. Когда ситуация меняется и человек снова нужен, внутри уже сидит установка: система справится лучше, я только мешаю.

Получается парадокс ^[11] — чем лучше работает автоматика, тем опаснее момент, когда она ошибается. К этому моменту человек уже не думает сам, а наблюдает.

Третий механизм: налог на каждое действие

В конце 1980 годов австралийский психолог Джон Свеллер сформулировал теорию когнитивной нагрузки. Рабочая память ^[12] человека — та, в которой держится информация прямо сейчас, — вмещает только несколько элементов. Всё, что требует умственного усилия, расходует ее. Когда она заполнена, новое не усваивается, а решения становятся хуже.

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

Откройте Microsoft Sentinel (я привожу его как один из примеров, но таких продуктов огромное множество) и попробуйте ответить на простой вопрос: что сейчас происходит и что мне делать? 

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

Один такой перевод занимает секунды. За восемь часов из них складывается усталость.

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

Четвертый механизм: тревога вместо фона

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

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

Легкая, но постоянная тревога подталкивает к действию. Однако, если напряжение длится часами, это сужает мышление ^[13]. Хронический стресс ^[14] бьет по префронтальной коре — части мозга, которая отвечает за планирование, переключение между задачами и работу с неопределенностью. Человек хуже переключается, острее реагирует на неясное и быстрее устает.

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

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

Почему так вышло

Никто не делал эти продукты (надеюсь), чтобы навредить людям. Скорее, сошлись четыре фактора.

• Продукты развивались годами, команды менялись, и за интерфейс целиком никто не отвечал. Каждая команда чинила свой кусок, а общая логика ^[15] расползалась.

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

• А пользователи не жаловались. Точнее, жаловались, но не так или не тем специалистам. Говорили «неудобно», по разным причинам придумывали обходные пути и считали это частью профессии. Ведь дискомфорт, с которым живешь долго, перестает ощущаться как проблема.

• Рынок кибербезопасности продает страх. Вендор, который показывает больше угроз, выглядит убедительнее на демо, и красный дашборд продает лучше зеленого. В одном из опросов 41% аналитиков сказали, что лавина алертов стала нормой, потому что производители боятся не отметить событие, которое потом окажется важным. 

Что с этим делать

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

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

На практике это четыре решения — по одному на каждый механизм, который описан выше:

• Против привыкания — считать долю ложных срабатываний метрикой продукта, а не проблемой заказчика. Если сигнал не требует действий, он не должен выглядеть как тревога.

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

• Против лишней когнитивной нагрузки — строить интерфейс вокруг задач аналитика («что происходит, что мне делать»), а не вокруг того, как и какие данные лежат в базе.

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

Вместо вывода

Вернемся к истории про аналитика, которую я привела в самом начале статьи. 23:14, шестой час смены, 388 алерт. Теперь понятно, что происходило с его вниманием все эти часы. Сотни пустых сигналов приучили его не слышать. Автоматика отучила спорить с системой. Интерфейс по секунде забирал силы на расшифровку того, что же хотела сказать система. А красный дашборд держал в тревоге, от которой думается еще хуже.

«Человеческий фактор» в отчете об инциденте ничего не объясняет. Это просто удобный способ закрыть расследование.

Мне часто кажется, что мы много думаем о том, от кого защищаем ИТ-инфраструктуру. И почти не задумываемся о том, что сами системы делают с людьми, которые их защищают.