SSP を仕上げる

SSP の最後のブロック、control-implementation（管理策の実装）を書きます。ここまでで、このシステムが従う管理策（Profile で選んだ 4 件）と、システムの実装にある 3 つの部品が文書に揃いました。残る仕事は、管理策を 1 件ずつ、どの部品が実装するかを書くことです。

書く相手：Profile で選んだ 4 件

管理策の実装を書く相手は、受発注システム基準プロファイルで選んだ 4 件の管理策です。本文は、Profile を通して見た形で確認しておきます。mk-ac-01 は、カタログの既定値 12 を Profile の set-parameters で 16 に差し替えているので、この SSP から見た要求は「16 文字以上」です。

実装する側の候補は、前のセクションで定義した 3 つの部品です。

管理策ごとに、この 3 つのどれが要求を実装しているかを判断して書くのが、この章の作業です。

1 件分の管理策の実装：implemented-requirement

control-implementation ブロックは、全体の説明（description）と、管理策ごとの実装のリスト（implemented-requirements）でできています。1 件の implemented-requirements の構造は、IFA の実物で読んだとおりです。

1 件の by-components には、次の 4 つを書きます。

implementation-status の state は決まった値から選びます。実装済みの implemented、一部だけ実装済みの partial、実装予定の planned、代替手段で満たしている alternative、このシステムには該当しない not-applicable です。

1 件目の mk-ac-01（パスワードの管理）を、この形で書くとこうなります。

  control-implementation:
    description: 受発注システム基準プロファイルで選んだ管理策についての、受発注システムの管理策の実装。
    implemented-requirements:
      - uuid: 2be66da7-268a-4bd1-ba7f-591591d33a18
        control-id: mk-ac-01
        by-components:
          - component-uuid: 180b8d1f-fe98-4762-9ea5-f661db3859ec
            uuid: 24eb9772-272d-4704-bb49-13970ffaab5b
            description: 受発注システムは、16 文字未満のパスワードを登録できない設定にしている。初期パスワードは、初回ログイン時に変更を求める。
            implementation-status:
              state: implemented

component-uuid の 180b8d1f… は this-system の部品、受発注システム本体です。パスワードの長さの検査はアプリケーション自身の設定なので、実装する部品はシステム本体になります。description の「16 文字」は、Profile を通して見た本文の要求にそのまま応えた値です。カタログの変数、Profile の値、SSP の管理策の実装が、1 つの数字でつながっています。

2 件目の mk-ac-02（利用者アカウントの棚卸し）は、自分で書いてください。

    implemented-requirements:
      - uuid: 2be66da7-268a-4bd1-ba7f-591591d33a18
        control-id: mk-ac-01
        by-components:
          - component-uuid: 180b8d1f-fe98-4762-9ea5-f661db3859ec
            uuid: 24eb9772-272d-4704-bb49-13970ffaab5b
            description: 受発注システムは、16 文字未満のパスワードを登録できない設定にしている。初期パスワードは、初回ログイン時に変更を求める。
            implementation-status:
              state: implemented
      - uuid: 88a9f4c7-a504-409f-a1c1-d9793b775872
        control-id: mk-ac-02

部品を選ぶ：mk-ph-01

3 件目は mk-ph-01（サーバー室の入退室管理）です。パスワードや棚卸しと違って、入退室の記録と入室者の限定をやっているのは、受発注システム自身ではありません。章冒頭の部品一覧から、実際にこの要求を担っている部品を選びます。

      - uuid: dbbcca84-0323-4b2f-a716-e3324b99d1be
        control-id: mk-ph-01

1 つの管理策を複数の部品で実装する：mk-bk-01

