People As Code. Как сделать, чтобы лингвистическая относительность не мешала защищать ИБ-активы

People As Code. Как сделать, чтобы лингвистическая относительность не мешала защищать ИБ-активы

Многочисленные исследования год за годом демонстрируют странное явление: люди являются причиной примерно 80% всех инцидентов, однако на защиту от угроз, связанных с человеческим фактором, приходится менее 3% ИБ-бюджетов. Всё остальное уходит на технические средства. В статье разберёмся в причине такой несправедливости, выясним, к чему это приводит в реальной жизни и как можно решить проблему. 

Картина маслом

По данным отчёта за 2022 год, подготовленного телекоммуникационным гигантом Verizon, человеческий фактор остаётся главной причиной всех ИБ-инцидентов. Он присутствует в 82% киберпроисшествий, будь то использование украденных учётных данных, фишинг, злоупотребление или просто ошибка конфигурации. Люди продолжают играть главную роль в инцидентах и нарушениях. Об этом говорит не только Verizon. Важность поведения сотрудников для безопасности признают практически все крупные компании. 

Но если проанализировать структуру затрат на различные системы защиты, то создаётся впечатление, что ИБ-подразделения во всём мире дружно не замечают очевидного и продолжают вкладываться в защиту сети, серверов и веб-приложений, игнорируя сотрудников (рис. 1).

Рисунок 1. Затраты на ИБ, количество происшествий и структура расходов на ИБ-решения

На долю продуктов, снижающих риски, связанные с человеческим фактором, приходится меньше 3% затрат.

В чём же причина такого нелогичного поведения? Дело в том, что всё, что связано с человеческим фактором, крайне сложно поддаётся учёту. Вот и получается, что то, что не учтено, остаётся не защищено. 

С чего начинается порядок в ИБ

Вряд ли у коллег по ИБ возникнет вопрос, о каком учёте речь, однако на всякий случай стоит уточнить, что мы говорим про учёт активов, без которого организация полноценной защиты невозможна. Порядок в ИБ начинается с порядка в ИТ-процессах. Между тем, по данным опросов, уровень удовлетворённости в ИБ хуже всего именно от управления активами. 

В идеальном мире, где царит ITSM, а инфраструктура реализована в полном соответствии с рекомендациями ITIL, проблем с учётом нет. Всё классифицировано, учтено и защищено. Однако большинству организаций до такого состояния очень далеко. Журналы SIEM переполнены алертами, но при этом часть активов выпадает из поля зрения систем мониторинга, потому что при инвентаризации о них не вспомнили. 

С техническими средствами ситуация более-менее понятна. Специалисты по ИБ вполне квалифицированно научились работать с серверами, сетевым оборудованием, шлюзами, системами IPS/IDS и прочим. Налаженный учёт активов обеспечивает качественное управление и защиту. И вроде бы картинка выглядит правильной, так что беспокоиться не о чем. До тех пор, пока не вспоминаем про поведение людей как фактор успеха 82% инцидентов. 

А где же люди?

Рисунок 2. Цепочка заражения инфостилером с помощью фишингового письма

Если посмотреть на перечень активов, которые мы защищаем от кибератак, то там найдётся всё что угодно. Кроме людей. EDR и SIEM-системы рисуют красивые цепочки заражения, на которых детально разобрано, как вредоносное ПО проникло в систему и к чему это привело. Но если присмотреться, на схеме (рис. 2) не хватает одного ключевого элемента, который расположен ровно между получением письма и запуском вложенного .LNK-файла. 

Почему ярлык запустился и произошло заражение? Кто нажал кнопку?

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

Рисунок 3. Реальная цепочка заражения. Человек — ключевой элемент

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

Если всё зависит от поведения людей, то почему мы не встречаем их на схемах с цепочками заражений? Куда подевались сотрудники, администраторы и разработчики, из-за которых происходят ИБ-инциденты? 

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

Есть сомнения? Тогда давайте посмотрим на базу данных угроз ФСТЭК. Чтобы не рисовать новые цепочки заражения, обратимся к разделу «Внедрение вредоносного ПО через электронную почту» (рис. 4).

Рисунок 4. База данных угроз ФСТЭК. Раздел «Способы реализации»

Внедрение вредоносного ПО через электронную почту невозможно без участия человека. Может показаться, что люди спрятаны где-то среди «Компонентов объектов воздействия», но это не так. Там есть ОС, браузер, клиент электронной почты и многое другое, а вот сотрудника, который открыл вредоносное письмо и запустил вредоноса в систему, нет. 

Люди остаются за скобками любых инцидентов ИБ, и это системная проблема всей отрасли. Атаки описываются так, словно человеческого фактора в них нет. Пример на рис. 5.

Рисунок 5. Атаки описываются так, словно человеческого фактора в них нет

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

Что на уме — то на языке. Или нет?

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

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

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

Всё как код

Чтобы работать с людьми и их поведением также удобно и прозрачно, как с другими активами, нужно ввести их в ИБ-язык как целостное понятие, формализовать. Реализовать это на практике можно с помощью концепции «Всё как код». 

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

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

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

Оцифровываем людей — People As Code

Для оцифровки людей мы воспользовались поведенческой моделью профессора Стэнфордского университета Брайана Джеффри Фогга. В соответствии с ней любые человеческие действия складываются из мотивации и возможностей. Чтобы действие было выполнено, требуется, чтобы один из этих показателей или оба были достаточно высоки (рис. 6).

Рисунок 6. Модель Фогга. Высокая мотивация и/или возможность = высокая вероятность действия

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

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

Когда мотивация и возможности человека описаны, их можно добавить в систему информационной безопасности и получить решение нового поколения, в котором учитывается человеческий фактор. Этот подход мы использовали при создании концепции People as Code и базы данных People CMDB.

People СMDB — это open-source-продукт, реализованный в виде базы данных управления конфигурациями сотрудников. Он представлен в виде репозитория, содержащего информацию о ролях, свойствах сотрудников (знания, навыки, мотивация, убеждения), их уровнях защищённости и других параметрах согласно методологии антифишинга. С помощью People CMDB сотрудников можно превратить из угрозы безопасности в сильный и надёжный цифровой актив.

В рамках концепции People as Code роли людей, их доступы и возможность влиять на недопустимые события описываются в виде структуры данных (JSON-файла). Критически важно наличие следующих пунктов:

• бизнес-цели,
• недопустимые события,
• сценарии недопустимых событий,
• опасные действия,
• безопасные действия,
• сотрудники,
• роли,
• курсы,
• имитированные атаки.

От каждого из этих пунктов будет зависеть информационная безопасность компании.

Более детально с концепцией можно познакомиться на гитхабе антифишинга. Там приведены примеры на специфичном DSL-языке для интеграции People CMDB со средствами защиты и реализации концепции People as Code в ключевых процессах управления безопасностью.

Заключение. Homo Digitalis как ИБ-актив

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

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

Чтобы превратить людей в управляемый и понятный актив, нужно оцифровать их, используя подход «Всё как код» (Everything as Code). По аналогии с системами Documents as code, Governance as code и Infrastructure as code мы создали систему People as code и назвали нашу разработку People СMDB. Она позволяет мотивировать сотрудников обходить угрозы и объясняет, как это сделать.

Внедрение People CMDB в организации избавит ИБ-специалистов от составления бесконечных регламентов, которые никто не читает, и позволит полноценно управлять рисками, вовлечённостью, мотивацией и производительностью людей.

В результате все объекты защиты окажутся покрыты вниманием команды безопасности и соответствующими процессами и в них не останется «белых пятен», занимающих 82% площади.