В предыдущем посте были освещены основы автоматизации аудита информационной безопасности с использованием спецификации SCAP, для дальнейшего понимания рекомендую с ним ознакомиться.
SCAP — иерархическая спецификация, разработанная NIST в 2009 году, которая позволяет автоматизировать аудит информационной безопасности, предоставляя инструмент перевода высокоуровневых требований в формализованный вид, понятный для SCAP-интерпретаторов (сканеров).
Основу SCAP составляют языки XCCDF и OVAL
Далее на основе Benchmark от CIS (аудит Windows 7), попробуем разобрать структуру и понять логику образования документов XCCDF и OVAL. Некоторые детали я намеренно опущу, что позволит упростить изложение и понимание, но базовой логики не нарушит.
Погнали!
Extensible Configuration Checklist Description Format
XCCDF — язык, который описывает списки настроек безопасности информационных систем и определяет взаимосвязь остальных компонентов SCAP. Язык предназначен для обеспечения обмена информацией, генерации документов, автоматизированного тестирования и оценки соответствия заданным требованиям. Не содержит команд для выполнения сканирования.
Последняя версия спецификации XCCDF разработана NIST в 2012 году.
Структурно документ XCCDF состоит из групп groups, правил rules и значений values, которые содержаться в таком элементе документа, как эталоне benchmark.
Эталон (Benchmark)
Эталон в документе XCCDF всегда содержится в единственном экземпляре. Фактически, эталон — контейнер для других элементов документа.
В первую очередь в эталоне указана общая информация о документе — ссылки на различные источники, сведения о дате создания, заголовок, описание и т.д. Из примера ниже понятно, что документ предназначен для аудита Windows 7 по требованиям STIG.
<Benchmark>
<title>Win7 Audit</title>
<description>"The Windows 7 Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements were developed from DoD consensus, as well as the Windows 7 Security Guide and security templates published by Microsoft Corporation."</description>
--- data omitted ---
</Benchmark>Как правило, эталон содержит одну или более группы, которые, в свою очередь, содержат правила, значения и дополнительные дочерние группы. Группы лишь обеспечивают удобную компоновку связанных правил и значений и не оказывают влияния на логику документа.
Важнейшим смысловым элементом эталона, а соответственно документа XCCDF, являются профили.
Профиль (Profile)
Профиль представляет собой набор из групп, правил, значений и т.д. Служит для компоновки элементарных требований под какой-либо конкретный стандарт или политику, например «Audit and Audit Log Checks» («Аудит и аудит журналов»).
В примере ниже представлен профиль требований STIG для класса систем MAC III - Administrative Sensitive (к нам эти требования никакого отношения не имеют, но могут использоваться как источник best practice). В примере профиль содержит ссылку только на одну группу idref="V-15706″, хотя в реальном документе их может быть несколько.
Прошу обратить внимание и запомнить (понадобится далее), что при ссылке на группу также указано selected="true". Это означает, что требования из этой группы должны быть проверены при аудите по профилю MAC-3_Sensitive.
<Profile id="MAC-3_Sensitive">
<title>"III - Administrative Sensitive"</title>
<description>"ProfileDescription"</description>
<select idref="V-15706" selected="true"/>
</Profile>Группы имеют различные служебные поля, предоставляющие общую информацию. Так из примера ниже понятно, что группа idref="V-15706" имеет отношение к управлению питанием (Power Mgmt).
Помимо различных служебных полей, группы имеют в своем составе перечень правил. В примере ниже группа имеет ссылку на одно правило SV-25168r1_rule.
<Group id="V-15706">
<title>Power Mgmt – Password Wake When Plugged In</title>
<description>GroupDescription</description>
<Rule id="SV-25168r1_rule">
--- data omitted ---
</Rule>
</Group>Правило (Rule)
Правило также имеет различные информационные поля. Например, в поле описания правилаSV-25168r1_rule, из примера ниже, указано, что правило предназначено для проверки того, запрашивается ли у пользователя пароль при возобновлении работы из спящего режима.
<Rule id="SV-25168r1_rule">
<title>"Password is required on resume from sleep (plugged in)."</title>
<description>"This check verifies that the user is prompted for a password on resume from sleep (Plugged In)"</description>
<fixtext>"Configure the policy value for Computer Configuration - Administrative Templates > System > Power Management > Sleep Settings “Require a Password When a Computer Wakes (Plugged In)” to “Enabled”."</fixtext>
<check>
<check-export value-id="password-require" export-name="var:381700"/>
<check-content-ref name="def:3817"/>
</check>
</Rule>Также правило может содержать информацию о том, что нужно делать, если оно не выполняется. В примере выше в поле fixtext указано, что для исправления несоответствия нужно установить значение «Enabled» в Administrative Templates > System > Power Management > Sleep Settings "Require a Password When a Computer Wakes (Plugged In).
Главное, что содержит правило — это различные ссылки.
В примере выше указаны ссылки на переменные: переменная password-require внутри документа; экспортируемая переменная var:381700, а также ссылка на определение в связанном документе OVAL: def:3817.
Обо всем по порядку.
Переменная (Value)
<Value id="password-require" operator="equals">
<value>1</value>
<value selector="disabled">0</value>
<value selector="enabled">1</value>
</Value>Внутренняя переменная документа XCCDF в примере выше имеет значение по умолчанию 1. Теперь вспомните, что в профиле при ссылке на группу было указано selected="true". Этот указатель используется для включения или исключения соответствующих групп и правил из проверки, что обеспечивается за счет присвоения переменной нужного значения.
Если selected="true" и operator="equals", то переменной присваивается значение 1.
Значение внутренней переменной password-require, через экспортируемую переменную var:381700 передается в связанный документ OVAL.
Таким образом, перед обработкой документа OVAL, интерпретатор хранит ряд значений. В примере выше интерпретатор хранит в памяти значение экспортируемой переменной var:381700 = 1 и ссылку на определение OVAL — def:3817.
Open Vulnerability and Assessment Language
OVAL (Open Vulnerability and Assessment Language) — декларативный язык логических утверждений о состоянии системы. Это основной компонент стандарта SCAP, который используется для описания уязвимостей и необходимой конфигурации системы.
Структурно документ OVAL состоит из определений definition, критериев criteria, тестов test, объектов object и состояний state.
Определение (Definition)
Определения являются основными логическими блоками документа.
Как видно из рисунка выше, определения включают критерии — выражения, которые с помощью булевой логики (И, ИЛИ, НЕ) позволяют оценить результаты тестов. Учитывая, что тесты возвращают результаты булева типа (true/false), определения также будут возвращать результаты булева типа.
В примере ниже в блоке criteria задан логический оператор «И» (operator="AND"). В этом случае он не играет никакой роли, поскольку содержится ссылка всего лишь на один тест tst:381700.
Определение может содержать множество вложенных критериев и тестов, что позволяет создавать достаточно сложные логические выражения, а соответственно формализовать комплексные высокоуровневые требования.
<definition id="def:3817" class="compliance">
<metadata>
<title>"Require a Password when a Computer Wakes (Plugged)"</title>
<affected family="windows">
<platform>Microsoft Windows 7</platform>
</affected>
<description>"Require a Password when a Computer Wakes (Plugged)"</description>
</metadata>
<criteria operator="AND">
<criterion test_ref="tst:381700"/>
</criteria>
</definition>Тест (Test)
Главная задача тестов — логическая связь объектов и требуемых состояний.
Объекты, тесты и состояния бывают различных типов, которые зависят от аудируемой системы.
Так например для Windows, в числе прочих, существует тип group_sid (group_sid_test, group_sid_object и group_sid_state), который позволяет по SID идентификатору оценить пользователей и подгруппы. А тип dpkginfo для Linux позволяет проверить информацию о заданном DPKG пакете. Тип textfilecontent не зависит от системы и обеспечивает проверку содержимого текстового файла, например файла конфигураций.
В примере ниже указан тип registry, который позволяет работать с записями реестра в Windows.
Тест registry_test ссылается на объект obj:381700 и состояние ste:381700, при этом для получения результатов теста необходимо проверить все указанные объекты (check="all"), при этом в системе хотя бы один должен существовать(check_existence="at_least_one_exists").
<registry_test id="tst:381700" check_existence="at_least_one_exists" check="all">
<object object_ref="obj:381700"/>
<state state_ref="ste:381700"/>
</registry_test>Объект (Object)
В качестве объекта в системе может выступать практически что угодно. Перечень возможных объектов задан спецификацией OVAL. Например объектом может быть запись в реестре registry_object, идентификатор пользователя и его маркер доступа accesstoken_object, набор событий аудита audit_event_policy_object и многие другие.
В примере ниже registry_object задан указателем на конкретное значение в реестре Windows: HKEY LOCAL MACHINE > Software\Policies\Micro… > ACSettingIndex.
<registry_object id="obj:381700">
<hive datatype="string">HKEY_LOCAL_MACHINE</hive>
<key datatype="string">Software\Policies\Microsoft\Power\PowerSettings\0e796bdb-100d-47d6-a2d5-f7d2daa51f51</key>
<name datatype="string">ACSettingIndex</name>
</registry_object>Состояние (State)
Этот компонент задает требуемое состояние объекта. В примере ниже состояние не указано непосредственно, а лишь дана ссылка на переменную var:381700.
Каждый тип объекта обладает определенной спецификой, поэтому объекты, тесты и состояния должны быть одного типа. Например объект registry_object возможно сравнивать только с состоянием registry_state с помощью теста registry_test.
<registry_state id="ste:381700">
<type>reg_dword</type>
<value datatype="int" var_ref="var:381700"/>
</registry_state>Переменная (Variable)
Переменная хранит какое-то значение. Значение может быть задано статически или определяться динамически экспортируемыми значениями из документа XCCDF.
В примере ниже экспортируемая из документа XCCDF переменная имеет значение, равное единице.
<external_variable id="var:381700">
<possible_value hint="disabled">0</possible_value>
<possible_value hint="enabled">1</possible_value>
</external_variable>Итог
В посте раскрыты принятые, де-факто, стандарты формализации высокоуровневых требований к различного рода системам. Такая формализация позволяет проверять выполнение требований регуляторов, установленных политик и т.д. на постоянной основе, при этом возникает независимость от конкретных средств аудита.
Полезные материалы
Спецификация SCAP
Спецификация XCCDF
Спецификация OVAL
Полные тексты разобранных документов на сайте CIS
Автоматизация аудита информационной безопасности или SCAP ликбез
P.S.
Все рассмотренные документы в сборе под катом.
Win7Audit_Benchmark-xccddf.xml
<Benchmark>
<title>Win7 Audit</title>
<description>The Windows 7 Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements were developed from DoD consensus, as well as the Windows 7 Security Guide and security templates published by Microsoft Corporation.</description>
<Profile id="MAC-3_Sensitive">
<title>III - Administrative Sensitive</title>
<description>ProfileDescription</description>
<select idref="V-15706" selected="true"/>
</Profile>
<Group id="V-15706">
<title>Power Mgmt – Password Wake When Plugged In</title>
<description>GroupDescription</description>
<Rule id="SV-25168r1_rule">
<title>Password is required on resume from sleep (plugged in).</title>
<description>This check verifies that the user is prompted for a password on resume from sleep (Plugged In)</description>
<fixtext>Configure the policy value for Computer Configuration - Administrative Templates > System > Power Management > Sleep Settings “Require a Password When a Computer Wakes (Plugged In)” to “Enabled”.</fixtext>
<check>
<check-export value-id="require_a_password_when_a_computer_wakes_plugged_var" export-name="var:381700"/>
<check-content-ref name="def:3817"/>
</check>
</Rule>
</Group>
<Value id="password-require" operator="equals">
<value>1</value>
<value selector="disabled">0</value>
<value selector="enabled">1</value>
</Value>
</Benchmark>Win7Audit_Benchmark-oval.xml
<oval_definitions>
<definitions>
<definition id="def:3817" class="compliance">
<metadata>
<title>Require a Password when a Computer Wakes (Plugged)</title>
<affected family="windows">
<platform>Microsoft Windows 7</platform>
</affected>
<description>Require a Password when a Computer Wakes (Plugged)</description>
</metadata>
<criteria operator="AND">
<criterion test_ref="tst:381700"/>
</criteria>
</definition>
</definitions>
<tests>
<registry_test id="tst:381700" check_existence="at_least_one_exists" check="all">
<object object_ref="obj:381700"/>
<state state_ref="ste:381700"/>
</registry_test>
</tests>
<objects>
<registry_object id="obj:381700">
<hive datatype="string">HKEY_LOCAL_MACHINE</hive>
<key datatype="string">Software\Policies\Microsoft\Power\PowerSettings\0e796bdb-100d-47d6-a2d5-f7d2daa51f51</key>
<name datatype="string">ACSettingIndex</name>
</registry_object>
</objects>
<states>
<registry_state id="ste:381700">
<type>reg_dword</type>
<value datatype="int" var_ref="var:381700"/>
</registry_state>
</states>
<variables>
<external_variable id="var:381700">
<possible_value hint="disabled">0</possible_value>
<possible_value hint="enabled">1</possible_value>
</external_variable>
</variables>
</oval_definitions>
