для чего не используются сканеры уязвимостей при аудите
Сканирование на уязвимости и безопасная разработка. Часть 1
В рамках профессиональной деятельности разработчикам, пентестерам, безопасникам приходится сталкиваться с такими процессами, как Vulnerability Management (VM), (Secure) SDLC.
Под этими словосочетаниями скрываются различные наборы практик и используемых инструментов, которые переплетены между собой, хотя их потребители различаются.
Технический прогресс пока не дошёл до того, чтобы одним инструментом заменить человека для проведения анализа защищённости инфраструктуры и ПО.
Интересно понять, почему это так, и с какими проблемами приходится сталкиваться.
Процессы
Процесс Vulnerability Management («управление уязвимостями») предназначен для непрерывного мониторинга защищённости инфраструктуры и патч-менеджмента.
Процесс Secure SDLC («цикл безопасной разработки») предназначен для поддержки защищённости приложения в ходе разработки и эксплуатации.
Схожей частью этих процессов является процесс Vulnerability Assessment — оценки на уязвимости, сканирования на уязвимости.
Основное различие в сканировании в рамках VM и SDLC в том, что в первом случае целью является обнаружить известные уязвимости в стороннем ПО или в конфигурации. Например, устаревшую версию Windows или community-строку по умолчанию для SNMP.
Во втором же случае целью является обнаружить уязвимости не только в сторонних компонентах (зависимостях), но в первую очередь в коде нового продукта.
Это порождает различия в инструментах и подходах. На мой взгляд, задача поиска новых уязвимостей в приложении значительно интереснее, поскольку не сводится к фингерпринтингу версий, сбору баннеров, перебору паролей и т.д.
Для качественного автоматизированного сканирования уязвимостей приложений необходимы алгоритмы, учитывающие семантику приложения, его предназначение, специфичные угрозы.
Инфраструктурный же сканер зачастую можно заменить таймером, как выразился avleonov. Смысл в том, что чисто статистически вы можете считать вашу инфраструктуру уязвимой, если вы её не обновляли, скажем, месяц.
Инструменты
Сканирование, как и анализ защищённости, можно выполнять как чёрным ящиком, так и белым ящиком.
Black Box
При blackbox-сканировании инструмент должен уметь работать с сервисом через те же интерфейсы, через которые с ним работают пользователи.
Сканеры инфраструктуры (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose и т.д.) ищут открытые сетевые порты, собирают «баннеры», определяют версии установленного ПО и ищут в своей базе знаний информацию об уязвимостях в этих версиях. Также пытаются обнаружить ошибки конфигурации, такие как пароли по умолчанию или открытый доступ к данным, слабые шифры SSL и т.д.
Сканеры веб-приложений (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, и т.д.) тоже умеют определять известные компоненты и их версии (например, CMS, фреймворки, JS-библиотеки). Основные шаги сканера — это краулинг и фаззинг.
В ходе краулинга сканер собирает информацию о существующих интерфейсах приложения, HTTP-параметрах. В ходе фаззинга во все обнаруженные параметры подставляются мутированные или сгенерированные данные с целью спровоцировать ошибку и обнаружить уязвимость.
Такие сканеры приложений относятся к классам DAST и IAST — соответственно Dynamic и Interactive Application Security Testing.
White Box
При whitebox-сканировании различий больше.
В рамках процесса VM сканерам (Vulners, Incsecurity Couch, Vuls, Tenable Nessus и т.д.) зачастую дают доступ к системам, проводя аутентифицированный скан. Таким образом, сканер может выгрузить установленные версии пакетов и конфигурационные параметры прямо из системы, не угадывая их по баннерам сетевых сервисов.
Скан получается точнее и полнее.
Если же говорить о whitebox-сканировании (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs и т.д.) приложений, то речь обычно идёт о статическом анализе кода и использовании соответствуюбщих инструментов класса SAST — Static Application Security Testing.
Проблемы
Проблем со сканированием возникает множество! С большинством из них мне приходится сталкиваться лично в рамках предоставления сервиса по построению процессов сканирования и безопасной разработки, а также при проведении работ по анализу защищённости.
Выделю 3 основные группы проблем, которые подтверждаются и беседами с инженерами и руководителями служб ИБ в самых разных компаниях.
Проблемы сканирования веб-приложений
Проблемы сканирования исходного кода
Проблемы сканирования инфраструктуры
Подходы
Stay tuned and let’s disrupt the vulnerability scanning!
Аудит информационной безопасности. SCAP ликбез
В статье:
> показана роль требований к защищенности в процессе аудита;
> описан SCAP подход к формализации требований;
> рассмотрены три сканера безопасности;
> поверхностно разобрана логика работы сканеров, поддерживающих SCAP;
> представлены вид результатов аудита и возможности по исправлению недостатков.
Материал развивает тему аудита информационной безопасности и составляет часть цикла статей.
Время для чтения — 10 минут.
Цикл статей об автоматизации аудита безопасности.
1. Автоматизация аудита информационной безопасности или SCAP ликбез.
2. Автоматизация аудита информационной безопасности: XCCDF и OVAL.
3. OpenSCAP. Настройка и использование. Ожидается.
Введение
Информационно-вычислительная система — совокупность данных (или баз данных), систем управления базами данных и прикладных программ, функционирующих на вычислительных средствах как единое целое для решения определённых задач [ГОСТ Р 53622-2009].
Далее понятие информационная система употребляется тождественно терминам: информационно-вычислительная система, операционная система, база данных, сетевое устройство и т.д.
Стандарты, приказы, рекомендации определяют требования к информационным системам. Требования к безопасной конфигурации, управлению уязвимостями и обновлениями встречаются в лучших практиках от CIS (Center for Internet Security), стандарте PCI DSS, приказах ФСТЭК и других документах.
Для проверки того, насколько информационная система соответствует требованиям, выполняют аудит информационной безопасности.
Информационная система — сложный и динамичный объект. Поэтому полный, да еще и периодический, аудит безопасности админ видит в кошмарах. Например рекомендации CIS по безопасной настройке Windows 10 включают сотни пунктов на тысяче листах в бумаге.
Выход один — автоматизация. Методику автоматизации аудита, де-факто — стандарт, разработал NIST.
Статья иллюстрирует процесс аудита информационной безопасности с учетом этого стандарта.
Структурная схема процесса автоматизированного аудита безопасности информационных систем с использованием SCAP
Требования
Регуляторы, исследователи, руководители определяют в законах, рекомендациях и политиках высокоуровневые бумажные требования к информационным системам.
Например PCI DSS определяет требования к безопасной конфигурации систем и управлению уязвимостями.
Управление конфигурациями и уязвимостями — элемент системы управления информационной безопасностью. Этот элемент включает обязательную периодическую проверку того, насколько конфигурации систем остаются неизменными, а новые уязвимости закрываются патчами.
SCAP (Security Content Automation Protocol) — спецификация, которая определяет три процесса: поиск и исправление уязвимостей, автоматическую настройку конфигураций, а также оценку уровня безопасности.
SCAP включает четыре языка: XCCDF, OVAL, OCIL, ARF; четыре схемы идентификации: CCE, CPE, SWID, CVE и две метрики: CVSS, CCSS.
Основные компоненты SCAP — языки XCCDF и OVAL. XCCDF и OVAL детально рассмотрены во второй статье цикла.
XCCDF (Extensible Configuration Checklist Description Format) — язык, который описывает контрольные списки настроек безопасности и связывает другие компоненты SCAP.
OVAL (Open Vulnerability and Assessment Language) — декларативный язык логических утверждений. OVAL описывает уязвимости и необходимое состояние конфигурации информационной системы.
XCCDF содержит наборы требований к информационным системам, а OVAL — инструкции для интерпретатора, которые эти требования формализуют. Интерпретатор — специальный сканер, который понимает язык SCAP.
Требования, которые преобразовали в инструкции для интерпретатора, называют SCAP-контентом.
Начальник отдела или администратор безопасности видит бумажные требования и задается вопросом «Где брать SCAP-контент?».
Интерпретаторы
Формализованные требования в виде SCAP-контента являются входными данными так называемых интерпретаторов или сканеров. Сканеров существует великое множество. Раньше MITRE вел учет «авторизованных» организаций, выпускаемых ими продуктов и репозиториев OVAL. Теперь этим занимается CIS. Я не нашел на их сайте такой-же перечень.
Рассмотрим некоторые бесплатные интерпретаторы: OVALdi, OpenSCAP и ScanOVAL.
OVALdi
В OVALdi заложены две функции — демонстрация оценки и проверка синтаксиса OVAL-документов. Тем не менее возможно использование для проведения аудита. Есть версии как для Windows, так и для Linux. Распространяется по BSD лицензии.
Управление OVALdi возможно только из командной строки и только локально.
Для запуска сканирования нужно ввести команду с правами администратора:
где m — не проверять целостность OVAL-документа, o — путь к OVAL-документу.
OpenSCAP
Проект компании Red Hat. OpenSCAP представлен множеством продуктов, среди которых OpenSCAP Base — сканер с CLI интерфейсом и открытым исходным кодом и SCAP Workbench — сканер с GUI интерфейсом.
Интерфейс SCAP Workbench
Несмотря на то, что средства OpenSCAP подходят для Windows, бОльшие возможности представлены для unix-подобных систем, т.к. изначально проект направлен только на их оценку.
Интерпретатор запускается командой в терминале:
SvanOVAL
Средство, разработанное для ФСТЭК одной российской компанией. Средство бесплатное и подходит как для Windows, так и для Linux (Astra).
Интерфейс ScanOVAL
Главный недостаток состоит в следующем. Возможности средства ограничены проверкой только на уязвимости из БДУ ФСТЭК. При этом проверяется цифровая подпись OVAL-документа. Несмотря на недостатки, ScanOVAL — большой шаг ФСТЭК к небумажной безопасности.
SCAP-логика
Для упрощения многие нюансы не учтены, что принципов SCAP, в целом, не нарушает, но позволяет лучше понять сам подход. Детально SCAP-логика представлена тут.
Схема базовой логики SCAP
XCCDF-документ содержит профили, один из которых можно выбрать для проверки, например — поиск уязвимостей в Windows 10 или соответствие каким-то конкретным требованиям. Фактически профили содержат контрольные списки, которые должны быть проверены для определения того, соответствует ли система этому профилю.
Контрольные списки содержат описательную информацию — вербальные требования, рекомендации по устранению несоответствий, метрики оценки и т.д. Все это используется для вывода пояснений к результатам проверки.
Но главное, что содержит каждый элемент контрольного списка — это ссылка на конкретное определение в связанном OVAL-документе. После обработки OVAL-определения интерпретатор возвращает результат булева типа ( true или false ), на основе которого делается вывод о выполнении требования из контрольного списка.
В OVAL-документе определения формируют логическую связку из тестов, которые должны быть пройдены. Каждый тест с помощью логических операторов связывает объекты и состояния.
Тесты, объекты и состояния бывают различных типов, которых достаточно много. Именно их многообразие определяет широкие возможности спецификации SCAP.
Состояние в OVAL-документе задает требуемое значение параметра, который характеризует какой-то объект.
Интерпретатор при обработке теста, определяет значение параметра, характеризующее текущее состояние объекта и, в соответствии с указанной в тесте логикой, сравнивает его с заданным значением. На основе этого формируется результат теста булева типа.
В определении результаты каждого связанного теста также сравниваются в соответствии с заданной логикой, в результате чего вычисляется финальный результат, который характеризует выполнение конкретного требования из контрольного списка.
Результаты
Согласно спецификации SCAP результаты аудита представляюстя в формате ARF (Asset Reporting Format).
Отчет в формате ARF содержится в XML-документе и включает описания профилей, требований из контрольных списков и итоговые результаты по каждому пункту из контрольного списка.
Как правило, результаты сканирования преобразуются к удобочитаемому виду.
Пример результатов проверки Windows 10 на наличие уязвимостей с помощью интерпретатора OVALdi
Исправление
Возможности протокола SCAP предполагают автоматическое исправление найденных несоответствий и устранение уязвимостей (функционал должен поддерживаться системой автоматизированного аудита).
Такой вариант кажется неплохим, но автоматические исправления могут нарушить работоспособность системы, поэтому использовать эти возможности нужно вдумчиво.
Наиболее распространен вариант, когда результаты проверки представлены перечнем невыполненных требований и текстовым описание действий, которые нужно выполнить для исправления. Например как в бесплатной версии CIS-CAT.
Пример результатов интерпретатора CIS-CAT Lite с рекомендациями по устранению
Заключение
Автоматизация аудита — важнейшая задача информационной безопасности, ее актуальность обусловлена количеством, сложностью и динамичностью систем, которые должны соответствовать определенным требованиям.
SCAP предоставляет гибкую и многогранную методологию автоматизации, которая, однако, имеет недостатки:
Сканеры безопасности: автоматическая классификация уязвимостей
Растущее количество угроз вынуждает разработчиков средств анализа защищенности постоянно усовершенствовать свои решения. Сейчас на рынке ИБ представлен широкий выбор сканеров безопасности от различных производителей, которые разнятся по своей эффективности. Это делает невозможным выпуск новых версий сканеров без конкурентного анализа подобных продуктов.
Компания Positive Technologies разработала собственную методологию конкурентного анализа для тестирования и сравнения сканеров по объективным критериям, таким как типы и количество найденных уязвимостей, полнота сканирования различных целей. Кроме того, была сформирована база данных конкурентного анализа (DBCA — Database of Competitive Analysis), в которой собраны уникальные уязвимости, найденные в процессе ручных проверок и автоматического сканирования синтетических целей, реальных сайтов, CMS, веб-приложений и прочих информационных систем сканерами безопасности (WebEngine – встроенный в PT AF и PT AI, Acunetix, AppScan и др.). DBCA используется для сравнения результатов сканирования новыми версиями сканеров Positive Technologies с результатами сторонних сканеров и отсеивания ложных срабатываний (false positive).
Однако наполнение DBCA требует месяцев ручного труда высококвалифицированных инженеров-тестировщиков. Процессы настройки окружений и сканирования занимают много времени, порой недели. Еще дольше происходит процесс валидации найденных уязвимостей. Так, над заполнением текущей базы работали три инженера отдела QA в течение года. В связи с этим возникла необходимость ускорения и автоматизации работ.
Решением стало использование математического аппарата нейронных сетей (НС) и нечетких измерительных шкал. Об этом мы подробно писали в предыдущей статье «Сканеры безопасности: автоматическая валидация уязвимостей с помощью нечетких множеств и нейронных сетей». Теоретические исследования вошли в основу практического эксперимента, поставленного инженерами Positive Technologies: Тимуром Гильмуллиным, Владимиром Софиным, Артемом Юшковским.
Была решена формальная задача по преобразованию DBCA в базу знаний, путем использования НС (в качестве решающего правила) и нечетких измерительных шкал (для лингвистической оценки результатов классификации в понятной человеку форме). Практически DBCA была дополнена правилами и механизмами отсеивания ложных срабатываний, заранее отсортированных по степени уверенности в их наличии, оцененных на нечеткой измерительной шкале. Это позволило ускорить работу инженеров-тестировщиков по анализу результатов сканирования и отсеиванию ложных срабатываний.
Ретроспектива, критерий приемки и основные результаты
После завершения работ по первичному заполнению DBCA уязвимостями, база содержала несколько десятков тысяч уязвимостей. Из них инженеры-тестировщики в течение года классифицировали лишь около половины. Результаты нашего анализа показали, что они выполняли до 70% лишних действий по отсеиванию ложных срабатываний от всего объема работ.
При регулярном проведении работ по конкурентному анализу использование автоматической системы для валидации уязвимостей дает огромный прирост производительности и повышает эффективность ручного труда — можно сократить до 70% объема требуемых работ! Кроме того, применение автоматической системы освободит инженеров для других приоритетных задач, что позволит увеличить число сканеров, участвующих в конкурентном анализе, и количество сканируемых CMS.
Со стороны тестирования были получены следующие критерии приемки и требования эффективности:
Функциональная схема классификации уязвимостей
Весь комплекс автоматизации процессов для классификации уязвимостей был описан функциональной IDEF0-схемой.
Рис. 1 Функциональная IDEF0-схема
На схеме отражены основные этапы классификации уязвимостей:
В качестве измерительных шкал для оценки свойств информационных систем была использована универсальная нечеткая измерительная шкала (рис. 2).
Рис. 2. Распределение уровней по нечеткой универсальной шкале
Нечеткая шкала (FuzzyScale) — это набор упорядоченных нечетких переменных, представленных в виде лингвистических переменных, описывающих некоторые свойства объекта:
Матрица кодирования свойств уязвимостей и формат ее хранения
Любой способ классификации уязвимостей предполагает кодирование, поэтому одним из важных этапов классификации уязвимостей было кодирование входных данных. В качестве основного элемента мы использовали матрицу кодирования свойств уязвимостей (Coding Matrix). Она применяется для преобразования уязвимостей, полученных из базы TFS в формате XML, в текстовый DAT-файл специального формата, подаваемого на вход нейросети программы FuzzyClassificator. После построения матрицы написать скрипты (support scripts) для кодирования при помощи матрицы не составляет никакого труда. Подробнее читайте в блоге (Кодирование входных данных).
Для более эффективного обучения нейросети требовалось подобрать оптимальную матрицу, которая описывает способ кодирования наиболее значимых свойств уязвимостей, подаваемых на входы нейросети. Матрица была реализована при помощи простого JSON-файла.
Автоматизация процесса классификации уязвимостей в TeamCity
Для удобства инженеров-тестировщиков весь процесс, представленный на функциональной схеме, был автоматизирован в системе интеграции TeamCity. Часть конфигурации, приведенная на рис. 3, иллюстрирует точку входа для реализации блоков 4, 5, 6 (7) функциональной схемы.
Рис. 3. Конфигурация в TeamCity, которая запускает процесс классификации уязвимостей
После завершения процесса анализа уязвимостей TeamCity выдает текстовые файлы с отчетами по классификации уязвимостей-кандидатов и статистику с оценкой качества обучения нейросети на эталонах.
Кроме того, до получения итоговых результатов можно оценивать качество обучения нейросети по ошибкам, которые она выдает на эталонных векторах. Процесс обучения проходит в удобном для инженера формате: вся необходимая информация выводится в конфигурации Training network (см. рис. 4) в реальном времени.
Рис. 4. Вывод промежуточных результатов по качеству обучения нейросетей
Параметры на рис. 4 отражают основные показатели обучения на эталонных векторах:
Примеры отчетов
Для удобства интерпретации результатов статистика во всех отчетах разбита на отдельные блоки, т. е. на выходе инженер-тестировщик получает понятный и подробный отчет. Под спойлером представлены пояснения по каждому блоку.
В заголовке отчета Overview:
• Neuronet — используемая сеть;
• Input file with encoded vectors — файл со входными данными для обучения или классификации (в зависимости от отчета);
• Network configuration — конфигурация нейронной сети;
• Report legend — описание нечетких уровней, использующихся для оценки принадлежности уязвимости к классам подтвержденных или неподтвержденных уязвимостей.
В таблице Main statistics:
• Total classificated vectors’ count — количество обработанных уязвимостей при классификации;
• Allocation table of sorted by levels vectors’ count — таблица распределения количества векторов уязвимостей по различным нечетким уровням.
В таблице Neural network quality statistics (for ethalon vectors only):
• False classificated vectors’ count — количество ошибочно классифицированных векторов уязвимостей при обучении на эталонах, согласно правилам подсчета статистики по качеству обучения нейросети (неполное совпадение засчитывается как верный результат);
• Allocation table of sorted by levels false classificated vectors — количество ошибок классификации сгруппированных по различным нечетким уровням.
• TFSID — ссылка на уязвимость в DBCA;
• Level Confirm — результат классификации уязвимости нейросетью, показывающий степень уверенности в том, что уязвимость подтверждается;
• Level Reject — результат классификации уязвимости нейросетью, показывающий степень уверенности в том, что уязвимость не подтверждается;
• Interpreting as — как интерпретировать результат композиции двух уровней (Level Confirm, Level Reject), четкий итоговый результат классификации:
Рис. 5. Пример отчета по классификации уязвимостей-эталонов, содержащий статистику по качеству обучения нейросети
На рис. 5 представлен пример отчета по классификации уязвимостей-эталонов. Данные, полученные нейросетью после обучения (блок Classification Result), сравниваются с эталоном и выдается результат — True или False (засчитать ответ как правильный или как ложный). По итогам классификации подсчитывается число ошибочно классифицированных уязвимостей при обучении на эталонах, согласно правилу подсчета статистики по качеству обучения нейросети. Это правило мы свели в табл. 1, где указали уровни, которые можно считать правильным результатом при классификации, исходя из практических соображений.
Табл. 1. Интерпретация ответов нейросети при обучении
В ходе исследования мы пришли к выводу, что требовать от нейросети стопроцентного совпадения уровней при классификации уязвимостей невозможно, так как некоторые уровни близки по значению друг к другу. К примеру, человек, получив в результате классификации Level Reject = High вместо Max, зачтет такую уязвимость как опровергнутую. Поэтому, если результат, выданный нейросетью, «близок» к истинному значению (High вместо Max и Low/Med вместо Min), то мы считаем его правильным при обучении True (weak), если значения полностью совпадают, то True (strong). Отметим, что правила для реальных уязвимостей строже, чем для ложных, так как выявление реальных уязвимостей является более приоритетной задачей. Все остальные варианты, не указанные в таблице, считаются ложным ответом (False).
Рис. 6. Пример отчета по классификации уязвимостей-кандидатов, содержащий значения нечетких уровней и их интерпретацию
Аналогично отчету по классификации уязвимостей-эталонов выглядит отчет с результатами классификации по кандидатам. Нейросеть выдает ответ, как интерпретировать нечеткие уровни Level Confirm и Level Reject по каждой уязвимости: Confirmed, Rejected или ERROR, согласно правилам однозначной интерпретации результатов нечеткой классификации уязвимостей (см. табл. 2).
Табл. 2. Правила однозначной интерпретации результатов нечеткой классификации уязвимостей
Использование правил позволяет дать четкий ответ в понятной человеку форме: уязвимость подтверждена, опровергнута или получен неоднозначный результат классификации — ошибка. В случае ошибки требуется ручная классификация. По аналогии с правилами табл. 1, уязвимости-кандидаты нужно считать отвергнутыми, если по результатам классификации нечеткий уровень Level Reject будет высоким (Max, High), а нечеткий уровень Level Confirm средним или низким (Med, Low, Min). Соответственно уязвимость будет подтверждена при противоположных результатах. Правила для подтвержденных уязвимостей также более строгие.
Результаты исследования
Работа с нейросетью включала в себя несколько этапов — обучение на эталонах и разбор уязвимостей в рабочем режиме на новых результатах сканирования.
Разбор уязвимостей в рабочем режиме состоял из двух этапов. Первый этап включал в себя ручной разбор данных сканирования и классификацию уязвимостей. На втором этапе разобранные уязвимости были предложены нейросети, которая ранее на них не обучалась, для анализа (одновременно и в качестве кандидатов для разбора уязвимостей, и в качестве эталонов).
В рабочем режиме, при классификации ранее неизвестных уязвимостей, нейросеть выдала следующие результаты: из 2998 проанализированных уязвимостей ошибочно классифицировала 595 (19.8%).
На данный момент удовлетворены все формальные требования со стороны отдела тестирования, и мы продолжаем работать над улучшением результатов классификации: оптимизируем параметры нейросети, отсеиваем «плохие» свойства из матрицы кодирования.
Полноценное использование всех преимуществ автоматической классификации уязвимостей при помощи нейросетей ожидается в начале 2016 года. Однако уже сейчас результаты разбора уязвимостей автоматически проставляются для уязвимостей в DBCA.
На рис. 7 приведен пример типичной записи об уязвимости из DBCA, для которой нейросеть сделала правильное предположение, что эту уязвимость, найденную сканером PT AI, нужно опровергнуть как ложное срабатывание. Об этом говорят значения полей: «Level Confirm: 5 – Min», «Level Reject: 1 — Max», «Notes: Interpreting as: Reject». Аналогичным образом проставляются результаты для всех остальных уязвимостей.
Рис. 7. Запись в DBCA с результатами нейросетевой классификации
Выражаю благодарность своим коллегам: QA-инженерам Positive Technologies Владимиру Софину и Артему Юшковскому за помощь в практической реализации некоторых инструментов и огромный вклад в проведение многочисленных экспериментов, а также доценту кафедры математического анализа, алгебры и геометрии, к. пед. н. Казанского (Приволжского) федерального университета Мансуру Гильмуллину за помощь в подготовке теоретической базы для исследований и экспериментов.
Автор: Тимур Гильмуллин, к. т. н., DevOps-инженер Positive Technologies.