Современные компании требуют особого подхода к обеспечению информационной безопасности. Отдел ИБ перестаёт быть только надзирателем и контролёром, начинает активно разговаривать с людьми, становится полноправным участником бизнес-процессов.

У финтех-компании Exness ежемесячно свыше 70 000 активных клиентов по всему миру, а весь бизнес находится в онлайне. Данные — основной наш основной актив и драйвер, поэтому защита информации — приоритет №1.

В Exness работают более 500 человек. Около 150 заняты в R&D и IT, много сотрудников технической поддержки, менеджеров по продажам, антифрод и комплаенс-службы. Все они так или иначе работают с чувствительными данными или имеют доступ к важному функционалу, внутренней информации, коду, админским консолям. Непреднамеренная ошибка или неинформированность персонала может стоить бизнесу миллионы. За примерами далеко ходить не нужно: новости пестрят сообщениями об утечках из незащищенного сервера хранилища Elastic, MongoDB или корзины S3, причинами которых зачастую был человеческий фактор.

Человек — самое слабое звено ИБ, поэтому мы поставили перед собой задачу повысить культуру информационной безопасности среди сотрудников. Делимся опытом, что мы для этого сделали и как оценивали результаты.

Задачу мы разделили на два направления:

1. Улучшить понимание вопросов безопасности среди технических команд.
   
2. Улучшить понимание вопросов безопасности среди всех сотрудников, в том числе, не IT-специалистов.
   

Назовем условно эти направления «организационное» и «техническое». Работа по первому направлению заключается в донесении общих вопросов цифровой гигиены, современных угроз, способов противодействия, возможных последствий для бизнеса. 

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

Цель — Security Аwareness

Security Аwareness — ключевое понятие информационной безопасности в компании. Сотрудники соблюдают правила информационной безопасности, если знают, понимают и разделяют их. 

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



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

Шериф или проповедник?

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

От теории — к делу! 

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

Обучение и вовлечение сотрудников

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

Для всех сотрудников мы проводим воркшопы (OSINT, brand protection, blind sql injections, lab machines pentest, cloud-specific hacking techniques) и делаем доклады на внутренних мероприятиях. Регулярное внутреннее обучение и живые демонстрации очень важны. Примеры эксплуатации типовых уязвимостей работают лучше долгих лекций. Объяснение «на пальцах», что такое асимметричная криптография, зачем нужна подпись в токене и как проще всего использовать Vault, значительно экономят время технических команд.

Мини-блог по безопасности в корпоративной социальной сети

Мы стараемся поддерживать постоянный поток постов от команды ИБ. Наши коллеги должны видеть, что мы постоянно держим руку на пульсе, даем советы, анонсируем нововведения, стараемся заинтересовать и привлечь каждого сотрудника.

Регулярные митапы, обмен опытом

На крыше нашего офиса в Лимассоле, помимо прекрасных видов, есть все возможности для проведения встреч на 100+ человек, чем мы регулярно пользуемся. Два-три раза в год мы собираем специалистов и обсуждаем безопасность приложений, управление рисками, devsecops-практики и другие вопросы. Мероприятия посещают сотрудники компании и представители локального ИТ сообщества, и тут наша главная задача в разрезе формирования внутренней культуры — показать, что вопросы ИБ интересны и важны.

Внутренний фишинг

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

Продуктовая безопасность

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

Постоянно общаемся с продуктовыми командами

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

Развиваем внешнюю баг-баунти программу на платформе HackerOne

Более трёх лет мы привлекаем внешнюю экспертизу для поиска уязвимостей в нашей инфраструктуре при помощи платформы HackerOne. В год мы тратим более $50к на выплаты вознаграждений, что совсем немного по сравнению с возможными убытками. Если у вас нет баг-баунти программы, рекомендуем запустить. За относительно небольшие деньги вы получаете фактически бесконечный по времени пентест.

Мы также используем отчёты об уязвимостях и потенциальных последствиях, которые нашёл «кто-то из Интернета». Эта информация помогает бизнесу принять решение о повышении приоритета и усилении требований к ИБ в новых продуктах, введении дополнительных проверок на уровне QA и автоматизированных средств контроля.

Ищем (и находим!) Security Сhampions в командах для локального контроля безопасности продукта

В современных реалиях при использовании Scrum/Agile моделей важно в каждой команде иметь хотя бы одного человека, который может выступать проводником ваших рекомендаций и «болеть» за безопасность продукта. В идеале нужна полноценная security-экспертиза в каждой команде, но ресурсов всегда не хватает. Через какое-то время из Security Champion может вырасти Devsecops или Application Security специалист, так что это неплохая возможность сменить фокус для продуктового инженера или разработчика. В нашем случае нам удалось найти и девопсов, и разработчиков, которые существенно улучшили понимание вопросов безопасности внутри команд.

Как мы ставим продуктовым командам задачи по ИБ

Для организации работы мы используем методологию OWASP ASVS в комбинации с описанными рисками для бизнеса. Для каждой команды мы вводим список контролей — требований к безопасности продукта. Это выглядит как набор рекомендаций, в котором каждой мере защиты соответствует свой риск. Документ показывает наглядно, что уже выполнено, что запланировано, и какие риски на данном этапе жизненного цикла продукта приняты бизнесом.

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

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

Пример контролей и релевантных рисков:

Что в итоге? 

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

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

1. Индекс безопасности продукта

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

• OWASP WRT — взвешенный риск. Сумма всех известных уязвимостей с коэффициентом в зависимости от серьёзности, умноженная на условную критичность системы для бизнеса.
  Эту метрику возможно получать как с внешней платформы баг-баунти, так и с внутренних сканеров безопасности и сообщений от команд. 
• Адаптированный список контролей OWASP ASVS 3.0. Каждый, применимый к сервису пункт имеет вес и его невыполнение понижает уровень безопасности продукта.
  На начальной стадии разработки продукта происходит верхнеуровневая оценка влияния рисков на бизнес-процессы в рамках продукта, применимости и реализуемости технических контролей. В ходе разработки, список актуализируется по ходу выполнения требований, уровень безопасности должен повышаться.

2. Результат регулярного пентеста, выполняемого квалифицированными внешними компаниями

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

По организационному направлению результаты более субъективны:

• Мы получаем больше сообщений от сотрудников по потенциальным уязвимостям и инцидентам, чем ранее. Сотрудники понимают важность своевременного сообщения.
• Продуктовые команды приходят на самых ранних стадиях проекта, появилось понимание, что предотвратить проблему гораздо проще, чем исправить.
• Меньше банальных ошибок, более зрелая с точки зрения ИБ разработка и управление сервисами. Осуществляется шифрование данных на всех уровнях, аудит вызовов API, работа с секретами, документирование.
• GDPR для бизнеса и команд — не просто набор букв, а понятный список требований к работе с данными, процессами, инцидентами.

Что планируем делать дальше?

• Ввести специализированные обучающие треки для менеджмента разных уровней (управление рисками ИБ, технологические нюансы, новые угрозы, защита от направленных атак);
• Запустить канал для анонимных сообщений о нарушениях ИБ;
• Ввести прозрачный KPI по безопасности для продуктового менеджмента;
• Мотивация и соревновательность, хороший уровень безопасности продукта должен быть предметом гордости и поощрения;
• Использовать высокий и подтверждённый уровень безопасности продукта для получения конкурентных преимуществ.

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