OSCALを活用した NIST SP 800-53 Rev.4 から Rev.5 への移行

この記事は、2022年3月にNISTが開催した「3rd Open Security Controls Assessment Language (OSCAL) Workshop 」の、Day1 Part4の公演内容をもとに、一部要約を行い、日本語に翻訳したものです。

Day1 Part4 では、C-FOCUS Software 社の President、ジェイソン・ウォーカーさんによる、NIST SP 800-53 Rev.4 から Rev.5 への移行についての講演が行われました。

ぜひ、実際の資料は動画も確認しながらご覧ください。

自己紹介

皆さん、こんにちは。C-FOCUS Software のジェイソン・ウォーカーです。本日は、どのように NIST SP 800-53 Rev.5 への移行を自動化するか、その方法をお話しします。

まずは当社と、私たちが提供しているソフトウェアソリューションについて簡単にご紹介します。それから、NIST SP 800-53 Rev.5 への移行がなぜ必要なのかをざっと確認したいと思います。OSCAL のコミュニティには、移行を支援してくれるいくつかのツールが存在し、皆さんにぜひ知っておいていただきたい。そのうえで、当社の “ATO as a Service” というソフトウェアを使った移行手順の自動化ワークフローを紹介し、最後に質疑応答の時間を設けます。

まず私自身について少しお話しします。私は C-FOCUS Software を率いており、DITSCAP（DoD の古い認証手順）から現在のリスクマネジメントフレームワークや FedRAMP のコンプライアンスに至るまで、長年この分野に関わってきました。C-FOCUS を創立して約15年になりますが、さまざまな省庁や機関でサイバーセキュリティの認証プロセスや管理を支援してきました。

そうした経験をもとに、私たちは “ATO as a Service” というソリューションを開発しています。これはソフトウェアと、どうしても自動化できない部分を補う専門家チームによるコンサルティングを組み合わせたものです。ソフトウェアの部分は、NIST SP 800-37 Rev.2 の各ステップ、すなわちリスクマネジメントフレームワーク全体を自動化する仕組みで、OSCAL 1.0 に完全対応しています。もちろん、そこから Word や Excel といった従来の形式にも書き出せるようにしており、現場でよく使われるドキュメント形式とも互換性をもたせています。

Rev.5 移行の背景と OSCAL が果たす役割

次に、Rev.5 への移行が求められる背景をおさらいしましょう。NIST SP 800-53 Rev.5 は 2020年9月23日に発行され、その後同年12月にアップデート版が出ました。また、Rev.5 のセキュリティコントロールに対するアセスメント手順をまとめた 800-53A（Rev.5）が、2022年1月25日に公表されています。OMB A-130 によれば、連邦機関はこうした NIST の標準やガイドラインを発行後1年以内に適用する必要があります。公表時期をいつ起点とするかにもよりますが、多くの機関は今がまさに移行計画を固める時期でしょう。

移行にあたって役立つ OSCAL のツールがいくつかあります。NIST は、すでに 800-53 Rev.5 カタログを OSCAL 形式で公開しており、いわゆる 800-53B（“Bravo”）に相当する低・中・高のベースラインやプライバシー基準の情報も、それぞれのプロファイルとして機械可読な形で入手可能です。これらを使えば PDF に書かれたコントロール群をそっくり OSCAL で扱うことができます。OSCAL の真価は拡張可能性にあり、Rev.4 から Rev.5 の変更点をまとめた MITRE のExcelファイルを組み合わせるなどして、元のカタログに追加のデータを紐づけることができます。

MITRE が公開している比較用の Excel には、各コントロールが “単なる編集レベルの変更” なのか、より本質的な変更があったのか、何が変わったのかといった情報が整理されています。私たちは、このスプレッドシートの情報を OSCAL カタログに取り込み、JSON の “property” として書き足す形で、移行に役立てています。

ATO as a Service を利用した移行の流れ

では、私たちの ATO as a Service ソフトウェアでどのように自動化するかを説明します。大まかにいえば、まず既存の認可関連ドキュメント（SSP などが多くは Word や Excel 形式で存在するはず）を OSCAL の SSP に変換しなければいけません。これが第1ステップです。変換には通常80～100時間ほどかかることが多いですが、これをやることで自動化の土台ができます。

続いて、第2ステップでは組織共通のコントロールやコンポーネント、機関が独自に設定しているパラメータなどを入力し、Rev.5 への移行パラメータをそろえます。そのうえで第3ステップとして、システムのカテゴリ（FIPS 199）を確認し、実際に採用すべきコントロールを洗い出します。Rev.4 ですでに使っていたコントロールをそのまま引き継ぐのか、新しく加わったコントロールを組み込むのか、廃止されたコントロールをどう扱うのかなど、見直しが必要です。

第4ステップが “自動化の本領” ともいえる部分です。Rev.5 の中でも小さな変更だけにとどまるコントロールがあれば、自動で “変更内容が軽微なのでそのまま準拠” とマークできます。MITRE の情報では、Rev.5 の全コントロールのうち 491件が比較的軽微な変更にとどまっているとされ、それらは自動でチェックをクリアできる可能性が高い。第5ステップでは、逆に大きな変更があるコントロールについて、Rev.4 と Rev.5 の記述を並べて見られるようにし、実際に実装方法を見直してどのように対応すべきか検討してもらいます。そして第6ステップとして、ここで対応できない部分については、クリックひとつで POA&M（是正計画）を自動生成するようにしています。

以上が移行ワークフローの概要です。OSCAL などを活用すれば、システム管理者やセキュリティ担当者が “目視でExcelとにらめっこしながら1つ1つ対処する” 手間を大幅に省き、本来検討すべき “実装内容の評価” や “リスク軽減策の決定” に集中できるわけです。私たちはこの機能をいま複数の政府機関向けに展開しており、1～2カ月という短いスパンで、Rev.4 から Rev.5 への移行を実際に進めています。さらに FedRAMP が扱っている GovCar のようにコントロールにスコアを付けて優先度を判断する仕組みも、今後取り入れられたら面白いと考えています。