Про Secure by Design в кибербезе не слышал только ленивый, но не только лишь все смогут объяснить, как на практике выглядит процесс внедрения этого подхода в крупной ИТ-компании. Чтобы разобраться в этом, мы поговорили с Романом Паниным — руководителем направления архитектуры ИБ в крупной телекоммуникационной компании и автором Telegram-канала «Пакет безопасности».

Роман поделился собственным опытом применения Secure by Design и рассказал о преимуществах и издержках методики. «На десерт» — несколько полезных лайфхаков для тех, кто планирует внедрить эту практику в своей компании. Передаем слово эксперту! 

Первые шаги к внедрению Secure by Design

Я впервые познакомился с методикой Secure by Design, когда работал в одном крупном российском банке. Если отсечь массу нюансов, суть подхода сводилась к двум ключевым принципам: 

1. ИБ-служба выступает в роли полноценных Security Business Partners. Притом за каждым продуктом, сервисом или их группой закрепляется свой ответственный ИБ-архитектор.

2. Вопросы информационной безопасности прорабатываются с момента появления идеи продукта или фичи. 

В то время банки только осваивали эту методику, и ее применяли не все продуктовые команды. У меня была возможность сравнить результаты работы подразделений, использующих и не использующих Secure by Design. Коллеги, которые работали по методике, собирали намного меньше «граблей» и в итоге экономили силы и средства. Это положительно влияло не только на безопасность, но и на технологичность и зрелость продукта. 

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

Продуктовые команды поначалу отнеслись к внедрению Secure by Design скептически. Они не понимали, как теперь работать с ИБ-архитекторами и какую информацию им предоставлять. Сперва коллеги не осознавали ценность нового подхода и опасались, что он растянет time-to-market и увеличит их трудозатраты.

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

Как удалось реализовать Secure by Design

Перейду к результатам и расскажу, как методику Secure by Design получилось реализовать на практике.

Организационный аспект

Мы закрепили за каждым продуктовым кластером ответственного ИБ-архитектора и определили сценарии, когда нужно включать в процесс безопасников:

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

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

3. Добавление или, напротив, отказ от внешних точек выхода в интернет.

4. Изменения во взаимодействии с партнерами и клиентами. Это может быть переработка структуры API сервисов или пересмотр бизнес-логики продуктов.

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

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

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

Обычно процесс выглядит так: ИБ-архитектор встречается с каждой подопечной продуктовой командой минимум раз в две недели. На встречах обсуждают:

• Что сделано за прошедшую неделю.

• Планы на ближайшее время.

• Выполненные и невыполненные задачи по информационной безопасности.

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

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

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

Технический аспект

О Daily, Scrum и планерках можно рассуждать долго, но работа ИБ-архитекторов выходит за рамки обсуждений. Рассмотрим, как Secure by Design реализован в компании с технической точки зрения.

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

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

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

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

Преимущества и издержки Secure by Design

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

Плюсы Secure by Design

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

Secure by Design учитывает потенциальные ИБ-риски уже на стадии анализа требований к продукту. На этом этапе формируется полный перечень необходимых средств защиты. Команда изначально включает в бюджет расходы на безопасность и планирует соответствующие трудозатраты.

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

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

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

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

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

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

Ограничения Secure by Design

Основное ограничение этого подхода — увеличение трудозатрат архитекторов ИБ или Security Business-партнеров. Количество контрольных точек для них значительно возрастает. Чтобы быть в курсе процесса, специалисты по безопасности участвуют в Sprint Review и контролируют подготовку к релизам. Иногда их присутствие на мероприятиях требуется для подстраховки, даже если вопросы ИБ там не обсуждаются. От архитекторов ИБ также нужно более глубокое понимание как бизнес-контекста, так и технической составляющей продуктов.

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

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

6 простых, но полезных советов

А теперь к обещанным лайфхакам по внедрению Secure by Design. Хотя эти советы могут показаться очевидными, они основаны на моем практическом опыте. А как заметил классик, опыт — лучший наставник.

Лайфхак 1. Оцените целесообразность внедрения методики

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

Еще одно ключевое условие — наличие множества ИТ-продуктов и сервисов. Например, внедрение Secure by Design целесообразно для федеральной торговой сети с собственными приложениями, CRM-системами и даже центрами обработки данных. Для небольшого локального бизнеса, использующего только кассовое ПО и сайт закупок, такой подход может оказаться неоправданным. При ограниченной ИТ-инфраструктуре временные и финансовые затраты на внедрение Secure by Design могут не окупиться.

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

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

Лайфхак 2. Оцените объем технического долга

Значительный технический долг может стать весомым аргументом, чтобы убедить руководство компании внедрить Secure by Design. На начальном этапе эта практика потребует дополнительных вложений, но она позволит значительно сэкономить на исправлении ошибок, допущенных в ходе разработки. 

Лайфхак 3. Внедряйте роль Security Champion в продуктовых командах

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

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

Лайфхак 4. Обеспечьте раннее взаимодействие с ключевыми специалистами в продуктовых командах

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

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

Лайфхак 5. Не ломайте сложившиеся процессы продуктовых команд

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

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

Лайфхак 6. Документируйте ключевые принципы взаимодействия ИБ-архитекторов и продуктовых команд 

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

Надеюсь, мой опыт применения Secure by Design окажется интересным и полезным для читателей Хабра. Если у вас возникли вопросы, или вы хотите поделиться своими кейсами реализации такой практики, не стесняйтесь писать об этом в комментариях.