По исследованию Verizon, причина 82% инцидентов информационной безопасности — ошибки сотрудников. 

По нашим собственным исследованиям девять из девяти техник Initial Access (стадия первичного проникновения в систему при цифровых атаках по классификации MITRE ATT&CK) реализуются с участием человека — в том числе из-за недостатка знаний или навыков сотрудников по информационной безопасности.

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

Меня зовут Сергей Волдохин, я CEO в команде Start X, ранее руководил безопасностью в международной компании со штатом более 9000 человек. 

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

Как язык ограничивает традиционную безопасность

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

Как эта философская концепция относится к современной информационной безопасности? На самом деле напрямую. 

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

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

К примеру, возьмем банк данных угроз безопасности информации ФСТЭК. Посмотрим раздел «Внедрение вредоносного ПО через электронную почту» — способ взлома, который на 100% определяется опасными действиями  человека, — то увидим следующее:

Кажется, будто внедрение вредоносного ПО через электронную почту происходит магическим способом, само собой:

Если у вас не эксплойт в почтовом сервисе, что бывает, но редко, то внедрение в ПО через электронную почту не может произойти без участия человека. 

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

Вот еще несколько примеров, как обычно описывают инциденты в безопасности и что на самом деле происходило — какие действия людей стали причиной инцидента:

Кто-то может возразить: «Слушай, ну вообще-то есть полностью технические атаки без участия человека. Например, веб — ну что там зависит от людей?»

Здесь возникает еще один интересный факт:

Дело в том, что большинство атак на веб-приложения — это не атаки на приложения, это снова атаки на людей.

В отчете DBIR (Data Breach Investigations Report) указано, что 80% успешных атак на веб-приложения происходит через использование украденных паролей и только 15% — через эксплуатацию уязвимостей в этих приложениях.

Вот несколько примеров, как за техническими атаками на самом деле скрывается человеческий фактор:

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

К чему приводит невнимательное отношение к причинам инцидентов

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

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

Вывод простой: финансирование IT-безопасности распределяется некорректно и не приводит к решению проблем, потому что главный ее фактор — человек — игнорируется.

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

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

Эту проблему научились решать с помощью подхода Everything as Code — все как код.

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

Infrastructure as Code

Благодаря этому, с помощью инструментов Terraform, Kubernetes, Ansible неопределенная среда становится управляемой, даже когда система разнородная и в ней очень много элементов.

Documents as Code

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

Governance as code

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

People as Code

Можно ли применить такой же подход к людям и определить сотрудников как активы, с которыми мы сможем работать так же, как работаем с техникой и документами?

Давайте попробуем провести аналогию:

Если Infrastructure as Code (инфраструктура как код) — это концепт, который позволяет развертывание сервиса описать каким-то набором свойств в виде сервисов, компонентов, серверов и так далее.

Тогда People as Code (люди как код) — это концепт, который позволяет «развертывание» человека в организации описать каким-то набором свойств. Например:

• мотивация человека,

• возможности человека (оборудование, ПО, доступы, знания, навыки).

Почему категории именно такие?

За основу мы взяли поведенческую модель социолога Брайана Джеффри Фогга, сотрудника Стэнфордского университета. По ней действия человека определяются мотивацией и возможностями:

Если у человека низкая мотивация, но сделать что-то достаточно легко, то он сможет это сделать. Если у человека низкая мотивация, при этом сделать что-то сложно (как в нижнем левом углу), то вряд ли вы получите это целевое действие. 

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

People CMDB — структура и DSL-язык для реализации концепции People as Code

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

Поэтому мы с командой разработали структуру, которую назвали People СMDB — по аналогии с СMDB (Configuration Management Database), или базой данных конфигурационных единиц в IT-активах.

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

• роль сотрудников,

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

• уровень защищенности сотрудников и другие параметры.

People CMDB  — это опенсорс-проект, вы можете использовать его, скачав репозиторий из GitHub и наполняя его теми данными, которые актуальны для вас, а также встраивая в свои продукты и процессы безопасности. 

Структуры People CMDB

В People СMDB описаны следующие сущности:

• Бизнес-цели

• Недопустимые события

• Сценарии недопустимых событий

• Опасные действия

• Безопасные действия

• Сотрудники и их роли

• Курсы

• Имитированные атаки

Начнем с определения бизнес-целей.

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

Примеры таких целей:

1. Подрядчики получают оплату за свои услуги вовремя.

