Нужен ли российской безопасности OSCAL?

Краткий обзор Open Security Controls Assessment Language

За достаточно агрессивно звучащей аббревиатурой OSCAL скрывается Open Security Controls Assessment Language, который разработчики из NIST называют «стандартом для стандартов».

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

Назначением OSCAL является предоставление инструментария для автоматической оценки соответствия различным требованиям ИБ (PCI DSS, ISO 2700x, HIPA и пр.) за счет представления этих требований как удобном для пользователей виде, так и в формате, доступном для средств защиты информации  (XML, JSON).

Вот как это достигается.


Архитектура OSCAL

В основе подхода лежит несколько терминов (приведены от общих к частным):

  1. Каталог – представление в нотации OSCAL определенного стандарта ИБ. Содержит данные о самом стандарте, структурированное описание контролей стандарта и их параметров.
  2. Профиль – представление наборов контролей для систем различного уровня критичности или конкретных программ оценки безопасности. Содержит включение контролей, определенных в родительских каталогах и профилях. Инициализирует, изменяет, дополняет параметры включенных контролей.
  3. Контроль – описание меры защиты, разработанный для соответствия набору определенных требований безопасности.

Данные термины определяют архитектуру проекта OSCAL и являются ключевыми при формировании стандартов ИБ в США.

На момент написания статьи, в рамках проекта OSCAL, реализован каталог публикации NIST SP 800-53 Rev 4. Выбор данного стандарта для первой реализации каталога в формате OSCAL обусловлен всеобъемлющей властью стандарта на рынке услуг ИБ в США. Документ структурирован, включает наглядные примеры и содержит несколько сотен контролей. Именно это позволило стать NIST SP 800-53 базовым стандартом для оценки защищенности организаций и информационных систем.

Теперь, более детально по доступному инструментарию OSCAL. На текущий момент реализованы следующие представления:

  1. Каталог стандарта NIST SP 800-53 Rev 4;
  2. Базовые профили стандарта NIST SP 800-53 Rev 4;
  3. Профили программы управления рисками и авторизацией FedRAMP.

Каждый из перечисленных объектов представляет собой текстовый файл в формате json и xml. Структура представлений базируется на схеме XML Schema Definition Language (XSD) 1.1 для представлений в формате xml и JSON Schema draft-07 для представления в формате json.

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

Каталог стандарта NIST SP 800-53 Rev 4

В этом разделе рассматривается реализация стандарта NIST SP 800-53 Rev 4 в виде каталога OCSAL, для формирования общего представления о используемых структурах данных. В качетсве примеров будет использоваться представление стандарта в формате json.

В каталоге определяются следующие родительские объекты:

  1. metadata — содержит информацию о публикации документа: название, версия документа, ссылки на публикации документа.
  2. groups — список групп контролей, включает контроли, распределенные на семейства, соответствующие различным областям обеспечения ИБ.
  3. back-metter — коллекция ссылок на ресурсы, связанных с публикацией.

Ниже приведен фрагмент определения объекта metadata каталога NIST SP 800-53 Rev 4.

