Сегодня организации сталкиваются с угрозами кибербезопасности, которые становятся все более разнообразными, сложными и изощренными. В тоже время, не каждая компания обладает отделом специалистов по кибербезопасности. Но любая современная IT-компания должна задумываться над безопасностью своих продуктов. Решением могут стать инструменты для автоматизации процессов обеспечения безопасности, чтобы развертывать решения безопасности быстрее и не держать большой отдел по кибербезопасности.
На практике основными причинами появления нарушений безопасности являются недостатки реализации механизмов защиты, уязвимости в коде приложения, недостатки конфигурации. Очень часто контроль со стороны службы информационной безопасности проводится на последних этапах жизненного цикла приложения. Такой сценарий несовместим с современными методиками DevOps и Agile, которые сокращают сроки циклов поставки ПО до нескольких недель.
Существует несколько подходов к анализу защищенности программного обеспечения, например, метод белого и черного (серого) ящика. При этом, проведение анализа исходного кода методом белого ящика позволяет обнаружить больше уязвимостей критичного уровня, в сравнении с методом черного ящика, который анализирует поведение уже собранного приложения.
Исправление ошибок на этапах эксплуатации или внедрения намного дороже, чем исправление уязвимостей на более ранних этапах. Чем раньше будет выявлена уязвимость, тем дешевле обойдется компании ее исправление. Принцип Shift Security Left (сдвиг безопасности влево) играет важную экономическую роль.
Стоимость исправления уязвимостей в приложениях может быть в 1000 раз дешевле на этапе разработки, чем после вывода продукта на рынок.
Внедрение процессов безопасности на более ранних этапах жизненного цикла может быть реализовано следующими способами:
Внедрение приемки кода, внедрение внутреннего аудита, внедрение процесса безопасной разработки (DevSecOps). При этом DevSecOps включает в себя все остальные пункты и является наиболее эффективным подходом к обеспечению безопасности.
Преимущества DevSecOps
DevSecOps интегрирует задачи по обеспечению безопасности приложений и инфраструктуры в процессы и инструменты Agile и DevOps.
Как и в случае с Agile инструментами, DevSecOps включает в себя разносторонние, синергетические методы, такие как непрерывная интеграция и непрерывная доставка (далее CI/CD), которые поощряют и поддерживают частую проверку кода, контроль версий, разумную автоматизацию тестирования, непрерывные выпуски с низким уровнем риска и обратную связь. В среде DevSecOps бизнес может извлечь выгоду из таких практик, сэкономив ресурсы за счет улучшения операций, сокращения переделок, повышения качества за счет автоматизированного тестирования и мониторинга, а также за счет более быстрой доставки проектов/продуктов клиенту.
Решает проблемы безопасности по мере их появления, когда это можно сделать с меньшими затратами времени и средств.
Такой подход позволяет проводить проверку, аудит, сканирование и тестирование кода на безопасность на каждом этапе цикла разработки. Проблемы безопасности устраняются сразу же после их обнаружения. Это исключает появление дополнительных зависимостей и увеличивает скорость исправления обнаруженных уязвимостей безопасности. Скорость разработки, безопасность и качество кода растут, а затраты снижаются.
Позволяет разделить ответственность за безопасность приложений и инфраструктуры между специалистами по разработке, безопасности и эксплуатации IT-систем. Закрывает такие вопросы, как:
– кто ищет уязвимости;
– кто исправляет уязвимости;
– кто проверяет корректность и полноту исправления;
– как обеспечить взаимодействие между подразделениями.
DevSecOps подход гарантирует, что члены группы эксплуатации и безопасности будут вовлечены в разработку с самого начала работы. Важную роль в DevSecOps играет распределение обязанностей по обеспечению безопасности среди владельцев продуктов и процессов. Таким образом, инженеры и разработчики становятся владельцами процессов и несут ответственность за свою работу.
Интеграция с CI/CD конвейерами. Тестирование кибербезопасности можно интегрировать в наборы автоматических тестов.
Современные программы для автоматического поиска уязвимостей позволяют производить анализ исходного кода прямо через CI/CD конвейеры, такие как Jenkins или TeamCity, и по результатам работы формировать тикеты с заданием на исправление уязвимости. В автоматических тестах можно задавать необходимые параметры сканирования для конкретного проекта, таким образом учитываются специфика и особенности каждого продукта, в зависимости от его назначения. Например, если приложение использует сторонние библиотеки, может быть включен анализ сторонних компонентов (SCA) для выявления уязвимостей в стороннем коде. Автоматизация позволяет удостовериться в том, что продукт успешно прошел этап модульного тестирования безопасности. Кроме того, возможно проводить тестирование исходного кода методом статического анализа на этапе разработки и динамический анализ приложений на этапе тестирования до развертывания итогового обновления в рабочей среде.
Методы DevSecOps
Не смотря на все преимущества DevSecOps, компании часто сталкиваются с общим набором проблем при переходе от DevOps к DevSecOps, которые можно решить, используя следующие методы.
· Продвижение культуры DevSecOps среди команд разработчиков. Командам необходимо предоставить возможность встроить безопасность в жизненный цикл разработки ПО (далее SDLC). Задачей организаций является объединение в одно сообщество специалистов по разработке, эксплуатации и нормативному контролю, чтобы каждый сотрудник разбирался в корпоративной системе безопасности и следовал единым стандартам. Все участники жизненного цикла доставки должны быть знакомы с базовыми принципами защиты приложений, списком из 10 самых опасных уязвимостей OWASP (Open Web Application Security Project), методами тестирования безопасности приложений и другими подходами к проектированию. Разработчики должны хорошо понимать модели угроз, проверки на соответствие нормативным требованиям и обладать практическими навыками оценки рисков, угроз и реализации средств контроля безопасности.
· Хорошей практикой является подход, при котором разработчики имеют подготовку по безопасному кодированию, они выполняют тестирование безопасности до того, как происходит коммит кода. Например, один из способов — использовать сканеры на основе интегрированных сред разработки (далее IDE), для выявления небезопасного кода прямо на рабочей станции разработчика.
· Разработчики должны заранее утвердить контрольные точки, когда выполнять действия по обеспечению безопасности. Необходимо продумать, когда действия по обеспечению безопасности выполняются в SDLC. Как упоминалось в предыдущем пункте, опытные разработчики проводят тестирование безопасности до того, как произойдет коммит кода. Это не позволяет разработчикам проверять незащищенный код. Для других организаций самой ранней отправной точкой для сканирования безопасности могут быть их центральные конвейеры интеграции, которые обычно запускаются сразу после слияния исходного кода из веток разработчиков в основную ветку. Всегда стоит помнить, что сканирование безопасности выгоднее проводить на более раннем этапе разработки.
· Автоматизация является ключевым фактором, позволяющим сбалансировать интеграцию безопасности со скоростью и масштабом. Современные анализаторы эффективно встраиваются в SDLC, а системы непрерывной интеграции, такие как Jenkins, позволяют интегрироваться с программами для автоматического поиска уязвимостей в исходном коде.
· При первом внедрении сканеров в конвейер DevSecOps, как правило, включается большое количество наборов правил и конфигураций сканирования. Это препятствует внедрению DevSecOps, так как команды разработчиков внезапно обнаруживают в своих очередях множество проблем безопасности, что делает невозможным их устранение в течение короткого времени. Поэтому, важно начинать с небольших изменений, например, командам следует ограничить набор правил пятью основными уязвимостями и запустить более глубокое сканирование позже.
· При внедрении автоматизированных методов сканирования, не стоит забывать про внеплановые проверки, которые помогают сбалансировать требования безопасности. По результатам таких проверок можно настраивать инструменты безопасности, анализируя исторические данные и информацию о приложениях. Например, можно переводить сканирование на ручной режим при аномальных событиях в статическом анализе кода или проводить анализ сторонних компонентов при нахождении критической уязвимости.
· Внедрение DevSecOps также подразумевает автоматизацию деятельности по управлению. При выборе инструмента для автоматизации необходимо учитывать наличие достаточного количества интерфейсов для его интеграции с другими подсистемами. Например, чтобы позволить разработчикам выполнять сканирование в IDE, нужно использовать инструмент, который поддерживает распространенное программное обеспечение IDE. Например, анализатор SonarJava интегрируется в сборочную систему Gradle, Maven и запускается в различных IDE через плагин SonarLint.
· Принципы «governance-as-code» и «configuration-as-code» предоставляют возможность управления через конфигурационные файлы, а не через интерактивное взаимодействие. Это ускоряет разработку и вывод продукта на рынок и определяет уровень автоматизации, который может быть достигнут во всем SDLC. Возможность автоматической проверки конвейера доставки программного обеспечения не исключает необходимость ручного вмешательства, чтобы обрабатывать исключения и корректировать элементы управления.
· Важно собирать обратную связь с команды разработчик при внедрении новых средств обеспечения безопасности. Сотрудничество, получение одобрения и предоставление возможностей командам разработчиков является ключом к обеспечению того, чтобы модель управления была инклюзивной и удобной в использовании.
Придерживаясь несложных правил, внедрение процесса безопасной разработки будет наиболее эффективным для компании и займет намного меньше времени.
Инструменты анализа безопасности
Известным подходом к выявлению уязвимостей является пентест. Цель пентеста — это взлом приложения, то есть поиск слабого места в приложении, из которого злоумышленник может развить вектор атаки. Но пентест не дает уверенности, что все уязвимости в коде найдены и верифицированы.
Ручной анализ кода – долго и дорого, существующие решения анализа требуют наличия отдела ИБ. Есть бесплатные open-source решения. Например, Reshift — это программное обеспечение для управления уязвимостями, включающее такие функции, как маркировка активов, управление исправлениями, управление политиками, определение приоритетов, оценка уязвимостей и веб-сканирование. Поддерживает пять языков программирования.
Преимущества данного анализатора:
⁃ Можно установить, как расширение для множества IDE;
⁃ Можно установить, как плагин GitHub.
Еще один анализатор LGTM – это платформа анализа кода для поиска уязвимостей нулевого дня и предотвращения критических уязвимостей. LGTM был разработан лабораторией GitHub совместно с создателем другого анализатора CodeQL, что позволило совместить статический анализ и анализ через специальный язык запросов. Поддерживает пять языков программирования и является расширением для GitHub.
Стоить заметить, что бесплатные анализаторы имеют ряд недостатков: во-первых, они имеют ограниченный функционал, который расширяется платной подпиской, во-вторых, некоторые из них не имеют поддержки в настоящее время и давно не обновлялись.
Анализаторы приложений используют автоматизированные решения: SAST (статический анализ), DAST (динамический анализ), IAST (интерактивный анализ), SCA (анализ сторонних компонентов).
Статический анализ — технология «белого ящика», которая анализирует и находит уязвимости прямо в исходном коде на этапе разработки.
Динамический анализ — технология «черного ящика», которая проверяет готовое приложение. Подает на вход приложения различные данные и анализируя, что приложение выдает на выходе на этапе тестирования.
Интерактивный анализ — подход, целью которого является поиск уязвимостей в ходе выполнения кода на этапе разработки.
Анализ сторонних компонентов — анализ 3rd party code, сторонние библиотеки и зависимости. Возможно применение на любом этапе жизненного цикла приложения.
Множество существующих решений используют либо один из подходов к анализу безопасности приложений (SAST или DAST), либо некоторые их комбинации (SAST + SCA). Но данные подходы не являются взаимозаменяемыми, поэтому исключая один из них, мы можем пропустить уязвимость.
Самым надежным в настоящее время признан инструментальный анализ, который нацелен на поиск всех уязвимостей в коде. В общем случае, инструментальный анализ должен включать статический анализ, динамический анализ, поиск слабых библиотек и конфигураций.
Application Inspector
Примером инструментального подхода к анализу безопасности является Application Inspector решение от Positive Technologies (AI PT).
AI PT объединяет все анализаторы кода и дает следующие преимущества:
⁃ Прохождение сертификации;
⁃ Оценка качества кода;
⁃ Поиск уязвимостей на разных языках программирования;
⁃ Генерация эксплоитов и условий эксплуатации уязвимости. (Алгоритм абстрактной интерпретации);
⁃ Создание шаблонов и тикетов в CI/CD системах.
Application Inspector имеет 2 версии: AI Desktop Edition и AI Enterprise Edition.
AI Desktop Edition используется для классической задачи приемки кода и лицензируются по количеству языков сканирования и по количеству сканируемых проектов.
AI Enterprise Edition имеет сервер сканирования и агенты сканирования, что позволяет встраивать процесс анализа кода в существующий CI/CD конвейер. Данная версия лицензируются по количеству агентов сканирования, а также по количеству языков сканирования.
В сравнении с остальными коммерческими и бесплатными анализаторами, PT Application Inspector имеет дополнительные возможности, которые отображены в таблице.
По сравнению с бесплатными движками, PT AI имеет Taint-анализ, то есть поиск уязвимостей нулевого дня. А в сравнении с коммерческими продуктами, PT AI имеет возможности абстрактной интерпретации, что позволяет вычислять условия эксплуатации уязвимости и генерировать эксплоиты. То есть разработчик может эмулировать в интерфейсе анализатора кода ту часть программы, которая имеет уязвимость.
Алгоритм поиска по шаблонам позволяет искать известные сигнатуры по базе данных уязвимостей (CVE, внутренние базы) и строить диаграммы потока данных.
Одна из особенноcтей PT AI является генерация отчетов в разных форматах. Например, HTML формат удобочитаем для разработчика, а на основе отчета в JSON формате можно проводить самостоятельный анализ и строить графики.
Заключение
Целью данной статьи было убедить вас, что переход к безопасной разработке является важным этапом эволюции IT-компаний. Задумываться о безопасности стоит не задним числом, а с самого первого шага жизненного цикла проекта. Стоит отметить, что преобразование вашей организации в DevSecOps — это масштабное мероприятие со многими известными и неизвестными проблемами. Важно помнить, что DevSecOps не является готовым инструментом или золотым конвейером. Потребуется дорожная карта, чтобы стать реальностью для любой организации. Но в конечном итоге, внедрение безопасной разработки сократит расходы компании на исправление ошибок, сэкономит время разработки, сделает взаимодействие среди сотрудников более качественным, где каждый четко понимает свою роль и самое главное, поможет создавать более совершенные и безопасные продукты для пользователей.
