Социнжиниринг выглядит вот так
Мы решили проверить, как поведут себя наши сотрудники в условиях реальной фишинговой атаки. Целью было понять, кому нужно дообучение и сколько денег компания может потерять от, в общем-то, примитивной атаки.
Фишинговый тест — это методика, при которой компания рассылает своим сотрудникам похожие на вредоносные электронные письма с целью проверки их реакции на кибератаки.
Идеальный результат такого теста — когда все получатели либо сообщают о подозрительных письмах в свои ИТ-отделы или службы безопасности, либо удаляют или не реагируют на них.
Наш случай сразу пошёл далеко от идеального. Рассказываю.
Меня зовут Ира Кекелева, я работаю менеджером по информационной безопасности в компании Skyeng. Именно мне было поручено организовать эту «провокацию».
Типы учений
В принципе учения по информационной безопасности могут быть разного типа: фишинг, социальная инженерия, эксплуатация уязвимости, примитивное подкидывание флешек или другие механики.
Главное — идти от проблем.
- Если у нас, скажем, на бухгалтерию постоянно идут фишинговые атаки и они постоянно всё пропускают, то мы тренируем бухгалтерию противостоять фишингу.
- Если мы боимся, что у нас в случае эксплуатации уязвимости не сработает защита, то начинаем исследовать эту уязвимость.
- Бывают учения по бизнес-процессам, когда мы выявляем какую-либо уязвимость и наблюдаем, через какое время её эксплуатацию заметят люди из бизнеса.
Это ситуация из нашего опыта. Был разработан сценарий, когда мы, приняв роль мошенников, попробовали «выкачать» деньги из компании через выявленную уязвимость. Мы проанализировали, пользовался ли кто-либо этой «пробоиной» в трюме нашего корабля, и, если да, к чему это привело. В итоге стало очевидно, что в роли мошенников мы могли «увести» у компании порядка 30 млн рублей, прежде чем кто-то заметит потерю. Так мы увидели, что вполне реальна ситуация, когда мы можем нести убытки и не замечать этого.
Любое учение позволяет понять, где мы недоработали, где у нас «косяки» в плане реагирования, где неправильно прописан регламент и кто конкретно неверно понимает свою роль в системе безопасности.
Учения с помощью фиктивной фишинговой атаки относятся к наиболее популярным у служб безопасности. Настолько популярным, что иногда они так «задалбливают» сотрудников, что те даже почту не читают. Тем не менее это вполне эффективное средство контроля.
При этом, несмотря на кажущуюся простоту задачи, реализация такого учения в крупной компании требует учёта множества факторов. Основные вопросы, которые нужно решить заранее:
- С кем нужно согласовать проведение подобного теста, чтобы потом не было лишнего возмущения и при этом информация о тайной акции не расползлась по организации.
- Какую форму учений и протокол контроля выбрать.
- Какие действия предпринять и к чему в итоге надо быть готовыми.
- Что необходимо делать после учений.
- И, главное, что мы хотим получить в результате.
Мы решили провести «социальный эксперимент» по безопасности, чтобы посмотреть, работают ли в реальности курсы, которые проходили сотрудники, узнать, как среагируют люди и как среагируем мы, то есть команда информационной безопасности.
Основные моменты, которые необходимо учесть при организации учения
1. Согласуйте свои действия с коллегами
Это необходимо сделать, получив «добро» от руководителя подразделения HR, особенно если вы проводите учения впервые. Согласование с юристами или инфраструктурой тоже может пригодиться, иначе потом они могут поднять волну, утверждая, что вы проникли в их зону ответственности и распугали персонал, нарушив их планы. Вот мы как раз этого не сделали и немного поплатились.
2. Учения надо проводить скрытно
Здесь важен эффект неожиданности. Люди должны ощущать реальность ситуации и вести себя соответственно. При этом все коллеги, которые участвуют в реагировании на инцидент, тоже должны думать, что это происходит взаправду. Если они знают, что это учения, то могут подготовиться и мониторить 24/7 либо «забить», ведь атака фейковая. А одна из наших целей — это проверить, насколько хорошо функционируют наши регламенты и реагирование.
У нас был опыт, когда вся команда безопасности знала, что в определённое время будут учения, и никто особо не реагировал на те репорты, которые к ним попадали. В итоге мне самой пришлось и тест организовывать, и отвечать на запросы пользователей. При этом параллельно я согласовывала с командой внутренних коммуникаций текст поста в наш общий канал и боролась с коллегами из инфраструктуры, которые уронили нам сервер, с которого шла рассылка «фишинга».
3. При проведении учения думайте, как злоумышленник
Надо поставить себя на место мошенника, чтобы понять, как бы он действовал, какую информацию он мог найти, чтобы использовать её во вред компании. Мы не достигнем нашей цели, если просто проверим, как люди поняли наши правила безопасности: необходимы именно действия «нарушителя». Нужно понять, как мошенник может использовать информацию из открытых источников. Возможно, это какие-то новые статьи, новые вакансии, то есть что-то, что можно вставить в текст письма, чтобы оно выглядело правдоподобно.
Допустим, у нас ищут нового СТО, и злоумышленник делает рассылку от его имени, что-то вроде: «Я новый СТО, пишу с новой почты, пока мне не дали корпоративную. Хочу того-то». То есть необходимо моделировать именно реальную ситуацию и действовать так, как действовал бы настоящий преступник.
4. Выберите оптимальное время учений и их продолжительность
Лучше всего это делать, когда все люди находятся на рабочих местах, но при этом чем-то отвлечены либо просто не сфокусированы. Условно — утро понедельника, время после обеда, время созвона. Когда мы отвлекаем человека, то надеемся, что он сейчас не в ресурсе, в потоке, в другой задаче и просто сделает то, что тебе нужно. Если сотрудники работают удалённо из разных часовых поясов, то это также нужно учитывать.
5. Убедитесь, что учения не нанесут реального ущерба
Имитация атаки не должна повредить компании (если мы положим production-сервер, то будет очень плохо). И желательно, чтобы это было что-то такое откатываемое. Поэтому необходимо продумать заранее, какие могут быть потенциальные проблемы, например, запускать фишинговые письма партиями, если мы не уверены в том, что наш почтовый сервис будет корректно отрабатывать задачу.
6. Продумайте метрики оценки эффективности учений
В случае с фишинговыми учениями это всё относительно просто. Надо подсчитать:
- Сколько человек открыли письмо.
- Сколько перешли по ссылке.
- Сколько сотрудников ввели пароль.
- Сколько людей сообщили об атаке.
Важно также понять, насколько давно шла атака до того момента, пока служба безопасности не узнала о том, что у них что-то происходит. Это время зависит от сложности системы, уровня защиты и целей атаки.
Продумайте, как вы будете собирать значения метрик в процессе: самые интересные значения — именно в процессе. Я снимала показатели как можно чаще, и они меня удивили.
7. Отдохните перед учениями
Если вы знаете точную дату учений, то, пожалуйста, отдохните и будьте готовы к тому, что это будет достаточно сложно и может затянуться по времени, особенно если в тесте принимает участие минимум людей, а в компании — сырой необкатанный регламент.
8. Возьмите второго пилота
В проведении учения должен участвовать как минимум ещё один человек, который может вас подменить и помочь, когда возникнет какая-либо нештатная ситуация. Иначе можно столкнуться со сложностями, когда у вас просто не хватит рук, чтобы со всем этим справиться.
Поскольку у нас распределённая компания, а я нахожусь в Красноярске, то для проведения «операции» был выбран вечер, чтобы письма основному персоналу, находящемуся в другом часовом поясе, попали днём. Всё закончилось уже за полночь. Вся наша команда отдыхала, положившись на меня, и это было очень сложно.
Лучше всего, если будет по два человека от Red Team и Blue Team. То есть должны быть не только специалисты команды, занимающиеся тестированием безопасности, но и команда, которая относится к внутренней защите компании и ограждает как от реальных хакеров, так и от Red Team.
9. Дублируйте оповещение об атаке
Меня очень удивил тот факт, что люди уже после того, как мы сделали общее оповещение об атаке, продолжали вводить пароли в фишинговую форму. При этом оповещение пошло даже не на почту — это была рассылка в общем канале в корпоративном мессенджере, который, как нам казалось, читали все. Так мы поняли, что нам нужно обязательно делать ещё какое-то оповещение помимо этого.
10. Уберите за собой
После проведения теста и подведения итогов важно устранить последствия проведённого учения. Если оставить где-то какие-то лишние данные, то это может стать ещё одной точкой для утечки или атаки.
Ошибки и проколы
При проведении учений не обошлись и без «косяков». Мы не учли по неопытности, что наши айтишники, заметив атаку, начнут развлекаться за счёт «мошенников». Они могут положить сервер, отреверсить код, проанализировать письма, вводить какие-нибудь символы. ИТ-специалисты способны быстро почуять нереальность происходящего, им весело, и они стараются показать сотрудникам подразделения безопасности, что они «крутые» и на хромой козе их не объедешь. В итоге страдает чистота эксперимента.
В самом начале во время учений фишинговое письмо было настроено так, чтобы пользователи вводили в форму свои данные, в частности, логин и пароль. Но в целях безопасности я решила собирать не пароли, а только логины. Айтишники сначала даже хотели пожаловаться регистратору доменов на атаку (то есть Skyeng пожаловался бы сам на себя), но очень быстро это поняли: конечно, это наверняка служба безопасности их проверяет!
Соответственно они и отреагировали: положили наш сервер — просто так, для развлечения.
Интересно, что когда мы собрали информацию о людях, которые попались на фишинговые письма, то там были не только так называемые «гуманитарии», но и определённое количество этих же самых айтишников.
Во время учений для своего удобства я выгрузила базу всех сотрудников из системы управления персоналом — с именами, должностями, почтовыми адресами. Затем по невнимательности вся эта информация попала в рассылку в заголовках письма каждому с его ФИО и должностью. Сначала айтишники запаниковали, что базу «унесли», но быстро сообразили и начали дёргать службу безопасности: мол, «попугали и хватит». Через пару часов все уже знали, что идёт проверка. Пришлось признаваться быстрее, чем мы планировали: интригу удалось сохранить только до утра, что сказалось на моём сне. Ведь к этому моменту нужно было подбить метрики (см. пункт про простое снятие метрик) и согласовать текст (см. пункт про второго пилота).
Кстати, здесь случился ещё один прокол. Письма сначала отправлялись сотрудникам из линейных подразделений, где много людей и у которых большая ротация. И, скорее всего, из-за этого нам так поздно начали приходить репорты. Потому что на таких позициях люди очень часто меняются: они просто либо ещё не знали, куда отсылать репорт, либо уже забыли, либо вообще не прошли курс обучения, где об этом говорится. Из-за этого мы получили не совсем адекватную результирующую картину. Лучше было вообще делать рассылку просто по алфавиту. Это как раз пример, где я думала не как злоумышленник, а как защитник.
Сколько может стоить компании реальная фишинговая атака и как считать потери
Зачем так заморачиваться и проводить учения, которые занимают столько времени у кучи людей в компании? Потому что атаки — это дорого. Вот расчёты:
Мы боимся не самих фишинговых атак, а того, что на них попадутся, слив злоумышленнику креды и информацию, которую могут использовать против нас.
По статистике фишинг и подобные техники являются одними из самых популярных начальных векторов при атаках. Они, в свою очередь, могут привести к простою бизнеса, утечке и санкциям регуляторов. Всё это очень больно может ударить по бизнесу, поэтому эти риски мы считаем и подсвечиваем.
При расчёте возможных потерь от фишинга мы учитываем доступы, которые имеют попавшиеся на удочку, и типы данных, потеря которых дорого обойдётся компании. Конкретно в этом кейсе мы рассчитывали и риски остановки, и риски от утечки ПДн, потому что в результате учений получили креды от людей с доступом к ПДн и к администраторской части.
Для определения величины рисков мы оцениваем вероятность возникновения ущерба и его потенциальную тяжесть через амплитуду и импакт в условиях неопределённости. Исходные данные для определения вероятности возникновения ущерба стараемся брать из свежих исследований, «из жизни» или экспертным путём, задавая вопросы типа: «Сколько раз максимум нас взломают и унесут базу в течение следующего года?»
Зачастую так же поступаем и для амплитуды потенциальных потерь. Информацию для оценки импакта потенциальной тяжести берём у экспертов компании в этой области — юристов, DPO, топ-менеджеров — или отталкиваемся от штрафных санкций регуляторов.
Основываясь на этом, мы моделируем риски с помощью достаточно сложной математики: так как у нас нет уверенности, мы используем математические инструменты, которые могут её заменить.
«Под капотом» симуляции — метод Монте-Карло. И хотя с его помощью можно получить оценку с невысокой точностью, но на диапазоне вводных, в которых мы уверены, это работает как надо. Так мы можем понять, во что обойдётся компании потенциальный риск. При оценке мы не надеемся получить точных значений (у нас просто нет такой статистики). Суть моделирования в том, что мы не пытаемся угадать точные числа значений — чему равна вероятность, чему равен ущерб, — а оцениваем диапазон, в котором с уверенностью Х (в нашем случае — 95 %) лежит истинное значение. Для понимания — простой бытовой пример.
Никакая математика не поможет мне угадать, какая температура будет в Питере завтра. Но я на 95 % уверена, что она будет в диапазоне от — 40 до + 40 °C. Должно произойти что-то экстраординарное, чтобы я ошиблась.
Наша цель – получить разумный диапазон, из которого мы берём значение, в котором уверены, в нашем случае — на 95 %. Обычно используем 95-й перцентиль, то есть это число, когда 95 % элементов массива меньше или равно этому числу. Это значит, что мы на 95 % уверены, что хуже точно не будет. Мы остановились на 95-м перцентиле, потому что это наибольшая форма уверенности, и так проще гарантировать бизнесу какие-то изменения.
Некоторые компании используют медиану, то есть среднее значение массива данных, или 50-й перцентиль.
При моделировании рисков мы отталкиваемся от доступов, от события, от того, что ему предшествует и что после него следует. То, что предшествует, — это, скорее всего, будет то, что может сыграть на риск. А то, что следует после него, — на тяжесть потенциальных потерь.
Допустим, что это риск хакерской атаки. Что у нас должно произойти перед её началом?
Вероятно, проблемы с доступом. Или у нас много людей с доступом к информации. Может, VPN не работает. И потом всё, что происходит после этого, превращается в наши потенциальные потери.
Потери бывают первичными и вторичными. Первичные — то, что мы потеряем достаточно быстро и в любом случае. Например, трудозатраты на восстановление, деньги на новые «железки», ущерб от недополученной прибыли. Вторичные — это то, что может произойти потом, например, если мы получим штраф от регулятора. Это могут быть какие-то репутационные потери, которые также можно оценивать в деньгах.
Когда строится математическая модель, мы видим график и можем посмотреть на любой из перцентилей. Ниже показаны некоторые данные (как читать графики, показано в конце*).
Итак, можно видеть, что от остановки функционирования бизнеса в 95-м перцентиле мы потеряли бы около 97,5 млн рублей в год.
На втором графике отображены комплаенс-потери из-за инцидента с персональными данными.
Это вариант потенциальных потерь на текущий момент с учётом российского (152-ФЗ) и европейского (GDPR) законодательств и принятых оборотных штрафов (когда за утечку или другой инцидент регулятор штрафует компанию на процент от оборота). Здесь у нас получилось 270 млн рублей в 95-м перцентиле.
Если же не рассматривать вариант оборотных штрафов (на момент проведения учений закон ещё был на стадии законопроекта), то получаем:
а) Потери по части 152-ФЗ вышли бы около 10,5 млн рублей в 95-м перцентиле.
б) Потери по GDPR могли составить порядка 210 тыс. евро в год (в рублях по текущему курсу — около 21 млн рублей).
Важно сказать, что суммировать все эти риски нельзя, поскольку все негативные события в 95-м перцентиле не происходят разом, если вы не самый неудачливый человек в мире. Но при этом здесь всегда остаётся некоторая неопределённость.
Мы оценивали, сколько людей у нас поддаётся фишинговой атаке. Оценивали в том числе и по когортам (департаментам): выявляли самые слабые команды и планировали для них обучение.
Всех коллег, кто выдал данные или был к этому близок, мы направили на внеочередное обучение.
Метрики, которые мы отслеживали:
- Сколько писем разослали (2 000).
- Сколько человек открыли сообщения (647).
- Сколько перешли по ссылке (74).
- Сколько ввели корректный логин (подразумеваем, что и пароль — тоже) (37).
Эта конверсия очень интересна, как мне кажется. В итоге подсчитали, что попались 5,7 % сотрудников (при среднем успехе таких атак — около 30–35 %). Считали итоговый процент именно от количества открывших, потому что остальные даже почту не читают, мы не можем оценить их защиту.
Проводили оценку результатов также по репортам. То есть смотрели, через какое время после начала атаки начинают приходить сообщения от сотрудников в отдел безопасности. Очень важно, чтобы специалисты подразделения безопасности вовремя узнавали, что что-то происходит. Если это получается, то это уже 50 % успеха: мы получили информацию и можем реагировать.
Итак, в результате проведённого эксперимента мы получили данные, которые дали руководству понять всю серьёзность проблемы в цифрах возможных потерь. А службе информационной безопасности пришлось переписать протоколы взаимодействия и провести переподготовку сотрудников, сдавших информацию «преступникам».
* Как читать графики
По оси абсцисс (х, горизонтальная) — потенциальные потери, по оси ординат (у, вертикальная) — перцентили, вероятность. На нуле процентов — у нас худший расклад, когда вы самый неудачливый человек в мире, на 100 % — идеальный расклад. Чтобы взять 95-й перцентиль, например, нужно провести линию в параллель оси абсцисс на уровне 5 %. Для всеми любимой медианы (перцентиль — 50 %, «в половине случаев будет хуже, а в половине — лучше») нужно провести эту линию на уровне 50 %.
