規格の壁を越えろ！NIST IR 8477の「コンセプトマッピング」でセキュリティ対策を最適化
こんにちは、「文系のセキュリティをDXする」SecureNavi株式会社の井崎です。
はるか数年前にOSCALの記事を書いたのですが、この記事をきっかけに、いくつかの方からコンタクトをいただきました。私たちが「文系のセキュリティ」と呼んでいる、社内規程の管理、監査、アセスメントなどの領域は、日本と比べ、アメリカがはるか先を進んでいます。
今回もそんなアメリカ発の情報をお伝えします。テーマは「規格の壁を超えろ！」ということで、アメリカのNISTが提供する内部報告書「NIST IR 8477」という文書を紹介します。
NIST IR 8477 の概要
この報告書（以下「当報告書」と表現します）のタイトルは「Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines」です。日本語に訳すと「文書化された、規格、規制、フレームワーク、ガイドラインの関係をマッピングする」といったところでしょうか？
夢のあるタイトルですね！日本国内でも各省庁や団体（例えば、経済産業省、総務省、厚生労働省、IPA、NICT、日本規格協会など）が、様々な規格やセキュリティガイドラインなどを発行しています（以下、これらの文書類をまとめて「ガイドライン等」と表現します）。しかし、これらのガイドライン等は多くの場合、個々で独立しており、その関係性が明らかになっていません。アメリカは日本と比べてもっと多くのガイドライン等があり、その量に苦しんでいる組織や企業も多いのではないかと推察されます。
これらの大量のガイドライン等に効率よく対応するには、各ガイドラインの間の関係性を明らかにする必要があります。例えば、当報告書の冒頭では、以下のような課題が紹介されています。
・あるガイドラインに適合することは、その組織が、別のガイドラインに適合することにどのように役立つのか？1つ目のガイドラインは、2つ目のガイドラインのどの部分に対応しているのか？
…
・ガイドラインの旧版と現行版で、どのような内容が大幅に変わったのか。
セキュリティ担当者であれば、誰もが直面する課題でしょう。これらの課題を解決するために、当報告書では「コンセプトマッピング（Concept Mapping）」という考え方を提唱しています。この考え方を使うことで、2つの異なるガイドラインの関係をなるべく厳密に記述することができます。なお、Conceptという言葉の意味は、ISO1087の定義が参照されています。これを深堀りすると大変なので、説明は割愛します。
マッピングのユースケースを特定する
さて、本題に入る前に、当報告書では「まず、何のためにマッピングしたいのか」のユースケースを明確にすることを要求しています。まどろっこしい気もしますが、紹介されている例を見てみましょう。
・CISOが、ガイドラインAを満たすことが、ガイドラインBを満たすことに、どのように役立つのかを判断したい。
…
・ガイドラインAの利用者は、あるバージョンから次のバージョンへ、どの条項が大幅に変更されたかを知りたい。
こういったユースケースを文書化することで、適切なマッピング手法を選択できます。では、本題に入っていきましょう。
マッピング手法を選択する
本題です。この章ではガイドライン同士をマッピングするうえで、4つのマッピング手法を紹介しています。それぞれの手法には、メリットとデメリットがあります。実際に見ていきましょう。
なお、以下では、日本におけるISMS認証の基準としてよく知られている「ISO/IEC 27001（および ISO/IEC 27002）」をもとにした例を示すことがあります。この例は、当報告書で正式に紹介されているものではなく、私自身の考えであることに注意してください。
1. コンセプト・クロスウォーク
最も単純かつ主観的なマッピング手法です。これは、単に「AとBが関係している」ということを示すのみで、それ以外の情報は全く与えられません。一番「しょぼい」方法とも言えますが、規格とのマッピングと聞いてすぐに思い浮かぶのはこの手法でしょう。
具体例としては、ISO/IEC 27002:2022 附属書B（Table B.1）に紹介されている「対応表」が挙げられます（下記参照）。規格の改訂により、新規格と旧規格の対応表として重宝している組織も多いでしょう。この表は、新規格の項番と、旧規格の項番の対応のみを示しており、それ以外の情報（例えば、旧規格の項番の内容を実行すれば、対応する新規格の項番の内容を完璧に実施したことになるのか、など）は示されていません。
2. サポーティブ関係マッピング
「サポート」という考え方を導入すると、コンセプト・クロスウォークと比べてコンセプト間の関係性がわかりやすくなります。「サポーティブ関係マッピング」と呼ばれるこの手法は、2つのコンセプト間の関係を、以下の記述で表現します。
・サポートする（Supports）：AがBをサポートするとは、Aに取り組むことで、Bの全部または一部を達成することができることを意味する。
・サポートされる（Is supported by）：サポートするの逆の関係を意味する。
・同一である（Identical）：AとBは同じ表現を使っている。
・同等である（Equivalent）：AとBは同じ表現ではないが、意味は同じである。
・矛盾する（Contrary）：AとBの間で矛盾する要素がある。
・関係ない（No relationship）：AとBは関連していない。
また、サポーティブ関係マッピングでは、「サポートする」「サポートされる」の関係において、オプションとして以下のプロパティを割り当てることができるとされています。
CがDをサポートする関係であるとき、
・〜の例（Example of）：Cは、Dの全部または一部を達成するための例である。あくまで例のため、Cを適用しなくでもDは達成できる。
・〜に不可欠（Integral to）：Cは、Dの構成要素である。Dを達成する上では、Cを適用しなければならない。
・〜に先行する（Precedes）：Cは、Dの前提条件である。Dを達成するには、その前にあらかじめCを達成しておく必要がある。
これも具体例を見てみましょう。手頃な文献が見当たらなかったので、私の手作りの表を紹介します。この表は、前述の「コンセプト・クロスウォーク」で登場した「ISO/IEC 27002:2022 附属書B（Table B.1）」をもとに作成したものです。
例えば、一番上の行を見てみます。2022年版の5.1（情報セキュリティ方針群を作成し、伝達し、レビューする）は、2013年版の5.1.1（情報セキュリティ方針群を作成し、通知する）と、5.1.2（それをレビューする）の組み合わせです。2022年版の5.1を達成するうえでは、2013年版の5.1.1と5.1.2をそれぞれ達成する必要がある、つまり「不可欠としてサポート（Support / Integral to）」と表現できます。
次の行に着目しましょう。2022年版の5.2（情報セキュリティの役割をニーズに応じて定め割り当てる）は、2013年版の6.1.1（情報セキュリティの役割を定め割り当てる）と同じ意味です。2022年版では「ニーズに応じて」という言葉が追加されているため表現は異なりますが、やることは基本的に変わりません。そのことを「同等（Equivalent）」と表現できます。
少し下の行になりますが、2022年版の5.13（情報のラベル付け手順を策定し実施する）は、2013年版の8.2.2（情報のラベル付け手順を策定し実施する）と全く同じ内容です。そのため、前述した「同等」ではなく「同一（Identical）」と表現できます。
最後に「例としてサポート（Support / Example of）」も見てみましょう。一番下の行では、2022年版の5.14（情報の転送における規則、手順、合意を備える）において、2013年版の13.2.3（電子メールなどの通信を保護する）はあくまで例示となっています。電子メールの通信を保護しなくても、組織において情報の転送における規則や手順などが備わっていれば、2022年版の5.14は達成できるからです。
3. 集合論的関係マッピング
数学を嗜んだ人にとって、「関係」と聞いて思い浮かぶのは集合論ではないでしょうか？その集合論の考え方を元にしたマッピング手法が、この「集合論的関係マッピング」です。集合論的関係マッピングを用いることで、ある2つのコンセプト間の関係は、以下の記述で表現することができます。
・（真）部分集合である（Subset of）：AはBの（真）部分集合である。言い換えると、BはAのすべてを含んでおり、かつそれ以上のことも含んでいる。
・交差する（Intersects with）：AとBは重なる部分があるが、それぞれが他方にはない内容も含んでいる。
・等しい（Equal）：AとBは同じである。
・（真）上位集合である（Superset of）：AはBの（真）上位集合である。言い換えると、AはBのすべてを含んでおり、かつそれ以上のことも含んでいる。
・関係ない：AとBは無関係であり、共通部分がない。
さらに、集合論的関係マッピングはこれだけではありません。上記の関係性を表す記述に加えて、その根拠をオプションとして記載することができます。具体的には「構文的に（Syntactic）」「意味的に（Semantic）」「結果的に（Functional）」の3つから選ぶことができます。
最もわかりやすいのが「意味的に（Semantic）」でしょう。2つのコンセプトの意味に着目し、全く同じ意味であれば「意味的に等しい」といえます。
次に「構文的に（Syntactic）」とは、そのコンセプトを表現する文章（英語や日本語）に着目しています。単語レベルで全く同じ書き方であれば「構文的に等しい」といえます。一見、単語レベルで同じ書き方のガイドライン等なんてないだろうと思うかもしれませんが、ガイドラインが改訂されたときに、改訂がない項番を示すときに使えそうです。
最後の「結果的に（Functional）」とは、そのコンセプトを実行したときに起こる結果に着目しています。一見異なるセキュリティ対策だけども、その対策を実施したときに得られる結果（リスクの低減など）が同じであれば「結果的に等しい」といえるでしょう。
これも具体例を見てみましょう。先ほどの「サポーティブ関係マッピング」よりも情報量が増えている事がわかると思います。オプションとして、意味的/構文的の2つの観点から、マッピングを考えてみました。
まずは、一番上の行を見てみましょう。意味的には、2022年版の5.1に対し、2013年版の5.1.1および5.1.2はそれぞれ「部分集合（Subset of）」となっています。先ほどの「サポーティブ関係マッピング」で「サポート」の関係だったため、この定義は自然に思えます。ただし、構文的に見てみると（つまり、規格を一言一句見てみると）、2022年版の5.1には「トピック固有の方針」という言葉が登場するのですが、2013年版にはありません。逆に、2013年版の5.1.1には「従業員」という言葉が、5.1.2には「適切、妥当かつ有効である」という表現が含まれていますが、2022年版の5.1にはいずれもありません。すなわちこれらは、構文的には「交差する（Intersects with）」状態です。
（補足：あくまで Control のみを参照しており、Guidanceなどは参照していません）
また、次の行を見てみましょう。2022年版の5.2は、2013年版の6.1.1と、意味的には「等しい（Equal）」となっています。先ほどの「サポーティブ関係マッピング」で「同等」だったため、この定義は自然でしょう。さらに構文的に見てみると、2022年版の5.2は、
> 情報セキュリティの役割及び責任は，組織のニーズに従って定め，割り当てなければならない。
2013年版の6.1.1は、
> 全ての情報セキュリティの責任を定め，割り当てなければならない。
となっています。（ちょっと大目に見るのですが）、6.1.1の記載は、5.2の記載の「部分集合（Subset of）」と考えることができそうです。
4. 構造的関係マッピング
最後に紹介する「構造的関係マッピング」は、少し今までのマッピング手法とは毛色が異なります。これは単に、1つのガイドライン等の中での、親子関係を表現するものだからです。
例えば、ISO/IEC 27002:2022 においては、「5 組織的管理策」と呼ばれるカテゴリの下に、「5.1 情報セキュリティのための方針群」「5.2 情報セキュリティの役割及び責任」と続きます。この親子関係を表すマッピングのことを指しています。
単なる親子関係なので、他の手法よりも情報量は多くありません。子コンセプトは親コンセプトの一部であることはわかりますが、親コンセプトを達成するために、子コンセプトを必ず達成しないといけないのか、任意なのかについては、このマッピングでは特定されません。
補足
当報告書では、上記4つの手法以外にも、カスタムした手法を作成することや、複数の手法を相互に変換する考え方などが紹介されています。
コンセプトペアの評価と文書化
4つのマッピング手法を紹介してきましたが、当報告書の最後には、このマッピングによって得られた成果を文書化して保管しておくことについて記載されています。
文書化においては、そのマッピングの根拠も合わせて記載することや、A→Bへのマッピングを考えたときには逆方向のマッピングも検討することで有意義な結果が得られる可能性になどについて示唆されています。
まとめと補足
NIST IR 8477への期待
さて、NIST IR 8477の概要を、その具体例とともに見てみました。今後、IT環境やセキュリティを取り巻く環境が複雑化する中で、国や業界団体が発行するガイドライン等がさらに増え、カオスになっていくでしょう。この報告書が、そんなガイドライン等に溢れたカオスな状況における一つの指針となり、表題通り「規格の壁を超えて」セキュリティの取り組みが最適化できる道標になると良いと考えています。
個人的には、国や業界団体などのガイドラインの発行体が、他ガイドラインとの関係性を適切に示すことは義務だと考えます。他のガイドラインとの参照を示さずに、組織や企業に対して「このガイドラインを守れ。他のガイドラインのことは知らん」といったスタンスは、セキュリティの取り組みの形骸化や、実態を伴わない文書主義的なセキュリティマネジメントシステムを助長する行為です。まずは「コンセプト・クロスウォーク」からでも良いので、他ガイドラインとの関係性を適切に示し、組織や企業が守らないといけないガイドライン全体がハーモナイズされた世界を目指してほしいと思います。弊社も、いち事業者として、そんな世界の実現に寄与していく所存です。
OSCALとの関係性
ちなみに、当報告書ではOSCALに関する記述も見られました。具体的には以下の記載があります。
The set theory relationship mapping style has been supported by NIST OLIR since its launch, and it is also leveraged by the NIST Open Security Controls Assessment Language (OSCAL) to support automated cybersecurity control assessment.
（この集合論的関係マッピング手法は、NIST OLIRの立ち上げ時からサポートされており、サイバーセキュリティ統制の自動評価をサポートするNIST OSCALでも活用されている）
OSCALをウォッチしている一人として全く心当たりがなかったため、少し調べてみました。あらためてOSCALのWebページを調べてみると、「Control Mapping Model」と呼ばれる、プロトタイプのモデルが開発されており、その中の属性として「releationship」という記述を見つけることができました。取りうる値を見てみると「equivalent-to」「equal-to」「subset-of」などの記述が見られます。また、NIST IR 8477を参照しているという記述もありました。
ちなみに、OSCALのGitHub上でも議論が行われていました。今後、OSCALのバージョンアップに伴い、日の目を見る事があるのかもしれません。期待したいですね！
さいごに
最後になりましたが、この記事のタイトル、そして記事の本文の一部は、Claude3 の出力によるものです。便利な世の中になりました。
また、私が代表を務めるSecureNavi株式会社では、こういった領域について研究開発を進めています。興味がある方は（非公開求人もあるので）お気軽にご連絡ください！セキュリティガイドラインオタクの方、ぜひ語りましょう！
参考文献
この記事が気に入ったらサポートをしてみませんか？