2. Клиенты успешно работают с продуктивной системой.

[
    {
        "business goal": "Подрядчики получают оплату за свои услуги вовремя",
        "critical events": [
            1
        ]
    },    
    {
        "business goal": "Клиенты успешно работают с продуктивной системой",
        "critical events": [
            2
        ]
    }
]

Что здесь может пойти не так? 

1. Могут быть остановлены платежи.

2. Систему могут взломать и скомпрометировать данные.

Другими словами, случатся  недопустимые события:

[
    {
        "critical event": "Платежи остановлены, нарушены обязательства",
        "id": 1,
        "scenarios": [
            1
        ]
    },
    {
        "critical event": "Продуктивная система взломана, и клиентские данные скомпрометированы",
        "id": 2,
        "scenarios": [
            2
        ]
    }
]

Как могут случиться эти события? Описываем сценарии недопустимых событий:

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

2. Во втором сценарии разработчик включил уязвимую библиотеку или зафиксировал не обновленную версию. 

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

[
    {
        "scenario": "Сотрудник нажал на вложение с фишингом и словил шифровальщика - платежи нельзя отправлять",
        "scenario_id": 1,
        "roles": [
            "accountant",
            "senior accountant"
        ],
        "unsafe_actions": [
            3
        ],
        "safe_actions": [
            2,
            3
        ]
    },
    {
        "scenario": "В приложении на продуктивном кластере обнаружена публично известная уязвимость во внешней библиотеке",
        "scenario_id": 2,
        "roles": [
            "frontend developer",
            "lead frontend developer",
            "backend developer",
            "ios developer"
        ],
        "unsafe_actions": [
            1,
            2
        ],
        "safe_actions": [
            1,
            2
        ]
    }   
]

Что конкретно сделает сотрудник, чтобы инцидент мог случиться? Какие будут опасные действия?

1. В первом случае с бухгалтером — открытие неизвестного файла.

2. Во втором случае с разработчиком — подключение уязвимой библиотеки из фрагмента кода со Stackoverflow или несвоевременное обновление библиотеки.

[
    {
        "unsafe_action": "подключить уязвимую библиотеку из фрагмента кода
      со Stackoverflow",
        "action_id": 1
    },


    {
        "unsafe_action": "зафиксировать версию библиотеки два года назад и не обновлять ее",
        "action_id": 2
    },    


    {
        "unsafe_action": "открыть неизвестный файл из эл. почты",
        "action_id": 3
    }
 
]

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

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

1. В первом случае с бухгалтером — сообщить об атаке и удалить письмо.

2. В случае с разработчиком — проверить, могут ли уже подключенные библиотеки выполнить нужную функцию и выбирать безопасные зависимости.  

Но что нужно, чтобы сотрудник действовал именно так? 

Ему нужна определенная мотивация (в том числе убеждения), а также знания, навыки и техническая возможность выполнить нужные действия. 

Например, у разработчика может быть (или не быть) навык отличить хорошего мейнтейнера от плохого или надежную библиотеку от ненадежной. А бухгалтер может иметь техническую возможность быстро сообщить команде безопасности о возможной атаке (например, через специальный плагин). 

Все условия для выполнения безопасных действий можно описать такой структурой:

