В предыдущем посте были освещены основы автоматизации аудита информационной безопасности с использованием спецификации 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>
Итог
В посте раскрыты принятые, де-факто, стандарты формализации высокоуровневых требований к различного рода системам. Такая формализация позволяет проверять выполнение требований регуляторов, установленных политик и т.д. на постоянной основе, при этом возникает независимость от конкретных средств аудита.
Полезные материалы
Полные тексты разобранных документов на сайте 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>