На стадии проектирования. Безопасность в производственном процессе ИT-продуктов

На стадии проектирования. Безопасность в производственном процессе ИT-продуктов

В настоящее время всё больше компаний обращают внимание не только на защиту собственной ИT-инфраструктуры, рабочих и серверных станций или Wi-Fi, но и на безопасность продуктов, процессов и клиентских путей, заложенных в них.

В первую очередь это связано с тем, что защита только на уровне инфраструктуры не позволяет автоматически сделать сервисы безопасными. Даже если были применены все современные средства защиты инфраструктуры, продукт может оказаться неработоспособным либо не соответствовать тому, чего ожидают от него клиенты. 

Безопасность цифрового сервиса или продукта — это его неотъемлемое свойство, которое невозможно привнести после создания. Представьте, что команда продукта через 1,5 года производства приносит куриное яйцо в качестве шара для игры в боулинг? И именно его нужно сделать безопасным. Очевидно, что данная задача невыполнима. Либо информационная безопасность «зальёт в бетон» данный снаряд и он станет квадратным куском камня, либо же клиенты столкнутся с проблемами при его использовании. 

Практика создания безопасных продуктов пропагандируется многими публичными компаниями и связана с привлечением специалиста ИБ не только на этапе постановки продукта в промышленную среду, но и на самых ранних этапах его формирования. Совокупность данных практик объединяют в подход Secure by Design, который предполагает формирование в компании производственного процесса с интегрированной безопасностью. Здесь важно отметить, что это именно процесс интеграции (или слияния) практик создания продуктов и ИБ, а не два отдельных процесса, живущих независимо друг от друга. 

В каждой компании из-за различий в специфике бизнеса и ИT-систем принят свой собственный производственный процесс. Различные этапы, контроли и модель, по которой принято там создавать продукты, приводит к необходимости адаптировать безопасность под те или иные особенности (рис. 1). И тем не менее можно выделить общий для всех принцип организации этого процесса. 

Рассмотрим эти этапы последовательно.

Рисунок 1. Каркас производственного процесса

PV (PRODUCT VISION)

Product Vision — это первый шаг к созданию продукта. На данном этапе формируется область применения, ключевая ценность, образ клиента, основные клиентские пути и производится оценка финансовых показателей. Также к данному этапу возвращаются при объёмных изменениях в существующем продукте, когда добавляемая функциональность привносит новые важные аспекты. Как показывает практика, этап PV — это наиболее дешёвый для компании способ принять решение об инвестициях в новое направление, так как именно в этот момент можно получить отзывы от профильных подразделений о продукте. 

Информационная безопасность в рамках PV становится одним из ключевых контрагентов, позволяя произвести экспресс-оценку в части рисков, которые продукт несёт для компании и сам для себя. Здесь исследуются как регуляторные ограничения (например, PCIDSS, обработка персональных данных и проч.), так и собственные риски в рамках модели угроз. 

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

КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ

Концептуальное проектирование решения — это один из ключевых этапов в создании продукта и его модификации. На данном этапе будущий продукт или изменения в нём обретают первые материализованные в артефактах очертания, доступные для анализа не только инженерам ИБ, но и другим смежным подразделениям (например, эксплуатации). 

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

Данный этап (как и PV) используется не часто и в основном связан с созданием продукта или глобальными изменениями в его составе — элементов в ландшафте или потоков данных. Но значение концептуального проектирования крайне велико, ведь именно здесь закладываются ключевые принципы и участники реализации продукта. В крупном ИT-ландшафте присутствует множество централизованных сервисов: IDM- и MDM-системы, подсистемы транспорта, аналитические хранилища данных, системы нотификации и другие. В задачи корпоративного архитектора, формирующего концепт решения, входит не только задача по декомпозиции PV и раскладки его на функциональные блоки с потоками данных, но и оптимизация ИT-ландшафта компании в части переиспользования общих компонент. 

Формат описания концептуальной архитектуры может быть разработан компанией самостоятельно, с учётом собственных потребностей и индивидуальных элементов. Главная цель здесь — договориться со всеми заинтересованными участниками о будущих изменениях. Пример концептуальной архитектуры приведён на рис. 2.