"metadata": {
      "title": "NIST Special Publication 800-53 Revision 4: Security and Privacy Controls for Federal Information Systems and Organizations",
      "last-modified-date": "2019-06-05T17:36:38.803-04:00",
      "version": "2015-01-22",
      "oscal-version": "1.0.0-milestone1",
      "properties": {
        "name": "keywords",
        "keywords": "Assurance, computer security, FISMA, Privacy Act, Risk Management Framework, security controls, security requirements"
      },
      "links": [
        {
          "href": "#resource-pdf-sp-800-53r4",
          "rel": "alternate"
        },
        {
          "href": "#resource-doi-sp-800-53r4",
          "rel": "canonical"
        }
      ]
...

Объект groups является ключевым. Каждая группа — семейство контролей, соответствующие различным областям обеспечения ИБ. Ниже представлен фрагмент определения семейства контролей «Access Control»

"groups": [
      {
        "id": "ac",
        "class": "family",
        "title": "Access Control",
        "controls": [
          {
            "id": "ac-1",
            "class": "SP800-53",
            "title": "Access Control Policy and Procedures",
...

Помимо полей с определением метаданных группы Access Control, объект содержит коллекцию controls. В этой коллекции содержаться ключевые объекты нотации OSCAL — контроли.

Объект контроль, содержит разделы, которые определены в публикации стандарта. В нотации OSCAL разделы транслируются в следующие объекты:

  • id, class, title — метаданные контроля;
  • parts — коллекция требований, определенных в данном контроле;
  • parametres — параметры, которые конкретизируют требования для определенной программы соответствия, организации или информационной системе;
  • subcontrols (опционально) — коллекции возможностей по усилению контроля путём добавления к нему дополнительной функциональности или требований;
  • properties — именованное значение, присваиваемое контролю (идентификатор в удобном для пользователя виде, метод оценки и т.д.);
  • links — cсылки на локальный или удаленный ресурс.

Для примера, рассмотрим контроль RA-5 Vulnerability Scanning. Ниже представлен фрагмент определения метаданных, требований и параметров требований контроля.

"id": "ra-5",
"class": "SP800-53",
"title": "Vulnerability Scanning",
"parameters": [
    {
         "id": "ra-5_prm_1",
         "label": "organization-defined frequency and/or randomly in accordance with organization-defined process"
     },
     {
          "id": "ra-5_prm_2",
          "label": "organization-defined response times"
     },
     {
          "id": "ra-5_prm_3",
          "label": "organization-defined personnel or roles"
     }
],
"parts": [
     {
          "id": "ra-5_smt",
          "name": "statement",
          "prose": "The organization:",
          "parts": [
               {
                    "id": "ra-5_smt.a",
                    "name": "item",
                    "properties": {
                      "name": "label",
                      "label": "a."
                    },
               "prose": "Scans for vulnerabilities in the information system and hosted applications { ra-5_prm_1 } and when new vulnerabilities potentially affecting the system/applications are identified and reported;"
                },
...

Из фрагмента видно, что требование RA-5.a содержит параметр ra-5_prm_1, который определяет заданную в организации частоту сканирования уязвимостей. Далее мы увидим, каким образом инициализируются этот параметр в профиле.

Перечислять все параметры контролей нет необходимости: в документации на официальном сайте, есть подробное описание используемых схем. Логика формирования не обозначенных в статье объектов аналогична указанным в примере. Подробно останавливаться на них не будем.

Базовые профили стандарта NIST SP 800-53 Rev 4

Что бы понять, что из себя представляют базовые профили, необходимо сформировать общее представление о подходе NIST к оценке уровня защищенности.

Для того, что бы минимизировать время на формирование достаточного списка контролей для конкретной организации или системы, в NIST разработаны базовые наборы контролей для систем/организаций, разного уровня критичности. Выделены три уровня критичности систем: низкая, средняя и высокая. Соответственно, для каждой из них сформирован базовый набор контролей.

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

  • LOW IMPACT BASELINE — базовый профиль для систем низкого уровня критичности;
  • MODERATE IMPACT BASELINE — базовый профиль для систем среднего уровня критичности;
  • HIGH IMPACT BASELINE — базовый профиль для систем высокого уровня критичности.

Базовые профили определяются составом контролей из каталога и определением приоритетов включенных контролей в соответствии с таблицей «SECURITY CONTROL BASELINES», представленной в публикации стандарта NIST SP 800-53 Revision 4 на странице 109.

Базовый профиль в нотации OSCAL содержит следующие объекты:

  • metadata — общая информация о профиле, содержит такие поля как название, версия документа, контактные данные разработчиков профиля;
  • imports — ссылки на включаемые контроли из каталога;
  • modify — определение приоритета внедрения включенных контролей;
  • back-matter — ссылки на используемые ресурсы.

Ниже представлен фрагмент определение профиля NIST SP 800-53 Rev 4 LOW IMPACT BASELINE.

"profile": {
  "metadata": {
    "title": "NIST Special Publication 800-53 Revision 4 LOW IMPACT BASELINE",
    ...
    }
  },
  "imports": {
    "href": "#catalog",
    "include": {
      "id-selectors": [
        ...
        {
          "control-id": "ra-5"
        },
        ...
      ]
    }
  },
  "modify": {
    "alterations": [
      ...
      {
        "control-id": "ra-5",
        "additions": {
          "position": "starting",
          "properties": {
            "name": "priority",
            "priority": "P1"
          }
        }
      },
      ...
    ]
  },
  "back-matter": {
    "resources": {
      "id": "catalog",
      "desc": "NIST Special Publication 800-53 Revision 4: Security and Privacy Controls for Federal\n            Information Systems and Organizations",
      "rlinks": {
        "href": "NIST_SP-800-53_rev4_catalog.json",
        "media-type": "application/oscal.catalog+json"
      }
    }
  }
}

В данном фрагменте можно увидеть, что контроль с идетификатором ra-5 включается в базовый профиль LOW из каталога NIST SP 800-53 Rev 4 и ему назначается приоритет P1. Идентификатор ra-5 принадлежит контролю Vulnerability Scanning, рассмотренному в каталоге выше.

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

Профили программы управления рисками и авторизацией FedRAMP

Завершает цепочку представлений OSCAL, реализация профиля для программы управления рисками и авторизацией Federal Risk and Authorization Management Program (FedRAMP). FedRAMP используется для обеспечения требуемого уровня защищенности продуктов и сервисов, используемых правительством США. Именно этим обусловлен выбор сотрудниками NIST реализации профиля данной программы.

Как и базовые профили стандарта NIST SP 800-53 Rev 4, профили FedRAMP содержат три набора контролей: LOW, MODERATE, HIGH. Большинство контролей профили FedRAMP наследуют из базовых профилей соответствующего уровня критичности. Однако, некоторые требуемые контроли в базовых профилях отсутствуют, поэтому в профилях FedRAMP присутствуют включения контролей напрямую из каталога NIST SP 800-53 Rev 4.

В блоке ниже представлен фрагмент объекта imports профиля FedRAMP уровня LOW. В данном фрагменте контроли наследуются как с базового профиля уровня LOW, так и с каталога NIST SP 800-53 Rev 4.

"imports": [
  {
    "href": "../../nist.gov/SP800-53/rev4/json/NIST_SP-800-53_rev4_LOW-baseline_profile.json",
    "include": {
      "id-selectors": [
        {
          "control-id": "ac-1"
        },
        ...
      ]
    }
  },
  {
    "href": "../../nist.gov/SP800-53/rev4/json/NIST_SP-800-53_rev4_catalog.json",
    "include": {
      "id-selectors": [
        {
          "subcontrol-id": "ca-2.1"
        },
        {
          "control-id": "si-16"
        }
      ]
    }
  }
]

Профили конкретных программ или систем имеют нотацию аналогичную базовым профилям. Отличительной особенностью является инициализация параметров контролей в соответствии с предъявляемыми требованиями. К примеру, в блоке ниже, представлена инициализация параметра ra-5_prm_1, определяющего частоту сканирования сканерами уязвимостей в профиле FedRAMP уровня LOW.

"modify": {
  "settings": {
    ...
    "ra-5_prm_1": {
      "constraints": {
        "STRVALUE": "monthly operating system/infrastructure; monthly web applications and databases"
      }
    },
    ...
  }
}

На этом предлагаю завершить обзор архитектурных особенностей OSCAL. Конечно, в этой статье обозначены только наиболее важные аспекты проекта. Если есть желание познакомится с нотацией OSCAL поближе, предлагаю посетить раздел Schema Reference на официальном сайте проекта.

Применение OSCAL

OSCAL является развивающимся проектом, однако уже сейчас активно внедряется в существующие решения для оценки уровня защищенности систем. На текущий момент интеграция проведена со следующими решениями:

  1. FedRAMP — Планируется, что OSCAL позволит автоматизировать оценки контроля безопасности FedRAMP и отслеживать возможные риски.
  2. Docker Enterprise Edition — OSCAL используется как экспериментальный функционал для оценки соответствия стандартам, представленным в нотации OSCAL.

Как уже говорилось, проект активно развивается. На текущий момент завершен только первый этап разработки. Однако, у проектной команды масштабные планы. От формирования планов защиты систем (System Security Plan) в машиночитаемом формате до реализации систем оценки уровня защищенности систем. Думаю, после официального релиза OCAL 1.0, решений по интеграции станет больше.

Выводы

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

Вопрос: Как я могу использовать OSCAL прямо сейчас?

Ответ: Как минимум представления стандартов в нотации OSCAL позволит упростить анализ публикаций стандартов ИБ. Стандарты в формате OSCAL имеют понятную и логичную иерархию. Это позволяет оптимизировать время на анализ и поиск нужных контролей и их параметров.

Вопрос: Я разработчик информационной системы. Каким образом мне реализовать интеграцию с OSCAL?

Ответ: Здесь множество вариантов использования. От реализации модуля тестирования программного обеспечения для оценки соотвествия необходимым требованиям до формирования полноценного отчета с перечнем предъевляемых требований к системе и какими средствами эти требования удовлетворяются.

Вопрос: Можно ли использовать OSCAL для представления российских стандартов ИБ?

Ответ: Ведется множество споров на тему «схожести» американских и российских стандартов ИБ. Проект OSCAL ориентирован на американский рынок ИБ. Однако, структура проекта и идеалогия представления документов достаточно универсальна. Поэтому, если возникнет потребность в реализации отечественных стандартов в нотации OSCAL, то специалисты ИБ смогут справиться с задачей трансляции стандартов.

В целом, проект OSCAL вызывает интерес в сообществе. Рынок нуждается в оптимизации аудита и аттестации организаций и информационных систем. Поэтому, рекомендую следить за обновлениями и релизами проекта.

Compliance, OSCAL

© VolgaBlob, 2007-2022. Все права защищены.