Открыть Электронные книги
Категории
Открыть Аудиокниги
Категории
Открыть Журналы
Категории
Открыть Документы
Категории
ru
Постановка задачи
Для определения решения, подходящего именно вам, мы рекомендуем рассмотреть
классическую триаду:
Ответы на эти вопросы помогут определиться с собственной картиной мира и понять, что
для вас означает безопасная разработка и DevSecOps, ведь универсального ответа
попросту не существует.
Процессы
Одна из возможных проблем, с которой сталкивается ИБ при погружении в мир
безопасной разработки, заключается в том, что она «слишком справа», ближе к
эксплуатации. Что это значит? Представим жизненный цикл разработки ПО в виде прямой
линии (процесса) — от сбора требований до эксплуатации (см. рис 1).
Таблица. Данные отчета NIST «The Economic Impacts of Inadequate Infrastructure for
Software Testing»
Чем раньше обнаружен дефект, тем меньше стоимость его устранения. То же относится к
уязвимостям в исходном коде и нарушениям требований в области ИБ — их можно
приравнять к дефектам кода.
Для решения этой проблемы используется подход Shift Left: безопасность начинают
привлекать к разработке ПО начиная со стадии проектирования. При этом ИБ
подключается не просто как «контролер», а как активный участник рабочей группы,
который вносит свой вклад в проектирование приложения или сбор функциональных
требований. Это позволяет, хотя и не в полной мере, реализовать концепт Security By
Design.
Наш опыт говорит о схожей ситуации: были случаи, когда команды разработки просили
дать им удобный и надежный инструмент для сканирования кода на наличие уязвимостей.
Ведь безопасность постепенно становится синонимом качества, особенно в условиях
рынка повышенной конкуренции, где любой фактор может оказаться тем самым
преимуществом, которое позволит именно этой компании обогнать конкурентов.
В итоге мы должны получить ситуацию, диаметрально противоположную той, что
отражена в эпиграфе. Ведь множественные ограничения обусловлены, как правило,
недостаточным пониманием, а его невозможно сформировать без постоянного
взаимодействия сторон и их взаимного обучения.
Люди
Формирование правильной процессной карты ИБ, необходимой для обеспечения
безопасности разработки, поможет ответить на вопрос «Что надо делать?». Ну а
следующий вопрос, на который желательно получить ответ, — «Кто будет это делать?».
Выше мы описали ряд трудностей, с которыми можно столкнуться в поисках ответа.
Приведем наиболее актуальные из них.
«Приоткрывать дверь в мир ИБ» нужно не только для Security Champions. Необходима и
обратная связь — погружение ИБ-специалистов в мир разработки. В какой-то степени эту
задачу возьмет на себя Security Champion, но ограничиваться этим не следует. Например,
можно приглашать ИБ-специалистов на обсуждение функциональной архитектуры или
планирование спринтов, что позволит устранить принцип «остаточности» при решении
вопросов ИБ (может быть, не в полной степени, но начало будет положено!).
Разработка ПО
Сборка приложения
SCA. Исходный код проверен на наличие уязвимостей, началось время сборки. На этом
этапе могут помочь решения класса Software Composition Analysis (SCA). SCA позволяют
определить полный перечень компонент open source, используемых при разработке
приложения (например, frameworks, plugin, библиотеки).
Тестирование и развертывание ПО
Кроме того, стоит добавить, что DAST может быть интегрирован в CI/CD-pipeline для
автоматического запуска сканирования.
Эксплуатация приложения
WAF. Web Application Firewall — межсетевой экран прикладного уровня, основной
задачей которого является защита приложений, доступных online. Сперва может
показаться, что это очень «ограниченное» решение, направленное на защиту одного
класса приложений. Однако практически каждый слышал о переходе в digital, одним из
аспектов которого является предоставление сервисов клиентам по всем возможным
каналам в любое время, в том числе через веб.
Особое внимание следует уделить ETCD (базе данных, в которой хранится конфигурация
кластера).
API-токены;
SSH-ключи;
технологические учетные записи;
данные аутентификации облачных сервисов;
509-сертификаты и другие чувствительные данные (например, пароли).
Все вместе это можно назвать одним словом — секрет. Если их немного, управление
можно осуществлять вручную. Ситуация меняется, когда число таких сервисов превышает
десяток. При этом в отношении секретов требования в области ИБ могут быть
различными. Самый просто пример: пароли пользователей и пароли технологических
учетных записей. Именно для этих целей применяются решения класса Secret Management
— централизованные хранилища, предназначенные для безопасного создания, управления
(доступ и распределение) и хранения различных секретов.
Так на что же следует обращать внимание при выборе инструментария для автоматизации
процесса безопасной разработки? Согласно лучшим практикам:
Что это значит? Допустим, наш контур состоит из статического анализатора исходного
кода (Static Application Security Testing), задокументированного процесса управления
уязвимостями (отвечает на вопросы, кто запускает сканирование, у кого есть доступ к
результатам, кто должен устранить уязвимости, что делать, если уязвимость не может
быть устранена, и т.д.) и перечня ИБ-сотрудников, которые отвечают за
администрирование SAST и процесс управления уязвимостями.
Что включать в этот контур на первых этапах? Увы, универсального ответа не существует.
В каждой ситуации нужен индивидуальный подход. Решение зависит от множества
аспектов — начиная от организационной структуры компании, применяемых методов
разработки ПО, используемых технологий и заканчивая ограничениями, к которым можно
отнести и конкретную цифру выделенного бюджета, и требования регуляторных органов,
и наличие/отсутствие поставщиков решений на российском рынке ИБ.
Надеемся, что статья помогла вам сформировать представление о том, что такое
безопасная разработка, и вы сможете найти подход к ее созданию и реализации на
практике. Главное — не браться за все и сразу. Нужно идти постепенно и выбирать то, что
необходимо именно вам и именно сейчас по трем направлениям: процессы, люди и
технологии.