Тема безопасной разработки является одной из наиболее «горячих» на рынках ИТ и ИБ. Участники дискуссии в рамках пленарной сессии на AM Live Plus обсудили то, как реализовать принципы безопасной разработки с минимумом издержек.
- Введение
- Стимулы ко внедрению DevSecOps
- Цена пренебрежения высока
- Пересадить разработчиков на конвейер
- DevSecOps на практике
- Как измерить результаты проекта
- Страхи и реальные проблемы в сфере DevSecOps
- Выводы
Введение
Тема внедрения DevSecOps стала одной из наиболее широко обсуждаемых во многом потому, что разработчики оказываются между двух огней: на них давят регуляторы, но при этом не все из принимающих решения в компаниях осознали важность вопроса, да и с ресурсами много проблем.
Рисунок 1. Участники первого обсуждения
В первой половине встречи приняли участие:
- Дмитрий Шмойлов, руководитель отдела безопасности программного обеспечения, «Лаборатория Касперского»;
- Алексей Антонов, директор по развитию бизнеса безопасной разработки, Positive Technologies;
- Антон Прокофьев, руководитель отдела операционной поддержки, ГК «Солар»;
- Екатерина Гайнуллина, эксперт по информационной безопасности, Security Vision.
Рисунок 2. Участники второго обсуждения
Во второй половине дискуссии участвовали:
- Евгений Тодышев, руководитель направления безопасной разработки, УЦСБ;
- Илья Поляков, руководитель отдела анализа кода, Angara Security;
- Анна Архипова, ведущий менеджер по развитию бизнеса, ITD Group.
Вёл обе части мероприятия генеральный директор «АМ Медиа» Илья Шабанов.
Стимулы ко внедрению DevSecOps
Главным драйвером, по мнению участников дискуссии, стала цифровизация. Во вторую очередь на ситуацию повлияли требования регуляторов и заказчиков.
Директор по развитию бизнеса безопасной разработки Positive Technologies Алексей Антонов
Алексей Антонов:
— Процесс ползучей цифровизации ведёт к тому, что если не ПО пишут, то по крайней мере сайты разрабатывают точно все. Скорее рано, чем поздно люди приходят к выводу, что эти самые сайты или приложения должны быть безопасными. Но и к срокам требования всё жёстче, а традиционные методологии безопасной разработки, существующие много лет, удлиняют сроки выхода продукта. Методы DevSecOps позволяют добиваться коротких сроков разработки при повышении безопасности кода.
Генеральный директор «АМ Медиа» Илья Шабанов
Илья Шабанов:
— Среднее время публикации эксплойта для обнаруженной уязвимости составляет 24 часа. Но это — средний показатель, очень часто времени ещё меньше. На наложенные средства при этом надеяться тоже нельзя. Это стимулирует безопасную разработку.
Начиная с 2022 года, когда темпы разработки в России резко ускорились, многим стало не до безопасности. И тут является ФСТЭК России, которая начинает активно продвигать технологии безопасной разработки, противодействуя этой тенденции.
Руководитель отдела безопасности программного обеспечения «Лаборатории Касперского» Дмитрий Шмойлов
Дмитрий Шмойлов:
— Сложность систем растёт, поэтому всё чаще разработчики используют сторонние компоненты, в том числе с открытым кодом. Но сообщества, стоящие за опенсорс-библиотеками, устраняют уязвимости очень медленно. При этом исследователи всё активнее применяют средства автоматизации, что позволяет им быстрее находить разного рода прорехи.
Эксперт по информационной безопасности Security Vision Екатерина Гайнуллина
Екатерина Гайнуллина:
— Применение любых высокоавтоматизированных средств, в том числе DevSecOps, снижает зависимость от человеческих ошибок.
Руководитель отдела операционной поддержки ГК «Солар» Антон Прокофьев
Антон Прокофьев:
— О безопасности часто начинают вспоминать под воздействием со стороны заказчиков, на которых, в свою очередь, влияют регуляторы. Это не только ФСТЭК России, но и Центробанк, который отвечает за банковский сектор и сферу платежей, а также Роскомнадзор, в ведении которого — оборот персональных данных. При этом реализация методов безопасной разработки даже на базовом уровне снимает до 80 % проблем, связанных с эксплуатацией типовых уязвимостей.
По мнению Антона Прокофьева, роль ФСТЭК России в продвижении технологий безопасной разработки состоит в том, что она отошла от традиционной сертификации каждого обновления в пользу процесса разработки в целом. Это позволило сократить сроки выхода таких обновлений, что стало серьёзным конкурентным преимуществом для тех вендоров, кто сертифицировал процесс разработки раньше остальных.
Дмитрий Шмойлов назвал выпуск патчей для сертифицированных систем по традиционной схеме «большой головной болью для всех, пользователей в первую очередь». Сертификацию процесса разработки вместо длительных проверок каждого обновления представитель «Лаборатории Касперского» назвал очень серьёзным прогрессом, который, безусловно, будет способствовать повышению популярности технологий безопасной разработки. Также Дмитрий Шмойлов напомнил, что новая версия ГОСТ 56939, которая вступает в силу в конце 2024 года, вводит новые требования по обеспечению безопасности самой среды разработки.
Как отметил Илья Шабанов, в традиционной схеме тестирование начиналось лишь в середине процесса разработки, тогда как внедрение DevSecOps позволяет запускать его почти сразу (рис. 3). Как уточнил Дмитрий Шмойлов, этого требует в том числе внедрение популярных в настоящее время технологий быстрой разработки. Спикер также обратил внимание на то, что тестирование на безопасность охватывает все этапы жизненного цикла.
Рисунок 3. «Смещение влево» в процессе создания ПО
Екатерина Гайнуллина, сославшись на личный опыт, отметила, что в ходе внедрения процессов безопасной разработки часто забывают об управлении командой и унификации стандартов. Всё это, по её мнению, мешает автоматизации процессов и снижает эффективность работы. Эти направления не попали и в схему на рис. 3.
Антон Прокофьев назвал недостатком схемы полное игнорирование цепочек поставок, через которые идут многочисленные атаки. Стороннее ПО, по его словам, необходимо проверять даже тогда, когда нет явных эксплойтов или репозиторий открытого кода декларирует аудит проектов на безопасность.
Цена пренебрежения высока
Классическим примером того, к чему приводит пренебрежение нормами безопасной разработки, участники дискуссии назвали июльский сбой Windows-систем по всему миру. По оценке Ильи Шабанова, этот инцидент указывает прежде всего на необходимость тестирования ПО от партнёров.
Дмитрий Шмойлов выразил надежду на то, что уже в ближайшем будущем DevSecOps станет органичной частью процесса разработки ПО. Он сравнил это с обязательным мытьём рук при приготовлении пищи.
Алексей Антонов добавил, что наиболее распространены два подхода ко внедрению таких процессов. Одни делают это быстро и массово, другие же действуют постепенно, часто прибегая к инструментарию с открытым кодом. Однако чем ближе компания к энтерпрайз-сегменту, тем чаще, по наблюдениям спикера, преобладает первый вариант.
Как показал первый опрос участников конференции и зрителей эфира, основным стимулом ко внедрению DevSecOps стало желание действовать проактивно (рис. 4). Оно, по мнению Ильи Шабанова, набрало аномально много голосов. Это явление можно, однако, объяснить высоким удельным весом ИБ-специалистов в аудитории.
Рисунок 4. С чем связан ваш интерес к безопасной разработке?
После подведения итогов второго опроса (рис. 5) оказалось, что наиболее популярным требованием к поставщикам и партнёрам стал аудит их защиты. Также Илья Шабанов обратил внимание собравшихся на то, что многие (почти каждый пятый участник опроса) заявили об отсутствии требований по части мер защиты.
Рисунок 5. Требования к безопасности поставщиков и партнёров
Пересадить разработчиков на конвейер
На первый взгляд конвейер (pipeline) DevSecOps кажется сложным (рис. 6). По мнению Ильи Шабанова, трудности обусловлены как выставлением приоритетов при внедрении тех или иных инструментов, так и особенностями интеграции последних в уже выстроенный процесс.
Рисунок 6. Традиционный конвейер DevSecOps и применяемые в ходе тестирования инструменты
Екатерина Гайнуллина напомнила, что перед внедрением необходимо разработать стандарты по безопасности, причём делать это надо до создания планов тестирования. Также она порекомендовала не пропускать внедрение тестирования на ранних стадиях разработки: потом бороться с уязвимостями будет намного труднее.
Антон Прокофьев напомнил о требовании стандарта SDL, разработанного Microsoft, тестировать любые изменения, которые вносятся в код. Алексей Антонов порекомендовал интегрировать инструменты разработчиков со сканерами безопасности. Так, по его мнению, можно снизить сроки устранения обнаруженных уязвимостей до абсолютного минимума. Однако схема традиционного DevSecOps-конвейера, изображённая на рис. 6, как обратил внимание Алексей Антонов, не содержит важного компонента: безопасности контейнеров, которые очень широко используются. Положение осложняется тем, что последние «общаются» между собой не только через сеть — так что WAF может закрыть далеко не все уязвимости.
Илья Шабанов отметил, что в традиционном DevSecOps-конвейере не хватает и программ вознаграждений за уязвимости (bug bounty). Также модератор напомнил, что появляются новые классы продуктов, например IAST (Interactive Application Security Testing, интерактивное тестирование безопасности приложений), о которых не все знают, да и российских продуктов такого класса пока нет.
Дмитрий Шмойлов считает, что в левой части схемы не хватает разработки безопасной архитектуры. Её наличие позволяет не допустить многих ошибок уже на начальных стадиях. Кроме того, сканер кода может использоваться на разных стадиях разработки, а не только на фазе сборки.
DevSecOps на практике
Руководитель направления безопасной разработки УЦСБ Евгений Тодышев
Евгений Тодышев:
— Выработаны два подхода ко внедрению DevSecOps. В первом случае бизнес решает, кто будет участвовать в проекте, и всё спускает «сверху». Для этого он должен быть заинтересованным и понимать, зачем это ему нужно. Второй подход сложнее, но действеннее: ИБ приходит к разработчикам и начинает продвигать необходимость безопасной разработки, выращивать среди них секьюрити-чемпионов. Какой подход выбрать, зависит от компании.
Ведущий менеджер по развитию бизнеса ITD Group Анна Архипова
Анна Архипова:
— Процесс безопасной разработки должен охватывать всех участников процесса разработки ПО или веб-сайтов, включая и тех, кто будет их эксплуатировать. Практика показывает, что все они так или иначе участвуют, но заинтересованность на всех звеньях цепочки повышает эффективность процессов безопасной разработки.
Руководитель отдела анализа кода Angara Security Илья Поляков
Илья Поляков:
— Бизнес тоже заинтересован в безопасности кода. Я лично отвечал на вопросы о том, каким анализатором мы пользуемся, ещё на прежнем месте работы, задолго до 2022 года. ПО обрабатывает весьма конфиденциальные данные, так что в процессы DevSecOps вовлекаются люди из коммерческих подразделений, далёкие от разработки.
Анна Архипова предупреждает: покупки инструмента недостаточно, нужны ещё нетехнические меры. Без повышения уровня знаний разработчиков тот же анализатор кода из стандартного конвейера (рис. 6), статический (SAST) или динамический (DAST), работать не будет. Необходимо, по мнению спикера, начинать не с какого-то одного продукта, а с совокупности. В частности, помимо сканеров кода необходимы инструменты контроля опенсорсных компонентов (OSA).
Кроме того, Анна Архипова назвала важной задачей выстраивание обратной автоматизированной цепочки — от приложения к коду — уже после внедрения. Особенно это важно для контейнерных сред.
Евгений Тодышев напомнил о необходимости планирования и разработки архитектур: работу над ними нужно начинать до внедрения технических средств. Илья Поляков порекомендовал перед запуском работ по проекту внедрения обратиться ко внешнему аудитору. «На выходе» будет получен хорошо документированный набор дефектов в коде, понятный разработчикам. Только тогда оформится набор процессов и инструментов, которые нужно внедрять.
Также Илья Поляков обратил внимание на то, что стандартные анализаторы не позволяют выявлять ошибки в бизнес-логике, на которые приходится до 70 % всех уязвимостей. Для их устранения необходимо выполнить ревизию архитектуры и чаще проводить внутренние пентесты. Из технических средств находить такого рода ошибки умеют только инструменты IAST, которых на российском рынке мало — и они при этом далеко не панацея.
Накладные средства защиты являются в большей степени временной мерой, позволяющей снизить ущерб от возможной эксплуатации уязвимостей на время их устранения. При этом, как предупредил Евгений Тодышев, многие из таких средств, например WAF, можно обойти. Об этом свидетельствуют результаты пентестов. А вот средства на основе искусственного интеллекта (ИИ) показывают вполне высокую эффективность: по словам Анны Архиповой, при разборе результатов сканирования трудозатраты снижаются иногда в восемь-девять раз. Илья Поляков назвал решение подобных задач без использования ИИ абсолютно невозможным (в разумные сроки, по крайней мере).
Евгений Тодышев заявил, что ИИ и машинное обучение в той или иной форме используют все, кто занимается внедрением DevSecOps. Соответствующий инструментарий добавляют многие вендоры, в том числе и отечественные. Однако, по мнению представителя УЦСБ, полностью заменить человека такие помощники не могут, будучи сугубо рекомендательными сервисами.
Как показал третий опрос аудитории (рис. 7), внедрили DevSecOps или находятся на стадии внедрения лишь чуть более 40 % участников. Евгений Тодышев назвал наиболее проблемной категорией те 8 %, которые не верят в DevSecOps: их очень трудно убедить в необходимости внедрения. Однако, по мнению Анны Архиповой, недоверие быстро исчезает, если компания сталкивается с серьёзным инцидентом.
Рисунок 7. На какой стадии внедрения DevSecOps вы сейчас находитесь?
Как измерить результаты проекта
Как напомнила Анна Архипова, по всем методологиям и направлениям существуют метрики. Однако важно и личное общение, поскольку только таким образом можно понять, работает ли тот или иной инструмент — особенно если его внедрили, что называется, «для галочки». Такое, как показывает практика, бывает часто.
Евгений Тодышев обратил внимание на то, что на стадии внедрения следить за метриками трудно. Однако результативность зрелого процесса отслеживается легко, и технический директор или CISO будут видеть то, как выявляются уязвимости.
Любая ошибка в коде, обнаруженная на стадии Bug Bounty, свидетельствует, как подчеркнул Илья Поляков, о серьёзном дефекте в бизнес-процессах, который нужно найти и устранить. Эффективность инструментов легко проверить с помощью намеренно уязвимого кода на любом языке программирования, который можно найти в репозиториях. А вот количество срабатываний сканера, как отметил спикер, метрикой считать нельзя.
По мнению Ильи Шабанова, в качестве метрики можно рассматривать снижение количества уязвимостей. Это продемонстрировала Microsoft, которая активно использовала его в маркетинговых материалах для своих продуктов, включая SQL Server и Windows. В итоге популярность практик безопасной разработки возросла.
Евгений Тодышев назвал такой подход работающим. Плюс ко всему, снижение количества ошибок и уязвимостей легко перевести в понятную бизнесу денежную форму. Однако для этого нужен заинтересованный руководитель, который понимает экономическую сторону вопроса.
Анна Архипова выразила другое мнение: необходимо делать акцент на том, что приложения становятся более безопасными, а количество обнаруженных уязвимостей не позволяет оценить эффективность процесса их поиска и устранения.
Страхи и реальные проблемы в сфере DevSecOps
Существует мнение, что внедрение DevSecOps замедляет процесс разработки. Однако участники дискуссии отнесли эти опасения к разряду суеверий и предрассудков. Как отметил Евгений Тодышев, если такое и имеет место, то только на начальной стадии внедрения и на короткий срок. Если безопасностью разработки хоть как-то занимались, то сроки выхода новых версий продуктов не увеличиваются, а иногда даже и уменьшаются.
Более серьёзной проблемой является высокая стоимость коммерческих инструментов, используемых в процессе DevSecOps. Однако, как напомнила Анна Архипова, существуют инструменты с открытым исходным кодом, с которых можно начать.
По мнению Антона Прокофьева, по-настоящему значимым сдерживающим фактором является разбор обнаруженных проблем в коде: далеко не все из них являются уязвимостями и, соответственно, нуждаются в исправлении. Однако с этой задачей, по оценке Анны Архиповой, помогает справиться ИИ, и тут накоплен большой положительный опыт.
Антон Прокофьев также обратил внимание на значимость внутренних регламентов при внедрении безопасной разработки. На его взгляд, лучший результат даёт выращивание так называемых секьюрити-чемпионов, которые следят за процессом изнутри. Однако Илья Поляков, сославшись на личный опыт, назвал эту практику малополезной: во многих компаниях она «не взлетела».
По мнению Дмитрия Шмойлова, кадровые проблемы неизбежны в любой молодой отрасли, в том числе и в области безопасности приложений. К тому же здесь нужны междисциплинарные знания и навыки. В итоге, как подчеркнул спикер, готовых рекомендаций по подбору кадров нет. Можно найти людей на рынке труда, можно выращивать экспертов внутри. Мотивация тоже может быть разной, не обязательно материальной.
Также Дмитрий Шмойлов напомнил: если на сотрудника накладывают дополнительные обязанности, то нужно компенсировать это снятием каких-то других. Только так можно снизить (но не снять совсем) риск того, что человек не справится.
По мнению Ильи Полякова, устранить кадровую проблему можно с помощью передачи функций контроля безопасности на аутсорсинг во внешнюю компанию — тем более что многие интеграторы начинают оказывать подобные услуги. Также, по его оценке, помогает использование средств автоматизации, в том числе с ИИ.
Как отметил Евгений Тодышев, компания УЦСБ уже хорошо отработала услуги аутсорсинга функций безопасной разработки. Он назвал потенциальной аудиторией такой услуги небольших разработчиков, которые работают в специфических нишах — например, создают ПО для промышленных систем вроде MES или АСУ ТП.
По мнению участников финального опроса (рис. 8), основными препятствиями для внедрения DevSecOps являются дефицит кадров и компетенций, на которые в общей сложности пришлось 40 % голосов, а также недостаток денег. По мнению Анны Архиповой, сославшейся на личный опыт, эти причины очень тесно связаны: руководители не финансируют проекты по внедрению DevSecOps как раз потому, что не осознают их необходимости.
Рисунок 8. Основные препятствия для внедрения DevSecOps
Выводы
Главным выводом из дискуссии стало то, что уже в ближайшем будущем DevSecOps станет неотъемлемой частью процесса разработки. К этому будут так или иначе подталкивать с одной стороны регуляторы, с другой — потенциальные заказчики. При этом измерить эффективность процессов и результатов не так трудно, как кажется.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий! Для этого подпишитесь на наш канал в YouTube.