最後の mk-bk-01（業務データのバックアップ）は、1 つの部品では完結しません。バックアップを作るのは受発注システム自身で、保管しているのはアオバドライブです。こういう場合は、by-components に 2 件並べます。

      - uuid: 9e405125-0b96-4e16-9fff-31a028b24842
        control-id: mk-bk-01
        by-components:
          - component-uuid: 180b8d1f-fe98-4762-9ea5-f661db3859ec
            uuid: 71239244-e728-47b4-a21f-162dedf73397
            description: 受発注システムは、業務データのバックアップを毎日作成する。
            implementation-status:
              state: implemented
          - component-uuid: ada2d11f-c849-475c-ac1b-c1b65cd2e083
            uuid: f07d2537-2c7e-4544-b9a3-869858124083
            description: 作成したバックアップはアオバドライブに保管する。復元の試験は、アオバドライブ上のバックアップから年 1 回行う。
            implementation-status:
              state: implemented

条文の要求（毎日バックアップする、復元の試験を年 1 回行う）が、2 つの部品の記述に分かれて収まっています。「誰が何をやっているか」が部品ごとに分かれて書かれるので、たとえばアオバドライブを別のサービスに切り替えるとき、影響を受ける記述がどれかを機械的に探せます。

これで 4 件すべての管理策の実装を書き終えました。このシステムが従う管理策（import-profile）、システムの概要（system-characteristics）、システムの実装（system-implementation）、管理策の実装（control-implementation）の必須ブロックが揃い、「ミナト精機 受発注システム セキュリティ計画書」の版 1.0.0 は、OSCAL の SSP として検証を通る完全な文書になりました。

文書の連なりを読み返す

第 2 部の最初からここまでで作った文書を、改めて整理してみましょう。

1. 社内基準カタログ（Catalog、版 1.2.0）。6 件の管理策の定義。mk-ac-01 にはパスワードの最低文字数の変数があり、既定値は 12。
2. 受発注システム基準プロファイル（Profile、版 1.1.0）。カタログを href で参照し、6 件から 4 件を選択。変数に 16 を差し込み、本文を書き足す調整。
3. 受発注システム SSP（版 1.0.0）。プロファイルを import-profile で参照し、選ばれた 4 件それぞれに、どの部品が実装するかを by-components で書いた管理策の実装。

Word の規程集だけを持っていた第 1 部の時点と比べると、「この条文は受発注システムに適用されるのか」「適用されるとして、管理策の実装はどうなっているのか」という問いに、OSCAL 文書をたどるだけで答えられるようになっています。しかもそのたどり方は人間の経験値に基づくものではなく、href、control-id、component-uuid という機械が決定的に辿れる形となっています。

Component Definition と SSP

最後に 1 点、補足情報です。

Catalog から Profile、Profile から SSP までは、href や import-profile で文書どうしが参照でつながっていました。Component Definition と SSP の関係は、それとは違います。

第 13 セクションのアオバドライブの Component Definition にある部品の uuid と、この SSP のアオバドライブの部品の uuid は、別の値だったことに気づいたでしょうか。共通部品定義の入退室管理システムもそうです。SSP の by-components が指しているのは、いつもこの SSP の中の components です。Component Definition 側の uuid を直接指す書き方にはなっていません。

では、第 13 セクションの文書は何のためだったのか。それは、SSP 作成時の「材料」です。アオバは「アオバドライブはこう守っている」と宣言した文書を配ります。ミナト精機はそれを読み、受発注システムではバックアップ保管にアオバドライブを使う、復元試験はこうする、と SSP に自ら書き直します。OSCAL には、Profile の import のように Component Definition を SSP へ自動で取り込む項目はありません（ただし、それをサポートするツールは多く提供されています）。

二つが疎な関係になっているのは、書き手と役割が違うからです。Component Definition は、あくまで部品の提供者による説明です。実際にその管理策を利用するのか、有効化するのかを決めるのは、SSP を書くミナト精機側です。アオバの説明が変わったときは、まずアオバが Component Definition を改訂し、受け取ったミナト精機が必要なら SSP を直す、という順になります。

理解の確認

次へ

Implementation Layer の 2 つのモデルを書き終えました。第 4 部は Assessment Layer です。書いた計画が実際に守られているかを確かめる Assessment Plan（評価の計画）と Assessment Results（評価の結果）、見つかった問題を追いかける POA&M（是正計画）の 3 つのモデルを扱います。ミナト精機の題材は、年 1 回の内部監査です。まずは NIST のサンプルで、評価の計画の実物を読むところから始めましょう。