Статья

Что скрывается за безопасной разработкой софта

Софт
мобильная версия
, Текст: Мария Сысойкина

Методология безопасной разработки ПО (SSDLC) – относительно новое явление на российском рынке, несмотря на то, что появилась она еще 15 лет назад. Процесс внедрения SSDLC – довольно хлопотное и затратное занятие, успешных кейсов в России пока не так много. Однако результат внедрения оправдывает все ожидания и инвестиции. О том, что представляет собой методология, почему проверка кода на уязвимости требует серьезных мощностей и длительного времени, и, разумеется, о том, как внедрять подход в организации, рассказывает Даниил Чернов, руководитель направления Solar appScreener компании «Ростелеком-Solar».

CNews: Что такое безопасный процесс разработки? Насколько эта методология распространена в российских компаниях?

Даниил Чернов: Методология безопасного процесса разработки была придумана Microsoft еще в 2004 году. По сути, это автоматизация проверок на безопасность, встроенная в сам процесс разработки. Eсли SDLC (жизненный цикл разработки ПО) регламентирует обычный процесс разработки, то Secure SDLC (SSDLC) отвечает за безопасный процесс разработки софта. Заслуга Microsoft в том, что специалисты этой компании описали процедуру встраивания проверок на безопасность в цикл разработки именно с точки зрения бизнес-процессов и автоматизации.

На российском рынке проникновение этого подхода пока невысоко. Лишь единицы предприятий уже внедрили у себя безопасный процесс разработки. Сложно выделить конкретные отрасли, где эта методология была бы наиболее востребована. В целом это те компании, где ведется масштабная внешняя (заказная) и внутренняя разработка. Безусловно, если в организации насчитывается несколько десятков разработчиков, то пора задумываться о том, чтобы внедрять автоматизацию проверки софта на уязвимости. Я думаю, через 3–5 лет SSDLC уже будет массовым трендом в России.

CNews: А если говорить об интеграторах или ИБ-компаниях – есть на российском рынке игроки, которые предлагают такой подход своим клиентам?

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

dsc77751000x665.jpg
Даниил Чернов: Если в организации насчитывается несколько десятков разработчиков, то пора задумываться о том, чтобы внедрять автоматизацию проверки софта на уязвимости

CNews: Что представляет собой процесс внедрения этой методологии? На какие этапы он делится? Какие отделы компании будут задействованы в нем?

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

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

CNews: Что делать с ПО, которое уже разработано и периодически обновляется? Для него нужно внедрять процессы SSDLC?

Даниил Чернов: Этот процесс необходим и для того ПО, которое используется в компании, и для того, которое только создается. Внедрение стартует с выбора самых критичных систем, которые уже работают на предприятии. На первом этапе проверяется весь код этих систем. Это колоссальные объемы кода, поэтому и количество выявленных уязвимостей обычно очень велико. Их надо приоритизировать и принять решение, что с ними делать дальше. Каждая система рано или поздно обновляется, поэтому проверка на безопасность актуальна для всего ПО, используемого в компании. В первую очередь, конечно, нужно выбрать приложения, которые обрабатывают наиболее критичные данные внутри компании – бухгалтерское ПО, CRM, либо те системы, которые имеют выход за периметр безопасности компании – сайты, мобильные приложения, личные кабинеты. Важно провести инвентаризацию, выявить наиболее критичные и начать с них. А потом уже постепенно расширять границы SSDLC на остальные системы.

CNews: Что еще важно учесть на старте проекта? Есть какие-то особенные сложности?

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

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

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

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

Если не проработать эти сложности еще на старте, то впоследствии они могут блокировать процесс безопасной разработки.

CNews: Что делать, если первоначально неверно оценили объем аппаратных ресурсов? Можете привести конкретный пример из практики?

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

Обычно заказчику проекта удается согласовать внутри компании необходимость выделения средств и закупку дополнительного «железа» под проект. Был случай, когда никак не удавалось согласовать увеличение мощностей. Можно было пойти дальше с тем, что имелось в наличии, но тогда потребовалось бы очень много времени. А ждать было невозможно. Мы пообщались с ИТ-специалистами и нашли аппаратное обеспечение внутри компании, некий резерв, который удалось задействовать в проекте.

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

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

CNews: Как быть с тем, что процесс уже запущен, а инфраструктура меняется – появляются новые приложения, новые сервисы?

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

dsc78011000x665.jpg
Даниил Чернов: Внедрение SSDLC, в первую очередь, уходит корнями в практику внедрения бизнес-процессов

CNews: А в вашей практике были такие случаи?

Даниил Чернов: Да, в крупных компаниях это не редкость. В ходе внедрения методологии безопасной разработки хотя бы одно-два изменения в инфраструктуре случается. Это даже прописано в наших внутренних методиках – обязательно данный пункт учитывать и на старте обсуждать с клиентом.

