NISTが開発する、セキュリティ対策をJSON等で記述する技術「OSCAL」とはなにか
こんにちは。日本初のISMSオートメーションツール「SecureNavi」を提供している、SecureNavi株式会社の井崎です。
弊社は、ISMS（ISO/IEC 27001）を始めとした様々なコンプライアンス要件に対し、企業や組織が、簡単・効率的に準拠できるようなプロダクトの開発を行っています。当然、海外を含めたセキュリティコンプライアンス業界の動向には目を光らせていますが、そんな中、個人的に興味を持っているのが、最近登場した「OSCAL」という新しい技術（言語）です。OSCALを使えば、組織の情報セキュリティ対策をJSONやXMLなどの機械判別可能なフォーマットで表現でき、その情報を利用することで、監査活動を効率化することが可能です。この記事では、そんなOSCALの基礎と、その思想、今後の展開や、日本市場への影響について紹介します。
# OSCALとはなにか
OSCALとは「Open Security Controls Assessment Language」の略称です。世の中には様々な企業がありますが、各企業がどのようなセキュリティ対策を実施しているかについて、それを表現するための画一的なフォーマットは存在しません。そのため、各社がExcelやWordを利用して、独自のフォーマットで管理しています。また、これらのExcelやWordの量は、準拠する必要があるコンプライアンス要件が増えれば増えるほど、複雑になってしまいます。このことが理由で、企業間取引におけるセキュリティチェックの煩雑化や、ISMS審査を始めとした監査・審査活動の非効率化につながっています。
OSCALの基本的なアイデアは、各種のコンプライアンス要件（例えばISMS）で求められるセキュリティ対策や、各企業が実施しているセキュリティ対策を、JSON/XML/YAMLといった機械識別可能なフォーマットで表現することです。これによって、組織が特定のコンプライアンス要件に準拠するための活動や、それを監査する活動を、大きく効率化することが可能です。
アメリカの政府機関が、民間のクラウドサービスを採用するときのガイドライン・制度であるFedRAMPでは、すでにOSCALに対応する動きを見せています。2021年7月には、FedRAMPの要求事項をOSCALの形式で表現したコードや変換ツールがGitHubに公開されました。一般的に、FedRAMPに準拠し、第三者評価機関からの評価を受け、認証を取得するには、非常に大きな工数がかかると言われてます。そのため、OSCALのような新しい技術の導入が、これらの工数の簡略化につながることが期待されています。
# OSCALのコンセプト
OSCALは、JSON/XML/YAMLなどのフォーマットで表現される「言語」です。つまり、OSCALのコンセプトを理解するためには、言語の仕様を理解する必要があります。
OSCALは、大きく3つのレイヤーから成り立ちます。さらに、各レイヤーは、モデルと呼ばれる概念の組み合わせとして表現されます。3つのレイヤーは、それぞれが「管理策(control)レイヤー」「実装(implementation)レイヤー」「評価(assessment)レイヤー」と呼ばれており、レイヤー間は一方向の依存関係を持っています。つまり、実装レイヤーは管理策レイヤーに依存しており、評価レイヤーは実装レイヤーに依存しています。
以下では、低レイヤーから順番に概要を説明します。
## 管理策レイヤー
このレイヤーには、管理策、すなわちセキュリティ対策が記述されます。このレイヤーは、カタログモデルと、プロファイルモデルと呼ばれる2つのモデルで成り立っています。
カタログモデルとは、NIST SP 800-53 や ISO/IEC 27002 といった規格等で定められたセキュリティ管理策を、決められたスキーマ定義に基づいて標準化したモデルです。他のすべてのOSCALモデルの基礎となるモデルで、他のモデルで利用される管理策は、元をたどると、全てこのカタログモデルに帰着することができます。
・カタログモデルの解説
・カタログモデルのスキーマ定義
・カタログモデルを作る（ISO/IEC 27001 を例に）
また、プロファイルモデルとは、カタログモデルに記載された管理策の「組み合わせ」を表現するモデルです。業界人にとっては「ベースライン」を表現するモデルだと考えるとわかりやすいでしょう。このモデルには「インポート」「マージ」「モディファイ」という、3つの重要なコンセプトがあります。インポートでは、どのセキュリティ管理策（カタログモデルに記載されています）をプロファイルに含めるかを決めます。マージでは、類似の管理策があった場合、それらをどう統合するかを表現します。モディファイでは、カタログモデルに記載された管理策の内容やパラメータを微修正することができます。
・プロファイルモデルの解説
・プロファイルモデルのスキーマ定義
## 実装レイヤー
このレイヤーでは、管理策レイヤーで定めた管理策を、組織がどのように実装（インプリメンテーション）しているかが記述されます。このレイヤーは、コンポーネント定義モデルと、システムセキュリティ計画モデルの、2つのモデルから成り立っています。
コンポーネント定義モデルとは、特定のハードウェアやソフトウェアなどを対象とし、それらに実装されている管理策の情報を提供しています。一般的に広く利用されているハードウェアやソフトウェアには、すでにセキュリティ管理策が実装されていたり、実装を助ける機能が用意されています。それらの情報をあらかじめコンポーネント定義モデルに記載しておくことで、後に登場するシステムセキュリティ計画モデルの構築が楽になります。このコンポーネント定義モデルは、ハードウェアベンダーやソフトウェアベンダーによって提供されることが期待されています。
・コンポーネント定義モデルの解説
・コンポーネント定義モデルのスキーマ定義
・コンポーネント定義モデルを作る（MongoDB を例に）
また、システムセキュリティ計画モデルとは、システムに対する管理策の実装状況を説明するモデルです。管理策レイヤーで定義されたプロファイルモデルをインポートし、それらの管理策がどのように実装されているのかを記述します。また、このとき、対象のシステムを構成するハードウェアやソフトウェア（これらを「コンポーネント」と呼びます）に対して、事前に定義されたコンポーネント定義モデルがあれば、それをインポートすることで、作業を簡略化することができます。このモデルは、英語表記（System Security Plan Model）の頭文字をとって、SSPモデルと呼ばれることもあります。
・システムセキュリティ計画モデルの解説
・システムセキュリティ計画モデルのスキーマ定義
## 評価レイヤー
このレイヤーは、実装レイヤーで表現された内容が、システムにおいて正しく実装されているかを評価（アセスメント）し、その結果や、残留するリスクを表現するためのレイヤーです。このレイヤーは3つのモデルから成り立ちます。
評価計画モデルは、SSPモデルに対して、評価（つまり、監査や診断など）を行う際の計画を示したモデルになります。SSPモデルをインポートした上で、評価の対象となる管理策やシステム、評価のために利用するツール（例えば、具体的な脆弱性診断ツールの名前）、評価を行う上で必要なタスクなどを記述することができます。SSPモデルは、主にシステムの所有者や、システムのセキュリティ計画を策定する人によって作成されますが、この評価計画モデルは、実際に評価を行う人（すなわち、脆弱性診断をする人や監査人）によって作成されます。
また、評価結果モデルは、評価計画モデルに対して、実際に評価を行った結果を記述するモデルです。評価の結果や、評価によって検出されたリスク、評価所見などを記述することができます。リスクはステータス管理を行うことが可能で、初期状態は「open」になっています。また、リスクには発生可能性と影響度といった値を付与することができます。この評価結果モデルは、「スナップショットインタイム評価」と呼ばれる、年に1回などの間隔で行われる評価の結果を記録できることはもちろん、「コンティニュアス評価」と呼ばれる、ツールを活用した高頻度かつ継続的に実施される評価も記録できる仕組みになっています。
最後に、行動計画とマイルストーンモデルです。このモデルでは、評価結果モデルで検出されたリスクをコピーして、そのリスクに対する対応の計画や、リスクのステータス管理を記述することができます。英語表記（Plan of Action and Milestones Model）の頭文字をとって、POA＆Mモデルと呼ばれることもあります。
・行動計画とマイルストーンモデルの解説
・行動計画とマイルストーンモデルのスキーマ定義
# OSCALの今後の展開
OSCALの言語仕様はオープンであり、特定のベンダーや機関が専有するものではありません。現在、OSCALチームでは、多くのGRCツールベンダーと協力して、OSCALをベースとした機能開発を進めているようです。すでに、IBMを始めとした複数のベンダーが開発を行っています。
また、現在OSCALは、FedRAMPの基準に対応していますが、それ以外の様々なガイドラインへの対応も予定されています。たとえば、ISMS認証の認証基準が参照する管理策として有名な「ISO/IEC 27002」については、当該規格を作成している ISO/IEC JTC1 SC27/WG1 というワーキンググループがOSCALへの対応を計画していると、OSCALプロジェクトのリーダーを務める Michaela Iorga が、ブログで明らかにしています。また、クレジットカード情報の保護を目的としたセキュリティ基準である「PCI-DSS」への対応も進めていきたいと、OSCALプロジェクトのテクニカルディレクターである David Waltermire が、2021年2月に行われたワークショップで明らかにしています。
# 国内のセキュリティコンプライアンス市場への影響
日本国内での動きは、まだ観測できていません。JIPDECの電子情報利活用研究部レポート（2020年07月16日）に、OSCALに関する言及がありますが、それ以外では日本語で書かれた文献はほぼありません。
何か分かり次第、追記する予定です。セキュリティコンプライアンス領域におけるDXとも言えるこの動きは、日本でも活発になってほしいですね。ISMAPも開始されたことですし...
# 【PR】 採用中です！
弊社では、OSCALを含めたセキュリティコンプライアンス領域の動向をウォッチし、自社のプロダクトへの実装を進めています。最近リリースしたリスクアセスメント機能は、OSCALに完全準拠までは行かないものの、その考え方を大きく取り入れたシステム構成になっています。
セキュリティコンプライアンス領域に興味がある方、情報交換したい方、また、一緒に弊社で働くことに興味がある方がいましたら、以下からお気軽にご連絡ください！お話しましょう！
弊社の採用情報は以下です。
# 参考文献
この記事が気に入ったらサポートをしてみませんか？