В последние два года мы видим много новостей про утечки данных, в том числе из популярных сервисов: СДЭК, Яндекс.Еда, Delivery Club, Литрес и других.
В результате таких утечек стали доступны более 660 миллионов записей персональных данных в России и до 15 миллиардов в мире.
![Источник данных об утечках — портал TAdviser: СДЭК, Яндекс.Еда и Delivery Club, Дом.ру Источник данных об утечках — портал TAdviser: СДЭК, Яндекс.Еда и Delivery Club, Дом.ру](https://habrastorage.org/getpro/habr/upload_files/6f8/c8a/a9a/6f8c8aa9ac7110772ba1e2c3b1fed485.png)
Кажется, что утечки сами по себе стали синонимом инцидента безопасности. Но почти никто не задает вопрос — а почему они происходят?
Меня зовут Сергей Волдохин, я CEO в команде Start X, ранее руководил безопасностью в международной компании со штатом более 9 000 человек. В этой статье я расскажу о главных причинах утечек и других инцидентов, а также о том, как организовать процессы информационной безопасности в компании, чтобы снизить их вероятность.
Утечки данных и другие инциденты случаются в 74% случаев из-за действий людей: сотрудники предоставляют злоумышленникам доступ к учетной записи с данными клиентов или скачивают пиратский софт с вирусами и компрометируют аккаунты.
Давайте разберем этот тезис на конкретных примерах.
У «Гемотеста» утекла база данных клиентов, наверняка вы слышали про этот инцидент. Через полгода после инцидента вышли статьи о том, что суд оштрафовал компанию, и заодно мы узнали причину, по которой произошла утечка: сотрудник компании предоставил доступ к учетной записи с данными клиентов.
Еще один пример — компания Airbus стала жертвой кибератак и заявила об утечке конфиденциальной информации. В новостях строили разные предположения о том, почему это могло произойти, вплоть до того, что за кибератаками мог стоять Китай. Так говорить очень удобно — это же великая держава, как ей можно противостоять?
А вот что случилось на самом деле — сотрудник компании скачал пиратский софт и заразил свою рабочую станцию, в итоге его пароль украли.
Вы можете мне возразить — Сергей, ты тут подобрал какие-то единичные примеры утечек, давай лучше разберем классический технический инцидент информационной безопасности.
Вот пример типичного технического инцидента:
![](https://habrastorage.org/getpro/habr/upload_files/734/efc/ea8/734efcea8b1a34c3eaab170ae9997fb4.png)
Здесь хорошо расписана вся цепочка заражения, но явно чего-то не хватает. Как эта цепочка превратилась в инцидент? Заражение произошло из-за того, что человек совершил опасное действие. Если бы он этого не сделал — не было бы и инцидента:
![](https://habrastorage.org/getpro/habr/upload_files/54f/7b4/0dd/54f7b40ddf959ecf1b69f1a6c07c8a2c.png)
Почему сотрудники совершают опасные действия
В имитированных атаках через Start AWR сотрудники открывают фишинговые письма в 51% случаев. И 40% из них совершают небезопасные действия: переходят по ссылкам, скачивают вложения или вводят данные в форму — любое из этих действий в реальной атаке может означать компрометацию систем, проникновение в периметр и утечку данных, или другие недопустимые события.
Чаще всего сотрудники совершают опасные действия не потому, что хотят навредить, а по другим причинам:
Не понимают, что их действия могут привести к проблеме.
Не знают, от чего нужно защищаться. Например, могут открыть договор с расширением.msi, потому что его прислали якобы представители компании MSI.
Действуют под влиянием эмоций, нерационально. Некоторые сотрудники объясняют, почему ввели пароль на фишинговых сайтах, примерно так: «Я взрослый, уверенный в себе мужчина, раз уж открыл этот сайт, то должен дойти до конца!».
К сожалению, команды информационной безопасности не всегда обращают внимание на эти причины. Давайте посмотрим на популярный фреймворк, по которому разбирают и анализируют недопустимые события:
![Источник: Positive Technologies Источник: Positive Technologies](https://habrastorage.org/getpro/habr/upload_files/c00/7ad/6a8/c007ad6a8cc2c6485399ae1cbf1035af.png)
Есть недопустимое событие, сценарии реализации, целевые системы, критерии, но нет ответа на главный вопрос — как именно злоумышленники получили несанкционированный доступ к серверу и взломали подрядчика.
Как снизить количество опасных действий сотрудников
Если принять как факт, что инциденты происходят из-за сотрудников, то станет ясно, что нужно работать с ними и встраивать их в процессы, которые помогают защитить компанию от утечек данных и других инцидентов.
Как именно это можно делать?
Мы разработали концепцию, которую назвали People as Code — по аналогии с Infrastructure as Code или Documents as Code. Она объясняет, как можно встроить человека в современные цифровые системы и в те продукты и процессы, которые у вас уже есть. Я подробно рассказывал про эту концепцию в другом посте «People as Code: как мы применили подход Everything as Code к людям, чтобы устранить причину 82% инцидентов безопасности».
А сейчас я хочу кратко рассказать, какие еще конкретные действия можно предпринять, чтобы построить информационную безопасность в вашей компании вокруг человека и снизить количество инцидентов и опасных действий.
Как построить информационную безопасность в компании вокруг человека
1. Оцениваем ключевые угрозы и тренируем навыки, которые помогут им противостоять
Нужно тренировать навыки сотрудника в условиях, максимально похожих на реальную ситуацию, в которой он может оказаться. Например, если мошенники могут попросить у сотрудника доступ к камере и микрофону, пожалуйста, поставьте его в такую ситуацию заранее и дайте сотруднику почувствовать, что произойдет, если он разрешит доступ:
![Пример имитированной атаки через веб-камеру Пример имитированной атаки через веб-камеру](https://habrastorage.org/getpro/habr/upload_files/776/d55/c45/776d55c45dbc57466661f1938776b5b7.gif)
Если мошенники могут прислать сотруднику вложение в формате .docx, и в этом файле можно разрешить редактирование, которое приведет к исполнению вредоносного кода, подготовьте имитированную атаку с таким же сценарием. Чтобы человек прошел через это и на своем опыте почувствовал ситуацию до того, как столкнется с ней с помощью мошенников.
![Пример имитированной атаки через документ в формате .docx Пример имитированной атаки через документ в формате .docx](https://habrastorage.org/getpro/habr/upload_files/af7/956/6cf/af79566cfbbbd02c1e8671b3629bd217.gif)
2. Измеряем защищенность и уровень риска каждого сотрудника
Важно не только обучать и тренировать сотрудников, но измерять защищенность и уровни риска. При этом нужно следить, чтобы данные измерений были актуальными — нельзя проводить имитированные атаки раз в год и быть спокойными, лучше повторять замеры как минимум раз в квартал.
Актуальные измерения помогают следить за уровнем риска сотрудника и принимать нужные решения: ограничивать доступ к данным или увольнять при важных нарушениях.
![В Start AWR вероятность инцидента в результате небезопасных действий сотрудников рассчитывается на основе показателя защищенности каждого сотрудника В Start AWR вероятность инцидента в результате небезопасных действий сотрудников рассчитывается на основе показателя защищенности каждого сотрудника](https://habrastorage.org/getpro/habr/upload_files/90d/19e/36d/90d19e36dae7e2c54fdf8f561572fca0.png)
При этом не нужно наказывать человека, если он провалил первую в своей жизни имитированную атаку. Важно настроить правильный процесс тренировки навыков: проводить различные по сложности и актуальные по атрибуции атаки, чтобы в процессе накапливался опыт. Если сотрудник после нескольких атак продолжает совершать опасные действия, то ему стоит ограничить доступ к данным или объявить взыскание.
В нашей практике были случаи, когда топ-менеджеры меняли свое отношение к безопасности после того, как вводили свои пароли на фишинговых страницах и видели, к чему приводят их действия. К счастью, это были имитированные атаки, но даже с их помощью отношение менялось.
3. Интегрируемся с процессами управления доступами
Итак, мы начали отслеживать актуальное состояние уровня защищенности сотрудников и компании. Что дальше? Встраивайте сотрудников в процессы на базе систем IDM/AIM.
Допустим, сотрудник компании запросил доступ к CRM. Может ли ваша система автоматизировано оценить уровень защищенности у человека, который просит доступ? Если уровень достаточный — доступ можно дать:
![](https://habrastorage.org/getpro/habr/upload_files/47a/47d/812/47a47d8125f629efde477ef378ee1bc4.png)
Если вы не знаете уровень защищенности сотрудника, подумайте, стоит ли давать ему доступы?
Если у сотрудника недостаточный уровень защищенности — он чего-то не знает, или у вас нет информации о том, что он проходил какое-то обучение, или он неадекватно реагировал в результате имитированных атак — как этот человек будет действовать, если получит реальные доступы?
![](https://habrastorage.org/getpro/habr/upload_files/ea9/335/b15/ea9335b1532aa4242b29662aea1bdebd.png)
Разумеется, для ответа на такие вопросы должны быть настроены программные интеграции. Если ваши awareness-системы или IDM-системы не умеют интегрироваться и у них нет API — поменяйте эти системы и сделайте так, чтобы они были связаны.
4. Интегрируемся с процессами DLP
С помощью DLP-систем можно выявить важные нарушения, но вопрос — что с этим делать? Часто команда безопасности в результате расследования видит, что нарушение не было злонамеренной утечкой, и руководство не готово увольнять человека. В этом случае проверьте, что сотрудник получит необходимые знания, и автоматически скорректируйте его уровень защищенности.
Эффективнее всего делать непрерывную профилактику через простые имитированные атаки и таким образом тренировать человека. У вас должны быть системы, в которых люди могут узнавать что-то, что им важно знать и тренировать те навыки, которые им действительно нужны.
DLP-система может быть важным инициатором этого процесса:
![](https://habrastorage.org/getpro/habr/upload_files/80f/9e2/739/80f9e27396f2828e94f8d143b1cef7eb.png)
5. Интегрируемся с процессами SOC
Люди могут стать лучшим источником данных о реальных атаках. И тот факт, сообщают ли сотрудники об атаках и любых подозрительных ситуациях, может быть самой важной метрикой. Этот параметр показывает реальную динамику вовлеченности сотрудников:
![](https://habrastorage.org/getpro/habr/upload_files/cf6/700/bc6/cf6700bc64ba5815a1147b21468904ed.png)
Важно помогать сотрудникам в защите компании — рассказывайте им, куда сообщать об атаках, используйте автоматизацию, например, плагины Outlook, чтобы информация дошла до тех систем защиты, которые внедрены в вашей компании:
![](https://habrastorage.org/getpro/habr/upload_files/836/282/a42/836282a42cfdef89ab30dae6d58a7a6a.png)
Чек-лист, как построить систему информационной безопасности в компании вокруг человека
Посмотрите на реальные угрозы, чтобы оценить, какие знания, умения, навыки и мотивация нужны людям, чтобы вести себя безопасно.
Настройте процесс обучения и тренировки навыков в реалистичных условиях.
Измеряйте уровень защищенности сотрудников точно так же, как вы измеряете процент покрытия антивирусами.
Интегрируйте процесс обучения и мотивации с другими решениями: DLP, IDM, SOC.
Если DLP- и awareness-системы, которые вы используете, нельзя интегрировать, задайте вендору вопросы или поменяйте решение. То же самое относится к любым другим средствам защиты, которые вы уже внедрили.
Пользуйтесь всеми доступными средствами защиты, но не выбрасывайте людей из уравнения.