CNews: А если начинается разработка принципиально нового продукта, который не был вообще предусмотрен в инфраструктуре, как его включить в уже внедренный процесс?

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

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

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

Допустим, при подготовке к внедрению SSDLC вы изучили регламенты, имеющиеся в компании. Вполне может выясниться, что для разных систем существуют разные подходы. В одном случае мы можем прописать четкий регламент, по которому разработчик пишет код и сам же его проверяет на уязвимости. А в другом случае может всплыть регламент, в котором описан неформализуемый процесс. Например, разработчик пишет код, и его задача – в кратчайшие сроки отдать этот код тестировщику, чтобы система ушла в продакшн. Таково требование бизнеса, закрепленное документально. Если не обнаружить данный регламент на старте, то в процесс SSDLC включается система, работающая по правилам, которые противоречат всей логике процесса безопасной разработки.

CNews: Если обнаружена уязвимость, как соблюсти баланс между качеством, защищенностью и сроками? Вернуть на доработку или запустить как есть?

Даниил Чернов: Хороший вопрос. Мы рекомендуем в самом начале процесса не накладывать вето на релизы. Если в первое время возвращать программный код на доработку в случае найденных уязвимостей, то будут сорваны все дедлайны разработки, и бизнесу это совершенно не понравится. Поэтому первые 3–6 месяцев, даже если есть уязвимости, не стоит нарушать привычный цикл разработки. Но при этом важно фиксировать, что найденные уязвимости должны быть устранены в определенный срок, и закреплять ответственных исполнителей. Дальше, по прошествии тестового периода уже появится понимание, как можно быстро устранять уязвимости текущими ресурсами. На этом же этапе следует сформировать и некие критерии приемки: в каком случае релиз не будет допущен к запуску в производство, в каком случае – допущен, но с оговорками и с жесткими сроками на устранение найденных уязвимостей.

Также в этом случае очень важно предусмотреть возможность принятия оперативного решения в ручном режиме. Бывает так, что в программе обнаружена уязвимость, бизнес понимает риск, но для него крайне важно вывести продукт на рынок в сжатые сроки. В таком случае необходимо, чтобы найденная уязвимость правильно транслировалась в бизнес-риски и доводилась до людей, принимающих решение. Они могут либо принять этот риск, либо не принять – решение должно быть за ними.

CNews: Есть примеры таких ситуаций, когда важнее было выпустить продукт, а не устранить уязвимость?

Даниил Чернов: Одна из компаний, в которой мы внедряли такой процесс, выводила совершенно новый продукт на рынок. И это надо было сделать быстро, потому что конкуренты в том же сегменте планировали запустить аналогичную систему. Как известно, разработка в настоящее время ведется достаточно быстрыми темпами, и часто в систему интегрируются уже готовые куски стороннего кода, заимствованные из библиотек. Самостоятельно пишется 10–20% кода. В данном случае получилось так, что разработчики включили в архитектуру своего продукта заимствованный из библиотеки код, содержащий старые уязвимости. Когда это выяснилось на этапе анализа готового приложения, разработчики сказали, что быстро устранить проблему не смогут, придется переписывать архитектуру продукта, а это займет несколько месяцев. А запуск продукта должен был состояться через 2–3 недели.

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

CNews: Какие еще форс-мажорные ситуации случаются при внедрении методологии SSDLC?

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

CNews: Что вы посоветуете компаниям, которые пока только рассматривают возможность внедрения SSDLC?

Даниил Чернов: Я рекомендую начать с малого. Как я уже сказал, практика внедрения процессов безопасной разработки – это, прежде всего, внедрение бизнес-процессов. И международные стандарты рекомендуют внедрять бизнес-процессы по частям. Сделали маленький кусочек – расширили область работ. Ни в коем случае не нужно начинать с понедельника новую жизнь – не сработает. Начните с выбора инструмента, который будет удобен команде. Вовлеките в процесс разработчиков и службу ИБ. Посмотрите, прогоните все вручную, без автоматизации и построения процессов. Это уже даст некие осознанные практические знания, а не абстрактные представления о том, что такое проверка кода на безопасность. На следующем шаге оцените, как часто в вашей компании выходят новые версии ПО, что стоит проверять в первую очередь и т.д. Вот здесь я бы рекомендовал задуматься о специалистах. Для того, чтобы внедрять методологию своими силами, нужно иметь в команде квалифицированных людей, которые хотя бы раз имели дело с этим процессом. Если таких людей нет, стоит обратиться к опытным внедренцам. Это сэкономит массу ресурсов, как финансовых, так и временных.