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

Привет! Это Маша из AppSec Альфа-Банка. Недавно мы провели первый (для себя) багатон по кибербезопасности, прошедший при совместной работе ИТ, AppSec, команд Внутрикома и DevRel. Главными целями были пропаганда безопасной разработки и сближение разработчиков и команды AppSec.

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

Правила подготовки

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

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

Всего провели три воркшопа:

• Воркшоп №1: «Как работать с уязвимостями: гайд для команд разработки».
  Рассказали как правильно идентифицировать и классифицировать уязвимости, а также поделились лучшими практиками для команд разработки. Это помогло участникам понять, с чего начинать работу и на что обращать внимание.

• Воркшоп №2: «Подходы к исправлению уязвимостей в ваших приложениях».
  Методы исправления уязвимостей: разобрали реальные кейсы, обсудили инструменты и подходы, которые помогают минимизировать риски.

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

Открытие

Начали с бизнес-завтрака. Завтрак задаёт правильный тон: все сыты, довольны, бодры, веселы. Также мы раздали участниками фирменные стартер-паки: дрип-пакеты для кофе, стикерпаки и ремувки для настроения. 

Не забывайте про мерч. Мероприятие пройдёт, а память останется. 

После завтрака вице-президент по IT произнёс напутственную речь, подчеркнул важность кибербезопасности и пожелал удачи всем участникам. В 11:00 он торжественно ударил в гонг, символизируя старт багатона.

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

Два дня участники решали задачи, искали уязвимости и зарабатывали баллы. Мы постарались создать комфортные условия для работы: в офисе были организованы зоны для команд, на кухне — завтраки и обеды. Организаторы были на связи 24/7, чтобы оперативно решать возникающие вопросы и поддерживать участников. 

Задачи

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

А чтобы у команд было разнообразие и мотивация попробовать свои силы в чём-то новом, мы позволили участникам самостоятельно выбирать, и подготовили 4 типа заданий::

1. Устранение уязвимостей, выявленных инструментам автоматического сканирования (SAST/SCA).

2. Устранение уязвимостей, выявленных командой AppSec.

3. Написание автотестов безопасности

4. Поиск новых уязвимостей. 

Немного про механику задач.

Уязвимости для первого типа задач были сгруппированы по репозиториям. Каждая отдельная задача фактически состояла из N-уязвимостей, выявленных инструментами в репозитории. За каждую устраненную уязвимость выдавалось Х баллов — итоговое количество баллов за задачу соответствовало количеству уязвимостей (N) умноженному на Х. Если команда смогла устранить только часть уязвимостей в репозитории, то мы начисляли соответствующее число баллов.

Механика со стороны команд была достаточно простая. Необходимо:

• создать отдельную ветку, 

• внести изменения, 

• запустить сканирование ветки, чтобы убедиться что уязвимости устранены,

• открыть PR в релизную ветку и отписаться в чат.

PR смотрели техлиды соответствующей компетенции (на соответствие стандартам) и ребята из AppSec (наличие отчета о сканировании и его результаты). Если от всех был «ОК», то задача считалась «предварительно» решенной и команде начислялись баллы. 

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

Мы не требовали от команд проведения регресса и отчёта от тестирования во время багатона, но это было обязательным пререквизитом для раскатки, поэтому комадны были замотивированы проводить проверки до завершения задачи, чтобы не потерять баллы в случае, если перед релизом возникнут проблемы и понадобится вносить изменения в код.

Второй тип задач отличался от первого тем, что:

• каждая уязвимость была отдельной задачей,

• для подтверждения устранения необходимо было получить аппрув от AppSec.

Как и в первом случае, команды создавали отдельную ветку, вносили изменения в код и устанавливали поставку на тестовый стенд. Далее просили команду AppSec подтвердить факт устранения уязвимостей и после получения одобрения от техлида компетенции и команды AppSec, получали «предварительные» баллы.

Третий тип задач был направлен на написание автотестов безопасности.

Часть проверок, которые команда AppSec выполняет вручную при анализе доработок, можно автоматизировать. Это позволяет гарантировать, что эти проверки будут выполняться (например, встроив их в пайплайны команд), а также снизить нагрузку на специалистов AppSec. Именно такие проверки команды и реализовывали на багатоне.

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

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

Для этой активности мы создали абстрактные задачи без привязки к чему-либо. 

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

Примечание. В статье поделились задачами, похожими на те, что мы давали на багатоне. Заходите почитать, мы подробно расписали решения.

Закрытие

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

Собрали участников на внутренней площадке, оформив ее в стиле мероприятия. Плюс один хороший фон для фото. 

Торжественную часть не стоит затягивать.

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

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

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

Итоги

Несколько выводов в формате заметок.

• Мы вовлекли ИТ-специалистов в тему кибербезопасности и остались довольны цифрами – 24 команды до 10 человек. А через месяц собрали sold out (250+ участников) на внутренний CTF.

• Приятный «побочный» эффект — закрытые уязвимости, написанные автотесты безопасности и чистые репозитории.

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

• Развеяли мифы, что невозможно исправить уязвимость за 2 дня, а новую уязвимость найти в чужой функциональной области просто невозможно

Люди – главная ценность! Все получилось благодаря совместной работе четырех подразделений. За поддержку мероприятия спасибо ИТ, AppSec, Внутрикому и DevRel и отделу маркетинга.

И всем-всем, кто принимал участие.