OSCALを活用し、CISやCSAのマッピングに挑む

この記事は、2023年5月にNISTが開催した「4th Annual OSCAL Conference and Workshop 」の、Part4の公演内容をもとに、一部要約を行い、日本語に翻訳したものです。

Part4 では、Center for Internet Security（CIS）のコンテンツ開発担当副社長であるフィリス・リーさん、クラウドセキュリティアライアンス（CSA）のCTOであり、STARプログラムや認証プログラムのリードを務めているダニエル・カテドゥさんによる、各講演と、パネルディスカッションが行われました。

ぜひ、実際の資料は動画も確認しながらご覧ください（2:27:51 あたりから）。

CIS’ Security Controls in OSCAL

おはようございます。改めましてフィリス・リーと申します。今はCenter for Internet Securityのコンテンツ開発担当副社長を務めています。つまり、私の管轄には、CISベンチマークやCISクリティカルセキュリティコントロール、クラウド関連のチームなどが含まれます。CISをご存じない方のために説明すると、私たちはセキュリティのベストプラクティスを無料で提供している非営利団体です。CISには2つの側面があり、1つは運用部門で、MS-ISACやEI-ISACを運営しています。MS-ISACはMulti-State Information Sharing and Analysis Center、EI-ISACはElections Infrastructure Information Sharing and Analysis Centerの略で、これらはDHSから資金提供を受け、CISAの管理のもと、州や郡、市町村、部族政府、選挙関連組織に対してサイバー脅威情報や防御、インシデント対応、復旧などを支援しています。私が所属するのはもう1つの側面で、セキュリティベストプラクティスを作成する部門です。サイバーセキュリティの専門家のコミュニティ、つまりこの場の皆さんのような方々と協力して合意形成を行いながら、そうしたベストプラクティスを策定しています。

CISでは、ベンチマーク（セキュアな設定ガイド）とCISクリティカルセキュリティコントロールという2つの柱があります。ダウンロードの半数以上が海外からという点は私たちにとっても大きな励みですし、米国以外でも広く受け入れられていることを示しています。CISクリティカルセキュリティコントロールは、組織が主要な脅威に備えるために実装すべき手順的・技術的アクションを優先度順にまとめたセットで、2021年5月にバージョン8を公開しました。以前は全部で20コントロールでしたが、今は18に再編され、しかも優先度順になっています。最初の3つ、つまりエンタープライズ資産インベントリ、ソフトウェア資産インベントリ、データ保護は「自分の環境を知る」という点を重視しており、これらをきちんと把握したうえで後続のコントロールを適用していくイメージです。4つ目のセキュア構成管理も重要で、さまざまな調査やデータからも、セキュアな設定が脅威防御には最も有効だと言われています。

またCISクリティカルコントロールは、実装グループという形でも優先度付けがされています。もちろん1から18まで順番に並んでいますが、横断的に見ても、たとえばデータリカバリやバックアップといったコントロールに到達する段階には、すでにさまざまな対策が進んでいるはずだ、といった考え方を取り入れているわけです。IG1（Implementation Group 1）は、小規模または中規模の組織を想定しており、そうした組織は高度に重要なデータを持たないうえ、サイバーセキュリティ専任者がほぼいない、と私たちは考えています。IG2はもう少し大きな組織で、いくつかの規制フレームワークに従わなければならないところ。そしてIG3はすべてのコントロールを含んでいて、さまざまな規制に大量に対応しなければならない上、標的にもされやすいような組織を想定しています。

先ほど別の方も業界標準の話をされていましたが、私がOSCALにとても興奮している理由の1つはそこにもあります。CISのベンチマークやクリティカルコントロールは多くの業界基準・規制で参照されており、「CISコントロールを実装したらPCIやISOとの整合性はどうなるのか」「NIST CSFやSP800-53、あるいはCSAとはどう対応付けされるのか」といった問い合わせが非常に多いのです。そのため、私たちはExcelを使ったマッピングを提供していますが、皆さんご存じのとおり、スプレッドシートで管理するのは非常に手間がかかります。なぜこうなるかというと、人間が作るそれぞれのフレームワークはレイヤーや記述の粒度がバラバラだからです。CISでは、コントロールをさらに小さなサブコントロールに分割し、各サブコントロールでやることを1つに絞るようにしています。それでもフレームワーク間のマッピングは、equivalent（同等）、superset（包括）、subset（包含）、あるいは関係なし、といった形に整理するしかなく、整合をつけるのが容易ではありません。またCISクリティカルコントロールは技術的な観点に重点を置いているので、たとえば物理的なセキュリティの話などは含まれないのです。

