Skip to main content

Нужен ли российской безопасности 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