2024/03/15 15:27:49

Интервью TAdviser: Вячеслав Касимов, ИБ-директор МКБ — о применении DevSecOps при разработке веб-приложений

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

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

С чего начинался DevSecOps? В чем заключается проверка безопасности веб-приложений в рамках DevSecOps?

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

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

Какие инструменты используются для проверки соблюдения требований по информационной безопасности в веб-приложениях?

Вячеслав Касимов: Основными инструментами являются статические (SAST) и динамические (DAST) анализаторы исходных кодов. Они используются на этапе тестирования разрабатываемых приложений, и позволяют обнаружить наиболее популярные ошибки, допускаемые разработчиками при создании приложений. Кроме того, если мы публикуем продукты для массового использования, такие как платежные сервисы или просто интернет-приложения, то подключаются еще и тестировщики безопасности из нашего Red team.

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

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

Как внедрение процедур безопасности влияет на процесс разработки веб-приложений?

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

Как учитывается в DevSecOps недоступность некоторых иностранных сервисов?

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

Насколько работа мобильного приложения влияет на безопасность банковской системы?

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

По каким причинам было принято решение внедрять DevSecOps?

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

Как вы приучаете разработчиков писать безопасный код? Какие инструменты и методы вы уже используете в своей системе безопасной разработки?

Вячеслав Касимов: Обучение созданию безопасного кода, постоянная проверка наличия уязвимостей в коде, внедрение практики security champions. Первичная задача – объяснить разработчикам максимально доступно, почему для них важно писать безопасный код. Далее требуется донести, как это можно эффективно сделать, а уже потом можно внедрять методы контроля и оценки эффективности каждого разработчика. Всё это мы успешно делаем.

Как в приложениях приходится учитывать безопасность устройств, находящихся в публичном доступе?

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

Как защищается разработка ПО от постороннего вмешательства извне?

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

На какие лучшие практики и стандарты вы опираетесь в своей работе?

Вячеслав Касимов: Мы опираемся на привычный для финансовой индустрии риск-ориентированный подход, для которого у нас применяются лучшие мировые практики, например, Cyber Security Framework NIST. Естественно, для работы с карточными продуктами мы реализуем требования стандарта безопасности данных индустрии платежных карт (Payment Card Industry Data Security Standard – PCI DSS). ЦБ РФ также активно занимается разработкой стандартов для обеспечения информационной безопасности в финансовой сфере, поэтому мы используем и разработанные Центробанком специально для банков ГОСТы.