Новые реалии заставили многих разработчиков пересмотреть отношение к безопасности создаваемого кода. Но происходящие события затронули также и заказчиков софта. Общемировой тренд в развитии ПО указывает на резкое увеличение числа уязвимостей. Каковы основные методики и подходы в этой области и как на требованиях по безопасности кода сказались актуальные события?
- Введение
- Безопасный исходный код: реальность или фантазия?
- Является ли «правильно разработанный» код безопасным?
- Риски от использования небезопасного кода
- Проверка безопасности кода
- Сертификация безопасности кода
- Инструменты для проверки кода на безопасность
- SAST, OSA, SCA, DAST, IAST, BAST…
- Процесс внедрения технологий проверки кода
- Как работает сканер безопасности кода?
- Анализ безопасности и требования госстандартов
- Примеры нарушения безопасности кода и их последствия
- Тенденции в развитии рынка безопасности исходного кода
- Выводы
Введение
Эфир AM Live от 9 ноября 2022 года был посвящён теме безопасности исходного кода и его анализа силами самих разработчиков. Каковы основные методики и подходы к повышению защищённости? Как проверять архитектуру и логику разработанного ПО на надёжность? Как выбрать анализатор исходного кода и контролировать безопасность компонентов Open Source?
В обсуждении этих и других вопросов приняли участие ведущие эксперты российского рынка:
- Сергей Деев, менеджер продукта Solar appScreener, «РТК-Солар».
- Михаил Волков, руководитель группы департамента сертификации и тестирования, НПО «Эшелон».
- Юрий Шабалин, ведущий архитектор Swordfish Security.
- Анна Архипова, ведущий менеджер по развитию продуктовых решений, ITD Group.
- Денис Кораблев, управляющий директор, директор по продуктам, Positive Technologies.
- Дмитрий Куколев, руководитель группы разработки защищённых и безопасных продуктов, «Мобильные ТелеСистемы».
- Дмитрий Шмойлов, руководитель отдела безопасности программного обеспечения, «Лаборатория Касперского».
Модератором дискуссии выступил Лев Палей, начальник службы информационной безопасности СО ЕЭС.
Рисунок 1. Участники дискуссии в эфире AM Live
Безопасный исходный код: реальность или фантазия?
Лев Палей, модератор дискуссии, предложил сначала выяснить, какой именно код можно называть безопасным. Существует ли он в природе или возникает только в умозрениях далёких от реальности людей?
По мнению Юрия Шабалина (Swordfish Security), абсолютно безопасного исходного кода не существует в принципе, есть только «недоизученный» код. «Сколько бы специалистов ни привлекалось, какими бы инструментами они ни пользовались, всё равно рано или поздно найдётся новая уязвимость в коде».
В то же время в рамках отдельно взятой компании или отдельного продукта можно выделить некий уровень, которым можно назвать «безопасным».
«Код можно назвать безопасным, если он удовлетворяет критериям качества безопасности, вписывающимся в модель угроз и нарушителей, которой придерживаются в компании, — считает Юрий Шабалин. — Требования зависят от места применения продукта. Есть внутренний и внешний контуры применения, мобильные приложения всегда применяются в открытой, враждебной среде».
Юрий Шабалин, Ведущий архитектор Swordfish Security
«Оценка безопасности разработки, — дополнил сказанное Сергей Деев («РТК-Солар»), — может быть проведена в рамках существующей нормативной базы. Это позволяет компаниям считать свои приложения безопасными. Уровень определяется применяемой методологией. Для примера, это может быть OWASP Firmware Security Testing Methodology».
Является ли «правильно разработанный» код безопасным?
Как считает Юрий Шабалин (Swordfish Security), все разработчики априори готовы создавать безопасный код. Но в реальности код пишут без явных ошибок только те, кто обладает соответствующим багажом знаний. Можно ли считать код безопасным, если его не проверяли, доверяя уровню разработчика?
По мнению Дениса Кораблева (Positive Technologies), оценка безопасности кода всегда зависит от дизайна решения. «Если в его выбор вкралась ошибка, то любой продукт, даже разработанный идеально, не может считаться безопасным», — считает он.
С его точки зрения, при оценке безопасности кода необходимо принимать во внимание модель угроз (чего боимся?) и портрет злоумышленника (кто будет атаковать?). Необходимо учитывать также, что софт работает в определённой среде. Поэтому компрометация системы может происходить, например, через утечку данных, а не через взлом кода. Даже при идеально написанном коде система может оказаться небезопасной. Безопасность кода не является самоцелью.
С этим мнением согласен Дмитрий Шмойлов («Лаборатория Касперского»). «Код полностью безопасен до тех пор, пока он не используется. Угрозы возникают, когда код начинает работать. В этот момент возникает модель угроз, появляются возможные нарушители, другие проблемы. Модель угроз определяет причины, из-за которых “абсолютно безопасный” неработающий код становится небезопасным. Поэтому оценка безопасности кода сильно зависит от риск-модели компании и уровня её зрелости».
Это идеально иллюстрируется практикой. На начальном этапе внедрения проблемы с безопасностью обычно отсутствуют (разработчики внедрили безопасный код). Уязвимости возникают потом.
Лев Палей, Начальник службы информационной безопасности, СО ЕЭС
Риски от использования небезопасного кода
Сергей Деев («РТК-Солар») отметил, что такие риски чаще всего оценивают количественно — например, через призму затрат на восстановительные работы. Но не стоит забывать о существовании и качественных оценок, играющих не менее важную роль для компаний. Сюда, в частности, относятся имиджевые потери.
Как рассказал Дмитрий Куколев, в компании «МТС» для нейтрализации рисков провели тщательную проработку всех этапов жизненного цикла ПО, начиная с подготовки дизайна решений. «Теперь уже на этапе разработки продукта даются оценки критической значимости рисков для компании. Оцениваются используемые данные и допустимая степень их безопасности. Исходя из полученной оценки, при разработке конкретного кода расставляются элементы контроля».
«Наши оценки выстроены на том, насколько трудоёмким для злоумышленников будет процесс атаки на код и его данные. Это позволяет оценить риски, принимая во внимание, что проведение слишком сложной атаки будет, скорее всего, невыгодно хакеру. Исходя из дизайна, мы выбираем критические точки контроля».
Рисунок 2. Анализируете ли вы исходный код своих проектов на безопасность?
Проверка безопасности кода
Жизненный цикл SDLC предполагает, что в оценке безопасности кода будут принимать участие разные команды: вендор, заказчик, партнёры. Как распределяются между ними работы и ответственность за получение в итоге безопасного кода?
Как рассказала Анна Архипова (ITD Group), это участие проявляется по-разному. Практически у каждой компании встречается внутренняя разработка. Эта особенность может стать критической с точки зрения рисков. «Важно различать также безопасность кода, поставляемого в открытом и закрытом видах. В первом случае риски возлагаются на заказчика, в то время как с закрытым кодом требуется поступать иначе. Необходимо оценить, как будет выстроен процесс взаимодействия с разработчиком. В этом случае вендор несёт репутационные риски, компания — технические».
Анна Архипова, Ведущий менеджер по развитию продуктовых решений, ITD Group
О позиции вендора ПО при взаимоотношениях с заказчиком рассказал Денис Кораблев (Positive Technologies). «Безопасность клиентов, особенно крупных, является для вендора очень важной задачей. Мы стараемся подготовить заранее список событий, которые клиент считает для себя недопустимыми. Это позволяет оценить недопустимые события и сделать прогноз, как они могли бы быть реализованы при действиях извне. После этого можно выстраивать процессы для обеспечения безопасности».
Денис Кораблев также отметил, что выстраивать защиту можно по-разному. «Можно защищать в первую очередь концевое приложение. Если же доступ к критически важным для заказчика участкам внутренней инфраструктуры отделён от места работы концевого приложения, то можно выстроить усиленный мониторинг на этом промежутке».
«При ведении разработки через внешнюю организацию важно прописать в техзадании ответственность: исправление ошибок должно ложиться на подрядчика в рамках контракта. Если же контракт заключается в соответствии с принципом “time and materials”, то выстраивать процесс безопасной разработки и эксплуатации ПО необходимо на стороне вендора, ведь разработка ведётся под его контролем, хотя и с привлечением внешних ресурсов».
Анна Архипова (ITD Group) добавила, что операции по соблюдению безопасности не исчерпываются одним обходом классического цикла DevSecOps «разработка — внедрение». Разработка софта продолжается до тех пор, пока он находится в эксплуатации. Его безопасность необходимо учитывать на протяжении всего жизненного цикла приложения.
Рисунок 3. Циклы разработки DevSecOps
Сертификация безопасности кода
Экспертом по госсертификации выступил Михаил Волков (НПО «Эшелон»). Он сообщил, что в нынешний момент «наблюдается наплыв компаний с новыми продуктами в рамках импортозамещения. Большинство из них не обладают достаточными навыками в области разработки безопасного кода».
При проведении сертификации НПО «Эшелон» опирается сейчас прежде всего на методологию ФСТЭК России. Она требует выполнять проверки по конкретной версии кода. Выдаваемый сертификат является свидетельством его безопасности на определённый период.
Эта особенность вызывает много вопросов со стороны разработчиков. Они ссылаются на то, что сроки обновления могут быть очень короткими (например, раз в неделю). Поэтому сертификация отдельной версии не охватывает процесс SDLC целиком. Получать сертификаты становится затруднительно.
Михаил Волков отметил, что нынешние требования со стороны ФСТЭК России предусматривают не только получение сертификата, но и последующую доработку самого продукта, в т. ч. для устранения уязвимостей. «После внесения изменений требуется пройти лайт-сертификацию. При её прохождении проверяются внесённые изменения и удостоверяется отсутствие новых ошибок или уязвимостей. Предполагается, что на сертификацию будут передаваться крупные обновления. Обычно это происходит раз в полгода или год».
Обновления, добавленные в код после сертификации и выполненные в соответствии с документированной процедурой, не снижают уровень безопасности, считает представитель НПО «Эшелон». Поэтому действие сертификата сохраняется.
Михаил Волков, Руководитель группы департамента сертификации и тестирования, АО "НПО «Эшелон»"
Денис Кораблев (Positive Technologies) рассказал о слухах, которые ходят сейчас в сообществе вокруг этой темы. «Сертификационные органы планируют перейти в будущем на сертификацию процесса разработки программных продуктов. Это означает, что если продукт сертифицирован, то и любые его модернизации также сертифицированы априори. Пока эта модель сертификации не принята окончательно, но движение идёт в эту сторону».
Дмитрий Шмойлов («Лаборатория Касперского») отметил: для реализации этих планов необходимо, чтобы внутри компании-разработчика был выстроен процесс разработки и чтобы он прошёл сертификацию.
«В этом как раз и состоит идея проекта нового ГОСТа РПО (регистра проверенных организаций), который мы уже подготовили, — подтвердил слухи Михаил Волков. — Вендор подаёт уже подготовленные документы, отражающие список проведённых испытаний: статический анализ, динамический анализ, фаззинг-тестирование, пентесты и так далее. Если в лаборатории по сертификации не возникает дополнительных вопросов, то сертификат будет выдаваться очень быстро».
Инструменты для проверки кода на безопасность
Живой интерес среди участников дискуссии вызвала тема выбора инструментов для проверки кода на безопасность.
Как рассказал Юрий Шабалин, в компании Swordfish Security ориентируются на концепцию BSIMM (Building Security In Maturity Model). Она описывает все возможные практики, с которыми могут столкнуться компании при построении процесса безопасной разработки.
Раньше многие организации придерживались принципа «shift left», сущность которого — установка средств контроля и применение различных методов обеспечения безопасности приложений на более раннем этапе SDLC (жизненного цикла ПО), предшествующем появлению риска или уязвимости.
«Теперь мы придерживаемся концепции “shift everywhere”. Она подразумевает проведение тестирования безопасности приложений, как только появляется достаточно артефактов. Тестирование проводится в любом месте и на любом этапе SDLC. Это позволяет применять практики безопасной разработки там, где они могут принести максимальную пользу. Ранее определённые инструменты тестирования должны были применяться строго в определённых местах: например, статические методы анализа — только на месте шлюза».
Дмитрий Куколев, Руководитель группы разработки защищенных и безопасных продуктов, МТС
О том, как выглядит выстраивание процесса безопасной разработки на практике, рассказал Дмитрий Куколев («МТС»). «Мы стали внедрять принцип “shift left” начиная с 2017 года. В 2021 году мы поняли, что движемся в неправильном направлении. Мы осознали, что количество необходимых проверок становится настолько огромным, что мы не справляемся с ними. Поэтому мы перешли на “shift everywhere”, установив соответствующие контроли (статические, динамические, композиционный анализ). Их действие распространяется на весь цикл жизни ПО, начиная с момента создания. Это позволяет иметь представление, из каких компонентов собирался продукт, кто и когда делал их. В такой парадигме разработчик видит, что происходит с его продуктом, и может выбрать, когда и как он может поправить ошибку. Разработчик также видит рекомендации со стороны группы проверки после проведённого анализа».
«Встраивание процесса с технической точки зрения происходит на уровне продуктовой фабрики, — отметил Дмитрий Куколев. — Это позволяет иметь доступ к билд-фермам и контролировать компоненты, которые участвуют в процессе сборки ПО. Мы стараемся максимально взаимодействовать с разработчиками на всём протяжении SDLC и подсказывать, что происходит с их кодом. Новый подход обеспечивает нужное качество в безопасности используемых продуктов».
Рисунок 4. Какой из методов анализа безопасности исходного кода вы считаете наиболее важными в цикле SDLC?
SAST, OSA, SCA, DAST, IAST, BAST…
В среде ИБ нередко можно встретить различные аббревиатуры, часть из которых активно используются в задачах проверки безопасности кода. Их расшифровку дал Юрий Шабалин (Swordfish Security).
- SAST (Static Application Security Testing) — статический анализ кода: проверка библиотек, поступающих в контур разработки.
- OSA (Open Source Analysis) — анализ компонентов с открытым исходным кодом.
- SCA (Software Composition Analysis) — анализ состава программного кода (из чего состоят программные системы).
- DAST (Dynamic Application Security Testing) — динамический анализ кода.
- IAST (Interactive Application Security Testing) — интерактивный анализ кода.
- BAST (Business Application Security Testing или Behavioral Application Security Testing) — анализ кода бизнес-программ или поведенческий анализ кода.
Анна Архипова (ITD Group) рассказала историю их появления, что также важно для понимания их роли. «Сначала в середине 1970-х годов появился DAST. В начале 2000-х годов появился SAST, в 2019-2020 годах — IAST. DAST больше относится к позднему этапу жизненного цикла ПО. Если же выделять особо стадию разработки, то цель безопасности — не допустить появления уязвимостей на этапе, когда начинает работать DAST. Поэтому SAST наиболее широко распространён в задачах безопасности исходного кода».
Процесс внедрения технологий проверки кода
О внедрении технологий рассказал Денис Кораблев (Positive Technologies). «Прежде всего надо выбрать на начальном этапе практику проверки кода. Сделанный выбор должен наилучшим образом соответствовать особенностям компании. При ошибочном выборе система будет пропускать много угроз или будут выделяться несущественные случаи. Это будет затруднять работу по контролю безопасности».
По словам эксперта, чаще всего построение процесса проверки начинают с выбора средств статистического анализа; рынок этих продуктов отличается зрелостью и наличием большой практики. Далее добавляют новые элементы, исходя из понимания того, как они гармонируют с уже внедрёнными инструментами. Частичное дублирование помогает не пропускать уязвимости на практике.
Денис Кораблев, Управляющий директор, директор по продуктам, Positive Technologies
«Важное влияние на процесс внедрения оказывает поддержка руководства, — добавил Дмитрий Шмойлов («Лаборатория Касперского»). — Пока оно не поймёт, что необходимо тратить ресурсы и контролировать безопасность в процессе выпуска релизов, всё остальное будет бесполезно. Формально будет предоставляться отчёт, выявленные риски будут приниматься и ПО пойдёт в продакшн, где оно столкнётся с реальными рисками».
«Наряду с поддержкой руководства также необходимо учесть ещё одну важную особенность, — добавил Дмитрий Куколев («МТС»). — Считается, что разработчики готовы писать безопасный код. Это так и есть, но не всегда им хватает знаний для этого». Как следствие, когда разработчикам предлагают ознакомиться со списком многочисленных неучтённых элементов в коде, которые могут приводить к его компрометации, никакого рвения со стороны разработчиков к исправлению ошибок, по словам эксперта, нет.
Дмитрий Шмойлов («Лаборатория Касперского») согласился с этим: «Информация о выявленных ошибках должна дойти до разработчика ещё и вовремя. Эту информацию необходимо донести ещё до того, как разработчик переключится на другой проект или функцию».
Рисунок 5. Что вас ограничивает во внедрении анализа безопасности исходного кода?
Как работает сканер безопасности кода?
Почему наличие готовых сканеров кода, работающих в автоматическом режиме, не позволяет выявлять уязвимости «из коробки»? Это было следующей темой, которую раскрыли участники дискуссии.
Сначала Сергей Деев («РТК-Солар») рассказал, как работает классический статический анализатор кода (SAST). «Его работу можно представить в следующем виде: сначала он получает исходные данные, затем приводит их к унифицированному виду и применяет определённые алгоритмы. На выходе выдаётся заключение о возможном присутствии уязвимостей с определённым уровнем критической значимости».
Сергей Деев, менеджер продукта Solar appScreener, «Ростелеком-Солар»
«Если проанализировать статистику пентестеров Positive Technologies, — продолжил Денис Кораблев (Positive Technologies), — то получается, что соотношение технических уязвимостей и ошибок бизнес-логики составляет 30 и 70. Это говорит о том, что взлом систем через технические уязвимости в ПО совершается значительно реже, чем взлом через ошибки в бизнес-логике (например, вход через случайно выявленный IP-адрес)».
Очевидно, что сканер «из коробки» не имеет никакой информации о бизнес-логике продукта в конкретной компании. Поэтому для его практического применения необходимо дописывать сценарии проверки для выявления ошибок бизнес-логики. Только после этого можно проводить полноценную проверку ПО.
Что касается технических уязвимостей, то при анализе бинарного кода пропадает семантика программной логики. В результате многие конструкции становятся не видны. При подаче бинарных файлов также появляются многочисленные положительные срабатывания из-за невыполнения определённых логических переходов. Адреса переходов должны быть формально запрещены в коде, но этого не делается. Так появляется возможность «вычислить» эксплойты.
«Если же сканер безопасности не умеет работать с конкретным языком, то придётся возлагать все надежды на уникального специалиста в компании (если такой имеется), который умеет распознавать уязвимости интуитивно», — отметил Дмитрий Шмойлов («Лаборатория Касперского»). — Есть очень талантливые люди, которые видят уязвимости, как в “Матрице”. Они — самородки, могут найти многие проблемы в исходном коде при недостаточной информации. Но этот вариант защиты дорог и не масштабируется.
Второй вариант для решения проблемы с отсутствием поддержки конкретного языка — это связь с комьюнити, ведущим его разработку. К моменту дозревания до уровня внедрения уже всегда готов инструмент для контроля безопасности. Исключение может составлять разве что российская разработка “Линтер”, но это — особый случай».
Рисунок 6. Какой из вариантов организации анализа безопасности исходного кода является оптимальным для вашей компании?
Анализ безопасности и требования госстандартов
Михаил Волков (НПО «Эшелон») отметил, что «безопасная разработка уже стала частью нашей жизни. Она позволяет самостоятельным компаниям выходить на рынок государственных систем и иметь соответствующий уровень доверия со стороны государства. Без неё выйти на госрынок невозможно».
Мнение сообщества выразил Денис Кораблев (Positive Technologies): «Коммерческие компании ждут от регуляторных органов отхода от традиционной оценки уровня стойкости программных продуктов против хакерских атак. Они ждут предложения новых сетевых метрик, которые будут отражать реальную стойкость программных систем против актуальных угроз».
Примеры нарушения безопасности кода и их последствия
О реалиях нынешнего года в этой области высказались все участники дискуссии. Отметим мнение Дмитрия Шмойлова («Лаборатория Касперского»).
«Общемировая тенденция последнего года — резкое снижение качества безопасной разработки в выпускаемых продуктах. Это заметили также и хакерские группы, которые стали активно охотиться за ошибками в новых релизах. Прежде всего такие ошибки попадаются в Open Source». По словам эксперта, хакеры подменяют данные для авторизации, добавляют уничтожители информации и шифровальщики, размещают среди внешних библиотек свои вредоносные программы.
В сложившейся ситуации острым становится вопрос о необходимости тщательной проверки кода, особенно когда пакеты получают извне.
Дмитрий Шмойлов, Руководитель отдела безопасности программного обеспечения, «Лаборатория Касперского»
Тезисы Дмитрия Шмойлова дополнил Дмитрий Куколев («МТС»): «В последнее время мы постоянно ловим пакеты типа “protestware”, особенно с массовыми попытками дефейса сайта. Мы отреагировали достаточно быстро после февральских событий. В течение трёх дней был запущен в работу анализатор плагинов, который стал отлавливать код с вредоносным действием. Перехват продолжается постоянно. К настоящему моменту мы уже отловили более 700 пакетов с атаками “protestware”».
Рисунок 7. Каково ваше мнение относительно анализаторов безопасности исходного кода?
Тенденции в развитии рынка безопасности исходного кода
Дмитрий Шмойлов («Лаборатория Касперского»):
— OpSec будет и далее тесно интегрироваться с другими подразделениями ИБ. Оценка безопасности войдёт в число основных свойств программных систем. В перспективе это произойдёт с ростом популярности концепции «secure by design».
Дмитрий Куколев («МТС»):
— Рост внимания к безопасности кода со стороны компаний будет способствовать снижению количества имеющихся уязвимостей. Это позволит создавать более безопасные продукты, быстрее выводить их на рынок. Средства контроля безопасности внутри кода сохранятся, но станут более скрытыми.
Денис Кораблев (Positive Technologies):
— Ещё не так давно о безопасности беспокоились в основном только пользователи систем. Теперь эта тема стала неотъемлемой частью процесса разработки. В будущем проверка безопасности может войти в список обязательных видов тестирования для всех программных продуктов. Она дополнит функциональное, нагрузочное и прочие виды тестирования. Команды OpSec станут заниматься анализом более сложных сценариев уязвимостей, передав тривиальные случаи на выявление автоматическим средствам анализа. Процесс контроля безопасности ПО станет более творческим.
Анна Архипова (ITD Group):
— До сих пор только часть разработчиков обращала внимание на проблемы безопасности создаваемого кода. В будущем эта функция станет для них обязательной. Будущие проверки станут более комплексными.
Юрий Шабалин (Swordfish Security):
— Будет расти комьюнити разработчиков. Они будут делиться своими наработками в области безопасности. Хотелось бы, чтобы появился русский аналог Acoustic Vehicle Alerting System (AVAS) — системы, которая предупреждает всех участников звуковым сигналом о возникновении опасности. Возможно, также появятся инструменты оркестровки, которые будут собирать данные о безопасности работы ПО из различных источников. Это поможет оценивать защищённость кода более комплексно.
Михаил Волков (НПО «Эшелон»):
— Хочется, чтобы в будущем появился репозиторий для достоверно безопасных программ. Его проверкой будут заниматься не только вендоры, но и разработчики из других компаний. Потребуется повышать уровень знаний по безопасности среди разработчиков. Создаваемые комьюнити должны принять, что в своей деятельности им следует придерживаться правового поля.
Сергей Деев («РТК-Солар»):
— Создание такого репозитория уже ведётся на уровне нацпроекта силами Минцифры. Это усиливает роль регулятора не только для организаций, которые упоминаются в системе сертификации, но и для широкого круга других участников (КИИ, ГИС и так далее). Для зрелых компаний это будет означать переход от стандартной сертификации к процессу аккредитации их инфраструктуры сборки безопасных приложений. Это поможет ускорить появление новых функций в продуктах и будет стимулировать компании к участию в общем процессе безопасной разработки.
Выводы
Как согласились все участники дискуссии, будущее российской разработки ПО связано с созданием нового сообщества. Совместными усилиями там будут развивать требования к безопасности программных продуктов. Это может дать синергетический эффект, поскольку позволит повысить доверие к отечественному софту.
Самые горячие для российского рынка информационной безопасности темы мы обсуждаем в прямом эфире онлайн-конференции AM Live. Чтобы не пропускать свежие выпуски и иметь возможность задать вопрос гостям студии, не забудьте подписаться на YouTube-канал Anti-Malware.ru. До встречи в эфире!
