Как сэкономить миллион на латании уязвимых продуктов с помощью центра компетенций

«Я - скорость!» — программисты сегодня создают миллионы строчек кода очень быстро, в том числе под прессингом бизнеса. Гонка по сокращению времени выхода продукта на рынок приводит не только к нервным подергиваниям глаз у разработчиков, но и плодит уязвимости. Ими просто кишат сегодня российские приложения (кстати, мы уже рассказали об этом с цифрами в руках).

Как сэкономить миллион на латании уязвимых продуктов с помощью центра компетенций

По данным Стингрей Технолоджиз, каждое третье мобильное приложение, поступающее сегодня в российские сторы, потенциально уязвимо. А что касается веба, в 2020–2021 годах злоумышленники могли проводить атаки на пользователей в 98% приложений — согласно исследованию Positive Technologies. Чтобы улучшить ситуацию, нужно непрерывно обучать разработчиков кибербезопасности. Это можно делать своими силами, создав внутри компании Центр компетенций по безопасной разработке. Как? — Разбираемся вместе с Юрием Шабалиным, ведущим архитектором Swordfish Security.

Шаг 0. Расскажите сотрудникам про безопасность

Прежде всего объясните программистам, зачем им вообще нужно знать про эту вашу безопасность. Опишите конкретные риски: какие потери могут возникнуть, если компания выкатит релиз, в котором тут же найдут, к примеру, 15 критических уязвимостей, сколько миллионов потеряют инвесторы, сколько времени потребуется на разработку патчей (исправлений). Добавьте в свой рассказ реальные кейсы (например, всем известный случай с Equifax) — информация, подкрепленная практикой, воспринимается гораздо лучше.

Начните с малого (вводной лекции) и постепенно расширяйте спектр инструментов и способов обучения (см. следующие шаги). Плавно погружая сотрудников в темы ИБ с помощью различных форматов, вы построите Центр компетенций по безопасной разработке, сможете обучать команду и поддерживать ее интерес. По опыту Swordfish Security, это практически всегда приносит плоды: к примеру, после проведения обучающих митапов, семинаров и рассылок мы отмечаем, что в процессе код-ревью разработчики обращают внимание не только на функциональность и стилистику кода, но и на проблемы безопасности. И это без инструмента статического анализа!

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

Шаг 1. Соберите материалы

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

Чтобы этого избежать, соберите в одном месте всю информацию, касающуюся ПО: требования, результаты проверок, уязвимости, которые вы находите или находили когда-то, требования к архитектуре, рекомендации или удачные решения в области защиты и так далее — всё, что у вас есть.

Шаг 2. Создайте внутренний портал

С этим делом желательно не затягивать, чтобы можно было скорее перейти к следующим шагам создания Центра компетенций. Возьмите те материалы, которые удалось собрать на предыдущем этапе. Объедините информацию, которую вы когда-то отправляли сотрудникам в почте и мессенджерах и размещали на корпоративных порталах. Это могут быть справки, ценные ссылки, статьи — в общем, всё, что покажется вам полезным. Распределите собранные материалы по темам — структура должна быть понятной всем сотрудникам.

Таким образом, у вас получится некая корпоративная база данных по security. В качестве платформы для нее можно использовать всё, что вашей душе угодно: Confluence, XWiki, Wordpress, Sharepoint, собственные продукты. Нанимать дизайнера и программиста для оформления портала совсем не обязательно — например, чтобы создать новый раздел на Confluence и загрузить туда материалы, специальные знания не понадобятся. После того как база будет готова, не забывайте регулярно ее обновлять и дополнять новой информацией.

Шаг 3. Напишите руководство по безопасной разработке

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

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

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

Шаг 4. Делайте почтовые рассылки

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

Темы писем могут быть разные: отправляйте сотрудникам подборки полезных статей за неделю, обзоры новых уязвимостей, результаты соревнований и всё остальное, что посчитаете нужным. Чтобы ко дню очередной рассылки у вас был контент, ищите интересную информацию каждый день по 10-15 минут — тут различные агрегаторы ИБ-новостей вам в помощь. Все ссылки, подборки и прочий материал из писем можно дублировать на внутренний портал — это сделает его еще актуальнее.

Шаг 5. Разработайте интерактивные курсы

Глубокая база знаний — это хорошо, но стоит подкрепить ее другими формами обучения. Интерактивные курсы помогут команде еще глубже погрузиться в тему безопасности и отвлечься от сплошного чтения. Чтобы они заинтересовали сотрудников, сделайте их максимально непохожими на учебник: используйте в курсах как можно больше игровых элементов, вопросов, примеров из практики. Пусть разработчики немного развлекутся в процессе обучения (они это любят). А в конце тренингов можно добавить информационные слайды об отделе безопасности, мероприятиях, которые уже прошли или состоятся в будущем и т. п.

<p>Источник: архив автора</p>

Источник: архив автора

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

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

Шаг 6. Создайте онлайн-тренинги

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

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

Шаг 7. Проводите открытые митапы

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

Прислушивайтесь к разработчикам, они сами «подкинут» идеи для митапов. Например, мы приходили к командам и говорили им: «Ребята, у нас есть несколько тем. Выбирайте, что вам интересно больше всего». У нас был случай, когда команда мобильной разработки под Android почти единогласно попросила рассказать про использование встроенных в систему способах хранения ключей шифрования (Android KeyStore). Мы подготовили на эту тему подробную часовую лекцию, рассказали им, что это, как работает, какие плюсы дает — а дальше команда взяла информацию на вооружение и начала использовать ее в коде.

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

Шаг 8. Устраивайте CTF

CTF (Capture the Flag) — это вид игры, где нужно искать и добывать флаги. Например, в центре активности может быть специально подготовленное приложение с уязвимостями. Задача игроков — найти слабые места и проэксплуатировать их, за успешно выполненные задания участники получают флаги или определенное количество очков. Побеждает тот, у кого флагов или очков больше.

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

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

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

Вывод

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

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

11
реклама
разместить
3 комментария

... и ни слова про проектирование, тестирование уязвимостей и т.д.

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

Про проектирование, анализ защищенности и другие практики это тема отдельной статьи, и не одной, ведь практик безопасной разработки много :)