Что разработчикам и компаниям надо знать о безопасности кода: интервью с Юрием Шабалиным

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

Но всё это не гарантирует, что ваш код — безопасный, а злоумышленники не смогут его взломать. Мы поговорили с Юрием Шабалиным, который уже много лет занимается вопросами безопасности, и выяснили, что значит «безопасный код» и как вовлечь программистов в проблемы безопасности.

Юрий Шабалин

Генеральный директор «Стингрей Технолоджиз», ведущий архитектор ГК Swordfish Security.

Почему информационная безопасность

— Юрий, привет! Расскажи почему ты решил заниматься именно информационной безопасностью? Как вообще пришёл в эту сферу?

— Довольно обычная история. На момент выбора темы диплома на четвёртом курсе мне надо было понять, куда идти и что делать. Один из немногих адекватных предметов, который у нас был, — защита компьютерной информации. И я решил писать диплом по криптографии, эта тема привлекла меня больше всего. Тогда меня безумно восхитило, что можно взять два разных ключа, одним зашифровать информацию, а другим расшифровывать — и на выходе получить то же самое значение. Это была прям магия, в которую мне захотелось погрузиться поглубже. В итоге я начал искать работу в компаниях, связанных с информационной безопасностью. Так я попал на собеседование в «Позитив Текнолоджиз», где получил должность и работу младшего security-инженера. Я не знаю, почему меня взяли, учитывая, что я ничего не знал, — но спасибо им за это. Дали мне дорогу в светлое, безопасное будущее.

Что такое безопасный и небезопасный код

— Есть проблема — разработчики пишут код, который бывает небезопасным. С другой стороны, все разработчики говорят: «Мы хотим писать хороший код. Надо писать хороший, красивый, грамотный код». И кажется, что он будто бы по умолчанию уже должен быть безопасным. Так что значит «безопасный» и «небезопасный» код?

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

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

Как появляются уязвимости в программном обеспечении

— Я правильно понимаю, что в подавляющем большинстве разработчики об этих вещах не задумываются или просто в них не разбираются, поэтому не знают, что об этом стоит думать?

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

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

Как понять, что в проекте есть проблемы с безопасностью кода

— Тогда такой момент. Например, у меня есть какой-то проект — пусть я тимлид, CTO или руководитель компании. У меня есть штат разработчиков. Как мне понять, что на проекте есть проблемы с безопасностью кода? Меня никогда не ломали — или, по крайней мере, мне так кажется, я не знаю о случаях взлома. У меня вроде бы всё хорошо. Зачем мне нужно задумываться о безопасности?

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

Зачем тратить деньги на безопасную разработку

— Если я руководитель бизнеса, то у меня возникает такой вопрос. У меня же всё было нормально. Я уже пару лет работаю. Ничего не происходило. Зачем мне вкладывать лишние деньги в безопасность? В чём моя выгода?

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

Сколько стоят пентесты

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

— Стоимость зависит от масштаба компании, а также от того, кто будет работать над проектом. Также учитывается, будут ли проводить анализ при помощи инструментов (просто сканерами прогонят), или будут трогать руками, либо всё вместе. Важно, что смотрят: open source, код, приложение. Если будет перепроверка после устранения проблем заказчиком, то стоимость выше. Стоимость может варьироваться от условных 100, 200 тысяч до миллионов рублей.

Когда нужно задумываться о безопасности кода

— Есть ли какие-то стадии жизненного цикла продукта, на которых такими вопросами и пентестами даже не стоит озадачиваться? Или типы продуктов, в которых это не принципиально?

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

Есть такая замечательная методология, фреймворк Building Security In Maturity Model (BSIMM). Это анализ уровня зрелости. Лозунг этой методологии сейчас — shift everywhere. В отличие от shift left (сдвига влево, к самым ранним стадиям разработки), новая парадигма предполагает анализ безопасности везде, где он принесёт наибольшую пользу.

