Profile を読む

Profile というモデル

Catalog は管理策の一覧でした。ただし、一覧に載っているものすべてを、どの組織のどのシステムにも一律に適用するわけではありません。リスクの大きさも、システムの性質も違うからです。「この一覧から、うちはこれを使う」という取捨選択が、Catalog の次に行う作業です。

この管理策の選択の指定を書くのが Profile というモデルです。Profile は、どの Catalog を選択元にするか、その中のどの管理策を使うかを書きます。ISO/IEC 27001 の適用宣言書で、管理策ごとに採用・不採用を付けていく作業に近い役割です。

選んだ結果として出来上がる管理策のセットには、ベースラインという呼び名がよく使われます。「当社の標準ベースライン」「重要システム向けベースライン」のように、守るべきことの基準線という意味です。

題材：SP 800-53 と SP 800-53B

実物を読んでみましょう。題材は、米国政府の情報システム向けの管理策集 NIST SP 800-53 と、その公式ベースライン集 SP 800-53B です。この 2 つの規格は、OSCAL のモデルできれいに役割が分かれています。

• SP 800-53 は巨大な Catalog です。OSCAL 版はアクセス制御（AC）や監査（AU）など 20 のファミリーに、拡張を含めて 1,196 件の管理策を収めています。
• SP 800-53B はそこからの選択、つまり Profile です。システムへの影響の大きさに応じた LOW / MODERATE / HIGH の 3 段階と、プライバシー向けの、合計 4 つのベースラインが、それぞれ 1 つの Profile ファイルとして公開されています。

今回読むのは、いちばん小さい LOW ベースラインの Profile です。全体で 225 行しかありません。1,196 件の管理策を持つ Catalog に対して、そこから選ぶ Profile はこの薄さで済む。この対比が、Profile というモデルの性格をよく表しています。

ファイルの外枠

冒頭はこうなっています。

profile:
  uuid: 201765f8-6d45-4941-8789-9eef2effd7d0
  metadata:
    title: Electronic (OSCAL) Version of NIST Special Publication 800-53 Revision 5.2.0 LOW IMPACT BASELINE
    last-modified: "2026-05-11T16:10:16.00000-00:00"
    version: 5.2.0
    oscal-version: 1.2.2
    # …略…
  imports:
    # …略…

外枠の形は Catalog とまったく同じです。全体を包む項目がモデル名の profile: に変わり、その下に uuid と metadata が並びます。metadata の必須 4 項目も同じです。OSCAL の 8 モデルは、この形を共有しています。一度覚えた読み方が、モデルが変わってもそのまま使えます。

imports：どの Catalog から選ぶか

Profile の本体は imports です。「どこから」と「どの管理策を」をここで指定します。

  imports:
    - href: '#84cbf061-eb87-4ec1-8112-1f529232e907'
      include-controls:
        - with-ids:
            - ac-1
            - ac-2
            - ac-3
            - ac-7
            # …略（全部で 149 件）…
            - sr-12
  merge:
    as-is: true

href が「どこから」、つまり選択元の Catalog への参照です。値の # で始まる書き方は「このファイル自身の中を見よ」という意味で、参照先はファイル末尾の back-matter（巻末の参考資料一覧）にあります。

  back-matter:
    resources:
      - uuid: 84cbf061-eb87-4ec1-8112-1f529232e907
        description: 'NIST Special Publication 800-53 Revision 5: Security and Privacy Controls for Federal Information Systems and Organizations'
        rlinks:
          - href: ../../../../nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5_catalog.xml
            media-type: application/oscal.catalog+xml
          - href: ../../../../nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json
            media-type: application/oscal.catalog+json
          - href: ../../../../nist.gov/SP800-53/rev5/yaml/NIST_SP-800-53_rev5_catalog.yaml
            media-type: application/oscal.catalog+yaml

imports の href が持つ #84cbf061… という値は、この back-matter に並ぶ資料の uuid です。つまり「巻末の資料 84cbf061… を参照」で、その資料の実体が rlinks（実ファイルの場所の一覧）に書かれています。場所が 3 行あるのは、SP 800-53 の Catalog が XML、JSON、YAML の 3 形式で公開されているからです。最初のセクションで「OSCAL ファイルには 3 つの形式がある」と述べましたが、その実物がここに並んでいます。中身は同じで、どれを参照しても構いません。

巻末を経由するのは丁寧な書き方で、href に参照先の場所を直接書くこともできます。次のセクションで自分の Profile を書くときは、直接書く形を使います。

149 件の選択：include-controls と with-ids

「どれを」を指定するのが include-controls です。この Profile は with-ids（この id のものを使う、という指定）で管理策を 1 件ずつ列挙しています。数えると 149 件。1,196 件の Catalog から 149 件を選んだものが LOW ベースラインだ、ということがこの一覧だけで機械的に決まります。

一覧の id が ac-1 のような小文字とハイフンの形なのは、選択元である SP 800-53 の Catalog の慣例だからです。Profile 側で id を新しく生み出すことはできず、選択元の Category で定義した id をそのまま使います。

一覧には ia-2.1 のようにピリオドの付いた id も混ざっています。これは管理策の拡張（enhancement）で、基本の管理策（ia-2）に追加する強化策の枝番です。拡張も 1 件の管理策として、同じ with-ids で選べます。

末尾に付いている merge は、選んだ結果をどう並べ直すかの指定です。as-is: true は「選択元の Catalog の章立てのまま並べる」という意味で、決まり文句としてよく現れます。

読み取り演習

次へ

実物のベースラインで、Profile の骨組み（imports、href、include-controls）を読み取りました。次のセクションでは、ミナト精機の Profile を自分の手で書きます。社内基準カタログの 6 件から、受発注システムに適用する管理策を選びます。