Банковское обозрение

Автотестирование бизнес-функционала приложений на соответствие требованиям кибербезопасности: миф или реальность?

Еще несколько лет назад бизнес выступал драйвером совершенствования IT. Однако сегодня ситуация изменилась: IT-специалисты предлагают бизнесу пути модернизации продуктов и систем.

В первую очередь изменения затронули практики разработки программного обеспечения. Не так давно процедуры разработки были стабильны и документированы, а сам процесс проходил последовательно в соответствии с концепцией водопадной (каскадной) модели разработки (рис. 1). 

Рисунок 1. Каскадная модель разработки

Такая модель разработки надежна и понятна: бизнес-подразделения придумывают идею, оформляют бизнес-требования, согласуют их со всеми заинтересованными сторонами. После этого пишется и снова согласовывается ТЗ, при этом все участники процесса вносят свои требования, включая требования кибербезопасности. Далее следует разработка. И вот, не прошло и года, как появился новый продукт. Что же не так? Современная реальность и уровень конкуренции таковы, что в момент появления продукта он уже никому не нужен и сильно устаревает. 

Как ы подошли к идее автотестирования кибербезопасности

Помимо бизнес-требований, эксплуатационных требований и требований кибербезопасности процесс разработки ПО предполагает обеспечение скорости вывода продукта на рынок. Именно для кардинального сокращения time-to-market Сбербанк принял решение о переходе на практики Agile при разработке продуктов.  

Что изменилось для специалистов по кибербезопасности Сбербанка с внедрением Agile? Все команды разработчиков переключились на параллельное выполнение задач, и стало очевидно, что эксперт по кибербезопасности не успевает участвовать во всех процессах. Чтобы решить эту проблему, необходимо было внимательно проанализировать жизненный цикл разработки и выбрать оптимальную точку приложения усилий.

В жизненном цикле разработки обычно выделяют следующие основные этапы: 

• анализ и проектирование;
• реализация; 
• тестирование;
• внедрение;
• эволюция.

Схематично данные этапы можно представить в виде круговой диаграммы (рис. 2).

Рисунок 2. Стадии жизненного цикла разработки

На стадии тестирования специалисты по кибербезопасности обычно сосредоточены на решении следующих задач:

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

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

Тогда и возникли первые идеи, связанные с автоматизацией труда эксперта по кибербезопасности с помощью методологии DevOps (рис. 3), которая позволяет выводить доработки в промышленную эксплуатацию в максимально сжатые сроки, соблюдая высокий уровень кибербезопасности. Применение в Банке культуры и практик DevOps решало задачу автоматизации доставки приложения от точки его разработки до промышленной среды. 

Рисунок 3. Методология DevOps

При реализации конвейера (pipeline) DevOps появляется возможность естественным образом встроить в процесс разработки практически любые практики автоматизированного тестирования, такие как:

• SAST ― Static Application Security Testing, статическое тестирование защищенности приложений. Анализ кода или его части на наличие уязвимостей без реального запуска исследуемого приложения;
• DAST ― Dynamic Application Security Testing, динамическое тестирование развернутого приложения. Анализ, который подразумевает наличие развернутой среды выполнения приложения и ее прогон на наиболее интересных с точки зрения анализа наборах входных данных;
• IAST ― Interactive Application Security Testing, интерактивный анализ защищенности приложений. Отличительной особенностью этого подхода является то, что он комбинирует SAST, который используется для формирования наборов входных данных и шаблонов ожидаемых результатов, и DAST, который выполняет тестирование системы на этих наборах;
• MAST ― Mobile Application Security Testing, позволяет быстро реализовывать анализ клиентского кода, кода на стороне сервера и сторонних библиотек, систематически находить и исправлять уязвимости безопасности в мобильных приложениях без необходимости использования исходного кода;
• OSS ― Open Source Software, выявление общеизвестных уязвимостей информационной безопасности CVE (Common Vulnerabilities andExposures) в свободно распространяемых библиотеках.

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

Сегодня к разработчикам программного обеспечения предъявляются требования реализовать проект ― от возникновения идеи до выпуска готового продукта ― в максимально сжатые сроки. Единственный способ снизить непомерную нагрузку на эксперта по кибербезопасности ― хотя бы частично автоматизировать его труд. Так появилась гипотеза, что часть экспертных проверок можно заменить автоматизированными тестами кибербезопасности.

Поиски оптимального пути

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

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

Анализ возможности автоматизации ручных экспертных проверок показал интересные результаты и выявил ряд сложностей:

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

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

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

После анализа задачи были сформулированы следующие цели работ:

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

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

Затраты на реализацию 12 автотестов оказались крайне высоки, и даже если тесты компенсируют треть работы эксперта, то стоимость их реализации будет очень большой

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

Требования кибербезопасности были проанализированы и разделены на следующие категории:

• требования, проверяемые инструментальным сканированием;
• требования, проверяемые сценариями;
• инфраструктурные требования;
• требования, проверяемые в ручном режиме.

