GitHub Actionsを利用したOSCALモデルの操作デモ

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

Day1 Track1 では、NIST チームのアレクサンダー・シュタインさんによる、OSCALを使って自動化ヒーローになるための流れについての講演が行われました。

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

自己紹介

私は NIST チームのアレクサンダー・シュタインと申します。本日のセッションは録画され、後ほど視聴できるようになります。今回のテーマは “OSCAL from Zero to Automation Hero” というタイトルで、OSCAL を使って情報セキュリティプログラムを自動化する方法をお話しします。セキュリティ・コンプライアンス、それらの交差点にかかわる方や、サイバーセキュリティへの情熱がある方が多いかと思います。

コントロール

まず “コントロール” という概念についてですが、システムをどう安全に保ち、どう実装すべきかという要求事項の1つ1つを “コントロール” と呼ぶのが一般的です。サイバーセキュリティ産業では、このコントロールの管理がとても大変だと痛感されていることでしょう。

ここには大きく2種類の人々がいるかもしれません。左側は政策策定者やベースラインの著者であり、組織のセキュリティポリシー全体を管理しています。数多くのコントロール同士の関係や、バージョン違い、定期的な更新など、とても複雑な作業があります。右側にはシステムエンジニアやオペレーション担当、いわゆる“キーボードを叩く”現場の人々がいて、組織内の指針や NIST などの外部団体が出すガイダンスを取り込み、運用する立場です。OSCAL 用語では、コントロール群を “カタログ” と呼び、それらを機械可読かつ構造化した形にまとめます。しかし OSCAL がなければ、Word や Excel などで扱う複雑な管理が必要になります。

さらに、政策担当寄りの立場でも、開発者としての深い経験がない場合、そもそも自動化自体がハードルに感じられるかもしれません。OSCAL はコントロール情報を機械可読にし、エンジニアリング思考を取り入れる際に大きな助けになります。とはいえ慣れない方には「これは違う世界だ…」と感じるかもしれません。そこで本日、ご紹介するデモでは、無料で使えるツールや GitHub Actions などを使い、“ゼロ” から “オートメーションの英雄” へと移行するプロセスを実演してみたいと思います。

デモ方針の説明

リスクマネジメントフレームワーク（NIST 800-53）を例に使ってみますが、ISO や PCI DSS、HIPAA、CMMC などでも考え方は同じです。リスクマネジメントフレームワークに含まれるコントロールを “カタログ” と呼び、それを「OSCAL プロファイル」で部分的に取り込んだり、編集したりしていくデモを行います。具体的には GitHub というコード共有プラットフォームを使って、テンプレートリポジトリから派生させる形で、いくつかの XML ファイル（プロファイル）を置き、それを自動的にバリデーションしてビルドし、結果として JSON や YAML、XML の出力を得る流れを見せていきます。仮に「重要連邦機関（Important Federal Agency）」と名づけた架空の組織があると想定しましょう。

プロファイルの実例①：1つのコントロールだけをインポート

まず、既存の 800-53 全体のカタログを参照しつつ、「AC1」コントロールだけを取り込みたいという例をやってみます。GitHub 上のテンプレートリポジトリを複製（テンプレートから新規作成）し、そこに profile.xml のようなファイルを用意し、中身には「AC1 だけインポートする」設定を書きます。実際には数行の XML コードだけです。これを Pull Request としてコミットすると、GitHub Actions が走り、自動的にそのプロファイルをバリデーションし、生成されたカタログ（AC1 のみを含む）が JSON, YAML, XML の各形式で出力されます。

プロファイルの実例②：全コントロールをインポート

次に同様のやり方で、カタログの全コントロール（400 以上）を丸ごとインポートするプロファイルを作ります。こちらも、インポート先で「除外しない」設定に変えるだけで、同じように Pull Request を作成すれば、数百にもおよぶコントロール群が一気にマシン可読な形式でビルドされます。

プロファイルの実例③：一部のコントロールだけ除外する

より実際的なシナリオとして、ベースラインとしてほとんどのコントロールを採用するけれど、特定のコントロールを外す、というケースを想定します。ここでもわずか数行の “exclude” 記述をプロファイルに加えるだけで、インポートされるコントロールを制御できます。

パラメータの設定

さらに、コントロールには“パラメータ”と呼ばれる組織独自の要素（例：監査の頻度など）を設定する必要がある場合があります。NIST のカタログでも「ここは組織が値を決める」という項目があります。そこで、set-param という形で「ポリシーは2年おきに見直す」「手順は半年ごとに見直す」といった具体値を埋め込みます。これも XML ファイルで数行書き足して Pull Request すれば、自動化パイプラインがビルドとバリデーションを行い、最終的にパラメータを組み込んだカタログが生成されます。

多くの組織では、標準のカタログ（NIST など）だけでなく、独自要件や補足のテキストをコントロールに追加したい場合があります。これも “modify” や “alter” といった要素を使って、たとえば「AC1 の末尾に、当組織固有の一文を挿入する」という操作を簡単に記述できます。これも同じ流れで Pull Request を投げ、GitHub Actions が自動処理を行います。

バージョンアップや新ファミリが登場したら

NIST が後日、新しいコントロールファミリを追加したり、カタログをバージョンアップすることは十分ありえます。Revision 4 → 5 の際も大きな変更がありました。OSCAL を使っていれば、その更新版のカタログを取得して、自分たちのプロファイルを参照先（import 先）だけ指し替えれば、簡単に新コントロールを取り込んだり既存コントロールを更新できます。Word や Excel の全体を読み直して人力で変更点を拾うより、ずっと早く、かつ変更をトラッキングしやすくなります。

まとめ

このように、OSCAL は「カタログ（コントロール群）」と「プロファイル（それをどう取り込んで編集するかの宣言）」を組み合わせ、マシン可読なパイプラインで処理できるようにします。開発者・非開発者問わず、数行の XML をいじるだけでコントロールのサブセットや独自テキスト、パラメータの設定などを柔軟に行えるようになります。

組織としては、半年～1年ほどかけて実際のワークフローでどう使うか試行し、ツール評価や運用方針を固めるとよいでしょう。2年くらい先には、OSCAL を実装したカタログ管理ツールを本格的に導入し、外部からの更新や内部ポリシーの変更をすばやく反映し続ける環境を整えるのが理想です。NIST や CIS などが OSCAL 形式の最新カタログを提供するようになれば、こちらも同様の仕組みで迅速かつ確実にバージョンアップに対応できます。

以上、駆け足でしたが、OSCAL を使ったカタログ管理・自動化のデモとポイントを紹介しました。私がいま作ったサンプルのリポジトリは後ほど整理し、皆さんが参考にできるようにしたいと思います。何かご質問があれば、この後の時間や他のセッションでお受けできるかと思います。ありがとうございました。