さらに私たちにはCIS Controls Assessment Specificationという仕組みもあります。これは「導入したコントロールをどう評価すればよいか」という問い合わせが多いことから作られたもので、組織がCISコントロールやサブコントロールをどの程度しっかり実装できているかをベンダーに依存しない形で測定する方法を示すものです。CIS自身が評価サービスをするのではなく、市場にいるツールベンダーやサービスベンダーがこの仕様を活用できるようにするのが狙いです。とはいえ、こうした評価も現状ではほとんどがスプレッドシート頼みで、とても手間がかかります。そこで私たちは「何かしらの自動化手段がないだろうか」と考えていたのですが、そのときに出会ったのがOSCALでした。私自身、元NSA職員で、NISTの方々とも長く仕事をしてきましたが、OSCALは自分たちが作るフレームワークを標準化された形で機械可読に表現できる可能性があるだけでなく、そこに含まれるマッピング情報も自動化しやすいところに大きな魅力を感じています。だからこそ私はOSCALを積極的に応援したいと思っていますし、今日はこうして皆さんの前でお話しできることをうれしく思います。

CSA CCM v4 in OSCAL

おはようございます。先ほどミカエラが紹介してくれたとおり、私はクラウドセキュリティアライアンス（CSA）のCTO、ダニエル・カテドゥと申します。最初にいくつか注意点というか言い訳をさせてください。まず、昨晩ここに到着したのが遅かったので、もし私が何かおかしなことを口走っても、時差ぼけのせいだと思って聞き流してください。それから私はイタリア人なので、英語を話すときにかなり強い訛りが出ます。もし私の言っていることがわからなければ、それはまあ、皆さんの問題ということにしておきます。そして、私の手の動きにあまり注目しないほうがいいですよ。そうしないとプレゼンが終わる頃には目が回ってしまうかもしれません。では、ミカエラも言っていましたが、これから10分ほどかけてCloud Control Matrixを使った継続的ガバナンスについてお話しします。

クラウドセキュリティアライアンス（CSA）をご存じない方のために簡単に説明しますと、私たちはグローバルな非営利団体で、設立は2009年、今年で14年目くらいになります。創設当初からクラウドセキュリティに関するコミュニティを支援しようとしてきましたが、最近ではクラウド以外の近い領域にも対象を広げています。基本的に私たちが作る成果物は無料で公開していますが、もしCSAの知的財産を商業目的で利用したい場合はライセンス費用が発生することもあります。現在17万人を超える個人メンバーと、約500社の法人会員がいて、大手クラウドサービスプロバイダやセキュリティベンダー、クラウドサービスを大規模に利用する企業などが主なメンバーです。主な活動としてはクラウドを中心とするセキュリティのリサーチを行っており、さまざまなテーマごとにワーキンググループをつくって作業しています。誰でも参加は可能ですが、そのトピックに一定の知識があることが望ましいです。また、トレーニング事業も行っていて、CCSK（Certificate of Cloud Security Knowledge）やCCAK（Certificate of Cloud Auditing Knowledge）といった資格制度を提供しています。近いうちにゼロトラスト関連の資格も出す予定です。ミカエラが触れていたSTARプログラムというのは、クラウド上のセキュリティ体制を認証する仕組みで、クラウドサービスのセキュリティ状況を透明化して保証を与える目的があります。そこでもクラウドコントロールマトリックス（CCM）が重要な役割を果たします。

今日お話ししたいのは、大きく分けると「ガバナンスやコンプライアンスの疲弊」と「コンプライアンスとセキュリティの緊張関係」、そして「クラウドコントロールマトリックス（CCM）の概要」です。まず、私がこのスライドを使うのは10年ぶりくらいなんですが、当初からクラウドのガバナンスとコンプライアンスは大きな課題になると確信していました。例えばこれはAWSのコンプライアンスページに載っているロゴ群ですが、10年前はこんなに多くなかったんですよ。企業によっては何十もの規制や標準に対応しなければならない現状は、やはり無駄が大きいと感じます。業界や地域によって多少の違いはあれど、いろいろ調べてみると実際には8～9割の要件が共通しているんですね。言い回しや用語が違うだけで本質的には同じようなコントロールが求められている。それなのにそれぞれを別々に証明しなければならないというのは非効率ですし、そもそもコンプライアンスはセキュリティそのものとイコールではありません。私としては、証明のためにリソースを割くよりも、もっとセキュリティを高めることに投資すべきだと思うのですが、現実的にはコンプライアンスにかける予算がセキュリティより大きいケースが多いというのが現状です。