[
    {
        "safe_action": "проверить, могут ли уже подключенные библиотеки выполнить нужную функцию",
        "action_id": 1,
        "motivation": {
            "believes": [
                "внешние зависимости могут иметь уязвимости",
                "злоумышленники могут эксплуатировать уязвимости через зависимости",
                "не стоит подключать новые библиотеки, если уже подключенные могут решить задачу",
                "больше зависимостей дает больше проблем с поддержкой приложения"
            ]
        },
        "ability": {
            "knowledge": [
                "какие возможности дают уже подключенные библиотеки",
                "алгоритм принятия решения о подключении новой библиотеки",
                "как новые зависимости влияют на время сборки и размер бандла"
            ],
            "skills": [
                "поиск нужной функциональности в существующей кодовой базе"
            ],
            "means": [
                
            ]
        }
    },
        {
        "safe_action": "выбирать безопасные зависимости",
        "action_id": 2,
        "motivation": {
            "believes": [
                "известные мейнтейнеры делают более качественное ПО",
                "если библиотека активно развивается, то и проблемы, и уязвимости устранятся быстрее",
                "судить о качестве кода по количеству звезд на GitHub некорректно",
                "хорошая и подробная документация может говорить о высоком качестве библиотеки"
            ]
        },
        "ability": {
            "knowledge": [
                "алгоритм выбора качественной библиотеки",
                "обратная связь сообщества",
                "публично известные проблемы с качеством"
            ],
            "skills": [
                "отличить хорошего мейнтейнера от плохого",
                "применить алгоритм и выбрать качественную библиотеку",
                "проверять, есть ли в выбранной версии библиотеки известные уязвимости"
            ],
            "means": [
                "GitHub",
                "Stackoverflow"
            ]
        }
    },
    {
        "safe_action": "сообщить от атаке",
        "action_id": 3,
        "motivation": {
            "believes": [
                "информационные активы компании важны",
                "мошенники могут отправить мне вредоносный файл",
                "мошенники могут отправлять письма и сообщения от имени коллег"
            ]
        },
        "ability": {
            "knowledge": [
                "как проверить письма отправителя",
                "как устроена атака с фишинговым письмом",
                "какие бывают опасные файлы",
                "какие эмоции могут использовать мошенники",
                "признаки фишинга",
                "способы проверки файла на вирусы"
            ],
            "skills": [
                "проверять вложения на ПК",
                "проверять отправителя письма",
                "проверять письмо на признаки фишинга",
                "проверить легитимность запроса из письма"
            ],
            "means": [
                "Repoter plugin"
            ]
        }
    },
    {
        "safe_action": "удалить письмо",
        "action_id": 4
    } 
]

Обязательно нужно описать Роли. 

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

[
    {
        "role": "accountant",
        "safety level": 2,
        "motivation": "high"
    },
    {
        "role": "senior accountant",
        "safety level": 3,
        "motivation": "high"
    },
    {
        "role": "frontend developer",
        "safety level": 3,
        "motivation": "high"
    },
    {
        "role": "lead frontend developer",
        "safety level": 3,
        "motivation": "high"
    },
    {
        "role": "backend developer",
        "safety level": 3,
        "motivation": "high"
    },
    {
        "role": "ios developer",
        "safety level": 3,
        "motivation": "high"
    }
       
]

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

Такая структура, при ее использовании, позволяет в реальном времени оценивать риски и угрозы, исходящие от сотрудников:

 [
    {
        "employee_id": 40201,
        "fullName": "Нина Ивановна Петрова",
        "email": "accountant@company.domain",
        "department": "Бухгалтерия",
        "roles": [
            "accountant"
        ],
        "safety level": 1,
        "priority": 1,
        "motivation": "medium"
    },
    {
        "employee_id": 9245,
        "fullName": "Алексей Алексеев",
        "email": "frontend@software.dev",
        "department": "Разработка ПО",
        "roles": [
            "frontend developer"
        ],
        "safety level": 1,
        "priority": 1,
        "motivation": "medium"
    }
]

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

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

Если мы говорим про кейс с разработчиком, то это может быть курс по безопасной работе с зависимостями:

Аналогично — с курсом по безопасной работе с электронной почтой:

[
    {
         "course": "Безопасная работа с электронной почтой",
        "course_id": 2,
        "knowledge": [
            "как проверить письма отправителя",
            "как устроена атака с фишинговым письмом",
            "какие бывают опасные файлы",
            "какие эмоции могут использовать мошенники",
            "признаки фишинга",
            "способы проверки файла на вирусы"
        ],
        "believes": [
            "информационные активы компании важны"
   ]
    }
]

Курсы — это хорошо, но, как видно из структур выше, курсы могут дать только знания. 

Навыки приходят с опытом, а опыт для бухгалтера — это, например, имитированные атаки:

[
    {
        "attack": "Имитированная атака от контрагента с вложением",
        "skills": [
            "проверять вложения на ПК",
            "проверять отправителя письма",
            "проверять письмо на признаки фишинга",
            "проверить легитимность запроса из письма"
        ],
        "believes": [
            "мошенники могут отправить мне вредоносный файл",
            "мошенники могут отправлять письма и сообщения от имени коллег"
        ]
    }
]

Пример, как сотрудники могут выявлять атаки и предотвращать инциденты с помощью инструментов Start AWR.

Интеграция People as Code с IDM/AIM

Чтобы концепция People as Code заработала, структуры People CMDB не должны быть мертвым грузом. 

Даже если вы их наполните, нужно обязательно связывать их в единые процессы вместе с теми системами, которые вы уже используете. Например, с системами повышения осведомленности и управления доступом:

