Где-то в компании “Рельсы-рельсы, шпалы-шпалы”.

CISO: Игорь, кто-то получил доступ к нашим камерам на вокзалах.
Игорь: @@@!
CISO: Ступай, разберись. Проверь конфигурации каждой камеры, каждого компьютера.
Игорь: Но их же 100500+, это займет уйму времени!
CISO: Возьми в помощь Михалыча, нашего электрика, он в детстве радиокружок посещал.
Игорь: Может лучше попробуем SCAP?
CISO: А это что за…

Введение

Во многих документах (стандарты, приказы, рекомендации) определены требования к настройкам безопасности информационных систем, поиску уязвимостей и управлению обновлениями. Недавно обнаруженная проблема в одной из крупнейших корпораций еще раз показывает необходимость управления уязвимостями и конфигурациями.

Как правило, информационная система представляет собой сложный и динамичный объект, поэтому для выполнения соответствия требованиям необходим постоянный контроль ее состояния (аудит).

Дефакто методом автоматизации аудита безопасности является подход, предложенный NIST и описанный в спецификации SCAP (Security Content Automation Protocol).


Структурная схема процесса автоматизированного аудита безопасности информационных систем с использованием SCAP

Далее я предлагаю подробнее ознакомиться со всеми пунктами процесса автоматизации аудита. Поехали!

Требования

Истоком аудита, его основой и резоном являются высокоуровневые бумажные требования к информационным системам, которые предъявляются регуляторами, определены в лучших практиках, собственных политиках или политиках партнеров.

Так, например, в стандарте PCI DSS описаны требования поддержки конфигураций межсетевых экранов, обновления программ, регулярного тестирования систем безопасности, поддержки политик информационной безопасности.

В рекомендациях CIS Controls v. 7.1 представлены требования к непрерывному управлению уязвимостями (CIS Control 3), безопасной настройке аппаратного и программного обеспечения (CIS Control 5).

А в приказе ФСТЭК № 17 определены требования к защите информации, содержащейся в государственных информационных системах.

Главной проблемой всех требований и рекомендаций является их высокоуровневое неформализованное описание, не позволяющее их использовать в процессе автоматизации. Решение предложил NIST в 2009 году, разработав спецификацию SCAP.

SCAP

SCAP (Security Content Automation Protocol) – иерархическая спецификация, которая позволяет в отношении информационных систем производить автоматическую настройку, осуществлять поиск и исправление уязвимостей, а также оценивать уровень безопасности.

SCAP включает в себя ряд взаимосвязанных компонентов, формальное описание которых основано на XML: языки XCCDF, OVAL, OCIL, ARF; схемы идентификации CCE, CPE, SWID, CVE; метрики CVSS, CCSS.

Хотя другие компоненты спецификации также важны, основные — это языки XCCDF и OVAL.

XCCDF (Extensible Configuration Checklist Description Format) — язык, который описывает списки настроек безопасности информационных систем и определяет взаимосвязь остальных компонентов SCAP. Язык предназначен для обеспечения обмена информацией, генерации документов, автоматизированного тестирования и оценки соответствия заданным требованиям. Не содержит команд для выполнения сканирования.

OVAL (Open Vulnerability and Assessment Language) — декларативный язык логических утверждений о состоянии системы. Это основной компонент стандарта SCAP, который используется для описания уязвимостей и необходимой конфигурации системы.

Итак, SCAP-контент — это требования к информационным системам, которые переведены в формализованный вид, что дает возможность автоматизированной проверки систем на соответствие требованиям и поиска уязвимостей.

Детально XCCDF и OVAL разберу в следующей статье и оставлю здесь ссылку.

Вопрос. Где брать SCAP-контент?

• Создавать самому, что достаточно трудоемко и требует понимания спецификаций. Жизнь упрощает SCAP-редактор с открытым исходным кодом, который позволяет в удобном графическом интерфейсе создавать XCCDF и OVAL-документы.
• Пользоваться открытыми ресурсами. Например база OVAL-описаний от ФСТЭК, требования USGCB или репозиторий от MITRE.
• Покупать. При покупке некоторых коммерческих продуктов можно получить доступ к базам производителя.

Интерпретаторы

Формализованные требования в виде SCAP-контента являются входными данными так называемых интерпретаторов или сканеров, которых существует великое множество. MITRE ведет учет “авторизованных” организаций, выпускаемых ими продуктов и репозиториев OVAL.

Рассмотрим некоторые бесплатные интерпретаторы: OVALdi, OpenSCAP и ScanOVAL.

OVALdi

Интерпретатор разработан MITRE. Предназначен лишь для демонстрации оценки и проверки синтаксиса разрабатываемых OVAL-документов. Обладает минимальным функционалом для оценки информационных систем. Существует как для Windows, так и для Linux. Распространяется по BSD лицензии.

Управление OVALdi возможно только из командной строки и только локально, для чего нужно ввести команду с правами администратора:

ovaldi.exe -m -o "definitions.xml"

где m – не проверять целостность OVAL-документа, o – путь к OVAL-документу.

OpenSCAP

Проект компании Red Hat, представленный множеством продуктов, среди которых OpenSCAP Base – сканер с CLI интерфейсом и открытым исходным кодом и SCAP Workbench – сканер с GUI интерфейсом.

