С чего начать внедрять безопасную разработку приложений

Алексей Даньков

руководитель отдела информационной безопасности Cross Technologies

Развитие технологий разработки в сторону микросервисной инфраструктуры, построение CI/CD процессов, ускорение процесса разработки размывает границы классического подхода информационной безопасности, когда основной акцент делается на защиту периметра и этап проверки кода. На замену ему приходят новые методики и практики такие как: SecSDLC и DevSecOps. Их основная задача создать условия для разработки программного продукта, которые обеспечили бы минимизацию рисков информационной безопасности и прозрачное (прогнозируемое) развитие продукта.

Вообще сам подход SDLC – не новый, ему уже более 12 лет и он успешно применяется при разработке продуктов информационных гигантов: Microsoft, Cisco и т.д. Каждая компания старается создать свою концепцию и набор практик, которые помогли бы определить общие правила построения процесса разработки приложений и связанных с ним контролей. А также обеспечить определенный уровень доверия к результатам разработки команд, которые использую на практике зарекомендовавшие себя подходы. В свою очередь, международные институты ISACA, OWASP, ISO, ГОСТ и т.д. принимают активное участие в создании и систематизации подходов, описании лучших практик, формировании требований, проверяемых при аудите.

Из изложенного выше видно, что работа в направлении SDLC ведется и достаточно успешно, есть материалы и стандарты, есть практика внедрения и накоплен опыт использования, однако изучив все это актуальным остается вопрос: «Как адаптировать эти практики к реальности и как не потратить на их внедрение много сил и средств?»

Для ответа на этот вопрос предлагаю рассмотреть некоторые примеры сложных ситуаций, с которыми сталкиваются команды разработки при внедрении у себя практик SecSDLC:

1. Отсутствие у руководства компании риск-ориентированного мышления;
2. Неустоявшиеся практики проектного управления (или использование различных подходов проектного управления на разных проектах, что не позволяет обеспечить оптимизацию процессов разработки. Например, большое количество команд разработки, пересечение команд, отсутствие контролей или наоборот для разных команд свое);
3. Низкая квалификация команд разработки в вопросах информационной безопасности;
4. Отсутствие накопленного систематизированного опыта в вопросах информационной безопасности, что приводит к решению повторяющихся кейсов с нуля;
5. Отсутствие моделирования угроз и управления рисками информационной безопасности;
6. Безопасность не успевает за развитием и внедрением новых технологий разработки;
7. Старые подходы мешают создавать синергетические схемы работы ИТ и ИБ.

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

К решению задачи построения SecSDLC предлагаем подходить комплексно и выделять следующие основные ветки внедрения практики безопасной разработки:

• создание процессов безопасной разработки – это внедрение цикла SDLC с включенными контролями ИБ на каждом этапе разработки (см. рис.1) с учетом специфики работы команд разработки и накопленного ими опыта (что может изменять базовый подход);
• создание безопасной среды разработки – внедрение на уровне инфраструктуры разработки практических мер защиты информации, базирующихся на актуальных угрозах безопасности и оценках возможного ущерба (рисков).

Классика или новация

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

Рисунок 1 – Создание безопасного цикла разработки приложений

В большинстве случаев получается так, что необходимо использовать смешанный подход (combi) как в рамках одной команды разработки, так и при выстраивании взаимодействия между командами разработки.

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

Тема экспериментов в области управления проектами разработки приложений раскрыта в художественной книге Тома Демарко «Deadline».

Начинаем с нуля

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

Рисунок 2 – Безопасный цикл разработки

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

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

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

• Модель угроз безопасности. Должна учитывать все актуальные угрозы и риски информационной безопасности, которые по разным причинам могут влиять на безопасность создаваемого продукта. Документ должен учитывать особенности инфраструктуры, процесса разработки (например, привлечение внешних организаций), используемые технологии.
• Оценка и управление рисками. Необходимо понять какие риски являются для компании и ее руководства важными, а какими можно пренебречь или делегировать. Исходя из принятого решения, актуализируется модель угроз и встраиваются контроли ИБ в процесс разработки ПО.
• Формирование базовых требований ИБ к архитектуре создаваемого продукта и к процессу разработки в целом. Требования должны относиться к специфике безопасного использования технологий, patch-management, разделение сред, мониторинг инцидентов ИБ, обезличивание данных в тестовых контурах и контуре разработки и пр.
• Разработка соглашения о кодировании. Документ, определяющий основные правила безопасности и требования к чистоте разрабатываемого программного кода. Обычно в группе разработки есть такие документы их достаточно дополнить в части безопасности.

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

Последнее несколько лет активно набирает обороты направления DevOps – это специалисты участвующие в процессе разработки в качестве инфраструктурных инженеров, своего рода микс разработчика и системного администратора. А с появлением микросервисных технологий и процессов CI/CD в разработке влияние DevOps на разработку становится колоссальным. Поэтому считаем, что не лишним будет обучить DevOps инженера азам информационной безопасности или взять на работу специалиста, который имеет опыт DevSecOps. Это важный момент, т.к. распространена ситуация, когда DevOps инженер — это выходец из команды разработки или бывший системный администратор, как следствие, субъективно, пренебрегающих вопросами информационной безопасности в угоду оперативности и удобству. Безопасники, ставшие DevOps инженерами в моей практике пока не встречались.

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

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

• статические анализаторы кода – применяются в отношении не компилируемого кода на этапе сборки кода или на промежуточных этапах разработки непосредственно из репозитория;
• динамический анализ кода – применяется в отношении уже готового кода, в основном web;
• интегрированные анализаторы кода – позволяющие реализовывать сканирование статического и динамического кода, интегрируются в CI;
• Left Shift анализаторы, позволяющие проверять код непосредственно в процессе его разработки;
• проверка open source компонентов – решения интегрируются с большим количеством внешних репозиториев, могут детектировать открытый код и уязвимости в нем;
• BugBounty – практика привлечения экспертного сообщества к поиску уязвимостей (для очень зрелых компаний);
• ручной анализ кода и pentest.

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

Защищенная среда разработки

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

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

1. Сегментирование сети и управление сетевыми проходами: сегмент разработки, тестирования, продуктивный сегмент, сегмент DMZ и тд.;
2. Управление ролями и правами доступа, особое внимание необходимо уделять вопросу контроля действий привилегированных пользователей (администраторов систем);
3. Управление и хранение парольной информации;
4. Защищенный удаленный доступ;
5. Управление уязвимостями инфраструктуры и патч-менеджмент;
6. Мониторинг и аудит ИТ и ИБ;
7. Обезличивание чувствительной информации в БД тестовых сегментов сети.

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

Заключение

В заключении хочется дать короткий подытоживающий ответ на поставленный в этой статье вопрос: «С чего начать внедрять безопасную разработку приложений?» — в первую очередь:

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

Все остальное может выстроиться со временем и путем приобретения необходимого опыта. Либо, вам могут помочь те, кто уже прошел этот путь. Удачи!