Мы создали DSL-язык, который можно читать так, как мы читаем обычный текст. 

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

IDM:
    для всех запросов на доступ
        проверять уровень защищенности сотрудника на соответствие требованиям роли
            если уровень защищенности соответствует выдавать доступ
        иначе 
            повысить защищенность
                отправить на обучение
                    со сроком прохождения 5 дней
                отправить имитированную атаку
                    по сценарию в соответствии с требованиями роли
            каждый 1 час
                проверять уровень защищенности 
                если уровень защищенности соответствует выдать доступ
    для всех выданных доступов
        проверять уровень защищенности 
            каждый 1 час
        если уровень защищенности не соответствует требованиям роли
            закрыть доступ
            отправить уведомление
            повысить защищенность
        каждый 1 час
            проверять уровень защищенности 
            если уровень защищенности соответствует выдать доступ

Также очень важна связь концепции People as Code с техподдержкой компании. 

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

SD:
    для всех бизнес-целей
        проверить means в соответствии с безопасными действиями
        отправить запросы на means в IDM

Интеграция с IRP/SOC

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

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

IRP:
    для всех инцидентов
        проверять уровень защищенности сотрудника на соответствие требованиям роли
            если не соответствует 
                повысить защищенность
                    отправить на обучение
                        по темам в соответствии с инцидентом
                        со сроком прохождения 5 дней
                    отправить имитированную атаку
                        по сценарию в соответствии с инцидентом
        проверять мотивацию на соответствие требованиям роли
            если не соответствует
                повысить мотивацию
                    провести видеовстречу с конструктивным разбором инцидента 
                    объяснить правильный, безопасный подход к работе
    для всех подозрений на инцидент
        проверять уровень защищенности сотрудника 
        определить приоритет реагирования по уровню защищенности сотрудника

Интеграция с DLP

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

В этом случае DLP-система в концепции People as Code не наказывает, а помогает выявить отклонения и повысить защищенность сотрудников:

Интеграция с DevSecOps

Важно интегрировать People CMDB в процессы безопасной разработки. В таком случае те же отчеты Quality Gate, которые приходят от команд безопасности, будут уже не просто мертвым грузом, их можно будет передать на триаж тем сотрудникам, чей уровень защищенности и чьи навыки, в соответствии с определенными требованиями, достаточно высоки. Этим же сотрудникам могут быть выданы права на bypass, если вы достаточно уверены в их классификации.

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

DevSecOps:
    для всех результатов прохождения Quality Gate
        получить отчет
        разобрать обнаружения по типам уязвимостей
        выбрать сотрудников с safety_level и motivation в соответствии с ролью
            выбрать сотрудников с ability по типам уязвимостей
        выбранным сотрудникам
            поручить триаж 
            выдать права на bypass   
    для всех pull request
        проверить safety_level и motivation сотрудника на соответствие роли
            если не соответствуют
                добавить особый комментарий в pull request                
                не одобрять pull request
                не выполнять merge
                повысить защищенность
                повысить мотивацию
        проверить ability сотрудника по требованиям проекта
            если не соответствуют
                добавить особый комментарий в pull request
                повысить ability по конкретным требованиям для выполнения безопасных действий

Чек-лист по внедрению подхода People as Code

1. Определитесь, кто ваши сотрудники, какие у них роли, и что вы от них хотите в плане их уровня защищенности и мотивации. 

2. Если вдруг у вас не определены бизнес-цели — нужно это сделать. Да, вроде бы это не наша задача, но можно просто подойти к коллегам, которые этим занимаются. 

3. Подумайте о недопустимых событиях и о сценариях их наступления.

4. Свяжите это с теми опасными и безопасными действиями, которые могут выполнять сотрудники. 

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

6. Не забудьте интегрировать это с процессами и системами безопасности, которые у вас уже есть. Эти процессы обязательно должны быть связаны с людьми. Концепция People as Code  — именно про это. Людей нужно не оставлять слабым звеном, а делать из них защитников и активных участников процессов безопасности. 

Define:
    Сотрудники
        roles + safety_level + priority + motivation

    Роли
        safety_level + motivation
    
    Бизнес-цели
        Недопустимые события
            Сценарии НС
                Опасные действия
                Безопасные действия
                    motivation
                        believes
                    Возможности
                        (knowledge + skills) х means

    Курсы + Имитированные атаки
        believes + knowledge + skills

Integrate:
    IDM
DLP
    IRP
    DevSecOps