То есть заниматься безопасностью нужно сразу, с самой первой строчки кода, с самого первого требования. Даже ещё раньше — на стадии продумывания архитектуры системы. Ведь безопасная разработка — это не только статический анализ кода. В неё входит огромное количество практик и активностей, в том числе динамический анализ, исследование open source, контейнеров, Kubernetes и многое другое.

Как обстоят дела с безопасностью в российских приложениях

— Насколько всё плохо или хорошо с безопасностью российских продуктов? Насколько на мировом уровне наши приложения выглядят хорошо или плохо?

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

Виды проблем с безопасностью кода

— Какие проблемы с безопасностью бывают на проектах? Чем они грозят компании или технической команде?

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

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

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

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

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

К чему приводят уязвимости в коде

— Есть пример из известных продуктов, какой-то громкий кейс, как цепочка уязвимостей привела к проблемам?

— Самый громкий кейс из американского общества — это взлом компании Equifax, бюро кредитных историй. У них через уязвимость выполнения кода слили данные всех клиентов (145 миллионов граждан США, Канады и Великобритании), всех сделок и всего остального. В итоге акции компании, стоимость которой оценивалась в несколько миллиардов, в один день упали до цента.

Ну и в России немало свежих примеров. Взять хотя бы утечки из «Яндекс Еды», Delivery Club, «СДЭК» и других компаний.

Человеческий фактор в информационной безопасности

— Там проблема была в технических уязвимостях или какой-то человек внутри компании решил принести с собой флешку?

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

Статистика уязвимостей

— А есть ли какая-то статистика по тому, какую долю проблем доставляют уязвимости технического характера, а какую всё, что связано с человеческим фактором?

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

Как сделать разработку безопасной

— Что должна сделать компания, чтобы понять, что их разработчики впитали некую культуру, что эта культура поддерживается, работает и позволяет делать более безопасные продукты?

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

Ключевые ресурсы — как человеческие, так и денежные. И с тем, и с другим бывают проблемы. И того, и другого не хватает. Надо искать.

Спрос на профессию безопасника

— Ты имеешь в виду, что безопасников на рынке не хватает или маловато в компаниях обычно?

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

Сколько зарабатывают специалисты по безопасности

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

— Я бы поспорил. Внутри безопасности есть много всего, на чём можно специализироваться. Есть безопасность Kubernetes, есть тестирование на проникновение, есть безопасность приложений, реагирование на инциденты, разработка.

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

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

Поддержка государства

— Какие-то госпрограммы даже идут?

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

Как внедрить принципы безопасной разработки

— Разработчики могут быть довольно капризными и не горят желанием брать на себя лишнего, заморачиваться с какими-то побочными вещами (нередко это оправданная позиция). В принципе, вообще сотрудники не очень любят какие-то инициативы, которые приходят сверху. Приходит руководство и говорит: «Теперь мы все будем заниматься безопасностью, строить у себя центр безопасной разработки. Всё будет классно». Разработчики такие: «Ё-моё. Ну опять. Ну что им всё не живётся спокойно?» Соответственно, логичная реакция — большая часть начинает эти изменения пытаться саботировать или спускать на тормозах. К нам уже приходили с разными инициативами — пытались внедрять новый мессенджер или планировщик. Мы вроде бы говорили: «Да», а сами спускали это на тормозах. Оно само отмерло. Попробуем и сейчас так же.

Как с этими вещами бороться, но не бороться с разработчиками? Победить это сопротивление, но чтобы при этом не ломать людей, а вовлечь, сделать их своими союзниками?

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

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

Они же в среде, внутри. Взять даже твой пример. Новый инструмент появился. Девяносто восьми это не зашло, а двум людям зашло. Они за обедом начинают рассказывать остальным, как это круто, удобно. В новом планировщике за пять минут на неделю задачи можно раскидать. Нотификации приходят куда угодно, всё здорово. Другие думают: «Может быть, попробовать? Может быть, не такая ерунда?» Потихоньку так всё это и «продаётся» внутри компании без давления, естественно. Для безопасности это идеально.