もうひとつ考えないといけないのは、クラウドは非常に動的な環境だということです。システム変更も頻繁ですし、実際、CISOや経営者は常に把握とコントロールを維持したいと考えています。そのために「継続的な監査」や「継続的アシュアランス」「継続的コンプライアンス」などというキーワードが出てきて、最終的には「継続的ガバナンス」へと向かおうとしています。これは技術的にも組織的にも複雑ですが、少なくとも下支えとなる共通言語が必要です。これは今回のカンファレンスでも繰り返し出てくるテーマだと思います。さらに標準化と相互運用性が欠かせません。そして、継続的ガバナンスを実現するなら、人力では無理ですから、少なくとも部分的には自動化、理想を言えばほぼ全自動化が必要になるでしょう。

そうした観点でクラウドコントロールマトリックス（CCM）を紹介します。これは名前のとおり、クラウドにおけるコントロール項目をまとめたマトリックスで、CSAが2010年、実際には2009年末頃から作り始めました。既に十数年運用されていることになりますが、各ドメインごとに97のコントロールがあり、クラウド特化というよりはクラウドに関連しつつも一般的なITにも通用する設計を意図しています。またCCMの大きな特徴の一つに、他の標準や法律・規制とのマッピングが多数用意されている点があります。なぜそんなことをしたかというと、多くの組織はすでにISOやNISTといったフレームワークを使っているので、そこへ橋をかける必要があるからです。CISとも考え方が近かったことから、私たちは両者のコントロールがどの程度重なり合い、どこに差分があるかという正式なマッピング作業を進めました。論理としては簡単で、たとえ似通っているコントロールでも完全な一対一にはならず、1対多の対応や部分的なギャップを認識する必要がある。たとえば80％は同じでも20％ほど要素が抜けているといったケースですね。こうした微妙な差異を扱えないと、OSCALを共通言語として使うにしても、実態とはズレた曖昧な共通化になりかねないと私は考えています。

さらに言えば、こうしたマッピングや差分の把握が重要なのは「継続的アシュアランス（continuous assurance）」の仕組みを実現するためでもあります。リスクの高いシステムを運用している場合、例えばSOC 2やISO 27001、あるいはCSAの認証があっても、年1回の審査だけでは不十分なことがあるかもしれない。そういうときこそ「継続的に状況を把握する」仕組みが有効になってくるわけです。今からパネルディスカッションに移ると思いますが、その前にもし質問があれば少しお受けします。

パネルディスカッション

それでは、このままパネルディスカッションに進みたいと思います。ご覧のように、フィリスとダニエルが椅子に座っているのは、OSCALのマッピングモデルについてのパネルディスカッションを行うためです。ここで私の同僚ダニエル、あ、彼はクリス・コンプトンと呼ばれていますね（ちょっと混乱させましたか？）。彼は私たちの上級ITスペシャリストで、OSCALチームのメンバーです。先ほど私が触れた「Defineリサーチ」や、そこで使われる方法論を整備した人物で、現在はOSCALのマッピングモデル草案を次の段階へ進める作業を担当しています。それでは、これ以上の前置きは抜きにして、クリスにマイクを渡します。パネルの皆さん、よろしくお願いします。

NIST クリスさん： 改めましておはようございます。今日はありがとうございます。私はこの10年ほど医療ITの分野に携わってきましたが、マッピングにはとても思い入れがあります。規制の厳しい環境に入ってくる組織は、多くの場合、複数のフレームワークへのマッピングをこなさなくてはならず、そのためにプロジェクト進行がとても困難になってしまうのを何度も見てきました。スプレッドシートが山のようになって、まさに悪夢でしたね。だからこそ、今回のようにマッピング分野が進展していくのは素晴らしいことだと思います。では、最初の質問ですが、いま進められているマッピング作業はすでに公開されているのでしょうか。ご存じのとおり、OSCALのマッピングモデル自体はまだ草案段階だと思いますが、そこはどうでしょう。

