По исследованию Verizon, причина 82% инцидентов информационной безопасности — ошибки сотрудников.  По нашим собственным исследованиям девять из девяти техник Initial Access (стадия первичного проникновения в систему при цифровых атаках по классификации MITRE ATT&CK) реализуются с участием человека — в том числе из-за недостатка знаний или навыков сотрудников по информационной безопасности. При этом команды безопасности 99% времени и бюджетов тратят на работу с техникой, технологиями и понятными цифровыми и физическими активами. А как работать с основной причиной инцидентов — человеческим фактором —  непонятно. Меня зовут Сергей Волдохин, я CEO в команде Start X, ранее руководил безопасностью в международной компании со штатом более 9000 человек.  В этой статье я расскажу о нашей разработке — концепции People as Code и структуре People CMDB. Благодаря этому подходу люди смогут из главной угрозы безопасности стать сильным и надежным цифровым активом.  В науке существует гипотеза лингвистической относительности. Идея очень простая: мы не можем понять и осмыслить то, чего нет в нашем языке. Если мы не знаем какое-то слово — значит, мы не думаем о соответствующем понятии, не говорим и не учитываем его в нашей работе.  Как эта философская концепция относится к современной информационной безопасности? На самом деле напрямую.  Любой опытный специалист по безопасности подтвердит приведенную выше статистику о том, что люди — главная угроза и источник инцидентов в безопасности.  Но как мы говорим об угрозах и инцидентах на практике? Насколько четко мы определяем, какие действия человека приводят к угрозам или инцидентам?  К примеру, возьмем банк данных угроз безопасности информации ФСТЭК. Посмотрим раздел «Внедрение вредоносного ПО через электронную почту» — способ взлома, который на 100% определяется опасными действиями  человека, — то увидим следующее: Кажется, будто внедрение вредоносного ПО через электронную почту происходит магическим способом, само собой: Если у вас не эксплойт в почтовом сервисе, что бывает, но редко, то внедрение в ПО через электронную почту не может произойти без участия человека.  Но за множеством аббревиатур ничего не сказано про сотрудника, который откроет вредоносное письмо, запустит вложение или скачает вредоносный файл по ссылке. Учтены и оперативная система, и браузер электронной почты, и веб-клиент, — но только не человек, чьи действия и определяет успех этого способа атаки: Вот еще несколько примеров, как обычно описывают инциденты в безопасности и что на самом деле происходило — какие действия людей стали причиной инцидента: Описываем инцидент через техническую последовательность действий  Что произошло на самом деле Вирусное заражение, которое привело к шифрованию десятка тысяч рабочих станций и остановке производственного процесса. Нам пришлось восстанавливать данные и системы из резервных копий. Бухгалтер открыл письмо и запустил файл из вложения, который ему прислали под видом срочного счета на оплату от знакомого контрагента. Компрометация учетной записи привела к возможности получения доступа к внутреннему веб-порталу организации, откуда злоумышленник сумел переместиться на внутренние сервера и повысил привилегии до администратора домена, и провел серию мероприятий по закреплению на ряде серверов в наших дата-центрах. Менеджер отдела продаж получил сообщение в мессенджер от мошенника, который представился системным администратором, перешел по ссылке и два раза ввел свой пароль, а затем ушел на встречу с клиентом и забыл про это. Рабочая станция во внутренней сети организации была скомпрометирована в результате запуска вредоносного кода, доставленного на рабочую станцию посредством вложения в сообщение электронной почты. Подрядчик, имеющий доступ к корпоративному компьютеру, получил письмо с требованием срочно проверить проектную документацию, открыл вложение и запустил офисный документ с макросами. Хост Еlasticsearch с дефолтной политикой авторизации «пускать всех» имел публичный IР, который не был ограничен сетевыми политиками, в результате неавторизованный пользователь мог получить доступ к персональным данным клиентов. Инженер инфраструктуры в первую неделю своей работы настраивал сервер по срочному запросу продуктовой команды, пришлось срочно разбираться с тем, что такое Еlasticsearch, но вроде бы все заработало. Кто-то может возразить: «Слушай, ну вообще-то есть полностью технические атаки без участия человека. Например, веб — ну что там зависит от людей?» Здесь возникает еще один интересный факт:  Дело в том, что большинство атак на веб-приложения — это не атаки на приложения, это снова атаки на людей. В отчете DBIR (Data Breach Investigations Report) указано, что 80% успешных атак на веб-приложения происходит через использование украденных паролей и только 15% — через эксплуатацию уязвимостей в этих приложениях. Вот несколько примеров, как за техническими атаками на самом деле скрывается человеческий фактор: Как описываем угрозу или инцидент Что произошло на самом деле Хакеры регулярно сканируют извне наши системы и могут найти непропатченные серверы и сервисы на внешнем периметре. Администраторы оставляют критичные сервисы доступными извне вместо того, чтобы ограничить к ним доступ через корпоративный VPN. Мы обнаружили, что наш сайт взломали и повесили на нем майнер криптовалюты, который запускается в браузерах у посетителей. Разработчики писали код без понимания контекстов и угроз безопасности, в результате простейшая XSS позволила получить доступ к сайту на уровне веб-администратора и добавить вредоносные скрипты во все страницы.  Из свежих примеров — успешная цифровая атака на Airbus, настоящей причиной которой стал сотрудник из Турции, который скачал на свой компьютер пиратское ПО и в результате заразил его вирусом.  Из-за того, что человеческий фактор не учитывается при анализе проблем в информационной безопасности, получаем следующую картину: Из  отчетов видно, затраты на IT-безопасность растут, но это не помогает  — количество инцидентов растет еще быстрее. При этом затраты на людей или что-то связанное с людьми — самая маленькая категория, она составляет меньше трех процентов.  Вывод простой: финансирование IT-безопасности распределяется некорректно и не приводит к решению проблем, потому что главный ее фактор — человек — игнорируется. Если кто-то из вас пробовал вручную администрировать инфраструктуры, вы знаете, что когда растет число серверов, сервисов или других систем, в такой недетерминированной, неопределенной среде становится сложно чем-то управлять.  Эту проблему научились решать с помощью подхода Everything as Code — все как код. Суть подхода такая: каждый элемент процесса, в данном случае разработки софта и его эксплуатации, описывается как код.  Благодаря этому, с помощью инструментов Terraform, Kubernetes, Ansible неопределенная среда становится управляемой, даже когда система разнородная и в ней очень много элементов. Если у вас в команде есть разработчики, аналитики, технические писатели, сходите к ним и посмотрите, как они ведут документацию — вероятно, она уже выглядит как код, который пишется на естественном языке и может сразу же трансформироваться в такие схемы: А это скриншот из доклада Александра Токарева из Сбера, очень рекомендую его посмотреть. Это какой-то декларативный язык, который описывает требования для их проверки, автоматизации и соблюдения в какой-то инфраструктуре.  Можно ли применить такой же подход к людям и определить сотрудников как активы, с которыми мы сможем работать так же, как работаем с техникой и документами? Давайте попробуем провести аналогию: Если Infrastructure as Code (инфраструктура как код) — это концепт, который позволяет развертывание сервиса описать каким-то набором свойств в виде сервисов, компонентов, серверов и так далее. Тогда People as Code (люди как код) — это концепт, который позволяет «развертывание» человека в организации описать каким-то набором свойств. Например: мотивация человека, возможности человека (оборудование, ПО, доступы, знания, навыки). Почему категории именно такие? За основу мы взяли поведенческую модель социолога Брайана Джеффри Фогга, сотрудника Стэнфордского университета. По ней действия человека определяются мотивацией и возможностями: Если у человека низкая мотивация, но сделать что-то достаточно легко, то он сможет это сделать. Если у человека низкая мотивация, при этом сделать что-то сложно (как в нижнем левом углу), то вряд ли вы получите это целевое действие.  Если мы понимаем мотивацию и возможности человека и четко их описываем, то мы можем связать это с конкретными действиями, которые человек сделает и которые приведут или не приведут к инциденту. Роли людей, их доступ и возможность влиять на недопустимые события идеально описываются структурами данных.  Поэтому мы с командой разработали структуру, которую назвали People СMDB — по аналогии с СMDB (Configuration Management Database), или базой данных конфигурационных единиц в IT-активах. В нашем случае это база данных управления конфигурациями сотрудников. Это  репозиторий, который содержит следующую информацию: роль сотрудников, важные для безопасности свойства сотрудников (их знания, навыки, мотивация, убеждения), уровень защищенности сотрудников и другие параметры. People CMDB  — это опенсорс-проект, вы можете использовать его, скачав репозиторий из GitHub и наполняя его теми данными, которые актуальны для вас, а также встраивая в свои продукты и процессы безопасности.  В People СMDB описаны следующие сущности: Бизнес-цели Недопустимые события Сценарии недопустимых событий Опасные действия Безопасные действия Сотрудники и их роли Курсы Имитированные атаки Начнем с определения бизнес-целей. Сейчас модно привязывать информационную безопасность к бизнесу, но в нашем случае это не просто дань моде. Прописать бизнес-цели не просто желательно, а критически важно. Потому что разные люди в разных ролях могут заниматься разными задачами и, в зависимости от этих задач, совершать разные действия. Соответственно, нам очень важно все это связать — людей, их свойства, параметры, что мы от них ждем, —  с теми действиями, которые они могут сделать. А  действия — это следствия  бизнес-целей.  Примеры таких целей: Подрядчики получают оплату за свои услуги вовремя. Клиенты успешно работают с продуктивной системой. Что здесь может пойти не так?  Могут быть остановлены платежи. Систему могут взломать и скомпрометировать данные. Другими словами, случатся  недопустимые события: Как могут случиться эти события? Описываем сценарии недопустимых событий: Первое событие может случиться, например, потому, что сотрудник открыл вложение с фишингом, словил шифровальщика, и теперь нельзя проводить платежи. Во втором сценарии разработчик включил уязвимую библиотеку или зафиксировал не обновленную версию.  Обратите внимание, что здесь добавляются уже конкретные роли — кто мог сделать определенные опасные и безопасные действия в рамках указанного сценария.  Что конкретно сделает сотрудник, чтобы инцидент мог случиться? Какие будут опасные действия? В первом случае с бухгалтером — открытие неизвестного файла. Во втором случае с разработчиком — подключение уязвимой библиотеки из фрагмента кода со Stackoverflow или несвоевременное обновление библиотеки.  Как избежать инцидента? Сотруднику нужно действовать прямо противоположным образом — опишем такое поведение как безопасные действия.  Это самый сложный этап — команды безопасности привыкли фокусироваться на угрозах и моделях нарушителя, то есть на опасных действиях. Здесь же нужно понять, что именно должен сделать человек, чтобы все прошло хорошо и чтобы в будущем таких инцидентов не было.  В первом случае с бухгалтером — сообщить об атаке и удалить письмо. В случае с разработчиком — проверить, могут ли уже подключенные библиотеки выполнить нужную функцию и выбирать безопасные зависимости.   Но что нужно, чтобы сотрудник действовал именно так?  Ему нужна определенная мотивация (в том числе убеждения), а также знания, навыки и техническая возможность выполнить нужные действия.  Например, у разработчика может быть (или не быть) навык отличить хорошего мейнтейнера от плохого или надежную библиотеку от ненадежной. А бухгалтер может иметь техническую возможность быстро сообщить команде безопасности о возможной атаке (например, через специальный плагин).  Все условия для выполнения безопасных действий можно описать такой структурой: Обязательно нужно описать Роли.  В них, кроме названия, мы описываем целевую мотивацию и уровень защищенности сотрудника — те, которые мы считаем минимально допустимыми для безопасной работы в этой роли.  При описании Сотрудников добавляется связка с ролями, актуальный уровень защищенности, мотивации, а также приоритет — то, к каким системам человек имеет доступ, насколько ответственная у него позиция и так далее.  Такая структура, при ее использовании, позволяет в реальном времени оценивать риски и угрозы, исходящие от сотрудников: Теперь самое интересное. Как нам перевести человека из низкого уровня защищенности в высокий — дать ему нужные мотивацию, убеждения, знания и навыки?  Для этого можно использовать обучающие Курсы, но их содержимое должно быть также четко структурировано. С такой структурой мы точно будем знать, какие вещи нужно доносить до каждого из сотрудников.  Если мы говорим про кейс с разработчиком, то это может быть курс по безопасной работе с зависимостями: Аналогично — с курсом по безопасной работе с электронной почтой: Курсы — это хорошо, но, как видно из структур выше, курсы могут дать только знания.  Навыки приходят с опытом, а опыт для бухгалтера — это, например, имитированные атаки: Пример, как сотрудники могут выявлять атаки и предотвращать инциденты с помощью инструментов Start AWR. Чтобы концепция People as Code заработала, структуры People CMDB не должны быть мертвым грузом.  Даже если вы их наполните, нужно обязательно связывать их в единые процессы вместе с теми системами, которые вы уже используете. Например, с системами повышения осведомленности и управления доступом: Мы создали DSL-язык, который можно читать так, как мы читаем обычный текст.  Он помогает понять правила и алгоритмы, как именно можно связывать людей с другими процессами безопасности. Например, что нужно проверять при запросах на доступ, что надо проверять для уже выданных доступов, как связана защищенность сотрудников и другие их свойства с доступами: Также очень важна связь концепции People as Code с техподдержкой компании.  Например, команда безопасности говорит сотрудникам: не храните пароли на листочках, храните их в парольных менеджерах. Прекрасно, но если мы хотим, чтобы сотрудники хранили пароли не на листочках, приклеенных к монитору, а в менеджере паролей, то нужно его установить. То есть перейти от слов и установок к действию и рабочей практике: Второй сценарий —  для всех инцидентов проверять уровень защищенности сотрудника и, если он не соответствует требованиям его роли, отправлять сотрудника на обучение и имитировать атаку в соответствии с тем инцидентом, который случился.  Также по опыту коллег, с которыми мы готовили этот материал, очень важно работать над мотивацией. Например, проводить личные или видеовстречи с человеком, объяснять и разговаривать с ним о том, что произошло и почему это недопустимо делать, и как надо действовать правильно.  Часто в результате разбора инцидентов, выявленных DLP-системами, выясняется, что нарушители — не злостные инсайдеры, а обычные сотрудники, которые не умели работать безопасно.  В этом случае DLP-система в концепции People as Code не наказывает, а помогает выявить отклонения и повысить защищенность сотрудников: Важно интегрировать People CMDB в процессы безопасной разработки. В таком случае те же отчеты Quality Gate, которые приходят от команд безопасности, будут уже не просто мертвым грузом, их можно будет передать на триаж тем сотрудникам, чей уровень защищенности и чьи навыки, в соответствии с определенными требованиями, достаточно высоки. Этим же сотрудникам могут быть выданы права на bypass, если вы достаточно уверены в их классификации. Так получится разгрузить безопасников и улучшить процесс, ведь квалифицированные и грамотные сотрудники из команды разработки лучше сделают триаж, чем условный архитектор информационной безопасности. При всем уважении к этим специалистам, если у вас тысячи разработчиков и сотни проектов, вряд ли кто-то из команды безопасности сможет разобраться в этом так же хорошо, как команда разработки. Определитесь, кто ваши сотрудники, какие у них роли, и что вы от них хотите в плане их уровня защищенности и мотивации.  Если вдруг у вас не определены бизнес-цели — нужно это сделать. Да, вроде бы это не наша задача, но можно просто подойти к коллегам, которые этим занимаются.  Подумайте о недопустимых событиях и о сценариях их наступления. Свяжите это с теми опасными и безопасными действиями, которые могут выполнять сотрудники.  Определитесь, что у вас уже есть из имитированных атак и курсов, а чего не хватает для того, чтобы у людей были нужные знания, навыки и убеждения. Начните с убеждений — если у людей будут нужные убеждения, поверьте, они найдут возможность действовать правильно и безопасно.  Не забудьте интегрировать это с процессами и системами безопасности, которые у вас уже есть. Эти процессы обязательно должны быть связаны с людьми. Концепция People as Code  — именно про это. Людей нужно не оставлять слабым звеном, а делать из них защитников и активных участников процессов безопасности.