Security Champions. Где найти чемпионов?

Security Champions. Где найти чемпионов?

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

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

Чтобы подружить разработчиков с безопасниками и сместить безопасность влево в жизненном цикле разработки ПО, придумали программу «чемпионов безопасности» (Security Champions).

Откуда взялись чемпионы

Одно из первых упоминаний о чемпионах безопасности как о сотрудниках, распространяющих среди коллег принципы безопасного поведения, встречается в статье Selecting security champions Тревора Габриэль и Стивена Фернелла из Центра безопасности, коммуникаций и сетевых исследований университета Плимута, Великобритания, опубликованной в журнале Computer Fraud & Security в августе 2011 года.

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

T. Gabriel and S. Furnell, “Selecting security champions”, Computer Fraud & Security, vol. 2011, no. 8, pp. 8–12, 2011.

https://www.academia.edu/5444900/Selecting_security_champions

В ЧЁМ ПРОБЛЕМА?

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

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

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

Массовая потребность в безопасности в условиях ограниченности ресурсов приводит к появлению «островов безопасности». ИБ-подразделение может разрабатывать политики и стандарты кодирования, но из-за нехватки ресурсов они так и останутся никому не нужными файлами где-то на внутреннем портале. Разработчики когда-нибудь узнают, что в компании есть руководство по безопасной разработке, а если в компании внедрён документооборот, даже поставят галочку «Ознакомлен». Но применять этот документ они вряд ли начнут. В результате забота о безопасности продуктов перемещается на более поздние этапы жизненного цикла разработки ПО. О Shift-Left Security и речи не идёт. Каждая обнаруженная проблема безопасности становится «золотой».

КАК ДОБАВИТЬ ИБ?

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

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

КТО СТАНЕТ ЧЕМПИОНОМ?

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

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

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

«Пояса безопасности» — уровни сертификации чемпионов в Adobe

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

Одна из самых интересных сторон программы чемпионов по безопасности Adobe — требования к набору навыков сотрудника, который берёт на себя эту роль:

• обширные и глубокие знания о продукте своей команды;
• способность предвидеть потенциальные проблемы безопасности и риски в ходе разработки продукта;
• готовность влиять на изменения.

ПЛАН ДЕЙСТВИЙ

Чемпионы безопасности не появятся сами по себе. Здесь не обойтись без административного ресурса. Программу должны поддержать на самом высоком уровне. Без этого инициатива станет просто бесполезным набором лозунгов.

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

Кроме поддержки, план запуска программы чемпионов должен содержать следующие пункты:

• Цели — зачем компании эта программа.
• Ожидания — какие результаты она должна принести.
• Способы выявления чемпионов.
• Мотивация.
• Обучение.

Остановимся на этих пунктах подробнее.

Цели программы чемпионов

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

Ожидания

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

Как выявить чемпионов

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

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

В этом случае выявить их поможет специализированное тестирование, подобное тесту Security Champions, разработанному командой Start EDU (рис. 1).

Рисунок 1. Тест Security Champions. Тест составлен на базе 20 реальных взломов известных приложений. Задания отличаются по сложности и проверяют пять важных навыков безопасной разработки.

Тест составлен на базе 20 реальных взломов известных приложений. Задания отличаются по сложности и проверяют пять важных навыков безопасной разработки.

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

Мотивация

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

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

• Участие в мероприятиях. Чемпионы по безопасности могут за счёт компании посещать конференции по безопасности, участвовать в CTF и хакатонах.
• Признание и поощрение. Важно признавать достижения чемпионов по безопасности, например регулярно сообщать о достигнутых результатах в информационных бюллетенях. Для обозначения прогресса чемпиона по безопасности можно использовать геймификацию с помощью уровней. Это поможет чемпиону по безопасности иметь то, над чем нужно работать, и отмечать свои успехи на пути к безопасности. Можно даже выделить чемпиона по безопасности как отдельную должность, чтобы мотивировать сотрудников на вступление в организацию.
• Измерение прогресса. У чемпионов по безопасности могут быть цели и ключевые результаты (OKR), которые необходимо достичь в области безопасности. Таким результатом может быть, например, выявленный процент критических уязвимостей, количество мероприятий по моделированию угроз, пройденные модули обучения по безопасности.

Обучение

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

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

ЧТО МОЖЕТ ПОЙТИ НЕ ТАК

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

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

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

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

В итоге полезная идея была уничтожена её неграмотной реализацией.

РЕЗЮМЕ

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

Реализовать принцип Shift-Left Security, переместив заботу о безопасности софта как можно ближе к началу жизненного цикла, мешают следующие факторы:

• разработчики не изучают вопросы безопасности, потому что воспринимают их как что-то постороннее, а времени и так не хватает;
• у безопасников не хватает квалифицированных специалистов, чтобы внедрить принципы безопасной разработки в продуктовых командах и обучить разработчиков.

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

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

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