В следующей статье подробно расскажу про развертывание и использование бесплатной автоматизированной системы аудита от Red Hat и оставлю здесь ссылку.


Интерфейс SCAP Workbench

Несмотря на то, что средства OpenSCAP подходят для Windows, бОльшие возможности представлены для unix-подобных систем, т.к. изначально проект был направлен только на их оценку.

Интерпретатор запускается командой в терминале:

oscap oval eval "D:\definitions.xml" --report "D:\results.html",
после чего будет выполнена проверка системы по инструкциям в OVAL-документе «D:\definitions.xml» с сохранением результатов в файл «D:\results.html».

SvanOVAL

Средство, разработанное для ФСТЭК одной российской компанией. Средство бесплатное и подходит как для Windows, так и для Linux (Astra).


Интерфейс ScanOVAL

Главный недостаток состоит в том, что возможности средства ограничены лишь проверкой системы на уязвимости, которые представлены в базе ФСТЭК, при этом проверяется цифровая подпись OVAL-документа, так что кастомный файл скормить не получится. Несмотря на это, ScanOVAL — большой шаг ФСТЭК к небумажной безопасности.

SCAP-логика

Для упрощения многие нюансы не учтены, что принципов SCAP, в целом, не нарушает, но позволяет лучше понять сам подход.


Схема базовой логики SCAP

XCCDF-документ содержит профили, один из которых можно выбрать для проверки, например — поиск уязвимостей в Windows 10 или соответствие каким-то конкретным требованиям. Фактически профили содержат контрольные списки, которые должны быть проверены для определения того, соответствует ли система этому профилю.

Контрольные списки содержат описательную информацию — вербальные требования, рекомендации по устранению несоответствий, метрики оценки и т.д. Все это используется для вывода пояснений к результатам проверки.

Но главное, что содержит каждый элемент контрольного списка — это ссылка на конкретное определение в связанном OVAL-документе. После обработки OVAL-определения интерпретатор возвращает результат булева типа (true или false), на основе которого делается вывод о выполнении требования из контрольного списка.

В OVAL-документе определения формируют логическую связку из тестов, которые должны быть пройдены. Каждый тест с помощью логических операторов связывает объекты и состояния.

Тесты, объекты и состояния бывают различных типов, которых достаточно много. Именно их многообразие определяет широкие возможности спецификации SCAP.

Например для Windows, в числе прочих, существует тип group_sid (group_sid_test, group_sid_object и group_sid_state), который позволяет по SID идентификатору оценить пользователей и подгруппы. А тип dpkginfo для Linux позволяет проверить информацию о заданном DPKG пакете. Тип textfilecontent не зависит от системы и обеспечивает проверку содержимого текстового файла, например файла конфигураций.

Состояние в OVAL-документе задает требуемое значение параметра, который характеризует какой-то объект.

Интерпретатор при обработке теста, определяет значение параметра, характеризующее текущее состояние объекта и, в соответствии с указанной в тесте логикой, сравнивает его с заданным значением. На основе этого формируется результат теста булева типа.

В определении результаты каждого связанного теста также сравниваются в соответствии с заданной логикой, в результате чего вычисляется финальный результат, который характеризует выполнение конкретного требования из контрольного списка.

Например, если существует требование обеспечить неизменность исполняемых файлов, то при его переводе в SCAP-контент в качестве объекта будет задан конкретный исполняемый файл, который определяется полным именем: .../example.exe. Состояние будет задано требуемым значением хеш-суммы: D41...27E. Тест будет определять операцию сравнения: equal — равенство. При этом интерпретатор вычислит хеш-сумму файла .../example.exe и сравнит ее с заданной D41...27E. В случае их совпадения — вернет положительный результат.

Результаты

Согласно спецификации SCAP результаты аудита представляюстя в формате ARF (Asset Reporting Format).

Отчет в формате ARF содержится в XML-документе и включает описания профилей, требований из контрольных списков и итоговые результаты по каждому пункту из контрольного списка.

Как правило, результаты сканирования преобразуются к удобочитаемому виду.


Пример результатов проверки Windows 10 на наличие уязвимостей с помощью интерпретатора OVALdi

Исправление

Возможности протокола SCAP предполагают автоматическое исправление найденных несоответствий и устранение уязвимостей (функционал должен поддерживаться системой автоматизированного аудита).

Такой вариант кажется неплохим, но автоматические исправления могут нарушить работоспособность системы, поэтому использовать эти возможности нужно вдумчиво.

Наиболее распространен вариант, когда результаты проверки представлены перечнем невыполненных требований и текстовым описание действий, которые нужно выполнить для исправления. Например как в бесплатной версии CIS-CAT.


Пример результатов интерпретатора CIS-CAT Lite с рекомендациями по устранению

Заключение

Автоматизация аудита — важнейшая задача информационной безопасности, ее актуальность обусловлена количеством, сложностью и динамичностью систем, которые должны соответствовать определенным требованиям.

SCAP предоставляет гибкую и многогранную методологию автоматизации, которая, однако, имеет недостатки:

• сложность перевода высокоуровневых вербальных требований в формализованный SCAP-контент;
• сложность создания интерпретаторов, позволяющих использовать весь потенциал спецификации SCAP.

С другой стороны, с точки зрения конечного пользователя, средства SCAP это простой и эффективный инструмент, который позволяет сократить временные затраты и повысить уровень безопасности администрируемой инфраструктуры.