Как избавиться от уязвимостей с помощью амбассадоров безопасности

— Фактически задача состоит в том, чтобы найти неких амбассадоров безопасности среди разных категорий сотрудников, разных функциональных ролей, которые бы где-то в своей среде, где им доверяют, среди тех, кто находится рядом с ними, с энтузиазмом всё это дело промоутировали, проповедовали, были такими евангелистами?

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

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

Практика внедрения безопасной среды

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

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

Начать, конечно, стоит с некоего портала по ИБ в компании, на котором должны быть все материалы: ссылки на курсы, записи с вебинаров, записи с предыдущих встреч, новостные рассылки. Здесь должны быть ответы на самые разные вопросы как по темам ИБ, так и по мероприятиям. Организовать такой портал можно даже на Confluence.

У нас в этом плане есть немало примеров такого рода. Мы приходим к клиенту и просим показать его внутренние требования по безопасности, которые предъявляются к системам. И после долгих поисков команда просто пишет их с нуля. А ведь это одна из ключевых вещей. Она должна быть на портале в числе прочего и легко находиться.

Далее начинаем реализовывать небольшие инициативы. Банально можно начать с еженедельных рассылок по новым уязвимостям, техникам атак. Какие-то интересные статьи и всё такое. Это можно делать в начале недели или в конце, как показала практика. В пятницу вечером, когда все устали, либо с утра в понедельник, чтобы прийти в рабочий режим.

Подборку составить довольно просто, поскольку информации очень много. Безопасник, уделяя в день по 10–15 минут, спокойно может составлять такие дайджесты и рассылать с небольшой преамбулой еженедельно. Это реально работает, хоть и не сразу. Но через пару-тройку недель народ начинает включаться. Условно, у разработчика, который пишет на Java, новость: «Обнаружена критическая уязвимость в Java-библиотеке, благодаря которой удалось получить доступ к 50% продуктов, которые её используют». Он её прочитал и подумал: «Интересно. Пойду посмотрю, есть ли у меня в проекте или нет». Такие вещи цепляют.

Хорошо работают внутренние курсы. Когда приходит новый сотрудник из целевого подразделения, то есть тестировщик, аналитик, безопасник, разработчик, ему назначается лёгкий интерактивный курс с базовыми знаниями. Его основная цель — показать, что в компании есть безопасность, рассказать об основных принципах конкретного направления. И в завершение: «Коллеги, если у вас возникнут вопросы по безопасности, у нас есть специальный ящик, специальный чат-канал в мессенджере. Пожалуйста, обращайтесь». Такое первое знакомство с безопасностью в компании.

Дальше эти курсы можно расширять, делать очные семинары, вебинары. Ребята сами могут готовить какие-то материалы. Можно приглашать специалистов из других компаний, из банков. В Mail.ru раньше раз в квартал делали открытый вебинар по безопасности, куда приглашали всех желающих. Это было очень круто.

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

И эта активность хорошо помогает искать security champion. Она подсвечивает, кто из разработки, из тестирования либо показал наилучшие результаты, либо проявил наибольшую активность. Это и есть потенциальные чемпионы, которые наверняка проявят себя и в других активностях. Главное — постоянно поддерживать тему, подбрасывать дровишек в этот костёр.

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

Как вовлечь людей и на какой результат можно рассчитывать

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

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

И не стоит сразу ждать большой вовлечённости. Например, мы проводили у одного из клиентов несколько CTF. В первой итерации их было три — по Android, iOS и Web. В CTF по Android приняли участие 15 человек. По Web — 20 человек. По iOS — один. Тех, кто проявил активность, было не более 20% от общего числа. Ну а в iOS одному пришлось зажигать. После этого был проведён ряд мероприятий, о которых я рассказал выше. На втором CTF было уже 30–50 человек. В третий раз у нас в каждом из трёх CTF поучаствовало по 100 человек. Потом ребята делились впечатлениями, как это всё происходило, как кто и что искал, началось мощное движение внутри.

