Безопасность приложений
Узнать большеЧтобы готовое ПО содержало меньше уязвимостей, разработчики должны с первых этапов создания позаботиться о безопасности, внедряя различные технологии анализа кода: статическое и динамическое тестирование, исследование состава, оценку рисков Supply Chain-атак и др. Эти методы легко интегрируются в Security Development Lifecycle (SDLC) — процесс безопасной разработки. Основной предпосылкой для внедрения такого подхода являются требования регуляторов (в частности, ФСТЭК России), которые фокусируются на технологической безопасности. В статье подробно рассказываем о нюансах SDLC и инструментах анализа ПО.
Что такое процесс безопасной разработки
Процесс безопасной разработки SDL — создание программных продуктов с упором на аспекты информационной безопасности и контроль защищенности ПО на протяжении всего жизненного цикла. Условно говоря, задача команды — найти и устранить максимум уязвимостей до выпуска приложения, вместо того, чтобы устранять последствия атак на программу. Такой подход позволяет соблюдать законодательные и отраслевые требования к программному обеспечению, минимизировать риски инцидентов ИБ, сохранять конфиденциальность пользовательских данных. Также он повышает вероятность своевременного нахождения проблем, что, в свою очередь, приводит к сокращению Time-to-Market, снижению числа потенциальных рекламаций и нагрузки на группы техподдержки.
Стратегия SDL предполагает интеграцию эффективных практик и технологий для раннего выявления уязвимостей, защиты от угроз. Также очень важно добиться слаженного взаимодействия команды разработчиков и специалистов, контролирующих вопросы безопасности.
Ключевые этапы процесса безопасной разработки в рамках модели SDLC
Коротко описываем каждый из семи этапов, из которых складывается процесс безопасной разработки.
Обучение команды
Причастные к разработке лица должны знать основы безопасного кодирования и дизайна приложений, уметь моделировать потенциальные угрозы и определять возможную область атак. Именно поэтому процесс безопасной разработки предполагает проведение тренингов и семинаров, посвященных теме кибербезопасности и созданию качественного кода.
Обучение должны пройти все члены команды, даже если обеспечением безопасности ПО будут заниматься компетентные специалисты: аналитики, секьюрити-инженеры, тестировщики. Чем выше общий уровень осведомленности, тем меньше вероятность пропустить проблемы с приложением.
Определение требований к программному обеспечению
На данном этапе определяются требования к безопасности создаваемого продукта. Они формируются с учетом отраслевых норм, типа обрабатываемых данных, лучших практик ИБ, актуального ландшафта угроз, опыта прошлых инцидентов.
На какие вопросы команда должна ответить на этом этапе процесса безопасной разработки:
- Какие риски безопасности ПО наиболее высоки и что можно предпринять для их снижения.
- Какой уровень приватности должен быть у приложения.
- Какая часть ПО в первую очередь потребует анализа.
- Какие тестирования безопасности будут проводиться, нужно ли привлекать к процессу пентестеров и других сторонних специалистов.
Самые строгие требования предъявляются к безопасности приложений для государственных структур и финансового сектора. Это связано с обработкой строго конфиденциальной информации, утечка которой может обернуться серьезными последствиями, в том числе проблемами с законом.
Создание и актуализация моделей угроз
На этом этапе процесса безопасной разработки ПО создаются модели угроз, которые должны быть классифицированы в соответствии с потенциальными рисками. Эти модели следует обновлять и дополнять на протяжении всего жизненного цикла программного продукта.
Реализация
Внедрение тестирований кода с целью обнаружения и своевременной ликвидации существующих уязвимостей. На этом этапе анализ проводится без запуска ПО, поэтому важно учитывать, что могут быть выявлены не все бреши безопасности.
Верификация
Это этап тестирований, подразумевающих запуск приложения в рабочей среде. Задача — проверить, как программа ведет себя при эксплуатации, будут ли сбои, некорректные действия и т.д.
Выпуск
Релиз программного обеспечения, перед которым разработчики финально проверяют, соответствует ли готовый продукт требованиям к безопасности. Также на этом этапе генерируется комплекс мер реагирования на инциденты ИБ.
Реагирование
Применение мер реагирования на хакерские атаки и другие инциденты ИБ — это тоже этап процесса безопасной разработки, которым нельзя пренебрегать. Команда должна знать, что предпринять в тех или иных случаях, чтобы повысить уровень безопасности ПО.
Аудит
Выявление потенциальных проблем, выводы по итогам работы над ошибками, определение мер для улучшения процессов разработки.
Обзор основных технологий для анализа ПО при построении процесса безопасной разработки
Перечислим пять ключевых инструментов, позволяющих всесторонне контролировать безопасность разрабатываемых продуктов:
- Static Application Security Testing (SAST, метод белого ящика) — статический анализ программы, обеспечивающий практически полное покрытие исходного кода. Может проводиться уже со старта процесса безопасной разработки, не требует запуска приложения, позволяет обнаружить максимум существующих уязвимостей. Минусы: необходимость доступа к коду, большая вероятность ложноположительных срабатываний False Positive (если анализ проводится с помощью автоматического анализатора).
- Dynamic Application Security Testing (DAST, метод черного ящика) — динамическое тестирование приложения, развернутого в имитированной рабочей среде. Выполняется с помощью автоматизированных сканеров, имитирующих реальные атаки и пользовательские действия с целью проанализировать поведение ПО. Позволяет обнаружить уязвимости и проблемы, которые проявляются только при эксплуатации продукта. Главное преимущество — анализ можно проводить без доступа к коду и знания структуры программы.
- Software Composition Analysis (SCA) — исследование состава приложений с целью выявить все open-source-компоненты кода, проанализировать сторонние библиотеки и зависимости. Такой анализ позволяет обнаруживать уязвимости в заимствованных фрагментах, программные закладки в библиотеках, проблемы с лицензиями.
- Supply Chain Security (SCS) — технология, позволяющая оценить риски, связанные с используемыми в коде сторонними компонентами, спрогнозировать вероятность атак на какое-либо из звеньев цепочки поставок (Supply Chain). На основе нескольких метрик автоматический анализатор исследует ПО и выставляет каждому компоненту оценки доверия.
- Анализ лицензионных рисков — проверка, позволяющая контролировать лицензионные политики при внедрении в ПО open-source-компонентов, оценивать юридические риски, связанные с лицензиями. Обычно такое тестирование применяется в комплексе с SCS.
У всех перечисленных технологий есть как достоинства, так и минусы, которые можно нивелировать, применяя тестирования комплексно. Например, в целях обнаружения уязвимостей DAST комбинируется с SAST. Исследование open-source-компонентов также происходит комплексно с помощью технологий SCA и SCS.
Выбор инструментов для контроля безопасности программных продуктов
Выбранный анализатор для проведения тестирований ПО в процессе безопасной разработки должен:
- Интегрироваться со средствами разработки, репозиториями, системами контроля безопасности и другими используемыми инструментами.
- Выдавать минимальное количество ложных срабатываний при проведении анализа.
- Формировать подробные отчеты по результатам проверок.
- Поддерживать все распространенные языки программирования.
- Иметь простой и интуитивно понятный пользовательский интерфейс для управления сканированиями и изучения отчетов.
Всем этим критериям соответствует сертифицированная ФСТЭК России платформа Solar appScreener, позволяющая выстроить процесс безопасной разработки и контролировать защищенность ПО с первых этапов. С помощью анализатора можно проводить все перечисленные в статье виды тестирований, получать коррелированные отчеты по результатам SAST, DAST, SCA и SCS. Также среди преимуществ: поддержка 36 языков программирования и 10 форматов исполняемых файлов, технология Fuzzy Logic Engine для минимизации False Positive, наличие собственной базы уязвимостей для более эффективного проведения SCA-анализа.
