Введение
С чего начинается обеспечение безопасности? Для всех этот вопрос звучит по разному и заурядный пользователь скорее всего скажет, что с надежного и качественного пароля к учетным записям. Но если рассматривать проблему немного шире и с точки зрения специалиста в сфере ИБ, то ответ будет куда интереснее. Первым делом это обновление баз антивирусного ПО и слежение за новыми уязвимостями. Чаще всего именно с помощью свежих дыр в безопасности хакеры проникают в сети крупных компаний. Чтобы этого избежать, я предлагаю рассмотреть тебе такую тему как аудит информационной безопасности. Ключевое слово из этой темы спрятано в заголовке статьи.
План работы
Для начала давай разберем все по пунктам. Первым делом я расскажу теорию. Что такое SCAP, зачем он нужен и что он делает в информационной безопасности. После этого плавно перейдем к языкам программирования. Ты не ослышался, в сфере безопасности существуют специализированные скрипты на особых языках, цель которых автоматизировать некоторые процессы. Я не буду рассказывать обо всех, а затрону только два из них. Сделано это для того, чтобы не напрягать твой мозг избытком информации. Далее мы рассмотрим их синтаксис и работу, которая будет не сложнее чем написание фишинговых сайтов на html. В конце подведем итог всей работы и посмотрим, что у нас получилось.
Основы автоматизации
Начну немного издалека. В каждой компании для защиты информации и сохранения конфиденциальности данных должен быть отдел специалистов в сфере информационной безопасности. Но кроме этого должны быть те, кто эту безопасность тестируют. Отсюда и пришло разделение специалистов на Blue и Red Team. Если копать в сторону синих, то отдел, который занимается защитой называется SOC. Чтобы ты не запутался в тексте ниже я оставил полную расшифровку термина:
Центр управления безопасностью (Security Operations Center, SOC) - отвечает за защиту организации от киберугроз. Аналитики SOC осуществляют круглосуточный мониторинг сети организации и расследуют любые потенциальные инциденты безопасности.
Чтобы обеспечить саму безопасность помимо расследования инцидентов требуется мониторинг всех известных уязвимостей для их закрытия. Для сокращения этого процесса и его упрощения был создан SCAP. Познакомимся с этой аббревиатурой по ближе:
Протокол автоматизации управления данными безопасности (SCAP) — набор открытых стандартов, определяющих технические спецификации для представления и обмена данными по безопасности. Эти данные могут быть использованы для нескольких целей, включая автоматизацию процесса поиска уязвимостей, оценки соответствия технических механизмов контроля и измерения уровня защищенности. Правительство, совместно с научными и коммерческими организациями, использует и поддерживает распространение SCAP.
Сам SCAP является лишь частью огромной программы автоматизации ИБ (ISAP) и состоит он из следующих стандартов:
Открытый язык описания и оценки уязвимостей (Open Vulnerability and Assessment Language, OVAL) - это международный стандарт по информационной безопасности. Он включает в себя как сам язык, так и репозитории контента. OVAL стандартизует 3 основных компонента процесса оценки: представление конфигурационной информации для системы, анализ системы на предмет наличия состояний (уязвимости, обновления, конфигурации и т.д), представление отчётов по оценке системы.
Особенности этого языка в том, что он составляет детальный отчет безопасности и использует формальный язык, который может легко понять как человек, так и машина. На основе этих двух переменных мы получаем все проблемы безопасности и понимание ошибок, которые к этому приводят. Кроме этого существует еще один язык - XCCDF. Его главная цель проводить проверки и создавать правила, которые будут ссылаться на другие XML документы. Говоря более официально, то:
Формат описания расширяемого контрольного списка конфигурации (Extensible Configuration Checklist Description Format, XCCDF) - это формат XML, определяющий контрольные списки безопасности, эталонные тесты и документацию по конфигурации. Также это важный инструмент для специалистов, связанных с автоматизацией процессов информационной безопасности. На этом языке описаны, к примеру, обязательные требования по настройке рабочих станций федеральных агентств США и их контрагентов.
Говоря проще XCCDF создает набор требований к безопасности, а OVAL эти требования реализует с использованием интерпретаторов. Требования, которые преобразовали в инструкции для интерпретатора, называют SCAP-контентом. Создается такой материал при помощи редакторов, поскольку вручную это занимает огромное количество времени, ну а дальше при помощи интерпретаторов OVAL это реализуется. Ниже я расписал несколько программ, которые помогут тебе создавать контент на твоем устройстве.
Также, чтобы ты не запутался в различие OVAL и XCCDF ниже я оставил небольшую таблицу. Она позволяет детальнее понять работу SCAP-логики и увидеть различия между созданием контента и его реализацией.
В XCCDF документе мы создаем правило и профиль, по которому будет проводится проверка. К примеру: "Проверка пароля на наличие символов и цифр". Таким образом в документе формируется контент, который содержит в себе уже готовые ссылки на OVAL-документы. В нем происходит проверка требований безопасности при помощи флагов и переменных. На месте звездочек у нас стоит название документов. Теперь давай разберемся как создавать контент с применением языка XCCDF и OVAL.
Создание контента
Начнем наше погружение с создание правил. Я буду использовать сторонний код, чтобы наглядно разобрать синтаксис и продемонстрировать как это работает. На основе всех примеров ты сможешь создавать свои правила и интерпретировать их с помощью утилит в машинный код. Как говорилось ранее за все это дело у нас отвечает XCCDF, который берет ссылки из OVAL-документов и создает формальный код, понятный человеку. Давай посмотрим как это выглядит:
В правиле мы используем ссылку на OVAL-документ с названием usgcb-rhel5desktop-oval.xml и вызываем оттуда идентификатор gov.nist.usgcb.rhel:def:20071 для проверки. Передача требуемого значения проверяемого параметра осуществляется через переменные. Значение переменной usgcb-rhel5desktop-var-2.3.1.7.a передается в наш вызванный идентификатор. Заголовок правила также содержит номер проверки (ССЕ-4154-1). Параметр weight, который с английского переводится как вес отвечает за значимость данного правила. По умолчанию она всегда равна одному. Это используются при расчете итоговой метрики, определяющей соответствие состояния системы требованиям стандарта. Кроме этого все правила подлежат нумерации, которые повторяют ее из "бумажного" стандарта. Более подробно я не стану затрагивать этот момент, поскольку он займет очень много времени. На нашем примере главное правило имеет номер 2.3.1.7, далее используются подразделения, которые включают в себя английский алфавит. То есть после ID 2.3.1.7.a должен следовать 2.3.1.7.b.
Более подробно разберем момент с профилями. Их основная задача это описание нескольких политик внутри одного XCCDF-документа. На коде все выглядит следующим образом:
Таким образом, в профиле "united_states_government_configuration_baseline" должно выполняться правило 2.3.1.7.a с селектором 12. Также профиль объединяет требования конкретного стандарта или политики и содержит ссылки на группы. Выше этого стоит эталон. Это контейнер для групп, правил и значений. В документе XCCDF эталон содержится в одном экземпляре поэтому документ и эталон тождественны. Ниже я предоставил полную иерархию этой структуры. Документы XCCDF и OVAL связаны при помощи двух вещей: ссылки на конкретные определения и экспортируемые переменные.
После работы с XCCDF файлом это все дело следует обработать в OVAL-документе. Для начала давай рассмотрим схему построения документа, ее я оставил ниже.
Определение является главным элементом из которого вытекают последующие (метаданные, критерии и тесты). Он задается в самом начале документа и содержит ID переменной вместе с ее классом.
Следом за ним идут метаданные и критерии. Первый элемент служит описанием уязвимости. В метаданные входит платформа, заголовок и описание. После идет критерий, который подразумевает под собой логическое выражение. Оно с помощью булевой логики (И, ИЛИ, НЕ) оценивает результаты включенных тестов. Далее располагается ссылка на требуемый тест.
Тесты в нашей иерархии возвращают булевое значение. Если ты помнишь оно может быть отрицательным (false) и положительным (true). Для наглядности ниже я привел код, который требует пароль при выходе компьютера из спящего режима:
Теперь давай разберем более подробно каждый элемент (тесты, объекты и состояние). Они бывают различных типов, которые определяются спецификацией и зависят от проверяемой системы.
Тесту registry_test присваивается ID, которое равно tst:381700, после этого задается условие at_least_one_exists, оно отвечает за то, чтобы хотя бы один объект существовал. После даем на проверку все элементы и задаем их в коде. Таким образом наш тест ссылается на объект с названием obj:381700 и его статусом ste:381700.
Наше состояние определяется через переменную var:381700. Также каждый объект специфичен и это значит, что объект registry_object возможно сравнить только с состоянием registry_state с помощью теста registry_test.
В коде мы даем два значение нашей переменной - активное и пассивное. Оно соответственно равно нулю и единице.
Теперь, после всех махинаций и необходимых введений ты можешь спокойно работать с SCAP-контентом и создавать правила под требуемые уязвимости. Дальше только интереснее, но к сожалению пора подвести итог нашей работы.
Подводим итоги
Сама работа с таким видом контента очень сложна в понимании, но проста на практике. Поэтому из главных особенностей ты должен знать структуру языков OVAL и XCCDF, а также разбираться в построении. Что откуда берется и зачем нужно. Кроме такой утомительной лекции по SCAP я рекомендую тебе прочесть введение в OVAL и миф об идеальном сканере. С этим ты ознакомишься уже на просторах Хабра. В остальном я постарался выдать максимально простой и понятный гайд о том, как работать с таким типом документов.
С чего начинается обеспечение безопасности? Для всех этот вопрос звучит по разному и заурядный пользователь скорее всего скажет, что с надежного и качественного пароля к учетным записям. Но если рассматривать проблему немного шире и с точки зрения специалиста в сфере ИБ, то ответ будет куда интереснее. Первым делом это обновление баз антивирусного ПО и слежение за новыми уязвимостями. Чаще всего именно с помощью свежих дыр в безопасности хакеры проникают в сети крупных компаний. Чтобы этого избежать, я предлагаю рассмотреть тебе такую тему как аудит информационной безопасности. Ключевое слово из этой темы спрятано в заголовке статьи.
Для начала давай разберем все по пунктам. Первым делом я расскажу теорию. Что такое SCAP, зачем он нужен и что он делает в информационной безопасности. После этого плавно перейдем к языкам программирования. Ты не ослышался, в сфере безопасности существуют специализированные скрипты на особых языках, цель которых автоматизировать некоторые процессы. Я не буду рассказывать обо всех, а затрону только два из них. Сделано это для того, чтобы не напрягать твой мозг избытком информации. Далее мы рассмотрим их синтаксис и работу, которая будет не сложнее чем написание фишинговых сайтов на html. В конце подведем итог всей работы и посмотрим, что у нас получилось.
Основы автоматизации
Начну немного издалека. В каждой компании для защиты информации и сохранения конфиденциальности данных должен быть отдел специалистов в сфере информационной безопасности. Но кроме этого должны быть те, кто эту безопасность тестируют. Отсюда и пришло разделение специалистов на Blue и Red Team. Если копать в сторону синих, то отдел, который занимается защитой называется SOC. Чтобы ты не запутался в тексте ниже я оставил полную расшифровку термина:
Центр управления безопасностью (Security Operations Center, SOC) - отвечает за защиту организации от киберугроз. Аналитики SOC осуществляют круглосуточный мониторинг сети организации и расследуют любые потенциальные инциденты безопасности.
Чтобы обеспечить саму безопасность помимо расследования инцидентов требуется мониторинг всех известных уязвимостей для их закрытия. Для сокращения этого процесса и его упрощения был создан SCAP. Познакомимся с этой аббревиатурой по ближе:
Протокол автоматизации управления данными безопасности (SCAP) — набор открытых стандартов, определяющих технические спецификации для представления и обмена данными по безопасности. Эти данные могут быть использованы для нескольких целей, включая автоматизацию процесса поиска уязвимостей, оценки соответствия технических механизмов контроля и измерения уровня защищенности. Правительство, совместно с научными и коммерческими организациями, использует и поддерживает распространение SCAP.
Сам SCAP является лишь частью огромной программы автоматизации ИБ (ISAP) и состоит он из следующих стандартов:
- Уязвимости и ошибки конфигурации;
- Список типовых конфигураций и платформ;
- Единая система определения величины уязвимостей;
- Расширяемый формат описания списка проверки конфигурации;
- Открытый язык описания уязвимостей и оценки.
Открытый язык описания и оценки уязвимостей (Open Vulnerability and Assessment Language, OVAL) - это международный стандарт по информационной безопасности. Он включает в себя как сам язык, так и репозитории контента. OVAL стандартизует 3 основных компонента процесса оценки: представление конфигурационной информации для системы, анализ системы на предмет наличия состояний (уязвимости, обновления, конфигурации и т.д), представление отчётов по оценке системы.
Особенности этого языка в том, что он составляет детальный отчет безопасности и использует формальный язык, который может легко понять как человек, так и машина. На основе этих двух переменных мы получаем все проблемы безопасности и понимание ошибок, которые к этому приводят. Кроме этого существует еще один язык - XCCDF. Его главная цель проводить проверки и создавать правила, которые будут ссылаться на другие XML документы. Говоря более официально, то:
Формат описания расширяемого контрольного списка конфигурации (Extensible Configuration Checklist Description Format, XCCDF) - это формат XML, определяющий контрольные списки безопасности, эталонные тесты и документацию по конфигурации. Также это важный инструмент для специалистов, связанных с автоматизацией процессов информационной безопасности. На этом языке описаны, к примеру, обязательные требования по настройке рабочих станций федеральных агентств США и их контрагентов.
Говоря проще XCCDF создает набор требований к безопасности, а OVAL эти требования реализует с использованием интерпретаторов. Требования, которые преобразовали в инструкции для интерпретатора, называют SCAP-контентом. Создается такой материал при помощи редакторов, поскольку вручную это занимает огромное количество времени, ну а дальше при помощи интерпретаторов OVAL это реализуется. Ниже я расписал несколько программ, которые помогут тебе создавать контент на твоем устройстве.
Ссылка скрыта от гостей
- консольное приложение для демонстрации оценки и проверки синтаксиса OVAL-документов. Поддерживает такие платформы как Linux и Windows. Распространяется по лицензии BSD. Управление выполняется только локально.
Ссылка скрыта от гостей
- представляет собой сборник продуктов, который включает в себя сканер с CLI и GUI интерфейсами и открытым исходным кодом. Поддерживает операционные системы Windows и Linux, но большинство функций раскрываются на unix-подобных системах.
Ссылка скрыта от гостей
- утилита, которая была создана русскими разработчиками. Основной целью является анализ OVAL-документов и их представление в виде таблицы. Есть GUI интерфейс и возможность работы на разных платформах (Windows, Astra Linux). Главным недостатком становится проверка только на уязвимости из БДУ ФСТЭК. При этом проверяется цифровая подпись файла.Также, чтобы ты не запутался в различие OVAL и XCCDF ниже я оставил небольшую таблицу. Она позволяет детальнее понять работу SCAP-логики и увидеть различия между созданием контента и его реализацией.
В XCCDF документе мы создаем правило и профиль, по которому будет проводится проверка. К примеру: "Проверка пароля на наличие символов и цифр". Таким образом в документе формируется контент, который содержит в себе уже готовые ссылки на OVAL-документы. В нем происходит проверка требований безопасности при помощи флагов и переменных. На месте звездочек у нас стоит название документов. Теперь давай разберемся как создавать контент с применением языка XCCDF и OVAL.
Создание контента
Начнем наше погружение с создание правил. Я буду использовать сторонний код, чтобы наглядно разобрать синтаксис и продемонстрировать как это работает. На основе всех примеров ты сможешь создавать свои правила и интерпретировать их с помощью утилит в машинный код. Как говорилось ранее за все это дело у нас отвечает XCCDF, который берет ссылки из OVAL-документов и создает формальный код, понятный человеку. Давай посмотрим как это выглядит:
XML:
<Rule id="usgcb-rhel5desktop-rule-2.3.1.7.a" selected="false" weight="10.0" prohibitChanges="false" abstract="false" hidden="false" role="full" severity="unknown">
<status date="2010-07-01">accepted</status>
<version update="1"/>
<title override="0">CCE-4154-1:Set password minimum length</title>
<description xml:lang="en-US" override="0">The password minimum length should be set appropriately</description>
<ident system="cce.mitre.org">CCE-4154-1</ident>
<check system="oval.mitre.org/XMLSchema/oval-definitions-5" selector="">
<check-export value-id="usgcb-rhel5desktop-var-2.3.1.7.a" export-name="oval:gov.nist.usgcb.rhel:var:20071"/>
<check-content-ref href="usgcb-rhel5desktop-oval.xml" name="oval:gov.nist.usgcb.rhel:def:20071"/>
</check>
</Rule>В правиле мы используем ссылку на OVAL-документ с названием usgcb-rhel5desktop-oval.xml и вызываем оттуда идентификатор gov.nist.usgcb.rhel:def:20071 для проверки. Передача требуемого значения проверяемого параметра осуществляется через переменные. Значение переменной usgcb-rhel5desktop-var-2.3.1.7.a передается в наш вызванный идентификатор. Заголовок правила также содержит номер проверки (ССЕ-4154-1). Параметр weight, который с английского переводится как вес отвечает за значимость данного правила. По умолчанию она всегда равна одному. Это используются при расчете итоговой метрики, определяющей соответствие состояния системы требованиям стандарта. Кроме этого все правила подлежат нумерации, которые повторяют ее из "бумажного" стандарта. Более подробно я не стану затрагивать этот момент, поскольку он займет очень много времени. На нашем примере главное правило имеет номер 2.3.1.7, далее используются подразделения, которые включают в себя английский алфавит. То есть после ID 2.3.1.7.a должен следовать 2.3.1.7.b.
Более подробно разберем момент с профилями. Их основная задача это описание нескольких политик внутри одного XCCDF-документа. На коде все выглядит следующим образом:
XML:
<Profile id="united_states_government_configuration_baseline" abstract="false" prohibitChanges="false">
<title xml:lang="en-US" override="0">United States Government Configuration Baseline 1.0.5.0</title>
<description xml:lang="en-US" override="0">This profile represents guidance outlined in United States Government Configuration Baseline for desktop systems with Redhat Enterprise Linux 5 installed.</description>
…
<select idref="usgcb-rhel5desktop-rule-2.3.1.7.a" selected="true"/>
<refine-value idref="usgcb-rhel5desktop-var-2.3.1.7.a" selector="12"/>
…
</Profile>Таким образом, в профиле "united_states_government_configuration_baseline" должно выполняться правило 2.3.1.7.a с селектором 12. Также профиль объединяет требования конкретного стандарта или политики и содержит ссылки на группы. Выше этого стоит эталон. Это контейнер для групп, правил и значений. В документе XCCDF эталон содержится в одном экземпляре поэтому документ и эталон тождественны. Ниже я предоставил полную иерархию этой структуры. Документы XCCDF и OVAL связаны при помощи двух вещей: ссылки на конкретные определения и экспортируемые переменные.
После работы с XCCDF файлом это все дело следует обработать в OVAL-документе. Для начала давай рассмотрим схему построения документа, ее я оставил ниже.
Определение является главным элементом из которого вытекают последующие (метаданные, критерии и тесты). Он задается в самом начале документа и содержит ID переменной вместе с ее классом.
Следом за ним идут метаданные и критерии. Первый элемент служит описанием уязвимости. В метаданные входит платформа, заголовок и описание. После идет критерий, который подразумевает под собой логическое выражение. Оно с помощью булевой логики (И, ИЛИ, НЕ) оценивает результаты включенных тестов. Далее располагается ссылка на требуемый тест.
Тесты в нашей иерархии возвращают булевое значение. Если ты помнишь оно может быть отрицательным (false) и положительным (true). Для наглядности ниже я привел код, который требует пароль при выходе компьютера из спящего режима:
XML:
<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>Теперь давай разберем более подробно каждый элемент (тесты, объекты и состояние). Они бывают различных типов, которые определяются спецификацией и зависят от проверяемой системы.
- Тесты - сопоставляют текущее состояние объекта с требуемым. Для этого он взаимодействует с объектом (флаг object_ref) и его состоянием (флаг state_ref). Давай рассмотрим работу тестов на примере.
XML:
<registry_test id="tst:381700" check_existence="at_least_one_exists" check="all">[/INDENT][/INDENT]
[INDENT=2][INDENT=2] <object object_ref="obj:381700"/>[/INDENT][/INDENT]
[INDENT=2][INDENT=2] <state state_ref="ste:381700"/>[/INDENT][/INDENT]
[INDENT=2][INDENT=2]</registry_test>Тесту registry_test присваивается ID, которое равно tst:381700, после этого задается условие at_least_one_exists, оно отвечает за то, чтобы хотя бы один объект существовал. После даем на проверку все элементы и задаем их в коде. Таким образом наш тест ссылается на объект с названием obj:381700 и его статусом ste:381700.
- Объекты - элементы, в перечень которых входят записи в реестре, идентификаторы пользователя и маркеры доступа, события аудита и т.д. На коде они выглядят таким образом.
XML:
<registry_object id="obj:381700">[/INDENT][/INDENT]
[INDENT=2][INDENT=2] <hive datatype="string">HKEY_LOCAL_MACHINE</hive>[/INDENT][/INDENT]
[INDENT=2][INDENT=2] <key datatype="string">Software\Policies\Microsoft\Power\PowerSettings\0e796bdb-100d-47d6-a2d5-f7d2daa51f51</key>[/INDENT][/INDENT]
[INDENT=2][INDENT=2] <name datatype="string">ACSettingIndex</name>[/INDENT][/INDENT]
[INDENT=2][INDENT=2]</registry_object>
В примере объекту registry_object мы передаем конкретное значение из реестра Windows. Оно задается при помощи флага datetype, где мы указываем тип элемента внутри и тем самым формируем строку для получения конкретного значения из файла ACSettingIndex.- Состояние - это компонент, который задает требуемое состояние объекта. Оно может быть статичным или определяться через переменную. Ниже я взял пример с адресацией на наш тест и взятие из него нужной информации.
XML:
<registry_state id="ste:381700">[/INDENT][/INDENT]
[INDENT=2][INDENT=2] <type>reg_dword</type>[/INDENT][/INDENT]
[INDENT=2][INDENT=2] <value datatype="int" var_ref="var:381700"/>[/INDENT][/INDENT]
[INDENT=2][INDENT=2]</registry_state>Наше состояние определяется через переменную var:381700. Также каждый объект специфичен и это значит, что объект registry_object возможно сравнить только с состоянием registry_state с помощью теста registry_test.
- Переменная - хранит некоторое значение, которое задается статически или определяется динамически из XCCDF. Ниже показан пример со значением переменной var:381700, которая экспортирована из XCCDF и равна единице.
XML:
<external_variable id="var:381700">[/INDENT][/INDENT]
[INDENT=2][INDENT=2]<possible_value hint="disabled">0</possible_value>[/INDENT][/INDENT]
[INDENT=2][INDENT=2] <possible_value hint="enabled">1</possible_value>[/INDENT][/INDENT]
[INDENT=2][INDENT=2]</external_variable>В коде мы даем два значение нашей переменной - активное и пассивное. Оно соответственно равно нулю и единице.
Теперь, после всех махинаций и необходимых введений ты можешь спокойно работать с SCAP-контентом и создавать правила под требуемые уязвимости. Дальше только интереснее, но к сожалению пора подвести итог нашей работы.
Подводим итоги
Сама работа с таким видом контента очень сложна в понимании, но проста на практике. Поэтому из главных особенностей ты должен знать структуру языков OVAL и XCCDF, а также разбираться в построении. Что откуда берется и зачем нужно. Кроме такой утомительной лекции по SCAP я рекомендую тебе прочесть введение в OVAL и миф об идеальном сканере. С этим ты ознакомишься уже на просторах Хабра. В остальном я постарался выдать максимально простой и понятный гайд о том, как работать с таким типом документов.
Последнее редактирование модератором: