Программисты «Яндекса» одновременно разрабатывают и поддерживают массу сервисов и приложений. Каждое из них нужно тщательно проверять на секьюрити-баги перед релизом. Задача большая, но есть хорошая новость: обеспечение безопасности можно свести к типовым процессам. А значит, они легко поддаются автоматизации! Я руковожу группой продуктовой безопасности «Яндекса». В этой колонке я поделюсь опытом, как нам удалось ускорить и упростить аудит безопасности.
Классическая ситуация: приложение функционально уже готово к релизу, но остается пройти еще один важный этап цикла разработки — финальный аудит безопасности. Как сделать его удобным и эффективным и с точки зрения команды продукта, и с точки зрения ответственных за безопасность? Как уменьшить влияние аудита на скорость разработки? На эти и другие сопутствующие вопросы мы попробовали дать ответы, исходя из собственного опыта, на предыдущей встрече российского отделения OWASP, которая проходила в московском офисе «Яндекса».
Когда обсуждают роль безопасности в цикле разработки программного обеспечения, то часто ссылаются на методологию от Microsoft.
Здесь все кажется логичным, правильным и, к сожалению, немного утопичным. Тем не менее это хорошая цель, к которой стоит стремиться, внедряя SDL частями в своей компании. Ведь, как известно, слона лучше есть по частям. В «Яндексе» внедрением SDL занимается выделенная группа продуктовой безопасности. Мы проводим тренинги, пишем внутренние руководства для разработчиков, поддерживаем «Охоту за ошибками», внедряем глобальные контроли и технологии безопасности и, конечно же, стараемся максимально автоматизировать свою деятельность. В общем, занимаемся множеством интересных вещей. В их числе — финальный аудит безопасности новых проектов и больших релизов наших сервисов. В качестве основы для методологии аудита используем OWASP Security Testing Guide с поправками на наши внутренние технологии и специфику. До недавнего времени процесс на верхнем уровне описания сводился к следующим этапам.
- Менеджер продукта заполняет специальную форму, в которой указывает различного рода информацию о релизе: краткое описание, ссылки на исходный код и тестовую среду, контакты разработчиков и прочее.
- Заявка на аудит в виде тикета попадает в единый с разработчиками багтрекер.
- Менеджер со стороны группы продуктовой безопасности разбирает этот поток и принимает решение о том, как дальше сложится судьба задачи.
- Задача попадает к аудитору, и начинается самое интересное.
В этом процессе есть недостатки, влияющие на скорость (и не только) работы.
- Промежуточное звено согласования (менеджер со стороны ИБ).
- К сожалению, нередко заявки приходят без нужного запаса по времени на сами работы.
- Мы всё еще находим типовые проблемы безопасности на финальной стадии.
- Финальный аудит становится «бутылочным горлышком» для цикла разработки.
Это все причиняло нам и самим сервисам постоянную боль. Мы подумали и решили, что нужно что-то делать! Во-первых, нам, конечно же, необходимо сдвигать задачи, связанные с ИБ, ближе к началу цикла разработки. Это очевидно. Во-вторых, мы любим автоматизацию, и самое время ей вновь заняться. Для этого нам понадобится новая суперформа для приема заявок на аудит безопасности, а также помощь наших «роботов».
Для начала мы подумали: почему бы не добавить полноценный опросник в форму и не давать рекомендации сразу же по мере ее заполнения? Сказано — сделано. Мы добавили вопросы про возможную специфичную (и связанную с рисками) функциональность и повязали их с нашими внутренними руководствами для разработчиков. То, что мы перешли, по сути, от статической формы к динамической, позволило подгружать по мере ее заполнения вопросы, соответствующие ситуации. Например, для мобильных приложений мы спрашиваем про платформоспецифичные настройки безопасности.
Получается, что мы не возлагаем все надежды на финальный аудит безопасности, но стараемся использовать его максимально, в том числе и для внедрения наших глобальных систем контроля и защитных технологий. К первым относятся различного рода автоматизированные сканеры безопасности веб-приложений и анализ кода, а ко вторым, например, Content Security Policy, который мы сейчас внедряем повсеместно.
Также стоит упомянуть HTTPS/TLS (про особенности его внедрения мы рассказывали на YaC в 2014 году), но его мы внедрили во всех наших продуктах, и вопрос в анкете носит скорее формальный характер.
Если менеджер отвечает в анкете, что какая-то из требуемых технологий еще не внедрена в его сервисе, то автоматически заводится соответствующий тикет на внедрение. Напрашивается закономерный вопрос: а что, если менеджер ответит не совсем честно? Получается, что внедрения контроля не будет? Мы это все равно выясним в рамках непосредственно аудита, а анкета (и автоматический тикет) позволяют сэкономить время. Также важно заметить, что культура информационной безопасности в нашей компании находится на достаточно высоком уровне и каких-то видимых на радарах проблем с правдивостью ответов на вопросы анкеты нет.
Следующий этап: форма заполнена и попадает в виде тикета в багтрекер. Но туда больше не приходит менеджер ИБ! Его место занял наш вежливый робот, которого мы назвали C-3PO.
Для начала C-3PO нормализует и валидирует содержимое тикета (указали ли всю необходимую информацию?). Затем на основе ответов в опроснике он создает задачи для соответствующего сервиса, например инициировать внедрение Molly (наш сканер безопасности веб-приложений, про который мы рассказывали на ZeroNights 2015 — PDF), а также запускает наши инструменты анализа защищенности: сканеры и анализаторы кода. Завершив свою работу, они вернутся в наш тикет, но уже с результатами. Запуск инструментов при обработке заявки на аудит позволяет получить самые свежие данные от них. Основной же робот переходит к ответственной фазе работы, а именно прогнозированию рисков соответствующего запуска с точки зрения безопасности. Прямо сейчас он использует для этого следующие факторы:
- статус внедрения наших контролей в сервисе;
- какие были последние результаты использования наших инструментов, много ли было обнаружено проблем безопасности и какого рода;
- когда был последний аудит безопасности и были ли в его рамках обнаружены проблемы безопасности;
- общая «карма» сервиса, которая у нас накапливается на специальном сервисе под названием «Ампельманн»;
- собственно ответы на вопросы в форме — например, есть ли в запуске какая-либо критичная с точки зрения ИБ функциональность.
Таким образом, при оценке рисков мы учитываем как историю безопасности сервиса, так и особенности конкретного запуска.
Под конец робот назначает задачу на специалиста группы продуктовой безопасности, который и будет отвечать за дальнейшие действия. При этом учитывается его текущая доступность (в отпуске он или нет) и набор компетенций. Вот что мы получили в итоге всех оптимизаций и автоматизаций:
- на вход поступает более тщательно подготовленная задача;
- предварительно оцениваются риски;
- результаты сканирования на уязвимости всегда свежие;
- менеджеры и разработчики получают рекомендации одновременно с заполнением формы;
- у нас есть еще одна возможность контроля;
- все вместе ускорило процесс.
Все изложенное можно обобщить до одного совета: старайтесь максимально автоматизировать поддающиеся этому процессы, и вы сможете освободить больше времени на более комплексные проекты. Более ранний контроль в рамках цикла разработки — не исключение!
