コンテナとKubernetesのためのNIST 800-53コンプライアンス

本文の内容は、2021年9月22日にVicente Herrera Garcíaが投稿したブログ(https://sysdig.com/blog/nist-800-53-compliance）を元に日本語に翻訳・再構成した内容となっております。

このブログでは、NIST 800-53準拠を実現するために必要な様々な要件と、コンテナやKubernetesのNIST 800-53要件を継続的に検証するためにSysdig Secureがどのように支援できるかについてご紹介します。

NIST 800-53 rev4は2021年9月23日以降、非推奨となります。
 バージョンの違いについては以下をご覧ください。 →

NIST 800-53準拠とは？

NIST（National Institute of Standards and Technology）は、イノベーションと経済的競争力を促進するための技術、測定基準、標準を開発する、規制を受けない政府機関です。NISTには、セキュリティに関するいくつかの出版物があり、その中に「NIST Special Publication (SP) 800-53: Security and Privacy Controls for Information Systems and Organizations」があります。

米国連邦政府との取引を想定している請負業者やサプライチェーン企業は、NIST 800-53を使用して、サイバーセキュリティにおける自社の対応能力を証明しています。

NIST 800-53コンプライアンスのコストへの示唆と影響

コンプライアンスの検証は、アプリケーションの迅速な提供を妨げる最大の要因となっています。規制当局は、コンプライアンスを怠った場合に金銭的なペナルティを課すようになってきています。

調査では次のように示されています：

• コンプライアンス違反による企業の年間コストは、平均1,480万ドルに上ります。
• 一方、コンプライアンスにかかるコストは平均550万ドルであることがわかりました。

Kubernetesは動的な環境であるため、アセットがNIST 800-53のコンプライアンスから外れたことを検知するのは困難です。NIST 800-53のガイドラインをこの新しい環境に明確にマッピングしなければ、チームはコンプライアンス要件を満たしていることを証明できません。その結果、NIST 800-53の監査に対応することは、費用のかかる演習となり、クラウド・チームのアプリケーションデリバリーを遅らせることになります。Kubernetesのコンプライアンスには、新しいアプローチが必要です。

お客様のチームは、コンテナ化されたワークロードに対するコントロールの明確なマッピングと、コンプライアンスを継続的に追跡する能力を持つ必要があります。これにより、セキュリティリスクを管理し、セキュリティ監査に合格する能力に自信を持つことができます。最終的には、コンプライアンスがクラウドの導入を妨げないようにして、ビジネスにおけるクラウドアプリケーションを迅速に提供できるようにする必要があります。

改訂5版と改訂4版の違いは何ですか？

SP 800-53 リビジョン 5 ファイナルは、2016年からドラフト文書となっていましたが、2020年9月23日に発行されました。これは、2015年に発行され、2021年9月23日に正式に撤回されたリビジョン4に取って代わるものです。NIST 800-53に準拠しようとしている組織は、どちらかの改訂版を使用することが認められる1年間の重複期間があったため、新しい規格に適応することができました。

リビジョン5の変更点は以下の通りです：

• コントロールの説明が更新され、責任者に焦点を当てるのではなく、期待される結果に焦点を当てるようになっています。
• すべての個々のコントロールに特徴的な名前が付けられ、情報セキュリティとプライバシーが単一の目標として統合されています。
• 2つの新しいファミリーが導入されました。「処理と透明性」と「サプライチェーンのリスク管理」です。
• ベースラインコントロールは、連邦政府機関に特化した新しい文書「NIST SP 800-53B」に移され、他の組織が独自のベースラインを導入できるようになりました。
• 全体として、管理項目数は513から1189に増加しています。

変更点の全リストは、NISTのブログ記事のアナウンスで確認できます。

コンテナとKubernetesでNIST 800-53のコンプライアンスが異なるのはなぜですか？

NIST 800-53は、”敵対的な攻撃、ヒューマンエラー、自然災害、構造的な障害、外国の諜報機関、プライバシーリスクなどの多様な脅威やリスクから、組織の運営や資産、個人、他の組織、国家を保護するためのセキュリティおよびプライバシーコントロールのカタログ “と定義されています。

これは、非常に幅広い分野をカバーするコントロールで、コンテナやKubernetesのセキュリティに特化したものではありません。私たちはその提言を、これらの技術に関する具体的な内容に「翻訳」しなければなりません。

もう1つの課題は、他の規格（NIST 800-190は18、PCI DSSは30、SOC 2は47）に比べてコントロールの数が膨大（513）であるため、この規格には特別なアプローチが必要であることがすぐにわかります。

また、おすすめの読み物として、NIST SP 800-53A “Guide for Assessing the Security Controls in Federal Information Systems and Organizations” という別のガイドラインがあります。これは、セキュリティ・コントロールのベースラインを提供しており、スタート時に関連するコントロールを選択するのに役立ちます。以下にコントロールをまとめ、コンテナ、Kubernetes、クラウドに関連するものを特定しました。

表: NIST 800-53（Rev.5）のファミリー、コントロールの数
クラウド、コンテナ、およびKubernetesのセキュリティに関連するコントロールの数と割合

*注釈：Sysdig Secureでこれらのコントロールをすべてカバーすることができます。

NISTが提供する完全なXMLまたはタブ区切りのコントロールリストを扱うのは大変なことです。最終的には対処する必要がありますが、最初のうちは、コンテナやKubernetesのセキュリティに大きな影響を与えられる部分に時間とリソースを投資する方が良いでしょう。例えば、このガイドを作るために、私たちはまず各コントロールファミリーを素早く分析し、コンテナやKubernetesのセキュリティに関連性の高いものに焦点を当てました。

すべてのファミリーとコントロールの詳細な分析は、最後のステップとして残しておくことをお勧めします。

NIST 800-53コンプライアンスは、コンテナやKubernetesのセキュリティにどのようにマッピングされるのか？

ここでは、コンテナやKubernetesのセキュリティに関連性の高いコントロールファミリーを、これらの技術に適用される分野の例とともに紹介します。

アクセスコントロール
コントロールの概要：ユーザーアカウントがどのように生成され、保護され、制御され、承認されるか。

クラウド、コンテナ、Kubernetesの場合：プロセスやユーザーが、割り当てられたユーザーアカウントやサービスアカウントのセキュリティ制約を超えようとしていることを検知する機能を実装する。コンテナイメージやランタイムレベルで行う。

監査とアカウンタビリティ
コントロールの概要：アクティビティの監査をどのように生成・保存し、アラートをどのようにトリガーし、レビューし、対応するか。

クラウド、コンテナ、Kubernetesの場合：Kubernetesのイベントや一般的なセキュリティ問題の監査を可能にするツールを設定する。インフラストラクチャーの一般的なセキュリティ状態を示すレポートを生成する。

評価、認証、監視
コントロールの概要：セキュリティ評価とコンプライアンス、ユーザー認証、セキュリティモニタリングをどのように実施するか。

クラウド、コンテナ、Kubernetesの場合：セキュリティツールの使用状況とその機能、デジタル資産のセキュリティ態勢を評価し、ユーザー認証手順を見直し、リスクを継続的に監視する。

識別と認証
コントロールの概要：ユーザーの識別と認証に関するセキュリティ対策。

クラウド、コンテナ、Kubernetesの場合：クラスターに参加する不正なノードや、クラウド環境で操作する企業以外のアカウントのように、操作時に認証をバイパスすることをチェックします。

リスク評価
コントロールの概要：システムの脅威と脆弱性を特定し、被害の可能性と大きさを判断する。

コンテナとKubernetesの場合：コンテナの脆弱性スキャンとベンチマークを自動化し、インフラ全体のセキュリティ態勢をグローバルに把握する。

システムと通信の保護
コントロール概要：cypherメカニズムを実装し、データやコンポーネントの偽造を防ぐ方法。

クラウド、コンテナ、Kubernetesの場合：コンテナ内の正当なシステムになりすましたり、変更しようとする試みを検出して対抗する仕組みを実装し、ランタイムにコンテナイメージからのドリフトを検出する。

コンフィギュレーション管理
コントロール概要：システムのベースライン構成をどのように構成管理下に置き、それに対する変更を実装前にどのようにテストするか。

クラウド、コンテナ、Kubernetesの場合：コンテナイメージのセキュリティや設定ミスの問題をテストする。CIパイプラインで行うか、デプロイする直前に行う。

システムと情報の完全性
コントロール概要：システムの欠陥を特定、修正、報告するためのメカニズム。

クラウド、コンテナ、Kubernetesの場合：イメージスキャンを備えたCI/CD用の集中型パイプラインを導入する。パイプラインを迂回するデプロイメントを遮断できるアドミッション・コントローラーを導入する。コンテナの実行中にのみ検出可能な異常な動作のためのランタイム検出を設定する。通知と報告のメカニズムを実装する。

システムおよびサービスの取得
コントロール概要：開発者が提供するシステムについて、開発者が品質メトリクスと保証を行う。

クラウド、コンテナ、Kubernetesの場合：前述のポイントと同様に、コンテナにデプロイされたソフトウェアの設定ミスや脆弱性のチェックに注力する。

インシデント対応
コントロール概要：インシデント対応のポリシーの特徴と、インシデントをどのように処理するか。

クラウド、コンテナ、Kubernetesの場合：コンテナやKubernetesで発生したセキュリティイベントが正しく通知され、フィルタリングされ、提供された情報によってインシデント対応作業が容易になるようにする。

その他のファミリー
NIST 800-53 rev.5には、コンテナとKubernetesの範囲外でも関連する可能性のあるコントロールを定義する他のファミリーが含まれています。他の項目がコントロールされていることに自信が持てたら、残りのファミリーやコントロールの全リストの詳細を確認することをお勧めします。

Sysdig Secureは、NIST 800-53コンプライアンスの検証をサポートします

Sysdig Secureは、コンテナやKubernetesのセキュリティに関連するすべての統制をカバーするNIST 800-53コンプライアンスの検証を支援し、コンプライアンスがクラウド導入の妨げにならないようにします。ここでは、NIST 800-53コントロールへの対応の例をいくつかご紹介します。

例1：Kubernetesのネットワークトポロジーマップ – NIST 800-53の主要コントロールAC-4

“組織で定義された情報フロー制御ポリシーに基づいて、システム内および接続されたシステム間の情報の流れを制御するための承認された権限を施行する。”

Sysdigは、お客様のインフラストラクチャー上のすべてのホスト、コンテナ、プロセスのトポロジーマップを動的に生成し、それらがお客様のネットワークの内外で行うあらゆるネットワーク接続をマッピングします。これらのトポロジーマップは、論理的なサービスとその接続方法を示すようにカスタマイズすることもできます。

例 2：資産インベントリ管理 – NIST 800-53 コントロール AU-6(5)

“監査記録の分析を、脆弱性スキャン情報、パフォーマンス・データ、システム監視情報の分析と統合して、不適切または異常な活動を特定する能力をさらに強化する。”

Sysdigには探索機能が付いていて、そのシステム上で実行されているすべてのホスト、コンテナ、またはメタデータでグループ化されたあらゆるプロセスを表示してくれます。このテーブルを使って、すべてのシステムコンポーネントを好きなように切り刻むように情報を確認することができます。

例3：カード会員データのアクセス制御 – NIST 800-53構成管理コントロールCM-3b

“組織は、提案された構成管理されたシステムへの変更をレビューし、セキュリティとプライバシーの影響分析を明確に考慮して、そのような変更を承認または不承認する。”

Sysdigは、お客様のデプロイメント定義にあるPod specの要件を分析し、お客様のアプリケーションに最も権限のないPSPを作成します。これにより、特権のあるポッド、コンテナとして実行するユーザー、ボリュームなどを許可するかどうかを制御します。

例4：Kubernetesの監査証跡 – NIST 800-53のシステムと情報の整合性コントロールSI-4e

“組織は、組織の運営と資産、個人、または他の組織に対するリスクに変化があった場合に、システム監視活動のレベルを調整する監視装置を配備している。”

Sysdigは、インシデント対応やNIST 800-53準拠を促進するために、すべてのコンテナインフラストラクチャーのイベントを継続的に監査します。コンテナがなくなった後でも、サードパーティの監査人にコンプライアンスの証明として使用できます。

システムコール、Kubernetes、AWS CloudTrailを使ったランタイムセキュリティ

オープンソースのFalcoをベースにしたSysdig Secureのランタイムセキュリティエンジンは、カーネルレベルのシステムコール、Kubernetesの監査ログイベント、Amazon Cloudtrailのインフライベントをキャプチャーします。ランタイムイベントが利用可能になると、直ちに安全でない状況を検出し、責任者への通知、監査情報の記録、コンテナの一時停止やKillなどの自動アクションを実行することができます。

Falcoの豊富なルール構文のおかげで、多くのビヘイビア指向コントロールのルールを作成することができます。

しかし、それらのルールをゼロから作成する必要はありません。Sysdigは、複数のコントロールやファミリーを同時にカバーする、アウトオブボックスのルールや機能を数多く提供しています。

• アクセスコントロール：このファミリーにタグ付けされた72のFalcoルールがあります。たとえば、「Terminal Shell in a container」は、コントロールAC-2g、AC-2（4）、AC-17、およびAU-6（8）にもタグ付けされています。

• 監査と説明責任: このファミリーにタグ付けされた 63 の Falco ルールがあります。例えば、「Clear log activities」は、コントロール AU-6(8)、AU-2、AU-10、および CM-5 にもタグ付けされています。
• システムおよび通信の保護：このファミリーのためにタグ付けされた19個のFalcoルールがあります。例えば、「Detect creation on AWS for a HTTP target group without SSL」は、コントロール SC-8(1)のためにタグ付けされています。
• 構成管理：このファミリーのためにタグ付けされた41のFalcoルールがあります。例えば 、「Create Sensitive Mount Pod」は、コントロールAC-6(9)、AC-6(10)、CM-3、SI-4、AU-2にもタグ付けされています。
• システムと情報の整合性: このファミリーにタグ付けされた 52 の Falcoルールがあります。例えば、「Update Package Repository」は、コントロール CM-5、SI-7、SI-4、SI-3 にもタグ付けされています。
• 評価、承認、監視：いくつかのベンチマーク、6つのイメージスキャンルール、および「Read sensitive file untrusted」などの2つのFalcoルールは、コントロールCA-9、SC-4もカバーしています。
• 識別と認証 ：“Untrusted Node Unsuccessfully Tried to Join the Cluster “などの3つのFalcoルールがあります。
• インシデント対応：すべてのアクティビティ（システムコール、メモリ、ファイル、ネットワーク）のSysdig Secureキャプチャーと組み合わせたFalcoエンジン全体は、例えばコントロールIR-4(12)で指定されているように、インシデントレスポンスを中心としています。”悪意のあるコードおよび/またはインシデント後にシステムに残った他のアーティファクトを分析する。”
• リスクアセスメント：コンテナとホストのための脆弱性スキャン機能全体は、例えば、コントロールRA-5に記載されているように、リスクアセスメントを中心に記述されています。”システムとホストされているアプリケーションの脆弱性を監視してスキャンし、システムに影響を与える可能性のある新しい脆弱性が特定し、報告する。”
• システムとサービスの取得：CI/CDパイプラインに統合されたSysdigのコンテナイメージスキャンと、適合しないイメージを拒否するAdmission Controllerのポリシーは、この問題に関連する機能であり、例えばコントロールSA-10eに見られるように、次のようになっています。”システム、システムコンポーネント、またはシステムサービスの開発者が構成管理を実行し、セキュリティ上の欠陥と欠陥の解決を追跡することを要求する”
• システムと情報の完全性：52のFalcoルール「Modify binary dirs」などは、コントロールCM-5、SI-7、SI-4にもタグ付けされています。
• システムと通信の保護：「Detect outbound connections to common miner pool ports」などの23個のFalcoルールは、CM-7(1)、AC-17、SC-7(3)、SI-4(4)のコントロールにもタグ付けされています。

AnitianによるNIST 800-53ルールの実装

Anitianは、NIST 800-53/FedRampに重点を置いて、企業向けにコンプライアンスをサービスとして提供しています。SysdigをAnitianのソリューションに組み込むことで、顧客は規制遵守の要件を満たすことができるようになります。

“連邦政府内でコンテナ技術の採用が増えるにつれ、コンテナとKubernetesのセキュリティとコンプライアンスの必要性が明らかになってきました。Sysdigは、これらの環境を保護する幅広いNISTコントロールに対応する柔軟性と粒度の両方を可能にするオープンソースベースのポリシーエンジンを提供する先駆者です。”
エミリー・カミン – Anitian、プリンシパルセキュリティアーキテクト

まとめ

NIST 800-53ガイドラインは、連邦政府で使用されている情報システムのセキュリティを強化するために作成されました。このガイドラインは、連邦政府の情報を保存、処理、または送信する情報システムのあらゆるコンポーネントに適用されます。

コンテナセキュリティツールは、コンテナやKubernetesに関連するコントロールにすでにマッピングしており、時間を節約するためのチェック、ダッシュボード、レポートを提供しています。

Sysdig Secureがさらに多くのNIST 800-53コントロールをどのようにマッピングして対応するかについては、以下のリソースをご覧ください。

• オンデマンド・ウェビナーをご覧ください：コンテナとKubernetesのためのNIST 800-53コンプライアンス
  
• Sysdig Secureの無料トライアルにお申し込みください！