NIST SP800-53の進化（Rev6を見据えて）
2024/10/07
この記事は、2022年3月にNISTが開催した「3rd Open Security Controls Assessment Language (OSCAL) Workshop 」の、Day1 Part3の公演内容をもとに、一部要約を行い、日本語に翻訳したものです。
Day1 Part3 では、NISTのアレクサンダー（AJ）・シュタインさんと、同じく NIST の OSCAL チームメンバー、ニキータ・ウーテンさんによるBlossomプロジェクトについてと、ビクトリア（ヴィッキー）・ピラテリさんによるNIST SP800-53 についての講演が行われました。
この記事では、後半のビクトリア（ヴィッキー）・ピラテリさんの内容（NIST SP800-53 について）を紹介します。
ぜひ、実際の資料は動画も確認しながらご覧ください（28:41 あたりから）。
はじめに
次は NIST SP 800-53 を率いるビクトリア（ヴィッキー）・ピラテリです。彼女は FISMA の実装プロジェクトのリードで、RMF の “声” とも言える存在ですね。ヴィッキー、今日はどうもありがとうございます。それではマイクをお渡しします。
自己紹介
ご紹介ありがとうございます。私はヴィッキー・アン・ピラテリと申しまして、NIST リスクマネジメントフレームワーク（RMF）プロジェクトのリード、そして 800-53 系列のコンテンツ制作を担当しています。ここからの30分は、NIST SP 800-53『システムと組織のためのセキュリティとプライバシーのコントロール』について、OSCAL がもたらした素晴らしいイノベーションに焦点を当て、今後の展望をお話しします。
SP 800-53、53A、53B などの話は先ほどから何度も出ています。私は 800-53 の “作る側” つまりコンテンツ作成者として、OSCAL を使ってどんなふうにコントロールやベースライン、アセスメント手順を作り・維持し・提供しているかをお伝えします。すでに多くの方が OSCAL で SSP（システムセキュリティ計画）やコントロール評価を自動化していると思いますが、コントロールデータを “発行する立場” の人間にとっても OSCAL は大きな価値があるという点を強調したいのです。もちろん、人間が読むための PDF やウェブ版なども依然として必要なので、そこをどう両立しているかも含めてご覧いただきます。
最後に、次のステップとして 800-53 がどう進化していくか、Revision 6 を見据えた動きを少しだけお話しして、皆さんからの質問にお答えしたいと思います。質問がありましたら Q&A チャットで受け付けますので、時間の許す限り対応します。
800-53 について
まず簡単に 800-53 についておさらいすると、セキュリティ・プライバシー・サプライチェーンリスク管理などに関わる総合的なコントロールカタログを提供するドキュメントです。合計20のコントロールファミリがあり、それぞれが組織やシステムのリスク管理を支えるための対策を提示しています。例えるなら “セキュリティ・プライバシー・サプライチェーン対策のフルコースメニュー” のようなもので、ありとあらゆるメニューが並んでいる感じです。ただし、すべてを全部注文して食べる（実装する）わけではありません。自分たちの状況に合わせて必要な項目を選択するためのカタログなのです。
私たちのリスクマネジメントフレームワーク、SP 800-37（837とも呼ぶ）などと連携して使うことを想定していますが、それ以外のフレームワーク（サイバーセキュリティフレームワークやプライバシーフレームワーク）とも組み合わせ可能です。あらゆるセクターや技術スタック（IoT、ICS、OT、あるいは従来型のITシステムなど）に適用し得るよう、技術に依存しない形で書かれています。最初の版が2005年に公開されて以来、5回の改訂を経て現在に至り、プログラム管理やプライバシー関連、サプライチェーンリスク管理などのファミリも順次追加してきました。米国内外から多くの組織に採用されている、という状況です。
ここからが本題ですが、今回注目してほしいのは、OSCAL と連携したことで 800-53（コントロール本体）や 53Bravo（ベースライン）、53Alpha（アセスメント手順）をどんなふうに提供できるようになったか、という点です。
800-53 コンテンツの再構築
Revision 5 では、以前は単なる Word 文書から PDF を作って公開するだけだったのを、OSCAL を用いて XML/JSON/YAML や CSV/スプレッドシート、そしてダイナミックなウェブ版など、複数の形態を提供できるようになりました。さらに、OSCAL が支える自動チェックのおかげで、膨大なコントロール群に含まれる細かな誤字脱字やパラメータ設定の不整合を見つけやすくなったのです。
例えば 53Alpha（アセスメント手順）では最初から OSCAL で利用しやすい形式を意識して作りました。具体的にはプレーンテキストファイルを “主たるソース” として管理し、それを OSCAL 形式に変換してから PDF や CSV を生成するという流れにしています。人間が目で読む文書だけでなく、機械可読なものも同時に更新できるようになったおかげで、作業効率が格段に向上しました。
以前は、Word や PDF の膨大な表を手作業で作る必要があり、Revision 4 の頃などは非常に大変でしたが、いまは数分で表を自動生成できるというのは大きなメリットです。
今後の方針
私たちはさらに先を見据えています。Revision 6 に向けては、コントロールやベースラインだけでなくアセスメント手順（53Alpha）も含めて、すべて同時にドラフトを公開・改訂して最終版を出す、という形を考えています。利用者の皆さんにとっても “コントロールだけ先に出て、手順はあとから” というタイムラグがなくなるので、導入やレビューがしやすくなるはずです。
もう一つ、NIST SP 800-53 の “オンラインコメントサイト” を設けて、コントロールやベースラインに対する意見をいつでも寄せられるようにしました。大規模な改訂を待たなくても、思いついた時点で提案や改善点を送れるようにする狙いです。さらに、私たちがコメントをどう処理したかや、その結果をどのように反映したかも透明性をもって追跡できるようにしています。 以上のように、コンテンツ作成からユーザーとのやり取り、さらに更新や公開まで、OSCAL の仕組みや自動化を活かしていこうというのが私たちの方針です。