CIS フィリスさん： CISの場合、バージョン8と7.1の両方のCISコントロールがOSCAL形式でGitHub上に公開されています。それから、CIS Controls Assessment Specification（評価仕様）もOSCAL形式で公開しています。さらにCSAとのマッピングも、GitHub上でOSCALフォーマットとして自由に参照できます。

CSA ダニエルさん： CSAも同じように、当団体のウェブサイトやGitHubのリポジトリでCloud Control Matrix（CCM）バージョン4をOSCAL形式で公開しています。そこにはCISコントロールおよびNIST SP 800-53改訂5とのマッピングも含まれています。ただ、他の標準とのマッピングがそこに含まれていない理由は、単にまだその標準をOSCAL形式で提供していないから、という点が大きいですね。なので、この場から改めて呼びかけたいのですが、各フレームワークの管理元には、ぜひOSCAL版を作っていただきたい。先ほど話に出た「共通言語」のビジョンを実現するには、公式かつ権威あるOSCAL版データが必要なんです。どうかご協力をお願いします。

CIS フィリスさん： 今まさにダニエルが言ったことに私も強く同意します。私たちはNISTのフレームワーク、たとえばSP 800-53のようにOSCAL形式で提供されているものについては、すでにそれを利用してマッピングを行っています。でも、CISのコントロールは他にも約30のフレームワークとマッピングしていますし、それ以外に何十ものフレームワークをConfluence上で管理して優先順位をつけたりしています。なので、フレームワーク管理者のみなさんが自分たちのフレームワークをOSCAL化してくれれば、私たちにとっても非常に助かりますし、コミュニティ全体にとってもメリットが大きいはずです。

NIST クリスさん： さて、フレームワークは公開されているとして、次のステップとしてはどうやってそれを組織に組み込み、運用レベルで活用していくのでしょうか。それを進めるのは誰で、どんな形で推進されるんでしょう？

CIS フィリスさん： CISとしては、市場を支援する立場をとっています。なので、具体的にはツールベンダーがOSCAL形式のフレームワークを取り込みやすくなるよう働きかけています。もう一つ、OSCALの利点として、フレームワーク側がバージョン8から8.1、9へと更新されたり、CCMが4.0から4.1へ進んだり、PCIが4から5へ移行したときに、OSCALにはユニークIDという考え方があるので、コントロールの意図が変わらない限りはマッピングも大きく書き換える必要がありません。スプレッドシートをもう一度作り直して「どこが変わったか」という差分を見せるような手間が要らないんです。これが大きな利点ですね。ですので、そういう観点からもフレームワークやマッピングをOSCAL形式にして、コミュニティが自動化しやすいようにするのが理想だと思います。

NIST クリスさん： ダニエルはいかがですか？

CSA ダニエルさん： フィリスの言ったことに全体的に同意します。ただ、継続的なガバナンスを実現し、複数フレームワークを細かく追っていくには、私たちが現在やっていることはまだ「入り口」に過ぎないと感じています。フレームワーク同士のコントロールを整合させる作業は重要ですが、それだけで完全にカバーできるわけではないです。本当に詳細な部分、つまりコントロールを技術的なレベルまで落とし込んで、AWSだとかGCPだとかAzureだとか、マルチクラウドの各プラットフォームでどう実装するかというところまで踏み込まないと、ちゃんとした「継続的な」コンプライアンスやアシュアランスは難しいでしょう。OSCALそのものはそうした高度なレベルにも対応できるよう設計されているので、そこに期待していますね。

NIST クリスさん： ここで簡単に補足すると、まさにその技術を支えるのが現在ドラフト状態の「マッピングモデル」です。これを正式にOSCALの一部としてリリースする前に、まだ少し手直しをする予定です。NISTとしては「入れもの」を提供しているだけで、実際のマッピングは各フレームワークの管理者や組織の方々がOSCALのモデルを使って行うことになります。先ほどの議論でも出ましたが、フレームワーク間で用語がバラバラだったり表現が違っていたりするので、OSCALはそこを統一する「きっかけ」を作ってくれるのではないでしょうか。逆に言えば、OSCALがあるからこそ「そもそもこのフレームワークの文言ってどういう意味？」という会話が生まれて、今後のフレームワーク作成時の文言にも影響があるんじゃないかという気がするんですが、そこはいかがですか？