И не нужно смотреть на то, что сначала интересуется лишь несколько человек, — про мероприятие быстро узнают другие сотрудники. У нас был классный пример, когда во втором нашем CTF принял участие директор отдела QA. После этого заинтересованность людей не только из подразделения, но и из других начала ползти вверх. Он рассказал про активности внутри, и ребята стали больше внимания уделять безопасности.

Типичные ошибки отделов безопасности

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

— Самая первая ошибка — это навязывание из-под палки, обязательное участие, особенно когда это доносится в форме приказа. И все такие: «У меня фича через два дня выкатывается. А тут ещё этот курс по безопасной разработке. Оно мне надо?» И тогда все присутствуют формально: открыли экран и занимаются своими делами. В принудительном порядке это результатов не принесёт и не отложится в голове.

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

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

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

У нас был забавный кейс, когда руководитель отдела безопасности, видя, что на уязвимости никто не обращает внимания, начал делать еженедельную рассылку. Было десять команд. Он делал простенькое письмо — scoreboard, где было количество команд с наибольшим количеством уязвимостей. Рассылал это топ-менеджменту, начальникам отделов. Первую неделю, вторую, третью, четвёртую. А потом в результатах те, кто был на первом месте, уже оказались на третьем. Никто не хотел возглавлять позорный рейтинг. Конечно, глубоких качественных перемен таким образом не добиться, но некую конкретную задачу решить можно.

Кто должен быть лидером безопасной разработки

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

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

Как найти хорошего лида безопасной разработки

— Как определить, что человек действительно заряжен? Как бы ты искал такого сотрудника внутри компании, внутри отдела безопасности, если он должен быть именно из безопасников? Как бы ты к этому подошёл?

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

Но кто-то должен весь этот процесс координировать. Кто-то, кто скажет: «Вася, ты новости постоянно читаешь. Скидывай мне самые интересные двумя предложениями. Дима, ты в CTF постоянно участвуешь. Их же выкладывают в паблик иногда. Скидывай мне то, что тебе понравится, какие там интересные кейсы были. Мы их будем включать».

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

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

— Наверное, последний вопрос, который хотел бы задать. Он неконкретный совсем. Возможно, мы о чём-то забыли поговорить. Может быть, упустили какие-то важные темы.

— На самом деле мы о многих важных вещах поговорили. Но каждую из них можно брать и копать вглубь. Но вот что очень важно, если мы говорим о security champion: мы обсуждали их в контексте разработки, но ведь они могут быть везде — в среде тестирования, в DevOps, аналитике, руководстве. Ведь безопасностью можно заниматься на любом этапе продукта и в любой из его составляющих, да и не только в том, что связано непосредственно с продуктами. Такой финальный аккорд у меня получился.

Что почитать о безопасной разработке программного обеспечения

— Это ещё не финальный аккорд. Я понял, о чём я забыл спросить. Что порекомендуешь почитать, посмотреть по теме? Может быть, подписаться на кого-то? Какие-то курсы, может быть?

— Конечно же, подписывайтесь на мой канал в Telegram Mobile AppSec World. Он про безопасность мобильных приложений, но сопутствующие материалы я тоже публикую. Читайте и другие Telegram-каналы по безопасности, которых немало. Они разного качества и разной тематики, разной направленности, нужно выбирать.

Рекомендую посмотреть фреймворки BSIMM (Building Security In Maturity Model), и OpenSAMM от OWASP, посвящённые безопасной разработке.

Рекомендую также по возможности участвовать в конференциях по безопасности — OFFZONE, Positive Hack Days, ZeroNights, а также в локальных мероприятиях, митапах от OWASP, Mail.ru, «Яндекса» и так далее. После ивентов все выкладывают записи докладов и презентаций. Так что можно смотреть что интересует в удобное для вас время.