В последние два года мы видим много новостей про утечки данных, в том числе из популярных сервисов: СДЭК, Яндекс.Еда, Delivery Club, Литрес и других.

В результате таких утечек стали доступны более 660 миллионов записей персональных данных в России и до 15 миллиардов в мире.

Источник данных об утечках — портал TAdviser: СДЭК, Яндекс.Еда и Delivery Club, Дом.ру

Кажется, что утечки сами по себе стали синонимом инцидента безопасности. Но почти никто не задает вопрос — а почему они происходят?

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

Утечки данных и другие инциденты случаются в 74% случаев из-за действий людей: сотрудники предоставляют злоумышленникам доступ к учетной записи с данными клиентов или скачивают пиратский софт с вирусами и компрометируют аккаунты.

Давайте разберем этот тезис на конкретных примерах.

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

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

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

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

Вот пример типичного технического инцидента:

Здесь хорошо расписана вся цепочка заражения, но явно чего-то не хватает. Как эта цепочка превратилась в инцидент? Заражение произошло из-за того, что человек совершил опасное действие. Если бы он этого не сделал — не было бы и инцидента:

Почему сотрудники совершают опасные действия

В имитированных атаках через Start AWR сотрудники открывают фишинговые письма в 51% случаев. И 40% из них совершают небезопасные действия: переходят по ссылкам, скачивают вложения или вводят данные в форму — любое из этих действий в реальной атаке может означать компрометацию систем, проникновение в периметр и утечку данных, или другие недопустимые события.

Чаще всего сотрудники совершают опасные действия не потому, что хотят навредить, а по другим причинам:

Не понимают, что их действия могут привести к проблеме.
Не знают, от чего нужно защищаться. Например, могут открыть договор с расширением.msi, потому что его прислали якобы представители компании MSI.
Действуют под влиянием эмоций, нерационально. Некоторые сотрудники объясняют, почему ввели пароль на фишинговых сайтах, примерно так: «Я взрослый, уверенный в себе мужчина, раз уж открыл этот сайт, то должен дойти до конца!».

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

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

Как снизить количество опасных действий сотрудников

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

Как именно это можно делать?

Мы разработали концепцию, которую назвали People as Code — по аналогии с Infrastructure as Code или Documents as Code. Она объясняет, как можно встроить человека в современные цифровые системы и в те продукты и процессы, которые у вас уже есть. Я подробно рассказывал про эту концепцию в другом посте «People as Code: как мы применили подход Everything as Code к людям, чтобы устранить причину 82% инцидентов безопасности».

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

Как построить информационную безопасность в компании вокруг человека

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

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

Пример имитированной атаки через веб-камеру

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

Пример имитированной атаки через документ в формате .docx

2. Измеряем защищенность и уровень риска каждого сотрудника

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

Актуальные измерения помогают следить за уровнем риска сотрудника и принимать нужные решения: ограничивать доступ к данным или увольнять при важных нарушениях.

В Start AWR вероятность инцидента в результате небезопасных действий сотрудников рассчитывается на основе показателя защищенности каждого сотрудника

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

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

3. Интегрируемся с процессами управления доступами

Итак, мы начали отслеживать актуальное состояние уровня защищенности сотрудников и компании. Что дальше? Встраивайте сотрудников в процессы на базе систем IDM/AIM.

Допустим, сотрудник компании запросил доступ к CRM. Может ли ваша система автоматизировано оценить уровень защищенности у человека, который просит доступ? Если уровень достаточный — доступ можно дать:

Если вы не знаете уровень защищенности сотрудника, подумайте, стоит ли давать ему доступы?

Если у сотрудника недостаточный уровень защищенности — он чего-то не знает, или у вас нет информации о том, что он проходил какое-то обучение, или он неадекватно реагировал в результате имитированных атак — как этот человек будет действовать, если получит реальные доступы?

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

4. Интегрируемся с процессами DLP

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

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

DLP-система может быть важным инициатором этого процесса:

5. Интегрируемся с процессами SOC

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

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

Чек-лист, как построить систему информационной безопасности в компании вокруг человека

Посмотрите на реальные угрозы, чтобы оценить, какие знания, умения, навыки и мотивация нужны людям, чтобы вести себя безопасно.
Настройте процесс обучения и тренировки навыков в реалистичных условиях.
Измеряйте уровень защищенности сотрудников точно так же, как вы измеряете процент покрытия антивирусами.
Интегрируйте процесс обучения и мотивации с другими решениями: DLP, IDM, SOC.
Если DLP- и awareness-системы, которые вы используете, нельзя интегрировать, задайте вендору вопросы или поменяйте решение. То же самое относится к любым другим средствам защиты, которые вы уже внедрили.
Пользуйтесь всеми доступными средствами защиты, но не выбрасывайте людей из уравнения.

People-Centric Security, или Человекоцентричная безопасность — забытая концепция или ключ к защите современных компаний?