Играли в детстве в сыщиков? SecDevOps во многом то же самое

— В западной терминологии есть три термина: SecDevOps, DevSecOps и DevOpsSec. Мы будем рассматривать самый оптимальный подход, то есть SecDevOps, когда безопасность участвует в разработке продукта с самого начала и на всех ее этапах. Если «Sec» возникает в середине процесса, это не совсем правильно, когда же о безопасности начинают задумываться на финальном этапе разработки, это практически преступление. У себя мы называем это SSDL (Software Security Development Lifecycle).

Я бы хотел сделать небольшое отступление о DevOps. На мой взгляд, этот термин сродни Machine Learning — математическим методам, которые разработали и применяли еще в ХХ веке. Военные довольно давно используют Machine Learning, но хайп вокруг этого понятия начался в середине 2000-х годов. То же самое характерно для DevOps. В компаниях традиционно были команды, которые писали код, администрировали его и отслеживали жизненный цикл ПО. Просто в 2007 году появился акроним от development и operations — DevOps.

Чем отличается SecDevOps от DevOps? Безопасность становится надстройкой над всем процессом. На самых ранних стадиях, начиная с проектирования той или иной функциональности, команда разработки работает в тандеме с командой безопасности. Проводится моделирование угроз, решение проектируется с учетом различных практик по обеспечению безопасности. На остальных стадиях проверяются уже качество реализации и соответствие корпоративным стандартам. Надо понимать, что процесс здесь важнее конечных инструментов, они могут меняться и улучшаться со временем. Использование такого подхода к безопасности при разработке ПО — вопрос зрелости компании. Если вы разрабатываете сервис в рамках стартапа, скорее всего, вы просто не сможете позволить себе такой процесс, поскольку он требует больше ресурсов, в том числе временных. Но когда речь идет о крупной компании, с финансовыми и GR-рисками, то множество контролей безопасности более чем уместно и позволяет решить ряд проблем до того, как они появятся в production.

Компания сама должна созреть для того, чтобы добавить к акрониму DevOps термин «Sec». Никакие внешние рекомендации не заставят использовать в процессах разработки Security. Отмечу, что я говорю о компаниях, которые не должны выполнять требования внешних регуляторов. В других случаях использование инструментов безопасности с самого начала разработки диктуется отраслью и особенностями бизнеса.

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

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

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

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

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

Нашу модель работы можно разделить на 5 этапов. Первый — обучение: как я уже сказал, мы обучаем разработчиков (организуем для них семинары и предлагаем пройти наши тесты), а также проводим внутренний CTF (Capture the flag, командные соревнования по информационной безопасности. — Прим. ред.). Заряжаем их своим visibility, чтобы они понимали, что у нас одна цель: мы хотим вместе сделать отличный продукт. Также мы работаем с менеджерами: вникаем в вопросы планирования, интегрируемся в процессы работы продуктовых команд. Затем начинается action: мы проводим Security Design Review — анализ архитектуры будущего решения. На этом этапе проще оценить уровень фрода и найти потенциальные уязвимости. Исправлять уязвимости в архитектуре, когда продукт уже запущен, в разы сложнее. 

Следующий этап — автоматизированный анализ. Мы используем различные инструменты и подходы, в частности SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing). Четвертый шаг — ручная проверка, мы регулярно смотрим коммиты и раз в квартал делаем общий срез по проекту, чтобы не потерять общую картину. Наконец, мы реализуем response — обнаружение и реагирование на инциденты ИБ. Также мы используем Bug Bounty, проводим внешние аудиты. Это дает непредвзятую оценку нашей работы и работы разработчиков. 

Всё вместе — это целый набор operations, которые мы реализуем совместно с разработчиками. «Яндекс.Такси» — это часть «Яндекса», следовательно, мы можем пользоваться всеми фичами безопасности, которые есть у головной компании. Например, у нас есть свой SOC: он вносит серьезный вклад в набор наших operations.

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

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

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

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

В любом процессе есть 2 фазы: onboarding и processing. Когда вы начинаете защищать продукт или сервис, очень важно разобраться в бизнес-модели, понять, какие болевые точки существуют. Нужно погрузиться в процесс разработки и разобраться в релизном цикле. Если команда и продукт существуют довольно давно и раньше безопасностью в компании не занимались, то этот процесс обычно напоминает пожаротушение: обнаруживается много проблем, которые нужно устранить. Иногда их нужно решить здесь и сейчас. Затем уже начинается процессная работа с командой: регулярный анализ архитектуры, review кода и аудиты, систематическое сканирование автоматикой. При переходе на SecDevOps необходимо проанализировать эти проблемы (своими силами или привлечь аудитора со стороны), определить узкие места и внедрять ИБ так, чтобы закрыть их. Если разработчики пишут небезопасный код, стоит начать с их обучения. Если есть проблема с безопасностью конфигурации серверов, необходимо в первую очередь заняться ею. По сути, задача проста: получить максимум выгоды за короткое время. 

Я считаю, что «Яндекс» эти тренды создает.