Привет, Хабр!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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