Рисунок 2. Пример концептуальной архитектуры

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

Реализация крупного продукта может затрагивать десятки автоматизированных систем, часть из которых развивается самостоятельно, часть разрабатывают другие команды, а оставшиеся могут быть отданы подрядчику. И важно отметить, что последующие этапы создания продукта — разработка технического задания (ТЗ) или фичей при Agile-подходе — связаны с изменениями в каждой отдельной системе или сервисе. Таким образом, после фиксации концептуальной архитектуры множество команд забирают свою часть работ по созданию аналитики решения и разработке исходного кода. Анализ небольшой части изменений, происходящих в каком-либо отдельном модуле или автоматизированной системе, не позволяет увидеть картину целиком, и инженеру ИБ придётся собирать информацию с разрозненных команд, что скажется на сроках разработки. 

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

Например, при организации магазина приложений RuStore была сформирована практика обсуждения ключевых изменений в ИT-ландшафте на архитектурном комитете, активным участником которого является ИБ. 

ДЕТАЛЬНОЕ ПРОЕКТИРОВАНИЕ

Следующий этап в процессе производства — это детальное проектирование. В отличие от предыдущего, формирующего основную декомпозицию бизнес-процессов продукта по различным элементам ИT-ландшафта, он описывает изменения, которые необходимо сделать в конкретном модуле или автоматизированной системе. Этап детального проектирования, в отличие от концептуального, не оперирует общей верхнеуровневой схемой и потоками данных, а описывает контракты взаимодействия с конкретными полями, алгоритмами обработки данных, ошибок и пограничных случаев. В результате формируются ТЗ на разработку, описанная фича или задача в task-трекере, которые применяются при использовании Agile-подходов. 

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

В VK подключение эксперта безопасности к артефактам детальной аналитики зависит от производственного процесса и организованно путём его подключения к системе ведения задач на разработку. Эксперт ИБ самостоятельно выявляет задачи, ведёт диалог с продуктовой командой и дополняет их требованиями. 

РАЗРАБОТКА

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

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

Объём исходного кода, используемых зависимостей и вариантов поставки непрерывно растёт. Большинство цифровых продуктов активно развивается, улучшая клиентский опыт благодаря удобному интерфейсу и богатой функциональности. Анализ такого объёма вручную не только существенно увеличивает срок реализации продукта, но и требует вовлечения огромного количества специалистов с высокой квалификацией. Поэтому для анализа небезопасных конструкций в исходном коде распространены инструменты статического и динамического анализа исходного кода (SAST и DAST), а для используемых в приложениях зависимостях — анализаторы OSA и SCA. Важным является не только поиск подходящих вашему технологическому стеку инструментов, но и реализация процессов внутри компании, которые предполагают своевременное проведение сканирования, обработку результатов и последующее исправление обнаруженных уязвимостей. 

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

ТЕСТИРОВАНИЕ

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

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

Финальным результатом тестирования станет заключение от ИБ о критичности выявленных уязвимостей. Крайне важно здесь зафиксировать найденные уязвимости, оценить степень их влияния на продукт и донести результаты тестирования до команды разработки. Стоит отметить также необходимость организации в компании процедур управления рисками, так как не все замечания от ИБ бизнес-подразделение может исправить или митигировать без ущерба основной деятельности компании. 

Этап тестирования безопасности VK Мессенджера начинается с постановки задачи в Jira командой разработки на эксперта ИБ. В задаче указывается тестовое окружение, на котором развёрнут новый релиз, а также даются ссылки на документацию с описанием изменений. В зависимости от объёма тестирование обычно занимает от 3 до 7 дней, в ходе которого идентифицируются как типичные ошибки, так и возможные проблемы с бизнес-логикой. По результатам тестирования все обнаруженные дефекты по безопасности также оформляются в виде задач Jira, которые связываются с исходной задачей. При этом, если была обнаружена уязвимость достаточно высокой критичности, релиз может быть отложен до её устранения и верификации фикса. 

***

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