CIS フィリスさん： そうなるといいな、と正直思っていますが、完全に同じ言葉を使うようになるのは難しいでしょうね。たとえば産業制御システム（ICS）系のフレームワークはすごく特殊な領域ですし、国ごとに規制も違う。でも、OSCALがあることで、少なくとも「マッピングを共通の枠組みで議論する」ことは可能になります。たとえばCISとCSAが共同でマッピングするときに、「CISコントロールの意図はこういうものです。あなたたちのコントロールの意図は何ですか？実装例はどうなりますか？」と擦り合わせられるようになりました。そうするとお互いに学び合って、「じゃあ我々のマッピングのやり方を少し変えましょうか」といった改善が生まれる。それは最終的に規制を受ける立場の組織にとってもメリットになるので、そうした方向性を広げていきたいですね。

NIST クリスさん： なるほど。技術的にコントロール同士を対応付ければいいというだけでなく、もっと上流にある規制の表現まで含めて調整が必要ということですね。そう考えると、いくら用語の定義をそろえようとしても、人間同士の協調作業が要りますし、そこにOSCALのマッピングが役立つわけですね。

CSA ダニエルさん： そこはちょっとだけ意見の違いがあるかもしれませんが、私は「OSCALがフレームワークの文言を統一させる」とは考えていません。むしろOSCALはメタ言語であって、各フレームワークが自分たちの好きなように書きつつ、それらを一括して変換可能にする、というほうが自然だと思います。私の母国イタリアには標準語のイタリア語がある一方で、地域ごとに20以上の方言があります。でもそれらも大切な個性で、無理に全部を同じ言葉にするより、それらをつなぐ「翻訳装置」があればいい。OSCALはそういう存在であってほしいというのが私の希望です。

NIST クリスさん： そろそろ残り5分になりましたので、会場からの質問を取り上げられるならいくつか見てみましょう。「OSCALコンテンツを作るとき、どんなツールを使っているのか？」という質問がありますが、どうでしょう。

CSA ダニエルさん： ええっと、私たちもそういうツールをいくつか使っていますが、正直どれも自作のスクリプトだったりします。

CIS フィリスさん： そうですね。フリーウェアで提供されているものもありますし、CIS内部でもPythonスクリプトを使って作っています。

NIST クリスさん： NISTとしても多くは手作業やエディタで行っていますが、公式サイトにOSCAL関連ツールの一覧ページがあり、そこに挙げられたオープンソースのソフトウェアなどもあります。NISTとして特定のツールを推奨することはありませんが、今日の後半でもいくつかの事例が紹介されると思うので、そちらをぜひチェックしてみてください。 「ExcelからOSCAL対応のツールへスムーズに移行できるか？」という質問に関しては、まだ成熟していない分野かもしれませんね。

CSA ダニエルさん： そうですね、まだこれといった答えはなくて、各社が工夫している段階じゃないでしょうか。

…（IBMの方から、ExcelベースとOSCAL間の変換を扱えるTrestle Complianceなどのツールが存在する旨のコメント。さらに、OSCALを「共通の看板」にすることで、各規制が独自解釈を持ちながらも合意形成を容易にする、といった趣旨の発言）

NIST クリスさん： オンライン視聴の方がいらっしゃるので、要約すると、「ExcelからOSCALへの変換を支援するツールは既に存在し、OSCALは共通言語として各規制の独自性を損なわずにやり取りをスムーズにする」というご意見ですね。

CSA ダニエルさん： その通りだと思います。

CIS フィリスさん： はい、まさにそうですね。

CSA ダニエルさん： OSCALは多様なフレームワークがそれぞれの表現を続けることを妨げず、それらを結びつける役割を担うと考えています。

NIST クリスさん： 私自身、ヘルスケアの世界で「FHIR」という標準を使ったデータ共有を見てきましたが、OSCALも同じように、いろいろなシステムや組織間で「どういう形式のデータを期待すればいいか」を明確にし、コラボレーションを推進できる存在だと思います。では、時間もそろそろなので、これでパネルは終了したいと思います。皆さん、ありがとうございました。