Для проведения первого этапа автотестов было отобрано около 30 кейсов-проверок. Была поставлена важная задача: сделать данные автотесты универсальными для двух целевых банковских платформ ― фронтальной и бэк. Внимание было сосредоточено на том, чтобы понять алгоритмы проверки и создать усредненный алгоритм. Большинство проверок, выполняемых экспертами, связаны с проверками действий в пользовательском интерфейсе, например проверка избыточного функционала в рамках выданной роли, проверка избыточности данных либо области их видимости, проверка функций аутентификации и авторизации, а также проверка фиксации событий аудита выполняемых действий и процессов. Именно поэтому реализуемые тесты были направлены на анализ действий в пользовательском интерфейсе. Однако при изменении пользовательского интерфейса оказалось, что пропадает универсальность проверки и это влечет необходимость оптимизировать автотест под измененный интерфейс. Проведенный ранее анализ подтвердился: изменчивость интерфейса не позволяет достичь универсальности создаваемых тестов, и под каждый интерфейс должны создаваться свои тесты. Тем не менее в результате данного этапа удалось реализовать 12 полностью универсальных автотестов из отобранных 30 кейсов-проверок.

По результатам проведенного «пилота» были сделаны следующие выводы:

• около 30% базовых требований кибербезопасности могут быть реализованы в виде автотестов и при этом могут быть универсальными;
• около 40% базовых требований кибербезопасности могут быть реализованы в индивидуальном виде для каждой из бизнес-подсистем, реализуемых на платформе;
• около 30% базовых требований кибербезопасности нельзя реализовать в виде автотестов. 

Итоговый вывод был не очень оптимистичным: затраты на реализацию 12 автотестов оказались крайне высоки, и даже если тесты компенсируют треть работы эксперта, то стоимость их реализации будет очень большой. Получалось, что реализация автотестов для массивных и монолитных автоматизированных систем ― это слишком трудоемкое и затратное мероприятие. Ручной труд эксперта был более эффективным и менее затратным. 

Хотя возможность реализации автотестов была доказана, выбранный способ реализации не совсем подходил для достижения цели. Так в чем же проблема и что можно улучшить?

Новый этап трансформации

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

При изучении международного опыта, связанного с микросервисной архитектурой и реализацией в ней практик DevOps, мы сделали важные выводы.

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

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

После декомпозиции функционала в сервисы и описания сценариев мы передали задачи по реализации автотестов кибербезопасности командам разработчиков. Разработчики были максимально вовлечены в процесс создания тестов кибербезопасности и зачастую сами предлагали оптимальные решения по реализации предложенных сценариев тестирования. 

Чего нам удалось добиться на втором этапе? Совместными усилиями мы реализовали несколько десятков автотестов для проверки требований кибербезопасности, представленных ниже.

Требования по реализации парольной политики:

• сложность пароля;
• неиспользование в качестве пароля имени учетной записи;
• запрос старого пароля при его смене;
• возможность самостоятельной смены пароля в любое время.

Требования безопасности к интерфейсам:

• наличие директив, запрещающих кеширование данных (API и UI);
• выставление у параметров cookie атрибутов HTTPOnly и secure;
• реализация максимальной длины, сложности и случайности значений сессионных идентификаторов;
• запрет на хранение на HTML-страницах критичной информации, например номера банковских карт, паролей, путей к конфигурационным файлам;
• запрет на наличие в сессионном идентификаторе и cookie-файлах в открытом виде логина, пароля, фамилии и номера банковской карты.

Требования к маскированию критичной информации:

• проверка правил маскирования номера банковской карты;
• проверка правил маскирования серии и номера паспорта;
• проверка правил маскирования номера телефона.

Требования к фиксации событий в журналах аудита: 

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

Стоит отметить, что нам удалось сократить срок реализации тестов в несколько раз по сравнению с первым этапом тестирования. Кроме того, команды разработчиков не стали останавливаться на достигнутых результатах и включили создание автотестов кибербезопасности в свою основную деятельность.  

Результаты

Большого объема автоматизированных проверок достичь пока не удалось. Главная задача, которая стояла перед нами, ― проверить выдвинутую гипотезу о потенциальной возможности автотестирования кибербезопасности. Поэтому самый важный результат достигнут: подтверждена возможность и экономическая целесообразность автотестирования.

Переход в микросервисную архитектуру как нельзя лучше помогает решить задачу универсальности, которая необходима для построения автотестирования требований кибербезопасности

По аналогии с прочими техниками тестирования родилось название для данного типа автоматизированного тестирования ― BAST (Businessprocess Application Security Testing). Его цель ― максимальная автоматизация труда эксперта кибербезопасности при проведении приемки бизнес-функционала и поиске нетипового поведения в нем. 

Реализация автоматизированных проверок значительно повышает уровень кибербезопасности при передаче разработок в эксплуатацию и одновременно помогает сократить time-to-market.

Выгоды для подразделения кибербезопасности заключаются в следующем:

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

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

Наша конечная цель ― автоматизированная приемка продукта и проверка реализации требований кибербезопасности. Полученные результаты показывают, что мы движемся в правильном направлении.